提起算力，人们最先看到的往往是峰值算力这个数字。但在真实的大模型训练和推理任务里，决定系统快慢的常常不是单颗芯片能算多快，而是数据能不能及时送到需要它的地方。XPU 这个说法本身就涵盖了多种加速器形态，无论是通用加速卡还是专用推理芯片，它们面临的都是同一道题：算力在涨，数据搬运的速度能不能跟上。

互连这笔账要分层来算。最里面一层是芯片内部的互连，计算单元、片上缓存和内存控制器之间的数据通路，决定了算力单元会不会经常空等数据。往外一层是芯片之间的互连，多颗加速器组成一个节点时，片间带宽和延迟直接决定了模型并行切分之后，跨芯片通信要吃掉多少时间。再往外是机柜内和机柜之间的网络，成百上千张卡协同训练时，集合通信的效率往往比单卡算力更能决定整体吞吐。

一个常见的误区是把带宽当成唯一的指标。带宽决定的是单位时间能搬多少数据，延迟决定的是小数据量交互要等多久，而实际利用率还要看通信模式与计算模式是否重叠得起来。训练中常见的流水线并行、数据并行和张量并行，对互连的需求各不相同：有的需要高带宽搬运大块梯度，有的需要低延迟频繁同步小块数据。同一套互连方案，在一种并行策略下表现很好，换一种策略可能立刻成为瓶颈。

另一个容易被忽略的维度是内存墙。加速器片外内存的带宽增长速度长期慢于算力增长，这意味着很多算子在实际运行中是访存受限而非算力受限。提高片上缓存命中率、做算子融合、把权重和激活的搬运量降下来，这些软件层面的优化，有时比升级互连硬件更划算。换句话说，互连问题不能只在硬件层解决，算法、编译器和通信库的协同同样关键。

从工程选型角度看，判断互连方案好不好，不应该只看宣传的峰值带宽，而要看三件事：第一，目标负载的通信模式是什么，带宽和延迟哪一个更敏感；第二，规模放大之后效率衰减有多快，8 卡跑得顺不等于 1024 卡也顺；第三，出现故障或局部拥塞时，系统能不能降级运行而不是整体停摆。把这三件事想清楚，再去比较不同互连技术路线的取舍，才不容易被单一指标带偏。