Mooncake：以 KVCache 为中心的 Prefill/Decode 分离式 LLM 服务架构

• 生命周期：推理服务（集群级）
• 部署形态：Prefill / Decode 分池 + 全局 KVCache 层
• 目标硬件：GPU 集群（第 15 页披露 A800-SXM4-80GB 测试平台、每实例 8 GPU、800 Gbps RDMA 互联）
• 核心资源：KVCache · 跨节点带宽 · 调度控制面
• 证据状态：P 主导 + 4 条编辑推断（I）；无仓库级（R）证据

一句话判断

对「长上下文、高前缀共享、过载频繁」的大规模在线 LLM 服务，Mooncake 把 KVCache 当成一等公民：Prefill 与 Decode 分池部署、全局调度器统一编排、过载时早期拒绝，在论文口径下以相同机器预算换取 20%–525% 不等的吞吐提升与更高的 SLO 达成率；代价是跨节点 KV 传输带宽依赖、控制面复杂度，以及「集中缓存 + 跨请求复用」带来的隔离与合规新问题。全部数字为论文条件性结果，且核验范围内无官方代码仓库声明。P I（代价与适用面判断为编辑观点）

3 分钟速读

1. 架构：图 1（PDF 第 2 页）给出整体形态——以 KVCache 为中心的分离式集群：全局调度器（Conductor）前置编排，Prefill 与 Decode 节点各自池化，两阶段之间通过 KVCache 的传输与复用衔接，并与全局 KVCache 缓存层协同。P
2. 动机：图 3–图 4（PDF 第 5–6 页）展示以 KVCache 为中心的调度与并发控制——基于前缀块的 KVCache 复用、跨请求/跨节点的缓存块映射与一致性处理；摘要文件同时以该门控记录负载统计：请求长度分布不均、可复用共享前缀多、长输入短输出占比高。P
3. 调度：PDF 第 9–11 页给出 CPP 与 KVCache 感知调度——结合缓存命中与负载估计决定请求接纳与 Prefill/Decode 节点放置，过载时进行准入控制；第 13–14 页补充早期拒绝：预计无法满足 SLO 的请求尽早拒绝，保护已接纳请求。P
4. 结果：相同 4 机预算下 [3P+1D] 较 vLLM [4M] 吞吐 +20%/+40%（第 15 页）；长上下文（输入 16k–128k、输出 512、命中率约 50%）+50%–525%（第 16 页）；过载回放 [10P+10D] 较 [20M] 多处理约 75% 请求（SLO：TTFT 30s、TBT 0.1s/token，第 17 页）。P
5. 边界：数字全部为条件性结果，禁止跨论文横比；核验到的 SLO 口径偏宽松（TTFT 30 秒）；无已核验代码仓库；安全、成本、多租户议题论文未涉及，均为编辑推断。P I

论文声称的主要结果

术语与记号

P / D / M

Prefill 节点 / Decode 节点 / 整体式（Monolithic）机器；配置记号 [3P+1D] 即 3 台 Prefill + 1 台 Decode，[4M] 即 4 台整体式机器。

TTFT

Time To First Token，首 token 时间。

TBT

Time Between Tokens，相邻 token 间隔时间。

论文出处

《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》，USENIX FAST '25（取自证据台账）；本地文件 03_Mooncake_2407.00079.pdf。

问题背景

整体式架构的结构性矛盾

LLM 推理的 prefill（并行处理整个 prompt、计算受限）与 decode（每迭代每请求只处理 1 个 token、内存受限）两阶段资源画像差异显著，整体式（monolithic）部署中二者混布互相干扰——prefill 长任务拖累运行中请求的 decode 延迟，decode 小批量又浪费算力。这一通识性动机在 Mooncake 论文中展开于引言与动机章节，但该部分不在本次核验门控范围内，本站按编辑通识转述，细节以论文原文为准。I

生产负载特征（论文核验门控内）

图 3–图 4（PDF 第 5–6 页）展示以 KVCache 为中心的调度与并发控制：基于前缀块的 KVCache 复用、跨请求/跨节点的缓存块映射与一致性处理。P 摘要文件同时以该门控记录负载统计：基于生产 trace 的请求长度分布不均、存在大量可复用的共享前缀、长输入短输出占比高——这构成以 KVCache 为核心进行调度与缓存管理的设计动机。P（两个来源对图 3–4 的侧重不同，本页并列呈现，不强行合并。）

