一台 DGX Spark 是强大的单节点推理主机。当模型和智能体工作负载无法容纳在一个 128 GB 相干内存池中，或需要跨节点张量并行服务时，NVIDIA 提供的扩展路径是通过 ConnectX-7 连接两台 Spark。
本文遵循 NVIDIA 官方描述的集群方案和 connect-two-sparks 操作手册，但不能替代接线当天的最新在线文档。
主要来源（从这里开始）：
- ConnectX-7 Networking / clustering（DGX Spark 用户指南）
- connect-two-sparks 手册
- NVIDIA Sync（Cluster Assistant）
- 产品上下文：DGX Spark · Spark 是什么 · 推理现实
重新配置网络可能隔离节点或中断管理访问。在更改 ConnectX-7 netplan 前，应先通过 10 GbE 或管理接口建立并保持一条确认可用的 SSH 路径。使用经批准的 QSFP 线缆；不要把方向错误的连接器强塞进端口，NVIDIA 文档明确指出这可能损坏端口。
你在构建什么
总体步骤如下：
- 用 QSFP 线缆将两台设备物理接入 ConnectX-7 端口（200 Gbps 级路径；线缆须至少支持 200 Gb/s）。
- 为该端口出现的 Linux 以太网接口分配 IP（每个 QSFP 端口映射到两个逻辑接口）。
- 在两台系统上使用相同用户名。
- 在节点之间建立免密 SSH。
- 在高速路径上运行分布式工作负载（面向多节点推理或训练配方的 NCCL / RoCE 流量）。
NVIDIA 的操作指南给出了时间和风险估计。应把它们视为供应商的规划参考，而不是对你的环境作出的承诺。实施变更前请重新阅读最新 README，因为接口说明和前提条件可能已经变化。
前置条件
来自官方手册：
| 要求 | 原因 |
|---|---|
| 两台 DGX Spark 系统 | 显而易见，但两台设备都需运行当前版本的 DGX OS |
| 一根 QSFP 电缆（直接 200GbE） | NVIDIA 文档说明单根电缆可实现满带宽；没有文档证明第二根电缆能提升吞吐量 |
| 两台设备上均具备 SSH 访问和 sudo 权限 | 配置和密钥分发 |
| 两台设备上的用户名相同 | 操作指南和发现脚本假定用户匹配 |
可选但很有帮助：安排第二个人关注管理 SSH 会话，并保存变更前 ip addr / ibdev2netdev 输出的书面记录。
路径 A：NVIDIA Sync Cluster Assistant
如果想减少手动配置 netplan 的工作，NVIDIA 提供了 NVIDIA Sync Cluster Assistant 这一引导式方案：
- 为受支持拓扑自动发现并创建网络。
- 应用 ConnectX-7 设置、检查链路性能，并配置节点间 SSH。
- 按 NVIDIA Sync / 集群文档，支持线缆直连最多三台 Spark，使用交换机时最多四台。
如果拓扑受支持，可以在笔记本上安装 Sync、添加 Spark，再用 Cluster Assistant 代替手工编写 YAML。物理布线规则、左右端口方向和接口命名背景仍须参阅 ConnectX-7 Networking。Cluster Assistant 减少的是手工配置，不会替代正确的线缆和回滚计划。
路径 B：手动手册（connect-two-sparks）
1. 相同用户名
whoami
如果用户名不同，应在两台系统上创建相同的用户（手册示例使用 nvidia），授予 sudo 权限，并以该用户继续。分布式配方和 SSH 密钥脚本都假定用户名一致。
2. 物理 QSFP 连接
- 在两台 Spark 之间插一根 QSFP 线缆。
- 遵循面向 NCCL 的手册时，优先每台设备上相同物理端口位置（NVIDIA 注明端口一致性以避免测试问题）。
- 拉环朝上；完全插入且不用力。
- 用
ibdev2netdev确认链路状态，期望相关接口显示 Up。
每个物理 QSFP 端口显示为两个 Linux 以太网接口（及对应 RoCE 设备）。来自 NVIDIA 手册的示例名称看起来像同一物理端口的 enp1s0f1np1 与 enP2p1s0f1np1，你的名称可能不同；应以你设备上的 ibdev2netdev 输出为准。
按 NVIDIA 集群文档，Spark 上的 QSFP 端口配置为以太网。使用 NVIDIA 列为适合 ≥200 Gb/s 的线缆。更快的线缆不会提高端口的 200 Gb/s 上限。
3. IP 配置
手册提供：
- 选项 1：netplan（
/etc/netplan/40-cx7.yaml）：重启后仍然生效；权限设为 600；运行sudo netplan apply。 - 选项 2：
ip addr add：便于快速试验；重启后 IP 配置会消失。
来自手册的示例寻址模式（将接口名调整为匹配你的 Up 接口）：
| 节点 | 接口 A | 接口 B |
|---|---|---|
| 节点 1 | 192.168.100.10/24 | 192.168.101.10/24 |
| 节点 2 | 192.168.100.11/24 | 192.168.101.11/24 |
上述两个地址属于同一有线端口的两个逻辑接口，因此单根电缆连接已使用两个子网。NVIDIA 的操作指南指出，仅使用一根 QSFP 电缆即可实现满带宽，其自身的 双 Spark 性能测试指南 测量了单根电缆上的 RoCE 带宽，并将该端口的两个链路相加，达到约 190 Gb/s，即 200 Gb/s 端口上限。操作指南中关于第二根电缆的唯一说明是配置要求：如果连接了两根电缆，则必须为所有四个接口分配 IP 地址，才能实现满带宽。NVIDIA 并未记录在相同两台设备之间添加第二根电缆可提升吞吐量，因此应将第二根电缆作为拓扑结构进行规划，例如添加第三个节点或交换式架构，而非为同一对设备增加带宽。
在调试 SSH 之前，在两边用 ip addr show <iface> 验证。
4. 免密 SSH
自动方式： 在其中一个节点运行手册中的 discover-sparks 脚本，发现对端并分发密钥（过程中可能要求输入一次密码）。
手动方式： 使用相同用户名，通过 ssh-copy-id 把公钥复制到两台节点的 ConnectX-7 IP。
验证：
ssh <node1-cx7-ip> hostname
ssh <node2-cx7-ip> hostname
5. 分布式工作负载与 RoCE
免密 SSH 和 L3 可达性是基础。多节点推理和训练配方随后依赖 ConnectX-7 / RoCE 路径完成集合通信（NCCL 等）。不要指望 Wi-Fi 7 或 10 GbE RJ-45 端口承载这套高速互连网络。
连通后的下一步通常在其他手册中（vLLM 多节点、NCCL 测试、特定模型配方）。在怪罪模型服务器之前，应使用与你的软件版本对应的 NVIDIA NCCL 或集群检查来验证集合通信。
接口命名坑（在写 YAML 之前读）
NVIDIA 的集群指南解释为何 Spark 的 ConnectX-7 布局会迷惑习惯“一块 NIC = 一个 eth0”的人：
- 每个 QSFP 端口有两条进入 SoC 的 PCIe 路径。
- 因此 Linux 为每个物理端口暴露两个以太网接口，加上对应 RoCE 设备。
- 手册示例（
enp1s0f1np1、enP2p1s0f1np1，…）仅供参考。线缆就位后，始终根据你的两台设备上ibdev2netdev的输出确定映射。
如果 netplan 引用了 Down 接口，却忽略状态为 Up 的那一对接口，你可能会白费一小时排查并不存在的“坏线缆”。首次启用时，可把集群文档中的对应表放在终端旁对照。
CX7 子网的安全备注
把 ConnectX-7 链路当作可信互连网络，而不是访客 Wi-Fi：
- 不要随意把它桥接到公司用户 VLAN。
- 限制哪些进程在那些 IP 上绑定 RPC / NCCL / 推理端口。
- 请记住，如果任一设备遭到入侵，节点间的免密 SSH 会成为强大的横向移动通道，因此必须相应保护物理访问和 OS 账户。
- 管理操作和人工 SSH 应继续走文档指定的管理路径，避免一次 CX7 配置错误导致完全失联。
风险、验证与回滚
| 风险 | 为何重要 | 控制 |
|---|---|---|
| netplan 中接口名错误 | 无链路或路由损坏 | 编辑前捕获 ibdev2netdev；不确定时一次改一侧 |
| 管理通道失联 | 你只配置了 CX7 并丢失 10 GbE SSH | 保持笔记本 Sync / 管理路径开放 |
| 用户名不一致 | SSH 与脚本莫名失败 | 先强制相同用户名 |
| 跳过 RoCE 验证 | 推理经错误 NIC 运行异常缓慢 | 确认 CX7 上的流量；运行 NCCL/链路检查 |
| 没有回滚记录 | 中断持续时间延长 | 保留变更前的 YAML 和 ip addr 转储 |
回滚设计（根据主机环境调整 NVIDIA 操作指南）：
- 在编辑之前，确认
/etc/netplan/40-cx7.yaml是否已存在，以及是否有其他 netplan 文件配置了相同的接口。备份相关文件并记录哈希值、所有权和权限。 - 不要盲目删除已有的文件。恢复更改前的原始文件，运行
sudo netplan generate，检查生成的结果，然后通过已知可靠的管理路径进行应用。 - 对于临时地址，只删除本次更改中明确添加的地址，并验证生成的路由和链路状态。
- 在两台节点均通过回滚后的 SSH 和路由检查之前，保持控制台或独立管理访问。
回滚会重置集群网络。若有人依赖多节点端点，应为此安排正式变更窗口。在删除配置之前确认管理 SSH 仍可用。
故障排除速查表
根据 NVIDIA 手册列出的症状整理：
| 症状 | 可能原因 | 修复方向 |
|---|---|---|
| 网络不可达 | 接口未配置 / netplan 未应用 | 重查 YAML、接口名、netplan apply |
| SSH 认证失败 | 密钥未分发 | 重跑 discover-sparks 或手动 ssh-copy-id |
| 对等方不可见 | 线缆、端口或 IP 不匹配 | 重插 QSFP；确认 Up 接口与子网 |
| NCCL / 分布式挂起 | 错误 NIC、防火墙或 SSH/MPI 设置 | 在配方中确认 CX7 IP；检查 RoCE 设备 |
现在还不要做这些
- 不要在 SSH 与链路检查通过前启动生产张量并行模型。
- 不要在重启间混合临时 IP 与遗忘的 netplan 文件。
- 不要把 CX7 子网暴露给不可信网络。
- 不要强塞 QSFP 连接器，或在未检查用户指南中的速度/兼容性说明时使用随机 DAC 线缆。
最小验收测试
在将智能体指向多节点端点之前：
- 两台节点均可在 CX7 子网中 ping 通。
- 以共享用户身份确认双向免密 SSH 可用。
- 文档指定的 NCCL 或操作手册链路检查通过。
- 服务配方中的节点列表使用 CX7 地址，而非 Wi-Fi IP 地址。
- 在维护窗口中测试了精确的备份和恢复步骤，且未丢失管理路径。
两台 Spark 加上一条经批准的 QSFP 链路，是 NVIDIA 有文档记录的方案。本文中的启用和回滚命令遵循供应商文档，但并不代表你的硬件、布线或软件版本已经通过认证。任何新的高速互连启用都应作为受变更控制的网络切换来实施，收集你自己的验收证据；只有这套互连通过上述测试后，再继续评估本地推理的现实限制。
