小白程序员轻松入门大模型核心机制：预填与解码分离（CSDN版）

Python官方资料

226人浏览 · 2026-10-09 10:00:00

Python官方资料 · 2026-10-09 10:00:00 发布

本文深入浅出地解释了大模型处理请求的两大核心阶段：预填（一次性读入并理解输入）和解码（逐字生成输出）。通过餐厅备菜与上菜的比喻，阐述了为何将两者分离（PD分离）能显著提升效率，特别是在处理超长输入时。文章详细介绍了分离后如何通过KV Cache的传输（拉取或推送）在不同节点间衔接，并以昇腾平台为例展示了具体实现。对于希望了解大模型内部运作及优化技巧的读者，本文提供了清晰的图解和关键术语解释。

开篇：一条请求，在大模型内部走了两段路

想象你正用 AI 助手写一份年终总结。你敲下一长串问题，按下回车……几秒钟后，答案一个字一个字地蹦出来。

你有没有想过：从「按下回车」到「第一个字出现」，再到「最后一个字出现」，这中间发生了什么？

用一句话概括：模型先"读"完你的整个问题，再"一个字一个字"把回答写出来。这两段，就是今天的主角——预填（Prefill）和解码（Decode）。

图 1 一条请求 = 预填（读题）+ 解码（作答）

你可能已经听过一个词——PD 分离（Prefill-Decode Disaggregation，预填/解码分离）。简单说，就是把预填和解码这两段路，交给不同的机器去干。它为什么会成为大模型推理的重要优化方向？这篇文章从头讲起。

第一节先补个基础：大模型是怎么「说话」的

大模型并不认识"汉字"或"英文单词"，它只认识一种最小单位——Token（词元）。你可以把它粗略理解为"半个词 / 半个字"，比如一句话会被切成一长串 Token。

模型的"思考"过程，分成两步：

预填（Prefill）：把你的整段输入一次性"读"进去，内部消化、建立上下文。特点是"一次干一大票"。
解码（Decode）：从上下文里一个字一个字"吐"答案，每次只吐一个 Token，吐完再看下一步，直到说完。

图 2 文本 → Token → 模型

第二节打个比方：这就像餐厅里的「备菜」和「上菜」

先抛开技术，用一个接地气的比喻。

假设你开了一家餐厅，后厨有两类活：

备菜（预填）：客人点了一大桌菜，后厨先把所有原材料准备好——洗菜、切菜、焯水、备料。这活儿一次处理一大堆。
上菜（解码）：菜备好了，接下来是一道一道往外端。而且每端一道，都要顾着前面已经上的菜（顺序、口味要呼应）。

问题来了：如果备菜和上菜共用同一批厨师、同一口灶台，会发生什么？

当一桌客人疯狂备菜（一个超长问题的预填），其他桌的"上菜"全被卡住——上一道菜要等半天。
反过来，大家都在"上菜"（一个个吐字）时，灶台又闲下来，没人备新菜，利用率很低。

图 3 备菜（批量）vs 上菜（串行）

你可能会想：那多雇厨师、多开灶台不就行了？——问题是，备菜和上菜需要的"灶台"还不一样。这就引出下一个核心概念。

第三节两种活，其实「性格」完全不同

回到技术本身。预填和解码，是两种计算特征完全相反的活：


维度	预填（Prefill）	解码（Decode）
一次处理多少	一次性处理整个输入（几百~几千 Token）	一次只处理 1 个 Token
计算量	大，算力饥渴	小，但极度依赖读内存
对内存带宽的需求	高	极高（被"内存带宽"卡脖子）
对"上文的记忆"的依赖	中	极强（每步都要"回忆"全部上文）
一句话概括	像"一口气读完全书"	像"每写一个字都翻一遍前面的笔记"

关键就在最后两行：解码每吐一个字，都要把"上文的记忆"重新读一遍。这些"记忆"存放在一个叫 KV Cache（键值缓存）的地方——你可以把它理解为模型给自己留的"便签/小抄"，记录"到目前为止，我读到了哪儿、想到了什么"。

图 4 预填是"算力大户"，解码是"访存大户"

先让 KV Cache 混个脸熟：它是 PD 分离里最关键的"交接物"，第七节会专门讲它怎么在机器之间"搬家"。

