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 的抱怨多数是软件状态与设定。