什么是 每秒 Token 数（Tokens per Second）？
每秒 Token 数（Tokens per Second）是必须由 Token 类型、统计范围和计时区间共同限定的速率，例如单请求 Decode 输出速率或整个服务的聚合输出 Token 吞吐。
快速了解
| 规范文档 | 官方规范 |
|---|
工作原理
Token 与事件身份
应使用目标模型的 Tokenizer 或服务端可信 Usage 字段；字符、单词和流式 Chunk 都不是 Token。[AIPerf 指标参考](https://docs.nvidia.com/aiperf/reference/ai-perf-metrics-reference)会分别处理 Output Sequence Length、Reasoning、Cache 与 Speculative Token 字段，而不是把传输事件混为一类。一个 Chunk 可能包含零个、一个或多个 Token。报告时要说明是否排除首 Token、时间从请求发送还是首输出开始，以及失败、取消或截断请求是否进入结果。
单请求与聚合速率
单请求输出 TPS 描述用户看到的 Decode 节奏，聚合输出 TPS 描述服务在并发负载下的容量。更大 Batch 可能提高聚合 TPS，却降低每个流的速率或增大 Jitter。输入 TPS 测量 Prefill 工作，不能与输出 TPS 直接比较，因为两个阶段的计算、批处理和状态行为不同。总 Token TPS 可用于固定工作负载，但可能掩盖输入输出比例变化。
比较契约
可比较结果必须固定模型与 Tokenizer 修订版、真实输入输出长度分布、并发、到达过程、Cache 状态、精度、采样与停止策略、Runtime、硬件、地域、Warmup 和测试时长。[vLLM Benchmark CLI](https://docs.vllm.ai/en/latest/benchmarking/cli/)会分别报告 Request、Output Token 与 Total Token Throughput，以及 TTFT、TPOT 和 ITL。还要同时报告错误率和任务质量；因为输出更短、提前终止或 Tokenizer 更易切分而得到的高 TPS，并不代表服务优化。
主要特点
- 必须声明分子是输入、输出、已接受还是总 Token
- 必须声明范围是请求、用户流、加速器还是整个服务
- 必须声明区间是 Decode Duration、端到端时间还是 Benchmark Window
- 受 Tokenizer、模型、输出策略、批处理、负载、缓存和硬件影响
- 可能与 TTFT、尾延迟或单用户公平性反向变化
- 只有保持质量、错误率与工作负载身份时才有比较价值
常见用途
- 测量单个流式请求对用户可见的生成节奏
- 估算真实并发下的服务聚合容量
- 在对齐 Token 与计时定义后比较不同 Runtime
- 检测量化、批处理或调度变更后的 Decode 回退
- 计算每个合格输出 Token 的成本或能耗且不隐藏失败工作
示例
Loading code...常见问题
每秒 Token 数表示单用户速度还是服务总吞吐？
两者都可能，因此不带限定词的 TPS 有歧义。必须说明分子是输入、输出还是总 Token，范围是单流还是整个服务，以及分母使用哪段真实时间。
计算 Decode TPS 时应包含首 Token 吗？
首 Token 后的单请求 TPS 应排除首 Token，用 `output_tokens - 1` 除以首尾输出之间的区间。不同 Benchmark 工具可能采用其他公式，因此应保留工具版本和指标定义，不能混用结果。
为什么流式 Chunk 不等于 Token？
Streaming 是传输行为。由于缓冲或推测解码，一个 Chunk 可以没有可见文本，也可以包含一个或多个 Token。应使用模型 Tokenizer 或可信 Usage 字段计数，Chunk Timing 则单独用于测量交付 Jitter。
更高聚合 TPS 会让每个用户的输出变慢吗？
可能。更大 Batch 可以摊薄模型权重读取并提高总输出速率，但每个序列被调度的频率会降低。应把单用户 TPOT 或 TPS 与尾延迟和聚合吞吐一起报告。
TPS 能公平比较不同模型或提供商吗？
只有在任务和工作负载受控时可以。不同 Tokenizer、输出长度、停止行为、质量、地域和服务策略都会改变计数与区间。除了 Token 速率，还应比较合格任务质量和完成时间。