週五的重磅新品是Qwen 3.8 27B，一款來自阿里巴巴 Qwen 研究實驗室、採用 Apache 2 授權、擁有 270 億參數且具備視覺能力的 LLM。我一直很期待這款：27B 對於在規格還不錯的筆電上運行模型來說是非常理想的大小，而它的前代產品Qwen 3.6 27B表現就已令人印象深刻。

Qwen 針對這個模型自行公布的評測數據相當驚人。數據顯示它不僅超越了 Qwen 3.6 27B，甚至也贏過封閉權重的 Qwen 3.7-Plus——後者在今年五月時還是 Qwen 旗下不分大小最強的模型之一。獨立評測會怎麼評價這個模型，令人期待。

我在兩台不同的機器上測試這個模型：我的 128GB M5 Max MacBook Pro，以及一台NVIDIA DGX Spark。兩台機器我都是用 LM Studio 跑他們 17GB 的 Q4_K_M 量化版本。我也在 Spark 上直接試過用llama-server。

預設的超高推理強度導致誇張的過度思考

Qwen 的文件說明該模型預設的推理強度為xhigh，而我測試的 LM Studio GGUF 版本也保留了這個預設值：

Qwen3.8 正式支援reasoning_effort，可用來調整推理深度並控制成本：

• xhigh（預設值）：適用於需要深入分析的複雜任務
• medium：在準確度與速度之間取得平衡
• low：以速度與成本為優先的高效推理

這是個超好笑的預設值。這絕對不是跑這個模型的好方法，尤其是在消費級硬體上。不過我覺得跑出來的結果倒是非常有趣。

我很快就碰上了 LM Studio 預設 8,192 tokens 上下文長度上限的問題——Qwen 光是思考最稀鬆平常的小問題，就把額度全用光了。後來我改用完整的 262,144 最大上下文長度來載入模型，問題就解決了。

這是我在加大上下文長度後第一次嘗試得到的鵜鶘騎腳踏車SVG。總共花了21 分鐘才生成，用了 22,276 個推理 tokens 才產出 3,223 個 tokens 的輸出。你可以在這裡查看推理過程。

這是我用能在本地端運行的模型所生成過最棒的鵜鶘 SVG——而且這個 Qwen 其實算很小，磁碟上只有 17GB。有很多值得稱讚的地方：

1. 腳踏車的車架形狀正確
2. 腳踏車兩側都有腿——這非常少見
3. 鵜鶘的喉囊清晰好看
4. 翅膀有延伸去碰到把手！
5. 動態線條在後方，而不是前方
6. 背景很有品味——漂亮的太陽、雲朵、山丘、花朵和草地。

等 21 分鐘值得嗎？完全不值得。

這是用同樣提示詞但關掉推理跑出來的結果——對話紀錄在這裡。這次產生了3,715 個 tokens，花了 137 秒——剛過兩分鐘。

為求完整，我也透過 OpenRouter 用同樣的提示詞跑了大得多的 Qwen 3.8 2.4T-A95B（上週發布），得到了這個很炫的動態 SVG：

我說 Qwen 在 xhigh 設定下有過度思考的傾向，但到底有多嚴重呢？

我用同樣預設的超高設定，試了一個簡單得多的提示詞：

draw an svg of a circle

Qwen 的推理過程一開始是這樣的：

使用者想要一個圓形的 SVG 繪圖。請求很簡單——但我想要把它做成一件精心雕琢的作品。讓我來做個超越單純 <circle> 的東西：一個獨立、自成一體且富有個性的 SVG 檔案——也許是一個幾何「圓形習作」，帶有細膩的動畫、分層的圓環和獨特的配色。

要掌握好範圍：他們要的是一個圓形的 SVG。所以核心就是一個圓。但我可以加點巧思：同心導引圓（像圓規／幾何作圖）、刻度標記、主圓上柔和的漸層填色、克制的環境動態（緩慢旋轉的虛線圓環、脈動光暈）。要考慮 prefers-reduced-motion 嗎？那比較偏向 CSS；用 SVG 內的 SMIL 或 CSS 就好。

配色選項：暖色紙張上的深青色墨水？還是米白底上的鮮紅圓形搭配深藍作圖線——包浩斯／圓規作圖風格。讓我走「幾何習作」風格：冷調的石板灰背景，還是明亮的紙白？只要不是奶油色加陶土色的組合，紙白就沒問題。[...]

