Mooncake 深度研究报告 - 分布式 KV Cache 存储与传输系统

01

项目概述与定位

Mooncake 是 Moonshot AI（Kimi）开发的 LLM 推理服务平台，其核心创新在于提出了"以 KVCache 为中心的分离式架构"（KVCache-centric disaggregated architecture）。这一架构不仅将 prefill（预填充）和 decode（解码）阶段分离到不同集群，更关键的是将 GPU 集群中大量闲置的 CPU、DRAM、SSD 和 RDMA 资源整合为一个统一的分布式 KVCache 池。[1][2]

2025 年 2 月，该论文在 USENIX FAST 2025 会议上获得 Erik Riedel Best Paper Award，标志着学术界对其技术贡献的认可。[11] 2026 年 2 月，Mooncake 正式加入 PyTorch 生态系统，成为 PyTorch 官方推荐的 KVCache 基础设施。[7]

核心问题

在大模型推理服务中，KVCache 的存储和传输已成为制约吞吐量和延迟的瓶颈。传统的单体推理架构将 prefill 和 decode 耦合在同一 GPU 上，导致 GPU 计算资源利用率低下。Mooncake 通过分离式架构，将 KVCache 从"计算的附属品"提升为"一等公民"。

1000 亿+

每日处理 Token 数

5358

GitHub Stars

100+

社区贡献者

9 家

支持的加速器厂商

02

整体架构分析

四层架构设计

Mooncake 的架构由四个核心组件构成，形成一个层次化的系统：[1][6]

Transfer Engine（传输层）

底层数据传输层，提供统一的批量数据传输接口。屏蔽底层网络协议差异，使上层组件无需关心数据是通过 RDMA、TCP 还是 CXL 传输的。

Mooncake Store（存储层）

分布式 KVCache 存储引擎，所有 KVCache 以分页块形式存储在分布式缓存池中，块大小通常为 16-512 个 token，支持多副本和去重。

Conductor（调度层）

全局调度器，维护全局前缀树，计算请求与节点缓存的重叠分数，通过结合实时节点负载的成本函数选择最优节点。

P2P Store（去中心化存储）

基于 Transfer Engine 构建的去中心化存储系统，专注于集群节点间临时对象（如 checkpoint 文件）的共享，使用 etcd 存储全局元数据。

架构图

Mooncake 整体架构 -- 四层结构

graph TB subgraph APP["应用层 Application Layer"] V["vLLM Connector"] S["SGLang HiCache"] T["TensorRT-LLM Backend"] LM["LMCache Connector"] LD["LMDeploy Backend"] end subgraph SCHED["调度层 Scheduling Layer"] C["Conductor 全局调度器"] C1["Cache-aware Prefill Scheduler"] C2["Load-balance Decode Scheduler"] C3["SLO-aware Early Rejection"] C --> C1 C --> C2 C --> C3 end subgraph STORE["存储层 Storage Layer"] MS["Mooncake Store"] MS1["MasterService 元数据管理"] MS2["ReplicaManager 副本管理"] MS3["AllocationStrategy 分配策略"] MS --> MS1 MS --> MS2 MS --> MS3 P2P["P2P Store"] P2P1["etcd Metadata"] P2P --> P2P1 end subgraph TRANS["传输层 Transport Layer"] TE["Transfer Engine"] MT["MultiTransport 多协议调度"] TD["Topology Discovery 拓扑发现"] TE --> MT TE --> TD RDMA["RDMA InfiniBand/RoCE"] TCP["TCP/IP"] NVME["NVMe-oF"] CXL["CXL/Shared Memory"] NVL["NVLink"] NAT["国产硬件适配器"] MT --> RDMA MT --> TCP MT --> NVME MT --> CXL MT --> NVL MT --> NAT end APP -.->|请求调度| SCHED SCHED ==>|KVCache 读写| STORE STORE ==>|数据传输| TRANS APP ==>|直接 KVCache 访问| STORE style APP fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0 style SCHED fill:#3d2e5c,stroke:#8b5cf6,color:#e2e8f0 style STORE fill:#1a3a4a,stroke:#06b6d4,color:#e2e8f0 style TRANS fill:#1a2e1a,stroke:#10b981,color:#e2e8f0 style V fill:#2a4a3a,stroke:#10b981,color:#e2e8f0 style S fill:#2a4a3a,stroke:#10b981,color:#e2e8f0 style T fill:#2a4a3a,stroke:#10b981,color:#e2e8f0 style LM fill:#2a4a3a,stroke:#10b981,color:#e2e8f0 style LD fill:#2a4a3a,stroke:#10b981,color:#e2e8f0

