我之前在 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 为什么仍然有独立价值。

把 SSD 数据送进 GPU，最直观的优化似乎是“绕过 CPU”。但这句话混合了两个不同问题：数据是否经过 CPU 内存，以及 I/O 请求究竟由 CPU 还是 GPU 发起。NVIDIA GDS 解决前者，BaM 进一步改变后者；代价是原本由 CPU 承担的队列管理、并发和缓存压力转移到了 GPU。

本文整理 DaMoN 2025 论文 Path to GPU-Initiated I/O for Data-Intensive Systems：先沿 Figure 1 比较五条 GPU-centric Storage 路径，再还原 BaM、GDS 与 SPDK 的实验边界。核心结论不是“GPU 发起一定更快”，而是系统应根据 CPU、GPU、PCIe、SSD 与数据复用状态，选择由谁支付 I/O 控制成本。

读到 Tutti 的 GPU io_uring 一节时，我几乎完全没看懂。SQ、CQ、IOCB、CUDA Event 和 Green Context 挤在一起，很难看出它们各自解决什么问题。

本文先用取餐叫号解释核心直觉，再用 Linux io_uring 的 SQ、CQ、SQE、CQE 和 SQPOLL 建立准确模型，最后把这些对象放回 Tutti：为什么队列能把发起请求和等待结果拆成两个时间点，以及为什么还需要 CUDA Event、Green Context 和 slack-aware Scheduler 才能真正减少 GPU 停顿。

把 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”结论在哪些条件下成立。