吞吐量定义：训练吞吐量、推理吞吐量与端到端吞吐量
吞吐量这个词，说白了就是「单位时间内能干多少活」。
但在深度学习里，它其实分三种场景。我刚开始调参那会儿，经常把训练和推理的吞吐量混为一谈，结果被老板怼了一顿。嗯，今天咱们就把这三个概念彻底掰扯清楚。
1. 训练吞吐量（samples/sec）
训练吞吐量，指的是模型在训练时，每秒能处理多少个样本。
公式很简单：
训练吞吐量 = 总样本数 / 总训练时间（秒）但这里有个坑——你用的是「有效样本数」还是「总样本数」？
我个人习惯用「有效样本数」，也就是去掉数据加载、预处理、梯度同步这些开销之后，真正参与前向和反向传播的样本数。为什么？因为这样算出来的吞吐量，才能真实反映 GPU 的计算效率。
关键点：训练吞吐量受 Batch Size 影响极大。Batch 越大，GPU 利用率越高，吞吐量也越高。但 Batch 太大，模型收敛会变差——这就是调参的平衡艺术。
我在项目中遇到过一件事：某次训练一个 7B 参数的模型，Batch Size 从 32 调到 128，吞吐量翻了 3 倍。但模型收敛速度反而慢了，因为梯度更新次数变少了。后来我折中到 64，效果最好。
2. 推理吞吐量（inferences/sec）
推理吞吐量，就是模型上线后，每秒能处理多少个推理请求。
公式：
推理吞吐量 = 总推理次数 / 总推理时间（秒）这里要注意，推理吞吐量通常比训练吞吐量高一个数量级。为什么？因为推理不需要反向传播，也不需要梯度计算。
你想想看，训练时一个样本要经过前向 + 反向 + 参数更新，推理时只需要前向一次。所以同样的硬件，推理吞吐量往往是训练吞吐量的 3-5 倍。
我的经验：推理吞吐量优化，核心在于减少单次推理的延迟。常用的手段包括：模型量化（FP16 -> INT8）、算子融合、KV Cache 优化等。
我曾经踩过一个坑：某次上线一个对话模型，推理吞吐量只有 50 inferences/sec，远低于预期。查了半天，发现是 Batch Size 设成了 1。改成动态 Batch 后，吞吐量直接飙到 200+。
3. 端到端吞吐量
端到端吞吐量，是用户最关心的指标。它衡量的是「从输入到输出」整个流程的吞吐能力。
公式：
端到端吞吐量 = 总请求数 / 总响应时间（秒）这个指标包含了：数据预处理、模型推理、后处理、网络传输等所有环节。
说白了，端到端吞吐量才是用户真正感受到的「快」或「慢」。模型推理再快，如果数据加载慢、网络延迟高，用户照样骂娘。
注意：端到端吞吐量往往比推理吞吐量低 20%-50%。瓶颈通常不在模型本身，而在 I/O 和预处理环节。
我记得有一次做视频理解模型的部署，模型推理只用了 30ms，但视频解码花了 200ms。端到端吞吐量惨不忍睹。后来我把解码和推理做成流水线并行，才把吞吐量提上来。
三种吞吐量的对比
| 指标 | 关注点 | 典型值（A100） | 优化方向 |
|---|---|---|---|
| 训练吞吐量 | GPU 计算效率 | 100-500 samples/sec | Batch Size、梯度累积、混合精度 |
| 推理吞吐量 | 模型响应速度 | 500-2000 inferences/sec | 量化、算子融合、KV Cache |
| 端到端吞吐量 | 用户体验 | 200-800 requests/sec | 流水线、异步 I/O、缓存 |
核心逻辑图
下面这张图，展示了三种吞吐量之间的关系：
一句话总结：训练吞吐量看 GPU 效率，推理吞吐量看模型响应，端到端吞吐量看用户体验。三者层层递进，缺一不可。
我个人建议，调参时先盯训练吞吐量，确保 GPU 利用率打满。上线前再测推理吞吐量和端到端吞吐量，找到真正的瓶颈在哪里。
嗯，这三个概念搞清楚了，后面的 Batch Size 调参才有意义。否则你调了半天，连自己在优化哪个吞吐量都不知道，那就尴尬了。
避坑指南：我曾经在汇报时，把训练吞吐量和推理吞吐量混着说，被技术总监当场指出。从那以后，我每次写报告都会明确标注「这是训练阶段」还是「推理阶段」的数据。
想要更多资料，联系可可