当前位置：首页 > news >正文

LLM Serving 进入下半场：Prefill/Decode 解耦架构、KV 迁移与 PD 调度工程实践

news 2026/6/30 3:11:01

很多人做大模型推理优化，第一反应是量化、连续批处理、KV Cache、FlashAttention 或 Tensor Parallel。但线上服务真正跑到高并发、长上下文、多模型混部之后，团队很快会遇到另一个问题：为什么同一批 GPU，Prefill 一上来，Decode 延迟就开始抖；为什么 TTFT 提升了，TPOT 和 P99 却变差；为什么压测 QPS 看起来很好，真实用户体验反而更差。
这些问题的背后，往往不是单个算子不够快，而是Prefill 和 Decode 两种负载被混在同一套资源池里，彼此争抢显存带宽、算力时间片和调度机会。于是，越来越多推理系统开始走向一个更“系统”的方向：Prefill/Decode 解耦（P/D Disaggregation）。
本文不从论文八股出发，而是从工程视角系统拆解：为什么 P/D 混部会互相伤害，Prefill GPU 池和 Decode GPU 池应该怎么分，KV Cache 跨池迁移到底贵不贵，什么叫 Goodput，为什么它比裸 QPS 更重要，以及 vLLM、SGLang、TensorRT-LLM 语境下应该如何理解这类架构。读完之后，你应该能把 P/D 解耦讲清楚，也能把它和实际线上瓶颈、性能分析、调度设计、面试回答串起来。

为什么说 LLM Serving 的瓶颈正在从“单点优化”走向“系统调度”
先把问题看清：Prefill 和 Decode 根本不是一类负载
P/D 混部为什么会互相伤害
什么是 Prefill/Decode 解耦架构
为什么越来越多系统开始考虑 P/D 解耦
P/D 解耦到底在优化什么
最关键的代价：KV Cache 迁移
P 池和 D 池怎么配比：不要靠拍脑袋
Goodput 为什么比 QPS 更重要
调度器怎么设计才像工程系统而不是 Demo
P/D 解耦与 Continuous Batching、KV Cache、TP 的关系
vLLM、SGLang、TensorRT-LLM 语境下怎么理解 P/D 架构
什么时候适合上 P/D 解耦，什么时候不适合
性能分析怎么做：别只盯着 tokens/s
工程落地最容易踩的坑
面试里如何把 P/D 解耦讲得像真正做过系统
学习路线与实践建议
总结

1. 为什么说 LLM Serving 的瓶颈正在从“单点优化”走向“系统调度”

早期很多团队做大模型推理，业务规模还不大，核心目标通常只有两个：

模型先跑起来
单卡性能尽量压高

这时候关注的重点很自然会落在：

模型权重量化
Attention Kernel 优化
Continuous Batching
KV Cache 管理
Tensor Parallel 切分

这些都很重要，但它们大多属于“局部优化”。也就是说，你是在优化某个算子、某种缓存、某个执行路径，或者单个实例的吞吐。

一旦系统进入真实线上阶段，问题会开始变化：

短请求和长请求混在一起
新请求不断进入，同时老请求还在持续 decode
一部分用户只要首 token 快，另一部分用户更在意整体生成速度
业务高峰时 admission control 开始触发
GPU 利用率看起来不低，但用户感知延迟越来越差

这时你会发现：系统瓶颈不再只是某个 kernel 不够快，而是不同类型的请求和不同阶段的负载在错误地共享资源。

P/D 解耦，就是在这个阶段开始变得有价值。

2. 先把问题看清：Prefill 和 Decode 根本不是一类负载

讨论 P/D 解耦之前，最重要的是先承认一个事实：

Prefill 和 Decode 虽然都属于推理，但它们的计算特性完全不同。

2.1 Prefill 是什么

Prefill 指的是把用户输入的 prompt 整段送进模型，完成上下文编码并建立初始 KV Cache 的阶段。

