8 台 DGX Spark 组集群，这个标题第一次看到的时候，我第一反应不是“牛”，而是“真有人这么干”。单个 DGX Spark 本身就是一台专门为大模型推理和微调设计的紧凑型 AI 工作站，官方定位是可以直接在本地运行 200B 参数级模型。单台的本地能力已经覆盖了大多数个人开发者场景，那为什么还要把它扩展成 8 台？答案其实很直接：当你要跑更大的模型、同时服务更多请求，或者让一个团队共享同一套 AI 算力底座时，单台机器就不够了。下面主要围绕 Alex Ziskind 用 8 台 DGX Spark 组集群的实测记录，把这类紧凑型 AI 工作站集群从组网、软件栈、模型服务到故障排查完整拆开。适合对本地大模型部署有兴趣，又想把“多机协同”这件事搞清楚的读者。

1. 为什么要把 8 台 DGX Spark 组在一起？先想清楚集群解决什么问题

1.1 单台能力不弱，集群是为了突破单机边界

先说单机的情况。DGX Spark 这类设备的核心优势，是把“能跑大模型”这件事搬到了桌面上。官方宣传中，单台可以在本地运行 200B 参数级模型，这意味着你在本地做推理、做接口测试、跑一个小团队的日常任务，基本不需要依赖远端算力。对很多开发者来说，单台的体验已经足够好。

那为什么还要组集群？我理解下来有三个真实动机：

• 模型变大了。200B 参数的模型单台能跑，但如果你要跑 400B、600B，或者跑像 DeepSeek 那种 600B+ 的 MoE 模型（量化权重），单台的显存和统一内存就不够放，必须拆到多台机器上做张量并行。
• 并发需求上来了。单台模型吞吐有限，如果多个同事同时发请求、同时跑批量任务，请求会排队，输出速度会明显下降。8 台集群可以把推理服务分散到多张卡上，提升整体吞吐。
• 数据不出本地。很多公司要求模型权重和业务数据不能离开内部环境，云端部署受限，本地集群就成了更合适的底座。

注意，这里说的是“提升整体吞吐”，不是“单次请求一定更快”。多机并行之后，单次输出的延迟可能因为通信开销反而略高，但系统的容量、并发能力和可承载的模型规模都上去了。

1.2 集群不是把 8 台机器叠起来，而是让它们协作得像一个整体

很多人第一次接触集群会有一个误区：以为 8 台机器摆在一起，任务自动就加速 8 倍。实际不是。集群要真正产生价值，必须解决三件事：

1. 网络通信。多台机器要交换模型权重、中间激活值，通信带宽不够，性能会直线下降。
2. 调度。谁的任务跑到哪台机器上，一台机器满了怎么办，任务失败要不要重试，都需要调度器处理。
3. 存储一致性。8 台机器都要读到同一份模型权重，权重文件放在哪，权限怎么统一，输出结果写到哪里，这些不提前规划，后面会非常难受。

Alex Ziskind 的实测记录里，8 台 DGX Spark 摆在一起，视觉冲击力很强，但真正值得关注的是背后的网络、软件和部署流程。这也是这次拆解重点展开的部分。

2. 组网和硬件准备：8 台机器连起来之前，先把网络和存储想明白

2.1 网络是集群的第一道门槛：带宽、拓扑和交换机选择

多机集群里，网络的重要性不亚于 GPU 本身。你把一台大模型拆到 8 台机器上，每次推理都要在机器之间同步中间结果，如果网卡不支持 RDMA 或带宽不够，模型根本跑不动。

所以第一步是确认每台 DGX Spark 的网卡规格。不同批次的设备、不同区域的版本可能有差异，不要凭印象判断，直接用系统命令查看：

lspci | grep -i ethernet
ethtool <网卡名称>

接下来要决定拓扑。8 台机器最直观的方式是全部接到同一台高速交换机上，形成星型拓扑。这种结构简单、排障方便，适合 8 台规模。如果以后要扩展到几十台，再考虑 Spine-Leaf 架构，现在先把当前需求的网络配通。

