每秒令牌数的工作原理
基本计算公式为：
TPS = 计数的令牌数 / 经过的秒数
在推理过程中，语言模型会生成作为输出的令牌。测量其速率看似简单，但基准测试必须做出三个选择：
- 谁的令牌？是单个请求的令牌，还是系统上所有并发请求的令牌。
- 哪些令牌？是输出令牌、输入令牌，还是两者都包括。
- 哪些秒数？是仅计算第一个令牌之后的生成时间、完整请求时间，还是整个基准测试窗口。
这些选择产生了两种常见含义。
单请求输出速度描述单个响应开始输出后，以多快的速度进行流式传输。它通常根据输出令牌之间的间隔计算，不包括首次等待时间。这是最接近用户在文本出现时实际感知到的 TPS。
系统输出 TPS将所有请求的输出令牌相加，再除以基准测试持续时间。它衡量部署的总体生成能力。NVIDIA 的基准测试定义和Anyscale 的指标指南区分了这两个范围，因为随着负载变化，它们可能朝相反方向变化。
你还可能看到输入 TPS，它衡量提示词处理速度；或者看到总 TPS，它将输入和输出令牌合并计算。比较数值前，请先检查标签。输入处理和输出生成是不同的工作，尽管两者都使用令牌。
一个计算示例
假设你在0.0 秒提交一个请求。它生成了 41 个输出令牌：
- 第一个令牌在
0.4 秒时到达。 - 最后一个令牌在
2.4 秒时到达。 - 第一个令牌之后的 40 个间隔共持续
2.0 秒。
稳定输出速度为：
40 个间隔 / 2.0 秒 = 20 tok/s
如果某个工具将整个请求都纳入计算，它可能会这样计算：
41 个输出令牌 / 2.4 秒 = 17.1 tok/s
这两个结果来自同一个响应。第一个结果只计算输出开始后的生成速度；第二个结果包括首次等待时间，并使用全部输出令牌。目前的文档并未采用统一约定：Artificial Analysis会从输出速度中排除首次令牌等待时间，而一些端到端指标会将其包括在内。
现在改变统计范围。在一个持续五秒的基准测试中，多个并发请求总共生成了 400 个输出令牌：
400 个输出令牌 / 5 秒 = 80 system tok/s
这 80 tok/s 表示聚合容量，并不表示某个单独响应以 80 tok/s 的速度进行流式传输。
为什么每秒令牌数很重要
单请求 TPS 有助于判断长响应在开始输出后需要多长时间才能到达。对于聊天、代码生成，以及任何需要在答案完成前就消费流式响应的工作流，它都很重要。
系统 TPS 有助于进行容量和成本规划。它显示部署在指定负载下能够生成多少输出。提高并发数可以通过更高效地利用硬件来提升这一聚合速率，但也可能使每个请求变慢。高容量系统并不自动意味着单个用户能获得更快的体验。
TPS 从来无法完整描述响应时间。应将单请求 TPS 与首个令牌时间结合使用，后者衡量输出开始前的等待时间；将系统 TPS 与推理吞吐量以及负载下的延迟结合使用。只有在满足应用响应时间需求的同时产生足够工作量，部署才真正有用。
哪些因素会改变 TPS 结果
TPS 是经过测量的配置的属性，而不只是模型名称的属性。它可能随以下因素变化：
- 模型的架构和规模；
- 硬件和设备数量；
- 推理引擎、数值精度、缓存和解码方法；
- 提示词和输出长度；
- 并发数、批处理、请求速率和其他流量模式；
- 用于计数令牌的分词器；以及
- 流式传输分块和网络交付等客户端因素。
更长的提示词可能同时改变初始等待时间和后续输出速度。当服务引擎使用推测解码等方法时，输出速度也可能随生成内容而变化。因此，可复现的结果应注明模型和端点、工作负载形态、负载、分词器以及确切公式。vLLM 的基准测试文档建议比较测量点和公式，而不只是比较指标名称。
常见误解
“TPS 告诉我答案多久会开始出现”
TPS 通常描述生成期间或整个基准测试窗口内的速率。它不会单独衡量首个令牌出现前的空白等待时间。两个系统可能拥有相同的输出 TPS，却有非常不同的首个令牌时间。
“系统 TPS 越高，我收到响应的速度就越快”
不一定。将更多请求放在一起服务，可能提高系统总 TPS，但每个请求获得令牌的频率可能降低。应确认结果表示单请求指标还是聚合指标。
“一个令牌就是一个单词”
令牌并不是可见文本的固定单位。不同的分词器可能以不同方式拆分同一个句子，因此相同的 tok/s 数值可能对应不同数量的文本。出于这一原因，跨模型基准测试有时会使用通用分词器重新对输出进行分词。
“TPS 是一个标准化指标”
不存在单一的强制性定义。TPS 可能排除或包括首次令牌等待时间，也可能只计算输出令牌，或同时计算输入和输出令牌。务必阅读公式。
下一步了解什么
使用推理延迟来了解响应延迟，使用首个令牌时间来了解初始等待时间，并使用推理吞吐量来了解总体服务容量。若要了解这四种测量之间的边界，请参阅延迟 vs. TTFT vs. 每秒令牌数 vs. 吞吐量。