最近 NVIDIA DGX Spark 的热度一直很高很多人把它看作“桌面上跑大模型”的终极设备。不过单机归单机真正让我觉得有意思的是 Alex Ziskind 那个 8 台 DGX Spark 组集群的实验。8 台机器通过高速网络互联变成一个可以承载超大模型的本地推理集群这件事从纸面上看很有吸引力但实际搭起来到底要做什么、会遇到哪些坑大部分资料都没有讲透。本文就从“组 8 台 DGX Spark 集群”这个场景出发拆解集群的硬件基础、架构设计、软件选型、完整部署流程以及大家最关心的几个问题8 台机器到底能跑多大的模型多机并行后性能是否能线性扩展如果有一天你想在自己的机房或者实验室复现类似方案应该重点关注哪些环节1. 背景当桌面级 AI 超算开始组队1.1 为什么 DGX Spark 能成为讨论焦点DGX Spark 是 NVIDIA 面向 AI 开发者推出的紧凑型 AI 超级计算机它解决的痛点是“本地跑大模型不想完全依赖云端 API”。它的硬件基础是 Grace Blackwell 架构的超级芯片CPU 和 GPU 通过片内高速互联集成在一起并配备了 128GB 级别的统一内存。对大模型开发来说统一内存的吸引力非常大因为显存和内存之间不需要频繁拷贝数据大模型参数可以直接放进这个统一内存池里。相比传统 CPU独立 GPU 的架构它在跑大模型的场景下更省心也更省功耗。很多开发者在拿到机器第一天的感受是单台 DGX Spark 已经能比较流畅地跑 70B 级别的量化模型也能做一定程度的微调和 RAG 实验。这已经颠覆了以往“大模型必须上服务器”的认知。1.2 单机虽有惊喜但物理边界也很明显单机能够跑到什么程度取决于内存容量和芯片算力。虽然 128GB 统一内存在桌面级设备里已经算很大但模型参数一旦超过 100B单机就会变得吃力如果还要开长上下文、大批量并发推理内存带宽又会成为瓶颈。更关键的是单机无法解决多用户共享问题。团队里如果有多个人同时要跑模型一台机器很快就排队如果要做集群容错单机更是无从谈起。于是很自然的思路是把多台 DGX Spark 连起来组成一个小型 AI 集群。1.3 组集群的意义是什么组 8 台 DGX Spark 集群核心目标有三点扩大模型容量单机放不下的模型通过多节点张量并行切分到不同机器上。提升吞吐多节点并行可以为多个请求同时提供服务适合团队集中使用。资源调度通过 Kubernetes 等调度平台统一管理 GPU、内存、存储实现按需分配。Alex Ziskind 那个实验本质上就是把 8 台单机能力合并成一个逻辑上的“大 GPU”再在这块大 GPU 上运行更大规模的模型。这也是为什么这个话题能让集群工程师和 AI 工程师同时感兴趣的原因。2. 从单机到 8 机集群的核心能力评估2.1 单机规格与定位在讲集群之前先明确单机的定位。根据 DGX Spark 公开的硬件规格它的核心配置大致如下芯片Grace Blackwell 超级芯片CPU 与 GPU 通过 NVLink-C2C 互联。统一内存128GB 级别可被 CPU 和 GPU 共同访问。算力FP4 精度下达到 1000 TFLOPS 级别。网络板载高速网络接口支持 RDMA 能力适合多机互联。这样的配置决定了它适合作为“小规模模型推理节点”或者“集群中的一个计算单元”。需要注意的是DGX Spark 并不是一台传统意义上的 GPU 服务器它更强调低功耗、低噪音和易部署所以多台机器之间需要通过高速以太网或 InfiniBand 类网络互联来提高通信效率。2.2 单机承载模型的上限判断判断一台机器能跑多大模型最简单的方法是看参数占用的内存模型内存占用 ≈ 参数量 × 每个参数的字节数70B 模型FP16 精度下大约需要 140GB单机 128GB 放不下。70B 模型INT4/FP4 量化后大约需要 35GB 到 40GB单机可以放下。200B 模型INT4 量化后大约需要 100GB 到 110GB单机很紧张需要集群。这个估算方式同样适用于集群场景。多台机器组成集群后模型参数可以按层切分或者按张量维度切分到多台机器上这样单机内存压力就会大幅降低。2.3 集群扩展的收益与挑战理想情况下8 台 DGX Spark 集群能够提供的总内存接近 8 × 128GB也就是 1TB 级别。这意味着从容量上看跑 200B 甚至更大规模的量化模型是有可能的。但集群不是简单的“内存相加”还有两个关键挑战通信带宽多节点并行推理时每层计算都可能需要跨节点同步中间结果网络带宽和延迟直接决定扩展效率。调度与容错节点多了任何一台机器出现故障都会影响整体服务必须引入调度平台做健康检查和自动重启。所以在组集群之前先要把网络和调度这两件事想清楚。3. 8 台 DGX Spark 集群的整体架构3.1 网络拓扑设计集群组网是所有环节里最优先的一件事。8 台 DGX Spark 建议采用两层架构计算网络用于 GPU 之间 NCCL 通信要求高带宽、低延迟建议使用支持 RDMA 的高速交换机。管理网络用于 Kubernetes API、SSH、监控数据可以使用普通千兆或万兆交换机。计算网络和管理网络必须分离。如果让 NCCL 通信和管理流量跑在同一张网卡上模型并行训练或推理时很容易出现网络拥塞表现为 NCCL 超时、训练速度骤降。具体拓扑可以用下面这个简化图来理解[ DGX Spark 01 ] \ [ DGX Spark 02 ] \ [ DGX Spark 03 ] |--- 高速交换机RDMA --- 计算网络 [ DGX Spark 04 ] / [ DGX Spark 05 ] / [ DGX Spark 06 ] / [ DGX Spark 07 ] \ [ DGX Spark 08 ] \--- 管理交换机 --- 跳板机/管理节点如果你的交换机不支持 RDMA 或 RoCENCCL 会退化为 TCP 通信性能会明显下降。所以在采购设备时一定要确认交换机和网卡是否支持 RoCE v2 或 InfiniBand。3.2 共享存储设计大模型集群通常需要一个共享存储用来存放模型权重、数据集和日志。最简单的方案是 NFS把一台机器作为存储服务端其他机器作为客户端挂载。NFS 的优点是实现简单、兼容性好缺点是性能一般。如果只是存放模型文件和代码NFS 完全够用。如果训练时要频繁读取数据集建议把数据放在本地 NVMe 盘上或者使用并行文件系统如 Lustre、BeeGFS、GPFS。对于 8 台 DGX Spark 这个规模我的建议是先上 NFS遇到 I/O 瓶颈再考虑替换。3.3 软件栈选型集群软件栈是整个方案中最复杂也最容易踩坑的部分。参考目前主流的 AI 集群方案推荐如下组合操作系统每台 DGX Spark 已经预装 DGX OS基于 Ubuntu 定制这一层基本不用折腾。容器运行时 containerd 或 Docker。调度平台 Kubernetes。GPU 资源接入 NVIDIA Device Plugin让 Kubernetes 能够感知 GPU 资源。监控 DCGM Exporter Prometheus Grafana。存储 NFS通过 Kubernetes NFS Subdir External Provisioner 动态创建 PVC。推理框架 vLLM 或 TensorRT-LLM。其中 Kubernetes 负责最上层的资源调度这一层选得是否合理直接影响后续使用体验。对于没有现成 K8s 运维经验的同学也可以先用 Docker Compose 做小规模集群但一旦涉及 8 台机器和多个用户还是建议一步到位使用 Kubernetes。4. 集群搭建实战从拆箱到调度4.1 环境准备在开始动手前先确认以下信息8 台 DGX Spark 已经完成系统启动网络端口正常。每台机器的主机名、IP 地址规划清楚。已配置 SSH 免密登录至少从管理节点可以免密登录到所有计算节点。确保 8 台机器的时间同步一致。下面的示例以 8 台机器为例假设主机名为node01到node08其中node01同时作为管理节点和存储服务端。4.2 基础网络配置DGX OS 使用 Netplan 管理网络。以node01为例假设管理网络 IP 为192.168.10.11计算网络 IP 为10.10.1.11配置文件内容如下# 文件路径/etc/netplan/01-netcfg.yaml network: version: 2 ethernets: eth0: dhcp4: no addresses: - 192.168.10.11/24 routes: - to: default via: 192.168.10.1 nameservers: addresses: - 192.168.10.1 eth1: dhcp4: no addresses: - 10.10.1.11/24配置完成后执行sudo netplan apply将其他节点按同样的方式配置计算网络 IP 依次为10.10.1.12到10.10.1.18。配置完成后从node01测试所有节点连通性for i in {12..18}; do ping -c 1 10.10.1.$i /dev/null echo node0$((i-10)) OK; done4.3 部署 NFS 共享存储在node01上安装 NFS 服务端sudo apt update sudo apt install -y nfs-kernel-server sudo mkdir -p /data/nfs/models /data/nfs/datasets /data/nfs/logs编辑/etc/exports# 文件路径/etc/exports /data/nfs 10.10.1.0/24(rw,sync,no_root_squash,no_subtree_check)重启服务并验证sudo exportfs -ra sudo systemctl restart nfs-kernel-server在node02到node08上安装 NFS 客户端并挂载sudo apt install -y nfs-common sudo mkdir -p /data/nfs sudo mount -t nfs 10.10.1.11:/data/nfs /data/nfs为了重启后自动挂载把下面这行写入/etc/fstab10.10.1.11:/data/nfs /data/nfs nfs defaults,_netdev,nofail 0 04.4 部署 Kubernetes 集群这里选择 kubeadm 方式搭建。首先在所有节点上执行初始化操作安装常用依赖并关闭交换分区。这里给出核心命令序列版本以你实际安装时的最新稳定版为准。# 在所有节点执行 cat EOF | sudo tee /etc/modules-load.d/containerd.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter sudo swapoff -a sudo sed -i / swap / s/^/#/ /etc/fstab sudo apt install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl在管理节点初始化集群sudo kubeadm init \ --pod-network-cidr10.244.0.0/16 \ --apiserver-advertise-address192.168.10.11初始化成功后按照命令行提示配置kubectlmkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config而后将其他节点加入集群加入命令在初始化成功后命令行会直接给出形如sudo kubeadm join 192.168.10.11:6443 --token token --discovery-token-ca-cert-hash sha256:hash之后安装 CNI 网络插件这里以 Flannel 为例kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml4.5 接入 NVIDIA GPUKubernetes 默认不能感知 DGX Spark 上的加速器需要安装 NVIDIA Device Plugin。先确认每台节点都安装了 NVIDIA Container Toolkit然后创建 Device Plugin DaemonSet。以下是一个精简版配置# 文件路径nvidia-device-plugin.yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: nvidia-device-plugin-daemonset namespace: kube-system spec: selector: matchLabels: name: nvidia-device-plugin-ds template: metadata: labels: name: nvidia-device-plugin-ds spec: tolerations: - operator: Exists effect: NoSchedule priorityClassName: system-node-critical containers: - name: nvidia-device-plugin-ctr image: nvcr.io/nvidia/k8s-device-plugin:v0.16.1 securityContext: allowPrivilegeEscalation: false capabilities: drop: [ALL] volumeMounts: - name: device-plugin mountPath: /var/lib/kubelet/device-plugins - name: gpu mountPath: /dev/gpu volumes: - name: device-plugin hostPath: path: /var/lib/kubelet/device-plugins - name: gpu hostPath: path: /dev/gpu部署完成后查看节点状态kubectl get nodes kubectl describe node node01 | grep -A5 Capacity正常情况下Capacity中会列出nvidia.com/gpu资源数量为 1代表该节点有 1 个可调度的加速器单元。4.6 验证集群调度能力创建一个测试 Pod确认 GPU 资源可以被调度# 文件路径gpu-test-pod.yaml apiVersion: v1 kind: Pod metadata: name: gpu-test spec: containers: - name: cuda-container image: nvcr.io/nvidia/cuda:12.4.1-base-ubuntu22.04 command: [nvidia-smi] resources: limits: nvidia.com/gpu: 1运行命令kubectl apply -f gpu-test-pod.yaml kubectl logs gpu-test如果日志能正常输出 NVIDIA 显卡信息说明 Kubernetes 已经能正确调度 GPU 资源。5. 在集群上部署大模型推理服务5.1 推理框架选型集群搭建完成后下一步就是跑大模型。目前主流的自托管推理框架有 vLLM 和 TensorRT-LLM两者都支持多节点并行推理。vLLM部署简单OpenAI 兼容 API 容易对接四舍五入可以无缝替换 OpenAI 接口。TensorRT-LLMNVIDIA 官方推理框架针对硬件优化更深入但配置更复杂更适合生产环境深度调优。我的建议是先上 vLLM 跑通全流程再根据性能瓶颈决定是否切换到 TensorRT-LLM。5.2 多节点推理的关键参数vLLM 多节点推理依赖张量并行tensor parallel和流水线并行pipeline parallel两个概念。张量并行把 Transformer 层中的权重切分到多张 GPU 或多台机器上适合节点间通信带宽较高的场景。流水线并行把不同层分配到不同 GPU 上通信压力较小但存在流水线气泡利用率偏低。在 8 台 DGX Spark 组成的集群中如果模型参数超过 100B优先使用张量并行。以 vLLM 为例启动时需要传入--tensor-parallel-size参数表示把模型切分到多少个推理引擎上。5.3 用 vLLM 部署一个多节点推理服务假设我们准备在 8 台节点上运行一个 200B 量级的 INT4 模型。vLLM 多节点部署有两种常见方式一种是通过同一份启动命令在所有节点上拉起 worker另一种是借助 Ray 集群。这里给出一种基于 Ray 的部署思路。先准备一个 workdir 目录存放模型文件。sudo mkdir -p /data/nfs/models/mixtral-200b-int4 cd /data/nfs/models/mixtral-200b-int4 # 将模型权重下载到该目录或通过对象存储同步到该目录然后创建 Kubernetes Deployment 文件# 文件路径vllm-serve.yaml apiVersion: apps/v1 kind: Deployment metadata: name: vllm-serve namespace: ai spec: replicas: 1 selector: matchLabels: app: vllm-serve template: metadata: labels: app: vllm-serve spec: volumes: - name: models hostPath: path: /data/nfs/models type: Directory nodeSelector: kubernetes.io/hostname: node01 containers: - name: vllm image: vllm/vllm-openai:latest command: [python3, -m, vllm.entrypoints.openai.api_server] args: - --model/data/nfs/models/mixtral-200b-int4 - --tensor-parallel-size1 - --max-model-len4096 - --gpu-memory-utilization0.9 ports: - containerPort: 8000 resources: limits: nvidia.com/gpu: 1 volumeMounts: - name: models mountPath: /data/nfs/models这个配置里使用了nodeSelector把服务固定到node01上tensor-parallel-size1表示先不启用多节点并行。多节点并行时需要额外配置 Ray head 和 worker并把--tensor-parallel-size设置为节点数量同时通过环境变量告诉 vLLM 各节点的 IP 地址。不同版本的 vLLM 配置方式略有差异部署前务必查看对应版本的官方文档。5.4 部署完成后如何验证服务启动后通过kubectl get svc获取服务地址然后用 curl 做一次推理测试curl http://node01-ip:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: mixtral-200b-int4, messages: [{role: user, content: 用一句话解释什么是集群}], max_tokens: 128 }如果返回正常的 JSON 响应说明整个链路已经打通Kubernetes 调度 - GPU 容器 - NFS 模型加载 - vLLM 推理。6. 8 台集群的算力分析与模型容量测算6.1 从内存角度估算可承载模型以 8 台 DGX Spark 为例总统一内存约 1TB。但实际可用内存并不会百分之百用于模型参数操作系统、推理框架、KV Cache 和输入输出缓冲区都要占用内存。保守估计可用模型内存约为总内存的 70% 到 80%也就是 700GB 到 800GB。按 INT4 量化每个参数约 0.5 字节计算可承载参数量 ≈ 750GB / 0.5B ≈ 1.5T 参数也就是说单从内存容量角度看8 台集群甚至可以尝试加载超过 1TB 的量化模型。但这里有一个重要前提多节点并行时跨节点通信带宽会成为瓶颈实际吞吐可能会远低于参数规模增加的比例。6.2 从算力角度估算推理吞吐很多读者关心“两台 DGX Spark 做张量并行跑 70B 模型单并发输出多少 token”。严格来说这个数字受多种因素影响是否量化、量化精度。输入序列长度和输出长度。张量并行效率取决于网络带宽和 NVLink 支持情况。推理框架的调度方式是否开启了 continuous batching。没有在真实硬件上测试之前任何具体的 token 数字都是估算。比较稳妥的做法是先用小模型跑一遍基准测试记录不同并发下的延迟和吞吐再推算出目标模型的性能区间。你也可以通过 vLLM 自带的/metrics接口直接监控吞吐数据curl http://node01-ip:8000/metrics重点关注vllm:generation_tokens_total和vllm:request_success_total这两个指标的变化趋势。6.3 8 台机器最合适的定位从工程角度看8 台 DGX Spark 组成集群后更适合做“多模型统一推理平台”而不是“把一个大模型切到 8 台机器上跑”。原因在于切分越大通信成本越高。更合理的做法是用 1 到 2 台机器跑 70B 级别的量化模型。用 2 到 4 台机器跑 200B 级别的量化模型。剩下的机器可以承担微调任务、开发调试环境、数据处理任务。这也是 Kubernetes 这类调度平台的价值所在不同规格的模型服务可以申请不同数量的节点资源互不干扰。7. 常见问题与排查思路7.1 集群部署与推理阶段高频问题问题现象常见原因解决思路节点加入集群超时管理网络不通或kubeadm joinToken 过期检查网络连通性重新生成 TokenPod 一直处在 Pending 状态GPU 资源不足或nvidia.com/gpu未识别检查 Nvidia Device Plugin 是否运行推理速度很慢NCCL 走 TCP或计算网络没有打通确认 RoCE/InfiniBand 配置检查网卡 MTU加载模型时 OOM内存利用率设置过高或模型量化精度不符调低gpu-memory-utilization重新计算内存NFS 挂载失败/etc/fstab启动顺序导致网络未就绪使用_netdev参数延迟挂载跨节点通信时报错NCCL 端口未放通或防火墙拦截放通 5000-5100 等 NCCL 通信端口vLLM 版本和模型不兼容模型架构较新vLLM 旧版本不支持升级 vLLM或改用官方支持的镜像7.2 推荐排查顺序遇到问题不要一个个试建议按照下面顺序排查先看网络从每个节点ping其他节点的计算网络 IP确认延迟和丢包。再看调度kubectl describe pod pod-name查看事件关注FailedScheduling的具体原因。再看日志kubectl logs pod-name查看应用日志重点是 NCCL 初始化和模型加载阶段。最后看监控通过 DCGM Exporter 查看加速卡的温度、功耗和使用率排除硬件层面的性能问题。7.3 如何避免类似问题再次出现在集群上线前把所有基础环境做成自动化脚本不要手工逐台配置。尤其是网络配置、NFS 挂载、内核参数、防火墙规则这些内容一旦不一致后续排查成本会非常高。建议在每台机器的/etc/hosts中写入所有节点的主机名映射并统一使用主机名而不是 IP 地址来访问节点这样既能提高可读性也能避免 IP 变化导致的配置混乱。8. 集群落地的最佳实践与生产建议8.1 网络不要省交换机8 台 DGX Spark 组集群最值得投入的硬件是高速交换机。如果预算有限宁可减少一部分存储设备或冗余电源也要保证计算网络的带宽和稳定性。跨节点推理对网络抖动非常敏感千兆网络跑小模型还能忍跑 200B 级别模型基本不可用。有条件的话为计算网络单独配置一个网段并为 NCCL 通信预留隔离的 VLAN 或子网避免其他业务流量干扰。8.2 存储模型目录和日志目录分离NFS 根目录下分别创建models、datasets、logs三个子目录并设置不同权限。模型目录一般只读给推理服务数据集目录只有训练任务可写日志目录可以允许所有服务写入。这样的好处是方便做权限控制和备份。对 DGX Spark 这类带有本地高速盘的设备KV Cache 或临时文件不要存在 NFS 上一定要指向本地磁盘否则大批量请求时 NFS 会成为新的瓶颈。8.3 安全默认最小权限DGX Spark 集群如果放在办公室或实验室要特别注意网络安全。Kubernetes 的 API Server 默认端口是 6443长时间暴露在办公网中会有被恶意访问的风险。建议通过防火墙限制只有跳板机可以访问管理端口。涉及微调数据集时要确认数据来源合法不要使用未经授权的材料涉及模型权重下载时遵循模型许可证要求不要将受限模型私自对外提供服务。在集群上执行任何删除操作之前都要确认对象存储和数据库没有误删风险。对于 NFS 上的模型文件建议保留一份只读快照或者定期同步到对象存储。8.4 运维从第一天就建立监控体系8 台 DGX Spark 虽然不算大集群但已经远超手工管理的范围。建议从第一天就部署Prometheus Grafana监控节点 CPU、内存、网络、磁盘。DCGM Exporter监控加速卡利用率、显存占用、功耗、温度。Kubernetes Dashboard 或 Lens方便查看工作负载状态。监控的价值在故障时体现得最明显。没有监控一台机器过热导致推理变慢你可能要到用户反馈时才意识到问题。9. 总结与下一步8 台 DGX Spark 组成集群这件事从硬件层面已经具备可行性剩下更考验人的是网络规划、调度平台选型和推理框架调优。文章里提到的所有方案都围绕一个核心目标让多台单机变成一个可调度、可扩展、可维护的统一资源池。如果你打算实际搭建建议先不要一次性上 8 台。可以先用两台机器重点解决网络通信和多节点并行推理的问题确认网络带宽和推理框架的配置思路都清晰之后再逐步扩容。这样能把踩坑成本控制在最小范围内。下一步值得关注的技术方向有两个一是 Kubernetes 与 NVIDIA NIM 的深度集成二是推理框架本身的分布式优化能力。无论哪种方案最终都要回归到业务需求上——你的场景是同时跑多个小模型还是集中资源跑一个大模型两者的架构取舍完全不同。动手之前先把网络和存储方案定下来再考虑软件层。基础设施稳定了后面的大模型部署才会顺利。如果这篇文章对你有帮助可以收藏备用后续有新的实测结果我也会继续补充。