几个关键配置点：

• 开启网卡的 RDMA 支持（如果硬件支持），确认 RoCE 模式和优先级流控配置正确。
• 所有节点使用统一的主机名，统一做时钟同步（chrony 或 NTP），否则分布式任务会出现节点间超时。
• 调整网卡 MTU，一般建议配合交换机开启 jumbo frame，但不要盲目拉高，先测试小包和大包传输是否正常。

我排障时见过最典型的问题，不是网卡不通，而是“能 ping 通，但带宽上不去”。这种情况多半是 RDMA 没开、MTU 不一致，或者交换机没有启用流控，先按这个顺序排查。

2.2 存储规划：模型权重、数据集和输出文件不能都堆在本地盘

8 台机器如果每台都自己存一份完整模型，听起来可行，但维护成本很高。权重更新一次，你得同步 8 台机器，很容易出现版本不一致。

更稳妥的做法是准备一块共享存储：

• 用一台单独的存储服务器做 NFS，把模型权重放在共享目录，所有节点只读挂载。
• 有条件的话，用并行文件系统或对象存储存放数据集，避免多个进程同时读同一个文件时打满单点带宽。
• 每个节点的本地 NVMe 盘用来做缓存和临时输出，最终结果统一写到共享目录。

这里的判断标准是：模型权重可以只读共享，但临时文件和日志要写本地。这样既保证一致性，又不让每台机器都向共享存储写垃圾数据。

2.3 电源和散热：8 台设备放在一起，不是插排连上就行

这个点很容易被忽略，尤其第一次搭硬件集群的人。8 台设备摆在一起，每台都有独立的电源适配器，如果全部插在同一个普通插排上，很可能跳闸。搭建之前要先估算总功率，并预留余量。

散热也要提前想。设备之间留出通风空间，房间要有空调或通风设施。DGX Spark 本身定位是桌面级，单台噪声控制还不错，但 8 台同时满载运行，环境温度会明显上升。温度过高会导致降频，性能下滑，这个问题在集群里比单机更明显。

建议：先单独加电启动每一台设备，确认系统正常后再统一上架。不要在通电状态下插拔高速网线或显示线，减少静电和意外断电风险。

3. 软件栈选择：Slurm 和 Kubernetes，两条路线怎么选

3.1 先装底层驱动和通信库，再谈调度器

不管选哪种调度器，底层的东西都一样：NVIDIA 驱动、CUDA 工具包、容器运行时，以及 NCCL。多机环境要特别注意版本一致性。

我的建议是，在所有节点上使用同一版本的驱动和 CUDA 工具包，不同机器版本不一致，是分布式任务最常见的问题来源。用容器跑任务可以缓解依赖冲突，但宿主机的驱动版本仍然要尽量统一。

然后安装通信库。NCCL 是多机多卡训练和推理的关键组件，它在跨节点通信时会自动选择可用的网络接口。安装后先用一个小任务验证 NCCL 是否正常发现所有设备，再进入下一步。

3.2 用 Slurm 做 AI 训练集群：思路简单，任务调度直接

如果你主要是跑大模型推理测试、微调实验、批量离线任务，Slurm 会更省心。Slurm 的模型是“一台管理节点 + 多台计算节点”，计算节点上装 slurmd，管理节点上装 slurmctld，配置好节点列表和分区即可。

一个最小示例：

# 查看所有节点状态
sinfo

# 在集群上申请 8 个节点，每个节点运行一个进程
srun --nodes=8 --ntasks-per-node=1 --gpus-per-node=1 python run_inference.py

Slurm 的好处是概念简单、文档多、社区成熟，非常适合 AI 团队内部使用。缺点是不太适合做对外服务的在线推理，因为它的调度单位是“作业”，而不是“请求”。

3.3 用 Kubernetes 做推理服务集群：更贴近生产环境

如果你要的是“对外提供一个推理 API”，Kubernetes 更合适。K8s 的优势在于服务编排、自动扩缩容、故障重启，一个推理服务挂掉后，调度器会自动把另一个副本拉起来。