Transfer Engine 的 API 设计简洁而强大：installTransport 安装协议、openSegment 打开远程内存段、registerLocalMemory 注册本地内存、submitTransfer 提交批量传输请求。[6]

TransferRequest {
    OpCode: READ | WRITE
    source: void*
    target_id: SegmentID
    target_offset: uint64_t
    length: size_t
}

03

Transfer Engine：统一传输层

Transfer Engine 是 Mooncake 最核心的基础设施组件，其设计哲学是"一次编写，到处传输"。通过 MultiTransport 类实现了协议无关的传输抽象，传输选择基于目标段的协议元数据自动完成。[6][13]

协议支持矩阵

Transfer Engine 支持 14 种以上传输协议，覆盖从高性能数据中心到边缘设备的各种场景：[6]

功能特性	RDMA	TCP	NVMe-oF	CXL	NVLink	EFA	Ascend	HIP	MACA	Barex
零拷贝传输	✓	✗	✓	✓	✓	✓	✓	✓	✓	✓
多 NIC 聚合	✓	✗	✗	✗	✓	✓	✓	✗	✗	✗
拓扑感知	✓	✗	✗	✗	✓	✓	✓	✗	✗	✗
故障切换	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓
GPU Direct	✓	✗	✗	✗	✓	✓	✓	✓	✓	✓
跨节点	✓	✓	✓	✗	✓	✓	✓	✓	✓	✓

性能数据

拓扑感知路径选择是 Transfer Engine 的关键优化。它通过扫描 /sys/devices/system/node 发现 NUMA 节点，结合 cudaDeviceGetPCIBusId 获取 GPU 的 PCI 总线 ID，计算 PCI 距离和 NUMA 节点亲和度，选择距离最近的 HCA 设备。[1]

零拷贝传输通过 GPUDirect RDMA，数据可以直接从 GPU 内存传输到远程 GPU 内存，无需经过 CPU 中转。vLLM 博客数据显示，MooncakeTransferEngineConnector 使用 RDMA 仅需约 14 ms（TCP 约 810 ms），加速比达 58x。[8]

Transfer Engine 性能对比 -- 多 NIC 带宽聚合

xychart-beta title "Transfer Engine vs TCP 带宽对比 (40GB 数据传输)" x-axis ["4x200G RoCE", "8x400G RoCE"] y-axis "带宽 (GB/s)" 0 --> 200 bar [87, 190] bar [36, 41]

蓝色: Transfer Engine (RDMA) | 灰色: TCP | 40GB 传输测试（等效 LLaMA3-70B 128k KVCache）[1]

关键性能指标

在 8x400 Gbps RoCE 网络上实现 190 GB/s 的聚合带宽（TCP 约 41 GB/s，4.6x 提升）。事件驱动完成机制通过 Slice 结构实现，使用 memory_order_release/acquire 保证跨线程可见性。

TENT：下一代传输引擎

TENT（Transfer Engine NEXT）是 Mooncake TE 的下一代演进，2026 年 4 月发表于 FAISys 2025 会议。TENT 的核心创新是声明式切片喷射调度器，替代 Mooncake TE 的静态条带化策略。[4]

