之前关注 NVIDIA DGX Spark 的时候大多数人讨论的都是“单台能跑什么模型”“本地部署怎么配”。真正把多台 DGX Spark 组到一起当成一个小型 AI 集群来用的资料其实非常少。正好最近看到 Alex Ziskind 关于组装 8 台 DGX Spark 集群的内容踩了不少网络、存储和调度上的坑这里结合我自己的实践和理解整理一份完整的多机 DGX Spark 集群搭建笔记。内容包括为什么要组集群、网络怎么规划、集群调度选哪种方案、多节点推理和大模型分布式部署怎么做以及真实场景下最容易被忽视的性能瓶颈。如果你手里已经有一台 DGX Spark正在犹豫要不要加机器或者你已经在考虑用几台 Spark 替代一台大 GPU 服务器那么这篇文章应该能帮你少走很多弯路。1. 为什么要组多台 DGX Spark 集群1.1 单台 DGX Spark 的边界在哪里DGX Spark 是一台面向桌面的 AI 超级计算机外观体积不大但内部集成了 Grace Blackwell 平台。单机拥有约 128GB 统一内存可以本地运行一些中等规模的模型。对很多开发者来说单台 Spark 已经能覆盖日常的模型微调、RAG 原型验证和百亿级参数模型的推理实验。但单台机器的算力天花板是清晰存在的。当你需要部署 200B 级别的大模型或者同时让多个团队共享训练资源时单机 128GB 内存和单卡算力就不够用了。模型中转参数、KV Cache、多路并发请求都会快速吃满内存。此时要么买更高规格的服务器要么把多台 DGX Spark 组成集群。1.2 组集群解决的是什么问题把多台 DGX Spark 连起来本质上解决三个问题第一是内存池化。大模型推理时模型权重和中间激活都需要驻留在内存里。单台 128GB跑 70B 模型已经比较紧张跑 200B 模型几乎不可能。多台机器的内存加在一起总量能达到 1TB 级别这就有条件去部署超大模型。第二是算力扩展。单台 DGX Spark 的推理吞吐量有限并发用户一多就会排队。多台机器可以分担流量或者通过张量并行让单请求的推理延迟下降。第三是资源调度。如果团队成员都在用模型每个人各自占一台机器效率很低。组集群之后可以像用数据中心一样按任务申请 GPU 和内存资源跑完自动释放。1.3 和小型 GPU 服务器相比DGX Spark 集群的定位有人会问既然要组集群为什么不直接买一台 8 卡的 H100 或者 4090 工作站DGX Spark 集群的优势在于功耗、体积和开发体验。单台 Spark 的功耗比传统 GPU 服务器低很多而且采用统一内存架构对开发者来说更像一台“模型电脑”而不是需要专门运维的服务器。当然8 台 DGX Spark 的互联带宽和单卡 A100/H100 的 NVLink 相比还是有差距。所以它更适合中小型团队、AI 应用开发者、高校实验室用来做模型推理、微调实验和中小规模并行训练。如果业务对训练吞吐要求极高建议还是选择专用 AI 服务器。2. 组网方案集群性能的胜负手2.1 DGX Spark 的互联能力组集群第一步是解决网络。DGX Spark 官方支持通过 ConnectX 网卡互联而且设计了专门的集群模式。单台 DGX Spark 除了常规的万兆以太网口还具备高速互联接口可以支持多机之间高带宽、低延迟通信。需要特别提醒的是不要把 DGX Spark 集群的“互联”理解成普通千兆交换机组成的局域网。如果你只是用普通网线把所有机器接到一台千兆交换机上那么就算机器再多大模型分布式推理也会卡在通信上。NCCL 在 AllReduce 和 AllGather 阶段会对网络带宽极其敏感带宽不足时集群的算力扩展比甚至会出现负数——多台机器比单机更慢。2.2 推荐网络拓扑对于 8 台 DGX Spark我建议采用如下拓扑每台 DGX Spark 使用高速网卡接入一台支持 RoCERDMA over Converged Ethernet的数据中心交换机。管理网络使用千兆或万兆以太网独立跑 SSH、监控、存储同步避免与分布式训练流量互相干扰。如果预算允许最好准备两台交换机做冗余或者在配置中启用链路聚合。从软件角度看RDMA 能显著降低通信延迟。NCCL 检测到 RDMA 可用时会优先走 RDMA 通道如果没有 RDMANCCL 会退回到 TCP/IP性能下降非常明显。2.3 网络配置清单下面是一个最小化的网络配置检查清单项目推荐配置说明交换机支持 RoCE 的数据中心交换机至少 25G/100G 端口预留扩展网卡NVIDIA ConnectX 系列DGX Spark 集群模式推荐IP 规划每台机器分配固定 IP建议写入 /etc/hosts方便 NCCL 解析防火墙开放 SSH、NCCL 通信端口分布式训练时 NCCL 会动态选择端口存储独立 NAS 或分布式存储避免模型文件反复拷贝占用网络带宽NCCL 通信端口是一个容易被忽略的点。集群中多机训练时NCCL 会使用一系列的 TCP 端口如果防火墙没有放行就会造成连接超时。最简单的做法是在测试环境放行全部内网端口确认成功后再收敛到具体端口范围。3. 集群软件栈选型K8s 还是裸机调度3.1 快速理解集群调度硬件连好之后下一步是决定用什么软件把 8 台机器管起来。最简单的方案是把每台机器都装上同样的环境手动 SSH 登录到不同机器跑任务。但这样做的坏处很明显资源利用率低任务冲突时没有排队机制也无法统计每一台机器的 GPU 和内存占用。所以需要引入集群调度。常见的方案有两类一类是 Kubernetes。它是目前最主流的容器编排平台配合 NVIDIA GPU Operator、Device Plugin可以实现 GPU 资源调度。你可以把每个推理任务封装成 PodKubernetes 会分配机器、挂载存储、设置环境变量并且在任务结束后自动清理。另一类是传统 HPC 调度器比如 Slurm。Slurm 对分布式训练任务支持非常成熟很多 AI 实验室和超算中心都在用。它比 Kubernetes 更轻量适合固定的用户组和队列管理。如果你的目标是长期运行在线推理服务Kubernetes 更合适如果目标是跑一批批的离线训练和评测任务Slurm 会更顺手。3.2 在 DGX Spark 上部署 Kubernetes 的要点在 DGX Spark 上部署 Kubernetes 与传统服务器并没有本质区别但有三个特殊点需要注意。第一个是 GPU 调度。默认情况下Kubernetes 不认识 DGX Spark 里的加速器。你需要安装 NVIDIA GPU Operator它会自动部署 Device Plugin、DCGM 监控和驱动组件。安装完成之后Pod 可以通过nvidia.com/gpu资源字段申请加速器。第二个是 RDMA 网络。要让容器内跑起来的训练任务也能享受到 RDMA 高速网络需要部署 RDMA Shared Device Plugin并且把主机上的网卡设备映射进容器。这部分的配置顺序通常是先确认物理机 NCCL 通信正常再容器化最后再上 Kubernetes。如果直接跳到 Kubernetes出问题时会很难排查。第三个是存储共享。多机训练通常需要所有节点读取同一份数据集和模型文件。你可以在 Kubernetes 里用 NFS Provisioner 挂载一个共享存储也可以部署 MinIO 或 GlusterFS 这类分布式存储。简单总结Kubernetes 方案适合希望把集群当成一个小型内部云平台来用的团队虽然前期部署略显繁琐但后面使用体验很顺滑。4. 多机大模型推理从单机到多机4.1 张量并行与流水线并行的选择组完集群我猜大部分人的目标和我一样让多台 DGX Spark 一起跑一个大模型。这里需要先理解大模型并行推理的两种常用方式。张量并行Tensor Parallel是把一个模型的权重切分到多张 GPU 上。每一层被切成多份分别放在不同机器上前向推理时每个 Transformer 层都需要多机通信。这种并行方式能显著降低单机显存压力但对互联带宽要求很高。流水线并行Pipeline Parallelism是把模型的不同层切分到不同机器上。第 1 层到第 10 层放在机器 A第 11 层到第 20 层放在机器 B。通信频率低于张量并行但并行效率受层间依赖影响容易产生流水线气泡。对于 70B 级别模型如果只有 2 台 DGX Spark我建议优先尝试张量并行加数据并行的组合。如果是 8 台机器跑 200B 以上大模型那么张量并行 流水线并行的混合模式更现实。4.2 推理框架选型vLLM Ray目前最常用的多机推理框架组合是 vLLM Ray。Ray 负责跨节点的资源调度和分布式运行时启动。vLLM 在 Ray 之上启动分布式推理引擎。vLLM 通过tensor_parallel_size参数指定参与张量并行的 GPU 数量当这个值大于单机 GPU 数时vLLM 会自动使用 Ray 进行跨节点通信。安装时建议在每台机器上创建同一个 Python 虚拟环境并安装相同版本的依赖。版本不一致是分布式推理中非常隐蔽的坑有时候两台机器都能单独启动服务但合在一起就报版本不兼容。4.3 两台 DGX Spark 跑 70B 模型能有多少吞吐网上有人讨论“两台 DGX Spark 张量并行跑 70B 模型单并发输出多少 token”这里分享一个粗略的估算思路。70B 模型在常见的精度下权重约需要 70GB 到 140GB。两台 DGX Spark 合计 256GB 统一内存能装下模型权重同时还能留出一部分空间给 KV Cache。推理解码阶段主要受内存带宽限制而不是纯算力限制。根据 DGX Spark 的内存带宽规格两台机器张量并行后带宽约等于两倍单机带宽但跨机通信会带来额外开销。在最优情况下单并发的输出速度可能达到每秒几 token 到十几 token 的水平具体数值和模型量化方式、上下文长度、通信链路质量都有关系。如果你的目标是高并发在线服务建议先做压测再决定是否继续加机器。4.4 用 vLLM 启动多机推理下面是一个基于 Ray 和 vLLM 的多机推理启动思路。假设你已经准备了一台主节点和若干台工作节点。首先启动 Ray 集群# 在主节点执行 ray start --head --port6379 --dashboard-host0.0.0.0 # 在工作节点执行替换为你的主节点 IP ray start --address192.168.1.10:6379然后写一个 vLLM 启动脚本通过环境变量指定模型路径和张量并行大小# 文件路径infer_70b.py import os from vllm import LLM, SamplingParams os.environ[NCCL_DEBUG] INFO os.environ[NCCL_SOCKET_IFNAME] eth0 llm LLM( model/models/Qwen2.5-70B, tensor_parallel_size8, dtypebfloat16, gpu_memory_utilization0.85, distributed_executor_backendray, ) sampling_params SamplingParams(temperature0.7, max_tokens1024) prompts [请介绍一下分布式训练的常见策略。] outputs llm.generate(prompts, sampling_params) for output in outputs: print(output.outputs[0].text)脚本执行时vLLM 会通过 Ray 在 8 台 DGX Spark 上启动分布式 worker。需要注意的NCCL_SOCKET_IFNAME要改成你实际规划的训练网卡名称否则 NCCL 可能选错网卡导致通信走了慢速管理网络。5. 8 台集群实战部署一套小型 AI 推理平台5.1 整体架构规划接下来我们做一个完整的实战规划用 8 台 DGX Spark 组成一个小型 AI 推理平台对外提供统一的 API 服务。整体架构分为四层接入层1 台机器上部署 Nginx 或 API Gateway负责请求分发。调度层Kubernetes 集群负责 Pod 调度和生命周期管理。推理层vLLM 推理服务运行在 GPU 节点上。存储层MinIO 保存模型文件NFS 提供共享缓存。对于 8 台机器我建议其中 1 台承担控制节点和存储节点其余 7 台作为计算节点。如果业务量不大也可以让控制节点同时跑推理任务。5.2 基础环境初始化每台 DGX Spark 执行同样的初始化操作sudo apt update sudo apt upgrade -y sudo apt install -y docker.io nfs-common # 安装 NVIDIA 容器工具包 distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/libnvidia-container.list sudo apt update sudo apt install -y nvidia-container-toolkit sudo systemctl restart dockerDocker 安装后需要在/etc/docker/daemon.json中配置默认运行时{ default-runtime: nvidia, runtimes: { nvidia: { path: nvidia-container-runtime, runtimeArgs: [] } } }配置完成后重启 Docker然后运行一个测试容器确认 GPU 是否可见sudo docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi如果能看到 8 台机器都正常输出 GPU 信息说明基础环境已经就绪。5.3 部署 MinIO 统一存储模型文件通常很大如果每台机器都拷贝一份原始权重既不现实也浪费磁盘。这里用 MinIO 做对象存储然后在计算节点下载模型到本地 NVMe 作为缓存。MinIO 部署有两种方式单机模式和分布式模式。对于 8 台 DGX Spark 的规模我建议先在控制节点部署 MinIO后面如果存储成为瓶颈再升级为分布式 MinIO 集群。启动 MinIO 的命令如下mkdir -p /data/minio docker run -d \ --name minio \ -p 9000:9000 \ -p 9001:9001 \ -v /data/minio:/data \ -e MINIO_ROOT_USERadmin \ -e MINIO_ROOT_PASSWORDyour-strong-password \ minio/minio server /data --console-address :9001模型文件上传后可以在计算节点上用mc工具同步。为了方便容器内访问建议把 MinIO Endpoint 写入 Kubernetes ConfigMap。5.4 部署 Kubernetes 与 GPU 调度组件控制节点初始化集群sudo kubeadm init --pod-network-cidr10.244.0.0/16安装 CNI 网络插件和 GPU 组件。这里重点提一下完成 K8s 基础安装之后一定要确认 GPU 资源已经暴露给节点而不是只看到 CPU 和内存。安装 GPU Operator 是目前最省心的方式helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm repo update helm install gpu-operator nvidia/gpu-operator --wait安装完成后查看节点资源kubectl get nodes -o custom-columnsNAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu如果每台计算节点都显示1说明 GPU 调度已经生效。5.5 启动多节点 vLLM 推理服务在 Kubernetes 中以多副本方式部署 vLLM 服务。每个副本通过tensor_parallel_size使用多张 GPU。以 8 台 DGX Spark 为例如果希望一个推理任务占用全部 8 卡配置如下# 文件路径vllm-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: vllm-70b spec: replicas: 1 selector: matchLabels: app: vllm template: metadata: labels: app: vllm spec: containers: - name: vllm image: vllm/vllm-openai:latest command: [python3, -m, vllm.entrypoints.openai.api_server] args: - --model - /models/Qwen2.5-70B - --tensor-parallel-size - 8 - --host - 0.0.0.0 - --port - 8000 resources: limits: nvidia.com/gpu: 8 volumeMounts: - name: model-cache mountPath: /models volumes: - name: model-cache hostPath: path: /models这里nvidia.com/gpu: 8表示这个 Pod 需要 8 张 GPUKubernetes 会自动把 Pod 调度到 GPU 总量足够满足 8 卡的节点组合上。由于 8 台 DGX Spark 每台只有 1 个加速器这个 8 卡请求实际上会被调度到多个节点vLLM 通过 Ray 完成跨节点通信。启动后通过 Service 暴露服务apiVersion: v1 kind: Service metadata: name: vllm-service spec: selector: app: vllm ports: - port: 8000 targetPort: 8000 type: NodePort测试调用curl -X POST http://node-ip:30000/v1/completions \ -H Content-Type: application/json \ -d { model: /models/Qwen2.5-70B, prompt: Kubernetes 在 AI 推理中的优势是什么, max_tokens: 256 }5.6 运行结果与观察要点正常情况下会返回一段完整文本和token数量。此时我们更关心的是性能指标。建议查看以下内容部署日志中是否有NCCL Version和distributed init输出。vLLM 日志中显示的Throughput是否随节点数线性增长。nvidia-smi 中每台 DGX Spark 的显存占用和利用率。交换机端口流量确认训练网卡带宽是否被跑满。如果Throughput不升反降大概率是网络通信瓶颈需要从网卡选择、防火墙和 NCCL 环境变量三个方向排查。6. 常见问题与排查思路6.1 多机通信超时问题现象常见原因解决思路启动时卡在 NCCL 初始化防火墙未放行 NCCL 端口临时放行全部内网端口确认正常后收敛报错connect timed out机器之间的 hosts 解析失败在 /etc/hosts 中配置所有节点 IP 和主机名多机通信极慢NCCL 选了错误网卡设置NCCL_SOCKET_IFNAME指向高速网卡6.2 显卡资源调度异常问题现象常见原因解决思路Pod 一直 PendingGPU 资源不足检查节点是否被其他 Pod 占满节点没有 nvidia.com/gpu 资源GPU Operator 未正确安装查看 gpu-operator Pod 日志确认驱动匹配容器内 nvidia-smi 不存在镜像缺少 CUDA 运行库更换为标准 CUDA 镜像6.3 大模型推理 OOM问题现象常见原因解决思路加载权重时 OOM模型精度过高尝试 8bit 或 4bit 量化推理过程中 OOMKV Cache 占用过大降低gpu_memory_utilization限制 max-model-len并发高时 OOM并发请求超出可分配显存在接入层配置限流和队列6.4 性能扩展比低多机集群最常见的问题是“加了机器速度没怎么变”。排查顺序如下第一步检查单机性能基线。先用一台 DGX Spark 跑同样的模型记录吞吐。第二步检查通信带宽。在两台机器之间用ib_write_bw或iperf3测试网络确认实际带宽与预期一致。第三步调整并行策略。如果通信成为瓶颈可以尝试增大 batch size、降低通信频率或改用流水线并行减少跨节点通信量。第四步检查 CPU 是否成为瓶颈。DGX Spark 的加速能力很强但数据预处理、tokenization、解码如果在 CPU 上执行会拖慢整体推理速度。建议把 tokenizer 等操作放到后台线程池中。7. 最佳实践与工程建议7.1 网络永远值得优先投入多台 DGX Spark 组集群成败主要在网络上。普通千兆网可以跑通 demo但不适合生产。如果条件允许尽量选用支持 RoCE 的交换机和 ConnectX 网卡并且在组网初期就完成 RDMA 连通性测试。另外建议把管理网络和训练网络分开。管理网络跑 SSH、监控和镜像拉取训练网络专门跑 NCCL 通信。两条网络不分开训练高峰时管理操作会变得卡顿遇到问题想登录机器排查都难。7.2 环境一致性要规范化管理多机集群的灾难往往来自“环境漂移”。机器 A 的 Python 是 3.10机器 B 是 3.11机器 A 的 CUDA 版本和机器 B 不一致。平时单机用没什么感觉一旦进入分布式训练各种诡异报错就会出现。建议把所有节点的基础环境做成镜像或者 Ansible Playbook。每次新节点加入集群时先执行统一的初始化脚本再跑一个简单的分布式测试确认环境一致后才允许加入生产集群。7.3 使用监控与告警8 台机器组成的集群虽然规模不大但故障影响范围也不小。建议部署 Prometheus 和 Grafana关注三个指标每台 DGX Spark 的温度与功耗。网络端口流量和丢包率。推理服务的请求成功率与 P95 延迟。当监控发现某台机器性能异常时可以提前排查避免影响整个集群的稳定性。7.4 模型文件管理模型文件建议使用对象存储保存并按版本目录组织/models/ Qwen2.5-70B/ v1/ v2/ Llama-3.1-405B/计算节点启动时通过标签选择需要加载的模型版本。这样一方面方便回滚另一方面也减少了不同团队之间覆盖文件的风险。7.5 生产环境变更保持谨慎如果这个 DGX Spark 集群承载的是团队内的正式业务那么任何变更都要遵循测试流程。尤其是涉及驱动升级、NCCL 版本、Kubernetes 组件升级的时候建议先在 2 台机器组成的测试集群上验证确认稳定后再全量更新。DGX Spark 集群的运维和传统 GPU 服务器集群相比门槛其实更低但风险控制思路完全一致小步变更、可回滚、有备份。8. 最后想说的话8 台 DGX Spark 组成的集群放在个人开发者面前是一套很奢侈的实验环境放在小型团队里则是一套可行的 AI 基础设施。它的价值不在于“8 台机器听起来很酷”而在于你能够在一套统一的管理平台上按需分配 CPU、内存、加速器和模型资源把原来各自为战的单机环境整合成真正可共享、可扩展的算力池。从我自己的经验来看组建这套集群最耗时间的不是插线接线也不是安装 CUDA而是理解分布式推理的通信模式以及接受“硬件堆起来不等于性能翻倍”这个事实。每加一台机器都要重新评估网络、存储和并行策略是否匹配。如果你手头正好有两台 DGX Spark可以先尝试用 vLLM Ray 跑一个 70B 模型把分布式推理链路跑通再慢慢加机器。毕竟先让两台机器稳定协作比盲目追求 8 台机器更有意义。 8台DGX Spark组集群实战：网络、调度与多机推理全攻略
之前关注 NVIDIA DGX Spark 的时候大多数人讨论的都是“单台能跑什么模型”“本地部署怎么配”。真正把多台 DGX Spark 组到一起当成一个小型 AI 集群来用的资料其实非常少。正好最近看到 Alex Ziskind 关于组装 8 台 DGX Spark 集群的内容踩了不少网络、存储和调度上的坑这里结合我自己的实践和理解整理一份完整的多机 DGX Spark 集群搭建笔记。内容包括为什么要组集群、网络怎么规划、集群调度选哪种方案、多节点推理和大模型分布式部署怎么做以及真实场景下最容易被忽视的性能瓶颈。如果你手里已经有一台 DGX Spark正在犹豫要不要加机器或者你已经在考虑用几台 Spark 替代一台大 GPU 服务器那么这篇文章应该能帮你少走很多弯路。1. 为什么要组多台 DGX Spark 集群1.1 单台 DGX Spark 的边界在哪里DGX Spark 是一台面向桌面的 AI 超级计算机外观体积不大但内部集成了 Grace Blackwell 平台。单机拥有约 128GB 统一内存可以本地运行一些中等规模的模型。对很多开发者来说单台 Spark 已经能覆盖日常的模型微调、RAG 原型验证和百亿级参数模型的推理实验。但单台机器的算力天花板是清晰存在的。当你需要部署 200B 级别的大模型或者同时让多个团队共享训练资源时单机 128GB 内存和单卡算力就不够用了。模型中转参数、KV Cache、多路并发请求都会快速吃满内存。此时要么买更高规格的服务器要么把多台 DGX Spark 组成集群。1.2 组集群解决的是什么问题把多台 DGX Spark 连起来本质上解决三个问题第一是内存池化。大模型推理时模型权重和中间激活都需要驻留在内存里。单台 128GB跑 70B 模型已经比较紧张跑 200B 模型几乎不可能。多台机器的内存加在一起总量能达到 1TB 级别这就有条件去部署超大模型。第二是算力扩展。单台 DGX Spark 的推理吞吐量有限并发用户一多就会排队。多台机器可以分担流量或者通过张量并行让单请求的推理延迟下降。第三是资源调度。如果团队成员都在用模型每个人各自占一台机器效率很低。组集群之后可以像用数据中心一样按任务申请 GPU 和内存资源跑完自动释放。1.3 和小型 GPU 服务器相比DGX Spark 集群的定位有人会问既然要组集群为什么不直接买一台 8 卡的 H100 或者 4090 工作站DGX Spark 集群的优势在于功耗、体积和开发体验。单台 Spark 的功耗比传统 GPU 服务器低很多而且采用统一内存架构对开发者来说更像一台“模型电脑”而不是需要专门运维的服务器。当然8 台 DGX Spark 的互联带宽和单卡 A100/H100 的 NVLink 相比还是有差距。所以它更适合中小型团队、AI 应用开发者、高校实验室用来做模型推理、微调实验和中小规模并行训练。如果业务对训练吞吐要求极高建议还是选择专用 AI 服务器。2. 组网方案集群性能的胜负手2.1 DGX Spark 的互联能力组集群第一步是解决网络。DGX Spark 官方支持通过 ConnectX 网卡互联而且设计了专门的集群模式。单台 DGX Spark 除了常规的万兆以太网口还具备高速互联接口可以支持多机之间高带宽、低延迟通信。需要特别提醒的是不要把 DGX Spark 集群的“互联”理解成普通千兆交换机组成的局域网。如果你只是用普通网线把所有机器接到一台千兆交换机上那么就算机器再多大模型分布式推理也会卡在通信上。NCCL 在 AllReduce 和 AllGather 阶段会对网络带宽极其敏感带宽不足时集群的算力扩展比甚至会出现负数——多台机器比单机更慢。2.2 推荐网络拓扑对于 8 台 DGX Spark我建议采用如下拓扑每台 DGX Spark 使用高速网卡接入一台支持 RoCERDMA over Converged Ethernet的数据中心交换机。管理网络使用千兆或万兆以太网独立跑 SSH、监控、存储同步避免与分布式训练流量互相干扰。如果预算允许最好准备两台交换机做冗余或者在配置中启用链路聚合。从软件角度看RDMA 能显著降低通信延迟。NCCL 检测到 RDMA 可用时会优先走 RDMA 通道如果没有 RDMANCCL 会退回到 TCP/IP性能下降非常明显。2.3 网络配置清单下面是一个最小化的网络配置检查清单项目推荐配置说明交换机支持 RoCE 的数据中心交换机至少 25G/100G 端口预留扩展网卡NVIDIA ConnectX 系列DGX Spark 集群模式推荐IP 规划每台机器分配固定 IP建议写入 /etc/hosts方便 NCCL 解析防火墙开放 SSH、NCCL 通信端口分布式训练时 NCCL 会动态选择端口存储独立 NAS 或分布式存储避免模型文件反复拷贝占用网络带宽NCCL 通信端口是一个容易被忽略的点。集群中多机训练时NCCL 会使用一系列的 TCP 端口如果防火墙没有放行就会造成连接超时。最简单的做法是在测试环境放行全部内网端口确认成功后再收敛到具体端口范围。3. 集群软件栈选型K8s 还是裸机调度3.1 快速理解集群调度硬件连好之后下一步是决定用什么软件把 8 台机器管起来。最简单的方案是把每台机器都装上同样的环境手动 SSH 登录到不同机器跑任务。但这样做的坏处很明显资源利用率低任务冲突时没有排队机制也无法统计每一台机器的 GPU 和内存占用。所以需要引入集群调度。常见的方案有两类一类是 Kubernetes。它是目前最主流的容器编排平台配合 NVIDIA GPU Operator、Device Plugin可以实现 GPU 资源调度。你可以把每个推理任务封装成 PodKubernetes 会分配机器、挂载存储、设置环境变量并且在任务结束后自动清理。另一类是传统 HPC 调度器比如 Slurm。Slurm 对分布式训练任务支持非常成熟很多 AI 实验室和超算中心都在用。它比 Kubernetes 更轻量适合固定的用户组和队列管理。如果你的目标是长期运行在线推理服务Kubernetes 更合适如果目标是跑一批批的离线训练和评测任务Slurm 会更顺手。3.2 在 DGX Spark 上部署 Kubernetes 的要点在 DGX Spark 上部署 Kubernetes 与传统服务器并没有本质区别但有三个特殊点需要注意。第一个是 GPU 调度。默认情况下Kubernetes 不认识 DGX Spark 里的加速器。你需要安装 NVIDIA GPU Operator它会自动部署 Device Plugin、DCGM 监控和驱动组件。安装完成之后Pod 可以通过nvidia.com/gpu资源字段申请加速器。第二个是 RDMA 网络。要让容器内跑起来的训练任务也能享受到 RDMA 高速网络需要部署 RDMA Shared Device Plugin并且把主机上的网卡设备映射进容器。这部分的配置顺序通常是先确认物理机 NCCL 通信正常再容器化最后再上 Kubernetes。如果直接跳到 Kubernetes出问题时会很难排查。第三个是存储共享。多机训练通常需要所有节点读取同一份数据集和模型文件。你可以在 Kubernetes 里用 NFS Provisioner 挂载一个共享存储也可以部署 MinIO 或 GlusterFS 这类分布式存储。简单总结Kubernetes 方案适合希望把集群当成一个小型内部云平台来用的团队虽然前期部署略显繁琐但后面使用体验很顺滑。4. 多机大模型推理从单机到多机4.1 张量并行与流水线并行的选择组完集群我猜大部分人的目标和我一样让多台 DGX Spark 一起跑一个大模型。这里需要先理解大模型并行推理的两种常用方式。张量并行Tensor Parallel是把一个模型的权重切分到多张 GPU 上。每一层被切成多份分别放在不同机器上前向推理时每个 Transformer 层都需要多机通信。这种并行方式能显著降低单机显存压力但对互联带宽要求很高。流水线并行Pipeline Parallelism是把模型的不同层切分到不同机器上。第 1 层到第 10 层放在机器 A第 11 层到第 20 层放在机器 B。通信频率低于张量并行但并行效率受层间依赖影响容易产生流水线气泡。对于 70B 级别模型如果只有 2 台 DGX Spark我建议优先尝试张量并行加数据并行的组合。如果是 8 台机器跑 200B 以上大模型那么张量并行 流水线并行的混合模式更现实。4.2 推理框架选型vLLM Ray目前最常用的多机推理框架组合是 vLLM Ray。Ray 负责跨节点的资源调度和分布式运行时启动。vLLM 在 Ray 之上启动分布式推理引擎。vLLM 通过tensor_parallel_size参数指定参与张量并行的 GPU 数量当这个值大于单机 GPU 数时vLLM 会自动使用 Ray 进行跨节点通信。安装时建议在每台机器上创建同一个 Python 虚拟环境并安装相同版本的依赖。版本不一致是分布式推理中非常隐蔽的坑有时候两台机器都能单独启动服务但合在一起就报版本不兼容。4.3 两台 DGX Spark 跑 70B 模型能有多少吞吐网上有人讨论“两台 DGX Spark 张量并行跑 70B 模型单并发输出多少 token”这里分享一个粗略的估算思路。70B 模型在常见的精度下权重约需要 70GB 到 140GB。两台 DGX Spark 合计 256GB 统一内存能装下模型权重同时还能留出一部分空间给 KV Cache。推理解码阶段主要受内存带宽限制而不是纯算力限制。根据 DGX Spark 的内存带宽规格两台机器张量并行后带宽约等于两倍单机带宽但跨机通信会带来额外开销。在最优情况下单并发的输出速度可能达到每秒几 token 到十几 token 的水平具体数值和模型量化方式、上下文长度、通信链路质量都有关系。如果你的目标是高并发在线服务建议先做压测再决定是否继续加机器。4.4 用 vLLM 启动多机推理下面是一个基于 Ray 和 vLLM 的多机推理启动思路。假设你已经准备了一台主节点和若干台工作节点。首先启动 Ray 集群# 在主节点执行 ray start --head --port6379 --dashboard-host0.0.0.0 # 在工作节点执行替换为你的主节点 IP ray start --address192.168.1.10:6379然后写一个 vLLM 启动脚本通过环境变量指定模型路径和张量并行大小# 文件路径infer_70b.py import os from vllm import LLM, SamplingParams os.environ[NCCL_DEBUG] INFO os.environ[NCCL_SOCKET_IFNAME] eth0 llm LLM( model/models/Qwen2.5-70B, tensor_parallel_size8, dtypebfloat16, gpu_memory_utilization0.85, distributed_executor_backendray, ) sampling_params SamplingParams(temperature0.7, max_tokens1024) prompts [请介绍一下分布式训练的常见策略。] outputs llm.generate(prompts, sampling_params) for output in outputs: print(output.outputs[0].text)脚本执行时vLLM 会通过 Ray 在 8 台 DGX Spark 上启动分布式 worker。需要注意的NCCL_SOCKET_IFNAME要改成你实际规划的训练网卡名称否则 NCCL 可能选错网卡导致通信走了慢速管理网络。5. 8 台集群实战部署一套小型 AI 推理平台5.1 整体架构规划接下来我们做一个完整的实战规划用 8 台 DGX Spark 组成一个小型 AI 推理平台对外提供统一的 API 服务。整体架构分为四层接入层1 台机器上部署 Nginx 或 API Gateway负责请求分发。调度层Kubernetes 集群负责 Pod 调度和生命周期管理。推理层vLLM 推理服务运行在 GPU 节点上。存储层MinIO 保存模型文件NFS 提供共享缓存。对于 8 台机器我建议其中 1 台承担控制节点和存储节点其余 7 台作为计算节点。如果业务量不大也可以让控制节点同时跑推理任务。5.2 基础环境初始化每台 DGX Spark 执行同样的初始化操作sudo apt update sudo apt upgrade -y sudo apt install -y docker.io nfs-common # 安装 NVIDIA 容器工具包 distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/libnvidia-container.list sudo apt update sudo apt install -y nvidia-container-toolkit sudo systemctl restart dockerDocker 安装后需要在/etc/docker/daemon.json中配置默认运行时{ default-runtime: nvidia, runtimes: { nvidia: { path: nvidia-container-runtime, runtimeArgs: [] } } }配置完成后重启 Docker然后运行一个测试容器确认 GPU 是否可见sudo docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi如果能看到 8 台机器都正常输出 GPU 信息说明基础环境已经就绪。5.3 部署 MinIO 统一存储模型文件通常很大如果每台机器都拷贝一份原始权重既不现实也浪费磁盘。这里用 MinIO 做对象存储然后在计算节点下载模型到本地 NVMe 作为缓存。MinIO 部署有两种方式单机模式和分布式模式。对于 8 台 DGX Spark 的规模我建议先在控制节点部署 MinIO后面如果存储成为瓶颈再升级为分布式 MinIO 集群。启动 MinIO 的命令如下mkdir -p /data/minio docker run -d \ --name minio \ -p 9000:9000 \ -p 9001:9001 \ -v /data/minio:/data \ -e MINIO_ROOT_USERadmin \ -e MINIO_ROOT_PASSWORDyour-strong-password \ minio/minio server /data --console-address :9001模型文件上传后可以在计算节点上用mc工具同步。为了方便容器内访问建议把 MinIO Endpoint 写入 Kubernetes ConfigMap。5.4 部署 Kubernetes 与 GPU 调度组件控制节点初始化集群sudo kubeadm init --pod-network-cidr10.244.0.0/16安装 CNI 网络插件和 GPU 组件。这里重点提一下完成 K8s 基础安装之后一定要确认 GPU 资源已经暴露给节点而不是只看到 CPU 和内存。安装 GPU Operator 是目前最省心的方式helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm repo update helm install gpu-operator nvidia/gpu-operator --wait安装完成后查看节点资源kubectl get nodes -o custom-columnsNAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu如果每台计算节点都显示1说明 GPU 调度已经生效。5.5 启动多节点 vLLM 推理服务在 Kubernetes 中以多副本方式部署 vLLM 服务。每个副本通过tensor_parallel_size使用多张 GPU。以 8 台 DGX Spark 为例如果希望一个推理任务占用全部 8 卡配置如下# 文件路径vllm-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: vllm-70b spec: replicas: 1 selector: matchLabels: app: vllm template: metadata: labels: app: vllm spec: containers: - name: vllm image: vllm/vllm-openai:latest command: [python3, -m, vllm.entrypoints.openai.api_server] args: - --model - /models/Qwen2.5-70B - --tensor-parallel-size - 8 - --host - 0.0.0.0 - --port - 8000 resources: limits: nvidia.com/gpu: 8 volumeMounts: - name: model-cache mountPath: /models volumes: - name: model-cache hostPath: path: /models这里nvidia.com/gpu: 8表示这个 Pod 需要 8 张 GPUKubernetes 会自动把 Pod 调度到 GPU 总量足够满足 8 卡的节点组合上。由于 8 台 DGX Spark 每台只有 1 个加速器这个 8 卡请求实际上会被调度到多个节点vLLM 通过 Ray 完成跨节点通信。启动后通过 Service 暴露服务apiVersion: v1 kind: Service metadata: name: vllm-service spec: selector: app: vllm ports: - port: 8000 targetPort: 8000 type: NodePort测试调用curl -X POST http://node-ip:30000/v1/completions \ -H Content-Type: application/json \ -d { model: /models/Qwen2.5-70B, prompt: Kubernetes 在 AI 推理中的优势是什么, max_tokens: 256 }5.6 运行结果与观察要点正常情况下会返回一段完整文本和token数量。此时我们更关心的是性能指标。建议查看以下内容部署日志中是否有NCCL Version和distributed init输出。vLLM 日志中显示的Throughput是否随节点数线性增长。nvidia-smi 中每台 DGX Spark 的显存占用和利用率。交换机端口流量确认训练网卡带宽是否被跑满。如果Throughput不升反降大概率是网络通信瓶颈需要从网卡选择、防火墙和 NCCL 环境变量三个方向排查。6. 常见问题与排查思路6.1 多机通信超时问题现象常见原因解决思路启动时卡在 NCCL 初始化防火墙未放行 NCCL 端口临时放行全部内网端口确认正常后收敛报错connect timed out机器之间的 hosts 解析失败在 /etc/hosts 中配置所有节点 IP 和主机名多机通信极慢NCCL 选了错误网卡设置NCCL_SOCKET_IFNAME指向高速网卡6.2 显卡资源调度异常问题现象常见原因解决思路Pod 一直 PendingGPU 资源不足检查节点是否被其他 Pod 占满节点没有 nvidia.com/gpu 资源GPU Operator 未正确安装查看 gpu-operator Pod 日志确认驱动匹配容器内 nvidia-smi 不存在镜像缺少 CUDA 运行库更换为标准 CUDA 镜像6.3 大模型推理 OOM问题现象常见原因解决思路加载权重时 OOM模型精度过高尝试 8bit 或 4bit 量化推理过程中 OOMKV Cache 占用过大降低gpu_memory_utilization限制 max-model-len并发高时 OOM并发请求超出可分配显存在接入层配置限流和队列6.4 性能扩展比低多机集群最常见的问题是“加了机器速度没怎么变”。排查顺序如下第一步检查单机性能基线。先用一台 DGX Spark 跑同样的模型记录吞吐。第二步检查通信带宽。在两台机器之间用ib_write_bw或iperf3测试网络确认实际带宽与预期一致。第三步调整并行策略。如果通信成为瓶颈可以尝试增大 batch size、降低通信频率或改用流水线并行减少跨节点通信量。第四步检查 CPU 是否成为瓶颈。DGX Spark 的加速能力很强但数据预处理、tokenization、解码如果在 CPU 上执行会拖慢整体推理速度。建议把 tokenizer 等操作放到后台线程池中。7. 最佳实践与工程建议7.1 网络永远值得优先投入多台 DGX Spark 组集群成败主要在网络上。普通千兆网可以跑通 demo但不适合生产。如果条件允许尽量选用支持 RoCE 的交换机和 ConnectX 网卡并且在组网初期就完成 RDMA 连通性测试。另外建议把管理网络和训练网络分开。管理网络跑 SSH、监控和镜像拉取训练网络专门跑 NCCL 通信。两条网络不分开训练高峰时管理操作会变得卡顿遇到问题想登录机器排查都难。7.2 环境一致性要规范化管理多机集群的灾难往往来自“环境漂移”。机器 A 的 Python 是 3.10机器 B 是 3.11机器 A 的 CUDA 版本和机器 B 不一致。平时单机用没什么感觉一旦进入分布式训练各种诡异报错就会出现。建议把所有节点的基础环境做成镜像或者 Ansible Playbook。每次新节点加入集群时先执行统一的初始化脚本再跑一个简单的分布式测试确认环境一致后才允许加入生产集群。7.3 使用监控与告警8 台机器组成的集群虽然规模不大但故障影响范围也不小。建议部署 Prometheus 和 Grafana关注三个指标每台 DGX Spark 的温度与功耗。网络端口流量和丢包率。推理服务的请求成功率与 P95 延迟。当监控发现某台机器性能异常时可以提前排查避免影响整个集群的稳定性。7.4 模型文件管理模型文件建议使用对象存储保存并按版本目录组织/models/ Qwen2.5-70B/ v1/ v2/ Llama-3.1-405B/计算节点启动时通过标签选择需要加载的模型版本。这样一方面方便回滚另一方面也减少了不同团队之间覆盖文件的风险。7.5 生产环境变更保持谨慎如果这个 DGX Spark 集群承载的是团队内的正式业务那么任何变更都要遵循测试流程。尤其是涉及驱动升级、NCCL 版本、Kubernetes 组件升级的时候建议先在 2 台机器组成的测试集群上验证确认稳定后再全量更新。DGX Spark 集群的运维和传统 GPU 服务器集群相比门槛其实更低但风险控制思路完全一致小步变更、可回滚、有备份。8. 最后想说的话8 台 DGX Spark 组成的集群放在个人开发者面前是一套很奢侈的实验环境放在小型团队里则是一套可行的 AI 基础设施。它的价值不在于“8 台机器听起来很酷”而在于你能够在一套统一的管理平台上按需分配 CPU、内存、加速器和模型资源把原来各自为战的单机环境整合成真正可共享、可扩展的算力池。从我自己的经验来看组建这套集群最耗时间的不是插线接线也不是安装 CUDA而是理解分布式推理的通信模式以及接受“硬件堆起来不等于性能翻倍”这个事实。每加一台机器都要重新评估网络、存储和并行策略是否匹配。如果你手头正好有两台 DGX Spark可以先尝试用 vLLM Ray 跑一个 70B 模型把分布式推理链路跑通再慢慢加机器。毕竟先让两台机器稳定协作比盲目追求 8 台机器更有意义。