导言
最初的问题很直接：Mooncake 管理 KV Cache，那么“KV Cache 的元数据”能否选择放在内存或 SSD？继续追问后才发现，元数据这个词把几种完全不同的东西揉在了一起：PagedAttention 的 Block Table、Master 保存的全局副本目录、SSD backend 保存的文件位置索引，以及为了故障恢复生成的 snapshot。
只有先回答“哪一种元数据真正负责定位 KV Cache 数据页”，才有可能讨论它应该放在哪里。本文基于 Mooncake 固定版本 0518784d，沿代码中的两级定位链路展开，再解释 Master snapshot 如何以较短在线停顿保存控制面状态，以及它为什么不能替代 KV payload 的持久化。
导言
我最开始想确认的是一个很具体的问题：Mooncake Classic TE 和 TENT 打开的究竟都是文件系统普通文件，还是也能把 /dev/nvme0n1 这样的 SSD 裸块设备交给 GDS？源码里两边都会调用 open(path, O_DIRECT)，NVIDIA cuFile 又确实接受 device fd，看起来答案应该是“可以”。继续向上追到 Segment 层后，结论却发生了分叉。
这篇文章把这条调用链从头串起来：先解释普通文件、块设备、S_ISREG 与 S_ISBLK，再看 GDS 提供了什么 API、Mooncake 实际用了什么，最后落到 cuFileBatchIOSubmit 的同一组参数为什么在两个场景里具有不同含义。核心判断是：GDS 统一了 I/O 接口，却没有替 Mooncake 补上块设备的容量、对齐、越界和独占语义。
导言
看到“应用必须持有 Transport*”时，我真正卡住的是：持有到底是什么意思？为什么直接保存一个后端指针就能工作，统一的 TransferEngine 反而走不通？
把这个词拆开后，Classic 与 TENT 的差异就不再只是两套接口。Classic 的公共 Batch 先于后端选择而创建，后端私有状态缺少稳定的安放位置；TENT 则在选定后端后，为每个 transport 创建独立 SubBatch，再由统一运行时协调提交、状态与回收。
因此，判断一个 Engine 是否容易扩展多个后端，不能只数有多少个 Transport 子类。真正要问的是：后端的私有状态放在哪里，由谁创建，又由谁保证它完成整个异步生命周期。
导言
在分析 Mooncake 的 NDS 接入位置时，经典 NVMeoFTransport 很容易被误认为 TENT GdsTransport 的前一版：二者都注册 buffer 和文件 handle，都使用 cuFile Batch API，也都维护异步完成事件。
但这条旧路径真正特殊的地方不在 cuFile，而在 Batch 所有权。可运行的调用必须直接持有 Transport*，并始终走 xport->allocateBatchID → xport->submitTransfer → xport->getTransferStatus → xport->freeBatchID。一旦换成 engine->allocateBatchID → engine->submitTransfer，批次便由 MultiTransport 创建，NVMeoFTransport 无法附加私有 descriptor，最终返回 NotImplemented。
本文把这条旧路径单独展开：先给出从 NVMe-oF 挂载到专用测试的 SOP，再画出可运行路径与断路分支，最后按执行顺序逐句解释 Batch 分配、请求切片、cuFile 提交、完成事件聚合与资源回收。
导言
一开始我只知道一件事：Mooncake 通过 TENT 接入了 NVIDIA GPUDirect Storage。真正沿代码往下追时，三个问题很快连在了一起：TENT 到底怎样调度一次传输，GDS 向上提供了哪些能力，以及新后端怎样实现同一套契约。
最关键的判断是：TENT 不是 GDS 的一层薄封装，而是负责 Segment、内存注册、后端选择、批次和状态推进的统一运行时；GdsTransport 才负责把 File Segment 请求翻译成 cuFile Batch I/O。 理清这条分工后，submitTransferTasks、cuFileBatchIOGetStatus 和新后端接口会自然落在同一张图里。
导言
手里已经有一套面向 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，解释每个设计判断究竟由哪段代码实现。