Mooncake 架构概览：以 KV Cache 为中心的高效 LLM 推理系统设计

本文对照 FAST 25 正式版论文 Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving（arXiv:2407.00079）核对。早期 arXiv v1（2024-07）与正式版存在数字口径差异，文中已标注；引用本文数字时建议一并注明版本。

1. 摘要

Mooncake 是月之暗面（Moonshot AI）为其智能助手 Kimi 构建的分离式 LLM 推理平台，核心是以 KVCache 为中心的调度器（Conductor）与分离式全局 KVCache 池（Mooncake Store），将预填充（Prefill）与解码（Decode）集群分离，并利用 GPU 集群中未充分利用的 CPU、DRAM、SSD 与 NIC 资源建立 KVCache 中心化缓存。

主要结果（FAST 25 正式版口径）：

  • 真实 trace 下有效请求容量提升 59%–498%（对比基线方法，同时满足 SLO）。早期 arXiv v1 曾报告模拟场景吞吐提升最高 525%，该数字在正式版中已移除，引用时注意版本；
  • Kimi 生产环境：对比基于 vLLM 的旧系统，A800 集群多处理 115%、H800 集群多处理 107% 请求（v1 口径为 75%，正式版已更新）；
  • 全局缓存收益：Mooncake Store 的 cache hit rate 最高达本地缓存方案的 2.36 倍，节省最高 48% 的 prefill 计算时间；
  • 传输引擎：较现有方案快约 2.4× 与 4.6×。

核心创新点（对应论文 §3–§4）：

  1. 分块管道并行（CPP）：长上下文预填充切分为 chunk 多节点流水处理，降低网络消耗并简化部署，缓解跨节点 TP 的 MFU 劣化；
  2. KVCache 感知全局调度：Conductor 基于「前缀匹配长度 → 传输/排队/执行时间估计」选择 prefill 实例，并配合基于负载的热点自动迁移；
  3. 预测性早期拒绝：对预测无法满足 SLO 的请求提前拒绝，避免浪费计算。

2. 研究背景

LLM 推理服务面临的核心矛盾：

  1. 长上下文：可用上下文从 8k 快速增长到 128k 甚至 1M token，输入 token 可达输出的 10–100 倍，TTFT 优化成为关键；注意力计算量随长度二次增长；
  2. 两阶段资源画像冲突：Prefill 计算密集、需要高 MFU；Decode 逐 token 生成、带宽敏感且受 TBT SLO 约束。耦合部署下两者互相干扰；
  3. 过载常态：GPU 供给受限、弹性扩容不可行，只能主动拒绝预测无法满足 SLO 的请求。

现有方案将预填充与解码耦合，且缓存局限于本地 HBM/DRAM——本地 DRAM 容量只能支持理论 cache hit rate 上限的约 50%，跨会话/跨请求的前缀复用大量流失。Mooncake 以 KVCache 为调度核心重构两阶段。

3. 核心架构设计

3.1 分离式全局 KVCache 池（Mooncake Store）

  • 资源池化：利用集群中未充分利用的 CPU、DRAM、SSD 与 NIC 资源建立分离式 KVCache 池，跨会话、跨请求共享前缀；
  • 块状存储与链式哈希：所有 KVCache 以分页块存储，块大小由模型规模与最优网络传输大小决定，典型范围 16–512 token；每个块的哈希键由自身内容与前缀块的哈希共同决定，因此前缀命中必须从开头连续匹配；
  • 驱逐策略：采用 LRU（被活跃请求引用的块不可驱逐）；

  • 全局 vs 本地：实验中全局缓存的 cache hit rate 最高为本地方案的 2.36 倍，本地 DRAM 容量只能支撑理论命中率上限的约 50%——这是全局池设计的核心依据。

  • 传输引擎：基于 RDMA 的高速 KVCache 传输，实测约为现有方案的 2.4× 与 4.6×；传输与增量 prefill 计算异步重叠执行。

3.2 双阶段分离调度

维度 预填充集群（P） 解码集群（D）
优化目标 最大化 MFU、满足 TTFT SLO 满足 TBT SLO
长上下文并行 分块管道并行（CPP） —
批处理 chunk 粒度流水 连续批处理
SLO 阈值（实验设置） TTFT ≤ 30 s TBT ≤ 100 / 200 / 300 ms（按场景）

实验集群配置：16 节点 × 8×A800（LLaMA3-70B，单 token KVCache 约 320 KB）。

CPP 机制：将 prefill 集群每 X 个节点组成一个流水线 prefill 节点组，请求输入切分为多个 chunk（阈值按 GPU 算力选取，典型大于 1000 token），不同 chunk 由组内不同节点同时处理。相比跨节点 TP（每层两次昂贵的 RDMA all-reduce）与传统序列并行（SP），CPP 降低网络消耗并提升 MFU。

4. 关键优化技术

4.1 KVCache 感知全局调度（Algorithm 1）

