AI芯片多卡为何一同步就慢？互连拓扑怎么选？

单卡算得快，多卡一并起来却先卡在同步上，这类问题通常不是算子变慢，而是互连把并行收益吃掉了。AI芯片进入多卡训练后，真正决定扩展效率的往往不是单点峰值带宽，而是最慢那轮 AllReduce 和最拥挤那段拓扑。

集体通信的麻烦在于它天然受长尾支配。梯度分桶、参数切片和优化器状态更新都需要所有参与者按节奏交换数据，只要其中某一条链路晚一点，整轮同步就得等它。平均链路很快并不能救最坏桶，因为训练步进通常要在所有关键桶都完成后才能继续推进，最终 wall time 被最长那一个直接锁住。

很多系统在两三张卡上扩展不错，一到更多节点就急转直下，本质上常是拓扑层级开始显形。板内 NVLink、板间交换芯片、机架间 RoCE 或 InfiniBand 带宽并不对等，若分桶和通信路径仍按“所有链路一样快”来假设，热桶很快就会被塞进最窄那条通道。此时问题看起来像通信总量太大，实际是最细的瓶颈链路被反复撞中。

过订阅还会把排队抖动放大。多个并行作业或多个并行流在同一交换层汇聚时，即便平均吞吐够用，瞬时突发也会让某些包列队时间急剧上升。对同步式训练而言，这种尾延迟比平均带宽下降更致命，因为一次队列抖动就足以让整批设备一起空等。于是日志里看到的不是稳定偏慢，而是步长时延忽大忽小。

对AI芯片集群来说，分桶粒度不能只按软件方便来定。桶切得太大，通信启动晚，计算与通信无法重叠；桶切得太碎，协议头、调度和 NIC 发包开销又会膨胀。更稳妥的办法，是让梯度就绪顺序、拓扑层级和网络注入能力共同决定桶大小，而不是统一用一个经验数套全模型。

拓扑选择也不是单看峰值链路数。环形在均匀链路上实现简单，树形或分层归约更适合跨层带宽不对称场景；某些混合拓扑还需要把频繁同步的参数尽量留在局部节点先做归约，再跨层上传。只要路径规划围着最窄链路做减压，而不是围着平均带宽做乐观估算，扩展效率通常会稳定得多。

排查多卡同步慢时，单看总网络利用率很容易误导。需要同时拆每个桶的完成时间、各层链路占用、计算通信重叠比例和长尾节点分布。只要把这些时间轴对齐，就能很快看出是桶太大、路径太挤，还是某级交换层被过订阅拖慢。

参数切分顺序也别忽略。某些层梯度天然更大、就绪也更晚，若它们总在最后几个桶里集中出现，长尾会比平均值难看得多。再加上优化器状态分片和激活检查点重算，桶的就绪先后还会继续漂移，长尾更难靠固定拓扑掩住，参数大的尾层尤其如此，大模型末段更明显。适当重排桶内容，让关键大桶更早起跑，往往能在不改硬件的前提下先压掉一截同步尾巴。

所以，多卡一同步就慢，往往不是模型太大，而是通信长尾和拓扑窄口先露头。把分桶策略和互连层级一起设计，扩展效率才不会在更多卡上反向缩水。