双节点 NVIDIA DGX Spark 组集群：200GbE 看起来很快，但 NCCL 才说明真相

最近我测试了双节点 NVIDIA DGX Spark 集群，目标是通过高速 QSFP / ConnectX-7 直连端口跑通大模型推理，并判断这套互联方案能否支撑 vLLM 实际服务。简短结论：物理链路表现优秀，但对 LLM 推理真正有意义的数字，并不是规格表上那个。

测试环境

两台 NVIDIA DGX Spark，通过 QSFP / ConnectX-7 高速端口直连：

节点	IP
dgxse01	192.168.10.1
dgxse02	192.168.10.2

两台节点的 RDMA 接口配置：

配置项	值
网络接口	enp1s0f0np0
RDMA 设备	rocep1s0f0
GID 索引	3

目标负载：通过 vLLM + Ray 分布式后端推理 Qwen3.5-122B-A10B-FP8。

第一步：确认物理链路

在测试 RDMA 或 NCCL 之前，先确认 QSFP 链路以满速完成协商：

ethtool enp1s0f0np0 | grep -E "Speed|Link detected"

结果：

Speed: 200000Mb/s
Link detected: yes

200GbE 确认。这只说明物理层健康——对于 NCCL 应用层能达到多少带宽，这一步完全不说明任何问题。

第二步：原始 RDMA 带宽

接下来用 ib_write_bw 测量原始 RDMA 写带宽，这是 InfiniBand / RoCE 链路最常用的基准测试工具。

dgxse01（服务端）：

ib_write_bw -d rocep1s0f0 -F --report_gbits -s 1048576 -q 8 -b

dgxse02（客户端）：

ib_write_bw -d rocep1s0f0 -F --report_gbits -s 1048576 -q 8 -b 192.168.10.1

结果：

BW average: ~197 Gb/s

换算成 GB/s：197 / 8 ≈ 24.6 GB/s

在 RDMA 层，两台 Spark 之间的连接健康，非常接近 200GbE 理论上限。

第三步：NCCL All-Reduce 带宽

原始 RDMA 带宽是必要条件，但不是充分条件。vLLM 这类框架使用 NCCL 进行 GPU 间集合通信——NCCL 集合带宽与点对点 RDMA 带宽是两回事。

我用 nccl-tests 测量了跨两节点的 all_reduce_perf：

cd /opt/nccl-tests
mpirun --allow-run-as-root -np 2 \
  -H 192.168.10.1:1,192.168.10.2:1 \
  --bind-to none \
  --map-by slot \
  --mca oob_tcp_if_include enp1s0f0np0 \
  --mca btl_tcp_if_include enp1s0f0np0 \
  -x NCCL_SOCKET_IFNAME=enp1s0f0np0 \
  -x NCCL_IB_DISABLE=0 \
  -x NCCL_IB_HCA=rocep1s0f0 \
  -x NCCL_IB_GID_INDEX=3 \
  -x NCCL_IB_TC=106 \
  -x NCCL_IB_PCI_RELAXED_ORDERING=1 \
  /opt/nccl-tests/build/all_reduce_perf -b 8M -e 4G -f 2 -g 1

结果：

Avg bus bandwidth: ~10.2 GB/s

约为原始 RDMA 带宽的 40%。NCCL 日志显示走的是正确路径：

NCCL INFO NET/IB
GID 3
devName=rocep1s0f0

NCCL 没有回退到 TCP Socket，确实在用 NET/IB。带宽下降不是配置错误导致的。

第四步：NCCL Send/Recv 带宽

vLLM 的流水线并行（Pipeline Parallelism）依赖的是点对点 send/recv，而非 all-reduce。我单独测试了这一路径：

