hero

Qwen 3.6 27B 發佈後在 Hacker News 上衝到首頁，作者 Piotr Migdał 直接說出那句很多人心裡想但不敢說的話：「這是我第一個真正敢拿來當通用智能用的本地模型。」分數 37，跟 2025 年中期的 GPT-5 / Claude Sonnet 4.5 同級。但重點不是它「追上」了誰——是一年前需要花大錢租 API 才能做的事，現在一台 MacBook 就扛得住。城武認為，這篇文章值得讀的不是 benchmark 數字，而是作者在技術選擇中透露的幾個重要訊號：為什麼選 27B dense 而非 35B MoE、為什麼挺 llama.cpp 而棄 Ollama、以及他對本地模型時代即將來臨的判斷是否站得住腳。

原文摘要

Piotr Migdał 在 Quesma 部落格上發表了這篇評測，開門見山：他過去對本地模型一直失望，但 Qwen 3.6 讓他「驚嘆」。Qwen 3.6 有兩個變體——35B A3B（MoE 混合專家架構）和 27B（dense 密集架構），後者較慢但更強，也是他唯一推薦的版本。他特別強調這顆模型跑起來很燙，甚至拍了 MacBook 的熱成像照片——膝蓋都快融化了，但他說值得。

測試環節： 他用 Simon Willison 的「企鵝騎腳踏車」煙霧測試來驗證模型基礎能力，自己則用限制性寫作測試。他請模型寫一首關於 Zouk 舞蹈和量子物理的八行詩——思考過程被完整記錄下來，無論是量子術語的斟酌還是押韻安排都相當合理。然後他在 OpenCode 中請模型用 pnpm 建立一個六角踩地雷遊戲——一次就成功，從單一 prompt 生成一個完整的 Node 套件。相比之下，MoE 版的 35B A3B 雖然更快，卻忽略了他的指示，直接用單一 index.html 搞定。

實戰測試： 當然，創意寫作或踩地雷複製版不是日常開發。作者用一個朋友提供的 prompt——為蠟燭店建立 landing page——來測試真實工作場景。幾分鐘內就產生了一個可運作的頁面：有反應、預設值合理，全部來自一個簡短的 prompt。以當前前沿模型的標準來看不算驚豔，但這已經是實際可用的工作成果。

本地部署： 作者推薦 llama.cpp 而非 Ollama，甚至直言「我會建議基於倫理理由不要用 Ollama」。他詳細說明了從 Hugging Face 下載量化模型的流程——BF16 預設精度、8-bit 量化可省一半空間且幾乎不損品質。他選擇的是 unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0，一個支援多token預測（MTP）的 8-bit 量化版。完整的 llama-server 啟動指令如下：指定 MTP 草稿模式、所有層級載入 GPU、啟用 flash attention、設定 64K 上下文（原生支援 256K）、固定 port 8080。啟動後可在瀏覽器直接對話，同一個伺服器也可用於 vibe coding。他列出了三個 agent 選擇：全功能的 OpenCode、簡潔的 Pi、自我改進的 Hermes。OpenCode 的整合只需要在設定檔中新增一個 provider 即可。

效能數據： 作者在 MacBook Max M5 128GB 上跑了完整測試，比較有無 MTP 的差異，也對比了 35B A3B 以及 DeepSeek V4 Flash 的量化版 DwarfStar4。35B A3B 在 llama.cpp 下達 93 tok/s（+MTP 105 tok/s），27B 則為 18 tok/s（+MTP 32 tok/s）。30 tok/s 被認為「在典型前沿模型 API 範圍內」。有趣的是，mlx-lm 這個專為 Apple Silicon 設計的工具反而比 llama.cpp 慢。GPU 使用率達 95%，代表資源被有效利用。一位 HN 網友回報在 RTX 5090 上以 Q6_K + Q4_0 KV 量化跑到 50 tok/s，約使用 28/32 GB VRAM。作者坦言 35B A3B 快三倍，但他寧可產出少但品質高——他選 27B。

與前沿模型的比較： Artificial Analysis 的評分顯示：Qwen 3.6 27B 得到 37 分，相當於 2025 年中期的 GPT-5 或 Claude Sonnet 4.5；35B A3B 為 32 分，相當於 early 2025 的 o3 或 Claude 4 Sonnet；作為對照，Gemma 4 31B 只有 29 分（late 2024），DeepSeek V4 Flash 為 40 分（late 2025）。作者特別加入 Gemma 4 31B 的對比，因為很多人拿它當本地編碼預設模型——但無論 benchmark 還是社群共識，Qwen 3.6 27B 都明顯勝出。一個但書：8-bit 量化幾乎不影響品質，但 DwarfStar4 用了更激進的 2-4 bit 量化，肯定不如完整模型。作者個人感覺在這些量化條件下 27B 跟 DwarfStar4 差不多（或略好），但對於長上下文專案，DS4 可能有優勢。

