企业官网建设流程全解析

如果你只有一台 DGX Spark，本地跑 200B 模型这件事已经足够让人兴奋。但只要真正把模型加载进去、开始连续对话，很多人会发现问题并没有想象中那么轻松：单机的统一内存再大，也经不住长上下文、大并发和持续推理的消耗；算力再强，一次只能干一条流水线的话，吞吐依然会被卡住。

于是，“能不能再加一台 DGX Spark，把两台机器连成一个集群”就成了很自然的下一步。这个问题在社区里讨论度很高，尤其是想用两台 DGX Spark 做张量并行、跑 70B 模型的人，几乎都会问：到底怎么连？需要什么配置？单并发下每秒能输出多少 token？

这篇文章就是围绕“用 NVIDIA Sync 连接两台 DGX Spark”展开。先说结论：连接两台机器不是插一根网线、跑一个脚本就能完事，它需要你同时处理好网络链路、NCCL 集合通信、容器环境和推理引擎四个层面的配置。文章不会依赖某个虚构的“一键同步命令”，而是把从物理连接、IP 规划、通信验证，到 70B 模型张量并行推理、性能基准测试的完整路径拆开讲清楚。读完你不仅能搭起来，还能判断“两台机器到底值不值得连”。

1. 为什么要连接两台 DGX Spark，而不是只买一台更大的机器

先理解单机的边界。DGX Spark 的定位是个人 AI 超级计算机，内置 Grace Blackwell 架构芯片和较大容量的统一内存，出厂目标是让开发者在桌面上直接跑数百亿甚至千亿级参数的模型。单机确实能“放进去”一个 200B 模型，但“能放进去”和“能跑好”之间有一条明显的性能鸿沟。

当你做推理时，内存不仅要放模型权重，还要放激活值、KV Cache 和临时计算张量。模型越大，上下文越长，KV Cache 增长越快。单机推理场景下，一旦上下文序列变长，内存就会被迅速占满，吞吐也随之下降。更麻烦的是，如果你还想同时服务多个请求，单机的算力和内存带宽会成为双重瓶颈。

这时两台 DGX Spark 的价值就出来了：

• 把 70B 甚至更大模型的权重分散到两台机器的显存/统一内存中，降低单机内存压力。
• 让两个 Grace Blackwell 芯片同时参与同一层计算，理论上提升推理吞吐。
• 为后续扩展到更多节点提供基础能力，形成一个小型本地算力池。

但也必须清醒：多机互联不是免费的。两机之间的通信延迟和带宽，永远比单机内部芯片间通信高一个量级。如果模型较小、单机已经跑得很快，强行做张量并行反而可能因为通信开销而得不偿失。所以“两台 DGX Spark 连接”最适合的场景是：模型超过单机理想工作负载，或者对并发/吞吐有明确要求。

2. 核心概念：NVIDIA Sync、DGX Spark 与张量并行

2.1 DGX Spark 是什么

DGX Spark 是 NVIDIA 推出的小型个人 AI 工作站产品，核心是一颗高度集成的超级芯片，配合高带宽统一内存。它的意义在于把过去需要一台服务器才能完成的 AI 推理/微调工作，压缩到桌面级设备里。正因为单机能力已经很强，用户才会进一步想通过多机组合来突破单机瓶颈。

2.2 NVIDIA Sync 是什么

NVIDIA Sync 是面向多台 DGX 设备协同计算的通信与同步方案。它解决的核心问题不是“把两台机器用网线连上”，而是“让两台机器在分布式计算时保持步调一致”。

分布式训练和推理中，多个节点必须频繁交换梯度、张量、中间状态。如果节点的时钟不同步、通信协议不一致、集合通信配置错误，轻则性能大幅下降，重则训练直接卡死或启动失败。NVIDIA Sync 的本质就是一套面向这类场景的同步和通信机制，底层依赖高速网卡驱动和 NCCL（NVIDIA Collective Communications Library）集合通信库。

需要特别注意：不同 DGX 系统版本、不同驱动版本对应的同步工具命令和配置方式可能有差异。本文会避开那些可能因版本而变的私有命令，重点讲通用配置流程。只要网络、NCCL、容器环境正确，不管当前 NVIDIA Sync 的具体实现是什么，都能顺利跑通。

2.3 张量并行、流水线并行、数据并行怎么选

多机部署大模型时，有三种典型并行策略：

