2026-06-10 — 次瀏覽

llama.cpp b9555 為 Blackwell SM121 推出原生 NVFP4 核心，釋放 DGX Spark 完整效能

llama.cpp b9555 為 Blackwell SM121/GB10 推出原生 NVFP4 GEMM 核心——首個繞過 FP16 計算回退路徑的版本，DGX Spark 單用戶解碼吞吐量估計提升 30–40%。

這次發布

2026 年 6 月 8 日在 ggml-org GitHub 儲存庫發布的 llama.cpp b9555，是 DGX Spark 用戶期待已久的版本。CUDA 後端首次附帶針對 Blackwell SM121——DGX Spark 內 GB10 晶片的運算架構——編譯的原生 NVFP4 矩陣乘法核心。在此之前，在 Spark 上運行 NVFP4 量化模型，要麼需要 TensorRT-LLM（快速但操作複雜），要麼需要 vLLM（高吞吐量但單用戶有額外開銷）。llama.cpp 輕量的單一二進制部署模式現在終於有了相匹配的硬體加速。

NVFP4 在 GB10 上為何重要

Grace Blackwell GB10 SoC 具備兩項相對前一代硬體的根本優勢：Grace CPU 與 Blackwell GPU 之間 900 GB/s 雙向 NVLink-C2C 連接，以及原生張量核心對 NVFP4 等次 8 位格式的支援。對推理工作負載而言，NVFP4 將 FP8 表示的記憶體佔用再減半，直接轉化為每設備的模型容量。

Qwen3-30B 以 FP16 格式約佔 Spark 128GB 統一記憶體的 60GB；以 NVFP4 則約 15GB，為 128K token KV 快取留下充足空間而無需溢出到系統記憶體。

b9555 實際改變了什麼

在 b9555 之前，llama.cpp 的 CUDA 後端可以在 Blackwell 硬體上載入 NVFP4 量化的 GGUF 文件，但矩陣乘法運算回退到軟體去量化再乘法的路徑。結果是輸出正確，但沒有張量核心利用——用 FP16 計算速度執行 NVFP4 權重，這在核心層面抵消了帶寬節省。

b9555 合併的 PR 將 NVFP4 輸入直接接入 Blackwell 的塊縮放 GEMM 張量核心路徑——與 NVIDIA CUTLASS 4.x 和 TensorRT-LLM 的 SM121 核心暴露的路徑相同。實現處理密集模型和專家（MoE）層的 NVFP4 張量名稱及其對應的縮放因子張量，這是早期實驗性補丁對 MoE 模型未完全解決的細節。

預期效能影響

使用之前的回退路徑，Llama-4-Scout-17B 的 NVFP4 在 DGX Spark 單用戶模式下，基於 Spark Arena 排行榜和 NVIDIA 開發者論壇的基準數據，約可實現 45–50 tokens/s 的解碼速度。SM121 原生核心路徑預計可縮小與 TensorRT-LLM 同模型同量化約 65–70 tokens/s 參考數字的差距——無需更改服務堆疊或模型權重，吞吐量提升 30–40%。

實際應用意義

對在 DGX Spark 上運行本地推理的團隊而言，b9555 使 llama.cpp 成為 NVFP4 模型的一流選項，而非退而求其次的方案。歷史上的框架選擇邏輯是：llama.cpp 用於單用戶互動工作負載（延遲更低、設置更簡單），vLLM 用於並發多用戶或批次工作負載。b9555 之後這個分工仍然成立，但在單用戶場景下與 vLLM NVFP4 路徑的效能差距已比 2026 年任何時候都更接近。

注意事項

兩點值得注意：第一，b9555 的 NVFP4 支援僅限於推理；llama.cpp 不在 NVFP4 下支援訓練和微調。第二，SM121 路徑目前針對密集模型和最多 64 個專家槽的 MoE 架構進行了驗證，非常大型的 MoE 配置可能需要額外調整。

結論：如果你在 DGX Spark 上運行 NVFP4 GGUF 模型，並因為操作簡便而選用 llama.cpp，請更新到 b9555 並重新執行基準測試。