2026-06-08 — 次瀏覽

為何 DGX Spark 的 GB10 解碼只有 23 tok/s、預填卻達 1,884 tok/s：一份頻寬預算拆解

對 vLLM 2026 年 6 月 DGX Spark 部署的驗證拆解：120B NVFP4 MoE 模型解碼約 23 tok/s，但預填達約 1,884 tok/s，而 GB10 的 273 GB/s 記憶體頻寬解釋了這個落差。

發布了什麼

2026 年 6 月 1 日，vLLM 專案發表了一篇深入剖析，探討如何在單台 NVIDIA DGX Spark（即 GB10 Grace Blackwell 桌上型機箱）上運行大型語言模型，而它做了多數「初體驗」貼文略過的一件事：它報告了一個實際部署完整的延遲—吞吐量形貌，而不是單一個亮眼數字。受測模型是 Nemotron-3-Super-120B-A12B-NVFP4——一個量化為 NVFP4 的 120B 參數混合專家（MoE）檢查點，每個 token 大約啟用 10-15B 參數，並在機箱 128 GB 的 CPU+GPU 統一記憶體池內以 131,072-token 的最大上下文提供服務。

這單一組態是一個清晰的教學案例，說明本地 Blackwell 推論實際上如何運作，因為它把推論請求的兩個階段分了開來——預填（讀取你的提示）與解碼（一次寫出一個 token 的答案）——並顯示它們落在完全不同的效能曲線上。

數字，以及它們屬於哪個階段

以下是 vLLM 貼文針對該部署所報告的數字，加上它們所受限的 GB10 硬體上限（出自 NVIDIA 對該晶片的發布細節），以及一份補足批次處理全貌的社群並發研究。

指標	數字	來源
解碼吞吐量（單一串流）	22.7–23.7 tok/s	vLLM, Nemotron-3-Super-120B-A12B-NVFP4
預填，短判官呼叫（58-token 提示）	~140 tok/s, TTFT 0.42 s	vLLM
預填，中等提示（1,834 tokens）	1,636 tok/s, TTFT 1.12 s	vLLM
預填，長提示（7,234 tokens）	~1,884 tok/s, TTFT 3.85 s	vLLM
測試的最大上下文	131,072 tokens	vLLM
示範流量下的 KV 快取使用率	低於 30%	vLLM
GB10 記憶體頻寬	273–301 GB/s	The Register（GB10 細節）
GB10 記憶體	128 GB LPDDR5x, 256-bit 匯流排, 9,400 MT/s	The Register
GB10 FP4 峰值算力	~1 petaFLOP	The Register

從上到下讀這張表，故事自己就寫出來了。長提示的預填以 1,600-1,900 tok/s 運行——超過解碼速率的 70 倍。無論提示多長，解碼都以約 23 tok/s 緩慢爬行。vLLM 作者指出解碼「仍受啟用參數量所形塑」，並在各種提示大小下維持平坦。那種平坦正是線索所在。

機制：解碼受頻寬限制，預填受算力限制

自迴歸解碼每次前向傳遞生成一個 token。對每個 token，引擎必須把模型的啟用權重從記憶體串流到 Tensor Cores。以約 12B 個各約 0.5 位元組的啟用 NVFP4 參數計算，這大約是每個 token 6 GB 的權重讀取（外加少量 KV 快取讀取）。在 GB10 約 273 GB/s 的下限下，6 GB 約需 22 ms，理論上把你上限壓在接近 45 tok/s，而一旦加上 KV 讀取、MoE 路由與框架開銷，就落在約 23 tok/s。約 1 PFLOP 的 FP4 算力在解碼期間幾乎閒置——Tensor Cores 大部分時間都在等記憶體。這就是為何不論你的提示是 58 個 token 還是 7,234 個，解碼速度幾乎不變：每個 token 的權重讀取是相同的。

