正文
规模再大，就只能经过 SPINE 或者最差经过 SUPER SPINE 来进行通信。为了减少流量上送 SPINE，百度百舸在任务调度的时候会自动进行服务器的亲和性调度。在创建任务的时候，尽量把同一通信组下的 Rank 排布在同一 LEAF 交换机下的服务器内，那么理论上大部分流量都可以收敛在 LEAF 下。
对于推理服务来说，MoE EP 之间的 Alltoall 通信流量模式与 AllReduce 等不同，会产生大量的跨导轨流量。虽然对于 Prefill 阶段来说，可以通过软件实现层面规避掉跨导轨的流量，但是 Decode 阶段仍然无法避免跨导轨，这会导致多机之间的通信不只是同号卡通信，跨机流量大部分并不能一跳可达，会有大量的流量上到 SPINE 或者 SUPER SPINE，从而导致时延增加。
对于 MoE 训练的流量会更加复杂，综合了训练和推理的流量特征，既存在传统的梯度同步产生的 AllReduce 或者 ReduceScatter 或者 AllGather，PP 之间的 SendRecv，也存在 EP 之间的 Alltoall 流量。这些流量不但会出现跨导轨传输的问题，他们之间可能会存在 overlap 导致互相干扰。
鉴于 Alltoall 通信的特点，我们在设计 HPN 网络的时候，会考虑优先保证跨导轨流量至多 2 跳可达，让 Alltoall 流量收敛到 SPINE 层，以这种方式尽量减少跨导轨的通信时延。如下图所示：
LEAF 层所有设备全部有一根线接入同一台 SPINE 交换机，这样可以让集群内 Alltoall 跨导轨流量全部收敛到 SPINE 层，跨导轨通信时延可以进一步从 5us+ 缩小为 4us。
这种经过优化后的 HPN 网络架构，能接入的卡数主要取决于交换机芯片支持的最大的下联口有多少。虽然对于超大模型的训练任务来说，这个集群规模可能不够，但是对于推理来说，通常不需要那么大规模的机器，是可以满足需求的。
同时，由于 Alltoall 通信流量的特征，LEAF 到 SPINE 之间的通信流量会成为常态。当流量需要通过 SPINE 传输的时候，会由 hash 选择 SPINE 出口的过程，这时候有可能会产生 hash 冲突，导致网络抖动。因此为了避免 hash 冲突，百度智能云基于自研交换机实现自适应路由。如下图所示：图片假设 A 和 C 进行 Alltoall 跨导轨通信，A 发出的流量必然要经过 SPINE，那么流量在到达 LEAF 的时候，会基于 packet 做 hash，并结合链路的负载情况动态选择最优的出口，将报文发送到多个 SPINE 上。
基于报文 hash 到不同的物理路径，百度智能云实现了链路负载均衡，消除因 hash 冲突时延增加导致的性能抖动，实现稳定的低时延网络。
详情可参考：
彻底解决网络哈希冲突，百度百舸的高性能网络 HPN 落地实践
Alltoall 和 KV Cache 流量的管理和优化
避免 incast 造成降速，不同类型流量的分队列管理
