我之前在 verl 里见过两种 vLLM offload 级别，后来又接触到 vLLM 的 KV offloading。再往 Mooncake 看，项目里似乎已经有 GDS。于是看到 vLLM Issue #48504 还要做 “GDS + KV offloading” 时，一个很自然的困惑出现了：这些机制是不是在重复做同一件事？

真正需要拆开的不是两个实现，而是三种不同的 offload 语义，以及两类不同的 GPU Direct。本文沿着实际数据路径，解释当前 vLLM 会自动做什么、Mooncake 怎样通过 Connector、Store 与 Transfer Engine 的解耦透明接入 GDS，以及 #48504 为什么仍然有独立价值。

最初的问题很直接：Mooncake 管理 KV Cache，那么“KV Cache 的元数据”能否选择放在内存或 SSD？继续追问后才发现，元数据这个词把几种完全不同的东西揉在了一起：PagedAttention 的 Block Table、Master 保存的全局副本目录、SSD backend 保存的文件位置索引，以及为了故障恢复生成的 snapshot。

只有先回答“哪一种元数据真正负责定位 KV Cache 数据页”，才有可能讨论它应该放在哪里。本文基于 Mooncake 固定版本 0518784d，沿代码中的两级定位链路展开，再解释 Master snapshot 如何以较短在线停顿保存控制面状态，以及它为什么不能替代 KV payload 的持久化。

上一篇文章从 FAST’25 论文出发，解释了 P/D 解耦、分布式 KV Cache 与调度机制。论文读懂以后，打开代码仓却很容易再次迷路：Connector、Mooncake Store、Transfer Engine、TENT 看起来像四个并列组件，实际却跨越 vLLM 与 Mooncake 两个仓库，并分别承担框架适配、对象管理、字节搬运和新传输内核。

本文固定在 Mooncake 6a00c353 与 vLLM 5bbc58c0，从仓库结构、请求流、时序和关键类关系重新组织这些概念，最后给出一套可重复的源码走读与开发 SOP。

把 KV Cache 放进 SSD 并不难，难的是让它取回来仍比重新 Prefill 更划算。GPU Direct Storage 已经能让数据绕过 Host DRAM，但每个 I/O 仍由 CPU 发起；Paged KV Cache 又会把一次长前缀恢复拆成海量小而散的请求。SSD 的标称带宽于是还没有用满，GPU 已经先停下来等数据。

Tutti 的核心不是再加一级缓存，而是重写 HBM 与 NVMe 之间的运行时路径：CPU 保留前缀索引和对象映射，却退出逐块 I/O 的数据与控制关键路径；GPU 通过对象化批处理、gio_uring 和 slack-aware 调度直接驱动本地 SSD。读完本文，应该能判断这三部分分别消除了什么瓶颈，以及论文的“接近 DRAM”结论在哪些条件下成立。

手里已经有一套面向 NPU 的 NDS send/receive 接口，下一步是把它接入 Mooncake。乍看之下，这只是把 GDS 的 cuFile* 调用替换为 NDS API；但沿源码真正走一遍后，会遇到两个容易误判的事实：Mooncake 同时保留了新旧两代 GDS 路径，而 Mooncake Store 的磁盘副本读写目前又绕开了它们。

因此，接入点不应先选旧 NVMeoFTransport，也不能只新增一个 transport 就宣称 Store 已经获得 NPU 直读 SSD。更稳妥的路径是：先把 NDS 实现为 TENT 的 NdsTransport，复用其选择、批次、状态与回退机制；再单独改造 Store 的文件副本路径。

PagedAttention 是 vLLM 高吞吐推理的核心内存管理机制。它没有改变 Attention 的数学公式，也没有消灭 KV Cache，而是把每条请求持续增长的 KV Cache 切成固定大小的 Block，通过 Block Table 将逻辑连续的 Token 映射到不连续的 GPU 物理块。

它解决的核心矛盾是：LLM 服务需要保留大量、长度未知且生命周期不同的 KV Cache，但 GPU 显存有限，传统连续分配容易产生预留浪费和碎片。 更高的显存利用率允许 vLLM 同时容纳更多请求，进而扩大 Batch、提高吞吐并降低高负载下的排队延迟。

Mooncake Store 的 KV Cache 管理很像 PagedAttention：两者都采用 切块、间接寻址、按块复用与淘汰。但它们解决的不是同一层问题。PagedAttention 管理单个推理实例内的 GPU KV Block；Mooncake Store 管理跨请求、跨实例、跨节点的 DRAM 与 SSD 副本。

理解二者关系的关键，是先区分 页表 与 KV 数据页：页表记录当前请求的逻辑块对应哪个 GPU 物理块，真正跨显存、内存和 SSD 分层迁移的是 K/V 张量数据，而不是页表本身。

但只理解“Master 管元数据、Client 传数据”仍然不够。本文沿 Mooncake 固定版本 bfca1ce2af8419c50dc8d464820a95d97d43c930 追到 store_c.cpp、real_client.cpp、client_service.cpp、master_service.cpp 与 transfer_task.cpp，解释每个设计判断究竟由哪段代码实现。

Mooncake 是 Moonshot AI 为 Kimi 长上下文服务设计的 KVCache-centric 推理架构。它不再把 KV Cache 视为某张 GPU 上随请求消失的临时副产物，而是把它提升为跨 Prefill、Decode、CPU DRAM、SSD 与高速网络统一调度的系统资源。本文先用直觉解释，再从 P/D 解耦、Mooncake Store 与 Transfer Engine、缓存感知调度、Chunked Pipeline Parallelism 四个机制展开，并明确论文、当前开源代码与教学重构之间的证据边界。

本文调研 2021—2026 年 SIGCOMM、NSDI、OSDI、SOSP、EuroSys、USENIX ATC、FAST、MLSys、ISCA、HPCA、ICML 和 NeurIPS 中与长序列、大规模 LLM 推理及 KV cache 管理直接相关的工作，重点关注分页、压缩、稀疏选择、复用、分层存储、卸载、Prefill/Decode 解耦、远程传输、GPU Direct Storage、CXL 和网络内计算。

检索截至 2026-08-24。会议归属以官方 proceedings 或会议程序为准；仅有 arXiv 或项目技术报告的工作被单独列出，不能与正式顶会论文混为一谈。