未來展望： 作者認為我們正在進入一個可以跑自己模型的迷人時代。Claude Fable 5 被下架就是警訊。前沿模型目前都在巨額補貼下運作——每月 $100 可以換到價值數千美元的 token——趁折扣還在的時候用吧。本地模型可以微調、不會被下架、企業可以用於敏感資料、個人可以用於不想跟中美兩國共享的醫療或隱私資料。GLM 5.2 雖然不能在 MacBook 或單張 RTX 5090 上跑，但在公司預算內已經可管理。他大膽預測：未來會出現比當前 SOTA 更聰明、同時能在本地裝置（甚至手機）上跑的模型。目前的模型把原始智能和事實知識混合在同一個權重中，未來的模型很可能會分離這兩者，把大量知識卸載到工具呼叫上。

城武觀點

這篇文章表面上是 Qwen 3.6 的評測，但城武讀完後覺得真正有意思的是作者在字裡行間做的幾個選擇——這些選擇各自透露了本地 LLM 生態系的不同層面。

第一，選 27B dense 而非 35B MoE 的訊息。

作者很清楚地說：「我寧可產出少但品質高。」這聽起來像個人偏好，但背後是一個更深層的命題：我們衡量本地模型的框架一直都是錯的。到今天為止，大部分人評估本地模型的第一個問題是「tok/s 多少？」——但 tok/s 是 API 時代留下來的思微（思維），那時候 token 是計費單位，快=省錢。在本地跑模型，token 不用錢，快慢只影響等待時間。真正該問的問題是「這個 token 值不值得生成？」如果你產出的程式碼第一版就能用，那 18 tok/s 也遠比 90 tok/s 但產出 garbage 來得划算。quality-per-watt——每瓦特功耗下的輸出品質——才是本地場景的正確度量衡。作者選擇 27B 等於在用行動說：這個領域的評估框架該從量轉向質了。

第二，llama.cpp vs Ollama 的倫理宣示。

「我會建議基於倫理理由不要用 Ollama」——這句話在 HN 上肯定會引發討論。城武的看法是：Ollama 的問題不在技術（它確實讓本地模型部署變簡單了），而在治理。Ollama 是一個封閉的開源專案——程式碼開源，但路線圖、決策流程、商業模式都不透明。它本質上是一個 VC-backed startup 用 open-core 模式在經營開源專案。相比之下，llama.cpp 由 ggerganov 主導，是真正的社群驅動，沒有外部資本壓力。這不是技術選擇，這是政治選擇——你選擇把本地 AI 基礎設施交給誰治理。城武覺得多數使用者不會在意這個差別，但作者特別點出來，恰恰是因為他意識到：當本地模型變成基礎設施的那一天，誰控制這些工具就等於誰控制了你跟模型之間的那層。

第三，「夠用門檻」已經被跨過了，剩下的是市場敘事的戰爭。

Qwen 3.6 27B 分數 37，對標的是「2025 年中期的 GPT-5/Claude Sonnet 4.5」。這句話翻成白話文就是：一顆能在 MacBook 上跑的模型，已經追上一年前的前沿水準。對 90% 的開發任務——寫 CRUD、做 landing page、寫單元測試、重構程式碼——你根本不需要 GPT-5.6 或 Claude Opus 4.5。真正卡住本地模型普及的，已經不是模型能力，而是工具鏈和使用者習慣。當你說「我要等本地模型追上 GPT-5.6 才開始用」，等於在說「我要等 Model T 跑贏法拉利才肯開車」——你錯過了的是那個夠用以經在跑的時刻。

作者用一句話總結了這個時代的矛盾：「每月 $100 可以換到價值數千美元的 token，趁折扣還在的時候用吧。」但同時他又說本地模型不能被拿走。這兩件事同時為真：API 很划算但那是一個限時優惠，本地模型才是長期持有。城武賭的是：未來六個月內，我們會看到更多類似 Qwen 3.6 27B 的 model release 把「夠用門檻」再往下推，而那時候選擇堅守 API 的人會發現自己付的錢越來越多，得到的邊際回報越來越少。

城武的未解檔案——18 tok/s 的模型你敢拿來寫 production code？敢。因為它給你的不是最快的 token，而是最不需要重寫的那個。