在推理过程中，模型可能返回一个结果，例如欺诈评分；也可能逐段流式返回结果，例如生成的文本。单次预测通常有一个明确的完成时间点，但流式响应并没有：首次可见输出和完整响应会在不同时间到达。
如何测量推理延迟
首先要确定测量边界。
模型延迟通常涵盖模型服务器附近或内部的工作。根据平台的不同，它可能包括预处理或与模型容器通信的时间。
服务延迟可能还会加入模型周围的准入检查、排队和批处理时间。
端到端延迟从客户端的角度进行测量，可能包括网络传输、网关、服务队列、模型执行、后处理以及结果交付。
这些标签并没有完全统一的标准。一个平台的“模型延迟”可能包括另一个平台记作开销的工作。因此，时间戳本身就是定义的一部分。“从客户端发送到收到最终响应”具有可比性；而“延迟为 800 毫秒”则没有。
对于流式输出文本的语言模型，计时器也可以在不同的输出事件处停止：
- 首 Token 时间（TTFT）在收到第一个输出 Token 时结束，用于衡量响应开始出现的速度。
- 端到端请求延迟有时称为末 Token 时间，在收到完整响应时结束。
- Token 间延迟（ITL）衡量生成开始后连续输出 Token 之间的时间间隔。一些工具将其称为每个输出 Token 的平均耗时。
按照一种常见约定：
端到端延迟 = TTFT + 生成时间
如果响应包含n个输出 Token，则首个 Token 之后的平均 Token 间延迟为：
（端到端延迟 - TTFT）/（n - 1）
分母是n - 1，因为n tokens contain that many gaps after the first token. Check the tool's definition before comparing results. Some tools include the first-token wait in a per-token average, while others exclude it.
示例计算
假设客户端为一个假想的流式响应记录了以下时间戳：
- 发送请求：
0 毫秒 - 收到第一个输出 Token：
450 毫秒 - 收到最后一个输出 Token：
1,400 毫秒 - 输出长度：
20 个 Token
客户端观测到的 TTFT 为 450 毫秒。端到端延迟为 1,400 毫秒。首个 Token 之后的生成耗时为 950 毫秒，分布在 19 个 Token 间隔中：
950 毫秒 / 19 = 50 毫秒
因此，同一个请求的首 Token 延迟为 450 毫秒，平均 Token 间延迟为 50 毫秒，完成延迟为 1.40 秒。这些数值彼此不能相互替代。
现在假设模型服务器报告模型容器内的工作耗时为 720 毫秒。这并不能证明剩余的 680 毫秒是网络延迟。客户端和服务器的计时器可能覆盖相互重叠或定义不同的阶段。要解释这一差距，需要对齐排队、预处理、模型执行、后处理和网络传输的时间戳。
影响推理延迟的因素
延迟是整个测试的结果，而不是模型的固定属性。它会受到以下因素影响：
- 输入的形状和大小。更多输入可能需要更多预处理和模型计算。
- 输出的形状和大小。生成更长的响应需要更多连续的生成步骤。
- 流量和并发量。当其他工作占用相同的服务资源时，请求可能需要等待可用容量。
- 批处理和调度。将请求分组可以提高系统整体效率，但也可能让单个请求等待更久。
- 硬件和服务软件。加速器、数值精度、内存移动、内核和推理引擎都会影响执行时间。
- 热状态或冷状态。如果代码、模型数据或缓存尚未准备就绪，请求可能会变慢。
- 应用阶段。检索、安全检查、工具调用和后处理都可能在模型之外增加用户可感知的延迟。
- 网络和客户端位置。服务器端基准测试不包括远程用户所经历的每一跳网络路径。
对于生成文本，输入长度通常会影响输出开始前的等待时间，而输出长度会显著影响响应完成的时间。流式传输可以更早显示部分输出，让界面感觉更灵敏，但它本身并不能保证更低的完成延迟。
为什么平均值还不够
生产服务会在不断变化的负载下处理大小不同的请求。一个平均值会压缩这一分布，并可能掩盖等待时间最长的请求。
延迟通常使用百分位数报告。p95 完成延迟是指 95% 的测量请求在该数值或更短时间内完成，剩余 5% 的请求耗时更长。p50 描述中间请求，而 p95 或 p99 能揭示更慢的长尾。
每个报告的百分位数仍然需要上下文。至少应标注：
- 边界：从客户端到首个 Token、从客户端到最终结果，或明确命名的服务器端时间区间。
- 工作负载：模型、输入分布、输出分布和请求设置。
- 负载：并发量或请求到达模式。
- 统计量：p50、p95、p99、平均值或单请求数值。
例如，“该工作负载在 20 个并发请求下，从客户端到最终结果的 p95 延迟”就是一个可用的测量结果。来自不同提示词组合或单请求负载下的较低数值，并不能证明生产系统更快。
为什么推理延迟很重要
延迟决定单个请求需要等待多长时间。相关的停止点取决于产品。
交互式界面可能最关注首次可见输出。后台分类器关注的是完成的预测。多步骤系统必须等前一步结果完成后才能开始下一个依赖步骤，因此完成延迟可能会在整个序列中累积。
延迟还与吞吐量有关，吞吐量衡量系统在一段时间内完成的工作量。增大批量大小或并发量可以提高总吞吐量，同时增加每个请求的等待时间。因此，一个系统每秒处理的 Token 总数可能更多，但对单个用户而言仍然感觉更慢。
常见误解
“推理延迟”总是指模型执行时间。并不是。这个术语也用于服务级别和客户端观测到的计时。请查看测量边界。
首 Token 时间就是响应延迟。它只是响应的一个时间节点。首个 Token 很快出现后，生成过程仍可能持续很长时间。
流式传输会让推理更快完成。流式传输改变的是部分结果交付的时间。即使最终结果在同一时间到达，它也能改善感知上的响应速度。
一个模型只有一个延迟数值。结果取决于输入、输出、负载、硬件、软件以及所报告的统计量。
每秒处理的总 Token 数越高，延迟就越低。总体吞吐量和单请求等待时间可能朝相反方向变化。
下一步阅读
当流式响应的开始时间很重要时，请使用首 Token 时间。使用每秒 Token 数描述生成速度，使用推理吞吐量描述总体服务能力。若要并列区分这些概念，请参阅延迟 vs. TTFT vs. 每秒 Token 数 vs. 吞吐量。