两台 DGX Spark 组合时，最常见的诉求是跑 70B 级模型推理。70B 模型如果使用 4-bit 量化，权重大约 40GB，单台 DGX Spark 的内存通常能放下，但推理速度和并发能力受限；如果使用 FP16/BF16，权重就接近 140GB，单机压力极大，这时候张量并行几乎成为必选项。

张量并行的核心逻辑是：一个 Transformer 层的矩阵乘法，可以被拆成多个 GPU 各自计算一部分，最后通过 AllReduce 汇总结果。这个过程每一次矩阵计算都伴随至少一次多机通信。所以张量并行对网络要求很苛刻，这也就是为什么连接两台 DGX Spark 时，网络配置和 NCCL 参数不能随便填。

3. 连接前的硬件与软件检查清单

在接任何线缆或输入任何命令之前，先做一轮检查。多机环境排错最痛苦的地方是“不知道问题是出在硬件、驱动、网络还是软件配置”，而前置检查能把问题范围快速缩小。

3.1 检查硬件状态和驱动

在两台机器上分别执行：

nvidia-smi

这个命令会输出 GPU 名称、驱动版本、CUDA 版本、显存使用情况。DGX Spark 的 GPU 应该正常显示，并且驱动版本尽量保持一致。如果两台机器的驱动版本不一致，分布式环境偶尔会出现奇怪的行为。

再检查高速网卡是否被系统识别：

lspci | grep -i mellanox lspci | grep -i ethernet

如果这台 DGX Spark 使用 ConnectX 系列网卡，Mellanox 关键字会出现在输出中。这一步是为了确认网卡驱动已经加载，而不是只有一块普通的板载网卡。

3.2 检查现有网络接口

ip link show ip addr show

输出中通常会看到多个网络接口。其中至少有一个接口用于管理网络（你可能用它 SSH 登录设备），还有一个接口是专门用于高速互连的。建议把“管理网络”和“高速互连网络”分离开，避免大数据通信时把管理流量也挤占掉。

如果你的环境支持 InfiniBand，还可以用：

ibstat 2>/dev/null || echo "no ibstat or no IB"

ibstat会显示 InfiniBand 设备状态和端口速率。如果命令不存在说明系统没有安装 InfiniBand 工具包，但不代表网卡不可用，因为同一块 ConnectX 网卡也可以工作在以太网（RoCE）模式下。

3.3 检查容器运行时和 NVIDIA 组件

推荐在两台机器上使用完全相同的容器镜像和软件栈。先确认 Docker 和 NVIDIA Container Toolkit 是否正常：

docker --version nvidia-container-runtime --version 2>/dev/null || nvidia-container-toolkit --version 2>/dev/null || echo "container runtime not found"

从实际经验看，DGX 类设备出厂通常已经预装好驱动的容器运行时。如果你拿到的是底层的 Server 版本系统，可能需要手动安装nvidia-container-toolkit。这一步务必先确认，否则后面启动容器时会报 GPU 不可用。

3.4 同步系统时间

分布式集群对时间同步非常敏感。即使 NCCL 不要求绝对严格的时间同步，节点间时钟偏差过大也会影响日志排查、证书校验和应用层逻辑。

timedatectl status sudo timedatectl set-ntp true

两台机器最好使用同一个 NTP 服务器。

4. 物理连接与基础网络配置

4.1 选择直连还是交换机连接

两台 DGX Spark 的高速互连，可以有两种拓扑：

• 直连：用一根足够高速的网线/光纤直接连接两台机器的高速网卡。
• 交换机连接：两台机器分别接到同一台交换机。

直连的优势是延迟更低、少一跳；缺点是只能连接两台，后续扩展要重新改线。交换机的优势是便于扩展到 3 台、4 台甚至更多节点，且链路管理更规范。如果你明确只组两机集群，优先直连；如果打算以后继续加机器，优先交换机。

4.2 静态 IP 规划

高速互连网段不要使用 DHCP，建议规划一个固定子网。例如：

这里把 192.168.10.0/24 专门留给高速互连，避免它与管理网络冲突。

4.3 使用 netplan 配置静态 IP

Ubuntu 或 DGX OS 通常使用 netplan。创建配置文件/etc/netplan/10-dgx-sync.yaml：

network: version: 2 ethernets: eth1: dhcp4: no addresses: - 192.168.10.1/24 routes: - to: 192.168.10.0/24 scope: link mtu: 9000

这里假设高速互连接口名是eth1。实际操作时，请用第 3 章ip link show看到的实际接口名替换。MTU 设置到 9000（Jumbo Frame）可以降低大数据包传输时的 CPU 开销，但需要交换机或对端网口同样支持，并且两端 MTU 一致，否则会出现分片或丢包。