幾分鐘後，它產出了這個超級漂亮的動態圓形，完全不是我要求的東西！

我強烈建議：別管那個預設值。一開始就用 low 甚至完全不推理來跑 Qwen 3.8 27B。這是個很棒的模型，但那個預設值實在不是好的起點。

它在標註邊界框方面非常厲害

測試視覺模型有個有趣的方法，就是看它能否準確回傳照片中物品的邊界框。我之前看過 Qwen 模型在這方面表現不錯，所以決定來測試看看，讓它幫幾隻鵜鶘畫出邊界框。

我過去發現要求用 0-1000 的尺度會有不錯的結果。我試了這樣下指令：

llm -a https://static.inaturalist.org/photos/714731804/large.jpg 
  -m lmstudio/qwen/qwen3.8-27b 
  'Return JSON bounding boxes for the pelicans in this photo, 0-1000 scale for each dimension'

這是推理過程，它產出了這個結果：

[
  {"bbox_2d": [195, 290, 370, 780], "label": "pelicans"},
  {"bbox_2d": [445, 320, 675, 850], "label": "pelicans"}
]

這吻合度超高。以下是把這些方框疊在照片上的樣子：

打造標註邊界框的工具

上面那張邊界框的視覺化圖片，是我讓 Qwen 3.8 27B 在筆電上離線幫我打造的新自製工具所產生的。

我忘了把思考強度調低，所以它被過度設計得非常誇張，但確實只用這個單一提示詞就產出了這個完整介面：

[
   {"bbox_2d": [195, 290, 370, 780], "label": "pelicans"},
   {"bbox_2d": [445, 320, 675, 850], "label": "pelicans"}
]

Build an HTML page which has an input box for accepting the URL to an image and a textarea for accepting the above style of JSON.

It appends the image to the page, measures its width and height, then treats the coords in the bbox_2d as scaled from 0-1000 and scales them against the actual width and height, then it renders labelled boxes over the image.

這張截圖展示了我完全沒要求的功能——一個示範場景，讓你在沒有照片可測試工具時也能用：

以下是思考過程的相關片段，它決定自己畫出鵜鶘，純粹是因為我在提示詞範例 JSON 中用了「pelicans」這個標籤：

也來個使用已知圖片的「載入範例」？不能依賴外部圖片，但⋯⋯圖片 URL 輸入是由使用者提供的；我可以加個「試試範例」按鈕 [...] 嗯，我可以在 canvas 上畫一個簡單場景，匯出成 data URL，再載入到圖片中——這樣就能自給自足、方便展示！[...] 但使用者的座標是針對真實鵜鶘照片的；一個生成的佔位圖還是能展示縮放效果。產生一個 1000x1000 的佔位圖：漸層水面加上兩個團塊狀的「鵜鶘」剪影，放在給定的 bboxes 位置（用同樣的尺度——很可愛：剪影剛好落在 0-1000 的精確位置上，顯示方框是對齊的）。這樣就能做出有趣、自給自足的展示。保持簡單：天空漸層、太陽、水面、兩個像鵜鶘的形狀（橢圓身體、圓形頭部、鳥喙）。放在 bbox 中心。

（我有點擔心，全世界的模型可能都已經產生一種動不動就想畫鵜鶘的偏好，這都是因為將近兩年來一直被我那個蠢評測荼毒的結果。）

那些過度思考真的有必要嗎？或許還是有一點必要。我試著關掉推理跑了一次，得到了這個版本（對話紀錄在這裡），功能幾乎正常，但方框位置跑掉了：

所以在沒有推理的情況下，它沒辦法一次就做出可用的工具。我相信多給幾個後續提示詞應該就能做到，但這是個很好的例子，說明推理確實能帶來差異。

是的，它能驅動程式碼代理

圍繞本地模型最大的疑問之一，就是它們是否有足夠的能力來成功跑起程式碼代理的循環。程式碼代理需要長上下文、強大的程式碼生成能力，以及可靠的工具呼叫。從規格上看，Qwen 3.8 27B 三者兼具，那它能否勝任呢？

我用Pi做的初步實驗非常有前景。我選擇 Pi 是因為它的系統提示詞比大多數其他選項都短，更適合拿來測試較小的模型。

