What Is Inference Throughput? Units and Tradeoffs

它衡量的是系统容量，而不是单个请求开始或完成的速度。

推理吞吐量的工作原理

基本计算公式为：

吞吐量 = 已完成的工作量 ÷ 经过的时间

“工作量”这个词很重要。对于图像分类器，它可能指处理的图像数量。对于语言模型，它可能指完成的请求数或处理的令牌数。在不知道统计对象之前，“每秒 2,000 个”的结果没有意义。

令牌吞吐量还需要进一步标注。输入令牌吞吐量衡量提示词处理量；输出令牌吞吐量衡量生成的令牌数；总令牌吞吐量则将两者合并。这些速率描述的是不同的工作，不应将它们当作同一指标进行比较。

测量边界同样很重要。一个结果可能覆盖单个加速器、单台服务器，或包含多个副本的完整部署。将整个部署的结果除以加速器数量，有助于比较每个加速器的容量，但前提是模型和工作负载在其他方面等效。

随着并发运行的请求增多，吞吐量通常会上升。服务系统可以将工作批量处理，在每个处理步骤中更充分地利用硬件。对于语言模型，连续批处理可以在某个序列完成后用等待中的序列替换它，而不是等到批次中最长的序列结束后才处理整个批次。

这种提升是有限的。一旦计算、内存或其他共享资源达到饱和，额外请求就会进入队列等待。到达速率可能继续上升，但完成速率不再随之增加。此时，即使原始吞吐量变化不大，延迟也会变差。

因此，有用的容量结果通常是满足延迟目标的可持续吞吐量。基准测试会增加负载、测量已完成的工作量，并检查响应时间限制是否仍然满足。对于在线服务规划而言，最后一个通过测试的负载比不受约束的峰值更有用。

假设一项基准测试在 60 秒内向一台模型服务器发送相同的提示词组合。服务器完成了 1,200 个请求，并生成了 180,000 个输出令牌。

这是同一次运行的两种视角。请求速率有助于估算服务器能够完成多少次交互；令牌速率则体现响应长度的差异，而请求数无法反映这种差异。

现在将到达负载提高到每秒 30 个请求。服务器每秒完成 22 个请求，但每秒还有 8 个请求进入队列，并且未达到延迟目标。到达负载是每秒 30 个请求，观察到的完成吞吐量是每秒 22 个请求。这两者都不能证明服务可以持续处理每秒 30 个请求。

如果每秒 20 个请求是经过测试的最高负载，并且在该负载下队列保持稳定且满足延迟目标，那么对于该工作负载和目标而言，20 就是一个站得住脚的容量数值。

吞吐量可以告诉运营人员，为满足预期需求需要多少硬件。它还支持计算每美元完成的请求数、每个加速器小时生成的输出令牌数等成本指标。

对于离线任务，更高的吞吐量可以缩短总处理窗口。对于在线服务，足够的吞吐量可以防止传入请求的累积速度超过系统完成请求的速度。

目标取决于产品。批处理流水线可能接受较长的等待时间，以最大化总工作量。交互式应用则需要在保持单个请求响应迅速的同时，提供足够的吞吐量。一个更严格的指标称为有效吞吐量（goodput），它只统计同时满足服务延迟目标的工作量。

不一定。批量处理更多请求可以提高服务器的总输出量，但每个请求可能需要等待更久，或以更低的速度接收令牌。吞吐量描述的是整个系统；延迟描述的是单个请求的等待时间。

“每秒令牌数”既可以描述聚合令牌吞吐量，也可以描述单个用户体验到的生成速率。需要确认该数值覆盖的是单个请求还是所有并发请求，以及它统计的是输入令牌、输出令牌还是两者。

请求速率是到达的请求量，吞吐量是完成的请求量。只有在系统能够跟上时，两者才会接近。如果到达量超过完成量，队列就会增长，直到请求被延迟、拒绝或丢弃。

吞吐量取决于模型、输入和输出大小、批处理或并发模式、硬件范围、测量窗口以及延迟限制。即使系统没有改变，只要工作负载发生变化，这个数值也可能改变。

阅读什么是 AI 推理？，了解吞吐量所衡量的过程。将其与推理延迟进行比较，后者跟踪等待时间；还可以与每秒令牌数进行比较，后者通常描述生成速度。要了解完整区别，请参阅延迟 vs. TTFT vs. 每秒令牌数 vs. 吞吐量。