Qwen3.8-27B 社群實測整理：六種硬體、39 條 X 貼文，跑出來的不是同一種產品

Qwen3.8-27B 放出權重不到 48 小時，X 上就炸開了。

每個人都在跑自己手上的卡，數字從 5 tok/s 到 223 tok/s 都有人喊。問題是——這些數字的量化版本不同、context 不同、runtime 不同、MTP 開關不同、甚至有人功耗被靜默限制在 210W 都不知道。直接拿來排行毫無意義。

我這兩天做的事情比較無聊：把 39 條 X 貼文一條一條拆開，對照硬體、量化、context、引擎版本、MTP 設定，整理成六條部署路線。再加上本站 RTX 5090 用 SGLang、vLLM、llama.cpp 三套引擎跑的實測數字。

最後得到的結論很簡單：

消費級甜蜜點是 24GB NVIDIA GPU + Q4 + MTP + 32K context。不是任何 laptop，不是任何有大記憶體的機器。

先看總表，再往下挑你的硬體。

本文數字初次整理於 2026-08-16，並於 2026-08-17 追蹤補充發布後 24 小時內的新實測。除了文中特別標示的本站 RTX 5090 測試，其餘為 X 使用者自行回報。量化格式、引擎版本、context、thinking、MTP 與 workload 不一致，請把它們當成部署區間，不是同條件排行榜。

總表：六條路線，一張圖

硬體 VRAM／RAM 建議量化 Context 起點 建議 Runtime 單人 Decode（tok/s） 判斷
RTX 3090 24GB 24GB Q4 32K llama.cpp + MTP 25–57；最佳化 stack 宣稱 82 最低成本實用起點
RTX 4090 24GB 24GB Q4 32K llama.cpp + MTP 45–97 消費級甜蜜點
RTX 5090 32GB 32GB Q4／NVFP4 32K–128K llama.cpp 單人；SGLang／vLLM 多人 單人 74–153；本站四人每人 106 高速單機，或四人 server
RTX PRO 6000 96GB NVFP4／FP8 64K–256K vLLM／SGLang 45–223，條件差異大 Production 與長 context
DGX Spark 128GB 統一 NVFP4／Q4 32K SGLang baseline 8–13；調校 22–75 高度依賴 serving stack
Mac 24–36GB 24–36GB Q4 8K–16K MLX／llama.cpp 6–18 可用但不快
Mac 64–128GB 64–128GB Q6／8-bit 32K MLX／llama.cpp 10–27；特製 stack 52+ 安靜與容量

一句購買建議：

  1. 預算敏感，找二手 RTX 3090 24GB。
  2. 想要最成熟的單卡體驗，RTX 4090 24GB。
  3. 要 100 tok/s 級互動與長 context 餘裕，RTX 5090 32GB。
  4. 要長 context、多人 serving 與 96GB VRAM，才看 RTX PRO 6000。
  5. 已經有 Mac 或 DGX Spark，就用現有機器。不要只因統一記憶體很大就購買。

部署之前：三個預算要分開算

最常見的錯誤是只看模型檔案大小。

Q4 GGUF 約 17–18GB，很多人看到 24GB 顯卡就推論「還剩 6GB，262K 沒問題」。但執行時還要放 KV cache、運算 buffer、MTP draft state，若啟用多模態還有 projector，作業系統和桌面也吃 VRAM。

精度 約略大小 適合硬體
BF16 51.76 GiB 64GB 級以上
FP8 28.76 GiB 48GB 較舒服；32GB 很緊
Q6 約 23GB 32GB GPU 或大統一記憶體
Q4 約 17–18GB 24GB GPU 的主力
IQ3／低位元 MLX 約 11–15GB 16–24GB Mac 實驗用

KV cache 決定 context 能開多長。Qwen3.8-27B 的 hybrid architecture（64 層裡只有 16 層 full attention，其餘 48 層 Gated DeltaNet）比純 Transformer 省，但 262K 仍然不是免費的。本站 RTX 5090 32GB 實測：Q4 權重 + Q8 KV，約 67K token 就 OOM；改成 Q4 KV，才完成約 237K token 輸入。

