从 2025 年 NVIDIA GTC 发布以来DGX Spark 在本地大模型部署圈子里始终保持着很高的话题度。它把“桌面级设备跑百亿甚至千亿参数模型”这件事从概念变成了可落地的硬件方案。不过很多团队在实际使用时会遇到同一个问题单台 DGX Spark 拥有 128GB 统一内存看起来确实不小但当你需要部署 200B 级别的模型或者业务要求同时处理多个并发推理请求时单机的内存容量和总算力都会变得紧张。把两台 DGX Spark 通过 NVIDIA Sync 连接起来组成一个“两台设备协同工作的小集群”是解决这类需求的重要思路。本文将从核心概念、环境准备、物理组网、软件配置、推理框架部署到吞吐估算完整拆解整个连接与使用流程。无论你已经在使用 DGX Spark还是正在调研本地私有化大模型部署方案这篇教程都可以作为参考。1. NVIDIA Sync 是什么DGX Spark 多机互联的核心概念1.1 先理解 DGX Spark 的定位DGX Spark 不是传统意义上的 PC 工作站。它基于 NVIDIA GB10 Grace Blackwell 超级芯片CPU 和 GPU 集成在一个封装内通过 NVLink-C2C 高速总线连接CPU 可以直接访问 GPU 内存。这种架构带来的直接好处是CPU 和 GPU 共享统一内存池模型权重不需要在 CPU 内存和显存之间反复拷贝推理时的数据搬运开销大幅降低。内存容量是 DGX Spark 最核心的指标之一。128GB 统一内存意味着即使不依赖外部服务器单台设备也能加载相当规模的量化模型。发布时 NVIDIA 官方的宣传重点是“本地运行 200B 参数模型”这一定位让很多个人开发者和中小团队看到了私有化部署的可能性。与此同时DGX Spark 的价格也进入了不少团队可以评估的区间具体售价请以官方渠道各时点信息为准这也是它热度持续走高的原因之一。但“可以运行”和“运行得好”是两回事。200B 模型加载进去之后单机还要同时承担 KV Cache、推理中间结果、服务框架自身的开销。如果上下文长度拉长或者业务请求并发上来128GB 很快就会成为瓶颈。这时连接第二台 DGX Spark用两台设备共同承担推理任务就是最直接的扩容方式。1.2 两台设备互联的真实场景把两台 DGX Spark 连接在一起通常有四种典型场景。第一种是超大模型部署。当模型权重加上运行开销超过了单台设备的内存容量又因为数据安全原因不能放到云上双机甚至多机协同就成了必经之路。第二种是吞吐量优化。单个 70B 级别的模型在单台设备上推理时单并发输出速度可能只有个位数到十几 token/s。通过张量并行Tensor Parallelism把模型切分到两台设备上每台设备只需要计算自己负责的那一部分理论上可以显著提升单并发和低并发场景的吞吐。第三种是开发与生产环境隔离。你可以用一台 DGX Spark 跑正式的推理服务另一台做模型微调、评测和版本验证两台设备之间共享数据和调试通道。第四种是多模型并行。一台设备跑对话模型另一台设备跑向量化模型或 Reranker通过内部网络互相调用组成一套完整的 RAG 服务链路。无论哪种场景背后都需要一套可靠的多机通信机制。NVIDIA Sync 就是这套机制的入口。1.3 NVIDIA Sync 在连接中扮演什么角色严格来说NVIDIA Sync 不是“一个命令”或“一个工具”而是一整套面向 DGX Spark 多机协同的软硬件方案。它的作用是让两台 DGX Spark 从“网络上互相能 ping 通”上升到“一个分布式推理系统”。这个升级过程包含三个层面。第一层是物理互连两台设备需要有高速网络接口相连确保数据通路带宽足够。第二层是系统配置包括固定 IP、主机名解析、SSH 可信关系、防火墙放通等基础工作。第三层是分布式运行时也就是让 PyTorch、NCCL、Ray 这些组件能够感知到对方设备上的 GPU 算力和内存资源并在框架层面完成多机调度。理解这一点很重要。很多初次接触多机训练的开发者会以为“连接两台设备”只需要插一根线、设置一下 IP 就结束了但真正让分布式推理跑起来还依赖软件栈的完整配置。本文后续章节会按照这三个层面依次展开你可以把 NVIDIA Sync 理解成贯穿整个过程的方法论和官方能力集合而具体到操作就是每一层配置的逐步落实。2. 连接前的环境准备与版本检查2.1 硬件与场地准备连接两台 DGX Spark 之前先确认硬件条件。你需要准备两台 DGX Spark并确保它们使用相同或兼容的电源规格和散热环境。DGX Spark 的定位虽然是桌面设备但高负载推理时发热和功耗仍然可观不要把它塞进密闭弱电箱或堆叠在一起使用设备之间至少要保持正常的通风间距。网络互连方面至少需要一条可靠的高速以太网线缆。如果条件允许建议通过支持万兆或更高规格的交换机连接。直连线缆适合两台设备互连的简单场景交换机组网则方便后续扩展第三台、第四台设备。具体使用哪种线缆规格请以两台设备的实际网口类型和 NVIDIA 官方配件说明为准不要随意混用不兼容的线缆。连接思路是先规划拓扑再设置 IP最后验证链路。不要跳过规划直接插线配置否则后续排查问题时线缆和 IP 的混乱会让你浪费大量时间。2.2 系统与软件初始检查DGX Spark 出厂搭载 NVIDIA 定制的 DGX OS底层是 Linux 系统。拿到设备后先通过显示器和键鼠或者通过默认管理网络 SSH 登录系统做一轮基础状态检查。# 查看系统发行版信息 cat /etc/os-release # 查看内核版本 uname -a # 查看 GPU 是否被正确识别 nvidia-smi # 查看内存与统一内存信息 free -h如果nvidia-smi能正常输出并且能看到 Grace Blackwell 芯片信息说明基础驱动没有问题。建议记录下每台设备的主机名、系统版本、驱动版本后续做多机互通时这些信息会帮助你快速判断版本兼容性问题。2.3 软硬件检查清单检查项说明验证方式系统版本两台设备应保持同一大版本cat /etc/os-release驱动状态GPU 能被正常识别nvidia-smi网络接口确认互联接口名称和速率ip link/ethtool主机名提前规划避免重名hostnamectl防火墙放通集群通信端口sudo ufw statusSSH 服务开启并允许密钥登录systemctl status ssh注意如果你的设备是刚拆箱的建议先按照 NVIDIA 官方文档完成系统初始化和驱动更新再进行双机连接操作。版本需要根据你的实际设备情况调整本文示例以常见 Linux 环境为例重点演示配置思路。3. 物理连接与网络组网3.1 选择连接拓扑两台 DGX Spark 最简单的连接方式是直连用一根高速网线把两台设备的互联网口直接连起来。这种方式延迟低、没有交换机转发开销适合两台设备固定的场景。如果后续还要扩展更多设备则建议使用交换机。通过交换机连接时所有设备处于同一个二层网络中IP 规划更灵活排查问题也更方便。无论采用哪种拓扑都建议为集群规划专用的静态 IP 网段例如设备主机名IP 地址设备 Adgx-a192.168.100.10设备 Bdgx-b192.168.100.11使用独立网段避免和办公网络冲突是双机组网的基本功。固定 IP 不仅方便记忆更重要的是后续 NCCL、Ray 等分布式组件需要稳定的地址发现机制。3.2 配置网络接口连接好线缆后需要确认系统是否识别到了新的网络接口。使用ip addr查看所有网络接口找到与互联线缆对应的那个接口名。不同系统下接口名可能不同常见形式包括enp1s0f0np0、eth0等。接下来为接口配置静态 IP。以设备 A 为例# 查看接口状态 ip addr show # 使用 nmcli 配置静态 IP需要根据实际接口名和连接名调整 sudo nmcli con mod Wired Connection \ ipv4.addresses 192.168.100.10/24 \ ipv4.gateway \ ipv4.method manual # 启用连接 sudo nmcli con up Wired Connection # 再次确认 IP 是否生效 ip addr show设备 B 同样操作设置192.168.100.11/24。这里要特别注意如果系统里存在多个网卡务必确认你修改的是互联接口而不是管理网络接口否则可能把设备“配断网”。3.3 连通性验证与 SSH 配置IP 配置完成后先验证链路是否通畅。# 从设备 A ping 设备 B ping 192.168.100.11 # 查看网卡速率与协商状态 ethtool 接口名ping通了只代表二层和三层网络正常还不能说明带宽和稳定性。建议进一步用iperf3做一次简单的带宽压测# 设备 B 先启动服务端 iperf3 -s # 设备 A 以客户端模式测试 30 秒 iperf3 -c 192.168.100.11 -t 30通过测试数据可以确认实际传输带宽是否接近网卡协商速率。如果带宽明显偏低检查线缆是否插到了正确的接口、是否启用了巨型帧Jumbo Frame、是否有网卡降速现象。网络通畅后配置 SSH 免密登录。这一步非常关键因为后续分布式组件在多机之间拉起进程时通常依赖 SSH 免密能力。# 在设备 A 上生成密钥如果还没有 ssh-keygen -t ed25519 # 将公钥复制到设备 B ssh-copy-id dgx-b192.168.100.11 # 验证免密登录 ssh dgx-b192.168.100.11 hostname同样操作将设备 B 的公钥复制到设备 A实现双向免密。4. 软件配置与多机协同验证4.1 更新系统与基础组件网络层就绪后进入软件配置阶段。首先确保两台设备的系统组件、驱动和 CUDA 工具链处于相近版本。# 更新系统软件源和软件包 sudo apt update sudo apt upgrade -y # 查看驱动与 CUDA 版本 nvidia-smi nvcc --version如果两台设备的驱动或 CUDA 版本差异较大分布式框架在初始化 NCCL 时可能报错。最好的做法是让两台设备保持相同版本避免“能 ping 通但框架通信失败”的尴尬情况。4.2 配置主机名解析分布式框架在多机通信时经常需要通过主机名解析 IP 地址。建议在两台设备的/etc/hosts中同时写入对方的信息避免依赖 DNS 服务。# 文件路径/etc/hosts 192.168.100.10 dgx-a 192.168.100.11 dgx-b修改完成后分别在两台设备上执行ping dgx-a和ping dgx-b验证主机名解析是否生效。4.3 使用 NVIDIA Sync 建立多机协同会话NVIDIA Sync 的正式启用通常会借助 NVIDIA 提供的管理工具或控制台完成设备注册与发现。具体入口和界面会随软件版本迭代而变化建议以官方文档和工具界面为准。这里要理解的核心链路是设备发现 → 网络检测 → 会话建立 → 资源分配到分布式运行时。如果暂时没有系统管理工具也可以通过完全手动的分布式配置达到同样的多机协同效果。本质上我们需要的是一套能让两台设备上的 GPU 互相感知的运行时环境。这一步可以通过 NCCL 测试来完成验证。4.4 用 NCCL 测试验证双机通信NCCLNVIDIA Collective Communications Library是 NVIDIA 提供的多 GPU 和多节点通信库PyTorch 分布式训练和 vLLM 多卡推理底层都依赖它。下面用一段最简单的 PyTorch 程序验证两台 DGX Spark 能否通过 NCCL 正常通信。# 文件路径任意目录/test_allreduce.py import torch import torch.distributed as dist def main(): # 初始化分布式进程组使用 NCCL 后端 dist.init_process_group(backendnccl) rank dist.get_rank() local_rank dist.get_local_rank() # 当前进程绑定到本机对应的 GPU torch.cuda.set_device(local_rank) # 每个进程创建一个初始值等于 rank 的 tensor tensor torch.ones(1, devicecuda) * rank # 所有进程执行 all_reduce 求和 dist.all_reduce(tensor, opdist.ReduceOp.SUM) if rank 0: print(frank{rank}, all_reduce result{tensor.item()}) else: print(frank{rank}, all_reduce result{tensor.item()}) if __name__ __main__: main()在设备 A 上启动torchrun --nnodes2 --nproc-per-node1 --node-rank0 \ --master-addr192.168.100.10 --master-port29500 \ test_allreduce.py在设备 B 上启动torchrun --nnodes2 --nproc-per-node1 --node-rank1 \ --master-addr192.168.100.10 --master-port29500 \ test_allreduce.py正常情况下两台终端窗口都会输出all_reduce result1.0。因为 rank 0 的初始值是 0rank 1 的初始值是 1求和结果为 1。如果能看到这个结果说明 NCCL 可以正常跨节点通信分布式运行时已经打通。小提示这里的nproc-per-node1表示每个节点启动 1 个进程。如果单台设备上实际只有一个 GPU 实例写 1 即可如果设备被系统识别为多个计算实例可以按实际数量调整。5. 双机部署 70B/200B 模型的实战案例5.1 实战目标打通双机通信后就可以进入真正的推理部署阶段。本文的实战目标有两个用两台 DGX Spark 部署一个 70B 级别的量化模型开启张量并行Tensor Parallelism验证双机推理效果。讨论 200B 级别模型在双机 256GB 统一内存下的部署可能性与注意事项。说明以下示例以 vLLM 为主要推理框架因为它对多机多卡支持较成熟并且提供 OpenAI 兼容的 API 服务。实际使用时可以根据模型格式和版本选择 SGLang、TGI 等框架思路是相通的。5.2 建立 Ray 集群vLLM 多机推理通常通过 Ray 集群协调跨节点资源。先在一台设备上启动 Ray head 节点然后在另一台设备上加入集群。# 在设备 A主节点启动 Ray head ray start --head --port6379看到 Ray 启动成功的日志后在设备 B 上执行加入命令# 在设备 B 加入设备 A 管理的集群 ray start --address192.168.100.10:6379使用ray status可以确认两台设备是否都已加入集群。如果能看到两个节点并且每个节点都贡献了 GPU 资源说明 Ray 集群就绪。Linux 命令补充# 查看 Ray 集群状态 ray status5.3 用 vLLM 启动双机张量并行推理假设 70B 模型权重已经存放在每台设备的本地磁盘路径/data/models/qwen-70b-awq下实际路径请替换为你自己的模型目录在设备 A 上启动 vLLM 服务vllm serve /data/models/qwen-70b-awq \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --api-key local-test关键参数含义--tensor-parallel-size 2张量并行度为 2让模型权重切分到两台设备上。如果 Ray 集群中有两个节点vLLM 会自动跨节点调度。--max-model-len 8192限制最大上下文长度避免 KV Cache 占用过多内存。--api-key local-test为 API 设置访问密钥仅用于本地测试环境。如果你的 vLLM 版本较老不支持vllm serve子命令可以使用python -m vllm.entrypoints.openai.api_server启动参数完全一致。不同版本的 vLLM 在多机调度的细节上有差异较新版本会自动识别 Ray 集群老版本可能需要额外指定--distributed-executor-backend ray。遇到问题先看启动日志根据日志提示调整即可。5.4 发送推理请求验证服务启动后通过 curl 发送一个聊天补全请求curl http://192.168.100.10:8000/v1/chat/completions \ -H Authorization: Bearer local-test \ -H Content-Type: application/json \ -d { model: /data/models/qwen-70b-awq, messages: [{role: user, content: 介绍一下 DGX Spark 的主要特点}], max_tokens: 256 }如果一切正常你会收到包含生成文本的 JSON 响应。此时打开nvidia-smi观察两台设备的 GPU 利用率应该能看到两台设备都在参与计算。对于 200B 模型双机部署的思路完全一样但需要注意两点第一200B 模型的量化版本通常在 100GB 到 120GB 之间双机 256GB 统一内存可以比较从容地加载还能剩余一部分空间给 KV Cache第二当模型权重超过单机内存容量时--tensor-parallel-size 2几乎是必须的配置尽量避免单机强行加载导致内存溢出。6. 聚焦两台 DGX Spark 张量并行 70B 模型的单并发吞吐估算6.1 为什么单并发吞吐主要受内存带宽限制很多人在双机部署 70B 模型后最关心的就是单并发输出速度到底每秒能生成多少 token回答这个问题之前先要理解大模型推理的性能瓶颈。在 decode 阶段也就是逐 token 生成阶段模型需要把全部权重从内存中读取一遍参与每一轮计算。相比计算量权重读取对内存带宽的需求更为突出。换句话说单并发推理的极限速度很大程度上取决于“在多长时间内把模型权重完整读一遍”。6.2 理论估算方法假设一个 70B 模型以 4bit 量化保存权重总量大约为 35GB。如果单台 DGX Spark 的统一内存带宽在 250GB/s 量级具体数值请以官方规格表为准那么单机每生成一个 token理论最低耗时约为35GB / 250GB/s ≈ 0.14 秒换算成吞吐就是大约 7 token/s 的上限。这只是一个纯读取权重的理论值实际还会叠加计算开销、KV Cache 访问、框架调度等所以真实值通常低于这个数字。6.3 双机张量并行的理论收益使用张量并行、把模型切分到两台设备时每台设备只需要读取自己负责的那一半权重。每台设备读取量35GB / 2 17.5GB 理想读取耗时17.5GB / 250GB/s ≈ 0.07 秒如果不考虑通信开销双机单并发吞吐可以达到约 14 token/s。但这个理想值无法完全实现因为每次前向计算都需要通过集群网络同步中间结果。假设每一次通信需要 20 到 40 毫秒那么实际耗时就在 0.09 到 0.11 秒之间对应的吞吐大约在 9 到 11 token/s。所以双机张量并行对单并发吞吐的提升通常不是严格的 2 倍而是接近 1.3 到 1.8 倍具体取决于互联带宽、模型量化精度和框架实现。6.4 如何实测真实吞吐理论估算只能帮你做容量规划真实环境必须依赖实测。vLLM 启动后直接向 API 发送多次请求统计生成 token 总数和总耗时即可。# 使用 curl 请求 10 次统计总耗时然后计算平均 token/s time for i in $(seq 1 10); do curl -s http://192.168.100.10:8000/v1/chat/completions \ -H Authorization: Bearer local-test \ -H Content-Type: application/json \ -d { model: /data/models/qwen-70b-awq, messages: [{role: user, content: 写一段关于人工智能发展的短文}], max_tokens: 512 } | jq -r .usage.completion_tokens done通过多次请求取平均值可以得到相对稳定的单并发吞吐数据。测试时要注意预热前几次请求可能包含权重加载、CUDA kernel 初始化等额外耗时正式统计时先发几个请求预热再开始计时结果更有参考价值。总的来说如果你在网上看到有人提到“两台 DGX Spark 张量并行跑 70B 模型单并发输出大约在 8 到 15 token/s”这个量级是符合内存带宽模型的。实际数字会因为量化位宽、上下文长度、模型架构、框架版本和网络质量的不同而变化不必纠结于某个具体数字。7. 常见问题与排查思路7.1 高频问题与处理对照表双机互联和分布式推理涉及网络、系统驱动、运行时、框架四个层面任何一层出现问题都可能导致集群不可用。下面以表格形式梳理高频问题方便快速定位。问题现象常见原因排查与解决思路两台设备互相 ping 不通线缆未插好、接口选错、IP 冲突检查线缆与接口确认 IP 是否在同一网段关闭无关网卡SSH 连接失败sshd 未启动、防火墙拦截、密钥权限错误检查 sshd 服务状态放通 22 端口修复密钥目录权限NCCL 初始化超时/etc/hosts 未配置、防火墙拦截通信端口、master 地址不可达补齐 hosts放通分布式通信端口用NCCL_DEBUGINFO查看日志分布式测试耗时异常高实际走了以太网回环或降速链路用ethtool检查网卡速率用iperf3验证带宽vLLM 启动时找不到足够的 GPURay 集群未正确加入或--tensor-parallel-size大于实际可用 GPUray status确认节点数检查CUDA_VISIBLE_DEVICES环境变量推理时显存/内存不足模型权重太大、KV Cache 过大、并发请求过多降低--max-model-len减少并发数换更低量化位宽双机推理反而比单机慢通信开销过大、网络带宽不足、量化后 GPU 计算占比变高检查网络带宽考虑使用流水线并行替代张量并行或减少并行度7.2 NCCL 调试日志的使用方法当 NCCL 通信出现异常时最有效的排查方式就是打开调试日志。# 在启动 torchrun 或 vllm 前设置环境变量 export NCCL_DEBUGINFO # 如果需要更多细节可以设置为 TRACE # export NCCL_DEBUGTRACE日志中会显示 NCCL 选择了哪个网络接口、连接了哪个 IP、在哪一步超时。看到类似NET/IB的日志表示 NCCL 尝试使用 InfiniBand 或 RoCE 设备看到NET/Socket则说明当前使用的是传统 TCP Socket。生产环境排错时先明确这条信息能帮你快速判断问题出在物理链路还是协议配置上。7.3 防火墙与端口放通建议分布式训练与推理需要放通多类端口。这里整理一份常见端口清单具体端口号可能因框架版本不同而变化请以实际配置为准。服务默认端口说明SSH22远程登录Ray Head6379集群协调vLLM API8000OpenAI 兼容接口torchrun 主节点29500PyTorch 分布式协调NCCL 动态端口随机高端口建议先NCCL_DEBUGINFO看实际端口在两台设备互相通信时优先保证这些端口在集群内部网段可以访问。如果公司网络存在安全组或防火墙务必在测试环境中先验证规则再上生产。8. 最佳实践与工程建议8.1 网络与拓扑层面的建议双机互联的稳定性直接决定分布式推理的上限。建议把集群组网独立到专用网段不要与办公网络共用广播域。固定 IP 之后务必写入/etc/hosts避免依赖 DHCP 分配产生地址漂移。如果业务对延迟敏感优先考虑直连拓扑减少交换机转发跳数。如果使用交换机确保交换机端口速率与网卡匹配不要出现千兆网口接万兆网卡导致降速的问题。有条件的话建议开启对称巨型帧支持Jumbo Frame但需要同时确认交换机、网卡和驱动都支持并保持两端 MTU 一致否则反而会引发分片问题。8.2 模型与数据管理建议多机推理时模型权重建议直接放在每台设备的本地 NVMe 存储中。虽然通过 NFS 共享权重看起来很省事但训练或推理启动时会并发读取大量文件NFS 很容易成为瓶颈。如果必须使用共享存储可以考虑只在启动阶段复制权重到本地推理过程中不要依赖共享存储。另外建议建立规范的模型目录结构。例如统一使用/data/models/模型名-量化精度的形式并在启动脚本中通过环境变量传入模型路径避免在多台设备上路径不一致导致服务启动失败。# 推荐在启动脚本中显式定义环境变量 export MODEL_PATH/data/models/qwen-70b-awq export TENSOR_PARALLEL_SIZE2 export API_KEYlocal-test统一变量管理减少手动改命令导致的低级错误。8.3 监控与日志管理双机集群的运维复杂度高于单机。建议至少配置以下监控项GPU 利用率与温度nvidia-smi dmon统一内存使用率nvidia-smi中的 Memory-Usage网络吞吐iperf3或nload推理服务日志vLLM 的访问日志与错误日志可以使用 systemd 管理推理服务保证服务异常退出时能自动重启。日志输出到文件后配合logrotate做轮转避免日志文件无限增长占满磁盘。8.4 安全与运维边界涉及生产环境的多机集群变更务必遵循最低权限原则。日常维护使用普通用户只有安装软件和修改系统配置时才使用 sudo。SSH 登录建议全部改为密钥认证并禁止密码登录。推理服务不要直接暴露到公网。如果业务需要远程访问通过企业内部网络或安全网关转发并在网关层做访问控制和审计。模型权重和训练数据属于敏感资产建议定期备份备份文件加密存储。9. 总结与下一步本文完整梳理了使用 NVIDIA Sync 连接两台 DGX Spark 的整个流程。从概念层面看NVIDIA Sync 不是单一命令而是物理连接、网络配置、分布式运行时和应用框架四个层次的协同。从操作层面看固定 IP、SSH 免密、NCCL 验证、Ray 集群、vLLM 张量并行是五个关键步骤每一步都有对应的验证方法和常见问题。如果你刚开始接触双机部署建议按照下面几步继续深入先用 7B 或 13B 规模的模型跑通全流程确认 NCCL 通信正常再切换到 70B 量化模型实测张量并行下的单并发吞吐最后再挑战 200B 级别模型并结合多并发压测观察集群的吞吐上限。每一步都记录实际数据和日志遇到问题及时对照官方文档和社区资料。双机部署最大的价值不是简单地把算力翻倍而是让你在本地环境中提前积累分布式推理的工程经验。把 70B 模型跑通之后你已经基本掌握了多机协同的核心链路后续扩展到 4 台、8 台设备时本质上只是在重复“组网 → 验证 → 启动服务 → 监控调优”这套流程。如果本文对你有帮助可以收藏备用。后续我也会持续关注 DGX Spark 相关的性能调优和部署实践欢迎一起