第5章:分离式 KV-Cache 与 PD 分离 —— Mooncake / DistServe / SplitWise

LLM 推理把 disaggregation 范式直接搬进了 AI infra:KV-cache 池化 = 跨实例的远端内存共享,Prefill/Decode 分离 = 计算阶段按内存特征切机器。本章拆解 Mooncake / DistServe / SplitWise 三条主流路线,讲清它们各自怎么用 RDMA(以及未来怎么用 CXL),解决的是”显存装不下”还是”算力浪费”。读完这章你会发现 Kimi 商用 50%+ prefix 命中率、3-5× 吞吐提升,本质和 FORD 把数据库放远端是同一种抽象。

1. LLM 推理的 KV-cache 困境

回顾第 1 章建立的 KV-cache 内存账,以 70B 模型(GQA, 8 KV heads, 128 head_dim, fp16, 80 layers)为例:

单 token KV =  2(K+V) × 8(KV heads) × 128(head_dim) × 2(fp16) × 80(layers)
            =  327,680 bytes ≈ 320 KB / token / 会话

32K context  ≈  10 GB / 会话
1 H100 (80GB) - 模型(140GB?) - activation/scratch ≈ 不够装一份模型
              → 必须 4 卡 TP, 每卡留约 20-30GB 给 KV-cache
              → 只能塞 2-3 个并发的 32K 会话

数据为合理估算,具体取决于模型架构和 batch 配置。

KV-cache 的三种”装不下”:

单会话单实例装不下:超长 context(100K+)单卡放不下
多会话争抢同一实例:一个 H100 实例只能并发几个长会话,大量请求排队
跨会话重复算 prefix:不同用户的相同 prefix(系统 prompt、文档 RAG)每次重新算 — 算力浪费

🌟 结论:KV-cache 困境本质是”显存装不下且算了又扔”——前者是容量问题,后者是利用率问题。两条路线对应:池化解决容量,prefix 复用解决利用率,两者都是 disaggregation 范式。

⭕ 补充:这章讲推理。训练侧也有”装不下”问题(参数/optimizer state),走的是另一条 offload 路线,见第 6 章。

2. KV-Cache 池化:把会话状态从 GPU 搬到外部

KV-cache 池化的基本思路:把 KV blocks 看成”远端内存对象”,推理实例只在需要时拉取。

                       ┌──────────────────────┐
                       │   KVCache Pool       │
                       │  (跨节点内存池)       │
                       │  ┌────┬────┬────┐    │
                       │  │KV-A│KV-B│KV-C│ ... │
                       │  └────┴────┴────┘    │
                       └──────────┬───────────┘
                          RDMA / NVLink
                                  │
                ┌─────────────┬───┴───┬─────────────┐
                ▼             ▼       ▼             ▼
            Inference     Inference Inference   Inference
            Instance 1    Instance 2 Instance 3  Instance 4
            (H100)        (H100)     (H100)      (H100)

三层 cache hierarchy(Mooncake 是这个设计的代表):

层	物理位置	容量	延迟	命中场景
L1: GPU HBM	本地 GPU	几十 GB	~ns(load/store)	当前会话活跃 KV
L2: 节点 DDR	本地 CPU 内存	几百 GB-TB	~µs(GPUDirect)	上一个或邻近会话的 KV
L3: 跨节点池	远端节点 DRAM/SSD	几十 TB+	几十 µs ~ ms	历史会话、共享 prefix

淘汰策略:LRU + prefix-aware(高频复用的系统 prompt 永驻 L1/L2)

RDMA 拉取的延迟预算:典型 4MB block(512 tokens × 8KB/token 估算)从 L3 拉回 L1 ≈ 50-100 µs(100GbE)。这个延迟相对于 prefill 计算时间(~毫秒级)是可以忍受的,前提是 prefetch 准确。

🍎 直觉比喻:推理实例像 CPU 核,KV pool 像 LLC——本地命中最快,但 LLC 的存在让多核能共享数据,不必每个核都自己装一份。

3. Prefill / Decode 解耦:为什么要分开跑

Prefill 和 Decode 在资源画像上完全不同:

阶段	算力需求	内存带宽需求	延迟敏感	工作负载特征
Prefill	极高(全 attention 矩阵)	中	TTFT(首 token)	一次性大计算
Decode	低(单 token 自回归)	极高(每步读全 KV)	TPOT(token 间隔)	长尾、连续性

同机跑互相争资源:

