Tutti: Making SSD-Backed KV Cache Practical for Long-Context LLM Serving

发表时间: 2026-05 · arXiv:2605.03375 (preprint)

原文: https://arxiv.org/abs/2605.03375

Shi Qiu (Xiamen University), Yifan Hu (Xiamen University), Xintao Wang (Shanghai Jiao Tong University), Wenhao Zhu (Xiamen University), Jianqin Yan (Xiamen University), Hao Chen (Xiamen University), Kaiqiang Xu (Hong Kong University of Science and Technology), Kai Chen (Hong Kong University of Science and Technology), Yiming Zhang (Shanghai Jiao Tong University)

速读

一句话结论
本文提出了一种名为 Tutti 的 GPU 中心化 SSD 键值缓存（KV Cache）存储系统，通过将 CPU 从关键的数据和 I/O 控制路径中移除，在严格的服务等级目标下将首字延迟降低了 78.3%，并使大语言模型长上下文推理的服务成本降低了 27%。

要解决什么问题
大语言模型在处理长上下文和高并发请求时，KV Cache 的显存占用会迅速超出 GPU HBM 和 CPU DRAM 的容量上限，必须将其卸载到容量更大的 NVMe SSD 中。然而，现有的三层存储架构在读取 SSD 数据时面临严重的性能卡点，导致高达 70% 到 80% 的 GPU 计算气泡。这个卡点的核心机制在于：现代推理引擎采用分页的 KV 内存管理，将逻辑上连续的缓存切分成了大量细碎、不连续的内存块。当这些数据被驱逐到 SSD 后，读取长前缀会产生海量的微小随机 I/O 请求。即使采用了 GPU Direct Storage（GDS）技术绕过 CPU 内存进行直接数据传输，每一次 I/O 请求的下发和完成确认仍然必须由 CPU 介入。这种以 CPU 为中心的控制流导致了极高的 CPU-GPU 同步开销，使得 CPU 成为低并发瓶颈，完全无法打满 SSD 的物理带宽，最终导致重用 KV Cache 的耗时甚至比直接重新计算还要长。

怎么做的
Tutti 的核心思路是构建一个以 GPU 为中心的 KV Cache 对象存储系统，彻底将 CPU 从数据传输和 I/O 控制的关键路径上剥离，让 GPU 能够直接向 SSD 发起高并发的 I/O 请求。该方法主要由三个关键部件构成：第一，GPU 原生对象抽象。Tutti 将 KV Cache 块映射为 GPU 文件，采用与张量粒度对齐的存储布局。为了解决虚拟地址到物理地址的转换开销，系统在启动时预计算点对点内存映射表，并使用分散聚集列表替代传统的物理区域页，将显存占用从 GB 级压缩到 MB 级。这一设计使得 CPU 只需要在每一层异步下发一次 I/O 任务，将 CPU 的控制开销从 $O(layer \times blocks)$ 降低到了 $O(layer)$。第二，GPU io_uring 异步提交机制。为了支持 GPU 直接发起异步 I/O，Tutti 在 GPU 显存中构建了无锁的提交队列和完成队列。它在硬件层面将 GPU 的流多处理器（SM）划分为计算域和 I/O 控制域，让 I/O 内核在专用的 SM 上运行。这样一来，I/O 任务的提交与完成检查都在 GPU 内部闭环，且不会抢占模型计算的资源。第三，感知空闲的 I/O 调度器。由于同时读写 SSD 会引发严重的带宽争抢，且 I/O 内核与计算内核会争夺 SM 资源，Tutti 放弃了简单的逐层流水线。它通过离线分析每一层注意力机制的计算耗时，记录下算力富裕且无读写冲突的空闲窗口。在运行时，调度器优先保障关键路径上的读请求，而将写请求推迟并精准安插到这些空闲窗口中执行，从而最大化计算与 I/O 的重叠，将 GPU 气泡降至接近于零。

