Mooncake：KVCache 解耦架构下的大模型推理优化生态

如果无法正常显示，请先停止浏览器的去广告插件。

1. 演讲人：马腾

2. 01 02 03 04 05 06 Mooncake项目未来规划

4. 01

5. 算法 - Transformer is all we need? 数据 – Big Data is Everywhere 数字化进程的推进使得采集和积累的数据前所未有的增多内部所有的算子均为 GEMM 或 BMM，最大化计算强度和并行度智能 – AI Become Everywhere Too 随着人工智能的发展，越来越多的软件基于 AI 技术进行改造硬件 – Huang’s Law Take Over 以 NVIDIA 为代表的 GPU 厂商通过提供高并发的稠密张量计算替代传统 CPU 厂商成为算力的主要提供商，从而进一步延续 FLOPS per Watt 的增速

6. 2024年：Llama3-405B = Dense模型 + SFT + 8k上下文（后扩展至 128k） 2025年：Deepseek-671B = MoE模型变化：模型规模模型结构影响：更多资源部署方式训练方法 + RL + 128k上下文上下文长度训推一体 kvcache Data Source: SimilarWeb 2024年3月Kimi凭借长文本处理能力成为最主要的大模型服务之一 2025年1月DeepSeek凭借推理能力快速晋升全球最知名的大模型服务之一

7. 更多数据 + 更大模型 + 更长上下文窗口 = 更高智能全新模型结构 + 更多资源需求 + 更低使用成本 + 更高性能 + 更安全可信部署 = 更高技术挑战 Data Source: SimilarWeb 2024年3月Kimi凭借长文本处理能力成为最主要的大模型服务之一 2025年1月DeepSeek凭借推理能力快速晋升全球最知名的大模型服务之一

9. 阶段核心指标优化目标举例预填充阶段 TTFT 最小化首次响应延迟 P90 TTFT ≤ 0.4秒（90%请求需满足）解码阶段 TBT/TPOT 平滑生成速度，减少波动用户每秒可读40词（快于人类阅读速度）整体推理框架 TPS 单位时间内处理的token数量并发用户数、内存限制、上下文切换线上服务质量 GoodPut 满足SLO的有效吞吐量满足TTFT/TPOT，平衡成本与服务质量

10. 静态稀疏化滑动窗口例子减少Head数 GQA/MQA 降低维度 MLA 只存部分层 YOCO/CLA 量化 FP8/Int4 高效显存管理 Page Attention vAttention

11. ◼ 每一个 1 token 对应 2 * 层数 * 隐藏维度 = 数十乃至数百 KB 的 KVCache ◼ 不仅数据量极大，还需要尽可能地快速进行传输不然会导致 GPU 空转应缓存的中每天数千亿 Token 的大型推理服务一个 Token （数 Bytes 级别）一个 Token 对应的 KVCache (数十 KB 级别) 推理可复用单张 GPU 显存 (数十 GB 级别) 单台机器的内存（数 TB 级别）间结果 KVCache (数百 TB 乃至 PB 级别)

12. 02

13. Orca Continus Batching 通过切分任务打满算力 vLLM Page-Attention Page粒度管理减少显存占用 SGLang Prefix Attention 尽可能复用KVCache

14. 模型级别优化 KVCache压缩通过算法优化（Head/Dimension）减少KVCache产生量 KVCache量化使用低精度格式 KVCache消除减少无关重要的数据

15. ◼ 在PagedAttention中，KV Cache只是在一个请求内复用，而没有做到跨请求的KV Cache复用 ◼ 在多轮对话的场景下，下一轮的prompt其实刚好就是上一轮的prompt+completion SGLang 原生支持通过RadixAttention来实现 Prefix Caching first-come-first-serve，无法达到最优的缓存复用效果 cache-aware scheduling的调度算法 vLLM Hash RadixAttention的方法，它使用哈希码作为物理KV Block的唯一标识 hash(prefix tokens + block tokens) <--> Logical KV blocks -> Physical KV blocks DeepSeek 上下文硬盘缓存技术，把预计未来会重复使用的内容，缓存在分布式的硬盘阵列中

16. 共享和复用基本原理以存换算基本原理：前缀匹配的中间结果可被复用 “What day is it tomorrow” “What day is it today” 前四个字 Prefill for Request I What Prefill for Request II What KVCache 复用符和第一个请求相 What What day 同，因此 day 无需重复 day day is is is is 计算可以 it toda y it it tomo rrow it 直接复用 tomorrow 中间结果 today (5 tokens computed) (1 token computed)

17. 共享和复用基本原理 • 大模型辅助读论文场景为例所有查询可复用可复用长度长 System Prompt: 你是一个论文阅读助手，… 热点论文复用率高 User Question 1: 总结一下这篇论文 User Question 2: 这篇论文关键创新是什么 User Question 3: 有哪些相关研究？ User Question 4: 可以进一步探索什么？不同的用户会对同一篇论文进行不同角度的提问，只要能将共享的可复用的部分保存下来多次复用就可以大幅度降低算力开销问题短

