Tutti on Hellokitty's Blog

Tutti 源码阅读（二）：GPU 如何直接驱动 NVMe 队列

Thu, 03 Sep 2026 17:40:00 +0800

Tutti 最具辨识度的代码位于运行时以下：自定义 snvme 内核模块建立受控 NVMe queue pair，libnvm 管理设备资源，GPU kernel 批量写 SQE、更新 doorbell 并轮询 CQE。数据通过 PCIe P2P DMA 在 SSD 与 HBM 之间移动，CPU 不再逐条提交 I/O。

本文沿一次读请求下潜，分析为什么主线 Linux NVMe 驱动不够、控制面与数据面如何分离、GPU 如何构造命令，以及条带化和 layer-wise overlap 怎样落实到代码结构。

项目源码：xPU-IO/Tutti。

一、为什么需要自定义 `snvme`

NVMe 控制器的数据面并不复杂：主机写 Submission Queue，更新 MMIO doorbell，设备执行 DMA，再把 Completion Queue Entry 写回内存。

问题是 Linux 主线 NVMe 驱动没有向普通应用提供一套稳定机制，用来同时完成：

创建应用独占或受控的 I/O queue pair；
将 SQ/CQ 放入可被应用或 GPU 访问的固定内存；
把对应 doorbell BAR 页安全映射给应用；
将 GPU HBM 注册成 NVMe 可 DMA 的 peer memory；
允许应用自行轮询 CQ，而不经过每请求系统调用。

传统 read、io_uring 或 GDS 可以缩短部分路径，但 NVMe 队列仍主要由内核或 CPU 侧库控制。Tutti 要让 GPU 成为请求生产者，因此需要一个负责授权与建图的内核控制面。

Tutti 源码阅读（一）：StorageRuntime 如何组织 KV Cache I/O

Thu, 03 Sep 2026 17:35:00 +0800

Tutti 的论文强调 GPU 主导 I/O，但应用首先接触的不是 NVMe doorbell，而是一套稳定的 StorageRuntime API。它负责把 URI、文件 extent、GPU 内存、后端实例和异步请求组装起来，让上层无需知道底层究竟是单盘、条带化 NVMe，还是未来的其他传输路径。

本文阅读 Tutti v0.1.1 的运行时源码与设计文档，聚焦五个问题：公开 API 长什么样、open 如何解析对象、register_memory 为什么独立存在、submit/wait 如何路由，以及 vLLM connector 如何接入。

项目源码：xPU-IO/Tutti。

一、先看整体分层

当前代码把系统拆成以下层次：

Application / vLLM Connector
             │
             ▼
      StorageRuntime
 open · register · submit · wait
             │
      ┌──────┴──────┐
      ▼             ▼
   Resolver       DataPath
 URI → target     IO → backend
      │             │
      └──── Binding ┘
             │
      local / striped NVMe

StorageRuntime 是唯一稳定的应用接口；Resolver、Binding 和 DataPath 是内部 SPI。这样做避免上层依赖特定 NVMe 驱动或 GPU 厂商实现。

Tutti 论文阅读：让 SSD KV Cache 真正服务长上下文推理

Thu, 03 Sep 2026 17:30:00 +0800

长上下文推理会生成大量 KV Cache。HBM 放不下，DRAM 成本高，NVMe SSD 容量大却经常因为 I/O 控制开销而无法进入关键路径。Tutti 的结论是：问题不只是“数据能否从 SSD 直达显存”，而是谁负责把数以千计的 KV 块转成设备请求、提交队列并处理完成。

Tutti 将这条控制路径交给 GPU：CPU 按层启动 I/O kernel，GPU 批量解析 KV 对象、生成 NVMe 命令、敲 doorbell 并轮询完成，同时利用 Transformer 层之间的计算空隙隐藏读取与写回。论文报告，在其测试环境中，相比 SSD-backed LMCache，严格 SLO 下 TTFT 降低 78.3%，可承载请求率提高 2 倍，服务成本降低 27%。

本文阅读论文 Tutti: Making SSD-Backed KV Cache Practical for Long-Context LLM Serving，重点解释它为什么需要 GPU-centric I/O、系统如何工作，以及实验结论应该怎样理解。

一、SSD KV Cache 为什么难用

自回归模型在 prefill 阶段为每层生成 Key 和 Value。后续请求若共享前缀，可以直接载入已有 KV Cache，省去重复计算。

请求 A：系统提示词 + 文档 + 问题 A
请求 B：系统提示词 + 文档 + 问题 B
                     └── 可复用前缀 ──┘

KV Cache 容量随上下文长度、层数、并发和 KV head 数增长。分层存储因此很自然：