# DGX Spark LLM实战笔记：在桌面级AI超算上运行大模型的完整指南

> 一份来自真实硬件测试的DGX Spark大模型部署实战笔记，涵盖llama.cpp、vLLM、Atlas等推理引擎的详细配置、性能基准测试，以及单卡vs双卡部署的权衡分析。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-06-09T10:41:38.000Z
- 最近活动: 2026-06-09T10:52:44.893Z
- 热度: 147.8
- 关键词: DGX Spark, NVIDIA, LLM inference, Step 3.7, vLLM, llama.cpp, Atlas, Blackwell, NVFP4, multi-node, benchmark
- 页面链接: https://www.zingnex.cn/forum/thread/dgx-spark-llm-ai
- Canonical: https://www.zingnex.cn/forum/thread/dgx-spark-llm-ai
- Markdown 来源: ingested_event

---

## 原作者与来源

- **原作者/维护者**: marksunner
- **来源平台**: GitHub
- **原始标题**: DGX Spark — Notes from the Workshop
- **原始链接**: <https://github.com/marksunner/dgx-spark>
- **发布时间**: 2026年6月9日

---

## 背景：什么是DGX Spark

NVIDIA DGX Spark（前身为Project DIGITS）是NVIDIA推出的桌面级AI超级计算机，搭载GB10芯片，主打"桌面AI超算"概念。每台DGX Spark配备：

- **GPU**: Blackwell架构，支持NVLink互联
- **显存**: 128GB统一内存（可运行更大模型）
- **CPU**: 20核ARM架构
- **互联**: NVLink支持多机互联扩展

对于希望在本地运行大模型（尤其是Step 3.7 Flash、DeepSeek V4等开源模型）的研究者和开发者，DGX Spark提供了一个介于消费级GPU和数据中心级DGX之间的独特选择。

---

## 项目概述

这份GitHub仓库不是某个具体软件项目，而是作者团队在真实DGX Spark硬件上测试运行大语言模型的**实战笔记合集**。内容特点是：

- **真实测试**：所有内容都在实际硬件上验证，包括失败案例
- **快速迭代**：标注为"fast-moving space"，持续更新
- **深度细节**：不仅记录成功的配置，还记录"什么失败了以及为什么"

仓库涵盖三大推理引擎的详细配置指南和基准测试结果。

---

## 推理引擎对比与选择

### Atlas（活跃开发中，作者团队正向上游贡献）

Atlas是一个纯Rust编写的推理引擎，采用AI-first设计理念。作者团队正在积极为其贡献DGX Spark支持：

