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 倍。实际不是。集群要真正产生价值必须解决三件事网络通信。多台机器要交换模型权重、中间激活值通信带宽不够性能会直线下降。调度。谁的任务跑到哪台机器上一台机器满了怎么办任务失败要不要重试都需要调度器处理。存储一致性。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 --nodes8 --ntasks-per-node1 --gpus-per-node1 python run_inference.pySlurm 的好处是概念简单、文档多、社区成熟非常适合 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 性能判断看吞吐、延迟、资源利用率和成功率集群部署完之后最忌讳只跑一个用例就说“成功了”。我建议至少从四个维度做验收吞吐并发请求下每秒处理的 token 数是否达到预期。时延首 token 延迟和完整输出延迟是否稳定有没有偶发的高延迟。资源利用率查看每台机器的显存利用率、GPU 利用率、网络带宽占用。成功率连续跑 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 台每一步都做好验证和记录。踩过几次坑之后你会发现集群真正考验的不是硬件本身而是网络、存储、调度和运维这几件看起来不太起眼的事。