对每个新请求，Conductor 的调度流程：

  1. 计算请求的 prefix hash，与各 prefill 实例的缓存键逐一比对，得到各实例的前缀匹配长度；
  2. 对每个实例估计 Ttransfer + Tqueue + Tprefill（基于离线数据拟合的多项式预测模型），选 TTFT 估计值最小的实例；
  3. 当最佳匹配实例负载过高（超过 kvcache_balancing_threshold）时，允许向次优实例迁移缓存——若估计的额外 prefill 时间短于缓存传输时间，则宁可重算；
  4. 准入判断：估计 TTFT 超过 TTFT SLO、或 TBT 超过 TBT SLO 的请求被主动拒绝。

调度算法的实测收益（conversation trace，16 节点 8×A800）：全局 cache-aware 调度相比本地 cache-aware 调度，平均 TTFT 再降 14%；并优于 random 与 load-balancing 调度。

热点迁移：论文明确否决了「预测未来使用量」的方案（负载高度动态、无法准确预测），改用启发式自动热点迁移提升缓存负载均衡。

4.2 预测性早期拒绝

由于 GPU 供给弹性受限，Mooncake 对预测无法满足 SLO 的请求提前拒绝，避免无效 prefill 计算。预测基于请求特征（输入/输出长度等）结合当前负载，输出长度预测器用于判断请求能否在 SLO 内完成。

5. 实验验证

5.1 工作负载（论文 Table 2）

工作负载 请求数 平均输入长度 前缀缓存比例 到达模式
Conversation（Kimi 真实对话 trace） 12,035 343 token 40% Timestamp
Tool&Agent（Kimi 真实工具/智能体 trace） 8,596 182 token 59% Timestamp
Synthetic（ShareGPT+Leval+LooGLE 按 1:1:1 组成，Poisson 到达） 15,325 149 token 66% Poisson

其中 Conversation 负载最长请求达 128k token；有效请求定义为 TTFT 与 TBT 均低于各自阈值的请求。

5.2 主要结果

工作负载 Mooncake 有效请求容量提升
Conversation（真实 trace） 最高 +498%
Tool&Agent（真实 trace） +64%
真实 trace 整体范围 59%–498%（对比基线方法）
  • 基线：vLLM、vLLM + prefix caching、vLLM + chunked prefill（各 16 节点）；
  • Store 消融：全局缓存使 cache hit rate 最高达本地方案的 2.36 倍，prefill 计算时间节省最高 48%；
  • 传输引擎消融：较现有方案快约 2.4× 与 4.6×；
  • 生产环境：Kimi 在 A800/H800 集群分别多处理 115% / 107% 请求（对比旧 vLLM 系统）；
  • 版本差异：arXiv v1 曾报告模拟场景（合成负载）吞吐提升最高 525%，FAST 正式版以真实 trace 的 59%–498% 为准。

6. 工程实践启示

  1. 存储优先原则：长上下文场景下 KVCache 是显存与网络的主要瓶颈。Mooncake 以 KVCache 为中心，优先利用 CPU/DRAM/SSD/NIC 的闲置资源建立全局池，用「全局命中率 2.36× 于本地」的实测数据支撑了资源池化的决策。

  2. 解耦调度：调度即估计时间。Conductor 的调度不是抽象的评分函数，而是把「换一个实例」拆成传输、排队、执行三段可估计的时间再求和取最小，并用同一套估计值做 SLO 准入。这个「调度决策 = 时间估计」的思路可推广到其他状态重用场景。

  3. 预测的边界：论文对两种预测给出了不同答案——输出长度可预测（用于早期拒绝），未来缓存使用量不可预测（因此热点迁移用启发式而非预测模型）。什么时候该用预测、什么时候该放弃预测，论文给出了一个干净的对照。

7. 延伸讨论（本文观点，非论文内容）

论文本身未展开以下方向；这里是本仓基于架构特征的延伸思考，不代表 Mooncake 团队立场：

  1. 异构加速器：预填充/解码分离后，两类集群可以选用不同硬件画像（算力型 vs 带宽型），论文未讨论异构配置；
  2. 更远的分层：Store 已利用 DRAM/SSD/NIC，CXL 内存池等新介质与该架构的适配是开放问题；
  3. 跨集群/多租：跨地域缓存共享涉及隐私与数据驻留，论文未涉及。

8. 技术价值总结

  1. 架构：首个在大规模生产环境验证「分布式 KVCache 池跨会话共享」价值的系统（论文自述为同类首个）；
  2. 方法：把调度问题还原为可估计的时间分解（传输/排队/执行），并区分「可预测」与「不可预测」分别设计机制；
  3. 验证：真实 trace、生产集群（数千节点、日处理超千亿 token）与消融实验齐备，结论的工程可信度较高。

相关阅读

参考资料

  1. Qin, R. et al. Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving. FAST 2025. https://arxiv.org/abs/2407.00079
  2. Mooncake Store 代码：https://github.com/kvcache-ai/Mooncake