DGX Spark 部署筆記
來自 NVIDIA DGX Spark / GB10 社群關於本地 LLM 部署的實戰發現。
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-06-09
Google 為整個 Gemma 4 家族推出 QAT 檢查點：Q4_0 權重達到接近 BF16 的品質
2026 年 6 月 5 日，Google 為所有 Gemma 4 尺寸發布量化感知訓練（QAT）檢查點。Q4_0 讓 E4B 從 15GB 降至 5GB、純文字 E2B 降到 1GB 以下，llama.cpp、Ollama、MLX、vLLM 與 SGLang 首日即支援。
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-06-08
llama.cpp 取得原生影片輸入：FFmpeg 子程序解碼進駐 mtmd 堆疊
2026 年 6 月 8 日，llama.cpp 合併了 PR #24269，為其多模態（mtmd）子系統加入原生影片輸入。它並非連結 FFmpeg，而是呼叫 FFmpeg 子程序來解碼影格，並透過新的延遲點陣圖 API，在 tokenization 階段將單一影片標記展開為已解碼的影格。此設計與模型無關，因此 Qwen3-VL 與 Gemma-4 等既有視覺模型只需極少量的 CLI/伺服器變更，即可在本地硬體上取得影片功能。
2026-06-08
TensorRT-LLM rc17 為 SM121（DGX Spark）帶來 NVFP4 MoE 後端與 NVFP4 KV 快取
TensorRT-LLM v1.3.0rc17（6 月 2 日）新增一條僅針對 SM120/SM121 啟用的 FlashInfer NVFP4 MoE 後端，並在 trtllm-gen attention 中啟用 NVFP4 KV 快取，還修正了 qwen3 在 SM120/121 上的卡死——這是 DGX Spark 在消費級 Blackwell 上的具體支援。
2026-06-07
vLLM 0.22 新增多層 KV Cache 卸載：GPU 到 CPU 再到磁碟，為長上下文本地服務而設
vLLM 0.22.0（2026 年 5 月 29 日）推出多層 KV cache 卸載框架，可將已快取的區塊由 CPU DRAM 進一步級聯下放到磁碟，並提供 Python 檔案系統層與 Mooncake 磁碟後端；6 月 5 日的修補版加入了少數模型與 AMD-CPU 修正。對於服務 128K-token 上下文的單機本地設備而言，把 KV 溢出到 NVMe 而非重新計算 prefill，正是同一張卡只能服務一位使用者、還是約八位使
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-06-06
Gemma 4 多權杖預測登陸 llama.cpp：自推測解碼在本地推論進入主流
llama.cpp 於 2026 年 5 月合併了原生多權杖預測（MTP）推測解碼（PR #22673），回報在 Qwen3.6-27B 上以約 72% 的草稿接受率達成單串流生成約 2.4 倍加速，草稿頭從同一個 GGUF 載入並擁有自己的 KV-cache。2026 年 6 月 6 日，後續的 Gemma 4 MTP PR（#23398）被標記為可供審查，將此技術擴展到 Google 的 Gemma 4
2026-06-04
NVIDIA 六月 DGX Spark 更新：把桌上型機器變成 4 節點叢集
NVIDIA 6 月 1 日的 DGX Spark 更新（DGX OS 7.5.0、驅動 580.159.03、NCCL 2.30u1）新增 Sync Cluster Assistant，免交換器可串接 3 台 Spark、有交換器則可串接 4 台，組成多節點推論叢集。
2026-05-29
一個 Triton FP8 繞道補丁，為 DGX Spark 的 GB10 擠出多 17% 的 NVFP4 速度
一個社群補丁把 NVFP4 權重改走 GB10 的 FP8 張量核心，而非緩慢的 BF16 後備路徑，讓 Qwen3.6-35B-A3B 在 DGX Spark 上從 40.8 提升到 47.6 tok/s。
2026-05-24
llama.cpp 合併原生 MTP 推測解碼 — Qwen3.6 單請求解碼提速約 2.16×，DGX Spark 受惠
PR #22673 為 llama.cpp 帶來原生多 token 預測（MTP）推測解碼（build b9180+）。在 GB10 DGX Spark 上，Qwen3.6-27B Q4_K_M 單請求從 13.1 升到 28.3 tok/s — 但在並發下反而退步。
2026-05-09
DGX Spark + Mac Studio 解耦推論 — GPT-OSS-120B 達 2.8× 加速：分離 prefill 與 decode
社群模式：DGX Spark 負責 prefill（GPT-OSS-120B 約 1,723 tok/s），Mac Studio M3 Ultra 負責 decode（819 GB/s 記憶體頻寬），相對單張 Spark FP8 達 2.8× 端到端加速。
2026-05-09
Litespark 三元 CPU 推論（arXiv 2605.06485）— TTFT 9.2×、吞吐量 52×，已發布 pip 套件
Litespark 用整數加減 SIMD 取代浮點矩陣乘法，針對三元 {-1,0,+1} 權重網路。TTFT 快 9.2×、吞吐量高 52×、記憶體小 14×。pip 可安裝、整合 HuggingFace。
2026-05-09
llama.cpp 落地 Gemma 4 26B-A4B NVFP4（b9080）與 MiMo-V2.5 注意力核心（b9085）
llama.cpp b9080–b9085 加入原生 Gemma 4 26B-A4B NVFP4（Spark 上 52 tok/s、KV 可用 82 GB）與支援 d_kq=192/d_v=128 GQA 形狀的 MiMo-V2.5 flash-attention 核心。
2026-05-09
TensorRT-LLM v1.3.0rc14 — Qwen3.5 NVFP4 權重載入修復、Mamba-hybrid 前綴快取啟用
TRT-LLM 1.3.0rc14（5/7）修復 Qwen3.5 NVFP4 weight_scales 載入、啟用 Mamba-hybrid 前綴快取、加入 NVFP4 權重更新、DFlash 單模型推測解碼，並有一個專為 Spark 命名的 GEMM 性能 PR。
2026-05-04
Qwen3 MoE 在 DGX Spark 上的效能 — NVFP4 vs FP8 基準測試與實際可行的設定
社群驗證的 Qwen3.6-35B-A3B 與 Qwen3.5-122B-A10B 在 GB10 上的數據：NVFP4+MTP 單使用者可達 55.9 tok/s，c=32 可達 433 tok/s。涵蓋 TRITON-only MoE 後端問題與 MTP+prefix-cache 失敗模式。
2026-05-03
DGX Spark 部署筆記：社群在 2026 Q2 真正遇到的問題
NVIDIA Developer Forums 上 DGX Spark / GB10 的六個重複出現部署陷阱（大多是軟體不是硬體），加上 MoE + NVFP4/MXFP4 的社群共識。
2026-05-02
llama.cpp NVFP4 與 MXFP4 在 GB10（SM121）上的編譯指南
DGX Spark GB10（SM121）上 llama.cpp NVFP4/MXFP4 的完整編譯旗標。gpt-oss-120B MXFP4 達到 pp2048=1,980 tok/s 與 tg32=35 tok/s（PR #22196 合併後）。
2026-05-01
DGX Spark 上 vLLM vs llama.cpp vs Ollama — 該用哪個推論堆疊
GB10 推論堆疊決策指南：vLLM 適合 MoE+高並發，llama.cpp 適合 MXFP4 提示與單使用者，Ollama 適合零設定開發。包含 NVFP4 tok/s 比較。
2026-04-30
LiteLLM + Claude Code 搭配 DGX Spark — LAN 服務設定與協議轉換
透過 LiteLLM 代理將 Claude Code API 呼叫路由到 DGX Spark 上的自架 Qwen3 模型。涵蓋設定、模型別名對映、多 GPU 卸載，以及延遲與雲端 API 的取捨分析。