应用配置：

sudo netplan apply

在 node-b 上做类似配置，IP 改为 192.168.10.2。

4.4 验证网络连通性

先确认基本联通：

ping -c 4 192.168.10.2

如果 ping 不通，先查网线、接口名、IP 配置、防火墙。两机的防火墙如果开着，需要放行内部互连网段的通信：

sudo ufw status sudo ufw allow from 192.168.10.0/24

然后检查端口速率和 MTU：

ip link show dev eth1

如果看到mtu 9000，并且状态是UP，说明链路层正常。

4.5 高速网络带宽测试

分布式训练和推理对带宽非常敏感。建议在配置完成后做一次裸带宽测试。如果环境里有iperf3：

在 node-b 启动服务端：

iperf3 -s

在 node-a 启动客户端并打满 60 秒：

iperf3 -c 192.168.10.2 -t 60 -P 8

如果支持 InfiniBand/RoCE，还可以使用：

ib_write_bw -d mlx5_0

命令会显示双向带宽。这一步的关键不只是看数值，而是确认链路能达到预期速率。如果吞吐异常低，大概率是 MTU 不一致、网卡驱动没有启用 RDMA 或线缆、模块有问题。不要带着一个低带宽链路继续往下配置，否则张量并行性能会很差。

5. 容器环境与 NCCL 通信配置

5.1 拉取统一的 PyTorch NGC 容器

推荐在两台机器上使用相同标签的 NGC PyTorch 容器。NGC 容器的好处是预装了 CUDA、NCCL、PyTorch 和常见分布式工具，能省去大量手动编译的环节。

docker pull nvcr.io/nvidia/pytorch:latest

如果你更看重稳定复现，可以指定一个固定标签。具体标签请以 NGC 目录当前列表为准，不要在文档里把一个不确定的版本写死。

5.2 启动容器并传递 NCCL 环境变量

在 node-a 和 node-b 上分别启动容器。启动命令要保持一致，除了网络参数外，尽量做到环境一致：

docker run -it --rm \ --gpus all \ --ipc=host \ --ulimit memlock=-1 \ --ulimit stack=67108864 \ --network host \ -e NCCL_SOCKET_IFNAME=eth1 \ -e NCCL_IB_DISABLE=0 \ -e NCCL_DEBUG=INFO \ -v /mnt/models:/models \ nvcr.io/nvidia/pytorch:latest \ bash

解释关键参数：

需要注意：NCCL_IB_DISABLE这一项取决于你的实际链路模式。如果你的两台机器通过普通以太网连接，且没有启用 RoCE，可以显式设置为NCCL_IB_DISABLE=1，让 NCCL 走 TCP socket 通信，避免它反复探测 IB 设备超时。

6. 用 torchrun 验证分布式通信是否正常

在正式跑 70B 模型之前，先用一个最小分布式程序验证两机通信。

6.1 编写测试代码

创建文件test_dist.py：

import os import torch import torch.distributed as dist def main(): dist.init_process_group(backend="nccl") rank = dist.get_rank() world_size = dist.get_world_size() print(f"[Rank {rank}/{world_size}] CUDA available: {torch.cuda.is_available()}, device: {torch.cuda.get_device_name(rank)}") # 构造一个大张量，测试多机 AllReduce x = torch.ones(4096, 4096, dtype=torch.float32).cuda() dist.barrier() dist.all_reduce(x, op=dist.ReduceOp.SUM) print(f"[Rank {rank}/{world_size}] all_reduce sum = {x[0, 0].item():.0f}") dist.barrier() dist.destroy_process_group() if __name__ == "__main__": main()

这段代码做了三件事：

1. 初始化 NCCL 分布式环境。
2. 打印每个 rank 的编号和总节点数。
3. 在两个节点上各建一个 4096x4096 的 float32 张量，执行 AllReduce 求和。如果两机通信正常，两个位置的结果都应该是 2.0。

6.2 在 node-a 上启动分布式任务

容器内执行：

torchrun \ --nproc_per_node=1 \ --nnodes=2 \ --node_rank=0 \ --master_addr=192.168.10.1 \ --master_port=29500 \ test_dist.py

在 node-b 上执行相同的命令，但把--node_rank改为 1:

torchrun \ --nproc_per_node=1 \ --nnodes=2 \ --node_rank=1 \ --master_addr=192.168.10.1 \ --master_port=29500 \ test_dist.py