效果如何
实验在单卡 Llama3-8B 和双卡张量并行的 GLM-4-9B-Chat-1M 模型上进行，硬件配备 H100 GPU 和企业级 NVMe SSD，并在 vLLM 引擎中集成了 Tutti。对比的基线方法包括：代表纯显存路线的 HBM、代表内存扩展及逐层计算 I/O 流水线路线的 DRAM（LMCache-DRAM-LW）、代表传统异步 I/O 固态硬盘路线的 LMCache-SSD，以及代表绕过 CPU 内存直通路线的强基线 LMCache-GDS。在 LEval 和 LooGLE 长文本评测集上，Tutti 展现了压倒性优势。在严格的 1 秒首字延迟约束下，Tutti 的有效请求吞吐量比 DRAM 路线高出 50%，比 LMCache-GDS 高出 100%。在 0.6 RPS 的高负载下，Tutti 的首字延迟比 LMCache-GDS 降低了 62.0%，比 DRAM 降低了 93.2%。在解码阶段，Tutti 的词间延迟也比 LMCache-GDS 降低了 24.4%。此外，在 640K 超长上下文的极限测试中，LMCache-GDS 因 I/O 缓冲机制耗尽显存而触发 OOM 失败，而 Tutti 凭借无缓冲直通架构成功完成推理，耗时仅 1.2 秒。作者也承认了当前设计的局限性：Tutti 目前在多节点分布式扩展时的远程检索路径尚未充分优化，跨节点拉取 KV Cache 时仍需回退到依赖 CPU 将 GPU 文件读入主机内存并通过 RDMA 传输的传统路径，这会引入额外的 CPU 开销。

主要贡献

大语言模型（LLM）的服务高度依赖前缀缓存（Prefix Caching）来提升推理性能。随着上下文长度的不断增长，键值（KV）缓存的内存占用量已经远远超出了GPU高带宽内存（HBM）和CPU动态随机存取存储器（DRAM）的容量限制，因此KV缓存正越来越多地被卸载到NVMe SSD中。然而，从SSD中恢复KV缓存会面临极差的I/O性能，并导致显著的GPU停顿（Stalls）。这主要是由于碎片化的GPU内存布局导致了大量微小的随机I/O操作，使得并行度较低的CPU成为严重的性能瓶颈。即使使用了GPU直接存储（GPU Direct Storage, GDS）技术，系统仍然需要CPU的介入来发起每一次I/O请求，因此本质上仍然是“以CPU为中心”的架构。

本文提出了Tutti，这是一个高效的基于SSD的KV缓存解决方案，它成功地将CPU从HBM与SSD之间的关键数据路径和I/O控制路径中彻底移除。Tutti的核心是一个“以GPU为中心”的KV缓存对象存储系统，在该系统中，CPU仅负责每层异步地将I/O内核加载到GPU一次。通过以下创新设计，Tutti成功打满了NVMe SSD的带宽，并将GPU停顿时间降至接近于零：
1. 提供了一种GPU原生的对象抽象，支持KV缓存的批量传输与管理；
2. 重构了GPU存储栈，引入了GPU io_uring机制，以支持异步的GPU直接对象I/O；
3. 提出了感知空闲时间（Slack-aware）的I/O调度策略，以避免GPU资源的争用。

实验结果表明，与最先进的、启用了GDS且基于SSD的LMCache相比，Tutti在严格的服务级别目标（SLO）约束下将首字生成时间（TTFT）降低了$78.3\%$，将可达到的请求吞吐量提升了$2 \times$，并将服务成本降低了$27\%$。Tutti实现了与基于DRAM的LMCache几乎相同的推理性能，同时提供了近乎无限的缓存容量。

图1. 以CPU为中心的KV缓存存储（带/不带GDS的LMCache）与以GPU为中心的Tutti的对比。Tutti消除了CPU在HBM和SSD之间的关键数据和I/O控制路径上的干预。
图1. 以CPU为中心的KV缓存存储（带/不带GDS的LMCache）与以GPU为中心的Tutti的对比。Tutti消除了CPU在HBM和SSD之间的关键数据和I/O控制路径上的干预。

