[Benchmark] Qwen3.8-Flash-Next NVFP4 在 DGX Spark 跑 41.7 tok/s：RAM 給流量，硬碟給字典

有些改裝不用進廠。原廠車開回家，九個零件用卡扣裝上去，油門踩下去就是另一台車;哪天不想要了，拆掉就是原廠。這篇講的配方就是這種改法:vLLM 官方 nightly image 一個檔都不改，九個 Python 檔用 docker 的唯讀 bind mount 蓋在容器裡對應的位置，啟動參數帶對，速度從 17 變 41.7。

這是 DGX Spark 系列第 45 篇。第 43 篇把同一個模型的 llama.cpp UD-Q4_K_XL 版塞進 GB10 的 121 GB 統一記憶體，散文 20.51 tok/s，拿到的是「262K context 不用拿任何東西去換」。這篇換 runtime 不換模型:NVIDIA 自己出的 NVFP4 checkpoint，跑在 vLLM 上，速度快了七成多。配方不是我的，是 tonyd2wild 的;我做的事是在自己的機器上把它重跑一遍、把數字對上、把坑記下來。

你會拿到什麼:中位 41.7，散文 27.4，四路並行 47.2

先看「harness 中位」那一列，那是 40 題八個類別合起來的中位數，最接近日常混用的感受。散文那列是所有類別裡最慢的，因為 MTP 猜字在自由文字上接受率最低，第 5 篇在 V4-Flash 上也量到同樣的現象。

量什麼	我的 GX10	作者的 Spark	同機 llama.cpp 席位
40 題 harness 中位(單流)	41.7	43.9	23.38
散文	27.4	29.0	20.51(第 43 篇)
程式	42.0–45.0	44.3	—
四路並行:每流 / 聚合	26.1 / 47.2	26.4 / 47.1	—
32K prefill	1,666 tok/s,TTFT 17.3 s	—	—

單位都是 tok/s。llama.cpp 那格的 23.38 是我們平常探測各台機器用的通用提示詞，不是 harness，所以只能當量級參考;第 43 篇的 76.65 是 n-gram 推測在「改一個檔案」這種重複度高的工作上量到的，那類工作仍是 llama.cpp 比較快，兩邊各有各的擅長題型。

MTP 是 multi-token prediction:模型多長一顆小的「草稿頭」，一次猜好幾個 token，主模型再一口氣驗收。這個 checkpoint 的草稿頭原本在 vLLM 上載入就炸，後面會講;配方修好它之後，一步平均吐出三個多 token，單流速度才從 17 跳到 40 以上。

需要什麼

• 一台 DGX Spark(GB10,128 GB 統一記憶體)。作者與我都是單機 TP1。
• NVMe 空間約 155 GB:nvidia/Qwen3.8-Flash-Next-NVFP4 124 GiB(133 GB),vLLM nightly image 22.2 GB。
• Docker 加 NVIDIA container toolkit，能跑 docker run --gpus all。
• 啟動前系統要有 25 GiB 以上的 MemAvailable。作者的 README 說每次啟動前都要 drop_caches,launcher 裡已經包了;我實測載入期間 MemAvailable 最低 25.6 GiB,32K prefill 時最低 12.9 GiB。
• 冷啟動 13 分鐘的耐心。權重 585.81 秒，MTP 草稿頭再 69.16 秒。

PLE 是 per-layer embedding:這個模型約 180B 參數(125B 主體、51B PLE、4B MTP)裡有 51B 是一張 n-gram 查表，每個 token 只讀幾列，不是拿來乘的矩陣。配方預設 PLE_MODE=staged，表留在 NVMe，每個 forward 前先把要用的列撈進來，所以記憶體只裝剩下的 76.48 GiB。

照這個順序做

# 1. 拿配方
git clone https://github.com/tonyd2wild/Qwen3.8-Flash-Next-NVFP4-DGX-Spark ~/src/tonyd2wild-nvfp4
cd ~/src/tonyd2wild-nvfp4 && git log -1 --format='%h %ad' --date=short
# 我跑的是 d83f10c 2026-09-05

# 2. 拿 checkpoint(124 GiB / 133 GB)
hf download nvidia/Qwen3.8-Flash-Next-NVFP4 --local-dir /home/coolthor/models/qwen38-fn-nvfp4-nvidia

# 3. 拿固定 hash 的 nightly image(22.2 GB)
docker pull vllm/vllm-openai:nightly-8a728663c1c3eeace834a95f5654fa653cc1998c

