AI 网络无阻塞与收敛比怎么选：从通信模型计算上联
从 AI 通信模型、并发、作业放置、故障状态和扩容目标说明无阻塞网络与不同收敛比的计算和验证方法。
AI 网络是否需要无阻塞，不能由 GPU 数量直接决定。通信算法、并行策略、消息大小、并发作业和服务器放置共同决定跨 Leaf 流量；有些作业主要在本机或同一组节点通信，有些则会持续执行全局集合通信。
收敛比是容量选择，不是单纯成本比例。降低上联可以节省端口和介质，但可能增加作业互相影响、排队和尾部时延，尤其在多个训练任务同时运行时。
用通信矩阵代替平均流量
为代表性作业记录节点数、并行策略、每节点网络端点、跨节点通信量和阶段变化。All-Reduce、All-to-All、参数同步和检查点流量的峰值时间并不相同。
平均端口利用率会掩盖短时间全局同步。容量规划应关注并发窗口、最低完成时间和对尾部节点的影响。
分别计算下行与上联
先得到每台 Leaf 的服务器下行总带宽，再按照目标收敛比计算正常状态上联。上联还要考虑端口颗粒度、Spine 数量和 ECMP 路径，不能只满足数学总和。
如果服务器端口速率和数量不一致，应按实际端点分组。把所有机柜用一个平均值计算，可能让高密度机柜先形成热点。
作业放置可以改变跨层流量
拓扑感知调度能让强通信任务尽量落在同一 Leaf 或预定 rail，减少非必要上联占用。但调度不是无限容量，多个大作业并行时仍可能跨越多个交换域。
容量方案应说明依赖哪些调度约束。如果运维无法长期保证作业放置，就不能把理论局部性全部计入节省。
故障状态重新计算收敛比
单条上联或单台 Spine 故障后，剩余链路的实际收敛比会变大。需要确定是否允许性能下降、是否暂停新作业，以及已有作业能否完成。
无阻塞设计也应检查故障后的容量，而不是只看完整拓扑。端口预留与冗余路径要落到具体设备。
用并发业务验证设计假设
测试包括单作业跨 Leaf、多作业并发、存储流量混跑和链路故障，记录交换机端口、队列、ECN/PFC、RDMA 与业务完成时间。
如果轻度收敛对业务无可见影响，可以保留成本优势；若尾部作业明显恶化，应增加上联或调整拓扑与调度。结论只对测试规模和业务组合有效。
把容量边界写进调度规则
采用收敛设计后，应规定单个网络域允许同时运行的高通信作业数量，以及利用率或拥塞达到什么条件时停止接收新作业。容量边界不能只存在于设计文档。
监控需把作业、Leaf 和上联关联起来。扩容或通信模型变化后，用新数据重新评估收敛比，不让旧的平均流量长期主导建设。