vLLM 在 DGX Spark 上：架構、設定與本地評估

vLLM 讓 NVIDIA DGX Spark 上的本地推論快速且高效，彌合了筆記型電腦規模開發與資料中心 GPU 服務之間的差距。透過結合相容 OpenAI 的 API 與先進的記憶體、批次處理與遙測控制，vLLM 允許開發者在 DGX Spark 獨特的硬體架構上本地執行大型 NVFP4 模型。

DGX Spark 架構與記憶體模型

NVIDIA DGX Spark 以 GB10 Grace Blackwell SoC 為核心，使用統一的 CPU 與 GPU 記憶體池。此架構對推論工作負載的配置與執行方式產生重大影響。

統一記憶體與模型容量

共享的 CPU/GPU 記憶體池讓開發者能載入比固定專屬 GPU 記憶體池更大的 NVFP4 模型。這使得在單一 Spark 上執行高達 2000 億參數的模型成為可能，具體取決於模型架構與執行時設定。vLLM 使用如 --gpu-memory-utilization、--max-model-len、--max-num-seqs 等旗標，並搭配分頁 KV 快取，來平衡模型大小、上下文長度與併發性。

硬體特定驗證

在 DGX Spark 上的部署必須使用針對 sm_121 目標驗證過的 vLLM 版本、容器映像標籤與執行時設定。從較大型 GPU 系統調整而來的配置應視為 kernel 支援的工程檢查清單，而非效能基準。

NVFP4 MoE 最佳化

DGX Spark 尤其適合 NVFP4 Mixture-of-Experts（MoE）服務。NVFP4 減少記憶體壓力並改善預填行為。約 10–15 億活躍參數的 MoE 模型非常契合，因為較小的活躍參數集合可優化系統記憶體頻寬上的解碼效能。

vLLM 本地服務的功能

vLLM 提供多項關鍵功能，以最佳化 DGX Spark 本地、小批次推論的效能。

分頁 KV 快取與持續批次處理

為避免聊天工作負載中靜態批次的低效，vLLM 採用持續批次，在每個解碼步驟接受與驅除請求。結合分頁 KV 快取後，DGX Spark 能支援多個同時進行的請求，而不會產生過度的記憶體碎片化。在使用 120B NVFP4 MoE 模型的測試中，KV 快取使用率對單一使用者通常低於 5%，對小批次示範流量則低於 30%。

相容 OpenAI 的串流

Spark 上的 vLLM 端點使用相容 OpenAI 的 API（例如 http://localhost:8000/v1），讓現有的客戶端程式碼得以重複使用。使用 stream=true 對本地回應性至關重要，能在 token 到達時即時渲染，以降低聊天、程式編寫與代理工作流程中的感知延遲。

透過 Prometheus 的可觀測性

vLLM 的 Prometheus 端點（/metrics）讓開發者監控本地設備的健康狀態。DGX Spark 的關鍵指標包括：

• KV 快取使用率（vllm:kv_cache_usage_perc）
• 提示與生成 token 計數器
• TTFT（首次 token 時間）與 token 間延遲直方圖

執行時配置與部署

在 DGX Spark 上成功部署需要將執行時旗標與系統的統一記憶體配置以及特定模型配方相匹配。

模型選擇指引

模型選擇是主要的效能杠桿。100–130B MoE NVFP4 模型，活躍參數為 10–15B，最能有效利用 Spark 的記憶體容量與解碼速率。

關鍵 vllm serve 旗標

• --gpu-memory-utilization：必須調整以在統一記憶體池中為作業系統、容器執行時與 KV 快取成長留出空間。
• --max-model-len 131072：設定最大提示與完成長度。vLLM 依據活躍上下文排程，而非為每個請求保留完整長度。
• --max-num-seqs 4：保持同時解碼串流數量低，以防止每 token 帶寬成本導致 TTFT 峰值。
• Automatic Prefix Caching：在 vLLM V1 中預設啟用，會在共享開頭提示的請求之間重用 KV 區塊，對於長系統提示非常有益。

JIT 預熱與載入

冷啟動延遲是重要因素；開機後的第一個請求會觸發 Inductor 與 FlashInfer 的 JIT 產生程式碼，對 Nemotron-3-Super 大約需要 25 秒。開發者應在啟動時發送小型「ping」請求以預熱 kernel。此外，雖然初始權重載入可能需要 10–15 分鐘，但可評估使用 fastsafetensors 或 InstantTensor 等路徑以縮短此時間。

本地評估結果：Nemotron-3-Super

在單一 DGX Spark 上評估 Nemotron-3-Super-120B-A12B-NVFP4 模型，於各種情境下顯示出 22.7–23.7 token/秒 的穩定解碼吞吐量。

情境	提示 token	生成 token	首次 token 時間	總延遲	預填 token/秒	解碼 token/秒
典型評估呼叫	58	2	0.42 s	~0.53 s	140	~23
中等提示，短生成	1,834	32	1.12 s	1.12 s	1,636	23.7
長提示，短生成	7,234	32	3.85 s	~5.26 s	1,877	22.7
中等提示，長生成	1,834	108	1.12 s	~5.74 s	1,639	23.4
長提示，長生成	7,234	124	3.84 s	~9.26 s	1,884	22.9

關鍵效能洞見

• 預填擴展：隨著提示變長，預填吞吐量提升，從 140 token/秒上升至接近 1,900 token/秒，因為開銷在更多 token 上被攤平。
• 解碼穩定性：解碼吞吐量在不同提示長度下保持穩定，受活躍參數數量與 FP4 kernel 路徑所決定。
• TTFT：首次 token 時間在提示大小增加四倍時大約會增加三倍。

營運摘要

為了在 DGX Spark 上最佳化 vLLM，開發者應優先選擇 100–130B MoE NVFP4 模型，使用針對 sm_121 驗證的官方 vLLM 映像，並調整 --gpu-memory-utilization 以適應統一記憶體池。預熱 JIT 並使用 /metrics 端點，可確保可預測且具互動性的本地推論體驗。