它的典型特征是：

一次要处理很多 token
张量形状更大，GEMM 更饱满
并行性更强
更容易吃满算力
往往更偏 compute-bound

通俗一点说，Prefill 像是“整批大活一起干”，适合把 GPU 算力榨满。

2.2 Decode 是什么

Decode 指的是模型进入自回归生成后，一步一步生成 token 的阶段。

它的典型特征是：

每一步只生成很少的新 token
但要反复读取历史 KV Cache
单步计算小、步数多
对调度抖动非常敏感
往往更偏 memory-bound

通俗一点说，Decode 像是“高频小单持续到来”，重点不在单次算得多快，而在于每一步都别被打断。

2.3 一个最关键的工程结论

Prefill 和 Decode 的矛盾，不是“谁更重要”，而是：

Prefill 喜欢大块时间片、喜欢大 batch、喜欢充分占用算力
Decode 喜欢稳定、低抖动、持续拿到执行机会

前者追求把机器跑满，后者追求别被插队。

这就天然埋下了冲突。

3. P/D 混部为什么会互相伤害

很多系统一开始采用的是混部思路：同一组 GPU 既做 prefill，也做 decode。这样实现最简单，也最符合“资源共享最大化”的直觉。

问题在于，这种直觉在线上常常失效。

3.1 Prefill 会打断 Decode 的稳定节奏

Decode 的体验高度依赖于两个东西：

每一步生成的延迟是否稳定
长尾是否可控

如果系统突然插入一个较大的 prefill batch，就可能出现：

当前 decode batch 被延后
TPOT 抬升
P95/P99 明显变差

对用户来说，这会体现为：

首 token 出得还行
但后续输出一顿一顿的
长回答尤其明显

3.2 Decode 也会拖住 Prefill

反过来，Decode 虽然单步计算不大，但它是持续存在的，而且往往带着活跃 KV Cache、调度状态和流式输出责任。

如果系统为了保住 decode 的延迟而频繁给它让路，Prefill 也会出现：

队列等待变长
TTFT 上升
大 prompt 的进入变慢

于是你会看到一种典型现象：

系统并不是绝对跑不动
而是任何一侧一忙起来，另一侧就开始恶化

3.3 混部的本质问题

P/D 混部最大的问题不是“实现不优雅”，而是：

两种资源诉求完全不同的负载，被迫在同一套 GPU 上竞争。

竞争的对象包括：

计算时间片
HBM 带宽
KV Cache 容量
调度优先级
动态 batch 空间

这就像把大货车和高频快递电动车放进同一条单车道，理论上大家都能走，实际上一旦流量上来，整个系统就会抖。

4. 什么是 Prefill/Decode 解耦架构

P/D 解耦的核心思想其实不复杂：

既然 Prefill 和 Decode 的资源诉求不同，那就不要让它们在同一池 GPU 上硬挤。

于是系统被拆成两类资源池：

Prefill Pool：专门负责处理新请求的 prompt 编码和初始 KV 构建
Decode Pool：专门负责接手已进入生成阶段的请求，持续执行 token-by-token decode

一个请求的大致生命周期会变成：

请求进入系统
调度器把它送到 Prefill Pool
Prefill 节点完成 prompt 计算，产出初始 KV Cache
KV Cache 或相关状态被迁移/转交到 Decode Pool
Decode 节点继续负责后续生成

这就是“解耦”。

4.1 它不是简单的服务拆分

很多人第一次听到会觉得：这不就是把一个服务拆成两个服务吗？

不完全是。

真正难的地方不是接口拆开，而是：

两个池子的资源比怎么定
请求何时切换阶段
KV 怎么传
传输时延是否吃掉收益
两边负载波动时如何联动调度

所以 P/D 解耦本质上是一种系统资源编排与调度架构，不是普通的微服务拆分。

5. 为什么越来越多系统开始考虑 P/D 解耦

