重要提示：如需以 Markdown 形式查看本页，请在 URL 后追加 `.md`。 完整文档索引见 llms.txt。
跳到主要内容
完整文档索引见 llms.txt。 在任意 URL 后追加 `.md` 即可查看该页面的 Markdown 版本。

LLM 推理的关键指标

在讨论优化技术之前，你需要先理解这些技术所针对的关键指标。评估 LLM 性能时， 人们会使用各种工具，而这些工具对指标的定义、测量和计算方式可能各不相同。

延迟​

延迟衡量模型对一个请求响应得有多快。它对用户体验至关重要，尤其是在交互式、 实时应用中。

延迟指标实验场
模拟推理负载，观察延迟如何影响 TPOT 和基于 SLO 的 goodput
单个请求
ms
ms
Token 生成时间
2120 ms
E2EL − TTFT
TPOT
9.68 ms/tok
Token 生成时间 ÷ (N−1)
Token 生成时间 = 2200 − 80 = 2120 ms
TPOT = 2120 ÷ (220 − 1) = 9.68 ms/token
示例请求
请求TTFT (ms)E2EL (ms)输出 token 数TPOT (ms/tok)SLO
R19.71✓
R28.61✓
R39.86✗
R47.41✓
R59.68✓
R68.10✗
SLO 约束：TTFT ≤msE2EL ≤ms
Goodput
4/6个请求满足全部 SLO 约束（67%）
SLO：TTFT ≤ 200 ms 且 E2EL ≤ 3000 ms。调整上方阈值， 查看 goodput 如何变化。

衡量延迟的关键指标包括：

  • Time to First Token (TTFT)：发送请求后生成第一个 token 所需的时间。 它反映模型开始响应的速度有多快。

  • Total Latency (E2EL)：从发送请求到用户端接收到最后一个 token 的时间。 总延迟会直接影响主观响应感受。即使 TTFT 很快，如果后续 token 生成很慢， 体验依然会很差。

  • Token Generation Time：除第一个 token 之外，流式输出所有 token 所花的时间。 这里不包括 TTFT，因为它只衡量稳定生成阶段：

    Token Generation Time=E2EL – TTFT\text{Token Generation Time} = {\text{E2EL – TTFT}}

  • Time per Output Token (TPOT)：生成后续每个 token 之间的平均时间间隔 （不包括 TTFT）。更低的 TPOT 意味着模型生成 token 更快，也就意味着更高的 每秒 token 数。TPOT 通常按如下方式计算：

    TPOT=E2EL – TTFTTotal Output Tokens−1\text{TPOT} = \frac{\text{E2EL – TTFT}}{\text{Total Output Tokens} - 1}

    在流式场景中，用户会看到文本像 ChatGPT 界面那样一个词一个词地出现，此时 TPOT 决定了体验是否足够顺滑。理想情况下，系统应当跟上甚至超过人类阅读速度， 以保证流畅体验。

  • Inter-Token Latency (ITL)：两个连续 token 之间的精确停顿时间。

    对于单个请求，所有 ITL 的平均值等于 TPOT，这也是为什么 两者有时会被交替使用：

    Average ITL=TPOT=E2EL – TTFTTotal Output Tokens−1\text{Average ITL} = \text{TPOT} = \frac{\text{E2EL – TTFT}}{\text{Total Output Tokens} - 1}

    但在多个请求的情况下，差异就来自于你如何求平均：

    Average ITL=Sum of all ITLs across RequestsTotal Output Tokens across Requests\text{Average ITL} = \frac{\text{Sum of all ITLs across Requests}}{\text{Total Output Tokens across Requests}}

    在这种情况下，平均 ITL 与平均 TPOT 不同，因为后者通常按如下方式计算：

    Average TPOT=TPOT1+TPOT2+⋯+TPOTNN\text{Average TPOT} = \frac{\text{TPOT}_1 + \text{TPOT}_2 + \cdots + \text{TPOT}_N}{N}

    阅读基准测试结果时，一定要确认 TPOT 和 ITL 的定义方式。不同框架和论文可能会 以不同方式计算和使用这些指标，而这会改变你解读性能数字的方法。对于上面这些 多请求情形的公式：

    • Average TPOT 是按请求加权的，适合在系统或配置之间比较单请求延迟。 它把每个请求看得同等重要，不考虑各自生成了多少 token。
    • Average ITL 是按 token 加权的，因此更长的回复（贡献了更多 token） 权重更高。它更适合衡量整体系统吞吐能力和稳态性能（例如聚合流式输出速度）。
