27B Dense 打贏 807GB 的前輩
上週我在評估一台新的 inference server 要跑什麼模型，本來 Qwen3.5-397B-A17B 的量化版本在候選清單上，然後看到 Simon Willison 的測試筆記：27B dense 模型在 coding benchmark 上全面超過那個 397B MoE 前輩。
先把數字攤開：Qwen3.5-397B-A17B 的 full weight 在 HuggingFace 上是 807GB，新的 Qwen3.6-27B 是 55.6GB。量化版（Q4_K_M）更是壓到 16.8GB，llama-server 實測約 25 tok/s，context 開到 65536。一張 RTX 4090 跑得動，一台高階 Mac mini 也跑得動。
好，事實陳述到這裡。但我覺得這件事的重點不是「小模型贏了」，而是它改變了一件很具體的事：部署的決策從「能不能跑」變成了「值不值得跑」。
以前的問題是「能不能跑得動」
一年前，想在 infra 上自架 LLM 做 coding assistant，大概就三條路：跑小模型（7B/13B）速度快但能力堪用；跑大模型（70B+）能力夠但得有 A100/H100；打 API 能力強但有資料出境問題或成本壓力。
這三條路各有硬傷，所以大部分中小型工程團隊最後都選了 API 這條——閉著眼睛接受資安風險，或者繳一筆 enterprise 合約費用換個合規說法。
27B 這個體量的模型，現在進入了「部署合理」的範圍。 在三年前的認知裡這個 size 是「還不夠用的大小」，但現在的訓練技術讓它在特定任務（比如 coding）上可以打平甚至超過舊世代頂級模型。說穿了：以前你得花 10 倍以上的硬體成本才能獲得 flagship 能力，現在這個成本差距在縮小。
但「能跑」≠「該用」
這裡是很多討論跳過的一塊。
我見過幾個工程團隊在「本地 LLM 這麼屌」的興奮浪潮下跑去買了一堆 GPU，結果發現維運成本比 API 費用還高。不是硬體貴——硬體是一次性的——是人力成本。
自架 inference server 之後你要管的事：GPU driver 升級（搞過的都知道有多鬼）、模型版本管理（哪個 team 用哪個版本怎麼 rollback）、推論服務的 monitoring（latency spike、OOM、context overflow）、量化版本的 quality regression 測試（Q4 跟 Q8 在你的 use case 上差多少？）。
這些加起來，一個 infra 工程師一週大概要花 5-10 小時，視穩定度而定。
所以我的判斷標準一直是：如果每個月的 API 費用超過一個 junior engineer 月薪的 20%，才認真考慮自架。 低於這個數字，打 API 通常是更合理的選擇，你的 infra 工程師的時間值更多錢。
Qwen3.6-27B 改變了哪一層的經濟學
但這個「自架門檻」在近幾個月確實在移動。
以 coding assistant 為例，一台 RTX 4090（二手約 NT$ 45,000-55,000 入手）跑 Qwen3.6-27B Q4_K_M：
- VRAM 16.8GB，4090 的 24GB 綽綽有餘
- ~25 tok/s，對 coding autocomplete 夠快
- 可以 24/7 running，serving 一個 5-10 人小團隊沒問題
折舊算下來每月大概 NT$ 2,000-3,000，電費加上去不超過 5,000。如果你的團隊每個月在 Copilot 或 Claude API 上燒超過這個數字，本地部署的回本期就在半年以內。
這個算術以前算不過去，因為 flagship 能力需要多卡 A100；現在開始算得過去了，因為 flagship coding 能力可以塞進一張消費級 GPU 裡。
小模型可部署性 vs 大模型能力上限，這個對立正在鬆動
更有意思的問題是：這個趨勢如果繼續，大模型的能力上限還剩多少護城河？
目前大模型仍然有幾個小模型追不上的地方：長 context 的連貫性（100k+ token 長文理解）、多步推理的穩定性（複雜 agent workflow 的失誤率）、稀有任務的泛化能力（遇到 training distribution 外的任務容易崩）。
但在特定的、定義明確的任務上，dense small model 正在縮小這個差距，甚至在特化任務上超車。這給了我一個實務上的部署框架：
任務定義越清晰 → 可以用越小的模型
→ Coding autocom
plete：27B 夠用，fine-tuned 7B 有時候也足夠
→ Code review / PR summary：27B-70B 視複雜度
→ 跨 codebase 的架構討論：可能還是打 API 用大模型比較穩
說穿了，你不需要一個模型做所有事。問題是很多公司還在用「一個 API key、一個模型」的方式思考 AI 工具，沒有按任務類型分 tier。這個習慣需要改，但改起來需要有人願意做這個分析，通常就是 infra 或 platform team 的事。
團隊導入判準，我目前用的版本
根據最近幾個月在客戶端推動本地 LLM 部署的經驗，整理一個粗略的判準框架：
先問這三個問題：
主要 use case 是哪一類？
- Coding assistant → 27B dense model 現在可以認真評估
- 客服 / RAG → 看知識庫複雜度，通常 13B-27B fine-tuned 夠
- 複雜推理 / 決策 → 暫時還是 API 比較穩
資料出境有沒有限制？
- 有限制 → 自架，沒得選
- 沒限制 → 做一下成本計算再決定
infra 團隊有沒有人有時間 own 這件事？
- 有 → 可以試
- 沒有 → 先不要，infra 債很貴
這三個問題回答完，大部分情況都能給一個明確的建議，不需要陷入「但大模型比較強」vs「但小模型比較便宜」的迴圈。
最後說一個比較感嘆的事：Qwen 這個系列從一開始我就覺得值得追，不是因為什麼 narrative，而是它的 roadmap 很明確——把 coding 任務做到極致，然後在這個基礎上往外擴。27B 打贏 397B 這件事，說穿了是這個專注帶來的結果。
反倒是那些每個任務都宣稱 SOTA 的模型，我一看就覺得難以置信。Benchmark 可以挑，但實務使用很難騙。
25 tok/s、16.8GB、一張 4090 能跑的 flagship coding model——這個組合在去年是不存在的。明年同樣的 VRAM 又能跑什麼，值得期待。
作者：CtrlC