原因很现实：随着模型更大、上下文更长、在线并发更高，P/D 互扰越来越难靠小修小补解决。

5.1 长上下文让 Prefill 更重

上下文从 2k、4k 增长到 32k、64k 之后，Prefill 的一次性计算量会明显抬升。

这意味着：

单次 prefill 更容易形成“大活”
对 decode 的打断更严重
混部场景下抖动更大

5.2 流式输出让 Decode 更敏感

流式体验的核心不是平均值，而是稳定性。

如果 TPOT 的均值不错，但 P99 经常抖，用户依然会觉得“卡”。

而 Decode 恰恰是最怕被打断的阶段。

5.3 多业务、多模型混布让调度更复杂

线上不只有一种请求：

短问答
长摘要
多轮对话
工具调用
RAG 拼接长 prompt

这些请求的 prefill/decode 比例差异很大。如果还强行混在同一个资源池里，调度复杂度会急剧上升。

5.4 Goodput 比 Raw Throughput 更重要

线上团队真正要保的是：

SLO 之内的 TTFT
SLO 之内的 TPOT
稳定的长尾延迟

这时就不能只问“机器一秒能吐多少 token”，而要问：

“在满足服务质量约束的前提下，系统到底能稳定服务多少请求？”

P/D 解耦，就是朝这个方向走的一步。

6. P/D 解耦到底在优化什么

很多人会误以为 P/D 解耦的目标是“提升绝对吞吐”。这不够准确。

它真正优化的是下面几件事。

6.1 降低阶段互扰

这是最直接的收益。

把 prefill 和 decode 分开后：

大 prompt 不会直接打断 decode 节奏
decode 的 TPOT 更稳定
长尾更容易收敛

6.2 让不同 GPU 池各自做擅长的事

Prefill Pool 可以倾向于：

大 batch
更高算力利用
更激进的请求聚合

Decode Pool 可以倾向于：

更稳定的调度节奏
更细粒度的步进控制
更保守的 admission 策略

这比一套统一策略硬覆盖两类负载更合理。

6.3 提高 SLO 内有效吞吐

解耦后，系统未必在裸 QPS 上永远大幅领先，但在满足 SLO 的前提下，通常更容易保住：

TTFT 不爆
TPOT 不抖
P99 不飙

这才是真正有业务价值的吞吐。

6.4 让调优目标更清晰

混部系统里你经常搞不清：

是 prefill 太重拖慢 decode
还是 decode backlog 反过来堵住了新请求

解耦后，问题边界会更清楚：

Prefill 池看 TTFT、prefill queue、prefill batch utilization
Decode 池看 TPOT、decode backlog、active sequence 数

系统更容易分析，也更容易扩容。

7. 最关键的代价：KV Cache 迁移

如果说 P/D 解耦最大的收益是“减少互扰”，那最大的代价就是：

Prefill 做完之后，如何把请求上下文安全、快速地交给 Decode 节点。

这通常意味着 KV Cache 迁移，或者等价的状态转移。

7.1 为什么 KV 迁移这么关键

因为 Prefill 的价值，本质就是为后续 Decode 准备历史上下文。

如果 Prefill 完成后 Decode 拿不到这些上下文，就只能：

重新算一遍 prompt
或者根本无法继续生成

这显然不成立。

所以 P/D 解耦不是算完就结束，而是必须解决“算完以后怎么交棒”。

7.2 KV 迁移的主要成本

KV 迁移的成本主要体现在：

额外网络传输
节点间状态同步
迁移过程中的排队与等待
可能的内存拷贝开销

如果 prompt 很长，初始 KV 很大，迁移成本就会明显上升。

7.3 一个核心权衡

P/D 解耦是否值得，常常取决于下面这个判断：

“P/D 混部造成的长期互扰损失，是否大于一次 KV 迁移引入的额外成本？”

如果答案是是，那么解耦值得考虑。