第四节混在一起，为什么效率上不去？

如果一台机器（或一个卡组）既做预填又做解码，会遇到两个绕不开的问题。

问题一：相互拖累，谁也做不好。
预填是"大批量、重计算"的活，解码是"单 Token、重访存"的活。两者混在同一批卡上，算力在"大规模计算"和"单点读取"之间反复横跳，调度开销大，两个活都做不快。

问题二：排队抖动，体验忽快忽慢。
推理服务里，请求是排队处理的。当一个超长输入的预填请求插进来，会占走大量算力，把后面所有正在"吐字"的请求都卡住。用户感知就是：刚才还秒回，突然一个字等好几秒——TTFT 和 TPOT 都被打乱。

两个缩写的通俗版解释（后面会反复用到）：

TTFT（Time To First Token，首字时延）：按下回车后，第一个字多久出现。用户对"卡不卡"的第一印象，主要看它。
TPOT（Time Per Output Token，每字时延）：后续每个字平均隔多久出现。它决定"读答案"的流畅度。
模型推理优化的两大核心目标，就是同时压低这两个数字。

图 5 TTFT：第一个字等多久；TPOT：每个字隔多久

为什么这事现在才被当成大问题？因为模型越来越大、上下文越来越长。当输入从几百字涨到几千甚至几万字，预填的时间占比急剧上升，"混在一起"的副作用被放大；同时业务既要首字快（TTFT 低）、又要吐字稳（TPOT 稳），这俩指标在混合模式里是打架的，很难同时做好。

第五节 PD 分离：给两段路各配一支队伍

既然预填和解码"性格不合"，最直接的办法就是——拆开，各干各的。

这就是 PD 分离（Prefill-Decode Disaggregation，预填/解码分离）：

一部分机器专门当 P 节点（Prefiller，预填工位）：负责"读题"，一口气算完预填，产出 KV Cache。
另一部分机器专门当 D 节点（Decoder，解码工位）：负责"作答"，拿到 KV Cache 后一个字一个字地吐。
中间放一个 Proxy（负载均衡代理）：它像"前台大堂经理"，收到外部请求后，决定这个请求先去 P 节点还是 D 节点、去哪个节点。

图 6 一个 Proxy + 一组 P 节点 + 一组 D 节点

拆开之后赚到了什么？可以概括为三点：

TTFT 和 TPOT 终于可以"各管各的"：想让首字快，就给 P 节点加卡、调并行策略；想让吐字稳，就给 D 节点配更合适的内存带宽和批次。两个指标不再互相牵制，调优从"跷跷板"变成了"两个独立旋钮"。
硬件利用率大幅提升：预填"算力饥渴"、解码"带宽饥渴"，混在一起怎么配都差一截；拆开后每台机器只干自己最擅长的活，同样的卡能服务更多请求——这是实打实的成本账。
调度更简单、行为更可控：混合模式下预填插入解码队列会造成抖动，还要为"一次切多少块"这类参数反复调优；分离后每个节点行为模式单一，延迟可预测，也更容易弹性扩缩容。

图 7 混在一起 vs 拆开之后

当然，天下没有免费的午餐。PD 分离最大的代价就是——KV Cache 得"搬家"。这个"搬家"做得好不好，直接决定 PD 分离的成败。

第六节关键问题：KV Cache 怎么「搬家」

KV Cache 到底是什么？

模型读完整段输入后，会把"读过的内容"提炼成一张张"便签"（Key / Value 两组数据）存下来。解码时每吐一个字，都要翻一遍这些便签，才能保证"记得前面说过什么"。

为什么不能重新算一遍？如果每次解码都重新读一遍完整输入，成本会随输入长度平方级增长，慢到没法用。用 KV Cache 换速度是行业通用做法。而 KV Cache 会随输入长度线性增长，超长上下文下能占掉相当大比例的显存——所以"搬"它很贵。

图 8 便签（KV Cache）为什么能省时间

两种「搬家」方案：拉（pull）还是推（push）？

业界两种主流路线，本质区别是"谁主动"。

方案 A：D 节点「拉」（pull）

