“每秒令牌数”这一说法需要特别谨慎。它只表示一个单位，并不是完整的指标。你还需要知道统计的是谁的令牌，以及使用了哪个时间区间。
各指标衡量的内容
推理延迟
推理延迟是一个请求经过的时间。对于生成式响应，“端到端延迟”通常从发送或接收请求开始，到收到最终输出为止。
它回答的是：这个请求还要多久才能完成？
这个边界并不统一。客户端测量可能包括路由、网络传输、排队和响应处理。推理服务器可能会在其中一些步骤完成后才开始计时。只说“延迟”的基准测试，并没有提供足够的信息让你复现这个数值。
延迟还直接取决于输出长度。一个简短响应和一个较长响应可能具有相同的 TTFT 和生成速度，但较长响应需要更多时间才能完成。
首令牌时间
首令牌时间（Time to First Token，简称 TTFT）是从请求边界到流式响应中第一个非空输出令牌之间的时间。
它回答的是：答案要多久才会开始出现？
TTFT 通常包括排队、输入处理、模型对提示词执行的预填充工作、第一个令牌的生成，以及处于所选边界内的网络耗时。它是端到端延迟的一部分，而不是端到端延迟的另一种名称。
较低的 TTFT 会让界面感觉更灵敏。但仅凭 TTFT，无法判断响应其余部分是否会平稳到达，也无法判断响应何时完成。
每秒令牌数
每秒令牌数是输出令牌数除以经过的秒数。在产品比较中，它通常表示第一个令牌之后，单个请求的生成速度。
它回答的是：生成开始后，生成的文本到达得有多快？
对于包含 (N) 个输出令牌的响应，第一个令牌和最后一个令牌之间有 (N-1) 个间隔。如果这些间隔耗时 (G) 秒，则首令牌之后的速率为：
[\n\\text{单请求生成速率} = \\frac{N-1}{G}\n]
当每个测量事件包含一个令牌时，这等于每个输出令牌间隔平均耗时的倒数。实际的流式 API 可能会传送包含多个令牌的数据块，因此客户端必须统计令牌数，不能假定每个事件对应一个令牌。
有些工具会将所有输出令牌除以请求完整的端到端延迟。有些工具会合并所有并发请求中的令牌。这些选择会产生不同的数值，尽管它们都可能被标记为 TPS 或 tokens/s。
推理吞吐量
推理吞吐量是系统在规定工作负载下，单位时间内完成的总工作量。它可以用每秒输出令牌数、每秒总令牌数、每秒请求数、每秒样本数，或其他适合该工作负载的单位来衡量。
它回答的是：系统能够处理多少负载？
吞吐量是一个聚合属性。它需要明确测试区间和负载模式。并发数、请求到达速率、提示词和响应长度、批处理、副本数量以及失败请求的处理方式，都可能改变吞吐量。
请求吞吐量和令牌吞吐量不可互换。服务器可以完成许多短请求，也可以完成较少的长请求，同时产生相同的每秒输出令牌数。
真正的区别
| Metric | Clock stops at | Typical scope | Typical unit | The question it answers |
|---|---|---|---|---|
| Latency | Final response output | One request | ms or s/request | When is this request finished? |
| TTFT | First content token | One streamed request | ms or s/request | When does the answer begin? |
| Tokens per second | Depends on the stated formula | One request or the whole system | output tokens/s | How fast are tokens arriving, and for whom? |
| Throughput | End of a test interval | System or deployment | tokens/s, requests/s, or samples/s | How much work is completed under load? |
三个问题几乎可以消除所有报告结果中的歧义：
- 统计什么？是输出令牌、全部令牌、已完成请求，还是样本？
- 计时从哪里开始、到哪里结束？是从客户端发送、服务器接收、第一个令牌、最后一个令牌，还是固定的测试边界开始和结束？
- 范围是什么？是单个请求、单个用户、单个副本，还是并发负载下的完整部署？
如果一个基准测试无法回答这三个问题，它的数值就还不具备可比性。
一个实际示例
假设一个请求返回 81 个输出令牌：
- 请求在 0.0 秒时发送。
- 第一个令牌在 0.8 秒时到达。
- 最后一个令牌在 2.8 秒时到达。
它的TTFT 是 0.8 秒。它的端到端延迟是 2.8 秒。第一个令牌之后的生成过程持续 2.0 秒，包含 80 个令牌间隔，因此其首令牌之后的速率是每秒 40 个令牌。
如果某个工具统计全部 81 个输出令牌，并将其除以完整的 2.8 秒延迟，则会报告约每秒 29 个令牌。这不是数学上的分歧，而是使用了不同的计时边界和分子。
现在让许多请求同时进入一台服务器。在 10 秒的测试窗口内，服务器生成了 3,000 个输出令牌，并完成了 50 个请求：
- 输出令牌吞吐量：(3{,}000 / 10 = 300) 个令牌/秒
- 请求吞吐量：(50 / 10 = 5) 个请求/秒
服务器的每秒 300 个令牌是所有活动请求合计的输出量。单个用户仍可能以每秒 40 个令牌的速度接收输出；如果额外负载增加了排队和解码延迟，速度也可能更低。
各指标何时重要
对于聊天界面、编程助手或其他流式交互，TTFT 描述初始等待时间。单请求生成速率，或其倒数——每个输出令牌的耗时——描述初始等待之后的输出速度。当用户或其他程序必须等待完整答案才能继续时，端到端延迟十分重要。
对于批处理任务，吞吐量通常比 TTFT 更重要。只要失败率和输出质量仍可接受，任务关心的就是总体完成速率。
对于容量规划，应将吞吐量与延迟目标结合使用。提高并发数起初通常会提升聚合吞吐量，因为硬件可以并行完成更多工作。同样的并发数也可能增加排队，使每个用户的响应变慢。达到饱和后，吞吐量可能趋于平稳甚至下降，而延迟仍会持续上升。
对于非流式 API，客户端可能无法观察到 TTFT，因为响应只有在完成后才会一次性交付。服务器仍然可以测量内部阶段，但客户端可见的性能指标是端到端延迟。
人们容易混淆的内容及其原因
低 TTFT 不保证低延迟
响应可能很快开始，但随后生成得很慢。TTFT 只捕捉第一个里程碑；总延迟还包括剩余的生成时间。
在明确采用首令牌之后的定义时，二者关系为：
[\n\\text{端到端延迟} = \\text{TTFT} + (N-1)\\times\\text{每个输出令牌间隔的平均耗时}\n]
不同实现采用不同的计数约定，因此在根据一个指标推导另一个指标之前，应先检查基准测试使用的公式。
每秒令牌数可能表示吞吐量
“每秒令牌数”有时表示单个用户的生成速度，也可能是聚合输出令牌吞吐量所使用的单位。仅凭这个标签无法区分二者。
应查找诸如每请求、每用户、每流、聚合或系统级等限定词。如果没有，应检查公式和测试设置。
高吞吐量不保证请求速度快
服务器可以通过批处理许多请求，在每秒生成更多总令牌，但同时让每个请求等待更久，或让令牌以更低频率到达。因此，严谨的服务测试会同时报告吞吐量和延迟百分位数，或者计算有效吞吐量（goodput）：即在满足规定服务目标的同时完成的工作量。
不同工作负载会产生不同结果
TTFT 会随提示词长度和排队情况变化。端到端延迟会随响应长度变化。吞吐量会随并发数、到达模式、批处理和硬件分配变化。令牌速率还取决于用于统计输出的分词器。
只有在模型行为、提示词和输出分布、负载模式、流式模式、采样设置、分词器、测量边界以及成功标准都相同的情况下，才应比较系统。单个空闲请求测试的是与饱和服务器不同的情况。
平均值会掩盖用户记得的那些请求
平均 TTFT 或平均延迟看起来可能很健康，但仍有少量请求在队列中等待更长时间。应报告分布，包括相关的尾部百分位数，并注明观测数量。对于吞吐量，应报告错误和被拒请求，而不是只统计成功完成的工作却不作说明。
如何阅读推理基准测试
在相信图表或模型卡声明之前，应检查其是否说明了：
- 每秒令牌数是单请求指标还是聚合指标；
- 统计的仅是输出令牌，还是输入加输出令牌；
- TTFT 或第一个令牌是否计入令牌速率计算；
- 延迟是客户端侧、服务器侧，还是仅模型侧的延迟；
- 提示词长度和输出长度的分布；
- 并发数和请求到达模式；
- 预热、测试时长以及起止边界的处理方式；
- 平均延迟和尾部延迟，而不只是一个平均值；
- 成功请求和错误的判定标准；
- 模型、精度、硬件、引擎和副本数量。
最佳指标并不是孤立地从这四个指标中选出的某一个，而是与用户可见目标或运营目标相匹配的指标，并且应在真实负载下测量，同时明确说明所有边界。
接下来阅读
阅读什么是推理延迟？，了解请求计时边界；阅读什么是首令牌时间？，了解流式响应的初始延迟；阅读什么是每秒令牌数？，了解令牌速率公式；阅读什么是推理吞吐量？，了解负载下的系统容量。