7.4 什么场景下迁移成本更容易接受

以下场景更容易从 P/D 解耦里获益：

prompt 较长，prefill 本身足够重
decode 生命周期长，后续收益能摊薄一次迁移开销
集群内有较高带宽互联
系统对 TPOT 稳定性要求高

反过来，如果请求极短、生成极短、上下文也不长，那么多引入一次迁移未必划算。

8. P 池和 D 池怎么配比：不要靠拍脑袋

P/D 解耦落地后，工程上第一个大问题就是：Prefill Pool 和 Decode Pool 各放多少 GPU？

这是很多团队最容易拍脑袋的地方。

8.1 先明确两个池子的负载来源

Prefill Pool 的压力主要来自：

新请求到达率
平均 prompt 长度
长 prompt 比例

Decode Pool 的压力主要来自：

活跃会话数
平均输出长度
持续生成时长
TPOT 目标

这两边本来就不一定同比例增长。

8.2 一个直观判断框架

可以先用下面的思路做一版粗估：

P 池容量 ~ 新请求速率 × 平均 prefill 成本 D 池容量 ~ 活跃会话数 × 平均 decode 成本

这里的“成本”不能只看 FLOPs，还要看：

单阶段平均耗时
显存占用
队列等待
SLO 约束

8.3 业务变化会直接改变最优配比

例如：

RAG 场景 prompt 很长，P 池要更厚
聊天场景生成很长，D 池要更厚
夜间批量摘要任务可能 P 池压力更大
客服对话场景常常 D 池更敏感

所以 P:D 配比不是固定常数，而是业务相关参数。

8.4 更像工程师的做法

真正靠谱的方式不是猜，而是：

统计真实请求分布：prompt 长度、输出长度、并发模式
分别测 prefill 单阶段成本和 decode 单步成本
结合目标 SLO 做容量测算
在压测中观察哪一池先形成 backlog
动态调参或弹性扩缩

也就是说，P/D 解耦不是“拆完就赢”，而是把资源配置问题显式化了。

9. Goodput 为什么比 QPS 更重要

这是理解 P/D 解耦价值的关键概念之一。

9.1 裸 QPS 的误导性

很多压测报告喜欢展示：

QPS
总 tokens/s
GPU 利用率

这些指标当然有用，但它们无法直接回答一个业务问题：

这些请求里，有多少是在用户可接受延迟内完成的？

如果系统虽然吞吐很高，但：

TTFT 超标
TPOT 长尾超标
请求频繁超时

那这些吞吐并不真正有价值。

9.2 Goodput 的直觉

Goodput 可以简单理解为：

满足既定 SLO 约束的有效吞吐。

比如：

TTFT 必须小于某阈值
TPOT P95 必须小于某阈值
成功完成率必须足够高

只有满足这些条件的请求，才算“有效服务”。

9.3 P/D 解耦为什么天然更适合做 Goodput 优化

因为它把两类矛盾负载拆开后，更容易分别守住：

Prefill 的首 token 时延
Decode 的生成稳定性

这意味着系统虽然可能增加了一次迁移，但却更容易把“有效请求数”做上去。

从工程角度看，这往往比只追裸吞吐更值钱。

10. 调度器怎么设计才像工程系统而不是 Demo

P/D 解耦的成败，很大程度上不在模型，而在调度器。

10.1 调度器至少要回答的四个问题

新请求先进哪个 Prefill 节点
Prefill 完成后转发到哪个 Decode 节点
当前 Decode 池是否还接得住新的活跃会话
哪一侧出现拥塞时，系统如何退化而不是雪崩

10.2 只看最空闲节点是不够的

很多人会下意识做一个“最少负载优先”。

这在线上往往太粗糙，因为真实负载不是一个数字能概括的。你至少还要看：

当前队列长度
预计 KV 占用
活跃序列数
当前 batch 结构
TP group 可用性
节点间网络距离

