Tutti

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 的论文强调 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 厂商实现。 ...

长上下文推理会生成大量 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 数增长。分层存储因此很自然： ...