摘要：大模型推理中的 KV Cache 既是计算结果，也是影响首 Token 延迟、吞吐量和显存利用率的关键资源。SGLang HiCache 将前缀缓存组织为 GPU、CPU 与外部存储三级体系；Mooncake 则提供跨节点数据传输和分布式存储能力。两者分别解决缓存管理与分布式基础设施问题，可独立使用，也可组合为跨实例 KV Cache 复用架构。
关键词：SGLang、HiCache、Mooncake、KV Cache、RadixAttention、PD 分离、RDMA、分布式推理
1. 背景：KV Cache 为什么需要分层
大语言模型推理通常包含 Prefill（预填充）与 Decode（逐 Token 解码）两个阶段。Prefill 处理输入上下文，生成注意力计算所需的 KV Cache。对于共享相同 Token 前缀的请求，可以直接复用已经计算过的前缀 KV，避免重复执行相同的 Prefill 计算。
SGLang 的 RadixAttention 通过前缀树组织并复用 GPU 显存中的 KV Cache。但 GPU 显存还要存放模型权重、运行时工作区和活跃请求状态，无法无限保留历史上下文。当多个会话交替运行、长文档被反复查询，或者历史前缀持续增长时，旧 KV 数据可能被驱逐出显存。缺少下层备份时，相同前缀再次出现就需要重新计算。
分层缓存利用更廉价、容量更大的存储介质保留部分计算结果，并在访问时按需恢复。但扩大缓存池容量不等于提高单次请求的最大上下文长度。前者决定可跨请求保留多少 KV 数据；后者仍由模型与推理引擎的上下文限制决定。[1]
2. HiCache：推理实例内部的分层缓存管理
HiCache 是 SGLang 在 RadixAttention 基础上构建的分层 KV Cache 管理机制。典型体系包括三个层级：
| 层级 | 典型存储位置 | 主要职责 | 特性 |
|---|---|---|---|
| L1 | GPU 显存 | 直接参与模型计算、承载热点前缀 | 延迟最低，容量受显存约束 |
| L2 | 推理节点 CPU 内存 | 保存部分历史 KV，供本地恢复 | 容量更大，但存在 PCIe/NVLink 等搬运开销 |
| L3 | 外部或分布式存储 | 扩大缓存范围、支持跨实例复用 | 容量与共享范围更大，受网络和存储性能影响 |
┌──────────────────────────┐
│ SGLang 实例 │
│ │
请求 Token 前缀 ──→ │ L1：GPU KV Cache │
│ ↕ │
│ L2：CPU KV Cache │
└────────────┬─────────────┘
↕
L3：外部共享 KV 存储
L1、L2 通常属于具体推理实例的缓存空间；共享 L3 则可以向不同实例提供缓存数据。启用 HiCache 并不要求配置 L3，单机 GPU + CPU 两级缓存也是完整、有效的使用方式。[1][2]
2.1 缓存命中与数据恢复
HiCache 通过前缀树元数据查找请求与历史 KV 数据之间的匹配关系。请求到达后，通常先匹配 L1 和 L2；启用 L3 时，再尝试检索外部缓存。命中的数据需要在 GPU 中可用，未命中的后缀则继续由 Prefill 计算。计算完成后，按照写入策略保留新生成的缓存。[1]
请求进入 → 前缀匹配
├─ 命中 L1 → 直接复用 GPU KV
├─ 命中 L2 → CPU → GPU → 继续推理
├─ 命中 L3 → L3 → 本地缓存/GPU → 继续推理
└─ 未命中 → 重新 Prefill
缓存匹配要求 Token 前缀一致、KV 表示兼容。模型版本、分词方式、聊天模板或 KV 布局发生变化，都可能影响可复用性。跨实例共享还涉及缓存键、并行切分和元数据的一致性，不能仅凭文本看起来相同就认定 KV 可直接互换。
2.2 写入策略与取舍
HiCache 支持不同的写入策略，常见方式包括：
| 写入策略 | 行为 | 主要收益 | 主要代价 |
|---|---|---|---|
write_through |
尽早向下层备份 | 提高后续恢复机会 | 额外写入流量与下层空间占用 |
write_back |
上层逐出时再写入 | 减少不必要的备份 | 逐出路径可能承担同步备份延迟 |
write_through_selective |
按热度选择性备份 | 聚焦高价值前缀 | 冷前缀可能没有下层副本 |
不同策略影响缓存存放时间、下层占用、写入带宽与逐出行为，并不改变 KV Cache 的数学内容。实际效果取决于访问局部性和传输性能。[1]
3. Mooncake：面向集群的数据传输与共享存储
Mooncake 是面向大模型分离式推理的通信和存储基础设施。HiCache 负责缓存层级管理，Mooncake 的核心能力则是跨进程、跨节点传输数据，以及将多个节点提供的存储资源组织成共享数据池。[3]
3.1 Mooncake Transfer Engine：传输数据
Transfer Engine 是数据传输组件，可在注册的内存区域之间执行异步批量读写。典型应用是在 Prefill 与 Decode 实例之间传输 KV 块。支持的传输路径取决于部署环境及版本，包括 RDMA、TCP、共享内存和部分加速器或存储互连方式；Mooncake 不等同于单一 RDMA 协议。[3][4]
┌────────────────┐ KV 数据传输 ┌────────────────┐
│ Prefill 实例 │ ─────────────────────→ │ Decode 实例 │
│ 计算输入上下文 │ Transfer Engine │ 继续生成 Token │
└────────────────┘ └────────────────┘
这里的核心目标是让不同计算阶段可以独立扩展和调度。只有 Transfer Engine，并不意味着自动拥有一个可长期查询、跨实例共享的 L3 KV 存储池。
3.2 Mooncake Store：保存数据
Mooncake Store 提供分布式对象存储能力，可将多个节点贡献的内存或其他存储资源整合为共享池。典型架构区分控制面与数据面：控制面管理对象位置、分配和生命周期；实际 KV 数据由客户端借助传输层直接搬运，不经元数据服务转发。[3][5]
SGLang A：L1 / L2 ──┐
├── Mooncake Store（共享 L3）
SGLang B：L1 / L2 ──┘ │
├─ 元数据与对象定位
└─ 分布式存储资源
当 Mooncake Store 作为 HiCache 的 L3 后端时，HiCache 负责前缀匹配、缓存层级和预取决策；Mooncake Store 提供可共享的数据对象及其存取能力。多个推理实例因此有机会复用其他实例已经生成的 KV Cache。[2][6]
3.3 组件关系：并非二选一
Mooncake 的两条典型集成路径相互独立：
- HiCache + Mooncake Store：侧重共享 L3 缓存留存与跨实例前缀复用。
- SGLang PD 分离 + Mooncake Transfer Engine：侧重 Prefill、Decode 实例之间的 KV 迁移。
同一集群可以同时使用两条路径，也可以只启用其中一条。Mooncake Store 的底层数据传输可利用 Transfer Engine，但“Store 作为缓存后端”与“Transfer Engine 作为 PD 传输后端”是不同的上层功能入口。[6]
4. 从单机到集群：四类典型架构
4.1 单机：GPU + CPU 分层缓存
单个推理实例通过 HiCache 将部分历史 KV 从 GPU 扩展至 CPU 内存。该架构不需要共享存储集群，适用于单实例长对话、长文档重复查询和 GPU 缓存淘汰后的恢复。
主要收益是降低历史前缀重新计算的频率；主要代价是主机内存占用、GPU/CPU 数据搬运，以及缓存元数据管理。若热点前缀始终留在 GPU，L2 可能很少命中，增加 L2 容量不一定带来收益。
4.2 多机多副本：各实例独立缓存
多台推理服务器也可以各自运行独立的 L1 或 L1+L2 缓存，再由网关分流请求。多机部署本身不要求使用 Mooncake。
在这种模式下，同一前缀可能在不同副本上重复 Prefill；通过会话粘性或前缀感知路由可以降低重复计算，但无法天然获得全局共享缓存。
4.3 多机共享前缀：HiCache + Mooncake Store
当长前缀频繁跨实例访问时，共享 L3 有机会降低重复计算。实例 A 计算并写入某段 KV 后，实例 B 可以在满足兼容性和命中条件时，通过 HiCache 从 Mooncake Store 恢复该数据。
该模式的性能收益取决于共享前缀比例、L3 访问延迟、网络带宽、写入冗余及缓存感知路由。跨节点取回 KV 并非零成本；如果传输耗时超过重新计算成本，性能可能不升反降。
4.4 PD 分离：Mooncake Transfer Engine
Prefill 偏向大规模并行计算，Decode 更关注连续 Token 生成、KV 访问与延迟稳定性。PD 分离允许两个阶段分别部署和扩容，并通过 Transfer Engine 传递 KV Cache。[6]
该架构与共享 L3 的目标不同：PD 分离解决计算阶段之间的资源与数据流问题，Mooncake Store 解决跨实例 KV 数据留存及复用问题。两者可以叠加，但没有必然依赖关系。
5. HiCache 与 Mooncake 对比
| 维度 | SGLang HiCache | Mooncake Transfer Engine | Mooncake Store |
|---|---|---|---|
| 核心角色 | 分层缓存管理 | 高性能数据传输 | 分布式共享存储 |
| 主要关注点 | 前缀匹配、缓存驻留、淘汰与预取 | 端点间数据搬运 | 对象定位、存放与生命周期 |
| 单机 GPU/CPU KV 扩容 | 核心能力 | 非主要职责 | 非必要组件 |
| 跨实例 KV 共享 | 依赖共享后端 | 提供传输能力 | 提供共享 L3 数据池 |
| PD 分离 | 可配合整个推理体系 | 典型使用场景 | 非必需 |
| 性能约束 | 命中率、CPU 内存、PCIe 搬运 | 网络带宽、拓扑、传输并发 | 后端容量、元数据与访问延迟 |
HiCache 更接近推理引擎内部的缓存控制与层级管理；Mooncake 更接近推理系统下方的分布式传输与存储基础设施。两者处于不同抽象层，不能简单地将一个归为“单机产品”、另一个归为“多机产品”。
6. 性能收益与工程成本
6.1 主要收益
降低重复 Prefill：请求共享的前缀越长、命中越稳定，避免的重复计算通常越多。扩大缓存有效工作集：CPU 和外部存储可保存部分无法长期驻留 GPU 的历史 KV。提升集群资源利用率：跨实例共享能够减少重复缓存构建；PD 分离可使 Prefill 与 Decode 分别扩容。
6.2 主要成本
数据传输并非免费：L2 命中需要从主机恢复到设备，L3 命中还引入网络或存储访问。共享一致性更复杂：模型版本、Token 前缀、缓存元数据及并行布局需要满足兼容条件。运维面扩大：分布式存储引入控制面、容量回收、网络拓扑、故障恢复和监控等新问题。
6.3 效果评估指标
- 各层命中量与命中率：区分 L1、L2、L3，避免只观察总体缓存命中率。
- TTFT（首 Token 延迟）：衡量前缀缓存复用是否真正缩短等待。
- ITL（Token 间延迟）与吞吐量：观察 PD 分离后 Decode 是否更平稳。
- 缓存备份和恢复字节量：估算 PCIe 与网络流量开销。
- 缓存逐出和丢弃量：识别写入未完成、缓存压力或复用失败。
- 资源占用：GPU 显存、CPU 内存、共享存储容量及网络带宽。
缓存命中率提高并不必然意味着端到端延迟降低，最终效果需要结合节省的计算与搬运代价分析。
7. 常见理解误区
误区一：多机推理必须使用 Mooncake。 多机副本扩容、张量并行和流水线并行可以采用其他通信或调度方案；只有涉及特定共享存储或数据传输需求时，Mooncake 才成为可选组件。
误区二：Mooncake 就是远程 KV Cache。 Mooncake 同时包含 Transfer Engine 与 Store。前者负责数据传输，不等于具备长期可查询的共享缓存；后者才提供分布式对象存储能力。
误区三：HiCache 只能用于单机。 HiCache 的 L1/L2 通常是实例本地缓存，但可以通过 L3 后端连接分布式存储，形成跨实例复用体系。
误区四：L2 必须大于 L1。 更大的 L2 有利于保存更多历史 KV，但这不是正确性要求。下层缓存的有效容量取决于实际访问模式；只有命中并避免重复计算时才体现收益。
误区五：L2/L3 容量增加会自动提升单请求上下文上限。 分层缓存扩大的是可跨请求保存的 KV 总量，单请求最大上下文仍受模型和推理框架限制。
误区六：TP=4 的四份缓存可直接相加为四倍逻辑 Token。 在按张量并行切分 KV 的模型中，不同 rank 可能保存同一批逻辑 Token 的不同分片。日志中各 rank 报告的相同逻辑 Token 容量，不应直接再次相加；实际可缓存长度要结合分片方式与每 rank 容量判断。
8. 总结
HiCache 决定 KV Cache 如何匹配、保留和跨层恢复；Mooncake 决定 KV 数据如何在节点间高效搬运，以及如何组织成分布式共享存储。
单机容量扩展可以只使用 HiCache；多机副本扩容不必引入共享 L3；跨实例历史前缀复用可以采用 HiCache + Mooncake Store；PD 分离则可以通过 Mooncake Transfer Engine 实现 KV 迁移。随着推理服务从单实例发展为集群化架构，缓存层级管理与分布式数据基础设施的协同，成为控制 Prefill 重算成本和提升资源利用率的重要技术方向。
参考资料
[1] SGLang，HiCache System Design and Optimization：https://docs.sglang.com.cn/advanced_features/hicache_design.html
[2] Mooncake，Mooncake x SGLang HiCache System Design：https://kvcache-ai.github.io/Mooncake/design/hicache-design.html
[3] Mooncake，Mooncake Architecture：https://kvcache-ai.github.io/Mooncake/design/architecture.html
[4] Mooncake，Transfer Engine：https://kvcache-ai.github.io/Mooncake/design/transfer-engine/index.html
[5] Mooncake，Mooncake Store：https://kvcache-ai.github.io/Mooncake/design/store/mooncake-store.html
[6] Mooncake，Mooncake x SGLang Integration：https://kvcache-ai.github.io/Mooncake/deployment/integrations/sglang/
资料核对日期：2026 年 10 月 30 日。具体接口、参数及性能特征可能随软件版本变化。