你有没有遇到过这种情况：明明只问了 AI 一句简单的话，它却半天没有反应，对话框里一片空白；或者它已经开始回复了，但一个字一个字往外蹦，像挤牙膏似的。这两种体验，都让人觉得“慢”。但在模型推理的视角里，它们其实是两码事。

第一种叫 Prefill——模型先把你的输入“读”完；第二种叫 Decode——模型才开始“写”回答。简单说，Prefill 决定你多久能看到第一个字；Decode 决定模型开口之后输出得有多快。

AI 回答分成两步

一次对话可以拆成两个阶段，看这张时间轴会更清楚：

第一阶段是 Prefill，有点像“读题”。你发给模型的 prompt 里，不光有这次的问题，还可能带着系统提示词、历史对话、工具返回结果、检索到的文档，甚至整段代码。模型得先把这些内容全部处理完，准备好中间状态（也就是常说的 KV Cache），才能进入回复环节。

第二阶段是 Decode，有点像“写答案”。模型读完题之后，开始生成回答，但这个回答不能一次性全部写出来——它必须一个 token 一个 token 往后接。第10个 token 依赖前面9个，第100个依赖前面99个，一环扣一环。

所以，一次请求的总时长 = 处理输入的时间 + 生成答案的时间，就是这么简单粗暴。

Prefill 慢是“迟迟不开口”

问题发出去，界面一直空着，模型迟迟没反应——这段时间就是在 Prefill。在 API 指标里，这段等待时间叫 TTFT（Time To First Token），从请求发出到第一个 token 出现之前所消耗的时间。

如果你给的 prompt 很长，Prefill 阶段就会被拉长。比如让模型读一整篇论文、分析一个代码仓库、总结一大段会议记录，或者 Agent 把大量工具调用结果和历史轨迹都塞进上下文里——模型都得先把这些输入啃完，才会开口。

这就是为什么有时候你只让 AI 回答一句话，它却让你等很久。慢点不在回答的难易，而在你给的输入太长。模型在真正开口之前，得花时间把上下文读完。

Prefill 还有一个特点：这个阶段模型已经接收了完整的输入，可以把一批 token 放在一起处理，所以比较容易把 GPU 算力用满。但上下文越长，开口前要读、要算的内容就越多，长 prompt 带来的前置成本明显增加。

这也是为什么很多推理优化都盯着 Prefill 做文章——prompt caching、prefix caching、chunked prefill，核心目标就是让模型少读重复内容，更稳定地拆解超长输入。

Decode 慢是“说得很慢”

Decode 对应另一种慢：模型开始回复了，但输出速度很慢。你会看到它一个 token 一个 token 往外蹦，短回答还好，但要是让它写长文、写代码，或者生成一份完整分析报告，Decode 阶段的时间就会明显变长。

原因很简单：模型生成回答是个顺序过程。它没法直接跳到最后一句话，也没法一次性算完所有内容。前一个 token 出来了，后一个 token 才能接着生成。所以 Decode 阶段的耗时和输出长度直接挂钩——让模型回答50个 token 和2000个 token，体验完全不一样。即使输入很短，只要输出很长，总处理时间照样被拉长。

在 API 指标里，Decode 常用 TPS（tokens per second）来衡量，也就是模型每秒能生成多少 token。用户看到的模型“打字速度”，就和这个指标有关。

两种不同的慢

理解了 Prefill 和 Decode，就能清楚判断一次 AI 请求到底慢在哪。

• 如果你给了很长的上下文，但只需要一个很短的答案，慢点通常更偏向 Prefill。举个例子：“请根据这份10万字资料，告诉我里面有没有提到项目A。”这种请求可能要等模型一会才会开始输出，但一旦开始，回复很快结束。因为真正耗时的是处理大量输入。
• 反之，你问题很短，但让模型生成很长的回复，慢点会偏向 Decode。比如：“帮我写一篇30,000字文章。”这种请求可能很快就开始输出，但完成生成要花很长时间——模型要沿着前面的内容一个 token 一个 token 往后生成。
• 还有一种情况是两边都慢。比如让 Agent 读取大量工具调用结果，再生成一份完整报告。前面的长输入增加 Prefill 压力，后面的长报告拉长 Decode 时间。这就是为什么很多 Agent 任务比普通聊天更慢——上下文更长，步骤更多，最后还要给出更完整的回答。

长上下文让事情慢上加慢

现在很多模型都在强调长上下文，几十万 token、上百万 token 的上下文窗口不再稀奇。但上下文变长，并不代表模型读取这些内容是免费的。

上下文越长，Prefill 阶段要处理的输入就越多，生成的 KV Cache 也越大。KV Cache 本身会占用显存，进入 Decode 阶段后，模型每生成一个新 token，还得不断利用这些缓存。所以长上下文的影响不只发生在输入阶段，还会延续到输出阶段。

因此在工程实践中，通常不会把所有内容一股脑塞进 prompt。无论是 RAG、上下文压缩、记忆筛选，还是工具结果清理，重点都是控制模型每次要读取的内容，减少不必要的输入和缓存负担。

对 Agent 来说，这一点尤其关键。如果每一步都带上完整历史、所有工具返回和全部中间过程，模型信息是多了，但延迟和成本也跟着上涨。更合理的做法是保留必要上下文，把可复用、可缓存、可摘要的内容整理好，让模型少读冗余信息。

只改善“开始速度”的优化

有些优化可以让模型更快开始回答，但对后续输出速度帮助有限。

prompt caching 就是典型例子。如果一段系统提示词、工具说明或固定模板经常重复出现，服务端可以复用之前处理过的前缀，减少 Prefill 阶段的重复计算。这样模型开口前的等待时间会缩短，首个 token 也会更快出现。

但模型进入 Decode 阶段后，仍然需要一个 token 一个 token 往外生成。缓存可以减少“读题”的重复成本，但不能让一篇长回答瞬间生成完。

所以，当你看到某个模型或服务强调“缓存命中后延迟降低”时，要看它主要优化哪个阶段。很多时候，改善的是 TTFT——开始输出前的等待时间。想提高输出阶段的速度，就得靠另一种优化：speculative decoding、批处理调度、KV Cache 管理、模型结构优化、推理引擎优化等等。这些关注的是 Decode 阶段，目标是让模型更高效地生成 token。

一个简单判断方法

判断方法就一点：AI 是迟迟不开口，还是开口之后写得慢。

如果很久没有开始回复，问题多半在 Prefill——模型还在处理输入；如果开始回复很快，但后面生成很慢，问题多半在 Decode——模型还在逐步生成输出。前者对应 TTFT，看的是多久出现第一个 token；后者对应 TPS，看的是开始输出后每秒能生成多少 token。

所以，下次看到 AI 卡住的时候，先看它卡在哪一段：慢在输入，还是慢在输出？拆开来看，原因瞬间清晰。