流程：请求先到 P 节点完成预填、产出 KV Cache；D 节点开始解码前，主动向 P 节点发起传输，把 KV Cache 拉到自己这边，再继续吐字。
特点：D 节点"按需取货"，什么时候要、要多少，D 说了算；P 节点只负责"供货"。实现相对简单。

方案 B：P 节点「推」（push）

流程：P 节点边算边把 KV Cache 主动逐层推给 D 节点，推完通知 D 可以开始解码。
特点：P 节点"送货上门"，可以边算边推（流水线化），减少 D 节点的等待时间，对 TPOT 更友好；但对网络和两侧协调要求更高。


维度	拉（pull）	推（push）
谁主动	D 节点	P 节点
何时传输	D 开始解码前一次性拉	P 边算边推（可流水线）
D 节点等待	相对更长	更短
实现复杂度	较低	较高（需分层协调）

图 9 D 主动来取（pull）vs P 主动送货（push）

谁来决定"去哪个节点"：Proxy 的前台职责

选节点：Proxy 拿到请求后，按轮询/负载方式选一个 P 节点（select_prefiller）和一个 D 节点（select_decoder），把请求转过去。
打标签：Proxy 转发时会带上"身份标签"（如 kv_role：本机是"生产者 kv_producer"还是"消费者 kv_consumer"），节点据此知道自己该预填还是该解码、KV 往哪送。
跨领域小知识：这里的"选节点"很像外卖平台的派单——派单策略直接影响整体吞吐和单请求延迟，是调度优化的核心战场。

图 10 先派给 P 完成预填，再派给 D 继续解码

第七节昇腾上是怎么落地的

在昇腾（Ascend）侧，PD 分离通过连接器（Connector）实现，负责 KV 缓存跨节点传输。核心角色有三类：

连接器本体（如 MooncakeConnector）：负责 KV 传输的核心逻辑，分为"拉取型"和"分层推送型"两种，对应上节的 pull / push。
调度器侧接口：管理"需要传输 / 传输完成"的请求状态。
Worker 侧接口：管理 KV 缓存的注册与传输。

请求是怎么流转的？以"拉取型"为例：请求先到 P 节点完成预填 → P 节点暂缓释放 KV → Proxy 把请求转给 D 节点 → D 节点把请求标记为"等待远端 KV"、先占好位、预分配 KV 空间 → D 节点把 KV 拉过来 → P 节点释放 KV → D 节点开始解码并返回结果。整个过程底层走 P2P（点对点）通信。

图 11 一条请求的完整流转（拉取型）

小科普（给非推理背景读者）：TP = Tensor Parallelism（张量并行），把一张卡算的活拆给多张卡一起算，是"并行"的一种方式；MLA = Multi-head Latent Attention（多头潜在注意力）、GQA = Grouped Query Attention（分组查询注意力），是两种主流模型常见的注意力实现，这里只需知道它们是当前主流的省显存方案即可。

术语小抄

Token（词元）：模型处理文本的最小单位，约等于"半个词 / 半个字"。
预填（Prefill）：一次性读完整段输入的阶段，重计算。
解码（Decode）：一个字一个字生成答案的阶段，重访存。
KV Cache（键值缓存）：模型记下的"上文便签"，解码时反复读它。
TTFT（首字时延）：第一个字多久出现。
TPOT（每字时延）：后续每个字隔多久出现。
P 节点 / D 节点：专门负责预填 / 专门负责解码的机器。
Proxy（代理）：转发请求、选择节点的"前台"。
超节点（SuperPoD）：昇腾侧对"一个卡组 / 资源池"的称呼，是 PD 分离部署时"一个节点"的基本单位。注意：是 SuperPoD，不是 SuperNode

结尾：一次回答，两段旅程

回到开头的场景：你按下回车，答案一字一句地出现。这背后，是预填在"读题"、解码在"作答"。

把这两段旅程交给不同的机器，就是 PD 分离。它用"KV Cache 搬家"的代价，换来了 TTFT 和 TPOT 各管各的、硬件利用率更高、行为更可控。从餐厅比喻到拉/推方案，从昇腾落地到术语小抄，希望这篇文章让你对 PD 分离有了一个完整的认识。

如果还想深入，可以继续探索：更大规模下的负载均衡策略、PD 分离与 MoE（Mixture of Experts，混合专家）/ MLA 的组合、以及端到端的成本优化。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】