但 K8s 的运维代价也更高。你需要处理节点亲和性、GPU 设备插件、服务发现、Ingress、健康检查，起码要几个人熟悉这套体系。8 台机器的规模不算大，如果只是为了内部测试，用 K8s 会有点重。

我一般会这样区分：

• 学习测试、离线批量任务、内部实验：Slurm。
• 对外推理 API、多人使用、希望服务自动恢复：Kubernetes。
• 两者都想要：先用 Slurm 跑通实验，稳定后再把模型服务包成容器丢到 K8s 上。

无论哪种方案，都要在集群上安装 GPU 监控插件（DCGM 或 Prometheus exporter），否则出问题时你根本不知道是哪台机器、哪张卡出了问题。

4. 多机大模型推理落地：从单机跑通到 8 机张量并行

4.1 先在一台机器上跑通，确认模型位置、显存和输出

这是我会反复强调的一步：不管最终目标是 8 台还是 16 台，第一次部署一定先从单台开始。先在单台设备上选择模型、启动推理引擎、发一条请求，确认输入输出都正常，再考虑多机。

单台部署时要注意几个点：

• 模型权重放在哪，路径是否所有节点都能读到。
• 推理引擎的缓存目录是否有足够的磁盘空间。
• 默认的 max model length 是多少，短文本和长文本的差异。
• 输出流式是否开启，是否会影响首 token 延迟。

这个阶段的目标不是追求速度，而是把“输入到输出”的链路跑通。链路没问题了，才能判断后面多机场景出现的问题到底是通信问题还是上游问题。

4.2 两台机器验证张量并行，再扩展到 8 台

把模型从单台扩展到多台，最常见的方式是张量并行（Tensor Parallelism）。原理是把模型的权重按层或按维度切分到多台机器上，推理时各个节点之间同步中间结果。

用 vLLM 这类推理引擎，参数通常是这样：

python -m vllm.entrypoints.openai.api_server \
  --model /shared/models/your-model \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.9

先用 --tensor-parallel-size 2 配两台机器跑通。此时要观察两个现象：

• 模型是否成功加载，权重是否被正确切分。
• 两条请求的输出是否与单机一致，吞吐是否合理。

如果两台机器跑通，再逐步扩展到 4 台、8 台。每增加一个数量级，都要重新验证一次，不要直接从 1 跳到 8。

这里要提醒一句：张量并行规模越大，通信开销越大。8 台机器跑一个模型，单并发下可能不会比 2 台快多少。真正值得关注的是高并发下的吞吐，以及模型本身能不能塞进这么多台设备。

4.3 推理引擎的并发与吞吐配置：别急着拉满

多机部署之后，很多人会急着把并发数拉满，结果发现输出变慢、节点报错、甚至 OOM。正确的做法是先压测，再调参。

压测时可以分成几个梯度：

• 1 个并发请求，测首 token 延迟和单次输出速度。
• 5 个并发，看吞吐是否提升。
• 20 个并发，看是否出现超时或错误。
• 继续增加，直到出现错误或延迟突增，那个点就是这套配置的容量上限。

需要关注的指标包括：每秒输出 token 数（tokens/s）、首 token 延迟（TTFT）、端到端请求延迟、请求失败率。建议用脚本记录这几项，而不是凭感觉判断“快还是慢”。

5. 验证指标与常见故障排查：怎么知道集群真的在干活

5.1 性能判断：看吞吐、延迟、资源利用率和成功率

集群部署完之后，最忌讳只跑一个用例就说“成功了”。我建议至少从四个维度做验收：

1. 吞吐：并发请求下每秒处理的 token 数，是否达到预期。
2. 时延：首 token 延迟和完整输出延迟是否稳定，有没有偶发的高延迟。
3. 资源利用率：查看每台机器的显存利用率、GPU 利用率、网络带宽占用。
4. 成功率：连续跑 100 条请求，统计失败率，任何一条失败都要记录日志。

如果这些指标都正常，集群才算真正可用，否则只能算“能启动”。

5.2 常见问题：通信超时、GPU 发现失败、卡死在加载阶段