背景知识与关键观察

LLM推理与KV缓存。现代LLM基于Transformer架构，其Token生成包含Prefill（预填充）和Decode（解码）两个阶段。Prefill阶段并行处理输入提示，计算Query（$Q$）、Key（$K$）和Value（$V$）矩阵，该阶段受限于计算能力，通常用首字生成时间（TTFT）来衡量。Decode阶段基于历史Token自回归地逐个生成新Token，通常用Token间延迟（ITL）来衡量。为了避免Decode阶段的重复计算，推理引擎会将Prefill阶段生成的$K$和$V$矩阵存储为KV缓存。KV缓存可以跨共享相同前缀的请求进行复用（即前缀缓存），这能跳过Prefill计算，释放计算能力，并将每个Token的成本降低高达$90\%$。随着输入长度的增长，变长的请求会导致GPU内存碎片化。现代推理系统采用分页KV内存管理，将KV缓存划分为形状为$[Block, h, d]$的非连续块，每个块通常容纳16-32个Token，按需分配以支持动态序列增长。

分层KV缓存中SSD引发的瓶颈。随着上下文窗口扩展至数百万Token以及并发会话的增加，KV缓存占用迅速超出GPU HBM容量。将KV缓存扩展到CPU DRAM和NVMe SSD形成了多级存储架构。DRAM层仅引入轻微性能下降，但容量有限；SSD层容量极大，但引发了严重的I/O开销。核心挑战在于分页KV布局与SSD访问模式的不匹配。非连续的GPU KV块被驱逐到SSD后，内存碎片化演变为严重的I/O碎片化。例如，对于块大小为64的64层Qwen3-32B模型，重新加载128K Token的KV需要获取约$256K$（即$2 \times 64 \times 128 \times 1024 / 64$）个分散的$80KB$对象。这种访问模式产生了海量的小型随机传输，导致CPU-GPU拷贝、文件系统和I/O提交开销主导了数据移动。即使将多个块分组为更大的块（如LMCache默认的256 Token块），128K Token的KV仍需要上千次随机访问。我们对最新版LMCache（支持DRAM、SSD层、层级计算-I/O流水线和GDS）进行了测试。结果显示，DRAM层非常高效，其低延迟和细粒度访问配合GPU辅助拷贝使开销极小。然而，SSD层即使有GDS加持也极其低效。从SSD恢复KV缓存比从DRAM恢复差得多，导致GPU气泡（Bubbles）在所有情况下均超过推理总延迟的$70\%$。在SSD上应用层级传输（SSD-LW）进一步减小了I/O粒度，使GPU气泡时间达到约$80\%$。GDS虽然通过P2P DMA消除了CPU-GPU拷贝，但仍依赖CPU发起每次I/O，软件开销大且限制了I/O并行度。

图2. vLLM结合LMCache在Llama3-8B上跨HBM、DRAM和SSD层的推理性能（序列长度=$64K$，命中率=$75\%$）。DRAM性能接近HBM，而SSD和GDS引发了巨大的GPU气泡。虚线标记了重新计算的性能。由于严重的I/O瓶颈，从SSD恢复KV缓存不再具有收益。
图2. vLLM结合LMCache在Llama3-8B上跨HBM、DRAM和SSD层的推理性能（序列长度=$64K$，命中率=$75\%$）。DRAM性能接近HBM，而SSD和GDS引发了巨大的GPU气泡。虚线标记了重新计算的性能。由于严重的I/O瓶颈，从SSD恢复KV缓存不再具有收益。