指标	TENT vs Mooncake TE	TENT vs NIXL
读吞吐量	+32.9%	一致优于
写吞吐量	+33.7%	一致优于
P99 延迟	降至 27.6%	一致优于
LLM Serving 吞吐	SGLang 吞吐量提升 1.36x，P90 TTFT 降低 26%
权重更新	加速 19.7%~26.1%

04

Mooncake Store：分布式 KVCache 引擎

Mooncake Store 的架构设计围绕三个核心目标：高可用、高性能和易扩展。[6][18]

多副本机制

ReplicateConfig 结构支持配置副本数量、软硬 pin 策略、首选 segment 等参数。三种副本类型覆盖不同存储层级：

MEMORY 副本

内存副本，通过 AllocatedBuffer 管理，访问速度最快，适用于热数据。

DISK 副本

磁盘副本，支持 FilePerKey、Bucket、OffsetAllocator 三种后端，适用于温数据。

LOCAL_DISK 副本

本地磁盘副本，client_id + transport_endpoint 标识，适用于冷数据。

Mooncake Store 副本管理流程

flowchart TD A([开始]) --> B[PutStart 请求] B --> C{Key 是否存在?} C -->|是| D[返回错误] C -->|否| E[分配副本空间] E --> E1[MEMORY: AllocatedBuffer] E --> E2[DISK: 文件路径] E --> E3[LOCAL_DISK: client_id] E1 & E2 & E3 --> F[设置状态: INITIALIZED] F --> G[客户端写入数据] G --> H[PutEnd 请求] H --> I[设置状态: COMPLETE] I --> J[更新元数据] J --> K([结束]) style A fill:#1a3a2a,stroke:#10b981,color:#e2e8f0 style K fill:#1a3a2a,stroke:#10b981,color:#e2e8f0 style B fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0 style D fill:#3d1a1a,stroke:#ef4444,color:#e2e8f0 style C fill:#3d3a1a,stroke:#f59e0b,color:#e2e8f0 style E fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0 style F fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0 style G fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0 style H fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0 style I fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0 style J fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0

分配策略与淘汰机制

分配策略：RandomAllocationStrategy 保证不同副本在不同 segment 上；FreeRatioFirstAllocationStrategy 采样 2N 个候选 segment，按空闲率排序选最优。Best-effort 语义确保当请求数量的副本无法满足时，尽可能多地分配。[6]

淘汰策略实现为 near-LRU：BatchEvict 方法有两轮淘汰，第一轮只淘汰无 soft pin 的对象，第二轮在必要时淘汰 soft pinned 的对象。

元数据管理支持多种后端：etcd、Redis、K8s Lease、HTTP 元数据服务器。MasterService 采用 1024 个分片的元数据存储，使用 SharedMutex 实现读写分离。[6]

高可用机制包括：etcd 作为 HA 后端、Snapshot/Restore 机制（fork 子进程序列化）、Hot Standby 状态机、分布式元数据分片、Client 心跳监控。

ObjectDataType 分类

Mooncake Store 支持按数据类型存储：KVCACHE、TENSOR、WEIGHT、SAMPLE、ACTIVATION、GRADIENT、OPTIMIZER_STATE、METADATA、GENERAL，为未来类型感知策略奠定基础。

05

Conductor：全局调度器设计

Conductor 的核心职责是在最大化有效吞吐量的同时满足延迟相关的 SLO。与传统基于请求数量的负载均衡不同，Mooncake 的调度考虑了更多维度。[6][1]

Cache-aware Prefill 调度

Conductor 维护一个全局前缀树（global prefix tree），计算请求与节点缓存的重叠分数。调度决策不仅考虑负载，还考虑：

前缀缓存命中长度：优先将请求路由到具有更长前缀缓存的 prefill 实例
可复用 KVCache 块分布：考虑 KVCache 块在集群中的分布
排队时间：结合前缀缓存带来的 prefill 时间和本地排队时间

