延迟优化

用户感知到的快慢主要由首 token 延迟决定，而这部分又大半花在预填充上。这些毫秒到底去了哪。

总响应时间是个错误的目标。用户评判的是首 token 延迟，因为阅读比生成慢——一旦文字开始往外冒，剩下的都在用户的阅读背后完成了。

所以这件事分成两个独立的问题，各有各的解法。

时间花在哪

首 token 延迟主要由预填充决定：生成开始之前，先把你的整个 prompt 处理完。它随 prompt 长度增长，而且增长很陡，因为注意力成本是平方级的。

每秒 token 数是解码循环——每个 token 大致是个常数，由模型大小和服务器负载决定。

总时间等于前者，加上「输出长度 ÷ 后者」。该攻哪一个取决于你的形态：长 prompt 配短回答，瓶颈在预填充，缩短 prompt 就是解法。短 prompt 配长回答，瓶颈在解码，只有换更小的模型或减少输出才有用。

不开流式输出把两者分开测，你根本分不清自己属于哪种。这是第一个该埋点的地方。

压低首 token 延迟

缩短 prompt。 杠杆最大的一招，而且效果比线性更好，因为预填充是平方级的。检索 5 个文本块而不是 20 个；给对话历史设个上限。

开启 prompt 缓存。 把稳定内容放前面，这样缓存命中的前缀能直接跳过预填充。几乎零成本，而且纯粹是一个排序决定——见砍掉 API 账单。

立刻开始流式输出。 它不降低真实延迟，但大幅降低感知延迟——而你要优化的正是感知延迟。

在模型回应之前先显示进度。 对 RAG 来说检索要花真实时间——把这个步骤显示出来，别给用户一块白屏。

压低生成时间

换更小的模型。 单项杠杆里最大的一个。大多数任务用不上顶配，而按任务路由就是既拿到速度、又不牺牲那些确实需要能力的场景的办法。

要求更少的输出。 输出 token 是逐个生成的，所以答案越短就越快。「用两句话回答」再加上一个很低的 max_tokens，是实打实的延迟改善。

在没用的地方跳过推理。 思维链和推理模型是拿延迟换准确率。难题上值得，查资料这类任务上纯粹是白花成本。

如果你能控制服务端，用投机解码。 单请求收益可观，高并发批处理下收益很小。

结构性的收益

并行化相互独立的调用。 三次检索或三次分类应该并发跑，而不是排着队跑。多步流水线里可拿到的最大改善常常就在这，也常常被漏掉，因为代码读起来天然就像一串顺序执行。

缓存响应。 重复的问题用自己的缓存回答，延迟接近零。能用上的地方就是白捡。

能提前返回就提前返回。 生成还在跑的时候先把检索到的来源显示出来；如果 schema 允许，直接渲染部分的结构化输出。

把工作挪出请求路径。 任何不必在响应之前做完的事——写日志、二次分类、写记忆——都该放进后台任务。

多步流程与 agent 流程

对 agent 循环来说，每一轮都是一次完整的往返，所以延迟大致等于步数乘以单步时间。减少步数比让单步更快更重要。

两个实用做法：当模型一次请求多个工具时，把彼此独立的工具调用并行起来；以及在循环层面流式汇报进度——显示正在跑哪个工具——别让一个十二步的执行全程一声不吭。

波动是常态

托管 API 的硬件是共享的。你的延迟取决于并发流量，别人的一个长 prompt 就能让你的流在响应中途卡住。

要为这一点做设计：宽松的超时、退避重试、用流式输出让部分结果可见，以及跟踪分位数而不是平均值。用户真正体验到的、会去抱怨的是尾部，而平均值把它完全抹掉了。

要点回顾

优化的重点是首 token 延迟——阅读比生成慢，所以感知到的快慢主要由开头决定。
预填充（随 prompt 长度平方增长）决定首 token 延迟，解码决定剩下的部分。优化之前先分开测这两项。
缩短 prompt、开启前缀缓存、立刻开始流式输出。
生成侧：更小的模型、更少的输出、跳过没必要的推理。
并行化相互独立的调用常常是流水线里最大的一笔收益，同时把非必要的工作挪出请求路径。
跟踪分位数而不是平均值；托管服务的延迟会随别人的流量波动。

下一篇： 可靠性模式

总响应时间是个错误的目标。用户评判的是首 token 延迟，因为阅读比生成慢——一旦文字开始往外冒，剩下的都在用户的阅读背后完成了。

所以这件事分成两个独立的问题，各有各的解法。

时间花在哪

首 token 延迟主要由预填充决定：生成开始之前，先把你的整个 prompt 处理完。它随 prompt 长度增长，而且增长很陡，因为注意力成本是平方级的。

每秒 token 数是解码循环——每个 token 大致是个常数，由模型大小和服务器负载决定。

不开流式输出把两者分开测，你根本分不清自己属于哪种。这是第一个该埋点的地方。

压低首 token 延迟

缩短 prompt。 杠杆最大的一招，而且效果比线性更好，因为预填充是平方级的。检索 5 个文本块而不是 20 个；给对话历史设个上限。

开启 prompt 缓存。 把稳定内容放前面，这样缓存命中的前缀能直接跳过预填充。几乎零成本，而且纯粹是一个排序决定——见砍掉 API 账单。

立刻开始流式输出。 它不降低真实延迟，但大幅降低感知延迟——而你要优化的正是感知延迟。

在模型回应之前先显示进度。 对 RAG 来说检索要花真实时间——把这个步骤显示出来，别给用户一块白屏。

压低生成时间

换更小的模型。 单项杠杆里最大的一个。大多数任务用不上顶配，而按任务路由就是既拿到速度、又不牺牲那些确实需要能力的场景的办法。

要求更少的输出。 输出 token 是逐个生成的，所以答案越短就越快。「用两句话回答」再加上一个很低的 max_tokens，是实打实的延迟改善。

在没用的地方跳过推理。 思维链和推理模型是拿延迟换准确率。难题上值得，查资料这类任务上纯粹是白花成本。

如果你能控制服务端，用投机解码。 单请求收益可观，高并发批处理下收益很小。

结构性的收益

缓存响应。 重复的问题用自己的缓存回答，延迟接近零。能用上的地方就是白捡。

能提前返回就提前返回。 生成还在跑的时候先把检索到的来源显示出来；如果 schema 允许，直接渲染部分的结构化输出。

把工作挪出请求路径。 任何不必在响应之前做完的事——写日志、二次分类、写记忆——都该放进后台任务。

多步流程与 agent 流程

对 agent 循环来说，每一轮都是一次完整的往返，所以延迟大致等于步数乘以单步时间。减少步数比让单步更快更重要。

波动是常态

托管 API 的硬件是共享的。你的延迟取决于并发流量，别人的一个长 prompt 就能让你的流在响应中途卡住。

要点回顾

优化的重点是首 token 延迟——阅读比生成慢，所以感知到的快慢主要由开头决定。
预填充（随 prompt 长度平方增长）决定首 token 延迟，解码决定剩下的部分。优化之前先分开测这两项。
缩短 prompt、开启前缀缓存、立刻开始流式输出。
生成侧：更小的模型、更少的输出、跳过没必要的推理。
并行化相互独立的调用常常是流水线里最大的一笔收益，同时把非必要的工作挪出请求路径。
跟踪分位数而不是平均值；托管服务的延迟会随别人的流量波动。

下一篇： 可靠性模式