2026 年 8 月 16 日

上週五發布的重磅模型是 Qwen 3.8 27B，這是一個來自阿里巴巴 Qwen 研究實驗室、採用 Apache 2 許可證的 27B 參數視覺化大型語言模型（LLM）。我一直很期待這個模型：27B 的大小非常適合在規格合理的筆記型電腦上運行，而且它的前身 Qwen 3.6 27B 已經令人印象深刻。

Qwen 針對此模型自行報告的基準測試結果令人驚訝。它們顯示，相較於 Qwen 3.6 27B 和今年五月仍是 Qwen 最強大模型之一的閉源 Qwen 3.7-Plus，新模型都有顯著提升。獨立基準測試會如何評價這個模型，將會很有趣。

我一直在兩台不同的機器上運行這個模型：我的 128GB M5 Max MacBook Pro 和一台 NVIDIA DGX Spark。在這兩台機器上，我都使用 LM Studio 及其 17GB Q4_K_M 量化版本。我也嘗試直接在 Spark 上使用 llama-server。

Qwen 的文件將模型預設的推理努力（reasoning effort）描述為「xhigh」，而我嘗試的 LM Studio GGUF 版本也保留了這個預設值：

Qwen3.8 官方支援 reasoning_effort，可用於調整推理深度和控制成本：

xhigh (預設)：適用於需要徹底分析的複雜任務

medium：平衡準確性和速度

low：高效推理，優化速度和成本

這是一個非常有趣的預設值。它絕對不是運行模型的最佳方式，尤其是在消費級硬體上。我發現結果非常有趣。

我很快就遇到了 LM Studio 預設上下文限制 8,192 個 token 的問題，Qwen 即使在處理最普通的任務時，也會用盡所有 token 來「思考」。我將模型載入到完整的 262,144 最大上下文長度，這個問題就消失了。

這是我第一次嘗試增加上下文長度後得到的騎自行車的鵜鶘 SVG 圖片。它花了 21 分鐘才生成，使用了 22,276 個推理 token 來產生 3,223 個輸出 token。你可以在這裡閱讀推理追蹤記錄。

這是我用可在本地機器上運行的模型生成過最好的鵜鶘 SVG 圖片，而且這個 Qwen 模型相當小，磁碟上只有 17GB 的檔案。它有很多值得稱讚的地方：

自行車車架形狀正確

自行車兩側都有腿，這非常罕見

清晰的鵜鶘喉囊

翅膀延伸到把手！

運動線條在後面，而不是前面

有雅緻的背景，漂亮的太陽、雲朵、小山、花朵和草地。

等待 21 分鐘值得嗎？絕對不值得。

這是關閉推理後運行相同提示詞的結果，記錄在此。這次產生了 3,715 個 token，耗時 137 秒，剛好超過兩分鐘。

為了完整性，我還使用 OpenRouter 透過更大的 Qwen 3.8 2.4T-A95B（上週發布）運行了相同的提示詞，得到了這個時髦的動畫 SVG：

（您的瀏覽器不支援 HTML5 影片。）

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

我嘗試了一個更簡單的提示詞，同樣使用預設的「極高」設定：

畫一個圓形的 SVG

Qwen 的推理追蹤記錄是這樣開始的：

使用者要求畫一個圓形的 SVG。簡單的請求，但我希望它是一個精心製作的作品。讓我做一些超越簡單 <circle> 的東西：一個具有特色、獨立的 SVG 檔案，也許是一個幾何「圓形研究」，帶有微妙的動畫、分層的環和獨特的調色板。

保持範圍正確：他們要求一個圓形的 SVG。所以核心是一個圓。但我可以增加工藝：同心導向圓（像指南針/幾何繪圖）、刻度線、主圓上的柔和漸變填充、克制的環境運動（緩慢旋轉的虛線環、脈動的光芒）。尊重 prefers-reduced-motion？那更多是針對 CSS；SVG SMIL 或 SVG 內的 CSS 都可以。

調色板選項：深藍綠色墨水在暖色紙上？還是大膽的朱紅色圓圈在米白色上，配上海軍藍的結構線，包浩斯/指南針繪圖的感覺。讓我選擇「幾何研究」的外觀：冷灰色背景，還是明亮的紙白色？如果不是奶油色和赤陶色組合，紙白色也可以。(...)

幾分鐘後，它產生了這個絕對美麗的動畫圓形，這完全不是我要求的！

（您的瀏覽器不支援 HTML5 影片。）

我的強烈建議是：忽略那個預設值。一開始運行 Qwen 3.8 27B 時，請將推理等級設定為「low」甚至「none」。這是一個很棒的模型，但哇，那個預設設定真是一個糟糕的起點。