所以调度器更像是一个多目标优化器，而不是简单的 round-robin。

10.3 Decode 池调度尤其要避免“假空闲”

有些节点当前看起来 QPS 不高，但已经挂着很多长会话和大量 KV Cache。

如果继续把新请求导进去，结果通常是：

admission 没有立刻失败
但后续 TPOT 和 P99 快速恶化

所以 Decode 池的容量评估，不能只看当前 token 速率，还要看“未来一段时间的持续压力”。

10.4 需要退化策略

成熟系统不能只有理想路径，还要有退化策略，例如：

Decode 池拥塞时限制长 prompt 进入
Prefill 池排队过长时做 admission control
部分请求回落到混部池
对不同优先级业务做差异化限流

这部分能力，比单纯把架构图画漂亮更重要。

11. P/D 解耦与 Continuous Batching、KV Cache、TP 的关系

P/D 解耦不是替代这些技术，而是和它们形成新的组合关系。

11.1 和 Continuous Batching 的关系

Continuous Batching 解决的是：

请求到达时间不一致时，如何动态拼 batch
如何减少 GPU 空转

P/D 解耦解决的是：

prefill 和 decode 是否应该共享同一执行池

前者更偏执行策略，后者更偏资源架构。

两者不是二选一，反而常常一起出现。

11.2 和 KV Cache 的关系

KV Cache 是 Decode 阶段的核心状态资产。

P/D 解耦后，KV 管理问题变得更复杂，因为你不仅要考虑：

分配
复用
回收

还要考虑：

节点间迁移
迁移后的布局一致性
P 池和 D 池对 KV 生命周期的协同

所以 P/D 解耦不是弱化 KV 问题，而是把 KV 问题升级成了“跨池状态管理”问题。

11.3 和 Tensor Parallel 的关系

如果模型本身需要 TP，那么 P 池和 D 池内部也可能各自有 TP group。

这会带来更多现实约束：

Prefill TP group 和 Decode TP group 是否同规模
KV 迁移是单卡到单卡，还是 group 到 group
不同池子的拓扑是否一致
跨机 TP 下解耦是否更贵

所以 P/D 解耦一旦叠加 TP，调度复杂度会明显增加。

12. vLLM、SGLang、TensorRT-LLM 语境下怎么理解 P/D 架构

很多人容易把“某框架支持某特性”理解成“系统问题已经被自动解决”。这要谨慎。

12.1 vLLM 语境

vLLM 强项在于：

PagedAttention
高效 KV 管理
Continuous Batching
较成熟的 serving 执行模型

在这个语境下理解 P/D 解耦时，要重点思考的是：

当前实例更偏混部还是可拆池
KV block 管理和跨节点迁移如何结合
调度器如何感知活跃序列与 block 使用率

12.2 SGLang 语境

SGLang 讨论更多的是：

请求执行图
前缀复用
调度表达能力
推理服务编排

在这个语境下，P/D 解耦更容易与：

Prefix Cache
复杂请求编排
多阶段执行控制

联系起来理解。

12.3 TensorRT-LLM 语境

TensorRT-LLM 更强调：

图优化
kernel 性能
高效 runtime
生产级推理路径

在这个语境下讨论 P/D 解耦，重点就会转向：

两个池子内部的单实例性能是否足够好
跨池切换是否抵消了 engine 优化收益
不同 engine 配置是否分别适配 prefill 和 decode

12.4 一个统一视角

无论是哪种框架，P/D 解耦都不是一个“自动开关”。

它始终对应同一个系统问题：

是否要把两类不同负载拆到不同资源池，并为此承担额外状态迁移和调度复杂度。

框架只决定你更容易怎么实现，不决定这个问题本身是否存在。

13. 什么时候适合上 P/D 解耦，什么时候不适合

这件事很容易被讲成“先进架构”，但工程上不能迷信它。

13.1 更适合的场景

