大模型推理为什么要拆成"两段"：Prefill 和 Decode 讲人话

前几天我把一份几万字的文档贴给 AI，让它总结要点。发送之后盯着屏幕等了七八秒，一个字都没有，我甚至怀疑是不是断网了。结果第一个字一蹦出来，后面就跟开了闸一样，哗哗往外冒，几百字一眨眼写完。

反过来，如果只发一句”你好”，第一个字几乎是秒回的。

为什么第一个字这么贵？而且输入越长越贵，但只影响第一个字——后面的字该多快还是多快。这个体感背后藏着大模型推理的一个基本事实：一次回答，其实是两种完全不同的计算。搞懂了它，也就搞懂了 2026 年推理圈最热的架构话题之一——Prefill/Decode 分离。

一次回答，两种性格

模型生成回答分两个阶段，行业里的名字叫 prefill 和 decode。

Prefill（预填充）：把你的整段输入一次性全部读完、消化掉，然后吐出第一个字。你等的那七八秒，等的就是它。

Decode（解码）：从第二个字开始，一个字一个字往外蹦，每蹦一个新字，都要基于”到目前为止的全部内容”来决定下一个字是什么。

听起来只是”先读后写”，平平无奇。关键在于，这两段计算的性格完全相反。

Prefill 是并行的力气活。你输入的一万个字不是逐个读的，是同时算的——全部输入摊开成一个大矩阵，一波大规模矩阵乘法怼过去。GPU 天生就爱这种活，几万个计算核心全部吃满，瓶颈卡在算力上。输入越长矩阵越大，这一步越久，所以第一个字的等待时间和你贴的文档长度直接挂钩。

Decode 是串行的细活。后面的字为什么快？因为模型在 prefill 阶段读完全文时，把中间计算结果缓存了下来——这份缓存叫 KV cache。之后每生成一个新字，不用重读全文，查缓存就行，算术量其实很小。但便宜不等于轻松：每生成一个字，都得把模型权重和这份越攒越大的缓存从显存里完整搬运一遍，送进计算单元过一趟。算得少、搬得多，瓶颈卡在显存带宽上——这时候 GPU 的算力再猛也使不上劲，大部分计算核心在等数据到货。

我喜欢这么比喻：prefill 像考前通宵把整本书读完、做好一沓笔记；decode 像逐字默写，每写一个字都要把整沓笔记翻一遍——写字本身不累，翻笔记翻得累。

行业给这两段各配了一个体验指标：TTFT（Time To First Token，首字延迟）是 prefill 的成绩单，TPOT（Time Per Output Token，吐字间隔）是 decode 的成绩单。记住这两个词，读任何推理优化的文章都不会迷路。

挤在一张卡上，会互相踩脚

单卡自己玩的时候，两段活排队干就是了，没什么问题。问题出在规模化服务上。

线上的推理服务为了摊薄成本，一张卡要同时伺候几十个请求，混在一个批次里跑。这几十个请求里，有的在 prefill，有的在 decode。冲突就来了：你的请求正在流畅吐字，突然隔壁进来一个贴了十万字文档的新请求——它的 prefill 是个大块头，一进来就把算力抢走了，所有正在吐字的请求集体一顿。你在聊天界面偶尔看到的”打字机突然停顿一两秒又继续”，有一部分就是这么来的。

这不是调度算法不够公平，是两种活的资源需求天然冲突：prefill 想要算力全开猛冲一波，decode 想要细水长流不被打断。挤在一张卡上，要么让 prefill 排队（别人的首字变慢），要么让 decode 被插队（你的吐字卡顿），两头讨不到好。

缓解手段是有的。比如把长 prefill 切成小片，穿插在 decode 中间跑，学名 chunked prefill，主流框架基本都实现了——像把大石头敲碎了再过磅，不至于一整块压垮秤。但切得再碎，也还是在同一张卡上抢资源，治标不治本。

干脆拆开：Prefill/Decode 分离

于是有了更彻底的方案：分离（disaggregation）。一组 GPU 专门跑 prefill，另一组专门跑 decode。请求先到 prefill 集群把输入消化完，然后把 KV cache 整份传给 decode 集群，由后者接手吐字。

拆开之后，事情一下子顺了：

**各自用对硬件。**Prefill 要算力猛的卡，decode 要显存带宽大的卡——而市面上的 GPU 本来就有算力型和带宽型的错位，拆开后可以各买各的，不用再为一张”全能卡”付溢价。

**各自扩缩容。**用户贴长文档多的时段，给 prefill 集群加机器；长对话连续输出多的时段，往 decode 倾斜。两种负载第一次可以独立伸缩。

**体验指标分开保。**首字延迟和吐字流畅不再互相拖累，各自守各自的 SLO。

代价也很实在：KV cache 不小，长输入能攒到 GB 级，要在两个集群之间高速传过去——传输一慢，分离省下的时间全赔进去。所以这套架构的成败在传输层。2026 年的现状是：vLLM、SGLang、NVIDIA Dynamo 这些主流推理框架都已经内置了 PD 分离支持，NVIDIA 开源的传输库 NIXL 基本成了 KV cache 搬运的标准件。国内把这套架构玩出名的是 Kimi 背后的 Mooncake，论文标题里就写着”以 KV cache 为中心的分离式架构”——整个系统围着这份缓存的生产、搬运、复用来设计。

不过别把它当银弹。流量小的时候分离反而亏：KV cache 传输的开销省不掉，两边集群的水位还难对齐，业界实测小负载下性能掉两三成并不罕见。它是为大规模服务准备的架构。个人在一张卡上跑 vLLM 玩模型，老老实实混跑就好，什么都不用改。

做后端的人看这段历史会很眼熟

我第一次把 PD 分离的论文看明白时，反应是：这不就是数据库的读写分离吗。

读和写的资源特征不同——读多写少、读可以扩副本、写要保一致——于是拆开，各自优化、各自扩容。后来的冷热数据分离、计算存储分离，全是同一个思路的变奏：负载特征不同的活，规模一大就会被拆开。单机时代混着干无所谓，因为规模会放大一切错配，而小规模会掩盖它们。

大模型推理这几年的演化，在我看来就是在快进重演分布式系统三十年的历史：从单体（一张卡包办一切），到按负载特征拆分（PD 分离），再往后还有更细的拆法——已经有团队在把注意力计算和 FFN 计算拆到不同的卡上了。技术名词一直在换，但”先合并求简单，规模逼着拆，拆完各自优化”的节奏惊人地一致。

所以每次看到推理架构又出新词，我不太焦虑。掀开引擎盖看一眼，底下的道理，做工程的人多半早就学过一遍了。