記憶體頻寬決定吐字速度。Dense 27B 每生成一個 token 要把大部分權重讀一遍——未調校的 DGX Spark baseline 約 8–13 tok/s，而 RTX 4090 Q4 + MTP 可以到 86.5。容量解決 fit，頻寬才決定 decode。

Fit ≠ Speed。這是整篇最重要的一行。

RTX 3090 24GB：最低成本實用起點

Q4 權重完整放進 24GB VRAM，二手市場最有性價比。

社群實測：

有趣的一條：一位使用者的 3090 eGPU（OCuLink 外接）被靜默限制在 210W，解除到 300W 後無 MTP 從 19.7 升到 36.1 tok/s、MTP n=2 約 48.9–49.8 tok/s。llama-bench 進入 131K 深度後 decode 約減半。

llama.cpp commit、MTP、功耗限制和 agent harness 已經跟硬體型號同樣重要。

RTX 4090 24GB：單人 Agent 的甜蜜點

單人 coding agent、tool calling、RAG 或低併發 API，4090 是速度與軟體成熟度最平衡的配置。24GB VRAM + 4-bit 是比較實際的單卡條件。

一組完整參數實測用 UD-Q4_K_XL、全層 GPU offload、Flash Attention、MTP：[未開 speculative decoding 約 44.9 tok/s；開 MTP 後 32K context 一般工作負載約 86.5 tok/s，coding 峰值約 97.3 tok/s（8K context、draft KV 改 q80）](https://x.com/outsource/status/2088743329760469374)。

4090 起手式：

1
2
3
4
5
6
7
8
9
10
11
12

llama-server \
  -m Qwen3.8-27B-UD-Q4_K_XL.gguf \
  -ngl 999 \
  -c 32768 \
  -fa on \
  -np 1 \
  --cache-type-k f16 \
  --cache-type-v f16 \
  --spec-type draft-mtp \
  --spec-draft-n-max 4 \
  --host 127.0.0.1 \
  --port 8000

這不是最佳參數，是容易驗證的 baseline。先關 MTP 記錄 decode、TTFT 與 VRAM，再用 draft 2、4 跑同一組 prompt；32K 穩定後才升 64K，VRAM 不足時先量化 KV cache。

RTX 5090 32GB：高速單機，或四人 model server

多出的 8GB 最實用的價值不是更高精度，是 context headroom。

社群數字

Stack Context／條件 Decode
llama.cpp Q4 baseline context 未揭露 約 74 tok/s
llama.cpp Q4 + MTP context 未揭露 約 113 tok/s
Docker llama.cpp + Q4 KV + MTP 131K 約 102 tok/s
vLLM + NVFP4 + MTP 256K、單 session（structural 數字，非實跑） 約 147 tok/s
SGLang + NVFP4 + MTP Triton attention、lm_head NVFP4 約 153 tok/s

同一則貼文下的回覆也提醒，147 tok/s 會隨 workload 與設定變動，應在自己的硬體上重測。

本站實測

我在同一張 32GB 5090 上跑了三套引擎。llama.cpp 偏單人長 context、SGLang 和 vLLM 偏多人 serving。完整過程在這集 YouTube 逐字稿。

llama.cpp Q4 + MTP（單人互動）：

Context Decode
7K–28K 日常 100–126 tok/s
約 237K 長文 49–55 tok/s

context 從日常區間進到 200K 後速度直接掉一半。長 context 是一種 workload，不是一個 checkbox。

128K 以上啟動參數：

1
2
3
4
5
6
7
8
9
10
11
12
13

llama-server \
  -m Qwen3.8-27B-UD-Q4_K_XL.gguf \
  -ngl 999 \
  --ctx-size 131072 \
  --flash-attn on \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --spec-type draft-mtp \
  --spec-draft-p-min 0.75 \
  --spec-draft-n-max 2 \
  --parallel 1 \
  --host 127.0.0.1 \
  --port 8000

SGLang／vLLM + NVFP4（多人 serving）：

同一張 5090 換成 RadixArk/Qwen3.8-27B-NVFP4，用 SGLang（FlashInfer、NEXTN／MTP 2 draft tokens、--disable-radix-cache）和 vLLM 0.27.1（FlashInfer、FP8 KV、32K context、num_speculative_tokens: 2）各跑一輪。

配置 單人 tok/s 四人總吞吐 tok/s 每人 tok/s MTP 接受率
SGLang MTP-2 113.75 425.44（19.3 秒） 106–108 78–91%
SGLang MTP-2、八人 — 303.4（約 54 秒） 實際 3–4 人在跑，其餘排隊 74–94%
vLLM 無 MTP 57.83 210.37 52–53 —
vLLM MTP-1 85.63 305.09 76–80 —
vLLM MTP-2 100.33 351.71 88–94 平均約 69%

三個結論：

  1. 四人是這張卡的甜蜜點。 四人並行每人仍有 106–108 tok/s，跟單人差不到 7%；八人時 KV pool 只剩約 7,703 tokens（四人約 64,079），長輸出時實際只有 3–4 個請求在生成，其餘排隊。32GB 的天花板不是權重，是 KV pool。
  2. MTP 在 serving engine 上一樣是免費午餐。 vLLM 無 MTP 到 MTP-2，單人快 73.5%、四人快 67.2%。
  3. SGLang 目前比 vLLM 快 12–17%。 差距來自 Verified 配置、CUDA Graph 與排程較成熟。vLLM 0.20.2 會撞到 lm_head.input_scale 錯誤，要升到 0.27.1。

兩個誠實的註腳：SGLang 四人測試每人輸出 2,048 tokens，vLLM A/B/C 是 512 tokens，tok/s 只能看趨勢；SGLang 為了把 Mamba state 塞進 32GB 用了 --disable-radix-cache，代價是沒有共享前綴快取。

SGLang 四人啟動參數：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

sglang serve \
  --trust-remote-code \
  --model-path RadixArk/Qwen3.8-27B-NVFP4 \
  --mem-fraction-static 0.98 \
  --attention-backend flashinfer \
  --chunked-prefill-size 2048 \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder \
  --mamba-full-memory-ratio 4.59 \
  --max-running-requests 4 \
  --speculative-algorithm NEXTN \
  --speculative-num-steps 1 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 2 \
  --cuda-graph-max-bs-decode 4 \
  --disable-radix-cache \
  --host 0.0.0.0 \
  --port 30000

vLLM MTP-2：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

vllm serve RadixArk/Qwen3.8-27B-NVFP4 \
  --trust-remote-code \
  --served-model-name Qwen3.8-27B \
  --gpu-memory-utilization 0.95 \
  --max-model-len 32768 \
  --max-num-seqs 4 \
  --max-num-batched-tokens 8192 \
  --attention-backend FLASHINFER \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --speculative-config '{"method":"mtp","num_speculative_tokens":2}' \
  --host 0.0.0.0 \
  --port 30000

同一張 5090 其實是兩種產品：llama.cpp + GGUF Q4 + MTP 是單人長 context 互動機（237K 塞得進去，49–55 tok/s）；SGLang／vLLM + NVFP4 + MTP-2 是四人小團隊 model server（每人 106 tok/s，但 context 被 KV pool 綁在幾萬 tokens）。選哪種，取決於這台機器服務一個人還是四個人。

RTX PRO 6000 96GB：Production 級，但 fast path 還在變

空間充裕，NVFP4 + SGLang + DSpark、256K context、concurrency 8，單 stream 約 200–223 tok/s。但full precision 實測裡 context 從 10K 增至 60K，速度約下降一半，TTFT 明顯升高。容量、單流速度和長 context latency 仍然要分開驗收。

更重要的是 fast path 還在快速變動。一組 500 題 coding suite 測試中，Inferact NVFP4 + vLLM nightly + MTP 得到 478/500、約 45 tok/s decode、5,200 tok/s prefill；同時測到 llama.cpp CUDA GGUF、vLLM FP8 + MTP 和部分 abliterated 權重有嚴重品質問題。單一使用者的早期結果不能直接當引擎定論，但足以提醒：最快的路徑如果沒有跑品質 regression suite，就還不算可用。

DGX Spark：128GB 不等於快

DGX Spark 跑 Qwen3.8-27B 的早期 baseline：llama.cpp + unsloth GGUF，prompt processing 約 837 tok/s、generation 約 11.6 tok/s；跨硬體比較約 12.6 tok/s。

但 8/17 的新結果證明這不是固定上限。七配置比較從 vLLM + NVFP4 的 11.2 tok/s，調到 SGLang cookbook 單流 21.6、10 streams aggregate 158 tok/s；更積極的最佳化宣稱從 stock FP8 的 7.88 拉到單流 75、16 streams aggregate 256 tok/s。較保守的 matched-prompt bake-off 測到 SGLang + EAGLE 單流約 31–32 tok/s，並明確表示沒有復現 161 tok/s 的單流說法。

這個 baseline 值得停下來看一眼：一台定位為 AI 工作站、128GB unified memory 的機器，未調校時跑 27B dense 竟然慢於多年前的 RTX 3090。

原因不是 Spark 差，是 workload 不對。Spark 的大記憶體適合放消費卡塞不下的大 MoE 或高精度模型；Qwen3.8-27B Q4 已經住進 24GB VRAM，這時 NVIDIA 獨顯的高記憶體頻寬才是決定性優勢。

Spark 的 baseline 慢，但 serving stack 調整空間非常大。已經有 Spark 可以部署；要為 Qwen3.8-27B 買硬體，拿真實單流 latency 與多流 aggregate 分開比較，不能只看 128GB，也不能只看調校後的 256 tok/s。

Mac：安靜省電，Dense 27B 就是慢

Apple Silicon 的優點很明確：安靜、省電、統一記憶體大、部署方便。缺點也很明確：Qwen3.8-27B 是 dense model，每個 token 都要讀取大部分權重，decode 吃記憶體頻寬。社群早在發布當天就提醒：unified memory 機器要的是 MoE，dense 模型塞得下但會很慢；也有 Mac 使用者回報 dense 跑不好、MoE 表現好得多，連 MTP 都沒幫上忙。

社群實測：

機器 量化／Runtime Decode
M5 Max 128GB Q6 約 26.6 tok/s
M4 Max 128GB 8-bit MLX／LM Studio 約 14.3 tok/s
M4 Max 36GB Q4、8K 約 17.53 tok/s
M4 Max、MTPLX 最佳化 MTPLX、coding agent 約 52 tok/s
M4 Pro 24GB Mac mini 條件未完整揭露 約 15.1 tok/s
M3 Max 36GB Q6_K 約 9.3 tok/s
M3 Ultra 256GB 條件未完整揭露 約 21 tok/s
M2 Max 96GB BF16 約 13–20 tok/s
M2 Max 96GB Ollama MLX NVFP4 + adaptive MTP、thinking off 約 31.5 tok/s
M1 Max 64GB Q4、128K、llama.cpp 約 10.2 tok/s

按記憶體級距處理：

一組橫跨三台 Mac 與 RTX 3090 的比較：MLX 約比 Ollama 快 1.5 倍，Q3 反而比 Q4 慢 2.7 倍，MTP 增益隨硬體大幅變動。「量化越小一定越快」與「MTP 一定加速」都不能當預設假設。

一個容易誤讀的 outlier：M5 Max Abliterated + MTPLX 特製混合精度版本跑到約 58 tok/s，但只有 4K context，模型與推理配置不是標準 Q6。不能直接代表一般 M5 Max 部署。

Mac 是你每天工作的主機的話，不要把記憶體全部給模型。36GB 機器載入 23GB 的 Q6，理論上放得下，實務上 OS、IDE、瀏覽器和 agent tools 都搶同一池記憶體。本地 AI 的機器不是只有模型在用。

MTP：最值得開，也最容易被誤讀

MTP 讓模型用自己的 prediction head 先草擬多個 token，再由主模型驗證。RTX 4090 社群數字從約 44.9 拉到 86.5 tok/s；RTX 5090 也有約 74 到 113 的回報。本站 vLLM 測試從 57.83 到 100.33，單人快 73.5%。

但 MTP 不是固定 2 倍。最明確的反例來自 M4 Mac mini：Q4_K_M、llama.cpp v10360 的 sweep 中，baseline 5.91 tok/s，最佳 n-max 2／p-min 0.8 只有 6.34；n-max 4／p-min 0.0 反而掉到 3.05。

幾個實際觀察：

  • Coding、boilerplate 等可預測輸出，acceptance 通常較高。
  • 複雜 reasoning、創意文字，接受率可能下降。
  • draft 數越高不一定越快，驗證也有成本。
  • 不同 llama.cpp commit 可能出現效能變化。

部署程序：MTP 關閉跑 20 組真實 prompt → draft 2 同一組 → draft 4 同一組。比較的不是瞬間 tok/s，是整個任務 wall time、acceptance rate、TTFT 與失敗率。

量化驗收：會聊天不代表 agent 會做事

Qwen3.8-27B 的賣點是 agentic workflow。部署驗收要測 agent，不是問「台北有什麼景點」。

保留一套 20–50 題的 golden set，至少包含：正確選擇 5–10 種 tools、必填與選填參數不混淆、嚴格輸出 JSON schema、tool error 後能修正不陷入 loop、20K 以上 context 仍能引用前文、修改程式後會跑測試、thinking on／off 各跑一次、Q4 與更低位元量化做對照。

低位元量化的損失不是平均分配。前代 Qwen3.6-27B 的壓縮測試就出現數學 benchmark 幾乎沒掉、TauBench tool calling 卻從 82.9 掉到 61.3、降幅 26% 的情況。Qwen3.8-27B 的早期 Q4 回報也呈現類似警訊：長程 Agent 與 tool calling 可以很穩，但細節能力仍落後 frontier 模型；跟 GPT-5.6 Luna Max 做相同實作，雖能完成，產出品質仍有明顯差距。

而且部署驗收不能只沿用官方表格。社群指出 Qwen3.8-27B 與 Qwen3.6-27B 的 HF config 完全相同、零變更，卻宣稱 DeepSWE 提升 217%、19 項 benchmark 贏 Opus 4.6 15 項，質疑這是純訓練帶來的真實進步，還是 benchmark 文化出了問題。這不等於模型沒有進步，是提醒：最後採用哪個量化、runtime 和 prompt template，必須用自己的任務復現。

坦白說

這篇的數據全部來自 X 社群自行回報和本站實測，不是同條件 benchmark。每個人的 llama.cpp commit 不同、量化版本不同、context 設定不同、MTP 開關不同、甚至有人功耗限制都沒察覺。sethprattsf 在 RTX PRO 6000 上測到 llama.cpp CUDA GGUF 品質直接崩掉，本站自己的 agent 品質系統性評測也還沒做——前一篇就承認了這一點。

把這些數字當成「部署區間」而不是排行榜。你真正需要的 benchmark 只有一個：你自己的 workload、你自己的 prompt、你自己的品質 golden set。

Runtime 怎麼選

情境 預設選擇 原因
想最快開始聊天 LM Studio／Ollama 安裝方便
單人 coding agent llama.cpp + MTP 單流快、跨平台、參數可控
NVIDIA 多使用者 API vLLM continuous batching、生態成熟
長 context／進階 serving SGLang scheduler、cache 與 serving 最佳化
DGX Spark SGLang 調校空間最大
Apple Silicon MLX 或 llama.cpp 原生 Metal 路線

不要把 GUI、模型格式和 inference engine 混成同一件事。Ollama 是很好的入口，但 production 需要併發排程、p95 latency、metrics 和故障隔離。

選引擎之前先回答：這台機器服務一個人，還是五十個人？

Production 上線前的 12 項檢查

模型與品質

  • 固定模型 repo、檔名、hash 與 license
  • 保存 Q4／IQ3 的 agent golden set 結果
  • 測 thinking on／off 的品質與 token 成本
  • 多模態若要用，確認 projector 與 API path 已實測

效能

  • 分開記錄 prefill 與 decode
  • 記錄 TTFT、TPOT、p50、p95，不只平均 tok/s
  • 用真實 input／output 長度測試
  • 用真實併發數測試，不拿 single-stream 代替 production

容量與穩定性

  • 8K、32K、64K 分段量 VRAM／RAM
  • 保留 10–15% 記憶體 headroom
  • Runtime、driver、CUDA／Metal 更新後自動重跑 benchmark
  • Server 前面放 auth、rate limit、timeout 與 sandbox；地端不等於安全完成

最後的決策樹

你已經有硬體嗎？

  • 有 RTX 3090：Q4 + llama.cpp + MTP + 32K，先檢查 power limit。
  • 有 RTX 4090：同一套起步，單人 coding agent 最均衡。
  • 有 RTX 5090：單人用 llama.cpp Q4 + MTP，32K 日常、128K 改量化 KV 並單獨壓測；給小團隊用就換 SGLang NVFP4 + MTP-2，四人上限，不要貪到八人。
  • 有 RTX PRO 6000：優先測 NVFP4／vLLM／SGLang，品質 regression suite 不能省。
  • 有 Mac：按統一記憶體容量選 Q4／Q6，MLX 與 llama.cpp 都要實測。
  • 有 DGX Spark：從 SGLang cookbook 起步，分開量 single-stream 與 aggregate throughput。

你準備買硬體嗎？

  • 最低成本實用：二手 RTX 3090 24GB；社群也有約 US$2,000 等級整機的入門建議。
  • 低風險高成熟度：RTX 4090 24GB。
  • 高速、長 context、NVFP4：RTX 5090 32GB。
  • 多使用者服務、96GB VRAM：RTX PRO 6000。
  • 已經在 Apple 生態且重視安靜、省電：Mac；不要只看統一記憶體容量。
  • 想跑多種大模型與多流 serving：DGX Spark；不要用 aggregate TPS 代替單人互動速度。

你的需求真的需要 262K 嗎？

  • 不確定：就不需要。從 32K 開始。
  • 只有少數長文件：把長文任務排到獨立 endpoint。
  • 每個 session 都超過 100K：這是 serving architecture 問題，不只是把 --ctx-size 數字改大。

結語

Qwen3.8-27B 最有意思的地方，是它在 RTX 3090／4090 這個 24GB 級距已經跨過「真的可以每天工作」的門檻。

3090 買的是性價比，4090 買的是成熟的單人 Agent 體驗，5090 把日常 context 推到 100 tok/s 以上而且同一張卡能變四人 model server，RTX PRO 6000 解的是 96GB VRAM、長 context 與 production serving。Mac 用安靜、省電和統一記憶體交換 decode 速度；DGX Spark 的價值取決於你能不能把 SGLang 和 speculative decoding 調好。

部署順序不要反過來：

先定 workload，再定 context；先定 context，再定量化；最後才是買硬體和選 runtime。

不要先買一台看起來很像 AI 的機器，再想辦法替它找 workload。

大概是這樣子。24GB NVIDIA 是目前最不容易後悔的答案；32K 是最誠實的 context 起點；Q4 是品質和容量的平衡；MTP 要開，但一定要用自己的 prompt 驗收。

真正的 deployment guideline 不是替六台機器排一張總榜。是知道每條路線在解什麼問題，以及那個交換是否符合你的 workload。

參考資料

官方文件與本站文章