8 台 DGX Spark 组集群这个话题刚出现时很多人第一反应是一台 DGX Spark 已经接近一台小型 AI 服务器的能力为什么要折腾 8 台Alex Ziskind 的这组实践把“单台桌面级 AI 超级计算机”推向了“小规模 AI 集群”的工程场景。但从技术角度看最值得讨论的不是 8 台 GPU 加在一起多强而是从 1 台到 8 台的过程中网络怎么组、模型怎么切、调度怎么排、故障怎么查。这篇文章会沿着这条链路拆解DGX Spark 的定位、单机到集群的架构变化、多机推理框架的选型与配置、以及最容易被忽视的运维细节。如果你是正在评估是否购买 DGX Spark 的开发者或者手里已经有设备、想尝试多机并联的工程师这篇文章能帮你提前看到集群这条路线上最真实的工程障碍。1. 8 台 DGX Spark 集群这是一道工程题不是堆硬件很多人在聊 AI 集群时习惯先算算力。比如 8 台 DGX Spark合起来有多大的“等效显存”、能跑多大参数的模型、训练速度能翻几倍。但 Alex Ziskind 的实践最有价值的地方在于它把问题从“算力叠加”拉回了“系统集成”。当你只有 1 台机器时你需要处理的是模型加载、推理 API、显存占用这些单机问题。但当你把 8 台机器组成集群问题会立刻变成以下几类网络拓扑怎么设计是 8 台直连交换机还是两两互联还是分级汇聚。模型并行策略怎么选同一个模型切到多张卡上跑还是每台机器独立跑一个完整模型。推理框架是否支持多机扩展有些框架单机性能很好但对跨节点通信支持并不成熟。如何做容器编排和任务调度Docker Compose 只适合单机8 台机器需要真正的编排系统。如何定位问题模型加载慢、推理超时、GPU 利用率低问题到底出在网络、存储、还是调度层。从网络热词来看“dgx spark 本地部署 200b 大模型”“两台 dgx spark 张量并行 70b 模型单并发输出多少 token”都是当前开发者最关心的问题。这些问题的共同点是大家并不满足于单机演示而是想探索多机协同的边界。而跨越这个边界恰恰需要补上分布式系统的基础知识。所以这篇文章的小结论是8 台 DGX Spark 集群的真正价值不是“更大的数字”而是验证了一条从单机走向分布式的现实路径。它能跑通说明桌面级 AI 设备具备了进入生产集群的可能它暴露的问题则是所有小规模 AI 集群都会遇到的共性问题。2. DGX Spark 是什么先分清它与传统 GPU 服务器的差异2.1 产品定位DGX Spark 是 NVIDIA 在 2025 年 GTC 大会上正式发布的桌面级 AI 超级计算机此前以 Project DIGITS 的名称进行过预告。它的定位非常明确给 AI 开发者、数据科学家和大模型研究者一台可以放在桌面上的本地推理设备而不是机架式 GPU 服务器。从名字上容易产生一个误解DGX Spark 里的“Spark”会让人联想到 Apache Spark 大数据框架。实际上两者没有关系DGX Spark 是 NVIDIA DGX 系列的一员只是体积和功耗都比 DGX Station、DGX H100 这类产品小得多。DGX Spark 的核心是 GB10 Grace Blackwell 超级芯片。它把 Grace CPU 和 Blackwell GPU 集成在一起属于 ARM 架构体系。这意味着它的底层生态与传统 x86 GPU 服务器不同很多软件需要适配 ARM 版本这会在后面部署环节反复出现。2.2 为什么“单机跑 200B 模型”是核心卖点DGX Spark 官方宣传的重点是它可以本地运行 200B 参数级别的大模型。它之所以能加载这么大的模型核心原因是拥有大容量统一内存CPU 和 GPU 可以共享同一块内存池而不像传统显卡那样有独立的显存上限。传统 GPU 服务器如果显存只有 80GB跑 70B 模型也需要反复切分和量化而 DGX Spark 的单机内存容量足够大使用 FP4 或量化模型时200B 级别的模型在单机上是可以装下的。这个能力是它与普通 PC、普通 NPU 设备拉开差距的关键。2.3 与 PC、NPU 的对比很多人会问PC 上的 NPU 能不能组集群从技术上看PC NPU 是一种端侧推理单元计算密度、互联能力和生态支持都不足以构成传统意义上的 GPU 集群。它适合做单机轻量推理加速但很难承担分布式训练和推理任务。对比项传统 GPU 服务器DGX Spark普通 PC / NPU 设备架构x86 独立 GPUARM Grace Blackwellx86/ARM NPU内存模型显存与内存分离统一内存显存/内存容量小单机大模型能力依赖显存容量可装 200B 级别量化模型受限集群扩展性成熟具备高速网络接口弱软件生态最成熟需要 ARM 适配不适用于分布式推理适用场景数据中心、训练集群桌面开发、小规模集群轻量端侧推理从开发者视角看DGX Spark 真正的意义不是替代数据中心里的 A100/H100而是把“本地跑大模型”从极客玩具变成了工程工具。而当你同时拥有 8 台 DGX Spark 时要思考的就不只是单机运行效率而是如何把它们组织成一个可调度的推理资源池。3. 为什么单机已经不小还需要组成集群3.1 单机内存再大也有边界DGX Spark 单机可以跑 200B 级别模型但这里的“跑”是有条件的。模型加载不仅需要保存权重还需要在推理过程中占据 KV Cache、中间激活值等额外内存。一个 70B 模型如果使用 FP8 精度权重约占 70GB 左右200B 模型即使量化后剩余可用的 KV Cache 空间也会被压得很小。实际部署时你可能面临一个尴尬局面模型能加载但并发请求一多KV Cache 分配失败或者上下文窗口稍微拉长内存直接打满。单机统一内存的容量上限决定了它更适合“单用户单请求”的开发调试而不是“多用户高并发”的在线服务。3.2 集群到底解决什么问题集群的核心价值可以概括为三点第一是加载更大的模型。如果单机内存不足以放下 300B 甚至 400B 参数级别的模型多台机器通过张量并行把模型切到多张卡上就能突破单机容量上限。第二是提升推理吞吐。如果单机只能单并发处理请求那么用多台机器做数据并行每台机器独立服务一部分请求整体吞吐量会线性增长。第三是高可用和任务隔离。在集群环境中可以把不同模型部署到不同节点避免一个模型占用内存导致另一个模型无法启动也可以实现滚动更新和故障转移。3.3 模型并行的几种方式并行方式原理适用场景对网络的依赖张量并行把一层模型的权重切到多张卡上每张卡算一部分单机内存放不下的超大模型高流水线并行按层切分前一个 stage 算完传给下一个层数很深的模型中数据并行每张卡保存完整模型各自处理不同请求高并发服务场景低从网络热词“两台 dgx spark 张量并行 70b 模型单并发输出多少 token”来看不少开发者最关心的是两台设备做张量并行后70B 模型单并发每秒能输出多少 token。这个问题没有一个公开的固定答案因为它取决于模型精度、量化方式、上下文长度、并行切分策略和网络带宽。但可以从原理上做一个判断张量并行会让每次推理都涉及跨节点通信如果设备之间的网络带宽不够通信开销可能会吃掉张量并行带来的算力收益。单机显存不够时张量并行是“能跑起来”的手段但不一定是“跑得快”的手段。这个部分的小结论是集群不等于加速器它首先是一个容量扩展器。如果你的模型单机能放下数据并行或独立部署通常比张量并行更划算只有当模型超过单机容量时张量并行才从“可选优化”变成“必选方案”。4. 8 台 DGX Spark 集群的架构设计思路4.1 网络拓扑集群的命脉组建 8 台 DGX Spark 集群第一步是设计网络拓扑。最简单的方案是 8 台设备全部接入一台高速以太网交换机形成一个星型拓扑。这种结构管理方便扩展性好8 台节点之间的通信延迟相对均衡。更复杂的方案是分两组每组 4 台各自接入交换机两组再通过汇聚交换机互联。这种拓扑适合未来扩展到 16 台、32 台的场景但小规模集群暂时没有必要。DGX Spark 自带 ConnectX-7 智能网卡支持高速以太网互联这也是它能组成集群的底层硬件基础。在规划网络时建议把“管理网络”和“数据网络”分开管理网络用于 SSH、监控、容器编排数据网络用于模型并行时的张量通信以及模型文件的传输。4.2 存储规划模型文件放哪里集群里每台节点都需要加载同一个模型文件。如果每台机器都从本地磁盘加载优点是加载速度快缺点是每个节点要保存一份模型副本多台设备会占掉大量存储空间如果使用 NFS 或共享文件系统统一存放模型优点是只存一份缺点是模型首次加载时网络会成为瓶颈。对于 8 台规模的小集群更稳妥的做法是权重文件先放在共享存储上首次校验后拷贝到各节点的本地 NVMe 盘后续推理优先从本地加载。等节点本地缓存齐全后共享存储的压力会大幅下降。4.3 软件调度从 Compose 到 K8s 的路线图单机部署时Docker Compose 足够用但 8 台设备的资源调度、失败重启、端口管理需要真正的编排系统。社区中最常见的选择是 Kubernetes配合 NVIDIA Device Plugin 调度 GPU如果偏向传统 HPC 场景也可以考虑 Slurm。调度层适合阶段优点缺点Docker Compose单机验证简单直接无法跨节点管理Kubernetes8 台以上集群资源调度、自动恢复、弹性伸缩运维成本高Slurm传统 HPC调度模型成熟容器支持相对繁琐从 Alex Ziskind 这类实践者的角度出发最合理的路径不是一开始就上 K8s而是先用 Compose 在单机上验证模型推理再引入 K8s 做多机编排。5. 环境准备与基础配置5.1 操作系统与基础软件DGX Spark 出厂时预装了定制的 Linux 系统但作为通用工程实践你需要确认以下组件是否正常Docker 或 Podman 容器运行时NVIDIA Container Toolkit用于在容器内识别 GPUPython 3.10 及以上版本支持 ARM64 架构的 PyTorch 和 CUDA 版本在开始之前先用uname -m确认架构正常情况下应该是aarch64。这会直接影响后续镜像选择和依赖安装。uname -m # aarch645.2 配置 hosts 与 SSH 免密8 台设备如果使用 IP 通信容易出错。先把主机名和 IP 的映射关系写到所有节点的/etc/hosts中。# /etc/hosts 192.168.50.10 dgx-spark-01 192.168.50.11 dgx-spark-02 192.168.50.12 dgx-spark-03 192.168.50.13 dgx-spark-04 192.168.50.14 dgx-spark-05 192.168.50.15 dgx-spark-06 192.168.50.16 dgx-spark-07 192.168.50.17 dgx-spark-08配置 SSH 免密后可以避免每台节点手动输入密码。具体做法是在管理节点生成密钥然后分发到各个目标节点。ssh-keygen -t ed25519 ssh-copy-id dgx-spark-01 ssh-copy-id dgx-spark-02 # 依次分发到 dgx-spark-085.3 安装 NVIDIA Container Toolkit容器内识别 GPU 是 AI 集群的基础。以下命令适用于 Debian/Ubuntu 系系统执行前需要确认与当前系统版本匹配。sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker安装完成后在每台节点上执行nvidia-smi确认 GPU 驱动和 CUDA 版本可见。nvidia-smi如果nvidia-smi没有输出说明驱动或软件栈未正确安装一定要先解决这个问题再继续集群配置不要带着“先跑起来再说”的心态往下走。5.4 Docker 运行 GPU 容器的最低配置单节点验证时需要把 GPU 设备的访问权限传入容器。手动执行 docker run 时加上--gpus all参数即可。docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi这个命令会拉取一个 CUDA 基础镜像并在容器内执行nvidia-smi。能输出 GPU 信息说明 Docker 与 GPU 的通道已经打通。这一步是整个集群验证流程中最简单也最基础的一环如果在这里失败后续所有推理服务都无法启动。6. 模型部署多机推理框架与并行配置6.1 推理框架选型当前主流的本地推理框架主要有三个方向vLLM 是目前使用最广的开源推理框架PagedAttention 机制能显著提高吞吐也支持多机多卡推理适合需要高并发的场景。SGLang 的 RadixAttention 在做多轮对话和复杂 prompt 处理时有优势。TensorRT-LLM 是 NVIDIA 官方生态的优化方案在 DGX 设备上通常能拿到最极致的性能但部署复杂度也最高。如果你第一次接触多机推理建议从 vLLM 开始。它的文档最全社区案例最多踩坑成本相对低。6.2 单机单卡的 vLLM 容器启动以在单台 DGX Spark 上启动 vLLM 为例Docker 命令如下docker run --runtime nvidia --gpus all \ -v /models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-72B-Instruct-GPTQ-Int4 \ --max-model-len 8192这里需要注意几点模型文件必须预先下载到/models目录--max-model-len要根据模型支持的最大上下文和内存剩余情况设置不要直接拉满如果模型是 GGUF 格式vLLM 的兼容性有限可能需要使用其他框架。6.3 多机张量并行配置当模型超过单机内存时需要使用多机张量并行。vLLM 多机推理通常借助 Ray 实现需要一个 Ray 头节点和若干工作节点。假设你有 2 台 DGX Spark目标是把一个 140B 级别的模型切到 2 台设备上# 在 dgx-spark-01 上启动 Ray 头节点 ray start --head --port6379 --dashboard-host0.0.0.0 # 在 dgx-spark-02 上加入 Ray 集群 ray start --addressray://dgx-spark-01:6379然后启动 vLLM 服务# 在 dgx-spark-01 上执行 vllm serve /models/Model-140B \ --tensor-parallel-size 2 \ --distributed-executor-backend ray \ --ray-address ray://dgx-spark-01:6379这里的关键配置是--tensor-parallel-size 2它告诉 vLLM 把模型切到 2 个 GPU 设备上。跨节点通信会走 ConnectX-7 以太网所以网络的稳定性会直接影响推理性能。“两台 dgx spark 张量并行 70b 模型单并发输出多少 token”这个问题在实际环境中的答案取决于很多变量量化精度、并行切分数量、网络延迟、输入输出长度、vLLM 的调度策略。对于 70B 级别模型如果单机内存足够优先体验单机部署如果必须双机并行建议重点观察每 token 生成时间和网络流量判断通信开销是否过大。6.4 多机数据并行配置数据并行与张量并行完全不同。它的思路是每台节点加载完整模型然后通过负载均衡把不同请求分发到不同节点。这种方式对网络依赖低吞吐扩展性好适合并发量大的生产场景。用 Kubernetes 部署时可以创建 8 个 Deployment 副本每副本绑定一台节点的 GPU然后通过 Service 统一暴露入口。用 Docker Compose 时则可以在不同节点分别启动容器再用 Nginx 做 TCP 负载均衡。# /etc/nginx/nginx.conf stream { upstream llm_backend { server 192.168.50.10:8000; server 192.168.50.11:8000; server 192.168.50.12:8000; server 192.168.50.13:8000; server 192.168.50.14:8000; server 192.168.50.15:8000; server 192.168.50.16:8000; server 192.168.50.17:8000; } server { listen 8000; proxy_pass llm_backend; } }这种方案的好处是任何一台节点故障时Nginx 可以自动将请求转发到健康节点集群整体可用性大幅提升。7. 运行验证与性能观察7.1 验证容器与 GPU 连通部署完成后先不要急着压测。第一步验证每台节点的容器是否都能正确看到 GPUdocker run --rm --gpus all vllm/vllm-openai:latest nvidia-smi能看到 GPU 信息代表容器运行时和驱动没问题。7.2 验证 Ray 集群状态多机推理的第一步是确认 Ray 集群中的节点数量。执行ray status --address ray://dgx-spark-01:6379如果显示 2 个节点、每节点 1 个 GPU说明 Ray 集群已经构建成功。7.3 验证推理 API模型加载完成并监听 8000 端口后用 curl 发一个最小请求curl http://192.168.50.10:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /models/Model-70B, messages: [{role: user, content: 你好请介绍一下你自己}], max_tokens: 128, temperature: 0.7 }正常响应会返回类似 OpenAI 格式的 JSON 结构包含choices和usage。如果请求超时优先查看模型日志确定是正在加载权重、网络通信失败还是内存不足。7.4 观察 GPU 与网络状态推理过程中在任意节点执行nvidia-smi可以观察 GPU 利用率和内存占用。对于多机张量并行还要关注网络流量。nvidia-smi -l 5如果 GPU 利用率很高但 token 输出速度很低大概率是等待跨节点通信这时应检查交换机的流控、网卡速度协商和丢包情况。如果 GPU 利用率很低但内存占用很高可能是模型权重加载过程还没有完成或者请求没有真正进入推理阶段。8. 常见问题与排查思路问题现象可能原因排查方式解决方案容器内无法识别 GPUNVIDIA Container Toolkit 未配置执行 nvidia-ctk runtime configure重新配置 runtime 并重启 Docker模型加载后很快 OOMmax-model-len 设置过大查看日志中的内存分配失败记录调小 max-model-len 或改用量化模型多机并行时 token 生成极慢跨节点网络通信瓶颈观察 nvidia-smi 利用率和网卡流量确认交换机规格和 VLAN 配置或减少张量并行度Ray 集群节点未全部注册防火墙或端口未开放查看 Ray dashboard 节点列表开放 6379、8265 等端口检查 hosts 映射镜像拉取失败镜像不支持 ARM64查看 manifest 列表更换支持 ARM64 的镜像或自行构建请求超时但无错误模型仍在加载阶段查看 vLLM 启动日志等待加载完成或优化模型文件存储为本地 NVMe多节点并发不均衡部分节点未参与调度查看 K8s node label 和 pod 分布确认节点数、GPU 数量和容器调度约束跨节点容器间通信超时网络策略限制ping 测试与 nc 测试端口调整防火墙规则确保同一子网互通重新部署后模型加载变慢节点本地缓存被清理检查 /models 挂载情况将模型固定到本地磁盘或定期预热在实际排查中我最推荐的方式是“先看日志再看监控最后猜原因”。DGX Spark 这类设备的日志通常会在启动阶段打印非常详细的初始化信息很多问题在日志里已经明确提示了失败原因不需要到处查资料。9. 最佳实践与工程建议9.1 先单机再双机最后上 8 台这是最重要的建议。不要拿到 8 台机器后直接都接入网络而是先在单机上跑通推理再增加第二台验证多机通信确认稳定后再扩展到 8 台。集群的问题往往是层层叠加的如果单机还没有完全掌握直接上集群会把问题复杂度放大到难以排查。9.2 网络是集群的命脉DGX Spark 的单机性能已经不错但跨节点的数据交换能力决定了你的集群到底是一个整体还是 8 台各自为战的设备。组建集群前建议先做基础网络性能测试确认节点间带宽和延迟在合理范围内。实际项目中我见过太多“硬件没瓶颈、调度也正常但就是慢”的情况最后都定位到交换机的 QoS 策略或者 MTU 配置不一致。9.3 模型文件尽量本地化每次从共享存储加载几百 GB 的模型文件都会带来不可控的启动延迟。更好的做法是先在一台节点下载模型并验证验证通过后再通过内部网络分发到其他节点。模型文件分发完成后再启动推理服务避免“并发加载”导致共享存储带宽打满。9.4 区分容量扩展和并发加速这是最容易被误解的点。8 台 DGX Spark 组成集群后如果你只是想让 70B 模型的推理变得更快可能不会得到预期效果但如果你的目标是加载 400B 级别的大模型或者同时服务几十个并发请求集群的价值就能体现出来。想清楚集群的第一目标才能选择正确的并行策略。9.5 版本锁定与可观测性集群环境中最忌讳“版本漂移”。节点 A 的 CUDA 版本、容器镜像、模型文件必须与节点 B 完全一致。建议把依赖版本写入统一的部署脚本并用 git 管理。同时尽早搭建 Prometheus Grafana 监控收集每个节点的 GPU 利用率、内存占用、网络流量和推理延迟。9.6 提前考虑电源和散热8 台 DGX Spark 虽然体积不大但长时间满载运行对电源和散热的要求仍然高于普通 PC。如果是在办公环境部署注意排插功率上限和机房散热能力避免因过热导致节点频繁降频。10. 总结与后续学习方向8 台 DGX Spark 集群的实践真正反映的是 AI 基础设施小型化的趋势。从一台能跑 200B 模型的桌面设备到 8 台组成的多机推理集群硬件门槛已经比传统数据中心低了很多但工程门槛并没有随之消失。网络设计、模型并行、容器编排、故障排查每一项都是分布式系统的通用知识只是现在有了更亲民的实验环境。对于想跟进这个方向的开发者建议的实践路径是先在自己的单台设备上部署 vLLM跑通一个 70B 量化模型的推理然后尝试双机张量并行观察模型超过单机内存时的行为变化最后才是完整的 8 节点集群。每一步都写清楚你的网络结构、模型配置和性能数据你会发现在这个过程中积累的分布式推理经验比堆硬件本身更有价值。如果你已经在尝试多机集群也建议把自己遇到的网络带宽、KV Cache、调度失败这类问题记录下来。这些问题的解决方案未来很可能会成为小规模 AI 集群部署的标准参考。