Prefill 长时,decode 被 block(GPU SM 全被吃掉)→ 别人 token 间延迟突增
Decode 占 KV-cache 显存,prefill 时新会话装不下
batch 调度策略难以同时优化 TTFT 和 TPOT

PD 解耦的核心:让 prefill 在一类机器,decode 在另一类机器,中间 KV blocks 通过 RDMA 搬运。

Request → Prefill node (compute-heavy GPU)
              │
              │ generates KV-cache (RDMA transfer)
              ▼
          Decode node (memory-bw GPU, maybe cheaper)
              │
              │ autoregressively generates tokens
              ▼
          Response stream

🌟 结论:PD 解耦把”两阶段一锅炖”拆成”两个独立可扩缩容的服务”,各自按本阶段最优配置硬件——这正是 disaggregation 范式在 AI infra 的直接体现:按计算特征分离物理资源。

4. Mooncake:Kimi 商用架构精读

Mooncake(月之暗面 Kimi 的推理架构,FAST’25)是当前商用规模最大的 KV-cache 池化系统。

架构总览:

                           ┌──────────────┐
                           │  Conductor   │
                           │  (调度器)    │
                           └──────┬───────┘
                                  │ 路由决策
                  ┌───────────────┼───────────────┐
                  ▼               ▼               ▼
            Prefill Pool     KVCache Pool    Decode Pool
            (compute-heavy)  (transfer       (memory-bw
                              engine: RDMA   GPU)
                              + GPUDirect)

三大组件:

Conductor:全局调度,决定 request 走哪台 prefill / 命中哪个 KV block / 路由到哪个 decode 实例
KVCache Pool:三层 cache(本地 HBM / 节点 DDR / 跨节点池),用 LRU + 命中策略
Transfer Engine:基于 RDMA + GPUDirect 的高速 KV blocks 搬运,绕过 CPU 直接 GPU 到远端 GPU

关键工程数字(Mooncake 公开的 Kimi 商用数据,2024-2025):

Prefix cache 命中率 50%+(系统 prompt + RAG context 等高频前缀)
整体 throughput 提升 3-5×(对比单机 vLLM)
单 cluster 规模:数千 GPU
KV pool 总容量:百 TB 级(跨节点 DRAM + SSD 二级)

🌟 Mooncake 的关键贡献:用 KV pool + transfer engine 把 prefix 复用从”实例内”扩到”集群级”,50% 命中率近似于”算力翻倍”,这是商用 LLM 推理最重要的优化之一。

🧠 Mooncake 实质就是 disaggregated memory:KV pool 是 MN,推理实例是 CN,transfer engine 是 RDMA verbs 封装。和 FORD/Motor 的设计哲学完全一致,只是 workload 从事务变成 LLM。

5. DistServe:Prefill/Decode 资源解耦的实证

DistServe(OSDI’24)是学术界对 PD 分离最系统的实证。

核心 insight:

不解耦时,prefill 长任务把 decode 短任务的 SLO 拖垮(TPOT P99 突增)
解耦后,两阶段独立扩缩容,各自满足 SLO

优化目标:goodput-per-GPU——满足 SLO 的有效 throughput 除以 GPU 数。

实验关键发现:

某些场景下 PD 解耦让 goodput 提升 2-4×
不同模型/workload 的最优 prefill:decode GPU 比例不一(从 1:2 到 1:8 都有)
prefill 用大 GPU(H100/A100),decode 用相对便宜 GPU(A40/L40)更经济

SLO 双轴优化:

        TTFT (s)
         ▲
       3 │
         │   ╳ 同机部署
       2 │     ╳
         │       ╳   PD 解耦
       1 │         ╳────━━━━━━┓
         │                     ┃ Pareto front
         └──────────────────────────► TPOT (ms)
              50    100   200

🌟 DistServe 的关键贡献:用学术严谨实验证明 PD 解耦能在 Pareto 上完整碾压同机部署,把 PD 解耦从”工程 trick”提升为”系统级方法论”。

6. SplitWise:PD 分离的硬件成本论证

SplitWise(微软 + 华盛顿大学,ISCA’24)从硬件成本角度论证 PD 分离的合理性。

核心论点:Prefill 和 Decode 对 GPU 的需求不一致,异构集群最优。

测算:

Prefill 是 compute-bound → 高 FLOPS GPU(H100, 接近 1 PetaFLOPS)
Decode 是 memory-bandwidth-bound → HBM 带宽才是关键(H100 的 HBM3 3TB/s)
但 decode 不用那么多算力 — 用 A100 / 上代 GPU完全可以,价格便宜 30-50%

