1. 吞吐瓶颈全景图

吞吐量，说白了就是单位时间内你能处理多少数据。

我刚开始做AI工程时，老板问我：“这个模型训练要多久？”我算了半天，给出一个数字。结果实际跑起来，慢了整整三倍。为什么？因为吞吐瓶颈卡死了。

吞吐量是AI工程的核心指标，没有之一。你模型再牛，训练不出来，等于零。

什么是训练吞吐

训练吞吐，通常用每秒处理的样本数来衡量。比如：

• 样本吞吐：每秒能喂给模型多少个训练样本
• Token吞吐：每秒能处理多少个token（对LLM来说更直观）
• FLOPs利用率：硬件理论算力用了多少百分比

举个例子：

# 假设你的GPU理论算力是312 TFLOPS
# 实际训练时只跑到了150 TFLOPS
# 利用率 = 150 / 312 ≈ 48%
# 那剩下的52%去哪了？被瓶颈吃掉了。

我个人习惯，先看FLOPs利用率。这个数字低于50%，基本可以断定有瓶颈。

为什么吞吐是核心指标

你想想看，训练一个大模型，成本是按小时算的。一小时几千块甚至上万块。吞吐量提升10%，意味着省下10%的钱。

我在项目中遇到过一件事：一个团队花了两周优化模型结构，精度提升了2%，但吞吐量掉了30%。结果呢？整体实验周期拉长，反而拖慢了项目进度。

所以，吞吐量直接决定了：

• 实验迭代速度：一天能跑几个实验
• 训练总成本：电费、机时费、人力成本
• 模型上线时间：早一天上线，早一天赚钱

常见的吞吐瓶颈全景概览

吞吐瓶颈，说白了就四个维度：计算、存储、网络、框架。我一个个说。

1. 计算瓶颈

计算瓶颈是最容易理解的——GPU算力不够用。但实际情况往往更复杂：

• 算子效率低：同样的计算，用不同的算子实现，速度能差好几倍
• 内存带宽限制：数据搬来搬去，比计算本身还慢
• 小算子太多：每个算子启动都有开销，小算子多了，开销占比就大了

我记得有一次，一个模型里有个reshape操作，看起来很简单。但它在每个step都触发了一次内存重排，直接让吞吐掉了20%。

2. 存储瓶颈

存储瓶颈，很多人会忽略。但数据加载慢，GPU就得等着。

• IO带宽不足：硬盘读数据的速度跟不上GPU处理速度
• 数据预处理太慢：解码、增强、打乱，每一步都在消耗时间
• 缓存命中率低：数据没在缓存里，得从内存甚至硬盘读

我曾经遇到一个项目，数据存在机械硬盘上。训练时GPU利用率只有30%，一看IO，磁盘队列深度爆了。换成SSD，利用率直接到80%。

3. 网络瓶颈

分布式训练时，网络就是命脉。

• 通信带宽不足：梯度同步时，数据量太大，网络堵死了
• 通信延迟高：跨机通信，延迟叠加，整体变慢
• 拓扑结构不合理：有的节点之间带宽小，成了短板

嗯，这里要注意。很多人以为买了100G网卡就万事大吉。但实际跑起来，可能因为PCIe带宽限制，实际只有40G。

4. 框架瓶颈

框架本身也会引入开销：

• Python解释器开销：每调用一次框架API，都有额外成本
• 图编译优化不足：动态图灵活但慢，静态图快但不够灵活
• 内存管理效率低：频繁分配释放内存，触发GC

我建议，能用torch.compile就用。它能把动态图编译成静态图，省掉不少解释器开销。

吞吐瓶颈全景图

下面这张图，是我自己总结的。它把四个维度的瓶颈串在了一起：

这张图里，四个维度不是孤立的。它们互相影响。比如：

• 存储瓶颈会导致GPU空闲，看起来像计算瓶颈
• 网络瓶颈会导致梯度同步慢，看起来像计算瓶颈
• 框架瓶颈会放大所有其他瓶颈

所以，定位瓶颈时，别只看一个维度。要全局看。

怎么开始优化

我个人的习惯是：

1. 先跑一个profiler：看看时间花在哪了
2. 找最长的那个阶段：是计算、加载、还是通信
3. 针对性地优化：别一上来就改模型结构
4. 验证效果：改完再跑一次profiler

记住一句话：不要优化你不知道的东西。先测量，再动手。