这里--master_addr指向 node-a 的高速互连 IP，--master_port是两机通信控制端口。推荐nproc_per_node=1，因为每台 DGX Spark 在一个容器里只需要暴露一个 rank，真正的大并行度通过多机实现。

6.3 预期输出与验证标准

如果配置正确，node-a 和 node-b 会交替输出类似日志：

[Rank 0/2] CUDA available: True, device: NVIDIA ... [Rank 1/2] CUDA available: True, device: NVIDIA ... [Rank 0/2] all_reduce sum = 2.0 [Rank 1/2] all_reduce sum = 2.0

验证标准有两条：

• 两边的 rank 都能打印出来，说明 master 地址、端口、通信链路都正常。
• AllReduce 结果等于 2.0，说明张量数据真的在节点间做了汇总，而不是各自跑各自的。

如果卡在初始化阶段，重点检查--master_addr是否能从 node-b 访问、NCCL_SOCKET_IFNAME是否指向了正确网卡、防火墙是否放行端口。

7. 在两台 DGX Spark 上部署 70B 模型张量并行推理

7.1 准备模型权重

先把 70B 模型权重放到两台机器都能访问的位置。最简单的做法是模型同时放在 node-a 和 node-b 的相同路径下，例如/mnt/models/Qwen2.5-70B-Instruct-GPTQ-Int4。如果有多台机器的扩展计划，推荐使用 NFS 或 Ceph 这类共享存储，让所有节点共享同一份权重文件，避免反复同步。

7.2 使用 vLLM 启动多机张量并行服务

vLLM 是当前比较主流的高性能推理框架，对多机张量并行支持也比较成熟。它需要借助 Ray 或者自身的分布式执行后端来做跨节点通信。下面是一个双节点部署示例，假设节点 A 的 IP 是 192.168.10.1，节点 B 的 IP 是 192.168.10.2。

先启动 Ray head 节点（在 node-a 上）：

ray start --head --port=6379 --dashboard-host=0.0.0.0

然后在 node-b 上加入该 Ray 集群：

ray start --address=192.168.10.1:6379

最后在 node-a 上启动 vLLM API Server：

python -m vllm.entrypoints.openai.api_server \ --model /mnt/models/Qwen2.5-70B-Instruct-GPTQ-Int4 \ --tensor-parallel-size 2 \ --distributed-executor-backend ray \ --ray-address 127.0.0.1:6379 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --host 0.0.0.0 \ --port 8000

参数说明：

这里假设两台机器上的 vLLM 、Torch、CUDA 版本完全一致。如果 vLLM 版本较老，可能不支持--distributed-executor-backend ray，需要参考当前版本说明替换为 TP 多机启动方式。

7.3 发一个推理请求验证

服务启动后，打开另一个终端向 node-a 发请求：

curl -s http://192.168.10.1:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "/mnt/models/Qwen2.5-70B-Instruct-GPTQ-Int4", "prompt": "用一句话解释分布式系统", "max_tokens": 128, "temperature": 0.7 }'

如果返回 JSON 中包含choices和生成文本，说明双机张量并行服务已经可以工作。

7.4 单并发输出多少 token 的真相

很多人关心“两台 DGX Spark 张量并行，70B 模型单并发输出多少 token”。这个问题没有一个固定答案，因为它取决于至少五个因素：

• 模型精度：FP16、BF16、INT8、INT4 对应的计算量和显存占用完全不同。
• 输入输出长度：输出越长，KV Cache 越大，计算量越大。
• 量化方案：GPTQ、AWQ、FP8 的 kernel 效率不一样。
• 互联带宽：张量并行每次矩阵乘法都要 AllReduce，网络越慢，性能掉得越厉害。
• vLLM 版本和调度策略：不同版本的 continuous batching 和 fusing kernel 差异很大。

更稳妥的做法是部署后自己测。可以使用 vLLM 自带的 benchmark 脚本：

python benchmarks/benchmark_serving.py \ --backend vllm \ --model /mnt/models/Qwen2.5-70B-Instruct-GPTQ-Int4 \ --tokenizer /mnt/models/Qwen2.5-70B-Instruct-GPTQ-Int4 \ --num-prompts 1 \ --output-len 256

把--num-prompts设为 1，就可以测到单并发下的输出吞吐。单位通常是tokens/s。真正上线前，建议分别测一次单机、一次双机，对比张量并行带来的收益。如果双机结果反而比单机低，不要惊讶，通信开销可能超过了计算收益，这时需要重新评估模型量化和网络优化策略。