# 4. overlay 檔與 launcher 放到 launcher 預期的位置
mkdir -p ~/patches && cp -r single-spark-vllm-tp1/patch ~/patches/qwen4exp-ple-mmap   # launcher 的 PATCH_DIR 預設值就是這個目錄名
cp single-spark-vllm-tp1/launch/qwen38fn-nvidia-tp1.sh ~/patches/

# 5. 起
PORT=8000 NAME=qwen38fn bash ~/patches/qwen38fn-nvidia-tp1.sh
docker logs -f qwen38fn 2>&1 | grep -m1 'Application startup complete'   # 約 13 分鐘

launcher 的預設值就是作者 2026-09-05 的單機最佳解，不用帶任何環境變數:PLE 表放硬碟用 staged gather、解碼用 CUDA graph 但不走 torch.compile、MTP 三個 token、草稿頭只在 id 最小的 65,536 個 token 裡猜(BPE 合併順序大致就是詞頻順序)、六路並行、prefill 一次 4,096 token、KV cache FP8、記憶體佔用上限 0.80、context 262,144、思考模式預設關。overlay 一共九個檔:四個是作者自己的 PLE / MTP 實作，四個是上游 PR 的原始碼直接蓋上去(PR #55375 的 PLE conv 步幅修正、PR #54846 的 QSA 路徑 FP8 KV)，最後一個 modelopt.py 是上游檔加作者自己的兩處修正，讓 MTP 草稿頭找得到自己的量化設定;作者註明 sfxnz 與 MiaAI-Lab 同一天各自獨立修了同樣的洞。完整展開的 docker run 命令在文末進階節。

起來之後做一次 smoke test:

curl -s http://<your-gx10-ip>:8000/v1/chat/completions -H 'content-type: application/json' -d '{
  "model": "qwen38-flash-next",
  "messages": [{"role":"user","content":"用三句話解釋什麼是 speculative decoding"}],
  "max_tokens": 200, "temperature": 0,
  "stream": true, "stream_options": {"include_usage": true}
}'

四個坑

串流模式拿不到 usage。 vLLM 的串流回應預設不帶 token 計數，要在請求裡加 stream_options: {"include_usage": true};llama-server 串流會自動附，所以從那邊搬過來的量測腳本第一次跑會算不出 tok/s。

vLLM 會檢查 model 名字，llama-server 不會。 換席位當晚我在容器 log 看到一串 404，來源是我自己筆電上兩支半年沒動的腳本，它們還在送舊模型的 id。llama-server 不管你送什麼名字都照答，所以那個錯誤藏了兩個月。換 runtime 前先把所有客戶端送的 model 名掃一遍。

--network host 直接佔 8000。 跟既有席位互斥，起新的之前先停舊的;我這次停機 33 分鐘(含 13 分鐘載入與全部驗收)。

