Qwen3.8-27B 在 08 月 14 日上架 Hugging Face，隔天我們把它下載到一台 DGX Spark（GB10、128 GB 統一記憶體）上，跑了一天的量測，三種 checkpoint、一套社群最佳化配方、兩個對照模型，全部出自同一支測試程式、同一個推論映像。
CyberQ 這篇的主線本來只有一個，驗證兩天前寫下的一個預測。預測成立了，但過程中出現一個更值得注意的點，這一整篇的加速數字，有的能在真實使用下留住，有的一碰到取樣就蒸發，最後那節才是重點喔。
一個反潮流的模型
Qwen3.8-27B 值得注意的地方在於它是密集的。過去兩年小型開源模型幾乎一面倒走向稀疏 MoE，總參數做大、活躍參數做小，用便宜的權重讀取換吞吐。Qwen 自家的 3.6-35B-A3B 就是典型，350 億總參數，每個 token 只活躍 30 億。3.8-27B 反過來，278 億參數，每個 token 全部都要算。它把省下來的力氣放在別的地方。
64 層裡只有 16 層跑 full attention，其餘 48 層是 Gated DeltaNet。
原生 262K context，官方說可延伸到 1M。
內建 vision tower，是原生多模態模型。
內建一層 MTP（多 token 預測）draft head，權重就在 repo 裡，而這點則是本次測試的主角。
為什麼這次測試值得做 ?
日前我們測完 Qwen3.6-35B-A3B，在報告裡留了一段預測，Qwen 3.8 27B 若為密集模型或活躍參數比例較高，投機解碼的提升幅度預期會明顯高於 21%，那個差異本身就是重點，不是量測誤差。
CyberQ 認為，投機解碼的紅利建立在一個前提上，驗證多個 token，與驗證一個 token，讀取一樣多的權重。當推論卡在記憶體頻寬時這成立，多驗證幾乎免費。但之前的Qwen3.6-35B-A3B 每步只讀 30 億參數，權重讀取本來就便宜，瓶頸落在計算與排程，多驗證一個 token 就會真的多算一次喔。
也就是說，極稀疏的 MoE 應該是投機解碼最不划算的情況，密集模型應該要漂亮得多，這是一個可以直接證偽的預測，而 Qwen 3.8-27B 剛好是完美的對照組，和 Qwen3.6-35B-A3B 一起測試剛剛好。
測試環境
| 項目 | 值 |
|---|---|
| 硬體 | DGX Spark，GB10（sm_121），121 GB 統一記憶體 |
| 模型 | Qwen3.8-27B，27.78B 參數，密集；三種 checkpoint 見下 |
| 架構 | 64 層＝16 ×（3 × Gated DeltaNet + 1 × Gated Attention），hidden 5120，內建 1 層 MTP |
| 推論 | vLLM 0.26.1rc1（vllm/vllm-openai:muse-glimmer，image 3f53491eb2c5） |
| 設定 | TP=1、gpu-util 0.80、max-model-len 32768 |
測試方式
這次的測試方式，是採用簡單的規則，但每一條都有對應理由：
走 /v1/completions 而不是 chat completions。不套 chat template，繞開思考模式，量的是純解碼。
貪婪解碼加 ignore_eos，固定 800 token。每個樣本吐出的 token 數完全一樣，回覆長度不會隨模型想多久而漂移。
先暖機再量。啟動後第一個請求要付 draft path 的 JIT 編譯成本。Qwen3.6 的暖機那次是 25.69 tok/s，穩態是 52.85，足足是差了一倍。
投機指標取量測區間內的計數差，不是 Prometheus 的累計值。三次取樣取中位數，實際散布都在 0.6% 以內，多數在 0.1% 以內。
重測結果：無 MTP 52.85 tok/s（手測 52.95，差 0.19%）、MTP n=1 64.24（手測 64.20，差 0.06%）。
所以測試基準重現，所以基於同樣的理由，本文後面的測試中，之前這篇文章中 Muse-Glimmer 的舊數字也不引用，改成整組重測。
測試結果數字
官方 FP8，TP=1、gpu-util 0.80、max-model-len 32768：
| 設定 | 吞吐 | 對基準 | Draft 接受率 | 接受長度 | 每步成本 |
|---|---|---|---|---|---|
| 無 MTP | 8.08 tok/s | — | — | 1.00 | 1.00× |
| MTP n=1 | 12.60 | 1.56× | 77.2% | 1.77 | 1.14× |
| MTP n=2 | 14.92 | 1.85× | 69.2% | 2.39 | 1.29× |
| MTP n=3 | 15.32 | 1.90× | 58.4% | 2.75 | 1.45× |
每步成本是接受長度除以實測加速時，當開了投機模型來加速後，每個解碼步驟相對基準貴了多少，這個每步成本的欄位呢，是整份報告的重點。
對照 Qwen3.6-35B-A3B：
| Qwen3.8-27B（密集 27B） | Qwen3.6-35B-A3B（3B 活躍） | |
|---|---|---|
| 無 MTP | 8.08 tok/s | 52.85 tok/s |
| MTP n=1 | 12.60（1.56×） | 64.24（1.22×） |
| n=1 接受率 | 77.2% | 81.2% |
| n=1 接受長度 | 1.77 | 1.81 |
| n=1 每步成本 | 1.14× | 1.49× |
預測成立，而且機制對得上
看第二張表的中間兩列，兩個模型的 draft 接受長度幾乎一樣（1.77 對 1.81）。draft head 草稿模型的品質差不多，猜得一樣準。但加速差了將近三倍，1.56× 對 1.22×。
CyberQ 分析，這次的差別全部落在最後一列。密集 27B 多驗證一個 token 只貴 14%，可是 A3B 要貴 49%。而理想的 1.77 倍加速，密集模型拿到了 1.56，A3B 的 1.81 倍只換到 1.22 而已。
這正是兩天前推論的機制，而且是用這二款真實模型量出來的，不是算出來的。極稀疏的 MoE 是投機解碼最不划算的情況，現在有資料證實。
同一個結構也解釋了兩邊 n 值的最佳點為什麼不同。A3B 上 n=2 反而輸給 n=1（61.40 對 64.20），因為每多驗證一個 token 都要付近五成的步驟成本。我們可以看密集 27B 這邊的 n 一路加到 3 都還在變快，只是報酬遞減得很明顯。但是這樣就看得出來這二款模型的特性不同。
投機解碼救不了活躍參數
同一批數字的另一面就沒那麼好看了，Qwen3.8-27B 開滿投機解碼模型機制加速後是 15.32 tok/s。Qwen3.6-35B-A3B 完全不開投機是 52.85 tok/s。
開頭機模型後有1.90 倍的加速聽起來好像很讚吧 ? 但它只是把密集模型從不能用拉到勉強能用，完全填不平活躍參數量造成的鴻溝，人家 Qwen3.6-35B-A3B 每次計算只要跑 3B，當然會比較快哪。在這台機器上，如果你要的是互動速度，稀疏 MoE 仍然是壓倒性的選擇。
Prefill 能力這次的測試更直白，同一個 12,001 token 的測試，Qwen3.8-27B 要跑 21.41 秒，但是 Qwen3.6-35B-A3B 只要 4.34 秒，等於慢五倍。Prefill 的特性本來就是計算受限，稀疏度的優勢無處可躲。
換成 NVFP4 更快，但加速倍率縮水
接著補測 vLLM recipe 指名的低延遲選項，我們採用了Inferact/Qwen3.8-27B-NVFP4（4-bit、26.4 GB，
第三方量化，非官方），它除了模型目錄與埠號，所有旗標與 FP8 那組是相同，測試成績如下：
| 設定 | FP8（29 GB） | NVFP4（26.4 GB） | 差 |
|---|---|---|---|
| 無 MTP | 8.08 tok/s | 9.73 | +20.4% |
| MTP n=1 | 12.60 | 14.43 | +14.5% |
| MTP n=2 | 14.92 | 16.89 | +13.2% |
| MTP n=3 | 15.32 | 15.56 | +1.6% |
| 各自最佳 | 15.32（n=3） | 16.89（n=2） | +10.2% |
NVFP4 每個設定都比較快。但加速倍率反而掉了，我們上一輪用 FP8 規格的模型去測試，最高 1.90×，NVFP4 只有 1.74×，而且 n=3 會倒退。
原因還是我們上面提到的那一欄「每步成本」，NVFP4 一路比 FP8 高（n=1 是 1.19× 對 1.14×）。權重從 8-bit 壓到 4-bit，讀取更便宜，於是多驗證一個 token 要多算的計算，它在測試中呈現的比例就會更大。這是前面那個機制的小尺度重演，量化把模型往「權重讀取便宜、計算相對貴」的方向推，也就是往 A3B 那一端推，投機解碼的相對紅利就跟著縮水，因此絕對速度和加速倍率剛好是天秤的兩邊。
n=3 倒退還有第二個原因，NVFP4 在第三個位置的接受率只有 50.9%（FP8 是 58.4%），但 n=1 時兩者接受率幾乎相同。4-bit 的 draft head 草稿模型猜第一個 token 一樣準，往後延伸才開始失準。
社群配方：哪幾條是真的
剛好社群傳一套「GB10 專用最佳化配方」，說法是照做就能讓 3.8 反超 3.6，批次吞吐衝到 110+ t/s。CyberQ 時測候，該配方的出處是真的，也就是從 MiaAI-Lab/Qwen3.8-27B-DGX-Spark-RTX-6000 這裡來的，它是專為 DGX Spark 寫的 vLLM Docker 腳本。四項設定逐條都能夠用上，包括 NVFP4 checkpoint、FP8 KV cache、MTP num_speculative_tokens: 2、YaRN factor 4.0 推到 1M context。
但那個 repo 裡一個 tok/s 數字都沒有，沒有吞吐量測、沒有與 3.6 的比較。所以我們把配方修改成 compose 檔實測了一遍。它用的 checkpoint 是unsloth/Qwen3.8-27B-NVFP4（23.4 GB），雖然模型的名字叫 NVFP4，實際是混合精度，包括了attention 投影、linear-attn 投影、lm_head 與最後 8 層 MLP 都是 FP8，只有其餘 MLP 是 4-bit，平均 6.5 bits/param。
| 無投機 | MTP n=2 | |
|---|---|---|
| 吞吐 | 11.18 tok/s | 19.95（1.78×） |
| KV cache | 2,472,049 | 2,281,004 |
這是本次測試中三種 checkpoint 裡最快的，19.95 對 Inferact NVFP4 的 16.89、官方 FP8 的 15.32，這幾條重點中 :
✅ FP8 KV cache 有效，而且是關鍵。 checkpoint 自帶校準過的 kv_cache_scheme，vLLM 自動套用，不用旗標。KV cache 拿到 2,281,004 token，是 Inferact NVFP4 的 2.4 倍。
✅ 1M context 是真的。 可用 KV 記憶體 75.43 GiB，日誌中有寫Maximum concurrency for 1,000,000 tokens per request: 2.28x，單條 1M 序列約 33 GiB，與他們 README 的「~32GB」吻合。
❌ --attention-backend triton_attn 沒生效。 日誌是Using FLASHINFER attention backend out of potential backends: ['FLASHINFER', 'TRITON_ATTN']，但 FP8 KV cache 照樣套用了。「GB10 上 FP8 KV cache 需要 triton_attn」這一條在 vLLM 0.26.1rc1 不成立。
❌ 「反超 3.6」不成立。 19.95 對 52.85，差距仍是 2.6 倍。
⚠ 「110+ t/s」要看你改了什麼。
最後這條值得單獨列表幫大家說明，這個測試中的批次總吞吐，每請求 400 token：
| 併發 | max-num-seqs 4（配方原值） | max-num-seqs 32 |
|---|---|---|
| 4 | 68.17 t/s | 69.28 t/s |
| 8 | 73.11（超上限，排隊） | 129.17 |
| 16 | — | 181.31 |
| 32 | — | 318.99 |
GB10 當然衝得到 110+，甚至能到 319。但用配方自己寫死的 max-num-seqs 4 衝不到，天花板的測試成績約能跑到 69–73 t/s。那個數字要成立，得先改掉配方裡的併發上限，而且單請求延遲會一路惡化，併發 32 時每請求只剩 10.42 tok/s，實務上會不好用。
Muse-Glimmer-30B：一個看起來太好的數字
既然要比，就把 CyberQ 最近測試過的另一款同級密集模型也拉進同一套量測，正是 Meta 剛釋出不久的 Muse-Glimmer-30B NVFP4，
它用的是獨立 draft 模型的 dflash 投機解碼，一次提 15 個 token，以下請看 CyberQ 測試的對照。
| 無投機 | 最佳投機 | 加速 | 接受率 | |
|---|---|---|---|---|
| Muse-Glimmer-30B | 12.57 tok/s | 123.41 | 9.82× | 93.1% |
| Qwen3.8-27B（配方） | 11.18 | 19.95 | 1.78× | 64.5% |
兩款模型都是密集、尺寸相近，無投機基準也幾乎一樣（12.57 對 11.18），差距完全來自投機解碼，高達 9.82 倍，接受率 93.1%，看起來 Glimmer 完勝，對吧? 真的是這樣嗎? 這個數字好到讓人不安，所以我們多做了一件事。
這些加速有多少能留下來呢 ?
如果都是貪婪解碼（temperature 0），這是投機解碼最有利的條件，draft 提的 token 只要和主模型的 argmax 一致就被接受，所以跑出來的數字才會高。但實務上，真實使用的場景不是這樣滴，Qwen 官方建議的思考模式取樣參數是 temperature 1.0, top_p 0.95, top_k 20。
所以測試同一套協定，只改取樣參數會變成這樣：
| 貪婪 | temperature 1.0 | 留存 | |
|---|---|---|---|
| Qwen3.8-27B，無投機（對照組） | 11.18 | 11.16 | 100% |
| Qwen3.8-27B，MTP n=2 | 19.88 | 18.36 | 92.4% |
| Muse-Glimmer-30B，dflash n=15 | 123.37 | 18.77 | 15.2% |
第一列是必要的對照：取樣本身不花錢（11.18 對 11.16），所以底下兩列的落差全部來自投機解碼。
CyberQ 觀察，Qwen 的 MTP 幾乎撐得住（−7.6%），但是呢，Glimmer 的 dflash 就垮掉了（−84.8%）。
於是那個 Glimmer 快 6.2 倍的成績，在真實取樣下變成幾乎打平，變成 18.36 對 18.77。
為什麼同樣是投機解碼，一個撐得住一個垮掉？我們沒有量到兩者在取樣下的接受率，只量了速度，所以下面是從設定推的，不是實測：Glimmer 用獨立的 draft 模型，一次提 15 個 token；Qwen 用內建的單層 MTP head，一次只提 2 個。草稿愈深，接受長度隨每 token 接受率的衰減就愈猛——貪婪解碼下 93.1% 的接受率撐得起 15 個，一旦主模型改成從分布抽樣，同樣的深度就撐不住了。這不見得是 Glimmer 的實作有問題，比較像是深草稿這個設計本身押錯了工作條件。
ds4 的 DSpark 則是同一件事的極端版本，而且我們這次是直接量到的：在 DeepSeek 官方的代理評測設定（temperature 1.0、top_p 0.95）下，伺服器的逐輪日誌一行 spec enter 都沒有，不是接受率低，是根本沒被觸發。順帶更正上一篇，那時我們寫「思考模式會強制忽略取樣參數，讓貪婪路徑意外生效」，那是錯的，來源是一行過期的 –help 說明。實際上思考模式對取樣參數沒有任何作用，DSpark 在取樣下就是不提案。
方法論的問題就在於，投機解碼加速的數字，必須連取樣設定一起報。只報貪婪解碼的倍率，等於在報一個多數人不會遇到的上限。這篇前面每一個加速倍率都是貪婪數字，其中只有 MTP 那一組大致能帶進真實工作負載。
至於最終的實務結論，反而變得很簡單：在 NVIDIA GB10 這台機器上，Qwen3.8-27B 與 Muse-Glimmer-30B 的互動速度都落在 18 tok/s 出頭。而 Qwen3.6-35B-A3B 光是不開投機就有 52.85 tok/s，這個數字是貪婪量的，我們沒有直接量它的取樣版本，但它本來就沒開投機，而無投機那組實測取樣不花錢，所以取樣下應該落在同一個數量級。如果是單純看速度，稀疏 MoE 依然壓倒性領先。
官方 benchmark 怎麼說
以上全是我們自己量的速度。能力方面我們本次沒有測，這裡只轉述官方模型卡自行發布的數字，請先都當成廠商說法看待：
| Qwen3.8-27B | Qwen3.6-27B | Muse Glimmer-30B | |
|---|---|---|---|
| Terminal Bench 2.1 | 73.0 | 63.4 | 51.7 |
| SWE-bench Pro | 61.7 | 53.5 | 51.2 |
| CoWorkBench（長時程） | 70.7 | 61.0 | — |
| OSWorld-Verified（電腦操作） | 84.3 | 63.9 | 65.9 |
| IFBench（指令遵循） | 79.5 | 69.1 | 77.0 |
兩邊都不是我們量的，所以只記下來給各位當參考。畢竟速度可以在一台機器上量到 0.1% 的重現性，但是能力不行。
給想在同級機器上跑的人
CyberQ 建議，如果想在 GB10 跑好 Qwen 3.8-27B ，最快的組合是 MiaAI-Lab 那套，unsloth/Qwen3.8-27B-NVFP4 + 自動 FP8 KV cache，MTP n=2，19.95 tok/s。次之是 Inferact NVFP4（16.89），官方 FP8 最慢（15.32）。
最佳 n 值會隨 checkpoint 改變，官方 FP8 是 3，兩個 NVFP4 都是 2，n=3 在 NVFP4 上會倒退。換權重就要重調。
GB10（sm_121）上 VLLM_USE_DEEP_GEMM 與 VLLM_MOE_USE_DEEP_GEMM 兩個都要關（官方 FP8 那套），否則權重後處理階段會崩在 layout transform。unsloth 這款模型走 compressed-tensors 路徑，不受影響。
要 1M context 就得用帶 kv_cache_scheme 的 checkpoint。沒有 FP8 KV cache 的話，NVFP4 在 gpu-util 0.80 下只有 946,176 個 KV token，連一條 1M 序列都放不下喔。
批次吞吐要自己調 max-num-seqs。配方預設 4，那是為長 context 留的，不是吞吐設定。
啟動 6～9 分鐘，開投機解碼再多一到兩分鐘。
兩個 repo 的 checksum 清單都不能用，官方 FP8 的 crc32.txt 有三筆過期，Inferact NVFP4 的 crc32.txt 根本是從官方 repo
整份複製的、列的檔名這裡不存在，兩者的 safetensors-md5sum.txt 都是 0 位元組空檔。
這幾款模型各自適合做什麼，以及誰適合當代理人
跑完這一輪，這三款較小模型的分工其實已經很清楚。它們都比不上雲端尖端模型或更大參數的地端模型 (如 CyberQ 目前使用的 DS4)，但在 GB10 這個量級的機器上，各有各的位置。
Qwen3.6-35B-A3B 適合互動與高吞吐場景
52.85 tok/s 的無投機速度加上 4.34 秒的 12K prefill，讓它成為聊天助理、文件問答、RAG 檢索摘要這類「人在等回覆」的工作首選。批次翻譯、批次摘要這種吞吐導向的任務它也占優勢，因為每個 token 只算 3B 參數的本質不會變。
Qwen3.8-27B 適合長時程的代理任務
它的互動速度只有 18 tok/s 出頭，prefill 慢五倍，單看速度確實比不上 Qwen 3.6。但官方模型卡的 Terminal Bench 2.1（73.0 對 3.6 的 63.4）、SWE-bench Pro（61.7 對 53.5）、OSWorld（84.3 對 63.9）都明顯領先，這些正好都是代理工作負載吃重的能力。加上原生 262K、可推到 1M 的 context 與原生視覺能力，它是三款模型中，唯一為「放著讓它自己跑」設計的模型。前提是這些官方測試成績待各方獨立驗證，但以實際使用的體感上，CyberQ 認為這款是最適合當邊緣裝置上 AI 代理人的模型了。
Muse-Glimmer-30B 目前找不到明確的位置
Meta 這款模型剛出來後，等於是被 Qwen 3.8-27B 壓著打，真實取樣下的速度與 Qwen3.8-27B 打平，官方模型卡上的代理向 benchmark（SWE-bench Pro 51.2、Terminal Bench 51.7）又是三款裡最弱的，IFBench 79.5 對 77.0 的指令遵循差距也不大。除非你的工作負載能全程貪婪解碼（例如固定格式的結構化抽取），否則它的 9.82 倍加速用不到。
DeepSeek V4 Flash 0731 才是這台機器上的代理主力
前面的比較，少算了這款我們日常在用的地端模型。DeepSeek-V4-Flash-0731 是 284B 總參數、每 token 活躍 13B 的稀疏 MoE，原生 1M context。官方公布的代理向數字相當優秀，Terminal Bench 2.1 拿到 82.7，把 Qwen3.8-27B 的 73.0 又拉開一截，照例這是廠商數字，待第三方驗證。更重要的是它在 GB10 上是適合用之外，我們在這篇 DeepSeek Harness 的實戰中，用 ds4-server 跑 IQ2_XXS 量化版，兩輪 agentic 任務全數一次通過、零工具錯誤，115 行套件的多檔案重構 244 秒完成，9 個測試全過。
它適合的任務就是本文推薦給 Qwen3.8-27B 的那一類，長時程程式碼代理、repo 級重構、背景批次自動化。有效產出速度約 13.7 tok/s（含每步 prefill），較適合背景執行的批次任務，不適合極度要求即時回應的互動場景，這個定位和密集 27B 一模一樣，但其 AI 代理能力的天花板更高，就比較接近真的實用那種。
搭配 Hermes Agent 或 OpenClaw，該選哪個模型好呢?
先講框架本身的限制，因為這直接決定模型怎麼選。OpenClaw 的 context 硬性門檻是 65K，光系統提示就約 17K token，而且工具呼叫是不可妥協的需求，模型必須能接收 function schema、判斷何時呼叫、產出格式正確的 JSON，許多小模型在這一關就持續失敗。CyberQ 認為，在龍蝦上，這至少從 14B 到 32B 起跳，32B 以上才比較可靠。
至於 Hermes Agent 這邊，官方文件同樣設有 64K 的最低 context 要求，它的特點是供應商中立且跨 session 保有持久記憶，解過一次的問題會存成可重用的技能。值得一提的是 NVIDIA 已在 build.nvidia.com 上發布 DGX Spark 跑 Hermes Agent 的官方部署指南，代表這條路線在 GB10 上是被驗證過的，CyberQ 也實際用愛馬仕代理人這樣有數個月的時間了。
在這個前提下，CyberQ 的建議如下 :
搭配 Hermes Agent 與 OpenClaw，GB 10 現階段最佳答案肯定是 DeepSeek-V4-Flash-0731 的，而且有幾個實測背書的理由。第一，工具呼叫穩定度已經在極度壓縮的量化下驗證過，IQ2_XXS 之下 JSON 格式保持完整無破損，這正是 OpenClaw 這類框架最挑剔的地方。第二，端點相容性好，ds4-server 同時提供 OpenAI、Responses 與 Anthropic 三種協定端點，supported_parameters 涵蓋 tools、tool_choice 與 reasoning_effort，Hermes 與 OpenClaw 都吃 OpenAI 相容端點，接上去就可以用不需要煩惱。第三，快取讀取量達實際輸入的 11 倍，代理迴圈每一步重用系統提示與歷史的效益直接反映在總耗時上，OpenClaw 那個 17K 的系統提示在這種快取行為下不再是懲罰。
CyberQ 經過測試後，有一個實務提醒，跑代理工作負載時投機解碼直接關閉，理由如前述我們在 Harness 一文的量測。另一個事項是 IQ2_XXS 在更複雜任務上相對全精度權重的能力折損，官方 benchmark 都是全精度數字，不能直接套在 2-bit 量化版上，都是要打折扣，但體感上還是比 Qwen3.8-27B 聰明。
在沒有辦法用 DeepSeek-V4-Flash-0731 的情況下，用比較小 VRAM 的設備，選擇就會變成如下這樣 :
代理人首選 Qwen3.8-27B，用 MiaAI-Lab 那套配置。 理由有三個。第一，代理任務的瓶頸在工具呼叫的正確率與長對話的穩定度，跑錯一步重來的成本遠高於每秒少幾個 token，而 3.8 的代理向 benchmark 全面領先。
第二，代理框架的系統提示動輒上萬 token，帶 FP8 KV cache 的 checkpoint 拿到 228 萬 KV token 的空間，開啟 vLLM prefix caching 後系統提示只需 prefill 一次，後續輪次可重用，能緩解它 prefill 慢的弱點。
第三，本文實測 MTP 在真實取樣下留存 92.4% 的加速，代理任務通常按官方建議的取樣參數跑，這個留存率直接適用。另外要注意Qwen3 系列思考模型搭配 OpenClaw 時需關閉 reasoning 模式，否則工具呼叫會無聲失敗，這是目前該框架追蹤中的首要故障原因。
如果任務簡單、追求迭代速度，選 Qwen3.6-35B-A3B。 個人開發者拿代理人做單步驟工作，例如查資料後摘要、改一個檔案、跑一段腳本，3.6 的 52.85 tok/s 能讓等待時間縮到三分之一。它的取捨是複雜多步驟任務的成功率，官方數字上它全面落後 3.8，長時程任務跑一半迷航的機率較高，所以這部分比較不推薦，不能只想著快就好。
Muse-Glimmer-30B 相較之下不建議用於代理場景。 速度優勢在取樣下蒸發，代理向能力又墊底，找不到選它的理由。
四款模型的最低可跑設備
以下依權重檔大小加上 KV cache 需求分項列出。
| 模型 | 已驗證環境 | 最低可跑設備 |
|---|---|---|
| Qwen3.6-35B-A3B | GB10 單機 | Q4 量化約 20 GB，24 GB VRAM 的 RTX 3090 或 4090 可跑，活躍參數僅 3B，32 GB 統一記憶體的 Mac 混合推論也有堪用速度 |
| Qwen3.8-27B | GB10 單機，NVFP4 23.4 至 26.4 GB | GGUF Q4 約 16 GB，24 GB VRAM 可跑但 context 空間有限），要 1M context 就需要 GB10 這種量級的記憶體加 FP8 KV cache |
| Muse-Glimmer-30B | GB10 單機 | 密集 30B，Q4 約 18 GB，24 GB VRAM 可跑，dflash 的獨立 draft 模型要額外吃記憶體 |
| DeepSeek V4 Flash 0731 | GB10 單機，IQ2_XXS 權重 80.76 GB | 實際可用門檻就是 128 GB 統一記憶體這一級，扣除權重後每個併發 session 還要 4.81 GB，96 GB 以下的設備要更激進的量化，品質折損待查。想跑更高位元的版本，LM Studio 標示最小需 156 GB RAM，等於雙 GB10 或 512 GB 級工作站起跳 |
128 GB 統一記憶體這一級的機器，代理主力直接上 V4 Flash 0731 IQ2_XXS 配 Hermes Agent 或 OpenClaw，這是我們自己正在跑的組合。Qwen3.8-27B 的位置變成 32 GB 上下設備的最佳代理選擇，以及需要原生視覺能力時的替代方案。Qwen3.6-35B-A3B 依然是互動服務的首選，速度快。
CyberQ 對小型企業的實務建議是，如果沒辦法跑 V4 Flash 0731 的，把兩款 Qwen 都留在 NAS 的模型庫裡按場景切換。客服問答、內部知識庫這類同仁在線上等回覆的服務可以跑 3.6-35B-A3B。然後，夜間排程的自動化工作流，例如日誌分析、報表產出、程式碼審查，交給 3.8-27B 配 Hermes Agent 或 OpenClaw 慢慢跑。
CyberQ 提醒大家，AI 代理人不怕慢，怕的是做錯，而互動服務則剛好相反，怕慢。最後講一下安全面的事，能執行指令、可從 Telegram 等訊息平台觸達的代理人屬於中等風險，若略過允許使用者 ID 的限制或把模型端點暴露到 localhost 之外，風險會再上升，這在 MSP 環境部署前，請務必記得要列入管控清單。
所有測試成績均於 2026-08-15，DGX Spark（GB10，128 GB 統一記憶體）完成，推論引擎採用 vLLM 0.26.1rc1
（同一個映像），單請求、ignore_eos 固定 800 token、暖機後取三次中位數。
除本文最後段落標示者外，其餘上半部皆為貪婪解碼。
