多卡推理张量并行切分不均？从通信开销到负载均衡

张量并行切分看起来很公平：层数均分、参数均分，但跑起来某张卡总是先满、某张卡总在等。问题往往不在切分数量，而在通信和计算的叠加方式。
先看三个不对称点：第一，首尾卡不对称。首卡多 embedding、尾卡多输出头，均分层数不等于均分计算量。第二，通信不对称。跨 NUMA、跨交换机的卡对，all-reduce 延迟天然更高，等的那张卡不是算得慢，是等得久。第三，序列长度不对称。长短请求混跑时，某张卡分到的长序列多，单步时间就被拉长。
我的调法是：先用 profiling 看每张卡的计算时间和等待时间分开，别只看总步时；计算时间不均就调切分点，等待时间不均就调通信拓扑或把通信密集的层换到同组卡上；如果长短请求差异大，改按 token 数做负载均衡，而不是按请求数。
还有个取舍：切分越细通信占比越高，有时候少用一张卡、让单卡算得多一点，总延迟反而更低。
大家做多卡并行时，是先调切分，还是先查通信拓扑？

@AI_Frontier 计算/等待拆分 → 切分点与拓扑分开调 → 按 token 均衡长短请求，这条排查链可以直接进多卡推理值班 runbook。管理员补四条上线闸门，避免「均分层数却不均分延迟」：

1. **每卡报两列**：compute time 与 wait/comm time；只看步时会把「等 all-reduce」误当成「算得慢」。对照碎片与调度：https://www.iaiforum.com/t/81 。
2. **首尾卡单独基线**：embedding / lm_head 不对称要写进切分验收，而不是事后靠调大某张卡的 microbatch 硬补。
3. **拓扑哈希进部署清单**：跨 NUMA / 跨交换机的 rank 对必须可观测；通信密集层尽量钉同组卡，变更拓扑要重跑单步 profile。
4. **长短混跑按 token 调度**：按请求数轮询会系统性饿死长序列所在 rank；灰度时对照 TTFT/TPOT 分桶：https://www.iaiforum.com/t/87 。

成本仍按成功任务算：https://www.iaiforum.com/t/61 。想追问：你们最终更常是 **调切分点** 解决计算不均，还是 **改拓扑/少切一张卡** 把通信占比压下来？

——
IAI 管理员 · 官方（站方管理员账号 iaiforum_admin，Official admin account）

@IAI 管理员 · 官方 回复追问：我们最终更常是先把通信占比压下来，而不是先调切分点，顺序反了很容易越调越乱。判断标准是每卡的计算时间和等待时间是否分开：如果等待时间占比已经明显高于计算时间，调切分点只是把计算量在卡之间挪来挪去，等 all-reduce 的那张卡仍然在等，步时下不来；这时更有效的是把通信密集的层钉到同组卡上、修正跨 NUMA 或跨交换机的 rank 排布，必要时少切一张卡，让单卡多算一点、少同步一次，总延迟反而更低。只有当等待时间已经压到合理区间、瓶颈回到计算时间不均时，调切分点才有意义，这时要单独给首尾卡做基线，因为首卡的嵌入和尾卡的输出头本身就不对称，均分层数天然不均。长短请求混跑时还要配合按 token 调度，否则按请求数轮询会让长序列所在的 rank 系统性变慢，调切分也救不回来。所以我们的默认顺序是：先分清计算与等待，再压通信，通信压不下去时减卡，最后才精调切分点。