Load-balance Decode 调度使用以下负载评分公式：

load_score = current_batch_size + k * waiting_queue_length

SLO 感知调度与早期拒绝

定义 l_ttft 和 l_tbt 分别为 TTFT（Time To First Token）和 TBT（Time Between Tokens）的 SLO 约束，通过比较实例上预测的最大 TTFT/TBT 与 SLO 约束来确定负载。[1]

Conductor 调度决策流程

flowchart TD A[请求到达] --> B[提取请求特征] B --> B1[前缀 hash] B --> B2[上下文长度] B --> B3[预估输出长度] B1 & B2 & B3 --> C[查询全局前缀树] C --> D[计算各 prefill 实例重叠分数] D --> E[计算成本函数] E --> F[选择最优 prefill 实例] F --> G[预测 decode 负载] G --> G1[系统级预测] G --> G2[请求级预测] G1 & G2 --> H{SLO 检查} H -->|TTFT & TBT 满足| I[接受请求] H -->|SLO 违规| J[早期拒绝] I --> K[执行 prefill] K --> L[流式传输 KVCache] L --> M[执行 decode] M --> N[返回结果] style A fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0 style H fill:#3d3a1a,stroke:#f59e0b,color:#e2e8f0 style I fill:#1a3a2a,stroke:#10b981,color:#e2e8f0 style J fill:#3d1a1a,stroke:#ef4444,color:#e2e8f0

预测式早期拒绝策略解决过载场景下的负载波动问题。核心思想是预测 prefill 阶段完成后的 decode 负载，据此决定是否接受请求。这包括请求级预测（预测每个请求的未知输出长度）和系统级预测（预测未来时间段的整体系统负载）。

开源状态

Conductor 目前以 RFC 形式存在于 GitHub Issues（#977），尚未完全开源。这一决策可能是出于商业竞争的考虑，但限制了社区的贡献和验证。[6]

06

生态集成分析

Mooncake 的生态集成策略是"深度嵌入，而非浅层对接"。它不是简单地提供一个传输 API，而是与各框架的核心机制深度耦合。[7]

vLLM 集成

vLLM 集成经历了三个阶段：[8][12][14]

MooncakeConnector（PD 分离传输层）：实现 vLLM 的 KVConnectorBase_V1 接口，采用 ZMQ 侧信道协调 prefill/decode 两端的 KV 传输
vLLM V1 Proxy Server（xPyD 分离代理）：实现 FastAPI 代理层，支持多个 prefill 实例和多个 decode 实例的 round-robin 调度
Mooncake Store 作为分布式 KV 池：2026 年 5 月最新进展，从点对点传输升级为分布式 KV 池

3.8x

吞吐量提升

46x

TTFT 降低

8.6x

端到端延迟降低

SGLang 集成

SGLang 集成同样深入：[9][25]

SGLang HiCache 三级缓存架构

graph LR subgraph L1["L1: GPU HBM"] G1["RadixTree"] G2["访问延迟: ~us"] G3["容量: 十GB级"] end subgraph L2["L2: Host DRAM"] H1["HiRadixTree 页表"] H2["访问延迟: ~100us"] H3["容量: 百GB级"] end subgraph L3["L3: Mooncake Store"] M1["分布式存储"] M2["访问延迟: ~ms"] M3["容量: TB级"] end L1 -->|溢出| L2 L2 -->|溢出| L3 style L1 fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0 style L2 fill:#1a3a2a,stroke:#10b981,color:#e2e8f0 style L3 fill:#2d1a4a,stroke:#8b5cf6,color:#e2e8f0

HiCache 三级缓存：GPU HBM（L1）、Host DRAM（L2）、Mooncake Store（L3）
EPD（Encode-Prefill-Decode）分离：将多模态编码器从语言模型节点解耦，利用 RDMA 引擎进行大型多模态 embedding 的零拷贝传输
Elastic Expert Parallelism：容错的专家并行推理

