昨天我們拆穿了 Q4_K_M 的真相——它是規格沒錯，但不是品質保證：同一個等級、不同人壓，第三方量到的 KL 散度可以差近三倍。
檔案會挑了，今天回答更前面的問題：模型本身該選哪顆？
2026 年 8 月的 Hugging Face 上，號稱能地端跑的模型幾百顆。我的做法很粗暴：硬碟只留六組，從 16GB 就跑得動的 gpt-oss-20b 到 128GB 工作站才輪得到的 DeepSeek，每一格都有解（gpt-oss 的 20b 與 120b 算同一組）。
| 模型 | 參數（總/啟用） | Context | Reasoning / Thinking | License | 推薦本地檔 |
|---|---|---|---|---|---|
| Qwen3.6-27B | 27B dense | 256K | 開 | Apache-2.0 | Q4_K_M 16.8GB |
| Qwen3.6-35B-A3B | 35B / 3B MoE | 256K | 開 | Apache-2.0 | UD-Q4_K_M 22.1GB |
| Gemma 4 12B | 12B dense | 256K | 可開，預設關 | Apache-2.0 | 官方 QAT 7.0GB |
| gpt-oss-20b / 120b | 21B/3.6B・117B/5.1B | 128K | effort low/medium/high | Apache-2.0 | 原生 MXFP4 12.1 / 63.4GB |
| GLM-4.7-Flash | 31B / 3B MoE | 202,752 | 開 | MIT | Q4_K_M 18.3GB |
| DeepSeek-V4-Flash-0731 | 304B / 約 13B 啟用 | 1M | effort low/high/max | MIT | UD-IQ3_XXS 104GB |
註：規格取自各家 model card 與 config.json，檔案大小取自 HF repo（查證日 2026-08-16）。最後一欄各家量化格式不同，不能橫向比誰省；帶
UD-的是 Unsloth 動態配置，不是標準 preset（Day 05 分過）。那也只是權重下限，實際還要加 KV cache 與 runtime 開銷——gpt-oss-120b 檔案 63.4GB，官方門檻寫單張 80GB。
圖 1：16GB 已經有入門選擇，主力甜蜜點落在 24–32GB；再往上就是 80GB／128GB 級，門檻跳著走。
拉開差異的是對外散布、商業產品與 MaaS。以 Kimi K3 這類帶規模門檻的自訂授權為例：產品月活破億或月營收兩千萬美元，UI 得標出「Kimi K3」；如果你的服務讓第三方能實質控制輸入、推理參數或訓練資料（授權文件叫 Model as a Service），而你和關係企業連續 12 個月合計營收超過兩千萬美元，商用前得先另簽合約。
純內部使用通常碰不到這些門檻，但自訂授權仍要逐份確認，別把「內部使用」當成通用豁免。
圖 2：同一顆模型，不同用法觸發的條款不同。內部使用通常碰不到規模門檻，對外產品看商業條款，MaaS 才是額外授權真正瞄準的對象。
今天這六組全是 Apache-2.0 或 MIT，沒有上面那種 MAU／營收／MaaS 的額外門檻。
每一顆官方都給了建議的 sampling，位置不一定在 model card。先把它們放在一起，後面各節只講各家的雷：
27B 是全能主力，agentic coding 同級最強之一。35B-A3B 每個 token 只啟用約 3B，單請求生成通常快上不少（實際 tok/s 看 backend 與記憶體頻寬，Day 04 有官方跑分），是 24–32GB 的甜蜜點。兩顆都是多模態、原生 256K。
你以為在照官方抄，runtime 可能已經幫你改掉了。我去 Ollama registry 撈 qwen3.6:27b 的內建參數，拿到的是 presence_penalty=1.5——那是 35B-A3B 的值，27B 官方要 0.0，Ollama 給兩個尺寸塞了同一組。ollama run 之前先 /show parameters 對一次。
8 月中上架的 Qwen3.8-27B 建立在 Qwen3.5 的架構基礎上，參數量同為 27B，仍是 Apache-2.0。但官方把它列為完整的 pre-training + post-training checkpoint，行為不能假設跟 3.6 等價：它 thinking 預設開，連 preserve_thinking 都改成預設開啟。同一家隔一代，runtime 行為都會變，換之前拿自己的評測集跑一輪。
先更正一個口耳相傳：家族是 E2B / E4B / 12B / 26B-A4B / 31B，「27B」這個型號不存在——27B 是上一代 Gemma 3 的尺寸，很多文章直接沿用了。
全系列 Apache-2.0，官方直接出 QAT 量化檔（12B 6.98GB、26B-A4B 14.44GB、31B 17.65GB、E4B 5.15GB），那份就是品質基準，優先選它。GGUF 走多模態要另外抓 mmproj（31B 那顆 1.20GB）；全系列吃文字與圖，音訊只有 E2B、E4B 與 12B Unified，上限 30 秒。
20b 是我在 16GB 級的首選，120b 塞得進單張 80GB。它出廠就帶量化：佔參數大宗的 MoE expert weights 做過 MXFP4 QAT（不是整顆都 4-bit），官方評測也跑這份權重，所以它就是品質基準，不必為了「4-bit」三個字再重壓一次。
它的長 context KV 帳很漂亮：一半的層走 sliding window，那半邊的 cache 長到 window 上限就封頂，所以每多一個 token 只要 24 KiB（20b）／36 KiB（120b）。
但這不是它的獨門絕活。2026 這一代幾乎都在對 KV 動刀，路數有三種：讓部分層只看局部（sliding window）、把部分層換成狀態固定的 linear attention、把 KV 壓成 latent 再存（MLA）。同一把尺量下來（由各家 config.json 換算，FP16）：
| 模型 | 減法路數 | 長 context 邊際 cache/token |
|---|---|---|
| Gemma 4 12B | sliding ×40 / global ×8，global 層 K=V 共用 | 8–16 KiB |
| Qwen3.6-35B-A3B | linear ×30 / full ×10 | 20 KiB |
| gpt-oss-20b | sliding ×12 / full ×12 | 24 KiB |
| gpt-oss-120b | sliding ×18 / full ×18 | 36 KiB |
| GLM-4.7-Flash | 每層都是 global，但走 MLA 壓縮 | 約 53 KiB |
| Qwen3.6-27B | linear ×48 / full ×16 | 64 KiB |
| 對照：Llama-3.3-70B | 無 | 320 KiB |
這欄只算「再長一個 token 多出多少」，linear state、封頂後的 sliding cache 與 runtime overhead 都不計。Gemma 的 global 層
attention_k_eq_v=true、K 與 V 同一份，落在 8 還是 16 KiB 看 runtime 有沒有真的共用。DeepSeek-V4-Flash 沒列進來：它走 CSA + HCA 的 hybrid compressed attention，換算不對等，Day 09 再拆。
兩件事跟直覺相反。Qwen3.6 兩顆都是 hybrid linear attention，35B-A3B 只要 20 KiB，比 gpt-oss-20b 還省；但同門的 27B 因為 full 層多一倍、KV 頭也多，是主模型列裡邊際 cache 最大的一顆。而 GLM-4.7-Flash 每層都是 global attention，卻不是最耗的——它用 MLA 把 KV 壓成 512 維 latent 再存，把帳壓到 53 KiB。
所以光看「有沒有 sliding window」不夠，得看它用哪種減法、你要開多長。至於 KV 量化能不能再對半砍，要看 runtime 支不支援該種 cache：標準 GQA 大多能開 8-bit，MLA 的 latent 與 linear 的 state 則各家實作不一，別預設一句「全部減半」。
官方 card 稱它 30B-A3B，HF 的 safetensors 統計則是約 31B／3B 啟用，又一個 Day 04 說的「型號數字不等於逐 tensor 加總」。MIT，定位是單卡 agentic coding，跟 Qwen3.6-35B-A3B 同一格對打。
圖 3 那組 temperature=0 是 τ²-Bench 的評測設定，別當成所有 tool-use 的通用建議。它的 tool call 是 XML 不是 JSON，chat template 裡長這樣：<tool_call>{name}<arg_key>…</arg_key><arg_value>…</arg_value></tool_call>，自接 OpenAI-compatible 端要先確認 parser 支援。
官方 preview 卡列的架構規格是 284B／13B 啟用，-0731 的 safetensors 統計則約 304B——兩個口徑不同，記憶體規劃看實際 checkpoint。MIT，context 1M。這是本系列的 T3 參照組：3-bit 也要 104GB 起跳，消費卡免談。128GB 機器建議 IQ3_XXS，M4 Max 剛好卡在門檻上，這正是 T1 後面要挑戰的終極測驗。
型號要指名帶日期戳的：裸名 DeepSeek-V4-Flash 是 preview，-0731 才是正式版，官方說明它附帶 speculative decoding module。兩者 safetensors 差約 13B，但別拿 config 的 num_nextn_predict_layers 當證據，preview 那份也是 1。Ollama 官方 library 目前只有 :cloud 系列 tag，但社群 GGUF 已經能直接 ollama run hf.co/unsloth/DeepSeek-V4-Flash-0731-GGUF:UD-Q4_K_XL 起來，只是沒有官方 local tag。
同一格還有 Step-3.7-Flash（198B／約 11B 啟用，Apache-2.0，256K，多模態 agent 取向）。官方建議 128GB，但那是照自家 Q3_K_L 算的：權重 102.5GB ＋ 投影檔 4GB ＋ runtime 約 7GB。換成 Unsloth 的 IQ3_XXS，權重只要 73.6GB，同樣加完約 85GB，96GB 那格塞得下——DeepSeek 同級要 104GB，連權重都過不了。代價是社群的量化與部署經驗比 DeepSeek 少一截。
再往上的 Kimi K3（2.8T 總參／104B 啟用，原生 MXFP4 權重要 1.56TB）與 GLM-5.2（753B、1M context、MIT），是 T4+ 的世界，列出來只為了說明「開源不等於跑得動」。Day 15 會解剖它們的架構。
圖 4：上排是 runtime 替你決定的兩件事，中排是各家方向相反、最容易抄錯的一條，下排是各家自己的坑。
圖上排那兩條特別容易中。Ollama 的 context 預設值，官方文件自己目前是打架的：新版 Context length 專頁寫的是依 VRAM 給 4K／32K／256K，FAQ 仍留著「預設 4096」，Modelfile Reference 那頁甚至還標著 num_ctx 預設 2048——三種說法並存。與其猜哪個版本說了算，不如讓模型跑起來，用 ollama ps 看 CONTEXT 欄位的實際分配值（/show parameters 看的是 Modelfile 帶的 sampling 參數，不是 runtime 最終給的 context），再自己指定掉：
OLLAMA_CONTEXT_LENGTH=16384 ollama serve
# 或在 API 請求的 options 裡帶 num_ctx
中排那條最值得單獨記住：**多輪對話要不要把前幾輪的 thinking 回餵，各家規則不同，方向甚至相反。**Qwen3.6 預設只留最新一輪，但官方訓練過保留歷史的能力，agent 場景建議開 preserve_thinking；GLM-4.7-Flash 明確要求多輪 agentic 打開 Preserved Thinking；DeepSeek-V4 的官方範例支援把上一輪 reasoning_content 放回 messages。只有 Gemma 4 明文要求歷史只留最終回覆，而它連這條都有 tool call 的例外。
所以流傳很廣的那句「多輪要記得把 thinking 剝掉」，套到前三家會砍掉官方特地訓練過的能力。
下排三個各家自己的坑。gpt-oss 的 Harmony format 是硬需求，但 Transformers、Ollama 這類整合好的 runtime 會替你處理；要小心的是自己接 GGUF／llama.cpp、或換掉 chat template 與 parser 的時候，別隨便抓一份 Jinja 就跑。GLM-4.7-Flash 官方 card 有 Transformers／vLLM／SGLang 三種範例，主推仍是後兩者；走 GGUF 得自己確認 template、tool parser 與 reasoning parser，Unsloth 的指南就建議避開 Ollama、改用 llama.cpp 或 LM Studio。Qwen3.6 在 llama.cpp 長 context 搭量化 KV 若出現亂碼，先把 KV 恢復高精度排除看看。
圖 5：公開 benchmark 不是第一刀。授權與記憶體先把候選縮到兩三顆，決勝的是你自己 workload 的評測。
16GB 級的機器優先評估 gpt-oss-20b 或 Gemma 4；24–32GB 在 Qwen3.6 雙生子與 GLM-4.7-Flash 之間看場景；單張 80GB 是 gpt-oss-120b 的主場。這裡說的是權重有機會完整載入，不代表標稱的 200K／256K context 也能全開——context 要另外照上面那張表算 cache。
DeepSeek-V4-Flash 要另外算一格。它連 3-bit 都要 104GB，80GB 放不下，得 128GB 以上的統一記憶體或多卡才輪得到。
但表格幫不了你最後一件事：任務品質本身也是門檻。授權過了、記憶體塞得下，tool call 成功率只有六成，這顆對你還是不能用。前面幾格只把候選砍到兩三顆，最後一刀要拿自己的評測集砍。
型錄日，不開機也能跟。手邊有 Ollama 的話，跑一顆起來用 ollama ps 看它實際給了多少 context，再用上面那行拉高；跑的剛好是 Qwen3.6 的話，順手試一次 enable_thinking=false，比較兩種模式的差別。
表裡有一格值得多看一眼：DeepSeek-V4-Flash 的 3-bit 要 104GB 起跳，而 M4 Max 有 128GB，看起來剛剛好？明天 Day 07「128GB 只能用 96GB？」告訴你為什麼沒那麼簡單：Mac 的統一記憶體預設只肯分 75% 給 GPU，那條線在哪、怎麼移、移了會怎樣。
咱們明天見。
iThome鐵人賽
看影片追技術