跳到主要内容
推理优化

7.2 解耦架构设计：DistServe、Splitwise 与统一框架

P/D 解耦的系统脉络：DistServe（goodput 优化与放置调度）、Splitwise（GPU 池分离与硬件选型）、TaiChi（聚解耦统一）、MLC Microserving（跨引擎编排）

PD解耦DistServeSplitwiseTaiChiMicroservingKVCache

7.1 论证了”混合有罪”，这一节看”解耦怎么建”。学术界在 2024 年密集产出了 P/D 解耦的系统研究：DistServe（OSDI’24）证明解耦能赢多少、Splitwise（ISCA’24）从硬件经济学角度拆池、TaiChi 尝试把聚/解耦统一、MLC Microserving 把解耦推到跨引擎的粒度。四篇的视角不同，合起来就是解耦架构的完整地图——为什么拆、拆成什么样、拆完怎么调度。

📑 目录

1. 解耦的基本形态：两个池、一条链

所有解耦方案的骨架相同：

请求 ──→ [Prefill 池] ──KV Cache 传输──→ [Decode 池] ──→ 响应
          多实例/多 GPU             高速网络            多实例/多 GPU
  • Prefill 池：只做提示处理，产出 KV Cache（不是输出 token！）和首 token
  • Decode 池：接收 KV Cache，从首 token 继续自回归生成，直到 EOS
  • 两者之间：KV Cache 的搬运（7.3 专讲）——这是解耦架构的工程命脉

💡 提示：注意一个容易混淆的点——Prefill 实例算完后，输出 token 只有 1 个，真正传给 Decode 的是”KV Cache + 首个输出 token”。Decode 实例拿着 KV Cache 从第 2 个 token 开始继续生成。KV Cache 是”接力棒”，Token 只是接力棒的把手。

各家方案的区别在三个设计轴上：

  1. 池的构成：硬件同构还是异构（Splitwise 最激进）
  2. 调度逻辑：请求怎么分到池、池间怎么协调（DistServe 的 placement + scheduling）
  3. 统一性：聚解耦是两种模式还是同一架构的两种形态（TaiChi 的回答）

2. DistServe：Goodput 视角的系统化论证

DistServe（OSDI 2024，清华/北大/上海交大等）是 P/D 解耦的奠基性系统论文，贡献有三层：

2.1 问题论证：耦合必须拆

系统化论证了 7.1 的两个问题（干扰 + 资源耦合），并定量给出：现有系统为了满足 P90 TTFT/TPOT，必须过度配置算力——即”混在一起”在 SLO 约束下是资源浪费的。

2.2 目标重定义：Goodput

DistServe 把优化目标从”吞吐”改为 Goodput——满足 SLO 的请求吞吐（7.4 细讲）。同样的硬件，满足 SLO 的请求数才是真正有用的产出。这个视角转变是解耦系统设计的哲学基础。

2.3 方法与效果

  • 独立调优：prefill 实例和 decode 实例各自配置并行度（TP/PP）、batch 策略，TTFT 与 ITL 两个 SLO 互不干扰
  • KV 传输：prefill 实例算出 KV 后通过高性能网络传给 decode 实例（论文中量化为 KV 传输开销，提出 batch 级传输优化）
  • 放置与在线调度：根据请求的 prefill/decode 负载特征（prompt 长度、输出长度分布）做实例放置（placement）和在线调度（online scheduling），兼顾节点亲和性（高/低亲和集群两种算法）

效果：相比 SOTA 系统，在相同延迟约束下多服务 7.4× 请求，或达到 12.6× 更紧的 SLO。

📌 关键点：DistServe 的启示不只是”解耦有效”，而是**“解耦必须配合 goodput 目标和放置调度才完整”**——只把进程拆开、不重新设计调度，收益有限。这也是 7.4/7.5 两节的内容来源。

3. Splitwise：GPU 池分离与硬件经济学

Splitwise（ISCA 2024，微软）从硬件选型角度切进：既然 Prefill 要算力、Decode 要带宽，为什么让它们用同一种 GPU？

3.1 核心观察

  • Prefill：算力密集，用高 FLOPS 卡（A100/H100）→ 单位时间处理更多 prompt
  • Decode：带宽密集，用高带宽卡（如 H200 级高带宽型号）→ 每 token 搬运更快
  • 两者混用时，卡型只能按”最贵需求”配置——算力卡在 decode 阶段闲置算力，带宽卡在 prefill 阶段闲置带宽

3.2 方案

把 GPU 池按阶段拆分，配以高效 KV 传输：

prefill 池：A100 集群（算力优先）
decode 池：H200 集群（带宽优先，更便宜）
KV：RDMA/InfiniBand 高速传输

3.3 效果

  • 相同资源下吞吐提升约 4.8×（论文数据，具体场景有差异）
  • 总成本下降：decode 池可以用更便宜的卡型，prefill 池的卡利用率大幅提高
  • 关键前提：池间 KV 传输开销必须可控——论文量化了传输开销与收益的权衡点（输出长度越长、传输摊薄越明显）

💡 提示：Splitwise 的视角对生产很有用——算资源账时，按”阶段”分卡型。一个常见的工程误区是”所有卡都买最强的”，在解耦架构下，decode 池用性价比更高的卡是显式的最优解。

4. TaiChi：聚合与解耦的统一框架

TaiChi（2024，中科大/清华等）回答一个更细的问题：P/D 聚合（混合）和 P/D 解耦不是二选一——负载是动态变化的，两种模式各有优势区间。