GPU中心化存储的挑战。GPU中心化存储将数据面和I/O控制面都移至GPU，允许GPU线程在无CPU干预下发出NVMe I/O。然而，将其应用于KV缓存面临独特挑战。首先是KV缓存管理的抽象不匹配。LLM引擎需要动态分配和索引KV块，而GPU中心化存储仅暴露底层块或文件接口。若将哈希管理推给GPU，性能极差：GPU哈希表的插入和查找成本比CPU哈希表高出$9.0 \times \sim 24.2 \times$和$25.6 \times \sim 50.0 \times$。其次是存储I/O与KV传输之间的粒度鸿沟。GPU NVMe驱动针对细粒度访问优化，但KV缓存重载需要中等大小的连续传输以满足SSD带宽。PCIe 5.0 SSD上4KB请求只能利用约$80\%$读带宽和$16\%$写带宽。大于8KB的请求需要NVMe额外的PRP列表页，这必须在特权CPU代码中分配，破坏了消除CPU干预的初衷。最后是资源争用。GPU中心化存储I/O与LLM计算争夺SM资源，现有的同步忙等待I/O会阻塞计算；此外，前缀缓存产生密集的双向流量，读写I/O竞争NVMe内部资源，导致带宽下降。

图3. CPU与GPU在哈希性能上的对比。
图3. CPU与GPU在哈希性能上的对比。

方法细节

GPU中心化对象存储。Tutti的核心是一个以GPU为中心的KV缓存对象存储。由于KV缓存的索引、全局共享和引擎可见的映射必须与CPU侧的推理引擎保持协调，Tutti将这些管理逻辑保留在CPU上，但将其移出KV缓存传输的关键数据和I/O控制路径。Tutti基于GPU伴随文件系统GeminiFS构建，扩展了可扩展的GPU文件池和P2P内存映射表，以支持动态、批量的KV缓存传输及管理操作。在可扩展的GPU文件池设计中，Tutti将存储分配与推理引擎的KV块管理器对齐，将每个内存块表示为一个对象。一个GPU文件由$2 \times L$个对象组成（$L$为层数），每层包含一个Key对象和一个Value对象。这种映射保留了推理引擎原生的块粒度。GPU文件对推理引擎可见，而NVMe文件由GeminiFS作为物理存储范围管理。Tutti使用Tensor-Stripe布局将每个GPU文件映射到多个NVMe文件，确保存储I/O与KV传输粒度对齐。对于跨越多个GPU文件的提示词，Tutti采用跨设备的轮询（Round-robin）放置策略，将对象均匀分布在多个NVMe SSD上，以平衡I/O流量并降低索引开销。在系统启动时，Tutti在每个设备上预分配大量NVMe文件，并将其作为空闲GPU文件暴露。持久化新KV缓存时，运行时只需选择一个空GPU文件并安装CPU侧的哈希映射，从而将文件创建和元数据操作移出关键路径。在P2P内存映射表设计中，为了将KV缓存虚拟地址转换为PCI可见的物理地址，Tutti在启动时预计算P2P内存映射表。为避免PRP设计带来的巨大内存开销（例如60GB KV缓存需要约3.75GB HBM），Tutti采用了分散聚集列表（Scatter Gather Lists, SGL）。SGL仅用16字节描述一大块连续内存，使内存消耗降至约$15MB$。运行时，推理引擎仅执行块查找和P2P表查找，生成轻量级GPU I/O上下文并传递给GPU，从而提供了层级批处理的Store和Retrieval接口，将CPU开销从$O(layer \times blocks)$降低到$O(layer)$。

图4. GPU中心化KV缓存存储的布局。
图4. GPU中心化KV缓存存储的布局。

