AI 推理延迟中首 token 与总耗时分别怎么看

同一个模型接口，用户说“响应太慢”时，至少可能在说两件不同的事：等了很久才看到第一个字，或者第一个字很快但整段答案迟迟没有结束。前者主要看 TTFT（Time to First Token），后者看端到端耗时；把两个数字混成一个平均延迟，优化方向很容易跑偏。

先记录请求开始、首个可见 token、最后一个 token 三个时间点：首 token 之前的等待是 TTFT，首 token 之后的流式速度决定阅读过程是否顺滑，直到最后一个 token 的时间才是完整响应耗时。

先把三个时间点记全，别把 TTFT 当成总耗时

在客户端或网关给一次请求打上三个时间戳：发送请求的 t0、收到第一个可见 token 的 t1、收到结束标记的 t2。基础计算很简单：

• TTFT = t1 - t0：用户多久看到第一点反馈。
• 总耗时 = t2 - t0：从提交到完整回答结束。
• 流式阶段 = t2 - t1：首 token 之后，剩余内容花了多久。

例如一次请求 420 毫秒出现首 token，3.8 秒才结束，那么用户感知的“开始响应”是 420 毫秒，但接口完整完成是 3.8 秒。做聊天体验优化时不能拿 3.8 秒替代 TTFT；做代码补全、结构化 JSON 或 Agent 工具调用时，也不能因为 TTFT 很小就判定任务快。

首 token 到底慢在哪里：网络、排队和 prefill 要拆开

TTFT 通常包含请求到服务端的网络时间、调度排队、RAG 检索与提示词组装，以及模型读取输入上下文的 prefill。prefill 完成后才会进入逐 token 的 decode，所以长提示词、很长的检索上下文和高并发都可能把首 token 推迟。

这也是为什么“模型每秒能生成多少 token”不能直接回答首 token 问题。tokens/s 多半描述生成阶段的吞吐；如果请求在队列里等了 800 毫秒，或者向量检索先花了 500 毫秒，decode 很快也无法让用户更早看到结果。Triton 这类推理服务还会把 request、queue、compute input、compute infer、compute output 等部分分别暴露，排查时应让这些分段指标和请求时间互相对账。

RAG 场景建议至少记录 retrieve_ms、queue_ms、prefill_ms 和 ttft_ms。如果 retrieve_ms 已经占据大头，先缩小候选集、减少重排或改善缓存，比盲目更换模型更直接；如果队列时间随并发陡增，则应检查批处理策略、实例数和限流。

用 TPOT 或 ITL 判断首 token 之后是否顺滑

首 token 到达后，用户还会感受到每个 token 之间的间隔。ITL（Inter-Token Latency）是相邻 token 的时间间隔，TPOT（Time Per Output Token）常用来表示这一阶段的平均值。两者都不该替代 TTFT：一个回答可能首 token 很快，却每隔很久才吐出下一个 token。

可把总耗时粗略理解为：

端到端耗时 ≈ TTFT + 输出 token 数 × 平均 TPOT

这是观测公式，不是精确计费公式。实际 ITL 会随动态批处理、输出长度和负载变化，因此要保留 token 数和分位数。下面这段前端计时只关心时间点，不把网络流事件误当成模型内部阶段：

const startedAt = performance.now();
let firstTokenAt = null;
let tokenCount = 0;

for await (const chunk of stream) {
  // 只在第一次收到可见文本时记录 TTFT，避免空事件污染数据。
  if (firstTokenAt === null && chunk.text) firstTokenAt = performance.now();
  tokenCount += chunk.text ? 1 : 0;
  render(chunk.text || "");
}

const finishedAt = performance.now();
const ttftMs = firstTokenAt === null ? null : firstTokenAt - startedAt;
const e2eMs = finishedAt - startedAt;
// 这里用 token 数保存口径，后续再结合有效输出 token 计算平均 TPOT。
const streamMs = firstTokenAt === null ? null : finishedAt - firstTokenAt;
console.log({ ttftMs, e2eMs, streamMs, tokenCount });

先按工作负载选指标，再谈优化

指标没有脱离场景的“绝对第一名”。交互聊天通常先盯 TTFT 和 ITL：用户需要尽早看到反馈，也需要稳定的输出节奏。代码生成和结构化输出更关心 E2E，因为编辑器或下游解析器往往要等完整结果。Agent 要看一次调用之外的 trace latency，检索、模型、工具和下一轮模型调用是串起来的；批处理则更关心吞吐、单位成本和是否按时完成。

一套能落地的延迟排查清单

1. 先按请求类型分组，分别记录 TTFT、ITL、E2E、输出 token 数和成功率。
2. 再看 P50、P95、P99；平均值正常而 P99 很高，通常意味着队列、冷启动或输入长度存在长尾。
3. 把 RAG 检索、网关、模型队列和生成阶段放进同一个 trace，确认各段相加是否接近 E2E。
4. 最后才做优化选择：重复请求考虑缓存，长上下文考虑压缩或前缀复用，排队明显则调整并发与实例容量。

最值得保留的是原始时间点，而不是一个被聚合过的“平均延迟”。只要 t0、t1、t2 和输出长度还在，后续换模型、换推理框架或换流式协议时，指标口径仍然可以复算。

相关问题

TTFT 越低，完整回答一定越快吗？

不一定。TTFT 只覆盖首 token 之前的等待；输出很长、ITL 很高或停止条件迟迟不满足时，E2E 仍可能很大。

为什么同一模型的 TTFT 会突然变高？

优先检查并发导致的队列等待、输入上下文长度、RAG 检索耗时和冷启动，再判断是否是模型计算本身变慢。

应该看平均值还是 P99？

平均值适合看整体趋势，交互产品的体验和告警更应关注 P95/P99，并同时保留输入长度、队列时间和输出长度。