1. 硬體與軟體

2. 生產啟動參數

以下從運行中進程的 /proc/<pid>/cmdline 直接抓，不是我貼的範例：

ninfer-serve <model>/qwen3_8_27b_nvfp4.ninfer \
  --host 0.0.0.0 --port 12435 --device 0 \
  --max-context 262144 --kv-dtype nvfp4 --kv-capacity 334000 \
  --max-concurrency 3 --prefill-chunk 1024 --pending-timeout-ms 600000 \
  --spec dflash2 --draft-tokens 8 --lm-head-draft \
  --vision --media-cache-mib 256 --media-live-mib 512

重點說明：

• --spec dflash2 --draft-tokens 8 --lm-head-draft：DFlash2 是 NInfer 的投機解碼模式，每輪猜 8 個 token，draft head 用 lm-head-draft（不單獨載 draft 模型）。Qwen3.8-27B 的 DFlash2 draft 權重內嵌在 artifact 裡，不用另載。
• --kv-dtype nvfp4：KV cache 走 NVFP4，同 8GiB 空間能放 1.83× 的 token 容量（262144 pool 下實測 277,696 tok，int8 是 151,424 tok）。
• --max-concurrency 3：agent 多路並發配置。單流 decode 極限測試（§3.1）則用 C=1 + int8 KV + 131072 的輕配置。
• 啟動方式用 systemd --user unit，不要用一般終端機 background（原因見 §4.5）。

3. 實測數據（server log 為準）

以下全部取自 ninfer-serve 自己的 per-request log 行（decode XXX tok/s | dflash2 accepted A/B (P%)），不是 client 端量測（client 端 SSE 計數會低估 ~4.5×，見 §4.1）。每組 3 跑取中位，同 GPU 前後腳。

3.1 單流 decode 極限（C=1，int8 KV，131072，draft-7）

長推理 2500-token prompt（AIME 風格，temperature=0）：

• DFlash2 vs 同 binary 同 artifact 的 MTP3 = +34%（純 spec 模式差異，同卡同配置）。
• 對照官方 issue #188 公佈的 NVFP4 數字（AIME 321±16 / Code 265±22 / Structured 357±41 等，區間 224–357），本機 271.7 落在區間內，無灌水。
• DFlash2 贏在每輪 draft 7 token（MTP3 是 3）——acceptance 反而更低（50% vs 72%），但每輪產出更多，淨速度更高。

3.2 並發配置（C=3，int8 KV，131072，draft-7）

同一 GPU、同一 binary、同一 artifact，C=3 多路並發配置下換「中文技術說明」prompt（低接受率場景）：

換回高接受率的長推理 prompt（同 C=3 配置，nvfp4 KV / 262144）：

3.3 關鍵結論：acceptance 是 work 相依的

原因：DFlash2「每輪賭 7–8 個 token」的優勢需要高 acceptance 才兌現。長推理 acceptance ~40–50% 時，長 draft 攤平、贏；中文技術說明 acceptance 掉到 ~20% 時，賭大的成本（DFlash2 的 draft 比 MTP 重，KV pool 也小一半——151k vs 246k token）抵消優勢，MTP 的輕 draft（acceptance 57%）打平甚至略勝。

一句話：work 以長推理 / code 為主 → DFlash2；以中文對話為主 → MTP 更省且速度不輸。 別拿單一 work 流派的 benchmark 決定換哪個。

4. 踩過的坑

4.1 client 端計數低估 ~4.5×（最重要）

用 SSE streaming 的 Python client 數 token：同一支 DFlash2 請求，client 看到 ~60 tok/s，server log 實為 271.7 tok/s。engine 提交的 token 數 > client SSE parser 抓到的（reasoning token、batched deltas）。比 decode 一律讀 server log 的 per-request 行，口徑不一樣的話引用時註明。

4.2 DFlash2 必須用新 artifact

