规划 NDR 叶脊网络时，最容易出现的错误是用交换机端口总数除以每台服务器网卡数，直接得到节点规模。这个算法没有扣除叶交换机上联、跨轨连接、管理与测试端口，也没有说明故障时是否仍满足目标带宽。对于多轨 GPU 集群，同一台服务器的不同端口还可能属于不同故障域，端口数量必须从通信模式反推。
可执行的预算需要同时给出正常态、单链路故障、单叶维护和扩容后的四张表。每张表都明确服务器端口、叶脊上联、速率与分拆方式，再用目标作业和存储流量验证阻塞比，而不是把“无阻塞”当成没有条件的标签。
先定义轨道和故障域，再画叶脊
多轨设计的价值在于让节点拥有彼此独立的通信路径，但独立性必须落实到网卡端口、叶交换机、脊交换机、供电与布线。若两条轨道共享同一叶设备或同一上联束，端口看似成倍增加，故障域却没有真正分开。设计文档应为每个服务器端口标注轨道、对端设备和预期路由。
阻塞比来自业务并发而非固定经验值
训练集合通信、检查点写入、数据加载和运维复制可能在同一时间出现。应按节点到叶的总注入带宽、叶到脊的可用带宽和实际并发模型计算，并分别评估大消息集合通信与存储突发。允许阻塞时要说明业务依据、持续时间和监控阈值，不能只引用其他集群的经验比例。
分拆端口必须按通道逐项记账
一个高速物理端口分拆后会形成多个逻辑端口，但它们仍共享模块、线缆或物理故障点。预算表要记录端口模式、分支编号、对端和介质完整料号；同时检查交换软件、子网管理与适配器是否支持目标组合。把一个分拆端口当成多个完全独立端口，会高估冗余。
故障状态决定真正可交付规模
正常态刚好满配的网络在一条上联或一台脊设备维护时，可能产生不可接受的过载。端口预算应预留替换、隔离和诊断所需资源，并计算故障收敛后每条剩余链路的负载。若业务允许降级运行，也要将可接受的作业规模和恢复时限写入运行手册。
扩容边界要在首期设计时保留
后续增加节点不仅消耗叶端口，还可能触发脊端口、机柜间光纤、配线架和管理许可的变化。应把首期、近期扩容和最终规模分别建模，确定何时增加叶、何时增加脊、何时需要重构。预留端口若没有配套光纤路径和电力空间，只是纸面余量。
项目评审需要留下哪些证据
- 列出每个节点的网卡端口、轨道和故障域。
- 分别计算正常态、链路故障和设备维护状态的上联负载。
- 将分拆通道、模块、线缆和对端写入逐链路清单。
- 用训练、存储和混合流量验证阻塞假设。
- 为扩容阶段预留脊端口、配线和机柜资源。
把官方信息转化为项目条件
Quantum-2 是 NVIDIA 面向 NDR InfiniBand 的网络平台，平台设计覆盖交换系统、适配器、互连和管理软件。
端口形态、分拆能力与支持配置应按具体交换系统、适配器、线缆和软件版本核对。
核对具体功能、版本和部署条件时，请以NVIDIA Quantum-2 官方资料的当前页面为准；公开平台方向不能替代完整料号、兼容矩阵和目标环境验证。
方案落地与服务范围
中科新远是 NVIDIA Networking Elite 合作伙伴。中科新远可围绕 MQM9700、ConnectX 与 LinkX 互连建立逐端口预算，把节点轨道、叶脊上联、介质 BOM、故障状态和扩容阶段放进同一份可验证设计。具体合作范围和项目交付内容以当前有效资质、官方目录及书面确认结果为准。
叶脊网络做到一比一上联就一定无阻塞吗？
不一定。还要看端口实际速率、分拆方式、路由散列、故障状态和业务通信模式。一比一只是容量关系，不能替代端到端负载验证。
WeChat
Profile