cd /opt/nccl-tests
mpirun --allow-run-as-root -np 2 \
  -H 192.168.10.1:1,192.168.10.2:1 \
  --bind-to none \
  --map-by slot \
  --mca oob_tcp_if_include enp1s0f0np0 \
  --mca btl_tcp_if_include enp1s0f0np0 \
  -x NCCL_SOCKET_IFNAME=enp1s0f0np0 \
  -x NCCL_IB_DISABLE=0 \
  -x NCCL_IB_HCA=rocep1s0f0 \
  -x NCCL_IB_GID_INDEX=3 \
  -x NCCL_IB_TC=106 \
  -x NCCL_IB_PCI_RELAXED_ORDERING=1 \
  /opt/nccl-tests/build/sendrecv_perf -b 8M -e 4G -f 2 -g 1

结果：

sendrecv_perf: ~9 GB/s

点对点性能和 all-reduce 几乎没有差距。在这套互联上，PP=2 不能保证比 TP=2 快。

第五步：理解 `GDR 0`

NCCL 日志中最关键的一行：

Connected all rings, use ring PXN 0 GDR 0

GDR 0 表示 NCCL 走的是 RDMA 网络路径，但未启用 GPUDirect RDMA。GPUDirect 未激活时，GPU 张量数据必须经过系统内存才能到达网卡——多了一次 PCIe 拷贝，而 ib_write_bw 的测试完全绕过了这一步。

这就是两者差距的根本原因：

层级	带宽
ib_write_bw（原始 RDMA）	~24.6 GB/s
NCCL all_reduce_perf	~10.2 GB/s
NCCL sendrecv_perf	~9 GB/s

ib_write_bw 测的是主机到主机的 RDMA，以满速运行。NCCL 传输的是 GPU 张量——在 GPUDirect 未启用的情况下，这是本质不同的数据路径。

第六步：vLLM 部署策略

Ray 正确识别了两节点：

Active nodes: 2
Total GPU:    2

将 Qwen3.5-122B-A10B-FP8 拆分到两台 Spark 上，有两种并行策略：

方案 A：张量并行（TP=2）

tensor-parallel-size: 2
pipeline-parallel-size: 1

每一层在两台机器上水平切分。每次前向传播都需要跨节点 all-reduce。~10.2 GB/s 的 all-reduce 带宽可以支撑 TP=2 运行，但对于 122B 模型，每层通信开销不可忽视。

方案 B：流水线并行（PP=2）

tensor-parallel-size: 1
pipeline-parallel-size: 2

每台机器负责连续的若干层，跨节点通信只发生在流水线阶段边界。我最初预期 PP=2 会明显占优，但实测 sendrecv_perf ~9 GB/s，与 all-reduce 几乎相同，优势并不显著。

务实建议： 两种方案都跑一遍，使用相同 prompt、相同上下文长度、相同输出长度，以实际 token/s 决定。

基线汇总

层级	指标	结果
物理层	链路速度	200GbE
物理层	链路状态	已连接
RDMA	ib_write_bw	~197 Gb/s（~24.6 GB/s）
NCCL	版本	2.28.9
NCCL	传输路径	NET/IB（rocep1s0f0，GID 3）
NCCL	GPUDirect	GDR 0（未启用）
NCCL	all_reduce_perf	~10.2 GB/s
NCCL	sendrecv_perf	~9 GB/s
vLLM	Ray 节点	2 节点，2 GPU

结论

双节点 DGX Spark 集群通过 200GbE / ConnectX-7 链路顺利组网。原始 RDMA 带宽表现优秀，接近 200GbE 理论上限。网络本身没有问题。

但核心结论很简单：

200GbE 不等于 NCCL 能跑到 25 GB/s。

大模型推理涉及四个不同的性能层次——物理链路速度、原始 RDMA 带宽、NCCL 集合带宽、vLLM 实际 token/s——相邻两层之间可以相差 2 到 3 倍。

在这套配置下，vLLM 实际可用的 GPU 通信带宽约为 9–10 GB/s，而非 25 GB/s。这才是真正的设计约束。针对两台 Spark 上的 122B FP8 模型，请在实际服务负载下分别测试 PP=2 和 TP=2，再决定并行策略。

测试时间：2026 年 6 月 19 日。NCCL 2.28.9，vLLM + Ray。模型：Qwen3.5-122B-A10B-FP8。