18. 03

19. 将Prefill与Decode解耦，让 “算力-吃紧”与“带宽-吃紧” 任务各得其所，推理延迟- 吞吐双降把Attention 计算和 Expert 路由/计算分到异构硬件， CPU缓存KV、GPU稀疏激活专家，MoE模型显存换带宽，成本直降 PD分离 AF分离把多模态编码、KV生成、自回归解码拆成三阶段流水线，单阶段内存爆降 95%，批尺寸×20，长图长视频秒级TTFT。 EPD分离把RLHF中的在线样本生成（推理）与策略梯度更新（训练）彻底分开，独立扩缩容、异构部署，训练吞吐提升2.6×，成本再降 30%。推训分离

20. AF分离 EPD分离 PD分离推训分离

21. GPU Shared Memory 显存（VRAM） 128 KB / SM 150 TB/s 聚合仅限同 Thread-Block 141 GB (H200) 4.8 TB/s 峰值内存（DRAM）远端内存（RDMA），SSD，分布式文件系统 2 TB DDR5 500 GB/s 读写带宽 30 TB NVMe-oF 25 GB/s 带宽 200 Gbps RDMA 整 GPU / NVLink 跨 GPU CPU 到 GPU PCIe 机柜/机柜、跨 DC PCIe/以太网

22. 以KVCache为中心的解耦结构：Mooncake icon KVCache- centric Conductor Local Chunked Prefill Scheduler GPU/VRAM PP/SP Paged KVCache CPU/DRAM/SSD Distributed KVCache Pool KVCache Balance Scheduler Distributed KVCache Pool GPU/VRAM Local Chunked Prefill Scheduler Paged KVCache ◼ 以存换算！提升 Kimi 吞吐 75% 以上 ◼ 以超大规模分离式内存池为中心的 KVCache 缓存和调度 CPU/DRAM/SSD Distributed KVCache Pool ◼ Paged KVCache Local Scheduler Decoding Instance CPU/DRAM/SSD Distributed KVCache Pool GPU/VRAM Paged KVCache Local Scheduler Decoding Instance 用户体验（SLO）优先、面向过载场景的调度策略 Inter-node KVCache Transfer CPU/DRAM/SSD Load- balance Decoding Scheduler Kimi 底层推理架构，承载 80% 以上流量 Prefill Instance GPU/VRAM Cache- aware Prefill Scheduler Prefill Instance 超大规模的优势 ◼ 缓存命中率和缓存池容量大小呈现正相关 ◼ 不同的场景下斜率不同 ◼ 单节点内存容量不足够达到容量和命中率的甜点区域，需要更大容量的缓存池

23. 点对点传输（CPU Offload）点对点传输（GDR） Store接口

24. 维度 LayerWise Chunk Level 全量传输吞吐量中高低扩展性强中弱实现难度复杂（动态调度）中等（块管理）简单 LayerWise（逐层传输）传输单位：单层参数/激活值特点：细粒度控制：按层动态调度，资源利用率高显存优化：预填充后立即释放单层资源通信开销：高频次小数据传输，增加延迟适用场景：长序列生成（＞4K tokens） Chunk Level（分块传输）传输单位：固定长度数据块（如1K tokens）特点：平衡性：减少传输次数，带宽占用可控流水线优化：支持预填充与解码阶段并行管理复杂度：需协调块间依赖关系适用场景：中长序列（512-4K tokens）全量传输（End-to-End）传输单位：完整上下文参数/激活值特点：低延迟：单次传输完成，无调度开销带宽瓶颈：显存占用高，限制序列长度扩展资源浪费：解码阶段空闲预填充资源适用场景：短序列推理（＜512 tokens）

25. 04

26. Transfer Engine： ◼ ◼ ◼ ◼ ◼ ◼ 全链路零拷贝、多网卡池化最高8*400Gbps聚合带宽、拓扑感知故障容错，负载均衡，多协议支持。更充分地发挥高性能网卡的优势，相比 nccl 更加灵活，支持动态拓朴、故障容错 KVCache Store： ◼ ◼ ◼ ◼ 充分利用GPU 集群中闲置的内存和带宽省成本的同时降低响应延迟透明多级缓存进一步下沉到底层廉价存储 Production Ready: ◼ AC2镜像 + K8S部署 ◼ 提供whl包一键安装

27. ◼ 关键特性：全链路零拷贝、多网卡池化，最高 8*400Gbps 聚合带宽、拓扑感知，故障容错，负载均衡，多协议支持 ◼ 相比其他传输协议能够发挥高性能网卡优势 ◼ 相比 nccl 更灵活，支持动态拓朴/故障容错训练框架推理框架零拷贝对象语义接口 P2P Store Managed Store BatchTransfer API Mooncake Transfer Engine 内存语义接口裸金属存储资源高性能内存型存储

