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

很多人做大模型推理优化，第一反应是量化、连续批处理、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 解耦讲清楚，也能把它和实际线上瓶颈、性能分析、调度设计、面试回答串起来。

目录

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

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

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

1. 请求进入系统
2. 调度器把它送到 Prefill Pool
3. Prefill 节点完成 prompt 计算，产出初始 KV Cache
4. KV Cache 或相关状态被迁移/转交到 Decode Pool
5. 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 更像工程师的做法

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

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

也就是说，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 调度器至少要回答的四个问题

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

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 池，减少互扰。”

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

16.2 再讲收益，但别讲成银弹

可以继续说：

“解耦的直接收益通常不是绝对 tokens/s 最大化，而是提高 SLO 内的有效吞吐，也就是 Goodput。Decode 更稳定，长尾更可控，但代价是要承担 KV 迁移和更复杂的调度。”

这比只说“性能更好”强得多。

16.3 最后讲代价和边界

例如：

• 请求太短时收益未必覆盖迁移成本
• 网络拓扑差时很容易被传输拖死
• 如果当前系统连阶段指标都没打清楚，贸然做解耦风险很高

这类边界表达，最能拉开和“只背过概念”的差距。

17. 学习路线与实践建议

如果你想把这个主题真正学扎实，可以按下面的顺序推进。

17.1 先补清推理基础

先彻底理解：

• Prefill / Decode 区别
• KV Cache 生命周期
• Continuous Batching
• TTFT / TPOT / Throughput / P99

17.2 再补系统调度视角

重点理解：

• 为什么不同请求会互相干扰
• 为什么队列论和容量规划重要
• 为什么在线系统要看 Goodput

17.3 再结合框架读实现

建议从以下方向看：

• vLLM 的请求调度和 KV 管理
• SGLang 的执行模型与缓存复用
• TensorRT-LLM 的 runtime 与 engine 优化思路

17.4 自己做一个小实验

哪怕没有完整集群，也可以先做一个简化实验：

1. 构造短 prompt + 长 prompt 混合负载
2. 比较混部执行与拆阶段执行的 TTFT / TPOT / P99
3. 观察某一侧压力升高时另一侧是否被拖累
4. 记录在不同负载分布下的最优资源配比变化

你不一定非得把完整解耦系统实现出来，但至少要把它的收益和代价量化出来。

18. 总结

P/D 解耦不是一个“看起来高级”的架构名词，它本质上是在回答一个非常现实的问题：

当 Prefill 和 Decode 的负载特性已经明显不同，并且它们在同一套资源上互相伤害时，系统是否应该为减少互扰而付出额外迁移和调度成本。

它的核心价值不在于把架构图拆成两块，而在于：

• 让 Prefill 和 Decode 各自在更合适的资源池里运行
• 降低阶段互扰
• 提高 SLO 内有效吞吐
• 让调度、扩容和性能定位更清晰

它的核心代价则在于：

• KV Cache 迁移
• 资源池配比
• 更复杂的调度器
• 更高的观测与运维要求

所以，真正成熟的工程判断从来不是“P/D 解耦先进不先进”，而是：

你的业务负载、网络条件、模型规模和服务目标，是否已经到了值得做这件事的阶段。

如果你能把这个问题讲清楚，无论是做推理系统设计、性能优化、架构评审，还是准备 AI Infra / LLM Serving 面试，这个主题都会很有分量。