GPU io_uring。GPU中心化对象存储遵循“CPU准备，GPU执行”的模型。CPU运行时从CPU管理的映射中准备I/O控制块（IOCBs），并将GPU I/O内核与模型计算内核一起提前入队。入队后，GPU侧的依赖追踪决定何时发出SSD访问，因此运行时I/O关键路径不再涉及CPU。这种设计镜像了CPU侧的io_uring，被称为GPU io_uring (gio_uring)。为了避免运行时内存分配、拷贝和CPU-GPU同步，gio_uring利用了一对驻留在GPU HBM中但通过非缓存mmap映射到CPU的无锁环形缓冲区（SQ和CQ）。每个SQ条目定义为一个I/O IOCB，包含2048个I/O上下文（IOCTXs）。IOCTX记录SGL地址、GPU文件偏移量和长度。这种批处理队列结构允许GPU一次性提交海量I/O请求。为了实现计算与I/O的细粒度重叠，Tutti通过NVIDIA green context在硬件层面将GPU资源隔离为“计算域”和“I/O控制域”。I/O控制内核运行在专用SM上，不受计算工作负载波动的影响，确保了确定性的QoS。异步I/O处理流程如下：首先，init_queue(depth)创建包含指定深度IOCB的SQ和CQ；其次，执行前调用get_iocb(nums, event)获取IOCB，应用程序填充CPU侧虚拟地址并更新num_ioctx，同时插入CUDA事件以保证乱序流执行下的正确性；接着，issue_io(IOCB_ids, SMs)将指定IOCB ID和SM分配的GPU I/O内核入队，内核完成后原子地将IOCB索引写入CQ；最后，wait_cqe()通过检查CQ中特定IOCB索引来提供细粒度等待，无需CPU参与每次I/O的发布。

图5. GPU io_uring的架构与I/O处理流程。
图5. GPU io_uring的架构与I/O处理流程。

感知空闲时间的I/O调度器（Slack-Aware I/O Scheduler）。仅使用异步I/O和SM分区不足以实现稳定的计算-I/O重叠，因为读写I/O会争夺SSD带宽，且I/O内核会与模型执行争夺SM资源。Tutti提出了一个由查找表驱动的感知空闲时间的I/O调度器。该调度器利用离线分析将读写内核放置在具有空闲SM资源且无读写带宽冲突的执行窗口（Slacks）中。在离线分析SM空闲窗口时，由于注意力复杂度随前缀长度线性增加，Tutti对每一层进行离线分析，并将空闲信息存储在由输入长度（$L_{input}$）和前缀长度（$L_{prefix}$）索引的查找表中。每个条目记录了可调度空闲窗口的持续时间和可用SM预算，步长与单个Warp的Token长度对齐。在读写解耦调度方面，为了避免并发读写导致的带宽崩溃，Tutti根据查找表分别调度读写。在Prefill期间，读内核具有较高优先级。当请求到达时，运行时将读取IOCB入队。每层开始前，调度器查询查找表并启动适合下一个空闲窗口的最大IOCB数量。如果不存在合适的空闲窗口，说明KV检索成为瓶颈，调度器会立即启动所需的读取。写请求只有在关键路径读取被调度后才处理。如果当前Prefill层有空闲窗口，调度器会尽可能多地发出写入；否则，将其推迟以缩短Prefill时间并保护TTFT。剩余的写入在Decode期间尽力而为地刷新，依靠查找表机会性地发出写入。

图6. 并发与解耦读写的PCIe带宽利用率对比。
图6. 并发与解耦读写的PCIe带宽利用率对比。
图7. 感知空闲时间的I/O调度器工作原理。
图7. 感知空闲时间的I/O调度器工作原理。

Tutti的实现细节。Tutti使用约8000行C++代码实现，并使用约1500行Python代码与vLLM的KVConnector集成。GPU文件池暴露了层级的retrieve_layer和store_layer接口。retrieve_layer在复用的关键路径上发出，而store_layer被排队并在必要时推迟。这些接口绑定到CUDA流依赖项，而详细的GPU侧提交和完成流程遵循GPU io_uring的设计。在多GPU支持方面，Tutti为每个GPU进程部署一个实例，每个实例仅管理部分KV缓存。为了支持GPU间共享NVMe，Tutti使用本地守护进程为每个GPU分配GPU内存并初始化专用的NVMe SQ/CQ对，从而消除GPU间的队列争用。在可扩展性方面，Tutti将本地存储数据面与Mooncake分布式控制面结合。当KV缓存被驱逐时，Tutti通过P2P DMA将其持久化到本地NVMe SSD，并通知Mooncake注册副本元数据。复用时，系统优先进行本地路由，若本地不可用，则回退到远程检索路径（目前通过CPU侧接口读取并通过RDMA跨节点传输）。

