2026-05-03

DGX Spark 部署筆記：社群在 2026 Q2 真正遇到的問題

NVIDIA Developer Forums 上 DGX Spark / GB10 的六個重複出現部署陷阱（大多是軟體不是硬體），加上 MoE + NVFP4/MXFP4 的社群共識。

如果你正在架設 NVIDIA DGX Spark / GB10 跑本地 LLM 服務，NVIDIA Developer Forums 的「DGX Spark / GB10」分類是訊號最強的閱讀起點。下面是 2026 年初社群在記錄的事，為開發者整理過。

六個重複出現的故障模式（先懷疑軟體再懷疑硬體）

1. GPU 卡在 ~5W / 0% 使用率

驅動／CUDA 不匹配。截至 2026-01 已知良好組合：Driver 580.95.05 + CUDA 13.0。舊的 550.54.15 + CUDA 12.4 在 Spark 上是壞的。在斷定 GPU 死掉前先更新兩者。

2. 80–86°C「熱降頻」

通常是假警報 — Spark 規格範圍內。真正原因常是 filesystem cache 塞滿 unified memory，搞混回報過時狀態的舊 CUDA 工具。

sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

3. Dense 70B FP8 卡在 2–3 tok/s

不是設定 bug — 是這個尺寸 dense 模型上 273 GB/s LPDDR5X 記憶體頻寬天花板。社群共識：換成每 token 啟動較少參數的 MoE 模型（gpt-oss-120b 啟動 ~5B、Qwen3-MoE、GLM），或用 speculative decoding 配 draft 模型。

4. 多節點 NCCL 靜默變慢

ConnectX-7 NCCL 在 pod 沒 privileged 或 VF NetworkAttachmentDefinition 缺漏時，沒有錯誤地退回 TCP socket。差距很大：RoCE 真的啟動時 2.12 → 9.78 GB/s（4.6 倍）。在懷疑模型 code 是瓶頸前先驗證 transport。

5. 接近 126.5 GB unified memory 時系統崩潰

別假設全部 128 GB 都是安全空間。llama-swap 編排需要在物理上限以下做自適應 memory cap。

6. ASUS Ascent GX10 卡在 30W「Safety Mode」

這個是真的硬體 — USB-PD 韌體協商失敗。影響 ASUS 牌變體；社群已記錄症狀。

快速分流工具

社群打造的 spark-doctor CLI 可一次檢查上面六項。開 forum thread 前先跑一遍，省下「你檢查過…嗎」的來回。

本地 LLM 效能的量化共識

2026 Q1–Q2 社群共識是 MoE 模型 + NVFP4 / MXFP4 量化在 Spark 上跑 — gpt-oss-120b 與 Qwen3.5-35B-A3B 是兩個最常被引用的選擇。原生 NVFP4 在 llama.cpp 於 build b8967（2026-04-29） 落地。

實戰筆記（我的）

2026 Q2 從零拉起一台 Spark 的人，三個 takeaway：

一開始就鎖 Driver 580.95.05 + CUDA 13.0。Forum thread 中多數效能抱怨都追溯回舊驅動還沒移除。
別跑 dense 70B+ 如果你在乎吞吐量。選個小 active-parameter MoE，同樣記憶體下 tok/s 會是 5-10 倍。
走 multi-node 的話，驗證 RoCE 真的有起來。 TCP 靜默退回是 thread 中最貴的 footgun。

硬體本身很快；2026 Q1–Q2 的抱怨多數是軟體狀態與設定。