prefix caching 刻意關著。 launcher 預設 --no-enable-prefix-caching，作者註明是因為 GDN 層開 prefix cache 會炸(他引 vLLM issue #54173，自己沒驗)。我也沒開，所以上面的數字都是無 prefix cache 的。

進階:這個模型長什麼樣，為什麼一台 Spark 跑得到 41

不讀這節不影響使用。這節講三件事:這個模型的結構、47.68 GiB 的查表為什麼放硬碟反而是對的、17 到 41.7 那 2.5 倍是從哪裡來的。六張圖裡我的數字全來自這台 GX10，作者的數字都標了作者。

一個 token 走過的路

Qwen3.8-Flash-Next 約 180B 參數，分三塊:125B 主體、51.2B n-gram 表、4B MTP 草稿頭。從 GGUF 檔頭讀出來的結構是這樣:

• 主幹 48 層，每 4 層一組:3 層 Gated DeltaNet 線性注意力，1 層全注意力。線性注意力層不存 KV，每層維持一個固定大小的狀態;全注意力層才存 KV，而且帶 DeepSeek 式的 sparse indexer，每個 query 只看 top-k 2,048 個位置。48 層裡只有 12 層要存 KV，這是 262,144 的上下文只吃 17 GiB 的第一個原因。
• 每層一個 MoE:512 個 expert，每個只有 640 寬，每個 token 由 router 選 10 個再加 1 個共享 expert。expert 參數合計 121B，每個 token 路由到的 10 個是 2.36B，加上共享 expert 是 2.60B。
• n-gram 表(PLE，per-layer embedding):只掛在主幹靠近輸入端的一層上(HF config 寫 ple_layer_ids=[2]，GGUF 檔頭寫 ple.layers=[1])，一個 token 只查一次。上下文最後 2 個 token 與最後 3 個 token 各做 8 種 hash，對應 8 張 bigram 表與 8 張 trigram 表，每張各兩千萬列，各取一列 160 維，拼起來接進那一層。16 列乘 160 B，一個 token 讀 2,560 B。這 51.2B 參數從頭到尾沒進過任何矩陣乘法。
• MTP 草稿頭:約 4B，一次猜 3 個 token，而且只在 65,536 個高頻 id 裡猜(FR-Spec 的做法，作者註明這個 65,536 詞表是 MiaAI-Lab 在這個模型上示範過的)。

RAM 給流量，硬碟給字典

這台機器 MemTotal 是 121.6 GiB，CPU 與 GPU 共用。載入之後常駐在記憶體裡的權重是 76.48 GiB(NVFP4 主體加 MTP 頭)，FP8 的 n-gram 表是 47.68 GiB，兩個加起來 124.16 GiB，還沒算 KV cache 與作業系統就超過了。所以表放硬碟首先是塞得下的問題。

但分配的邏輯不只是塞得下。看每個 token 的流量:主體那 76.48 GiB 每個 token、每一層都要讀，對記憶體的需求是 GB 級;n-gram 表每個 token 只讀 16 列，2,560 B。把表拿出去之後，記憶體裡剩下的每一個 byte 都是高流量的權重與 KV cache。--gpu-memory-utilization 0.80 之下 vLLM 分到的 KV cache 是 17.04 GiB，FP8 存法裝 1,069,759 個 token，262,144 的上下文可以同時開 4.08 路。表若硬塞進來，這塊就沒了。

表放在硬碟上之後，讀取方式決定它會不會拖慢速度。配方預設 PLE_MODE=staged:每個 forward 之前，用一個 preadv 執行緒池把這一步要用的列先撈進一塊固定的 GPU buffer，作者量到 131K 列/秒(純 mmap 因為 mmap_lock 只有 10 到 20K 列/秒)。解碼一步 16 列，撈的時間在 0.1 ms 的量級，對一步幾十毫秒的解碼來說可以忽略;而且因為 buffer 位址固定，解碼路徑才吃得到 CUDA graph。

Prefill 是另一回事。32K 的 prompt 要撈 524,288 列，每列 160 B 卻要碰一整頁 4 KiB，實際讀的量放大 25.6 倍。我這台量到 32K prefill 1,666 tok/s、短 prompt 的 TTFT 0.21 到 0.28 秒;作者的表是 7K 1,269 tok/s、28K 1,757、113K 1,760，短 prompt TTFT 0.30 秒，沒有隨長度掉下去。「表常駐會快多少」在這台機器上量不出來，因為它塞不進去;同一張表在 unsloth 的 GGUF 版本裡量化到 26.85 GiB 的 IQ4_NL，全部常駐，兩邊的 prefill 不能直接比。

17 到 41.7:一次 forward 多吐幾個 token

NVIDIA 的 checkpoint 不開 MTP 是 16.6 到 17.0 tok/s，散文與程式同速。不開 MTP 時單流快不起來，是因為每個 token 都要把權重搬一遍:主體每個 token 有效讀取約 9.27 GiB，乘以量到的速度是 154 到 158 GiB/s，約規格 273 GB/s 的六成。換更小的量化也抬不動這個數字，第 32 篇量過，NVFP4 快是因為壓縮，不是那顆 FP4 運算單元。

MTP 把「搬一次權重換一個 token」改成「搬一次權重換好幾個」。草稿頭先猜 3 個，主體一次 forward 把 3 個一起驗，接受幾個就吐幾個，再補一個自己算的。整輪 harness 加總，平均一步吐 2.93 個 token。剩下的差距來自三件事:解碼走 CUDA graph 而不是 torch.compile，草稿頭的 logits 只算 65,536 個而不是整個詞表，KV 用 FP8 讓同樣的記憶體裝兩倍 token。

散文 27.4、程式 42 到 45，這個差距在不開 MTP 的時候不存在。程式碼的下一個 token 好猜，縮排、括號、關鍵字，草稿頭三個位置的接受率是 93% / 78% / 67%;散文是 65% / 39% / 22%。第 42 篇的 27B 從 12.3 到 65 也是同一件事，那台上程式 65 對長文 28，差兩倍多。

九個檔蓋上去，vLLM 不用重編

配方不重編 vLLM，拿 nightly image 的固定 hash，啟動時用 -v 把九個 Python 檔掛到容器內同名檔的位置上。四個是作者自己的 PLE staged 載入與 MTP 實作，四個是上游還沒進 nightly 的 PR 原檔(#55375 修 PLE 的 conv stride，#54846 讓 QSA 路徑吃 FP8 KV)，最後一個是 modelopt.py，上游檔加兩處修正。

那兩處修正對應的是 MTP 一開就死的載入錯誤:

AttributeError: Layer mtp.layers.48.mlp.experts has no parameter 'w2_weight_scale_inv'
  for checkpoint weight 'mtp.layers.48.mlp.experts.0.down_proj.weight_scale_inv'

checkpoint 把 MTP 的 experts 量化成 FP8_BLOCK_SCALES(group 128)，key 叫 mtp.layers.0.mlp.experts;vLLM 把 MTP 層編號成 mtp.layers.48，draft config 只 remap 了 ignored_layers 與 exclude_modules，沒 remap quantized_layers，所以查不到量化設定。就算 prefix 對了，modelopt.py 的 RoutedExperts 分支也只認 FP8 / NVFP4 / W4A16_NVFP4 / MXFP8。overlay 版補的就是這兩處。

每流變慢，整台變快

解碼速度卡在記憶體頻寬。一次 forward 搬一遍權重，同一個 batch 塞越多路請求，總吞吐越高，但每一路都會變慢。四路並行每流 26.1、聚合 47.2，作者六路每流 21.7、聚合 68.8。作者跑到六路，我跑到四路;17.04 GiB 的 KV 在滿 262K 上下文裝得下 4.08 路，短上下文可以更多。

第一輪的單流數字全部比作者低:散文 27.4 對 29.0，JSON 44.3 對 49.3，摘要 31.0 對 35.4，差 2% 到 12%;四路並行卻幾乎一樣，26.1 / 47.2 對 26.4 / 47.1。四路並行的結果幾乎一致，表示 GPU 和頻寬不是差距來源;比較可能只是 harness 每類只有五題，樣本太少。為了畫圖 4，我把每類重跑到至少 15 個十秒視窗，短答題型跑了 25 到 26 輪、程式 9 輪、長答題型 3 到 5 輪，合計 500 題。這一輪的中位是散文 29.3、程式 44.6、推理 46.5、JSON 47.3、HTML 47.9、敘事 28.7、摘要 35.8、格式化 31.0，對作者的 29.0 / 44.3 / 45.6 / 49.3 / 47.6 / 28.5 / 35.4 / 32.4，八類全在 ±4.4% 內，差最多的是格式化的 −4.3%;按原本 40 題等權重算的整體中位 43.6，對作者 43.9。標題與第一節留第一輪的 41.7，這一輪的 43.6 記在這裡。

我的算式漏了什麼

09-06 早上我用「地板 17 乘 MTP +35% 約 23」的算式判定不值得修 vLLM，同一天下午看到作者的 43.9。我當時漏算的，就是這一節講的幾項:接受長度不是 +35% 而是一步 2.93 個 token，再加 CUDA graph、FR-Spec 的小詞表與 FP8 KV。要否決一個實驗，只能用另一個實驗。

完整參數

以下是 launcher 在全預設下真正執行的命令，IP 換成你的。overlay 的來源檔在作者 repo 的 single-spark-vllm-tp1/patch/，本機複製成 ~/patches/qwen4exp-ple-mmap/(launcher 的 PATCH_DIR 預設值)。

docker run --gpus all -d --name qwen38fn --restart no \
  --network host --ipc host --shm-size 32g --ulimit memlock=-1:-1 \
  -v /home/coolthor/models/qwen38-fn-nvfp4-nvidia:/models/qwen38fn:ro \
  -v /home/coolthor/qwen38fn-vllm-cache:/root/.cache \
  -e HF_HUB_OFFLINE=1 -e TRANSFORMERS_OFFLINE=1 -e VLLM_ENGINE_READY_TIMEOUT_S=3600 \
  -e PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True -e CUTE_DSL_ARCH=sm_121a \
  -e TORCH_CUDA_ARCH_LIST=12.1a -e FLASHINFER_CUDA_ARCH_LIST=12.1a -e FLASHINFER_DISABLE_VERSION_CHECK=1 \
  -e VLLM_USE_DEEP_GEMM=0 -e VLLM_USE_V2_MODEL_RUNNER=1 \
  -e QWEN4EXP_PLE_MMAP=1 -e QWEN4EXP_PLE_STAGED=1 -e QWEN4EXP_PLE_MMAP_THREADS=64 \
  -e QWEN4EXP_DRAFT_VOCAB=65536 \
  -v $P/ple_layer.py:$VP/models/qwen4_exp/nvidia/ple_layer.py:ro \
  -v $P/ple_mmap.py:$VP/models/qwen4_exp/nvidia/ops/ple_mmap.py:ro \
  -v $P/model_state.py:$VP/models/qwen4_exp/nvidia/model_state.py:ro \
  -v $P/mtp_draft_vocab.py:$VP/models/qwen4_exp/nvidia/mtp.py:ro \
  -v $P/upstream-overlays/ops_ple.py:$VP/models/qwen4_exp/nvidia/ops/ple.py:ro \
  -v $P/upstream-overlays/ops_qsa.py:$VP/models/qwen4_exp/nvidia/ops/qsa.py:ro \
  -v $P/upstream-overlays/qsa.py:$VP/models/qwen4_exp/nvidia/qsa.py:ro \
  -v $P/upstream-overlays/platforms_interface.py:$VP/platforms/interface.py:ro \
  -v $P/upstream-overlays/modelopt.py:$VP/model_executor/layers/quantization/modelopt.py:ro \
  vllm/vllm-openai:nightly-8a728663c1c3eeace834a95f5654fa653cc1998c \
    /models/qwen38fn --served-model-name qwen38-flash-next qwen3.8-flash-next \
    --host 0.0.0.0 --port 8000 --trust-remote-code \
    --quantization modelopt --tensor-parallel-size 1 \
    --max-model-len 262144 --max-num-seqs 6 --gpu-memory-utilization 0.80 --max-num-batched-tokens 4096 \
    --no-enable-flashinfer-autotune --no-enable-prefix-caching \
    --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_xml \
    --default-chat-template-kwargs '{"enable_thinking": false}' \
    --speculative-config '{"method":"mtp","num_speculative_tokens":3}' \
    --compilation-config '{"mode":0,"cudagraph_mode":"FULL_DECODE_ONLY","cudagraph_capture_sizes":[4,8,12,16,20,24]}' \
    --kv-cache-dtype fp8_e4m3
# P=/home/coolthor/patches/qwen4exp-ple-mmap   VP=/usr/local/lib/python3.12/dist-packages/vllm
# 啟動前:sync; echo 3 | sudo tee /proc/sys/vm/drop_caches

載入完的幾個數字:Model loading took 76.48 GiB;KV cache 可放 1,130,661 個 token，在 262,144 context 下是 4.31 路並行(席位上線後重啟一次的 log 是 17.04 GiB、1,069,759 個 token、4.08 路，進階節與圖 1 用的是這組);短提示 TTFT 0.21–0.28 秒;32K 提示 28,903 個 token 進去 TTFT 17.3 秒(prefill 約 1,670 tok/s)，針放在中間的 PELICAN-7 有撈到;穩態 MemAvailable 14.3–14.9 GB，swap 用了約 4 GB,earlyoom(-m 6)整晚沒動。視覺用一張 64×64 的紅色 PNG 問顏色回「Red」;工具呼叫給 get_weather schema 問台北天氣，回 {"city":"Taipei"}、finish_reason=tool_calls。

八個類別的完整對照(我 / 作者，tok/s):散文 27.4 / 29.0，程式 42.0 / 44.3，推理 44.6 / 45.6，JSON 44.3 / 49.3，HTML 46.8 / 47.6，敘事 27.7 / 28.5，摘要 31.0 / 35.4，格式化 30.3 / 32.4。這是第一輪、每類五題的數字;進階節裡每類 15 到 130 題的重跑，八類都落在作者 ±4.4% 內。作者另有六路並行聚合 68.8，我沒跑那一階。

收穫

帶走三句

• RAM 給流量，硬碟給字典。 47.68 GiB 的 n-gram 表每個 token 只讀 2,560 B，放 NVMe 空出的記憶體全留給 KV cache，262K 上下文可以同時 4 路。代價只會出在 prefill，解碼不受影響。
• MTP 猜得越準，題型之間的速度差距越大。 不開 MTP 是 17，散文與程式同速;開了之後平均一步 2.93 個，散文 27.4 與程式 42 到 45 的差距全是接受率。
• 不重編 vLLM 也拿得到還沒合併的修正。 九個用 bind-mount 蓋上去的檔就是配方的全部;換 image 時只要比對容器裡那九個路徑，不用比整個 repo。