评估数据：真实生产 trace

PDF 第 7–8 页描述用于评估的真实生产 trace：请求含长前缀、负载随时间波动；后续 trace 驱动仿真实验（含 2 倍速率回放）均基于该数据集，在可控配置下比较不同调度与缓存策略的吞吐和延迟表现。P

本页使用的延迟指标

与全站一致，本页以 TTFT（首 token 时间）与 TBT（token 间隔时间）讨论延迟；Mooncake 论文在过载回放实验中给出显式 SLO 数值——TTFT 30 秒、TBT 0.1 秒/token（第 17 页）。P 指标名词解释为站内通识口径。I

核心机制

1 · 以 KVCache 为中心的分离式架构（Fig.1，PDF 第 2 页）

Mooncake 将请求的 Prefill 与 Decode 阶段部署到不同的 GPU 节点池，中间通过 KVCache 的传输与复用衔接，并由全局调度器（Conductor）统一编排请求调度与缓存资源，整体与全局 KVCache 缓存层协同。KVCache 从「每张卡顺带维护的状态」升级为跨节点调度与复用的中心资源——这是「KVCache 为中心（KVCache-centric）」的含义。P

2 · 前缀块复用与跨节点缓存一致性（Figs.3–4，PDF 第 5–6 页）

以 KVCache 为中心的调度与并发控制落在两件事上：其一是基于前缀块的 KVCache 复用——相同前缀（如系统提示词、模板化任务头）的 KV 只需计算/传输一次，可跨请求复用；其二是跨请求/跨节点的缓存块映射与一致性处理——缓存块在不同请求与不同节点之间建立映射，并处理一致性。P

3 · CPP 与 KVCache 感知调度（PDF 第 9–11 页）

• 调度与放置：结合缓存命中情况与负载估计做请求调度与放置，决定「是否接纳」与「落到哪个 Prefill / Decode 节点」——摘要文件转述为按前缀/缓存亲和性选择节点，并结合缓存热度进行复制与淘汰。P
• 准入控制：过载时进行准入控制，避免新请求无限进入拖垮全体延迟。P
• 关于 CPP 的名称：CPP 即 chunked pipeline parallelism（分块流水线并行），术语见 PDF 第 9 页；本页 CPP 相关调度描述仍以第 9–11 页门控为准。P

4 · 早期拒绝（early rejection，PDF 第 13–14 页）

过载场景下，对预计无法满足 SLO 的请求尽早拒绝，避免其长期占用 Prefill/Decode 资源，从而保障已接纳请求的 TTFT 与 TBT，以及整体集群的 SLO 达成率。P 直觉上，这是把过载从「全体一起变慢、尾部延迟爆炸」改写为「部分请求被明确拒绝、其余请求守住 SLO」——该定性概括为编辑观点。I 量化结果（被拒请求数 4183/3771/3589）见 实验与指标。

GPU / 系统数据路径

端到端文字序列

1. ① 请求进入：客户端请求到达前置的全局调度器/控制器（Conductor）。P Fig.1（第 2 页）
2. ② 调度与准入：调度器结合缓存命中与负载估计做调度/放置，决定请求接纳与 Prefill/Decode 节点分配（第 9–11 页）；预计无法满足 SLO 的请求在此被尽早拒绝（第 13–14 页）。P
3. ③ Prefill 计算：Prefill 节点并行处理 prompt、产出 KV 缓存（Fig.1，第 2 页）；基于前缀块的复用使共享前缀不必重算（第 5–6 页）。P
4. ④ KV 传输：KV 缓存经 KV 传输 fabric 从 Prefill 侧转移到 Decode 侧（Fig.1，第 2 页：两阶段通过 KVCache 的传输与复用衔接）；跨节点带宽是这一段的硬约束——论文第 15 页披露 A800 测试平台实例间为 800 Gbps RDMA 互联，不代表其他部署。P I（带宽约束的部署含义为编辑推断）
5. ⑤ Decode 计算：Decode 节点基于传输到的 KV 做增量解码，逐 token 生成。P Fig.1（第 2 页）
6. ⑥ 流式返回：输出 Tokens 流式回传客户端；TTFT 对应第 ③→⑥ 段的首 token 到达，TBT 对应其后相邻 token 间隔——第 17 页实验即以 TTFT 30s、TBT 0.1s/token 为 SLO 口径。P