长上下文请求较多
流式输出体验很重要
并发高，P99 压力明显
Prefill 和 Decode 干扰已经在压测中可见
集群网络较好，能承受 KV 迁移
系统已经有较成熟的调度和监控体系

13.2 不一定适合的场景

请求很短，prompt 和输出都不长
业务规模小，混部还远未到瓶颈
集群网络一般，跨池迁移代价大
团队没有足够的调度与观测能力
当前单实例瓶颈还没有解决

13.3 一个务实结论

如果你现在连：

TTFT 和 TPOT 的分阶段指标
KV 占用
batch 结构
decode backlog

都还没有监控清楚，那大概率还没到“先上 P/D 解耦”的时候。

先把系统看清，再决定要不要拆。

14. 性能分析怎么做：别只盯着 tokens/s

做 P/D 解耦评估，最忌讳的是只看一个总吞吐数字。

14.1 至少要分阶段看

你至少要拆开看：

Prefill latency
TTFT
TPOT
Decode P95/P99
请求完成率
Goodput
KV 迁移耗时
Prefill/Decode 两池 backlog

14.2 要看阶段互扰是否真的下降

不是说拆成两个池子就算成功，而是要验证：

大 prompt 到来时，decode TPOT 是否更稳定
decode 池的长尾是否明显改善
prefill 池是否因为排队而把 TTFT 抬太高

14.3 要做真实负载而不是玩具负载

很多压测脚本的问题在于：

prompt 长度固定
输出长度固定
请求间隔均匀

这种负载很难看出 P/D 解耦的真实价值。

更好的做法是模拟：

长短 prompt 混合
长短输出混合
峰值突发
流式会话持续驻留

因为真实线上就是这样。

14.4 还要看迁移成本是否吞掉收益

如果你发现：

decode 的抖动确实下降了
但 TTFT 因为迁移和排队上升太多

那么架构不一定真正更优。

这也是为什么 P/D 解耦必须用端到端指标来评估，而不是只看局部性能。

15. 工程落地最容易踩的坑

15.1 误把“拆服务”当成“做解耦”

只把 API 分成两个服务，不等于系统真的解耦了。

如果：

还是共用同一组 GPU
还是共用同一套队列
还是没有独立容量控制

那只是代码拆分，不是资源解耦。

15.2 没有算清 KV 迁移成本

很多方案 PPT 上很好看，问题都出在这一步：

prompt 长时 KV 太大
网络没那么快
迁移过程引入额外等待

最后收益被吞掉。

15.3 没有给两池做独立监控

如果上线后你仍然只看一个总体 QPS 和一个总体延迟，那定位会非常痛苦。

P 池和 D 池必须至少分开观测：

队列长度
活跃请求
GPU 利用率
显存占用
迁移耗时
admission reject

15.4 资源配比静态写死

业务分布会变，白天夜间会变，长短请求比例会变。

如果你把 P:D 比例固定死，很可能在某些时段效果好，某些时段反而更差。

15.5 忽略异常路径

例如：

Prefill 成功但迁移失败怎么办
Decode 池节点故障怎么办
请求中途取消如何回收状态
P 池热点和 D 池热点如何迁移

这些异常路径决定它是不是一个生产系统。

16. 面试里如何把 P/D 解耦讲得像真正做过系统

很多候选人一说这个主题，就容易停在概念层：

Prefill 是算 prompt
Decode 是生成 token
两者分开更高效

这远远不够。

更像做过系统的表达方式应该是：

16.1 先讲问题，不先讲方案

可以先说：

“线上混部时，Prefill 更偏 compute-heavy，Decode 更偏 memory-bound 和 latency-sensitive。大 prompt 或批量 prefill 进入后，容易打断 decode 节奏，导致 TPOT 和 P99 恶化。所以我们会考虑把两个阶段拆到不同 GPU 池，减少互扰。”

这样一开口就体现你理解的是系统矛盾，而不是名词解释。