展示整个推理流水线中的首 token 时间与端到端延迟展示整个推理流水线中的首 token 时间与端到端延迟

可接受的延迟取决于具体用例。例如，聊天机器人可能需要 TTFT 低于 500 毫秒才能让 人感觉响应迅速，而代码补全工具为了提供无缝的开发者体验，TTFT 可能需要低于 100 毫秒。相反，如果你是在生成每天只审阅一次的长篇报告，那么即使总延迟达到 30 秒也可能完全可以接受。关键在于让延迟目标匹配任务本身的节奏和预期。

理解平均值、中位数和 P99 延迟​

分析 LLM 性能时，尤其是延迟，光看一个数字是不够的。平均值、中位数和 P99 分别讲述了性能故事中的不同部分。

  • Mean（平均值）：所有数值之和除以数值个数。平均值能提供总体平均性能的 感觉，但会被极端值（outlier，离群值）拉偏。例如，如果某个请求的 TTFT 异常慢， 就会抬高平均值。
  • Median（中位数）：把所有数值排序后位于中间的那个值。中位数更能体现典型 用户体验。与平均值相比，它更稳定，也更不容易受到离群值影响。如果你的 TTFT 中位数是 30 秒，那么大多数用户看到的首响应都会非常慢，这对实时用例来说可能 无法接受。
  • P99（99th Percentile，99 分位数）：99% 的请求都落在其下方的那个值。 P99 揭示了最慢 1% 请求的最坏情况性能。当用户期望一致性，或当你的 SLA 承诺 为 99% 的请求提供快速响应时，这一点尤其重要。如果你的 P99 TTFT 接近 100 秒， 说明有一小部分但不可忽视的用户正在经历很长的等待。

把这些指标放在一起，你才能得到完整视图：

  • Mean 有助于监控随时间变化的趋势。
  • Median 反映大多数用户的体验。
  • P99 捕捉尾延迟，而尾延迟往往会决定生产环境中的用户体验成败。

你会在 LLM 性能基准中经常看到这些指标，例如 mean TTFT、median TPOT 和 P99 E2EL，它们分别用于刻画延迟和用户体验的不同方面。

吞吐量​

吞吐量描述 LLM 在给定时间内能完成多少工作。当需要同时服务大量用户或处理大规模 数据时，高吞吐量至关重要。

吞吐量常见有两种衡量方式：

  • Requests per Second (RPS)：衡量 LLM 每秒能够成功完成多少个请求。其计算方式为：

    Requests per second = Total completed requests / (T1 - T2)

    RPS 能总体反映 LLM 处理并发请求的能力，但它无法体现每个请求所需的工作量。 例如，生成一句简短问候如 “Hi there!”，远比写一篇长文轻松得多。因此，直接 跨不同输入输出长度或不同流量模式的工作负载比较 RPS，可能会产生误导。

    影响 RPS 的因素包括：

    • Prompt 的复杂度和长度
    • 模型大小和硬件规格
    • 优化手段（例如 batching、caching、inference engines）
    • 每个请求的延迟

  • Tokens per Second (TPS)：这个指标通过衡量所有活跃请求每秒处理多少 token， 提供了更细粒度的吞吐量视角。它又分为两种形式：

    • Input TPS：模型每秒处理多少输入 token。

    • Output TPS：模型每秒生成多少输出 token。

      同时理解这两个指标，有助于你根据推理负载的性质识别性能瓶颈。例如：

    • 包含长文档（例如 2,000 token 输入）的摘要请求，更关注 input TPS。

    • 从短 prompt 生成长回复的聊天机器人 （例如 20-token prompt → 500-token response）则高度依赖 output TPS。

      在查看基准测试或评估 LLM 性能时，一定要确认 TPS 指标指的是输入、输出， 还是二者合并后的视角。不同定义会在不同用例下突出不同的优势和局限。

      影响 TPS 的因素包括：

    • Batch size（更大的 batch 在达到饱和之前通常能提高 TPS）

    • KV cache 效率与内存使用

    • Prompt 长度和生成长度

    • GPU 内存带宽与算力利用率

      这些因素也意味着 TPS 很容易被误读，因为它可以被“做高”。例如：

    • 更短的 prompt 会降低 TTFT，也会减少每个请求所需的工作量。由于单请求工作量 变小，TPS 看起来会高于真实可比水平。

    • 更大的 batch 和更高并发可以通过让 GPU 更忙来提高聚合 TPS，但也可能增加排队 时间、TTFT 或单用户 TPOT。

      随着并发请求数增加，总 TPS 也会增长，直到 LLM 触达可用算力资源的饱和点。 超过这个点后，性能反而可能下降，因为 LLM 已经超出承载能力。