架构权衡

云上部署映射

本节为部署映射：论文硬件事实标 P，云产品对应标 E（仅作厂商中立示例，参数与价格以云厂商文档为准，本站未联网核验），运维建议/推断标 I。

成本 / 性能 / SLO

SLO 与实验口径（论文定义）

容量规划变量

• KVCache 命中率：决定复用收益（论文口径 50% 对应 50%–525% 提升，第 16 页）——前缀共享度是第一变量；P
• P:D 池比例：论文覆盖 [3P+1D]、[8P+8D]、[10P+10D] 等配置，比例是容量与成本的一级旋钮；P
• 拒绝率：过载下有效处理量 = 到达量 − 被拒量，早拒绝阈值直接决定对外语义；P I
• 跨节点带宽：KV 传输 fabric 的可行域约束（论文第 15 页披露 A800 平台 800 Gbps RDMA）。P I

成本模型（参数化，非论文结论）

论文不含任何成本数据（仅吞吐/SLO/拒绝率）。架构师可用下式估算（I，价格项为参数）：

每百万请求成本 ≈ ( p_gpu × (N_P + N_D) + p_net ) ÷ R_adm × 10⁶ …（公式 1）

• p_gpu：单卡时租价（按查询日云价代入，E）；
• N_P / N_D：Prefill 池 / Decode 池卡数（如 [3P+1D]×每机卡数起步）；
• p_net：跨节点 KV 传输与缓存层折算成本（命中率低、带宽贵时不可忽略，I）；
• R_adm：SLO 内单位时间有效接纳并完成的请求数 ≈ 到达率 × (1 − 拒绝率)（I）。

敏感项：命中率上升 → R_adm 上升（第 16 页命中 50% 时 50%–525% 提升 P）；拒绝率上升 → R_adm 直接折损（第 17 页拒绝计数 P）；P:D 比例失衡 → 某一池闲置、单位成本上升（编辑推断 I）。

安全与可运维性

论文披露范围

• 核验门控内论文未涉及安全、隐私、多租户与故障恢复议题——以下部署要点均为编辑推断。I
• 无已核验代码仓库：核验范围内论文未给出可核验的官方仓库声明，证据台账刻意不含任何仓库/实现层声明（commit、release、目录结构等均未验证）。R
• 评估方法论为真实生产 trace 驱动仿真（含 2 倍速回放），非公开可复现的基准套件声明。P（第 7–8 页）

论文未披露、部署方必须自行覆盖的项

适用 / 不适用场景

适用（触发条件 → 理由）

1. 长上下文生产负载：触发条件——输入在 16k–128k token 量级、输出数百 token。理由——论文在输入 16k–128k、输出 512、命中率约 50% 条件下实测吞吐 +50%–525%（第 16 页）。P
2. 高共享前缀 / 高命中率业务：触发条件——系统提示词、模板化任务头等前缀大量复用（命中率可测且可观）。理由——前缀块 KVCache 复用与跨请求映射是机制核心（第 5–6 页），命中率正是论文收益数字的前提变量。P
3. 过载频繁、重视 SLO 达成率的集群服务：触发条件——峰值到达量常态性超过容量、业务可接受部分拒绝。理由——过载回放中 [10P+10D] 较 [20M] 多处理约 75% 请求（TTFT 30s / TBT 0.1s/token，第 17 页），早拒绝保住已接纳请求的延迟（第 13–14 页）。P
4. 两阶段负载不均衡、需独立伸缩的平台：触发条件——prefill 与 decode 峰值错位、扩容需求不同步。理由——P/D 天然分池，可各自伸缩；此为架构形态的直接推论。P（分池形态，第 2 页） I（伸缩收益判断）

不适用（触发条件 → 理由）

