LLM API 延迟：TTFT、每秒 token 数与总时间（2026）

延迟是最先被投诉的那个问题。模型答得对、成本也能接受，但第一个字要等四秒才出来，产品体感就是坏的。把 LLM API 延迟当成一个数字来讨论，是大多数优化最后没有结果的根本原因。

LLM API 延迟其实是三个数字

单一的"响应时间"把三个性质完全不同的量混在了一起。

首字延迟（TTFT，time to first token）：调用方从发出请求到收到第一个 token 的时间，包含网络传输、服务端排队、以及对你 prompt 的 prefill 计算。对话式界面里用户真正感知到的就是它。

token 间延迟：开始生成之后每个 token 之间的间隔，通常用它的倒数（每秒 token 数）来表示。它决定文字是顺畅流出还是一顿一顿。

总完成时间：TTFT 加上生成全部输出 token 的时间。批处理任务只关心它；交互式界面里它是最没用的一个数。

优化错对象非常常见：有的团队换小模型把总完成时间压下来了，TTFT 却纹丝不动——因为那里的 TTFT 主要由排队而不是由模型决定。

真正决定这三个数的是什么

输出长度占主导。生成是串行的，每个 token 都要等前一个。同一个模型下，900 token 的回答大约要花 300 token 回答三倍的时间。prompt 长度则不同：prefill 是并行的，prompt 翻倍对 TTFT 的抬升，远小于输出翻倍对总时间的抬升。如果只能动一个变量，就动"你要求它输出多长"。

模型体量决定下限。模型越大，每秒生成的 token 越少。再多的基础设施优化，也不可能让一个模型跑得比它自身的生成速度更快。

流式改变的是体感，不是总量。流式并不会让响应更早结束，它把感知上的等待压缩到 TTFT，而 TTFT 通常只占总时间的一小部分。对任何"边出边读"的场景，这是可选项里性价比最高的一个。事件流怎么正确消费是另一个话题，见Claude API 流式响应。

距离和网络真实存在，但通常不是大头。跨洲一次往返增加几十到一两百毫秒。当 TTFT 是 400 毫秒时这很关键，当 TTFT 是四秒时它是噪声。

服务端排队是那个看不见的变量。负载高时，请求要先排队才轮到 prefill。p50 很好看而 p99 很难看，通常就是它造成的——而且这一段在你自己的进程里完全观测不到。

prompt 缓存省的是 prefill，不是生成。在支持的服务上，共享的长前缀被缓存后，重复调用可以省掉大部分 prefill 开销：它降低 TTFT，对每秒 token 数没有影响。

怎么把 LLM API 延迟测准

大多数被引用的延迟数字，是在开发机上、对着热端点、用空 prompt 取的平均值。它们谈不上错，只是和生产环境无关。

测分位数，不要测平均。平均值会被少数极慢的调用拽着走，而那批调用恰恰是你要治理的对象。请报告 p50、p95、p99；p50 与 p99 之间的差距，直接告诉你暴露在多少排队风险里。

TTFT 和总时间分开记。合成一个数之后，你就再也分不清"模型慢"和"服务端忙"。

用生产形态的输入测。真实的 prompt 长度、真实的输出长度、真实的系统前缀。一个只要十个 token 的基准测试，对一个要生成六百 token 的功能几乎没有参考价值。

在调用真正发起的地方测，不是在你工位上测——另一个大洲的 serverless 区域跑出来的数完全不同。

固定并发并记录下来。并发 1 和并发 50 下测出的延迟，是两个共用同一个名字的指标。

你实际能改的东西

按效果大致排序：

少要点输出。设置 max tokens 上限、要求结构化或精简的回答、不要让模型先把问题复述一遍再作答。这一条通常比其余所有加起来还值钱。
凡是给人读的都上流式。它把总时间问题转化成 TTFT 问题。
选能过你自己评测的最小模型。不是可选项里最小的那个，而是仍然答得对的那个最小的，用你自己的用例来判定。
缓存稳定前缀，尤其是跨调用复用的长系统指令。
让互相独立的调用并行，别串起来。三次 1.5 秒的串行调用是 4.5 秒，并发跑大约是 1.5 秒。
把调用方挪近服务区域——在上面这些都做完之后再考虑。

链路里有网关的时候

走网关或代理会多一跳。诚实的预期是：网关位置合理时，额外开销在个位数到几十毫秒量级。相对于以百毫秒甚至秒计的 TTFT，这点开销很少是问题所在——但值得实测而不是假设，因为位置不当的网关可能凭空加上一次跨区往返。用同样的 prompt、同样的并发，对比链路里有无网关时的 TTFT。这些组件各自做什么，见LLM API 网关；协议兼容性见什么是 OpenAI 兼容 API。

常见问题

LLM API 的 TTFT 多少算好？

没有通用数字。任何不附带模型、prompt 体量和区域的数字都没法用。可操作的判据是你自己的 p95 对你自己的界面：如果用户正盯着光标闪，一秒以内是跟手的，好几秒就是坏的。先按交互形态定目标，再去测有没有达到。

流式到底有没有降低延迟？

它降低的是感知延迟，也就是用户会投诉的那一个。总完成时间没有变，某些客户端实现下甚至略微变差。但对交互式文本，它仍然是多数团队能做的最划算的改动。

为什么我的 p99 比 p50 差那么多？

几乎总是排队——要么是服务端负载下的排队，要么是你自己连接池里的排队。输入体量稳定的前提下 p99 是 p50 的好几倍，指向的是资源争抢而不是模型本身。看看尖峰是否在时间上聚集：如果是，那就是负载不是内容。

prompt 变长和回答变长，拖慢程度一样吗？

不一样，而且差距很大。对 prompt 的 prefill 是并行的，回答的生成是严格串行的。砍掉 500 token 的输出，省下的墙钟时间远多于砍掉 500 token 的 prompt。

换小模型是不是一定更快？

它会提高每秒 token 数，所以生成更早结束。但如果你的延迟主要来自排队或网络距离，换小模型没有用，而且要付出准确率的代价。先量清楚时间到底花在哪里，再决定要不要拿质量换速度。

一句话总结

LLM API 延迟是三个数而不是一个：首字延迟、每秒 token 数、总时间。输出长度和模型选择决定下限，排队决定长尾，流式改变用户体感但不改变总量。用生产形态的 prompt、在代码真正运行的位置测 p95，然后去修和你界面匹配的那个数，而不是最容易改好的那个数。