28. ◼ 与传统缓存系统的区别: ◼ 灵活性与可定制性: ◼ Key 由 value 通过哈希计算得到，无需 update操作 ◼ 提供底层对象存储和管理功能。 ◼ 支持Lease，没有版本管理的需求 ◼ 具体缓存策略由上层框架/用户实现（如 vLLM） ◼ 系统特性: ◼ 提供KV复用率，TTFT等指标 ◼ etcd可靠性服务，高可用模式 ◼ 数据持久化能力 ◼ 提供分层存储能力（NFS/3FS） ◼ 提供Restful API/独立服务 ◼ 多语言接口/零拷贝能力

29. KVCache 缓存的关键：存的多，传得快，性价比高！ ◼ 充分利用当前 GPU 集群中闲需要充分利用 (GPUDirect) RDMA/Storage 等高性能 IO 技术置的内存容量和互联带宽推理用机 2 推理用机 1 GPU 1-1 更新 X[1..s+1] 对应的 K/V向量 CPU/ DRAM/ SSD GPU 2-1 装载 X[1..s] 对应的 K/V向量 ◼ 省成本的同时降低响应延迟 ◼ 透明多级缓存，未来可以进一 GPU/VRAM 步下沉到底层廉价存储 Prefix + tokens GPU/VRAM Paged KVCache Hash() 全局缓存节点 S3 PCIe 链路读缓存存储接口层 SSD SSD SSD 读写缓存 Paged Paged KVCache KVCache RDMA Paged Paged KVCache KVCache NVMe-of CPU/DRAM/SSD 对象存储写缓冲 Paged Paged KVCache KVCache SSD SSD SSD Paged Paged KVCache KVCache CPU/DRAM/SSD POSIX 并行存储系统下一级全局缓存

30. ◼ 不能充分利用3FS的并发读取性能？ ◼ 存储：辅存上的KVCache object如何组织？（映射关系，抽象粒度？） ◼ 接入：DFS的能力如何“优雅”地接入store？（写盘时机，与evict结合？）问题1：get每次只进行单个kvcache数据的读取， ◼ 解决思路：使用batchget操作，多线程同时读取多个kvcache数据。 ◼ 管理：逻辑层谁来负责管理3fs上的kvcache？（client or master管理？） ◼ 问题2：使用通用的POSIX接口需要经过fuse客户端，过程中存在多次上下文切换和数据拷贝 ◼ 解决思路：引入3fs高性能读写接口USRBIO支持，并进行优化，以实现高吞吐、低延迟的数据读写。 ◼ 问题3：client端负责元数据管理，带来了数据一致性问题，查询文件系统也会带来性能开销 ◼ 3FS kvcache object 解决思路：将ssd的metadata元数据信息管理从 client迁移至master，使master统一管理disk和 memory两种类型的元数据信息。

31. 特性 Inference Middleware RL Training Project Type Transfer KVCache Store SGLang Inference ✓ ✓ vLLM V0 Inference ✓ ✓ vLLM V1 Inference ✗ LMDeploy Inference ✓ ✓ RTP (Alibaba) Inference ✗ ✓ TBase (Ant) Middleware ✓ ✗ Dynamo Framework ✓ (w/ Nixl) ✗ LMCache Middleware ✓ ✗ Slime RL Training WIP WIP ✓ (w/ LMCache)

32. 基于Transfer Engine的SGLang PD分离基于Store的vLLM PD分离

33. 05

34. NVIDIA Dynamo • 被最广泛被使用的推理引擎，应用于各大云厂商 - vLLM • 黄仁勋在 GTC 2025 Keynote 中重点发布的分布式推理系统 – Dynamo • 其分布式推理实现基于 Mooncake 实现 • 其架构参考 Mooncake 设计并在文档中专门致谢 • xAI 底层推理引擎，被广泛应用于 DeepSeek 推理 - SGLang • 和 Mooncake 合作实现其分布式推理架构

35. 到产业推广从标杆应用 2024 年 3 月Kimi 凭借长文本处理能力出圈 Mooncake 上线并经受住流量剧增的考验 2024 年 11 月 Mooncake 开源，应用于阿里和蚂蚁的内部业务与 vLLM/SGLang 携手共建分离式大模型推理平台 2024 年 6 月 Mooncake 技术报告公布引发业界广泛讨论 icon Kimi 底层推理平台被 GTC 2025 Keynote 黄仁勋专门介绍的 Dynamo 分布式推理系统所使用 2025 年 2 月 USENIX FAST 最佳论文 kvcache-ai/Mooncake --月之暗面和清华大学共同发起，多家大模型和 Infra 厂商联合共建的开源项目 • 承载其近四千万的月活用户 • 以 KVCache 为中心的 P/D 分离架构 • 通过以存换算的思想，提升 Kimi 吞吐 75% 以上 + • 和国际最主流的开源推理框架共建分布式推理架构的标准参考实现 • vLLM/SGLang 均已完成初步对接 USENIX FAST 最佳论文 and more …

36.

37.