动机
当 KV 缓存变成 I/O 碎片
随着上下文长度的增长，键值（KV）缓存占用空间远远超出 GPU HBM 和 CPU DRAM 容量，KV 缓存越来越多地被卸载到 NVMe SSD。LLM 服务系统将 KV 缓存管理为许多相对较小的、不连续的内存块（通常每块 16KB-64KB）。当这些块被移动到基于 SSD 的存储时，恢复长前缀变成了许多小型、碎片化的存储操作。
不幸的是，从 SSD 恢复 KV 缓存会遭受糟糕的 I/O 性能并导致显著的 GPU 停顿。这主要是因为：
- 碎片化的 GPU 内存布局导致小规模、分散的 I/O 操作
- 每个 I/O 请求都需要频繁的 CPU 参与，造成开销
- KV 缓存传输与 GPU 存储 I/O 之间缺乏协调
- 缓存恢复期间的 GPU 资源争用
Tutti 围绕 GPU 原生 KV 缓存对象和 GPU 发起的存储操作重组了这条路径，将 CPU 参与减少到粗粒度的编排。通过提供批量 KV 缓存传输和对 SSD 存储缓存的直接 GPU 访问，Tutti 充分利用 NVMe SSD 带宽，并将 GPU 停顿减少到接近零。
关键设计思想
GPU 原生对象抽象
Tutti 提供 GPU 原生对象抽象，支持批量 KV 缓存传输和管理，允许直接 GPU 访问存储在 NVMe SSD 上的 KV 缓存。
- • 用于内存对象管理的 GPU 文件池
- • 基于 GPU 文件系统（GeminiFS）的 NVMe 文件池
- • 用于直接访问的 P2P 内存映射表
- • 集成分配、索引和 GPU 访问的 CPU 侧接口
异步 GPU 直接对象 I/O
重新架构的 GPU 存储栈支持异步直接 I/O，GPU 内核可以发起存储操作而无需每次请求都需要 CPU 干预。
- • GPU 内核直接发起 NVMe 命令
- • 批量 I/O 提交减少开销
- • 异步完成处理
- • 缓存恢复期间接近零的 GPU 停顿
智能体工作负载的前缀缓存
为 AI 智能体场景优化，其中长上下文前缀在请求之间频繁重用，大幅减少冗余计算。
- • 智能前缀匹配和重用
- • 智能体工作负载的高缓存命中率
- • 常见上下文前缀的高效存储
- • 支持 131:1 的输入/输出令牌比
多层缓存管理
跨 GPU HBM、CPU DRAM 和 NVMe SSD 的分层缓存，采用针对长上下文推理模式优化的智能放置策略。
- • HBM 用于活跃推理
- • DRAM 用于热缓存块
- • NVMe 作为主存储层（100TB+ 容量）
- • 自适应的提升/降级策略
架构
架构基于研究论文。实际实现可能有所不同。
证据
论文结果
来源："Tutti: Making SSD-Backed KV Cache Practical for Long-Context LLM Serving"（arXiv:2605.03375v1，2026年5月）
关键性能特征
- 通过异步直接 I/O 实现接近零的 GPU 停顿
- 充分利用 NVMe SSD 带宽进行批量 KV 缓存传输
- NVMe SSD 层提供 100TB+ 容量潜力（相比有限的 HBM/DRAM）
当前支持边界
研究架构
- • GPU 原生对象抽象
- • 异步直接 I/O 栈
- • 多层缓存管理（HBM/DRAM/NVMe）
- • 智能体工作负载的前缀缓存
实现状态
Tutti 是一个研究项目。请查看 GitHub 仓库以了解当前实现状态、支持的平台和集成指南。
性能结果来自论文评估。生产部署应在其特定环境中验证性能。
重要说明
- →部署前应在仓库 README 中验证供应商支持和硬件兼容性
- →论文结果是在具有特定配置的受控研究环境中获得的
- →与 LLM 服务框架（vLLM、TensorRT-LLM 等）的集成状态应在仓库中查看