它非常擅長邊界框偵測

測試視覺模型的一個有趣方法是看它能多好地回傳照片中物體的邊界框。我之前看過 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"}

]

建立一個 HTML 頁面，其中包含一個用於接受圖片 URL 的輸入框和一個用於接受上述 JSON 樣式文字的文字區域。

它將圖片附加到頁面，測量其寬度和高度，然後將 bbox_2d 中的座標視為從 0-1000 縮放，並根據實際寬度和高度進行縮放，然後在圖片上渲染帶標籤的框。

這張截圖顯示了我沒有要求的功能之一，一個演示場景，用於在沒有照片可測試工具時使用：

這是相關的思考追蹤片段，其中它決定自己繪製鵜鶘，僅僅因為我在提示詞中給它的範例 JSON 中使用了「pelicans」這個標籤：

還有一個「載入範例」按鈕，使用已知圖片？不能依賴外部圖片，但是……圖片 URL 輸入是使用者提供的；我可以添加一個「嘗試範例」按鈕 [...] 嗯，我可以在 canvas 上繪製一個簡單的場景，將其匯出為資料 URL，然後載入到圖片中，這樣就獨立且可演示了！

[...] 但使用者的座標是針對實際的鵜鶘圖片；生成的佔位符仍然可以演示縮放。生成一個 1000x1000 的佔位符：漸變水面 + 兩個 blob 狀的「鵜鶘」剪影，放置在給定的邊界框處（使用相同的比例，可愛：剪影在確切的 0-1000 位置，顯示框對齊）。

這構成了一個有趣、獨立的演示。保持簡單：天空漸變、太陽、水、兩個鵜鶘形狀（橢圓形身體、圓形頭部、喙）。放置在邊界框中心。

（我有點擔心世界各地的模型可能會傾向於在任何可能的情況下繪製鵜鶘，這是我近兩年來接觸我愚蠢的基準測試所導致的。）

所有這些過度思考都是必要的嗎？也許是，至少有一點。我嘗試關閉推理，得到了這個版本（記錄在此），它幾乎可以工作，但顯示的框位置不正確：

所以沒有推理，它無法一次性生成一個可用的工具。我相信透過一些後續提示詞可以達到目的，但這是一個很好的例子，說明推理可以帶來多大的不同。

是的，它可以驅動程式碼代理

關於本地模型最大的問題之一是，它們是否有足夠的運算能力來成功運行程式碼代理迴圈。程式碼代理需要長上下文、強大的程式碼生成支援和可靠的工具呼叫。從理論上講，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，並提示：

auth 如何運作？

經過一系列的推理和工具呼叫，它存取了許多不同的檔案，然後產生了這個非常可靠的回覆。

只有一個問題：我想分享那個記錄。所以我將 Pi 和 Qwen 3.8 27B 指向 ~/.pi/agent/sessions/--Users-simon-Dropbox-dev-datasette-- 中的 JSONL 記錄檔案，並提示：

編寫 Python 程式碼將此 jsonl 轉換為 markdown

它建立並測試了這個 pi_jsonl_to_md.py，它完全符合我的需求。這是該會話記錄，使用它創建的工具發布。

追求速度

到目前為止，這一切看起來都非常有希望。我們有一個 17GB 的模型，可以在高階消費級硬體上運行，並且可以編寫程式碼、驅動工具、標註圖片，並普遍完成我從 LLM 獲得實際工作所需的一切。

有一個非常重要的問題：它感覺很慢，尤其是在它開始過度思考時，但即使沒有過度思考，它也不是特別輕快。

我從 LM Studio 獲得了大約每秒 15-30 個 token 的速度。這不算太糟，但它足夠慢，以至於很難讓我放棄託管 API 模型，後者可以更快地回傳結果。Artificial Analysis 追蹤 token 速度，顯示 OpenAI 5.6 Sol 為每秒 74 個 token，5.6 Luna 則達到驚人的每秒 184 個 token。

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

其中一個最有希望的優化內建在模型本身中。Qwen 支援多 token 預測（Multi-Token Prediction，MTP），這是一種架構技巧，其中一個較便宜的機制會提前猜測幾個 token，然後主模型可以快速驗證這些猜測是否正確。這對推理性能有相當顯著的影響。

根據 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 上都感覺相當慢。這就是這些密集型（非混合專家）模型的缺點，它們需要大量的記憶體頻寬才能表現良好，而我能使用的機器在這方面都不是頂級的。

Qwen 3.8 27B 最重要的一點是它所展示的。我們可以擁有一個具有長上下文、有效工具呼叫的開源通用模型。