TCO 计算:同机方案需要全 H100;PD 解耦可以 prefill H100 + decode A100,整体 TCO 下降 ~25%。

🌟 SplitWise 的关键贡献:给云厂商 PD 解耦的硬件账本 ROI,推动了 Azure/AWS 部署 PD 解耦推理服务的工业决策。

⭕ 与 DistServe 的关系:DistServe 重在”系统怎么调度”,SplitWise 重在”硬件怎么配比”,两篇论文是互补关系。

7. 三家路线对比 + 工业落地考量

维度	vLLM(单机基线)	Mooncake	DistServe	SplitWise
Disaggregation 程度	无(单机 PagedAttention)	KV pool + PD 解耦	PD 解耦	PD 解耦(硬件视角)
硬件假设	单机多卡	同构 GPU + RDMA fabric	同构 GPU	异构 GPU(成本优化)
Prefix 跨实例复用	❌	✅ 50%+ 命中	❌(单实例内)	❌
主要研究焦点	单机内存调度	全栈系统(调度+池+transfer)	系统调度	硬件配比 + TCO
开源	✅	部分(transfer engine)	✅	❌(论文方法可复现)
工业落地	已部署广泛	Kimi 商用	学术原型 + 部分采纳	Azure 内部部署

工业落地需要解决的工程问题:

健康检查:KV pool 节点故障时,正在引用的 KV blocks 怎么 fallback 重算?
Cache 一致性:更新某个 prefix 后,所有引用该 prefix 的实例怎么知道刷 cache?(类似 CDN 失效)
Failover:PD 解耦后请求跨多机,某机 crash 时请求怎么重路由?(状态机比同机复杂得多)
多租户隔离:KV pool 共享时,租户 A 的 KV 不能被租户 B 误读
冷启动:新 prefix 首次出现时,prefill 全跑还是预热(speculative prefetch)?

⚠️ 失败模式:RDMA 带宽 100GbE 下 transfer 一个 4MB KV block 大约 40 µs,如果 prefix 命中预测错了把全部 cache miss 拉过去,反而比直接重算慢——所以 Mooncake 的 Conductor 必须保守预测,只对高置信命中触发预拉取。

🌟 结论:KV-cache 池化 + PD 解耦是 LLM 推理领域 disaggregation 的两个必选项,但二者解决不同问题:池化解决”存量复用”,PD 解耦解决”硬件错配”。生产部署一般两者结合(Mooncake 就是)。

✅ 自我检验清单

KV-cache 困境:能徒手算 70B 模型 32K context 单会话占多大 HBM
池化收益:能讲清 prefix cache 命中率 50% 等价于推理算力翻倍
PD 解耦动机:能讲清 Prefill 和 Decode 各自的资源画像差异
Mooncake 三层:能默写本地 / 节点 / 跨节点三层 cache 的延迟和容量量级
DistServe vs SplitWise:能区分两者的研究焦点(系统 vs 硬件成本)
跟数据库的同源性:能用一句话讲清”KV-cache 池本质是 disaggregated memory”
失败模式:能讲清 prefix prediction 错误的代价为什么很大

📚 参考资料

关键论文

Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving(Qin et al., FAST’25):arXiv 2407.00079 ⭐
DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving(Zhong et al., OSDI’24):arXiv 2401.09670 ⭐
SplitWise: Efficient Generative LLM Inference Using Phase Splitting(Patel et al., ISCA’24):arXiv 2311.18677
Efficient Memory Management for Large Language Model Serving with PagedAttention(Kwon et al., SOSP’23):arXiv 2309.06180 —— vLLM 的 PagedAttention,单机版同问题(对照)

框架文档

Mooncake transfer engine:github.com/kvcache-ai/Mooncake —— Kimi 开源的核心 KV transfer 组件
vLLM:github.com/vllm-project/vllm —— 单机基线,几乎所有论文都拿它做 baseline
SGLang:github.com/sgl-project/sglang —— RadixAttention 做 prefix tree
DeepSpeed-MII:github.com/microsoft/DeepSpeed-MII —— 微软的推理加速

行业讨论

Kimi 工程博客 —— 月之暗面公开的 Mooncake 设计文档
Anyscale Blog —— vLLM 团队的多篇技术博客
NVIDIA TensorRT-LLM —— 工业级推理加速的对照参考

下一章看训练侧:同一套 disaggregation 思想如何救千亿模型训练。

搜索