8. 常见问题与排查思路

多机分布式环境的问题往往不是单点故障，而是多个环节叠加。常见的排查顺序是：链路层 → 网络层 → NCCL → 应用层。

对于第一次接触分布式推理的开发者，建议在运行 70B 模型之前，先用前面第 6 章的 AllReduce 测试验证通信，再跑一次小模型的单机 vLLM，最后才切到 70B 模型。这样每一步失败都能快速定位，而不是面对一长串错误日志无从下手。

9. 最佳实践与工程建议

9.1 网络规划要早做

两台机器互联很简单，但不要忽略后续扩展。建议从一开始就把高速互连网段、管理网段、存储网段分开，并写入网络规划文档。IP 地址固定，不要依赖 DHCP。所有节点的主机名和 IP 映射写入/etc/hosts，避免分布式框架解析主机名时出错。

192.168.10.1 node-a 192.168.10.2 node-b

9.2 环境一致性是稳定性的前提

两台的驱动版本、CUDA 版本、NGC 容器标签、Python 包版本、vLLM 版本尽量完全一致。最省心的方式是维护一份requirements.txt或直接使用同一个容器镜像。环境不一致带来的问题往往很隐蔽，比如张量并行在某些层上计算正常，在某些层上出现NaN或崩溃。

9.3 模型权重与数据的安全管理

模型权重文件往往很大，建议集中放在共享存储中，并做好只读挂载。不要在每次启动时往节点里拷贝大文件。推理服务如果需要对外暴露，不要直接监听公网 IP，最好放在内网并通过 API 网关或 SSH 隧道访问。对模型文件设置严格权限，避免未授权用户覆盖或删除权重。

9.4 监控与日志不可少

分布式推理比单机复杂得多，必须有监控。推荐部署 NVIDIA DCGM。DCGM 是 NVIDIA 官方的数据中心 GPU 管理工具，能采集 GPU 利用率、显存使用、温度、带宽等信息。配合 Prometheus 和 Grafana，可以在一个面板上同时查看两台 DGX Spark 的状态。

启动 nvidia-smi 的实时监控模式也可以临时观察：

nvidia-smi dmon -s pum

这个命令会周期性刷新 GPU 利用率、显存读写和功耗。如果张量并行推理时某个节点利用率明显低于另一个，优先检查网络通信是否成为瓶颈。

9.5 上线前先做基准测试和回滚方案

不要一上来就切换生产流量。先用小并发、短上下文跑通全链路，记录单机性能和双机性能，确认双机收益符合预期后再扩大。配置变更前备份当前正常的 Docker 启动命令、环境变量清单和权重文件列表。由于多机环境依赖项多，一旦改挂，快速恢复的最好方式不是现场排查，而是回滚到上一份验证过的配置快照。

9.6 明确适合场景，避免过度设计

最后一条建议可能最重要：如果不是模型真的超过单机承受能力，或者并发需求明确，两台 DGX Spark 互联的收益未必显著。70B 模型在量化后的单机推理，很多时候已经能跑。真正需要双机张量并行的，是那些单机内存放不下、或者需要高吞吐/低首 token 延迟的正式业务场景。先基准测试，再决定是否要加节点，比盲目堆硬件更省钱、更省时间。

10. 总结与后续学习方向

本文的关键在于把两台 DGX Spark 通过 NVIDIA Sync 互联这件事拆成了三层：物理网络层、NCCL 通信层、推理引擎层。物理网络层解决“两台机器能不能高速通信”，NCCL 层解决“分布式进程能不能步调一致地交换张量”，推理引擎层解决“70B 模型到底该怎么切到两个节点上”。只有每一层都验证通过，多机张量并行才能真正跑起来。

很多初学者会把精力集中在最后的 vLLM 命令上，却忽略了前面的网络验证和环境一致性。真正决定双机性能上限的，往往是那根高速网线的链路质量、MTU 是否对齐、NCCL 是否选择了正确的网络接口。如果你的集群搭完之后速度不理想，不要急着换推理框架，先回头检查通信链路。

下一步值得研究的方向有三个：一是更多节点的扩展，从两台到四台时网络拓扑会复杂得多；二是训练场景下的多机并行，数据并行与张量并行的组合调度；三是结合 NVIDIA DCGM 和 Prometheus 建立完整监控，把集群变成一个可运维的长期服务。建议先把本文第 6 章的 AllReduce 测试和三组 vLLM 基准数据跑出来，再决定要不要继续投入。