Quantum-2 QM9700 组网前怎么算端口：NDR 400G、分拆与扩容预留
从服务器端点、rail 数量、交换层级、OSFP 物理笼口、逻辑端口、分拆链路和扩容余量出发，说明 Quantum-2 QM9700 的端口规划方法。
Quantum-2 网络的端口数不能从 GPU 总数直接得出。需要先确定服务器数量、每台服务器接入端口、rail 数量、叶脊层级和目标收敛比，再把逻辑链路换算为交换机物理笼口、分拆线缆和模块数量。
NVIDIA Quantum-2 提供最高 400Gb/s 的 InfiniBand 连接能力。实际 BOM 中最容易混淆的是“OSFP 物理笼口”和“可用逻辑端口”，尤其在一拖二分拆和 200G 端点并存时，若不先画逐链路表，交换机端口、线缆和服务器网卡数量很容易对不上。
先算服务器侧端点
设服务器数量为 N，每台服务器在一个计算平面使用 P 个网卡端口，计算平面数量为 R，则基础下行链路数为 N × P × R。这里的 P 指实际接入网络的端口，不是 GPU 数量。8 卡服务器可能使用 1、2、4 或更多网络端口，取决于通信模型、rail 设计和性能目标。
例如 32 台服务器、每台每个平面 1 个端口、双平面部署，基础下行链路为 64 条，并分别落在两个故障域中。两个平面的端口和线缆应分开计算，不能先合并后再平均分配。
把四种数量分开记录
| 数量 | 含义 | 为什么不能混用 |
|---|---|---|
| 服务器端口 | 网卡上实际启用的网络端口 | 决定下行链路和服务器侧线缆端 |
| 逻辑交换端口 | 配置后参与网络的 400G/200G 等端口 | 可能由一个物理笼口分拆产生 |
| 物理笼口 | 交换机面板上的 OSFP 连接位置 | 决定模块或线缆主端数量 |
| 链路与分支 | 端到端连接及一拖二后的独立分支 | 决定线缆、标签和验收记录数量 |
分拆只解决端口形态，不自动解决带宽规划
400G 交换端口分拆为多个较低速率分支时，应同时核对交换机支持的分拆模式、服务器网卡速率、线缆 OPN 和子端标识。分拆后的每个逻辑端口都要在配置、布线和监控中保持唯一关系。
不能把一条分拆线缆只记为一个物料，也不能按物理笼口数量估算服务器端口。逐链路表应明确主端、分支 A/B、目标服务器、网卡端口和最终速率。
再计算 Spine 上联
Leaf 层确定后，Spine 上联数量取决于 Leaf 数量、每台 Leaf 的下行带宽、目标收敛比和故障模型。训练网络若要求接近无阻塞，不能只保证总上联带宽相等，还要检查 ECMP 路径、作业放置和单个故障后的剩余容量。
Rail-Optimized 设计还要确认同一 rail 的 GPU 通信是否按计划落在对应交换平面。端口总数正确但服务器接线顺序错误，仍会导致流量跨越非预期路径。
扩容预留应落到具体位置
笼统写 20% 预留不够。预留必须能回答“预留在哪台设备、哪个端口、对应哪批服务器”，否则到扩容阶段仍需要重新设计。
- 预留服务器端口：对应未来节点和确定的机柜位置。
- 预留交换机笼口：确认是否需要提前配置分拆模式。
- 预留 Spine 容量：检查新增 Leaf 后的上联和故障余量。
- 预留模块与线缆：按长度、接口、速率和备件类型分别统计。
- 预留电力与散热：避免端口可用但机柜条件无法支持扩容。
验收时按端口表逐项闭环
验收先比对物料、端口配置和现场布线，再检查链路速率、宽度、错误计数、分区和子网管理状态。随后执行 RDMA 与多节点通信测试，并记录每个平面在正常、单链路故障和单交换机故障下的结果。
端口规划表应在项目结束后继续作为扩容和故障定位基线。只有图纸、BOM、配置和现场标签使用同一套端口编号，后续变更才不会失去可追溯性。