在 LLM 推理性能评估中，"100 tokens/second" 这样的数字常被当作衡量系统能力的金标准。然而，这个看似简单的指标背后隐藏着复杂的计算逻辑和潜在的误导性。本文将系统梳理吞吐量（throughput）指标的测量方法、真实含义以及基准测试中的常见陷阱，帮助工程团队建立可复现的评估框架。
一、TPS 的三种计算范式
Tokens per second（TPS）并非单一指标，根据测量视角和计算方式的不同，至少存在三种截然不同的定义：
系统级 TPS 衡量的是整个推理服务在单位时间内生成的总 token 数。根据 NVIDIA GenAI-Perf 的定义，其计算公式为：
TPS_system = Total_output_tokens / (T_y - T_x)
其中 T_x 是第一个请求的发送时间戳，T_y 是最后一个响应的接收时间戳。这种计算方式关注的是系统整体的吞吐能力，适用于容量规划和成本评估场景。
用户级 TPS 反映的是单个用户的感知速度：
TPS_user = Output_sequence_length / End_to_end_latency
随着并发请求增加，系统级 TPS 会上升直至 GPU 资源饱和，但用户级 TPS 反而会下降，因为排队延迟和竞争资源导致单请求耗时增加。这意味着一个 "高吞吐量" 的系统可能给每个用户带来糟糕的体验。
感知 TPS 则特指流式输出场景下用户实际接收内容的速度。当首 token 延迟（TTFT）足够低时，感知 TPS 与用户级 TPS 接近；但如果 prompt 处理耗时较长，两者的差异可能非常显著。
不同基准测试工具对这些指标的计算方式也存在微妙但关键的差异。例如，LLMPerf 在计算 TPS 时使用整个 benchmark 持续时间作为分母，包含了输入 prompt 生成、请求准备和响应存储等开销，这可能导致单并发场景下高达 33% 的测量偏差。
二、基准测试的四大陷阱
陷阱一：并发级别的选择性报告
吞吐量与延迟存在固有的权衡关系。增加并发请求数通常会提升系统级 TPS，但会恶化单请求的端到端延迟。一些厂商倾向于在最高并发点报告 TPS 数据，却隐瞒此时用户的实际等待时间。NVIDIA 的技术文档明确指出，系统 TPS 随并发增加而上升直至 GPU 饱和，但这并不意味着用户体验同步改善。
合理的做法是报告并发矩阵而非单一数值 —— 从单并发逐步增加到最大 batch size 的 1.5 倍左右，观察 TPS 和延迟的变化曲线。
陷阱二：测量窗口的不一致性
GenAI-Perf 采用滑动窗口技术寻找稳定测量区间，排除 "预热" 和 "冷却" 阶段的请求。这种设计能反映系统的稳态性能，但不同工具的窗口策略差异使得结果难以横向对比。工程团队在选择工具时，应明确记录其 warmup 策略和测量窗口定义。
陷阱三：Prompt 处理阶段的忽略
许多吞吐量测试仅关注生成阶段（decode）的速度，却忽略了 prompt 处理（prefill）阶段的开销。对于长输入序列的场景，prefill 阶段可能占据总耗时的显著比例。一个系统在 decode 阶段表现优异，但如果 prefill 效率低下，整体吞吐量指标仍然具有误导性。
陷阱四：尾延迟的掩盖
仅报告平均 TPS 会隐藏关键的性能波动。生产环境的 SLA 通常基于 p95 或 p99 延迟设定，而平均值的优化可能导致长尾请求体验极差。基准测试应当同时报告吞吐量指标的分布特征，包括中位数、平均值和尾部百分位数。
三、可复现方法论：负载矩阵设计
建立可复现的吞吐量基准测试需要系统化的负载矩阵设计。以下是关键参数及其建议的扫描范围：
输入 / 输出序列长度：根据实际应用场景设定。翻译任务通常采用 ISL≈OSL≈500-2000 tokens；内容生成任务 OSL 远大于 ISL；摘要任务则相反；推理类任务 ISL 较短但 OSL 可能达到数千甚至上万 tokens。
并发级别：从 1 开始，逐步增加到最大 batch size 的 1.2-1.5 倍。当并发超过 max_batch_size × replica_count 时，请求将进入队列等待，此时 TTFT 会显著增加。
采样参数：使用 greedy 解码以消除随机性对结果的影响；设置 ignore_eos=True 确保达到预定的输出长度，获得一致的测量结果。
测量稳定化：采用滑动窗口技术，排除前 10% 和后 10% 的请求，仅对中间稳定区间进行统计。
四、从数字到决策的解读框架
面对一组吞吐量基准数据，工程团队应当建立结构化的解读框架：
场景适配性检查：首先确认测试负载与实际生产负载的匹配程度。如果生产环境以短 prompt、长输出的聊天场景为主，而基准测试使用的是长 prompt、短输出的摘要配置，结果的可迁移性将大打折扣。
饱和点识别：观察 TPS 随并发增加的变化曲线。理想的系统会在并发达到某个阈值后进入平台期，而非持续线性增长后突然崩溃。识别饱和点有助于确定最优的并发配置。
延迟 - 吞吐量权衡分析：绘制延迟 - 吞吐量曲线（latency-throughput curve），识别满足延迟 SLA 的最大吞吐能力。对于交互式应用，通常需要在 TPS 和 p95 延迟之间寻找平衡点。
成本归一化：将吞吐量数据转换为每千 token 成本或每请求成本，结合硬件规格和运行时长进行经济性评估。
五、工程落地建议
在实际部署吞吐量基准测试时，建议遵循以下 checklist：
-
明确指标定义：在报告中清晰说明使用的是系统级 TPS、用户级 TPS 还是感知 TPS，以及具体的计算公式。
-
完整披露配置：包括 GPU 型号与数量、量化方案（FP16/INT8/INT4）、模型 checkpoint 版本、batch size 和并发级别。
-
多维度报告：除了平均 TPS，同时报告 p50/p95/p99 延迟、TTFT 分布、ITL（inter-token latency）稳定性。
-
工具链标准化：在团队内部统一使用同一套基准测试工具（如 GenAI-Perf 或 LLMPerf），避免因工具差异导致的测量偏差。
-
持续回归测试：将吞吐量基准测试纳入 CI/CD 流程，在每次模型更新或框架升级时进行性能回归验证。
吞吐量指标是 LLM 推理性能评估的重要维度，但单一数字无法讲述完整故事。只有通过系统化的方法论、透明的配置披露和多维度的结果分析，才能将 "N tokens/second" 从营销话术转化为工程决策的可靠依据。
参考来源
- Baseten, "Understanding performance benchmarks for LLM inference", 2024
- NVIDIA Developer Blog, "LLM Inference Benchmarking: Fundamental Concepts", 2025
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。