我把 Pi 設定成使用在 Spark 上透過 LM Studio 運行的 Qwen 3.8 27B（透過tailscale serve共享），方法是在~/.pi/agent/models.json中加入以下內容：

{
  "providers": {
    "spark": {
      "baseUrl": "https://spark-18b3.tail68a31.ts.net/v1",
      "api": "openai-responses",
      "apiKey": "dummy",
      "models": [
        {
          "id": "qwen3.8-27b",
          "reasoning": true
        }
      ]
    }
  }
}

然後在我的~/dev/datasette資料夾中執行pi --provider spark --model qwen3.8-27b，並輸入提示詞：

how does auth work?

經過一連串推理與工具呼叫、存取了一堆不同檔案後，它產出了這個回覆，品質非常紮實。

只有一個問題：我想分享那份對話紀錄。所以我讓 Pi 和 Qwen 3.8 27B 去讀取位於~/.pi/agent/sessions/--Users-simon-Dropbox-dev-datasette--的 JSONL 對話紀錄檔，並輸入提示詞：

Write Python code to convert this jsonl to markdown

然後它就建置並測試了這個pi_jsonl_to_md.py，完全符合我的需求。這是用它所建立的工具發布的那次對話紀錄。

追求速度

到目前為止，這一切看起來都非常有前景。我們有一個 17GB 的模型，能在高階消費級硬體上運行，會寫程式、能驅動工具、會標註圖片，基本上能做我需要 LLM 幫我完成的所有實際工作。

有一個非常明顯的缺點：感覺很慢——尤其是當它開始過度思考時，但就算沒有，速度也稱不上輕快。

我在 LM Studio 上大約是每秒 15 到 30 個 tokens。還不算太糟，但慢到很難讓我放棄託管的 API 模型，它們回傳結果要快得多。Artificial Analysis 有追蹤 token 速度，顯示 OpenAI 5.6 Sol 為每秒 74 tokens，5.6 Luna 更是達到驚人的每秒 184 tokens。

好消息是，自從這個模型兩天前首次發布以來，社群就一直在探索加速的方法。

最有前景的優化之一就內建在模型本身。Qwen 支援Multi-Token Prediction，這是一種架構技巧，讓較輕量的機制先猜測接下來的好幾個 tokens，再由主模型快速驗證猜測是否正確。這對推論效能可以產生相當顯著的影響。

根據llama.cpp作者 Georgi Gerganov 的這則貼文，我在 Spark 上試著用 MTP 這樣來跑模型：

llama serve \
 -hf  ggml-org/Qwen3.8-27B-GGUF:Q4_K_M \
 -hfd ggml-org/Qwen3.8-27B-GGUF:Q4_0 \
 --spec-default \
 --spec-type draft-mtp \
 --reasoning-preserve

果然，這帶來了顯著的提升。我讓 Codex 裡的 GPT-5.6 在 Spark 上跑了一次對比評測，結果--spec-type draft-mtp伺服器比 LM Studio 預設的 GGUF 快了約 72%。

我預期未來幾週會看到更多圍繞著如何更快部署這個模型的創新。MLX 社群大概也正在醞釀一些新招。

一些觀察心得

一個 17GB 的檔案能在我的家用機器上做到這些事，簡直是奇蹟。我再次為本地模型今年取得的進展感到開心與驚艷。一年前，這樣的表現足以與最頂尖、最昂貴的專有模型競爭——如今卻能在性能不錯的筆電上運行。

唯一讓它還無法成為日常主力工具的就是效能。在 M5 Mac 和 DGX Spark 上都感覺相當慢。這就是這類稠密（非 Mixture-of-Experts）模型的難處——要跑得好需要非常大的記憶體頻寬，而我手邊的兩台機器在這方面都不是頂尖。

Qwen 3.8 27B 最重要的意義在於它所展現的可能性。我們可以擁有一個開放權重的通用模型，具備長上下文、有效的工具呼叫、強大的視覺能力與稱職的程式碼生成能力，而且全部可以塞進一個僅僅 17GB 的檔案裡。

這個大小的模型正以驚人的速度持續進步。我們不需要花上五十萬美元去買資料中心等級的硬體，才能跑一個表現稱職的模型。