4.1 核心设计

  • 单一统一架构：一个系统同时支持聚合与解耦两种执行模式
  • 差异化 GPU 实例：区分 prefill-heavy 实例与 decode-heavy 实例，同一个实例可以动态切换角色（负载变化时重新配置）
  • 负载感知的池伸缩：根据实时请求特征在”聚合模式 ↔ 解耦模式”之间调整实例配置

4.2 与 DistServe/Splitwise 的关系

系统视角场景假设
DistServe解耦 + goodput 调度负载特征稳定，可静态放置
Splitwise解耦 + 异构硬件硬件池可按阶段分工
TaiChi聚/解耦动态统一负载动态变化，需要弹性

📌 关键点：TaiChi 的工程启示——解耦不是部署态而是运行态。生产负载（尤其多租户）的 prefill/decode 比例随时间波动，硬编码”永远解耦”可能浪费，硬编码”永远混合”可能爆尾部。动态模式切换是生产级系统的下一站。

5. MLC Microserving：跨引擎的流水线编排

MLC Microserving（MLC-LLM 团队的思路，也有独立论文）把解耦推到跨引擎/跨框架的粒度：

5.1 核心设计

  • 把大模型的推理拆成多个微服务阶段（不只是 P/D 两段，可以按层/按功能拆更细）
  • 每个阶段独立部署、独立伸缩、独立版本升级
  • 阶段之间通过标准 RPC/流式接口传递中间状态（KV 或 token 流）

5.2 与 P/D 解耦的关系

  • 特例关系：P/D 解耦是”拆成 2 段”的 microserving
  • 额外收益：每段可以独立用不同引擎/框架实现（如 prefill 用高性能引擎、decode 用低延迟引擎）；故障隔离更细（一个阶段挂了不影响其他阶段）
  • 额外成本：接口标准化开销、多跳延迟、运维复杂度

💡 提示：工程上”跨引擎编排”的价值主要在多团队协作和异构部署（不同引擎在各自擅长场景胜出）。单团队、单引擎场景，2 段式解耦（P/D）已经足够——microserving 是”拆得更碎”的选项，别为抽象而抽象。

6. 四篇的对比与共识

系统会议核心贡献优化目标关键结果
DistServeOSDI’24解耦 + goodput 视角 + 放置调度Goodput（SLO 内吞吐）多服务 7.4× 请求 / 12.6× 更紧 SLO
SplitwiseISCA’24阶段化 GPU 池 + 异构硬件选型吞吐/成本吞吐 ~4.8×，成本下降
TaiChi2024聚解耦统一架构、动态实例角色动态负载适配两种模式的统一弹性
MLC Microserving2024跨引擎流水线编排部署灵活性更细粒度解耦的参考

共识（四篇都认同的）：

  1. P/D 必须分离优化目标：TTFT 和 ITL 是独立的 SLO 维度，混在一起必然互相妥协
  2. KV 传输是解耦的命脉：传输开销决定解耦的收益边界（Splitwise 的权衡、DistServe 的优化、TaiChi 的池间协调都围绕它）
  3. 调度要与解耦配套：只是把进程拆开远远不够——放置、负载感知、弹性都是系统设计的组成部分
  4. 解耦不免费：多一跳网络、多一层编排、更复杂的运维——收益 > 成本才值得

📌 关键点：读完四篇后应该建立的心智模型——解耦不是”一个开关”，而是”两个池 + 一条 KV 链 + 一套配套调度”的完整系统。论文给方向，工程落地见 7.3（KV 传输）和 7.6（vLLM 实战）。

7. 从论文到工程：vLLM 的落地

vLLM 的 Disaggregated Prefill（v0.26 标记 experimental）采纳了论文的核心设计：

  • 两个实例：prefill 实例 + decode 实例（对应 DistServe/Splitwise 的池）
  • KV Connector 抽象：KV 传输可插拔（对应”KV 传输是命脉”的共识，7.3 详讲）
  • 独立并行配置：两个实例可各自设 TP/PP（对应 DistServe 的独立调优）
  • 官方明确：解耦不提升吞吐，目标是 TTFT/ITL 独立控制与尾部控制（v0.26 文档原话）

💡 提示：注意 vLLM 官方的定位——“Disaggregated prefill DOES NOT improve throughput”。这与论文的 goodput 提升并不矛盾：goodput 是”满足 SLO 的吞吐”，混排下 SLO 达标率低、有效吞吐低；解耦后同样硬件下满足 SLO 的请求变多。读论文时抓住”goodput 不等于 raw throughput”这条主线，就不会被”7.4× vs 不提升吞吐”搞晕。

📝 总结

  • 解耦骨架：Prefill 池 → KV 传输 → Decode 池；传的是 KV Cache（接力棒）
  • DistServe：goodput 视角 + 放置调度，7.4× 请求或 12.6× 更紧 SLO
  • Splitwise：按阶段分 GPU 池、异构选型，吞吐 ~4.8×、成本下降
  • TaiChi：聚/解耦统一架构，实例角色动态切换
  • Microserving：跨引擎细粒度流水线（P/D 是 2 段特例）
  • 共识：独立 SLO、KV 传输是命脉、调度必须配套、解耦不免费
  • vLLM 落地：双实例 + KV Connector 抽象，官方定位是尾部控制而非吞吐

🎯 自我检验清单

  • 解耦架构的三个组成部分是什么？传的”接力棒”是什么？
  • DistServe 的 goodput 定义与 raw throughput 的区别？
  • Splitwise 为什么让 prefill 池和 decode 池用不同卡型？各自要什么硬件特性？
  • TaiChi 与 DistServe 的定位差异？（静态解耦 vs 动态统一）
  • “解耦不免费”——成本有哪些？什么场景收益>成本？
  • vLLM 官方说解耦不提升吞吐，论文说 7.4×，矛盾吗？怎么解释？

📚 参考资料