跳到主要内容

LLM 推理的关键指标

在探索优化技术之前,你需要理解它们所针对的关键指标。评估 LLM 性能需要用到各种工具,而这些工具对指标的定义、度量和计算方式各不相同。

延迟(Latency)​

延迟(latency)度量模型响应请求的速度。它对于用户体验至关重要,尤其是在交互式、实时的应用中。

提示: 若无法显示,请直接打开 独立工具页面。

度量延迟的关键指标:

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

  • 总延迟(E2EL,End-to-End Latency): 从发送请求到用户端收到最后一个 token 的时间。总延迟直接影响用户感知的响应速度。即使 TTFT 很快,如果后续 token 生成很慢,仍然会导致糟糕的体验。

  • token 生成时间(Token Generation Time): 在第一个 token 之后流式输出所有 token 所需的时间。它不包括 TTFT,因为只度量稳定的生成阶段:

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

  • 每输出 token 时间(TPOT,Time per Output Token): 生成每个后续 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 决定了体验的流畅程度。理想情况下,系统应跟上甚至超过人类的阅读速度,以确保流畅的体验。

  • token 间延迟(ITL,Inter-Token Latency): 两个连续 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 是如何定义的。不同的框架和论文可能以不同的方式计算和使用这些指标,这会影响你如何解读性能数字。在上面针对多个请求的公式中:

    • 平均 TPOT 是请求加权的,当你想要跨系统或配置比较每个请求的延迟时很有用。它平等地对待每个请求,无论生成了多少 token。
    • 平均 ITL 是 token 加权的,因此较长的响应(贡献更多总 token)权重更大。它更适合度量整体系统吞吐量和稳态性能(例如聚合流式速度)。
推理流水线中的首 token 时间和端到端延迟

可接受的延迟取决于使用场景。例如,聊天机器人可能需要 TTFT 低于 500 毫秒才能让用户感觉响应迅速,而代码补全工具可能需要 TTFT 低于 100 毫秒才能带来无缝的开发者体验。相比之下,如果你生成的是每天审阅一次的长报告,那么即使总延迟 30 秒也可能完全可以接受。关键在于让延迟目标与手头任务的节奏和预期相匹配。

理解平均(mean)、中位数(median)和 P99 延迟​

在分析 LLM 性能(尤其是延迟)时,只看一个数字是不够的。平均(mean)、中位数(median)和 P99 等指标各自讲述了故事的不同侧面。

  • 平均(Mean/Average): 所有值的总和除以值的数量。平均给出了平均性能的总体感觉,但可能会被极端值(离群点)拉偏。例如,如果某个请求的 TTFT 异常缓慢,就会拉高平均值。
  • 中位数(Median): 所有值排序后的中间值。中位数反映了典型用户的体验。它比平均值更稳定,更能抵抗离群点的影响。如果你的 TTFT 中位数是 30 秒,那么大多数用户看到的是非常慢的首响应,这对于实时场景可能是不可接受的。
  • P99(第 99 百分位): 99% 的请求都低于该值。P99 揭示了最慢的 1% 请求的最坏情况性能。当用户期望一致性,或你的 SLA 保证 99% 的情况下都能快速响应时,这一点很重要。如果你的 P99 TTFT 接近 100 秒,说明有一小部分但不可忽视的用户面临非常长的等待。
    备注

    你可能还会看到 P90 或 P95,它们分别表示第 90 和第 95 百分位延迟。这些指标有助于理解接近最坏情况的性能,并且常用于 P99 可能过于严格或对噪声过于敏感的情况。

综合来看,这些指标能让你对性能有全面的了解:

  • 平均有助于监控随时间变化的趋势。
  • 中位数反映了大多数用户的体验。
  • P99 捕获尾部延迟,它可能成就或毁掉生产环境中的用户体验。

你经常会看到这些指标出现在 LLM 性能基准测试中,例如平均 TTFT、中位数 TPOT 和 P99 E2EL,以捕获延迟和用户体验的不同方面。

吞吐量(Throughput)​

吞吐量(throughput)描述 LLM 在给定时间段内能完成多少工作。当同时服务大量用户或处理海量数据时,高吞吐量至关重要。