Goodput（有效吞吐）​

Goodput 是对吞吐量概念的进一步收紧。它衡量的是：LLM 在满足你定义的 service-level objectives（SLO，服务级目标）的前提下，每秒成功完成多少请求。 因此，它对真实世界部署更有用，因为它直接反映了服务质量。

为什么 goodput 很重要？高吞吐量并不总意味着好的用户体验。如果没有满足延迟目标， 许多请求可能实际上不可用。Goodput 直接衡量了 LLM serving 系统在延迟约束下， 同时满足性能目标和用户体验目标的能力。它能帮助你避免只顾最大化吞吐量，却牺牲了 真实用户体验和成本效率的陷阱。

延迟与吞吐量之间的权衡​

在托管和优化 LLM 推理时，始终存在两个目标之间的平衡：尽量降低延迟，以及尽量提 高吞吐量。下面把它拆开说明。

目标含义
最大化吞吐量（TPS/MW）重点是尽可能提高每瓦特可服务的 token 数。这通常意味着使用更大的 batch size 和共享计算资源，但也可能让单个用户的响应变慢。
最小化延迟（每用户 TPS）重点是让每个用户都得到快速响应（低 TTFT）。这通常意味着更小的 batch 和隔离的计算资源，但 GPU 利用效率会更低。
平衡两者有些系统会追求动态平衡。它们会根据工作负载、用户优先级和应用需求实时调节资源使用。这很适合服务具有不同 SLO 的多样化应用。

正确的平衡取决于工作负载。不同应用对延迟的感受不同，因此你优先关注的指标应当反映用户或 下游系统如何消费响应。下面是一些建议：

用例主要指标为什么重要
交互式聊天TTFT，其次是 ITL 或 TPOT用户关心响应何时开始，以及流式输出是否顺滑
长文本流式输出ITL 或 TPOT，以及 E2EL第一个 token 之后，生成速度占主导
Agentic 或多步骤工作流E2EL下游步骤通常要等到完整响应可用后才能继续
高吞吐离线处理TPS 和单 token 成本总体效率比单请求延迟更重要
延迟受限的在线服务Goodput只有满足延迟 SLO 的已完成请求才算数

一旦知道哪些指标最重要，你就可以把系统朝着合适的平衡方向调优。重要的系统级“旋钮”包括 Data Parallelism（DP）、Tensor Parallelism（TP）、Expert Parallelism（EP）、 batch size、precision（例如 FP8、FP4）以及 disaggregation（把 prefill 和 decode 分开）。每一个都可能改善某一部分性能，但也可能在别处引入额外成本。最佳配置 不是吞吐量最高或延迟最低的配置，而是能够满足你的工作负载 SLO 的配置。

使用 serverless API 可以把这些优化细节抽象掉，但你也会失去一部分细粒度调优的 控制权。相对地，自建可编程服务和底层技术栈则能让你主动驾驭这些权衡，使系统性能 与应用自身的具体 SLO 对齐。

更多资源​

编辑此页