多机环境下的故障，往往不是单点问题，而是多个条件叠加的结果。我按排查优先级列一下：

• 先看状态。哪台机器掉线？哪个进程卡住？ nvidia-smi 是否正常输出？ sinfo 或 kubectl get nodes 是否显示所有节点 Ready？
• 再看通信。节点之间是否互通，主机名解析是否正常，NCCL 是否报网络超时。可以用 nccl-tests 做一次小规模通信测试。
• 再看存储。模型权重路径是否能被所有节点访问，共享目录的读写权限是否正确，NFS 挂载是否稳定。
• 再看资源。某台机器的内存、磁盘、共享存储是否被打满，显存是否被其他进程占用。
• 最后看日志。不要只看应用日志，还要看系统日志和 GPU 监控日志。

一个比较常见的现象是：任务在某个节点上卡住，看起来像模型推理变慢，实际上是该节点网络不稳定或共享存储读不出来了。这时候不要反复重启任务，先确认网络和存储状态。

5.3 稳定运行的日常习惯：日志、监控、资源配额

集群搭好只是开始，长期稳定运行靠的是日常习惯。我自己的经验是三条：

• 所有任务必须写日志，日志目录按日期和任务名组织，否则故障排查无从下手。
• 监控要一直开着，GPU 利用率、内存、网络、温度、共享存储容量，至少保存 7 天到 30 天的历史数据。
• 给每个用户或每个团队设置资源配额，防止某个人把集群资源占满，影响其他人任务。

另外，集群本身要有明确的故障转移意识。虽然 8 台机器规模不大，但调度器配置里最好预留“节点故障后任务自动迁移或告警”的机制，而不是等用户发现任务卡住才人工处理。

6. 适不适合跟进：哪些人该组集群，哪些人只需要一两台

6.1 适合场景：私有化部署、多团队共享、离线批量任务

先说实话，8 台 DGX Spark 组集群不是普通个人开发者需要做的事。单台就能跑 200B 模型的设备，个人使用完全够。真正需要集群的是这几类场景：

• 企业内部私有化部署，模型权重和数据不能出本地。
• 多个团队共享一套算力底座，需要集中调度和配额管理。
• 有大量离线批量推理任务，需要并行处理。
• 团队正在做多机分布式推理或微调的研究，需要在真实环境中验证方案。

在这些场景下，8 台设备组一个集群是合理的，甚至算是一种比较务实的本地 AI 基础设施方案。

6.2 不适合场景：预算有限、只跑单任务、缺少运维精力

如果你属于以下情况，我更建议先别碰：

• 只有一个人在用，跑单个模型的推理，单台已经完全够用。
• 团队没有运维经验，也不想折腾 Linux、网络、调度器，直接选云服务更省心。
• 任务量不大，8 台设备的功耗和散热成本已经超过实际收益。
• 想要通过集群“让大模型跑得更快”，但实际瓶颈不在算力，而在数据准备和代码质量。

工具是解决问题的，不是制造新问题的。组集群之前，先把需求量化：到底要跑多大的模型、多少并发、多少个任务、多少人用。如果这些数字都很小，单台就够。

6.3 再想一步：从 8 台集群到生产服务，还缺什么

即便 8 台集群跑通了，离生产级推理服务还有距离。需要补的东西包括：稳定的监控告警、备份机制、权限管理、API 网关、请求限流、模型版本管理，以及一套清晰的发布流程。

在 Alex Ziskind 的这次实测里，8 台 DGX Spark 摆在一起本身是一种技术探索，说明这类桌面级 AI 设备已经具备“拼成小集群”的能力。但对大多数团队来说，我更推荐的分步路线是：先用一两台跑通模型和业务逻辑，确定真实需求后，再评估是不是真的要上多机集群。如果决定要上，就从 2 台开始，逐步扩展到 4 台、8 台，每一步都做好验证和记录。

踩过几次坑之后你会发现，集群真正考验的不是硬件本身，而是网络、存储、调度和运维这几件看起来不太起眼的事。