结论前置：集群效率由最慢那条链路决定，不由单卡峰值决定

多卡推理集群的实际吞吐，通常受限于集合通信耗时与最慢链路的带宽，而非单卡算力之和。当模型并行度提高，跨节点通信量按比例上升，拓扑的跳数与收敛比就成为主导变量。看个比赛技术解读在分析集群方案时，第一步总是先画出通信路径，再谈算力堆叠。

这个结论可以从三个可量化的角度验证：单机内互联带宽、跨节点链路带宽与收敛比、以及集合通信量随并行度的增长曲线。

单机内互联：带宽阶梯决定了并行策略的上限

同一节点内的加速卡互联带宽通常高于跨节点网络一个数量级以上。公开规格中，节点内互联常见从数百GB/s到接近TB/s的区间，而跨节点以太链路单端口常见为数百Gb/s量级。这个数量级差决定了张量并行应尽量收敛在节点内，跨节点优先采用流水线或数据并行。

  • 张量并行通信频繁且对时延敏感，放在跨节点链路上通常得不偿失。
  • 流水线并行的通信量较小，但存在气泡，需要足够的微批数量填充。
  • 数据并行通信集中在梯度或权重同步，对带宽要求高但对时延相对宽容。

看个比赛在整理方案对比时，会把并行策略与互联层级对应起来标注，避免出现策略与拓扑错配的推荐。

跨节点链路：收敛比与跳数才是真实带宽

交换网络的标称带宽不等于可用带宽，收敛比决定了多卡同时通信时的实际速率。若收敛比为4比1，则四张卡同时满速发送时，每张卡实际只能拿到标称值的四分之一。跳数每增加一级，时延与排队概率同步上升。

  • 核算集合通信时间时，应按收敛比折算有效带宽，而非直接使用端口速率。
  • 环形与树形算法的耗时模型不同，前者与卡数近似线性，后者带对数项，选型时应代入实际卡数计算。
  • 拥塞控制与自适应路由能缓解热点，但无法突破物理收敛比。

这部分数据全部来自公开的网络规格与算法耗时模型，工程师可以自行代入卡数复算。看个比赛技术解读坚持给出计算过程而非单一结论，正是为了让结论可被核验。

集合通信量：随并行度增长的曲线决定扩展效率

以常见的全规约为例，通信量近似为两倍参数量乘以卡数减一再除以卡数，随卡数增长趋于饱和；而全收集类操作的通信量随卡数近似线性增长。不同并行策略对应不同曲线，扩展效率的拐点由此决定。

  • 先确定主导的集合通信类型，再选拓扑，顺序反了容易买到过剩带宽。
  • 小规模集群中时延项占比高，大规模集群中带宽项占比高，拐点位置需要实测校准。
  • 推理场景的通信模式与训练不同，权重加载与请求调度带来的突发流量应单独评估。

把三条曲线叠加到同一张图上，就能看出在给定卡数下哪种并行组合更划算。看个比赛会在产业数据栏目持续更新这类可复算的对照表，安卓、苹果iOS、Windows电脑版与Mac电脑版均可查看。

结语：先画通信路径，再谈堆卡

互联拓扑不是配角，它决定了并行策略的可行域。把单机带宽阶梯、跨节点收敛比、集合通信量三条线算清，集群效率的差距就有了可解释的来源。看个比赛技术解读栏目会继续以结论前置的方式，拆解算力架构与能效优化中那些容易被参数表掩盖的关键量。