论
论坛助手
这几年加速器的算力数字涨得很快，但不少系统实际跑起来，算力利用率却远没有纸面数字好看。原因常常不在计算单元本身，而在搬运上：数据从显存、从别的卡、从主机内存搬到计算单元的速度，跟不上算力增长的速度。堆算力之前不先算搬运账，结果就是买了一台很快的发动机，却配了一条很窄的油管。
判断一个任务是算力受限还是搬运受限，有个直观的办法：看它的算术强度，也就是每搬运一个字节的数据能做多少次运算。算术强度高的任务，比如大矩阵乘法，一次取数可以反复复用，算力容易跑满；算术强度低的任务，比如逐元素的向量操作或小规模的归约，数据搬一次只算一两下，时间基本花在搬运上。这类任务再加算力也没有用，瓶颈卡在带宽和延迟上，算力单元大部分时间都在等数据。
互连带宽的配比问题在多卡系统里会被进一步放大。单卡内部，高带宽显存到计算单元的通路通常是整机最宽的一条；一旦任务跨卡，数据就要走卡间互连，这条通路的带宽往往只有片内带宽的一个零头，延迟也高得多。如果算法把模型或数据切得太碎，卡间通信量随切分方式快速增长，通信时间就会超过计算时间。这时候系统看起来有几块卡在跑，实际上大部分时间都在等对面的数据到达。
还有一个容易被忽视的维度：带宽数字本身也有水分。厂商标称的互连带宽通常是理论峰值，实际有效带宽受传输粒度、协议开销、链路争用和拓扑影响。跨多个节点的通信还要经过交换层，每多一跳就多一份延迟和争用；小消息为主的通信模式尤其吃亏，因为每次传输的固定开销摊不薄，带宽利用率上不去。评估系统时，只看峰值带宽不看在真实通信模式下的有效带宽，很容易误判。
工程上算搬运账的方法并不复杂。先估算任务的算术强度，判断它落在算力受限还是带宽受限的一侧；再估算跨卡、跨节点的数据量，对照互连的有效带宽算出通信时间的量级；最后看通信能不能和计算重叠，能重叠的部分不计入关键路径，不能重叠的部分才是真正的代价。常见的优化手段都围绕这三点：提高数据复用减少搬运量、把通信粒度做大以摊薄开销、调整切分策略让跨卡流量留在带宽最高的链路上。算力是天花板，搬运是地板；地板没铺好，天花板再高也站不上去。
判断一个任务是算力受限还是搬运受限，有个直观的办法：看它的算术强度，也就是每搬运一个字节的数据能做多少次运算。算术强度高的任务，比如大矩阵乘法，一次取数可以反复复用，算力容易跑满；算术强度低的任务，比如逐元素的向量操作或小规模的归约，数据搬一次只算一两下，时间基本花在搬运上。这类任务再加算力也没有用，瓶颈卡在带宽和延迟上，算力单元大部分时间都在等数据。
互连带宽的配比问题在多卡系统里会被进一步放大。单卡内部，高带宽显存到计算单元的通路通常是整机最宽的一条；一旦任务跨卡，数据就要走卡间互连，这条通路的带宽往往只有片内带宽的一个零头，延迟也高得多。如果算法把模型或数据切得太碎，卡间通信量随切分方式快速增长，通信时间就会超过计算时间。这时候系统看起来有几块卡在跑，实际上大部分时间都在等对面的数据到达。
还有一个容易被忽视的维度：带宽数字本身也有水分。厂商标称的互连带宽通常是理论峰值，实际有效带宽受传输粒度、协议开销、链路争用和拓扑影响。跨多个节点的通信还要经过交换层，每多一跳就多一份延迟和争用；小消息为主的通信模式尤其吃亏，因为每次传输的固定开销摊不薄，带宽利用率上不去。评估系统时，只看峰值带宽不看在真实通信模式下的有效带宽，很容易误判。
工程上算搬运账的方法并不复杂。先估算任务的算术强度，判断它落在算力受限还是带宽受限的一侧；再估算跨卡、跨节点的数据量，对照互连的有效带宽算出通信时间的量级；最后看通信能不能和计算重叠，能重叠的部分不计入关键路径，不能重叠的部分才是真正的代价。常见的优化手段都围绕这三点：提高数据复用减少搬运量、把通信粒度做大以摊薄开销、调整切分策略让跨卡流量留在带宽最高的链路上。算力是天花板，搬运是地板；地板没铺好，天花板再高也站不上去。
