解构 tokens/s 的工程误导性：首Token延迟与流式真实体验的评估模型

在 LLM 推理性能的公开讨论中，"N tokens/s" 几乎成了衡量系统能力的默认标尺。从模型发布到云服务选型，这个数字被反复引用、比较和优化。然而，这一指标在工程实践中存在显著的误导性 —— 它测量的是系统吞吐量，而非用户实际感知的响应质量。当一个系统报告 "100 tokens/s" 时，它可能意味着用户需要等待数秒才能看到第一个字符，随后以流畅的流式输出完成响应；也可能意味着首 token 在 100 毫秒内出现，但后续输出断断续续、体验割裂。这两种场景在 "tokens/s" 数值上可能完全相同，却带来截然不同的用户体验。

吞吐量与延迟的本质混淆

计算机系统性能评估中，吞吐量（Throughput）与延迟（Latency）是两个互补但截然不同的维度。吞吐量衡量单位时间内处理的工作量，而延迟衡量单个请求从提交到完成的总耗时。在传统的批处理系统中，二者通常呈现正向关联：处理速度越快，单位时间完成的请求越多。然而，LLM 推理的特殊性打破了这种简单的对应关系。

LLM 推理包含两个计算特征迥异的阶段：Prefill（提示处理）和 Decode（token 生成）。Prefill 阶段需要对整个输入提示进行前向传播，构建 KV 缓存；Decode 阶段则利用缓存逐个生成输出 token。在批处理（Batching）优化中，系统可以将多个请求合并处理以提高 GPU 利用率 —— 这能显著提升整体吞吐量，但会导致每个请求的 Prefill 阶段被延迟，从而增加首 token 等待时间。

这正是 "tokens/s" 指标的盲区：一个系统可以通过激进的批处理策略达到极高的吞吐量数字，却让每个用户承受漫长的初始等待。正如 SambaNova 工程师在 LanceDB 的技术文章中所指出的，当一项指标成为优化目标时，它往往会失去作为衡量标准的有效性。

关键指标的语义澄清

要建立真正反映用户体验的评估模型，需要区分以下核心指标：

Time to First Token (TTFT)：从请求提交到首个输出 token 生成的时间。它涵盖了网络传输、请求排队、Prefill 计算等全过程，是用户感知 "系统是否响应" 的直接信号。在聊天机器人、代码补全等交互式场景中，TTFT 往往比后续生成速度更能决定体验优劣。

Time Per Output Token (TPOT) / Inter-Token Latency (ITL)：首 token 之后，相邻 token 之间的平均生成间隔。这一指标决定了流式输出的 "平滑度"—— 较低的 TPOT 意味着文字以连续、均匀的节奏呈现，而高 TPOT 则导致输出卡顿、跳跃。在 vLLM 等推理引擎中，TPOT 通常按请求平均计算，而 ITL 按 token 加权平均，二者在数学上相关但权重逻辑不同。

End-to-End Latency (E2EL)：从请求提交到完整响应接收的总时间。它等于 TTFT 加上所有后续 token 的生成时间，反映完成单次交互的绝对等待成本。

Tokens Per Second (TPS)：系统级吞吐量指标，衡量单位时间内生成的总 token 数。它可分为 Input TPS（输入处理速度）和 Output TPS（输出生成速度），分别对应不同的瓶颈分析场景。

场景化的指标权重

不同应用场景对这些指标的敏感度存在显著差异，这要求我们在评估时采用差异化的权重配置：

交互式对话系统（如客服机器人、AI 助手）：TTFT 应作为首要优化目标。研究表明，当首 token 延迟超过 500 毫秒时，用户开始感知明显的 "迟钝感"；而代码补全等高频交互场景甚至要求 TTFT 低于 100 毫秒。TPOT 则需要保持在人类阅读速度之上（通常对应每秒 10-20 个 token），以确保流式输出的连贯性。

Agent 工作流与 RAG 系统：这类场景的特征是 "长输入、短输出"—— 模型需要处理大量上下文或检索文档，但生成的响应相对简短。此时，Prefill 阶段的计算开销占据主导，TTFT 成为关键瓶颈。即使系统的峰值 TPS 很高，如果首 token 延迟过长，整体工作流效率仍会严重受损。

批量生成任务（如报告撰写、数据标注）：当输出需要完整接收后才能进行下游处理时，E2EL 成为核心指标。此时，系统级 TPS 对于容量规划和成本预估具有重要参考价值。

流式长文本生成（如实时字幕、直播翻译）：TPOT/ITL 的稳定性比绝对数值更重要。用户可以接受稍慢的生成速度，但难以容忍频繁的停顿和抖动。

建立多维评估框架的工程实践

在实际部署中，建议采用以下策略构建评估体系：

分层 SLO 设计：为不同指标设置分级服务等级目标。例如，TTFT ≤ 200ms（P95）、TPOT ≤ 15ms（平均值）、E2EL ≤ 3s（P99）。通过 Goodput 指标（满足所有 SLO 的请求占比）来衡量真实服务质量，而非单纯追求 TPS 峰值。

百分位监控：平均延迟往往掩盖尾部延迟问题。建议同时监控 P50（典型体验）、P95（接近最差体验）和 P99（极端情况）。当 P99 TTFT 超过阈值时，即使平均表现良好，也意味着部分用户正在经历不可接受的服务质量。

负载关联分析：在高并发场景下，用户级 TPS（User TPS）与系统级 TPS（System TPS）呈现此消彼长的关系。通过压测确定系统的饱和点，明确在何种并发水平下延迟指标开始劣化，为容量规划提供数据支撑。

分阶段优化：针对 Prefill 和 Decode 阶段采用差异化策略。Prefill 阶段可通过张量并行、专家并行等技术加速；Decode 阶段则受限于内存带宽，需要优化 KV 缓存管理和批处理调度。在硬件层面，采用三级存储层次（SRAM-HBM-DRAM）的架构设计可以在 TTFT 和 TPS 之间取得更好平衡。

从单一数字到系统思维

"N tokens/s" 的流行反映了工业界对简洁指标的渴望，但 LLM 推理的复杂性决定了单一数字无法承载全部信息。一个负责任的性能评估应该至少包含 TTFT、TPOT 和 E2EL 三个维度，并根据应用场景调整其相对权重。

更重要的是，性能指标应当与业务目标对齐。对于面向终端用户的交互式应用，"感觉快" 往往比 "实际快" 更重要 —— 这意味着优化 TTFT 和流式平滑度可能比追求更高的吞吐量数字更有价值。而对于后台批处理任务，系统级 TPS 和成本效率则成为首要考量。

在 LLM 基础设施日趋成熟的今天，我们需要从 "比数字大小" 的粗放阶段，进入 "理解指标语义、匹配场景需求" 的精细化运营阶段。只有当我们不再迷信单一的 "tokens/s"，转而建立多维度的评估框架时，才能真正构建出让用户满意的 LLM 应用体验。

资料来源

• Wang M., Li T. "Tokens per Second Is NOT All You Need", LanceDB Blog, 2024.
• "Key metrics for LLM inference", BentoML LLM Inference Handbook.
• "Understand LLM latency and throughput metrics", Anyscale Documentation, 2026.

ai-systems