实验环境

  • 硬件配置：一台配备64核Intel Xeon 6530 CPU和512 GB内存的服务器。服务器搭载两块具有80GB HBM的H100 GPU，以及4块Solidigm D7-PS1010 7.68TB企业级NVMe SSD。在分层存储配置中，分配256 GB主机DRAM作为固定内存，并为每个GPU提供14TB的SSD卷。
  • 软件配置：基于vLLM 0.12.0和vLLM 0.17.0进行评估。基线系统包括：(1) HBM：仅使用HBM的标准vLLM；(2) DRAM (LMCache-DRAM-LW)：使用主机内存扩展容量并应用层级计算-I/O流水线；(3) LMCache-SSD：使用memcopy和标准异步I/O将KV数据卸载到SSD；(4) LMCache-GDS：使用GDS绕过CPU反弹缓冲区。
  • 模型架构：主要使用单GPU上的Llama3-8B模型。为了评估超长序列扩展性，使用张量并行分布在双GPU上的GLM-4-9B-Chat-1M模型。
  • 数据集：LEval（包含20个子任务，长度跨度3k到200k tokens）和LooGLE（针对超长上下文理解，大量样本超过100k tokens）。通过泊松分布模拟查询到达来测试并发负载。

实验结果

端到端性能。如图8所示，无论是在vLLM 0.12.0还是0.17.0版本下，Tutti在TTFT和ITL上均表现出最佳的端到端性能和稳定性。对于TTFT，HBM和SSD基线表现不佳。在LEval数据集和旧版本下，Tutti在最高负载点比GDS提升了$71.8\%$；在新版本下，Tutti比DRAM降低了$69.1\%$，比GDS降低了$78.3\%$。在1秒的TTFT SLO下，Tutti的有效请求率比DRAM提高了$50\%$，比GDS提高了$100\%$。在LooGLE数据集上，Tutti在0.6 RPS时的TTFT分别比DRAM和GDS降低了$93.2\%$和$62.0\%$。对于ITL，Tutti在LEval数据集1.5 RPS负载下（新版本）比DRAM降低了$22.0\%$，比GDS降低了$24.4\%$。

图8. 在两个vLLM版本下，Llama3-8B在LEval和LooGLE上的端到端TTFT和ITL。
图8. 在两个vLLM版本下，Llama3-8B在LEval和LooGLE上的端到端TTFT和ITL。

存储带宽消融实验。如图9所示，Tutti的检索带宽随上下文长度平滑增长，最高达到$25.9 GB/s$，比LMCache-GDS高出$2.08 \times$。在存储带宽方面，Tutti稳定在约$10 GB/s$（受限于SSD物理极限），而LMCache-GDS仅维持在约$7 GB/s$。

图9. 不同上下文长度下检索和存储接口的原始带宽。
图9. 不同上下文长度下检索和存储接口的原始带宽。

PRP与SGL带宽对比。如图10所示，在单线程微基准测试中，采用PRP的读写带宽仅为$0.287 GB/s$和$0.032 GB/s$，而切换到SGL后，带宽分别提升至$8.891 GB/s$和$2.922 GB/s$，获得了$31.0 \times$和$91.3 \times$的提升，证明SGL显著降低了PCIe通信开销。

图10. 单线程读写微基准测试下PRP与SGL的带宽对比。
图10. 单线程读写微基准测试下PRP与SGL的带宽对比。

不同上下文长度下的TTFT。如图11所示，固定输入为128k Token，前缀缓存从16k增加到128k。Tutti始终优于LMCache-GDS（在128k时提升高达$61.4\%$）。在中等复用率（16k-96k）下，Tutti甚至匹配或超越了DRAM的性能（提升达$13.4\%$），证明高效的I/O-计算重叠可以抵消DRAM的原始延迟优势。

图11. Llama3-8B-Instruct在不同前缀长度下的TTFT性能对比。
图11. Llama3-8B-Instruct在不同前缀长度下的TTFT性能对比。