舊的 20GB artifact 不含 DFlash2 companion weights，啟用 --spec dflash2 會失敗。DFlash2 版是 21.5GB 的新 artifact（上游官方發布，SHA256 552c374c…0d462c 可對照 manifest 驗證）。換 spec 模式前先確認 artifact 版本，這是我廢掉一次 dry-run 的原因。

4.3 本地編譯的兩個坑

• CUDA 版本：/usr/local/cuda 預設是 12.0，不認 sm_120a（5090 Blackwell）。NInfer 的 CMakeLists 硬性要求 CMAKE_CUDA_ARCHITECTURES=120a，要用 CUDA 13.1。
• 編譯 OOM：-j$(nproc) 全速並編會吃掉記憶體頂峰，cicc 預處理步驟被 SIGKILL（318 個物件編到 258 就死）。改 -j4 增量補編，幾分鐘收工。

4.4 long-context 穩定性：社群 fork 的 causal_small_t 修正

上游 master 有一個 shared-memory 溢出 bug：大 window（>8198 token）+ decode 時 causal_small_t kernel 的 page 數算錯，寫出 __shared__ 邊界 → GPU Xid 13 / cudaErrorLaunchFailure，跑幾小時後隨機觸發。社群 fork（Doelfke/ninfer-yarn @ 7a876cf）的修正（加 page-safety floor）編進本地 binary 後，長 context 長時間跑不再觸發。長 context 重度使用的話，建議用含此修正的 build。

4.5 不要用終端機 background 拉 server

Hermes agent 的 terminal background 會把 process 包在帶 memcg cap 的 cgroup 裡；NInfer 啟動時要 pin ~8–9GB host KV，超過 cap 直接 OOM（log 停在 host-kv-pin status=begin，dmesg 顯示 CONSTRAINT_MEMCG，但 host 記憶體其實沒吃緊）。用 systemd --user unit 起就解決。

5. 跟 llama.cpp 路線的對照（同一台機）

差距的來源不是「誰更強」，是引擎架構：NInfer 是專為單卡 + CUDA Graphs + paged KV 設計的自研引擎，單卡 decode 的極限遠高於走跨卡 all-reduce 的 tensor split；但雙卡 llama.cpp 能容納更大的模型（BF16 全精度 54.6GB 單卡放不下）。27B 放得進單張 5090 的話，單卡 NInfer 是 decode 最快的路。

6. 參數建議（單卡 5090 + NInfer + Qwen3.8-27B）

# 高接受率 work（長推理 / code / agent）
--spec dflash2 --draft-tokens 8 --lm-head-draft
--kv-dtype nvfp4 --max-context 262144 --kv-capacity 334000 --max-concurrency 3

# 中文對話為主 / 要更大 KV pool
--spec mtp --draft-tokens 3
# （MTP 的 KV pool 是 DFlash2 的 ~1.6×，同空間撐更長 context / 更高並發）

# 通用
# - 本地編譯用 CUDA 13.1 + sm_120a + -j4（§4.3）
# - server 用 systemd --user 起（§4.5）
# - 長 context 重度使用 → 用含 causal_small_t fork 修正的 build（§4.4）
# - decode 數據讀 server log per-request 行，client 端計數會低估 4.5×（§4.1）

7. 結語

單卡 5090 跑 27B 這條路，重點心得兩句：

1. 投機解碼的勝負是 work 相依的——DFlash2 在長推理大贏 +34%，在低接受率的中文場景反而打平/小負。測 benchmark 時 acceptance 不寫進報告，數字會騙人。
2. 口徑決定一切——client 端 SSE 計數、不同 KV 量化、不同 concurrency 的數字混在一起比，會得出完全錯誤的結論。本篇所有 A/B 都是同 GPU、同 binary、同配置、讀 server log。

數據全部可重現：server 端 per-request log + 啟動參數如上（§2）。有問題歡迎直接問。

附：所有數據以引擎端 log 為準；client 端量測與引擎端計時窗不同，會偏低，引用時請註明口徑。本篇為 1350 系列的單卡 NInfer 路線，硬體/模型/用途與前篇一致，差異集中在引擎與 spec 模式。

技術來源