算子与编译器：GPU 互联与拓扑映射

很多大模型系统瓶颈并不是某个 kernel 写得不够好，而是并行策略和物理拓扑映射错位了。你可以拥有很强的 GPU、很快的单卡 kernel、很成熟的并行框架，但如果：

1. 高频通信被放到最慢链路上；
2. TP 跨了不该跨的节点；
3. MoE expert 分布和网络拓扑错位；
4. prefill / decode 资源池和机器结构不匹配；

整体性能仍然会很差。
因此 GPU 互联和拓扑映射，应该被视为算子与系统之间的一层关键现实约束。

初学者先抓住

多卡性能不只取决于 GPU 型号，还取决于哪些通信被放在哪条链路上。高频、细粒度通信应尽量留在高速拓扑域；把 TP、MoE all-to-all 或 KV 相关同步跨到慢链路上，很容易吞掉 kernel 优化收益。

有趣例子：城市道路

同样数量的车，如果每天通勤都被安排走小巷，城市会堵住。拓扑映射就是把高频流量放到高速路，把低频流量放到普通路。

1. 为什么拓扑会决定上限

分布式系统的很多时间开销，本质上都要通过互联来传递：

1. 梯度同步；
2. 参数 gather；
3. TP 中间张量归并；
4. PP 激活传输；
5. MoE token all-to-all；
6. 某些推理路径中的跨卡同步。

如果这些流量的路径和拓扑不匹配，再好的算法也无法获得理想吞吐。

2. 节点内与节点间不是一回事

一个最基本的判断是：

1. 节点内通常有更高带宽、更低延迟互联；
2. 节点间通常更慢、更容易成为瓶颈。

这意味着高频、细粒度通信更适合留在节点内，而粗粒度复制或较少同步的维度更适合跨节点扩展。

3. 为什么 TP 往往优先留在节点内

张量并行的特点是：

1. 通信频繁；
2. 位于前向 / 反向主路径；
3. 粒度细；
4. 对延迟敏感。

因此它通常最适合映射到节点内高速互联域。
如果让 TP 跨了慢链路，收益会很容易被通信吃掉。

4. DP 为什么更适合向外扩展

数据并行虽然通信量也大，但：

1. 通信更粗粒度；
2. 更容易通过 bucket 和 overlap 隐藏；
3. 在很多系统里更适合横向扩展到更多节点。

这也是为什么很多大模型训练会把：

1. TP 放在内层；
2. PP 放在中层；
3. DP 放在更外层。

5. 拓扑映射和 MoE 的关系

MoE 里专家分布如果和互联结构不匹配，就会出现：

1. 热门 expert 跨慢链路集中；
2. token all-to-all 被放大；
3. 负载均衡和网络热点一起出现。

因此 expert placement 本质上同时是：

1. 路由问题；
2. 负载均衡问题；
3. 拓扑映射问题。

6. 推理服务系统里为什么也要关心拓扑

在线推理虽然不像训练那样每步大规模同步，但仍然会受拓扑影响，例如：

1. 张量并行推理；
2. 多 GPU KV cache 管理；
3. 多模型共部署；
4. prefill 和 decode 分池部署；
5. MoE 推理与 expert placement。

尤其在 tail latency 敏感场景中，跨节点慢链路会被放大得非常明显。

6.1 最小拓扑排查口径

排查拓扑问题时，先把物理图画出来：GPU 到 GPU 是 NVLink、NVSwitch 还是 PCIe，GPU 到 NIC 是否跨 NUMA，节点间是否经过同一层交换。随后用 NCCL / RCCL 基准分别测节点内、节点间、跨机架的带宽和延迟，再把 TP、PP、DP、MoE all-to-all 的进程组贴到这张图上。

如果端到端变慢但单卡 kernel 没退化，优先看通信是否跨了错误拓扑域、某个节点是否链路降级、进程绑核是否跑到远端 NUMA、以及故障节点是否仍在承载高频通信。很多“kernel 变慢”的问题，最后其实是数据走错了路。

服务场景还要注意资源池划分。prefill 通常更吃计算和长序列 attention，decode 更吃 KV 读取、批调度和尾延迟；如果两者混在同一组拓扑质量参差不齐的机器上，调度器可能把最敏感的请求放到最差链路上。拓扑信息最好进入调度标签，而不是只停留在部署文档里。

7. 一个形象比喻

拓扑映射就像城市道路规划。不是有很多车道就一定快，关键在于哪条路承载哪种车流。如果把最频繁的短途通勤全都导到跨城高速，再好的车也会堵；如果把重型货运和本地配送混在同一条窄路上，整个物流系统都会失衡。GPU 互联也是一样，系统真正快不快，很大程度上取决于数据流是否走在适合它的路径上。

8. 小结

GPU 互联与拓扑映射不是部署细节，而是决定分布式训练与推理上限的基础条件。理解它，才能真正明白为什么同样的 DP/TP/PP/MoE 配置，在不同机器结构上会表现出完全不同的效率，也才能在系统设计阶段就避免很多后面无法靠“再写快一点的 kernel”弥补的问题。

工程收束

GPU 互联要把 NVLink / NVSwitch、PCIe、IB、机架层级和路由对称性一起看。最容易误判的是把通信问题当作算力问题、进程组映射不看物理拓扑、只看理论带宽；上线前应先画拓扑图，分层记录通信基准，让 TP / PP / DP 各自贴合最快链路，并支持故障节点降权。

拓扑信息最好进入调度和实验记录，而不是只存在于集群文档。否则同一个并行配置在不同节点池里表现不一致时，团队很容易把问题误归因到模型、kernel 或 batch 设置。

对大规模训练和高并发推理来说，拓扑漂移往往不是小噪声，而是能直接改变成本曲线的系统变量。

因此拓扑基准应像模型评测一样周期性重跑，尤其在扩容、换机型和网络维护之后。

否则旧拓扑假设会悄悄失效。

调度也会随之变差。