分布式扩展性。如图12所示，在双GPU、4磁盘环境下运行GLM-4-9B-1M模型，Tutti在128K前缀长度下比LMCache-GDS降低了约$25\%$的TTFT。更关键的是，LMCache-GDS在512K和640K时因GDS需要分配大量GPU内存作为暂存缓冲区而导致OOM崩溃，而Tutti通过深度集成直接管理GPU内存，成功完成了测试并在640K时实现了1.2秒的最佳TTFT。

图12. GLM-4-9B-1M的分布式扩展性测试。Tutti克服了LMCache-GDS在长上下文下的OOM问题。
图12. GLM-4-9B-1M的分布式扩展性测试。Tutti克服了LMCache-GDS在长上下文下的OOM问题。

层级异步流水线的有效性。如图13所示，Tutti成功掩盖了传输开销，在大部分测试范围内气泡时间平均仅为$25ms$。Tutti将计算受限转变为I/O受限的“交叉点”推迟到了极高的$98.3\%$缓存命中率，显著优于LMCache-SSD，证明其机制将“有效零气泡区”扩展到了物理极限。

图13. 按缓存命中率分解的延迟，突出了气泡时间开始超过计算时间的关键交叉点。
图13. 按缓存命中率分解的延迟，突出了气泡时间开始超过计算时间的关键交叉点。

补充细节（推理成本分析）

为了量化Tutti的经济效益，论文计算了标准化为Token生成吞吐量的服务成本。总成本公式定义为：

$$Cost_{1M} = \frac{P_{GPU} \cdot N_{GPU} + P_{mem} \cdot S_{mem} + P_{ssd} \cdot S_{ssd}}{Throughput (tokens/hour)} \times 10^6$$


其中$P_{GPU}$是GPU的小时价格，$N_{GPU}$是GPU数量，$P_{x} / S_{x}$分别代表DRAM/SSD的单价和容量。如图14所示，Tutti在所有请求率下均表现出最有利的成本效益曲线。在LooGLE工作负载$0.5 QPS$下，Tutti的服务成本比LMCache-SSD降低了$66.2\%$，比LMCache-GDS降低了约$27\%$。这是因为Tutti充分饱和了GPU计算资源，最大化了吞吐量，从而优化了每GPU小时的Token产出。

图14. LEval和LooGLE工作负载下每生成100万个Token的推理成本。
图14. LEval和LooGLE工作负载下每生成100万个Token的推理成本。

结论

本文提出了Tutti，这是一个用于长上下文LLM服务的、以GPU为中心的SSD支持的KV缓存存储系统。Tutti将CPU干预从GPU HBM和NVMe SSD之间的关键数据和I/O控制路径中移除。通过将GPU中心化的对象存储设计与层级GPU计算-I/O流水线相结合，Tutti使基于SSD的KV缓存达到了类似DRAM的效率，同时有效抑制了GPU停顿时间。评估表明，与最先进的启用GDS的SSD解决方案相比，Tutti在严格的SLO约束下将TTFT降低了$78.3\%$，将请求率提高了$2 \times$，并将LLM服务成本降低了约$27\%$。未来的工作计划扩展设计以支持更直接的由GPU驱动的远程路径（例如通过RDMA）。