- **核心特性**: Rust + CUDA，原生Blackwell支持，无Python开销
- **DGX Spark支持**: Step 3.7 Flash NVFP4量化、模型架构、权重加载、专家并行
- **相关PR**: [#119](https://github.com/Avarok-Cybersecurity/atlas/pull/119) —— Step 3.7 Flash NVFP4支持（进行中）
- **开发分支**: [作者fork](https://github.com/marksunner/atlas)

Atlas的设计哲学与DGX Spark高度契合——原生Blackwell支持、无Python开销、设计理念与推理任务的本质一致。这是作者团队当前主要投入的方向。

### vLLM

上游vLLM默认不支持DGX Spark的多节点张量并行，因为其V1引擎硬编码了NCCL的环回地址。解决方案是使用StepFun的vLLM fork：

- **Step 3.7支持**: StepFun fork添加Step 3.7模型支持
- **多节点NCCL**: 需要打两个补丁实现多节点NCCL
- **Ray执行器**: 结合Ray实现双Spark TP=2配置

详细配置文档：
- [Step 3.7 Flash — Dual Spark](https://github.com/marksunner/dgx-spark-step37-dual) —— NVFP4跨双Spark，RoCE RDMA配置，262K上下文，18.5 tok/s
- [DeepSeek V4 Flash — TP Benchmark](https://github.com/marksunner/dgx-spark-vllm-tp-benchmark) —— 284B MoE双Spark基准，12.4 tok/s

### llama.cpp / Ollama

单Spark上运行大模型的最简单路径：

- **量化**: GGUF格式支持
- **配置简单**: 最小化设置，良好吞吐量
- **相关指南**: [Step 3.7 Flash — Single Spark](https://github.com/marksunner/dgx-spark-step37-flash) —— Q4_K_S GGUF，27 tok/s，128K上下文，通过mmproj支持vision

---

## 单卡 vs 双卡：关键决策矩阵

对于Step 3.7 Flash，作者提供了清晰的单双卡对比：

| 维度 | 单Spark | 双Spark |
|------|---------|---------|
| **指南** | [Single Spark](https://github.com/marksunner/dgx-spark-step37-flash) | [Dual Spark](https://github.com/marksunner/dgx-spark-step37-dual) |
| **引擎** | llama.cpp (Q4_K_S GGUF) | vLLM (NVFP4, StepFun fork) |
| **吞吐量** | ~27 tok/s | ~18.5 tok/s (with RoCE) |
| **上下文** | 96K (注意稳定性问题) | **262K** |
| **量化** | Q4_K_S (更激进) | NVFP4 (接近BF16) |
| **Vision** | 通过mmproj | 原生 (1.8B encoder) |
| **复杂度** | 低 | 高 |

**核心结论**: 单Spark方案更快更简单；双Spark方案解锁模型的完整262K原生上下文——对于大型代码库、长文档或扩展对话场景至关重要。吞吐量大致相当，上下文窗口是实际的差异化因素。

物理限制：NVFP4模型权重（约121GB）根本无法放入单Spark的显存（即使考虑KV缓存）。这是必须双卡部署的根本原因。

---

## 模型质量对比研究

作者进行了一项有趣的对比研究：给两个模型（Step 3.7 Flash和Qwen 3.5 122B）分配相同的真实研究任务——"撰写一份关于2026年6月DGX Spark本地LLM推理现状的综合报告"。

### 测试条件

| 维度 | Step 3.7 Flash | Qwen 3.5 122B |
|------|----------------|---------------|
| **架构** | 198B MoE (~11B active) | 122B MoE (~10B active) |
| **量化** | Q4_K_S GGUF | INT4+FP8 hybrid (AutoRound) |
| **引擎** | llama.cpp | vLLM |
| **硬件** | 1× DGX Spark | 1× DGX Spark |
| **生成速度** | ~28 tok/s | ~47 tok/s |

### 结果对比

| 指标 | Step 3.7 Flash | Qwen 3.5 122B |
|------|----------------|---------------|
| **完成时间** | ~27分钟 | ~4分钟 |
| **报告规模** | 366行 / 37KB | 505行 / 20KB |
| **网络搜索次数** | 24 | ~13 |
| **引用来源数** | 74 (编号) | ~25 (内联) |
| **识别矛盾数** | 6 (带分析) | 4 (带分析) |
| **6个章节全覆盖** | ✅ | ✅ |

### 关键观察

1. **Step 3.7更深入**: 更多搜索、更多来源、更详细的矛盾分析。当两个来源给出冲突的性能数字时，Step 3.7不仅记录差异，还识别根本原因（如混淆预填充吞吐量与生成速度、或模型相关的量化质量差异）。内置的推理能力（思维链）似乎真正提升了需要比较和调和信息的任务的分析质量。

2. **Qwen 3.5更快更简洁**: 快约6.7倍的墙钟时间，输出更简洁、建议更可操作，包含另一个模型遗漏的实际发现（如AWQ/GPTQ在GB10上性能差，Atlas推理引擎基准）。

3. **两者都有幻觉风险**: 两个模型的来源URL都未完全验证。Step 3.7引用了74个来源，表面上有更多真实链接的风险——但也可能有更多真实链接。Qwen 3.5引用的来源总体更少。

---

## 其他推理引擎

### ds4 (DwarfStar)

antirez设计的推理引擎，专为分布式服务设计。
- [DeepSeek V4 Flash — ds4 Benchmark](https://github.com/marksunner/dgx-spark-ds4-benchmark) —— 284B MoE双Spark基准，11.4 tok/s

---

## 实用价值与适用场景

这份笔记合集对于以下人群具有直接参考价值：

1. **DGX Spark已购用户**: 提供了经过验证的配置路径，避免重复踩坑
2. **考虑购买DGX Spark的开发者**: 真实的性能数据和复杂度评估，帮助决策
3. **LLM推理优化研究者**: 不同引擎、量化方案、并行策略的详细对比
4. **MoE模型部署工程师**: Step 3.7 Flash和DeepSeek V4的具体部署经验

仓库的价值不在于提供"一键部署脚本"，而在于记录了**真实的试错过程**——包括Docker设备权限、NCCL环境变量、补丁应用、以及所有"为什么没有工作"的细节。对于硬件新品的早期采用者，这种"诚实的失败记录"往往比"理想化的成功案例"更有价值。

---

## 相关资源

- [Atlas推理引擎](https://github.com/Avarok-Cybersecurity/atlas)
- [StepFun vLLM fork](https://github.com/stepfun-ai/vllm)
- [Hermes Agent](https://github.com/NousResearch/hermes-agent) —— 测试中使用的Agent框架

---

*本文基于GitHub仓库marksunner/dgx-spark的公开信息整理。