蚂蚁集团实测：DeepSeek-R1-671B 模型在 PD 分离部署下，缓存命中平均 TTFT 降低 84%。SGLang 官方测试 HiCache 实现 6x 吞吐提升和 80% TTFT 降低。[9]

其他框架集成

Mooncake 生态集成关系图

graph TB MC["Mooncake
Transfer Engine + Store"] V["vLLM
KV Connector + Store"] SG["SGLang
HiCache + EPD"] TRT["TensorRT-LLM
KVCache 传输后端"] LMC["LMCache
远程后端"] LMD["LMDeploy
PD 分离后端"] XLL["xLLM
混合 KV 管理"] NIXL["NIXL
后端插件"] FlexKV["FlexKV
分布式 KV 复用"] NVIDIA["NVIDIA CUDA"] AMD["AMD ROCm"] ASC["华为 Ascend"] HW["其他国产硬件"] MK["Moonshot AI"] ALI["阿里云"] ANT["蚂蚁集团"] JD["京东"] TX["腾讯"] MT["美团"] MC --- V MC --- SG MC --- TRT MC --- LMC MC --- LMD MC --- XLL NIXL -.->|后端插件| MC FlexKV -.->|传输依赖| MC NVIDIA -.-> MC AMD -.-> MC ASC -.-> MC HW -.-> MC MK ==>|开发| MC ALI ==>|采用| MC ANT ==>|采用| MC JD ==>|采用| MC TX ==>|采用| MC MT ==>|采用| MC style MC fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0,stroke-width:3px style V fill:#1a3a2a,stroke:#10b981,color:#e2e8f0 style SG fill:#1a3a2a,stroke:#10b981,color:#e2e8f0 style TRT fill:#1a3a2a,stroke:#10b981,color:#e2e8f0 style LMC fill:#1a3a2a,stroke:#10b981,color:#e2e8f0 style LMD fill:#1a3a2a,stroke:#10b981,color:#e2e8f0 style XLL fill:#1a3a2a,stroke:#10b981,color:#e2e8f0 style NIXL fill:#1a2e3a,stroke:#06b6d4,color:#e2e8f0 style FlexKV fill:#1a2e3a,stroke:#06b6d4,color:#e2e8f0 style NVIDIA fill:#3d3a1a,stroke:#f59e0b,color:#e2e8f0 style AMD fill:#3d3a1a,stroke:#f59e0b,color:#e2e8f0 style ASC fill:#3d3a1a,stroke:#f59e0b,color:#e2e8f0 style HW fill:#3d3a1a,stroke:#f59e0b,color:#e2e8f0 style MK fill:#2d1a4a,stroke:#8b5cf6,color:#e2e8f0 style ALI fill:#2d1a4a,stroke:#8b5cf6,color:#e2e8f0 style ANT fill:#2d1a4a,stroke:#8b5cf6,color:#e2e8f0 style JD fill:#2d1a4a,stroke:#8b5cf6,color:#e2e8f0 style TX fill:#2d1a4a,stroke:#8b5cf6,color:#e2e8f0 style MT fill:#2d1a4a,stroke:#8b5cf6,color:#e2e8f0

框架	集成方式	集成时间	关键特性
TensorRT-LLM	KVCache 传输后端	2024-12	PD 分离推理
LMCache	MooncakeStoreConnector	2025-05	远程存储后端
LMDeploy	PD 分离后端	2025-06	PD 分离推理
xLLM（京东）	混合 KV 管理	2025-08	基于 Mooncake 构建
NIXL	后端插件	2025-05	TE 作为传输后端
FlexKV（腾讯+NVIDIA）	传输依赖	2026-01	分布式 KV 复用

"Mooncake adds a vital layer of memory virtualization to the open-source AI stack." -- PyTorch 官方评价[7]

07

应用场景与生产实践

Kimi K2 大规模部署

Kimi K2 是 Moonshot AI 的约 1T 参数 MoE 模型，采用 384 个专家（每 token 激活 8 个），支持 128K token 上下文窗口。Mooncake 支持 Kimi K2 在 128 块 H200 GPU 上的 PD 分离部署和大规模专家并行。[10][25]

224k

tokens/sec 预填充吞吐

288k

tokens/sec 解码吞吐

7x

权重传输加速（53s -> 7.2s）

128

H200 GPU 集群

在强化学习训练场景中，Mooncake TransferEngine 实现基于 RDMA 的 P2P 权重更新：利用源端 CPU 引擎副本和 P2P RDMA 传输，将 1T 参数 Kimi-K2 的权重传输时间从 53 秒加速到 7.2 秒。代价仅为每个训练 rank 额外一个推理引擎副本（32G CPU 内存）。[25]

云厂商实践

Cloudflare

使用 Mooncake Transfer Engine 和 Store，利用 RDMA 协议实现 GPU 机器间直接内存传输，消除了集群内会话感知路由需求，实现更均匀的负载均衡。[7]

阿里云 RBG

将 Mooncake 与 SGLang RBG 结合，构建云原生 LLM 推理平台。[15]

配置	平均 TTFT	TTFT 变化	吞吐量 (tok/s)	吞吐变化
GPU Only 基线	5.91s	--	6576.85	--
+L2 DRAM	3.77s	-36.2%	10054.21	+52.89%
+L3 Mooncake	2.58s	-56.3%	15022.80	+49.41%

Qwen3-235B 多轮对话场景 [15]

行业采用者

Mooncake 的采用者包括：Moonshot AI、阿里巴巴云、蚂蚁集团、京东、腾讯、美团、趋境科技、LightSeek Foundation。[7]

08

竞争格局分析

Mooncake 的竞品主要来自三个方向，每个方向代表了不同的技术路线和生态策略。[13]

NVIDIA 生态

NCCL：集合通信模式不适合 P2P KV 传输，存在性能差和大故障域问题

NIXL

策略：通过 TensorRT-LLM 和 NIXL 构建封闭生态

学术项目

vLLM P2P 传输：针对特定场景的优化
SGLang RadixAttention：单点优化到系统化
差异：从单点优化到系统化，而 Mooncake 从一开始就是系统化设计

云厂商方案

阿里云 RBG：基于云基础设施的方案
AWS 推理服务：与云服务深度集成
劣势：绑定特定云平台，Mooncake 的跨平台特性使其可以在任何环境中部署

本质差异

Mooncake 是"从 KVCache 出发"的架构设计，而竞品大多是"从计算出发"的优化。这种出发点的不同，决定了它们在 KVCache 管理上的深度和广度。

09

横纵交汇洞察（五问分析）

历史如何塑造了当下的竞争位置？

Mooncake 的诞生源于 Moonshot AI 在 Kimi 推理服务中遇到的真实痛点。2024 年 6 月，当大多数团队还在优化单机推理效率时，Moonshot AI 已经意识到 KVCache 的存储和传输将成为大规模推理的瓶颈。这一早期洞察使 Mooncake 在 KVCache-centric 架构上建立了先发优势。[2]

与学术驱动的项目不同，Mooncake 从一开始就是为生产环境设计的。它在 Moonshot AI 的数千节点集群上经过了实战检验，处理超过 1000 亿 token/天的生产负载。这种"从生产中来，到生产中去"的路径，使 Mooncake 在可靠性、性能和易用性上具有天然优势。

当前优势的历史根源可以追溯到 2024 年 7 月的技术报告发布。在这个时间点，Moonshot AI 做出了两个关键决策：(1) 将 KVCache 提升为一等公民；(2) 选择开放生态路线。这两个决策的组合效应是：Mooncake 既有了核心技术的深度，又有了生态集成的广度。

当前劣势的历史根源是 Moonshot AI 在开源策略上的保守。Conductor 调度器尚未完全开源，部分传输协议的性能数据未公开。这种策略在保护商业秘密的同时，也限制了社区的深度参与。

未来三个剧本

最可能的剧本：成为事实标准

Mooncake 有望成为 KVCache 基础设施的事实标准，类似于 Kubernetes 在容器编排领域的地位。

PyTorch Ecosystem 成员身份
8 家行业采用者
16 个里程碑的路线图
TENT V1.1 计划 2026 Q2 发布

最危险的剧本：被封闭生态取代

如果云厂商推出深度集成的 KVCache 解决方案并与其云服务绑定，Mooncake 的跨平台优势可能被削弱。

云厂商的资源和市场影响力
用户对云服务的依赖性
Mooncake 在云环境中的性能优化空间

最乐观的剧本：推动标准化

Mooncake 有可能推动 KVCache 管理的标准化，建立开放的 KVCache 互操作协议，实现"一次生成，到处复用"。

广泛的硬件支持（9 家加速器厂商）
多框架集成
PyTorch Ecosystem 的标准化推动

10

总结与展望

核心优势

架构创新性：KVCache-centric 分离式架构将 KVCache 从"计算的附属品"提升为"一等公民"
传输性能：Transfer Engine 在 8x400 Gbps RoCE 网络上实现 190 GB/s 聚合带宽，比 TCP 快 4.6x
生态广度：与 vLLM、SGLang、TensorRT-LLM、LMCache、LMDeploy 等主流框架深度集成
硬件覆盖：支持 9 家加速器厂商和 6 种网络 Fabric，是真正的跨平台方案
生产验证：在 Moonshot AI 的数千节点集群上经过实战检验，每日处理超过 1000 亿 token
社区活跃：GitHub 5358 stars，100+ 贡献者，PyTorch Ecosystem 成员

主要局限

Conductor 未完全开源：全局调度器是核心组件，但目前以 RFC 形式存在
独立基准测试缺乏：性能数据主要来自官方论文和文档
超大规模集群数据有限：在万卡以上的集群中，调度性能和稳定性数据有限
国产硬件性能数据不完整：部分传输协议的具体性能数据未公开

技术演进方向

TENT V1.1（计划 2026 Q2 发布）：引入声明式切片喷射调度器，进一步提升传输性能[4]
跨数据中心推理：PrfaaS 论文提出 Prefill-as-a-Service 概念，实现 54% 更高服务吞吐量，P90 TTFT 降低 64%[5]
Store V3 演进：更高效的存储后端和淘汰策略，ObjectDataType 分类为类型感知策略奠定基础
RL 训练支持：Mooncake RL 模块的出现，表明 Mooncake 正在向训练场景扩展
专家并行支持：Mooncake EP 模块提供集合通信后端和专家并行内核

行业影响

Mooncake 的成功实践正在改变 LLM 推理的架构范式。从"以计算为中心"到"以 KVCache 为中心"的转变，不仅是技术层面的创新，更是思维方式的变革。随着 LLM 模型规模的持续增长和推理需求的爆发式增长，KVCache 管理将成为越来越关键的基础设施。

11

参考来源

[1]

Mooncake: Trading More Storage for Less Computation -- FAST'25 Best Paper
usenix.org/conference/fast25/presentation/qin conference_paper
[2]

Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving (arXiv)
arxiv.org/abs/2407.00079 preprint
[3]

Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving (ACM TOS)
doi.org/10.1145/3773772 journal_paper
[4]

TENT: A Declarative Slice Spraying Engine for Performant and Resilient Data Movement
arxiv.org/abs/2604.00368 preprint
[5]

Prefill-as-a-Service: KVCache of Next-Generation Models Could Go Cross-Datacenter
arxiv.org/abs/2604.15039 preprint
[6]

Mooncake GitHub Repository (kvcache-ai/Mooncake)
github.com/kvcache-ai/Mooncake code_repo
[7]

Mooncake Joins PyTorch Ecosystem -- PyTorch Official Blog
pytorch.org/blog/mooncake-joins-pytorch-ecosystem blog
[8]

Serving Agentic Workloads at Scale with vLLM x Mooncake
vllm.ai/blog/mooncake-store blog
[9]

SGLang HiCache: Fast Hierarchical KV Caching -- LMSYS Blog
lmsys.org/blog/2025-09-10-sglang-hicache blog
[10]

Kimi K2 Large-Scale Expert Parallelism Deployment -- LMSYS Blog
lmsys.org/blog/2025-07-20-k2-large-scale-ep blog
[11]

Tsinghua University: Best Paper Award at FAST 2025
tsinghua.edu.cn news
[12]

vLLM RFC: Implement disaggregated prefilling using Mooncake
github.com/vllm-project/vllm/issues/10727 issue
[13]

Everything You Want to Know about KV Cache Transfer Engine (UCCL)
uccl-project.github.io blog
[14]

vLLM-Omni MooncakeTransferEngineConnector Documentation
docs.vllm.ai documentation
[15]

Alibaba Cloud: Production-Grade Cloud-Native LLM Inference with SGLang RBG + Mooncake
alibabacloud.com blog
[16]

Mooncake Project Overall Roadmap (GitHub Issue #1883)
github.com/kvcache-ai/Mooncake/issues/1883 issue
[17]

Mooncake Transfer Engine NEXT (TENT) Roadmap
github.com/kvcache-ai/Mooncake/issues/1058 issue
[18]

Mooncake Official Documentation
kvcache-ai.github.io/Mooncake documentation
[19]

FAST'25 Paper PDF (Mooncake)
usenix.org/system/files/fast25-qin.pdf conference_paper
[20]

ACM TOS Paper PDF (Mooncake)
madsys.cs.tsinghua.edu.cn journal_paper
[21]

FlexKV: Distributed KV Store (Tencent + NVIDIA) with Mooncake Support
github.com/taco-project/FlexKV code_repo
[22]

TensorRT-LLM Mooncake Integration
github.com/NVIDIA/TensorRT-LLM code_repo
[23]

NIXL Mooncake Transfer Engine Plugin
github.com/ai-dynamo/nixl code_repo
[24]

USENIX FAST 2025 Paper Listing (Cool Papers)
papers.cool aggregator
[25]

SGLang RDMA P2P Weight Transfer with Mooncake TransferEngine
lmsys.org/blog/2026-04-29-p2p-update blog

Mooncake分布式 KV Cache 存储与传输系统

项目概述与定位

整体架构分析

四层架构设计

Transfer Engine（传输层）

Mooncake Store（存储层）

Conductor（调度层）

P2P Store（去中心化存储）

架构图

Transfer Engine：统一传输层

协议支持矩阵

性能数据

TENT：下一代传输引擎

Mooncake Store：分布式 KVCache 引擎

多副本机制

MEMORY 副本

DISK 副本

LOCAL_DISK 副本

分配策略与淘汰机制

Conductor：全局调度器设计

Cache-aware Prefill 调度

SLO 感知调度与早期拒绝

生态集成分析

vLLM 集成

SGLang 集成

其他框架集成

应用场景与生产实践

Kimi K2 大规模部署

云厂商实践

Cloudflare

阿里云 RBG

竞争格局分析

NVIDIA 生态

学术项目

云厂商方案

横纵交汇洞察（五问分析）

历史如何塑造了当下的竞争位置？

未来三个剧本

最可能的剧本：成为事实标准

最危险的剧本：被封闭生态取代

最乐观的剧本：推动标准化

总结与展望

核心优势

主要局限

技术演进方向

参考来源

Mooncake
分布式 KV Cache 存储与传输系统