度量吞吐量有两种常见方式:

  • 每秒请求数(RPS,Requests per Second): 该指标衡量 LLM 在一秒内能成功完成多少个请求。其计算公式为:

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

    这里,T1 和 T2 表示以秒为单位的时间窗口。

    RPS 能大致反映 LLM 处理并发请求的能力,但它没有捕获每个请求所需的工作量。例如,生成一句简短的问候语 "Hi there!" 远比写一篇长文章要轻松得多。因此,直接比较输入和输出长度或流量模式不同工作负载之间的 RPS 可能会产生误导。

    影响 RPS 的因素:

    • 提示词的复杂度和长度
    • 模型大小和硬件规格
    • 优化(例如批处理、缓存、推理引擎)
    • 每个请求的延迟

  • 每秒 token 数(TPS,Tokens per Second): 该指标通过度量所有活跃请求每秒处理的 token 数量,提供更细粒度的吞吐量视图。它有两种形式:

    • 输入 TPS(Input TPS): 模型每秒处理多少输入 token。
    • 输出 TPS(Output TPS): 模型每秒生成多少输出 token。

    理解这两个指标有助于你根据推理工作负载的性质来识别性能瓶颈。例如:

    • 包含长文档(例如 2,000 个 token 的输入)的摘要请求更关心输入 TPS。
    • 从短提示词生成长回复的聊天机器人(例如 20 个 token 的提示词 → 500 个 token 的响应)则严重依赖输出 TPS。

    在查看基准测试或评估 LLM 性能时,务必检查 TPS 指标指的是输入、输出还是综合视图。它们根据使用场景突出了不同的优势和局限。

    影响 TPS 的因素:

    • 批次大小(更大的批次可以提高 TPS,直到达到饱和)
    • KV 缓存效率和内存占用
    • 提示词长度和生成长度
    • GPU 内存带宽和算力利用率

    这些因素也意味着 TPS 很容易被误读,因为它可以被「优化」得更好看。例如:

    • 更短的提示词会降低 TTFT,从而减少每个请求所需的工作量。由于每个请求的工作量更少,TPS 看起来会比实际情况更高。

    • 更大的批次和更高的并发可以通过让 GPU 保持繁忙来提高聚合 TPS,但可能会增加排队时间、TTFT 或每个用户的 TPOT。

      随着并发请求数量的增加,总 TPS 也会增长,直到 LLM 达到可用计算资源的饱和点。超过这个点后,性能可能会下降,因为 LLM 已经超出容量。

有效吞吐量(Goodput)​

有效吞吐量(goodput)细化了吞吐量的概念。它衡量 LLM 在满足你定义的服务等级目标(SLO,Service-Level Objective)的同时,每秒能成功完成多少个请求。这使得它对于真实世界部署来说更有用,因为它直接反映了服务质量。

信息

**服务等级目标(SLO,Service-Level Objective)**为特定指标定义了目标性能水平。它为「什么样的服务是可接受的」设定标准。例如,TTFT 的 SLO 可能规定 95% 的聊天机器人交互的 TTFT 应低于 200 毫秒。SLO 通常是服务提供商与其用户之间更广泛的服务等级协议(SLA)的关键组成部分。

为什么有效吞吐量很重要?高吞吐量并不总是意味着良好的用户体验。如果延迟目标没有达到,许多请求可能实际上无法使用。有效吞吐量直接衡量 LLM 服务系统在延迟约束下,在多大程度上同时满足性能和用户体验目标。它有助于避免以牺牲真实用户体验和成本效益为代价来最大化吞吐量的陷阱。

延迟与吞吐量的权衡​

在托管和优化 LLM 推理时,始终要在两个关键目标之间取得平衡:最小化延迟和最大化吞吐量。让我们来分析一下这意味着什么。

目标影响
最大化吞吐量(TPS/瓦)侧重于尽可能多地服务每瓦特对应的 token 数。这通常意味着使用更大的批次和共享的计算资源。然而,这可能会减慢单个用户的响应速度。
最小化延迟(每个用户的 TPS)侧重于给每个用户快速的响应(低 TTFT)。这通常涉及小批次和隔离的计算资源,但这意味着 GPU 的利用效率会降低。
两者平衡一些系统力求达到动态平衡。它们根据工作负载、用户优先级和应用需求实时调整资源使用。这对于服务具有不同 SLO 的多样化应用来说是理想的。

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

使用场景主要指标为什么重要
交互式聊天TTFT,其次是 ITL 或 TPOT用户关心响应何时开始,以及是否流畅地流式输出
长文流式生成ITL 或 TPOT 以及 E2EL第一个 token 之后,生成速度占主导地位
智能体或多步工作流E2EL下游步骤通常要等到完整响应可用后才能继续
高容量离线处理TPS 和每 token 成本聚合效率比单个请求的延迟更重要
延迟受限的在线服务有效吞吐量(Goodput)只有满足延迟 SLO 的已完成的请求才被计入

一旦你知道哪些指标最重要,就可以将系统调整到适当的平衡。重要的系统级「旋钮」包括数据并行(DP)、张量并行(TP)、专家并行(EP)、批次大小、精度(例如 FP8、FP4)以及分离(将预填充和解码分开)。每一项都能改进性能的某一部分,但可能会在其他方面增加成本。最佳的配置是能满足工作负载 SLO 的配置,而不是简单地提供最高吞吐量或最低延迟。

使用无服务器 API 可以隐藏这些优化,让你对微调的控制更少。另一方面,构建你自己可编程的底层技术栈,可以让你在这些权衡中游刃有余,使系统性能与应用的具体 SLO 保持一致。

其他资源​