2026年9月8日

Q5：Ring All-Reduce 模型与 MoE 的 NIC 热点

从环上的分块传输理解成本模型，区分热点字节、有效带宽与分块优化的边界。

下面是 Ring All-Reduce 的教学成本模型。n 是每个 rank 的 tensor 字节数，bw_bytes_per_us 是每条逻辑环边的有效带宽，alpha_us 是每轮启动开销；忽略本地归约成本。

p = 8
alpha_us = 3.0
bw_bytes_per_us = 20_000
def ring_us(n):
    return 2*(p-1)*alpha_us + 2*(p-1)/p*n/bw_bytes_per_us
small = ring_us(1024)
large = ring_us(1_000_000)

Q: 为什么这个模型不能直接预测 MoE All-to-All？遇到 NIC 热点时，哪些优化真正有效？

A: 模型里的 /p 来自把 tensor 分成 p 块：每轮每条环边传输 n/p 字节。Reduce-Scatter 和 All-Gather 各进行 p-1 轮，因此有两阶段的启动与传输成本；这不能无条件解释成总带宽变成了 p*bw，逻辑环边可能共享物理瓶颈。

Reduce-Scatter 结束后，每个 rank 负责一块完整的归约结果；在原地实现中，其余位置不保证仍保存原始数据。随后 All-Gather 让每个 rank 拿到全部归约结果。MoE dispatch 则把 token 发往所选专家的目的地，各目标字节数可能不同，也不要求所有 rank 收到全部归约结果。通信语义与流量分布都变了，不能直接套用这个环模型。参见 NCCL 2.31.2 集合通信文档。

分析跨机热点，可以先定义 D_ij 为机器 i 到机器 j 真正跨机传输的字节数。接收侧有：

D^{\mathrm{recv}}_j=\sum_{i\ne j}D_{ij},\qquad T\ge\max_j\frac{D^{\mathrm{recv}}_j}{B^{\mathrm{recv}}_j}.

这里 B 是对应场景下的有效接收服务速率；发送侧和共享链路也可能给出更强的下界。在窗口 Δt 内，需求压力可写成 ρ=D/(B·Δt)：持续大于 1 时，需求超过服务能力，队列会积累；有限 buffer 则通过反压让上游等待。例如当前 master 的 NCCL Simple 缓冲区路径中，发送方观察 head 消费进度，空间不足时等待。这里的通信层消费不等于专家计算完成，也不能泛化为所有协议的实现。

NIC 标称 bit/s 除以 8 只是 byte/s 的线速上限。建模应匹配消息大小、GPU/NIC 路径和并发场景，实测有效带宽；RDMA perftest 提供相关带宽测试，Linux 网络统计文档则用于核对计数器口径。接口字节统计不能直接当成应用有效载荷吞吐。

优化要对应瓶颈：

减少或分散热点字节：调整专家放置或副本；同一 token 发往同一目标机器时去重；使用经过精度验证的压缩。
提高实际可用带宽：合理利用多 NIC 或多路径，但它们共享的瓶颈不会因此消失。
有条件地分块与重叠：若总字节不变、NIC 已持续满速，分块不会降低 D/B，还会增加启动开销。配合错峰或限流、通信计算流水线、公平调度，或用于降低临时 buffer 需求时，才可能获益。更大的 buffer 不提高持续吞吐；重叠可能缩短端到端时间，却不改变通信字节对应的带宽下界。