2026-06-07 — 次瀏覽
vLLM 官方 DGX Spark 指南：為何 120B NVFP4 模型解碼僅約 23 tok/s，以及這對頻寬受限的本地推論帶來什麼啟示
2026 年 6 月 1 日，vLLM 專案發布了在 NVIDIA DGX Spark（GB10 Grace Blackwell、sm_121、128 GB 統一記憶體）上運行 vLLM 的官方指南。透過 vllm/vllm-openai:cu130-nightly 容器服務 Nemotron-3-Super-120B-A12B-NVFP4，報告解碼速度 22.7-23.7 tok/s、預填充最高約 1,884 tok/s、TTFT
發布了什麼
2026 年 6 月 1 日，vLLM 專案發布了在 NVIDIA DGX Spark 上運行 vLLM 的官方逐步指南。DGX Spark 是桌邊型 GB10 Grace Blackwell 機器，配備 128 GB 統一 LPDDR5X 記憶體與消費級 Blackwell 的 sm_121 計算能力。與大多數「我把它開機起來了」的論壇貼文不同，這篇文章將經過測試的部署配方與真實的本地評估結合，因此也可作為思考單機推論經濟性的參考。
主打的工作負載是 Nemotron-3-Super-120B-A12B-NVFP4：總計 120B 參數，在混合專家（MoE）架構中每個 token 約啟用 12B，量化為 NVFP4。這個組合正是整個練習的重點。一個 BF16 的 120B 稠密模型根本放不下，但一個約 12B 啟用參數的 NVFP4 MoE 能輕鬆容納於 128 GB 中，且每個 token 只需串流其權重的一小部分。
報告中的數字
透過 vllm/vllm-openai:cu130-nightly 容器（CUDA 13）服務，搭配 --gpu-memory-utilization 0.85、--max-model-len 131072 與 --max-num-seqs 4，該文測得：
| 指標 | 報告範圍 |
|---|---|
| 解碼吞吐量 | 22.7-23.7 tok/s |
| 預填充吞吐量 | ~140 tok/s（58-tok 提示）至 ~1,884 tok/s（7,234-tok 提示） |
| 首 token 時間 | 0.42 s（短）至 ~3.85 s（長） |
| KV 快取使用率 | 單用戶低於 5%；小批次低於 30% |
有兩點特別突出。第一，KV 快取佔用極小，因此 128 GB 幾乎全部用於權重而非脈絡。第二，預填充隨提示長度擴展，而解碼無論如何都維持在約 23 tok/s 的平穩狀態。那條平穩的解碼曲線正是關鍵線索。
為何解碼是平的：頻寬，而非算力
結構性的啟示就在記憶體匯流排。GB10 透過 256-bit LPDDR5X 介面（8,533 MT/s）以 273 GB/s 移動資料 — 約比 H100 的 ~3.35 TB/s HBM3 慢 12 倍。自迴歸解碼每個 token 讀取一次啟用權重，因此在低批次下，張量核心大多閒置等待記憶體。獨立拆解報告也直白地指出同一點：在 273 GB/s 下，無論投入多少算力，35 GB 的模型理論上最高僅能達到約 7.8 tok/s。
這也是為何 NVFP4 在此比在資料中心卡上更重要。將權重從 16 bytes/param（BF16）削減至約 4.5 bytes/param，能將每個 token 移動的位元組數減半，這在頻寬受限的機器上能將解碼吞吐量大約翻倍。生態系中流傳的一項比較顯示，同樣的 Nemotron 3 Super 在 NVFP4 版本下約為 38 tok/s，而在 Q4_K_M GGUF 下約為 19.5 tok/s — 同一個模型，變數在於格式與核心路徑。（vLLM 文章自身的 ~23 tok/s 反映其特定的 131K 脈絡配置與容器，因此應將跨來源數字視為方向性指標，而非完全對等的比較。）
實務框架
該文對其適用範圍坦率得令人耳目一新：DGX Spark「最好視為本地單用戶或小批次推論目標」。它刻意運行 --max-num-seqs 4；將並行度推得更高會犧牲延遲，因為你受限的是頻寬而非算力。透過 ConnectX 結構的多 Spark 配置雖被提及，但本文明確未予評估。
統一記憶體架構是低調的促成者。由於 CPU 與 GPU 共享一個實體 128 GB 池，權重與 KV 快取無需透過 PCIe 進行 cudaMemcpy 往返即可常駐 — 相較 HBM 你損失了原始頻寬，但省下了複製的成本，而這正是讓 120B 級模型能在桌機上運行的關鍵。
從業者註記： 若你要為 100-130B 的 NVFP4 MoE 規劃單機本地伺服器，請以約 20-40 tok/s 解碼與較低的 max-num-seqs 來設定預期，而非資料中心級吞吐量。請驗證你實際要運行的容器／CUDA 組合（此處官方路徑為 cu130-nightly 映像與特定於模型的推理解析器）；在不同脈絡、量化核心或服務堆疊下發布的解碼速率不會乾淨地轉移，而光是初始權重載入就可能耗時 10-15 分鐘。
未被充分考量的角度： 幾乎每個 DGX Spark 基準測試的標題都是單串流解碼數字，這會美化 MoE 模型 — 每個 token 只有約 10% 的參數會移動。真正能預測這台機器是否適合小團隊使用的指標，是在真實 KV 佔用下的並行解碼。在 KV 快取使用率低於 5% 時，系統幾乎沒有動用其最弱的資源；有趣（且大多未被發布）的問題，是當你在 273 GB/s 匯流排上提高批次時的吞吐量與延遲曲線，因為那正是一台桌邊統一記憶體機器要麼撐得住數名同時使用者、要麼崩塌為嚴格的單人工具的分水嶺。