1. 低缓存复用负载：触发条件——prompt 随机性强、共享前缀少、命中率远低于论文 50% 口径。理由——复用是收益主引擎，命中率坍塌则 50%–525% 的前提不成立（编辑按第 16 页条件反推，论文未测低命中率对照）。I
2. 单机 / 小规模部署：触发条件——总计个位数 GPU、无实例间高带宽网络。理由——分离架构至少要求 P/D 两组节点 + KV 传输 fabric，小规模下额外网络与控制面成本压倒收益（编辑推断）。I
3. 紧 TTFT SLO 的强交互服务：触发条件——首 token 延迟要求亚秒级。理由——论文核验到的显式 SLO 为 TTFT 30 秒 / TBT 0.1 秒/token（第 17 页），更紧 SLO 下的行为无核验证据，不能外推。P（证据边界） I
4. 硬多租户隔离 / 强合规业务：触发条件——跨租户数据严格不可见、审计要求高。理由——前缀块跨请求复用与集中 KVCache 与硬隔离天然冲突，需关闭复用或分域部署，收益随之缩水（编辑推断，论文未涉安全议题）。I
5. 带宽受限的存量集群：触发条件——实例间仅普通以太网、无扩带宽计划。理由——KV 传输 fabric 是必经数据通路，带宽不足直接限制可行配置（论文第 15 页披露 A800 测试平台实例间 800 Gbps RDMA 互联）。P I

实验与指标

复现实验的完整条件（论文核验门控内）

关键结果（均带条件）

公平性限制与已知差异

• 全部数字为对门控页的转述；精确引用请回查 PDF 原文（摘要文件同此声明）。P I
• 页码口径：被拒请求数（4183/3771/3589）在证据台账与摘要文件中均定位于第 17 页（P09）；第 13–14 页门控仅覆盖早期拒绝机制描述，不含该计数。P
• 论文第 15 页已披露实验模型与测试平台：LLaMA2-70B 同质 dummy 模型、A800-SXM4-80GB 节点（每实例 8 GPU、共 4 台机器）、实例间 800 Gbps RDMA 互联；第 16 页 §8.1.2 沿用 §8.1.1 相同配置。精度（dtype）、trace 起止时间等细节门控页未明示，按「论文未明示」如实标注，本页不臆测。P（第 15–16 页）
• 数字不可与 DistServe、Sarathi-Serve 等其他论文横比（硬件、负载、SLO 口径均不同）。I

核对 / 复现路径

由于核验范围内不存在已核验的官方代码仓库（R 缺位），无法给出仓库级复现步骤；建议按 PDF 门控逐条核对：I（顺序为编辑建议）

1. 以 Fig.1（第 2 页）核对整体架构与组件边界；
2. 以第 7–8 页核对 trace 定义与 2 倍速回放口径；
3. 以第 9–11 页核对 CPP/调度与准入控制描述（CPP 即 chunked pipeline parallelism，见第 9 页）；
4. 以第 13–14 页核对早拒绝机制，再以第 15–17 页核对全部数字及其条件。

论文 / 链接 / 延伸阅读

论文引用的关联工作（vLLM 及其他）仅按门控页转述，未核验到官方仓库的恕不提供链接。下一篇（04）页面如尚未生成，请从首页目录进入。

给架构师的决策清单

证据台账

分级：P = 论文 PDF 原文证据（已核验）；R = 论文给出的官方仓库声明（本页为 0 条——台账刻意不含任何仓库声明）；E = 外部/云文档（仅部署映射，未联网核验）；I = 编辑推断（显式标注不确定性）。编号与 sources/mooncake.evidence.json（P01–P09、I01–I04）对应，E-01 为本站补充条目；定位均为真实 PDF 页码/图号。P09 被拒计数在台账与摘要文件中均为第 17 页；第 13–14 页门控仅覆盖早期拒绝机制。最后核验日期：2026-09-14。

R 级说明：核验范围内论文未给出官方代码仓库声明，台账不含任何仓库/实现层声明（代码结构、commit、release 等均未验证）；本页因此不提供任何仓库链接。摘要文件 sources/mooncake.summary.json 的 source_pdf 同步记为 03_Mooncake_2407.00079.pdf。