預填正好相反。它把每個提示 token 平行處理成一次大型矩陣乘法，因此它飽和的是 FP4 Tensor Cores 而非記憶體匯流排。這就是為何預填能達到四位數的 tok/s，以及為何 TTFT 隨提示長度擴展、而解碼不會。

MoE 設計正是讓 120B 模型在此能用得起來的關鍵。一個 NVFP4 的稠密 120B 模型每個 token 將需要約 60 GB 的權重讀取，並以個位數低值解碼。透過每個 token 只啟用約 12B 參數，MoE 把每個 token 的頻寬帳單砍掉約 5 倍——以充裕的統一記憶體容量（你儲存全部 120B 參數）換取稀缺的記憶體頻寬（你每步只讀取 12B）。這就是本地 Blackwell 推論的核心設計動作：容量便宜，頻寬才是預算。

批次處理改變了算式

單一串流解碼看起來很慢，但另一份並發基準測試（Dendro Logic，2026 年 4 月 22 日）顯示了當你批次處理時會發生什麼。在單台 DGX Spark 上，Nemotron Super 49B v1.5 NVFP4 從單一串流的 5.79 tok/s 總量，提升到 32 串流的 161.90 tok/s 與 256 串流的 695.11 tok/s——總量增益達 120 倍——而每序列速度則從 5.79 降到 2.85 tok/s。OpenAI 的 gpt-oss 120B（MXFP4）呈現相同形貌：單一串流 33.53 tok/s，提升到 256 串流時總量 862.84 tok/s。該貼文的描述很精確：「記憶體頻寬是你花用的預算……當你同時運行兩個串流時，你花用相同的頻寬預算去讀取相同的權重，而兩個串流都拿到結果。」你只載入一次權重，並把那次讀取攤分到整個批次，因此總吞吐量會持續攀升，直到 KV 快取記憶體或算力最終飽和為止。

軟體堆疊一直是另一個槓桿。NVIDIA 於 2026 年 1 月 5 日報告，在 Qwen-235B 上 NVFP4 加上推測式解碼相較 FP8 帶來最高 2.6 倍的增益，NVFP4 把記憶體用量削減約 40%，而 llama.cpp 的更新為 MoE 模型平均增添 35% 的提升——全都在同一塊矽晶上。

實務筆記

如果是我要在這類機箱上部署一個助理或代理迴圈，我會停止把單一串流解碼當作「速度」來引述，而改為圍繞這兩條曲線來設計。對於互動式單一使用者，約 23 tok/s 用於聊天還行，但用於長篇生成就很痛苦，所以我會倚重推測式解碼並讓輸出保持簡短。對於任何要服務多於一位呼叫者的情況——小團隊、批次摘要工作、為許多候選評分的 LLM 判官管線——我會以 16-32 的並發運行，並把機箱當作吞吐量引擎，因為那正是頻寬預算真正回本之處（上面資料中的 45 至 162 tok/s 總量）。我會預設採用 NVFP4 MoE 檢查點，把模型尺寸調到讓啟用參數能舒適地容進頻寬預算內，而非把總參數量拉滿，而且在信任任何人的頭條 tok/s 之前——包括我自己的——我會針對我自己的提示長度分布分別對預填與解碼做基準測試。

被忽略的角度

人人都在對解碼 tok/s 做基準測試；幾乎沒有人針對代理迴圈去編列預填的預算。一個在每一步都重讀一份不斷增長的 7K-token 草稿紙的代理式工作流，每一輪都要付出約 3.85 秒的 TTFT，而在一個 20 步的迴圈中，那筆預填成本可能會壓過實際生成。在一台受頻寬限制的機箱上，提示快取與 KV 重用並不是一個錦上添花的最佳化——它們是「可用的本地代理」與「把大部分牆鐘時間花在重讀自己上下文的代理」之間的差別。讓 120B 模型得以載入的統一記憶體設計，正是讓被浪費的預填變得昂貴的同一個設計，因為沒有多餘的頻寬可以把它藏在背後。