方法细节中引用的参考文献汇总：
- 前缀缓存机制：[6, IMPRESS: An Importance-InformedMulti-Tier Prefix KV Storage System for Large Language Model Inference, 2025, FAST], [38, Mooncake: Kimi’s KVCachecentric Architecture for LLM Serving, 2024, arXiv], [50, Strata: Hierarchical Context Caching for Long Context Language Model Serving, 2025, arXiv]。原文描述它们为现代推理服务的关键优化。
- 成本降低：[7, Deepseek Models and Pricing, 2025], [36, OpenAI API Pricing, 2025]。原文指出前缀缓存能降低高达90%的成本。
- GPU HBM耗尽与DRAM限制：[9, How Weka is Solving AI’s Trillion Dollar Memory Problem, 2026], [35, Another Conversation with Val Bercovici Memory Markets, 2026]。原文描述HBM容量不足，而2TB DRAM也只能保留约5分钟的KV缓存。
- SSD扩展：[12, 13, 26, 27, 38, 44, 51, 54]。原文提到进一步扩展需要NVMe SSD作为下一层。
- 现代推理引擎架构：[20, Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023, SOSP], [42, SGLang, 2024]。原文提到它们使用分页KV布局管理内存。
- 碎片化问题：[19, 26, 32, 57]。原文指出逻辑连续的KV缓存被碎片化为许多小而分散的块。
- GPU停顿：[41, An I/O Characterizing Study of Offloading LLM Models and KV Caches to NVMe SSD, 2025]。原文描述多层开销导致70~80%的GPU停顿。
- 流水线优化：[13, Fast state restoration in llm serving with hcache, 2025], [16, Accelerating LLM Serving for Multi-turn Dialogues with Efficient Resource Management, 2025]。原文提到用计算掩盖传输开销对DRAM有效，但对SSD会导致I/O碎片化。
- 避免使用SSD的系统：[1, 11, 21, 38, 50, 55]。原文提到现有系统倾向于避免将KV缓存卸载到SSD。
- LMCache与GDS：[26, Cachegen: Kv cache compression and streaming for fast large language model serving, 2024, SIGCOMM], [33, NVIDIA GPUDirect Storage, 2024]。原文指出LMCache集成了GDS，但仍受限于CPU控制。
- GDS开销：[8, DeepNVMe, 2025]。原文指出GDS仍依赖CPU干预，限制了I/O并行度。
- GPU中心化存储：[5, GMT: GPU Orchestrated Memory Tiering, 2024], [28, Smartio, 2021], [39, GeminiFS, 2025, FAST], [40, GPU-initiated on-demand high-throughput storage access in the BaM system architecture, 2023, ASPLOS], [23, Managing Scalable Direct Storage Accesses for GPUs with GoFS, 2025, SOSP]。原文提到BaM、GeminiFS等系统允许GPU直接控制NVMe。
- Qwen3-32B模型：[53, Qwen3 Technical Report, 2025]。原文用其作为128K上下文分块的计算示例。
- 内存碎片化：[43, Fastswitch, 2024]。原文提到非连续KV块驱逐到SSD导致内存碎片化变为I/O碎片化。
- PCIe 5.0 SSDs与PRP：[18, KIOXIA CM7-V Series], [46, Solidigm D7-PS1010], [49, NVM Express Base Specification Revision 2.0c, 2022]。原文指出4KB请求无法打满带宽，而大请求需要CPU分配PRP列表页。
- SGL应用：[49, NVM Express Base Specification Revision 2.0c, 2022]。原文指出Tutti采用SGL代替PRP以极大地节省内存。
- CPU io_uring：[10, Understanding modern storage APIs: a systematic study of libaio, SPDK, and io_uring, 2022]。原文提到Tutti的GPU io_uring镜像了其设计。
- 非缓存mmap：[52, Phoenix: A Refactored I/O Stack for GPU Direct Storage without Phony Buffers, 2025]。原文提及利用此技术将HBM中的环形缓冲区映射给CPU。
- GPU硬件调度器与隔离：[24, Bullet: Boosting GPU Utilization for LLM Serving, 2025], [34, Cuda-programming-guide Green Contexts, 2025]。原文提到GPU调度缺乏抢占性，因此使用Green Contexts隔离SM。
- NVMe内部缓存竞争：[15, PASS: A proactive and adaptive SSD buffer scheme, 2015], [25, Improving fairness for SSD devices through DRAM overprovisioning cache management, 2022]。原文指出读写并发会导致NVMe内部缓存竞争从而降低带宽。
- 测试设备：[45, Solidigm D7-PS1010, 2024]。原文提到原型系统使用了该SSD，支持多达256个I/O队列。