预填充和解码差在哪？两阶段的分工

同一次 AI 大模型问答，其实分成前后两个阶段——预填充和解码，它们的分工决定了一句话多久蹦出第一个字、后面又以什么节奏接上。

可以把它想成做一场现场演讲：预填充是把讲稿通读一遍、划好要点；解码是照着要点一句一句往外说。这个类比的失效之处在于，演讲通读一次就够，而对话每多一轮，之前的整段历史都要重新「通读」，越聊越长。带走一个判断：输入的苦吃在预填充，输出的账算在解码。

先给结论：什么场景关心哪个阶段

关心首字速度的，看预填充：资料长、提示词长，第一阶段就慢，用户盯着空白等；关心整体节奏的，看解码：长回答的阅读体验由解码速度决定。做交互产品优先优化前者，做批量生成优先优化后者，两条优化路线各自独立。两个指标怎么量化，见首字时间和吞吐有什么区别？选型不再纠结。

差异一：计算的方式不同

预填充把整段输入一次性喂进去，所有 token 的中间结果可以并行算出来，算得密、耗时集中；解码是逐个 token 往外吐，每生成一个都要参考前面全部内容，只能一步一步来。这就是为什么输入几千字的请求，第一阶段可能占掉大头时间。对调用方的直观启示是：输入瘦身主要救第一字，输出设限主要救总时长，两件事别混为一谈。两阶段各自的消耗怎么记账，见服务端怎么记录 token 用量？账单的来源。

差异二：对速度指标的影响不同

预填充慢，拖的是首字时间——用户等第一句话的时长；解码慢，拖的是每秒出字数——后续阅读的流畅度。流式产品对两者都敏感，分界点见流式和非流式有什么区别？分界点在哪。重复前缀的预填充结果可以缓存复用，命中条件见语义缓存和精确缓存有什么区别？。

两阶段怎么协作完成一次回答

一次完整回答是接力：请求到达，先进入预填充，把系统提示词、历史对话和资料一起处理成中间状态；随后切到解码，逐 token 生成正文；解码产生的每个新 token 又并入上下文，供下一个 token 参考。讯飞星火、通义千问的响应速度说明里虽不细拆两阶段，但优化思路都围绕这条接力线展开。两段的边界并不总是泾渭分明，一些服务会把长输入的预填充拆成多段流水执行，边处理边放行，这也是「长资料也能快速开讲」的技术来源，体感快不等于跳过了处理。

预填充内部还有个值得了解的优化方向：前缀复用。多轮对话中系统提示词和历史对话是稳定的，这部分中间状态可以缓存，下一轮只对新增内容做预填充。复用是否生效，从首字时间就能看出来——同样的对话继续追问，第二轮明显快于第一轮，多半是命中了。这也是把易变变量放在提示词末尾的原因：前缀越稳，可复用的部分越长，预填充越省，这笔账在长对话里尤其明显。

两阶段对照表：

• 预填充：整段并行算，决定首字快慢
• 解码：逐字串行出，决定节奏顺不顺
• 长输入优化前者，长输出优化后者

分清两段，卡顿出在哪一清二楚。

聊聊预填充和解码的常见疑问

• 多轮对话会重复预填充吗？：理想情况不会，命中缓存的历史部分直接复用，未命中才重算。
• 两阶段用同一块显卡吗？：通常在同一实例上先后执行，大规模部署也可能分开部署、分别扩容。
• 缩短提示词能加快解码吗？：基本不能，它主要省预填充时间，解码节奏取决于输出长度和模型本身。

把一次回答拆成两段看，很多「为什么慢」的疑问就有着落了。