2026-06-07 — 次浏览

vLLM 0.22 新增多层 KV Cache 卸载：GPU 到 CPU 再到磁盘，为长上下文本地服务而设

vLLM 0.22.0（2026 年 5 月 29 日）推出多层 KV cache 卸载框架，可将已缓存的块由 CPU DRAM 进一步级联下放到磁盘，并提供 Python 文件系统层与 Mooncake 磁盘后端；6 月 5 日的补丁加入了少数模型与 AMD-CPU 修正。对于服务 128K-token 上下文的单机本地设备而言，把 KV 溢出到 NVMe 而非重新计算 prefill，正是同一张卡只能服务一位用户、还是约八位用户的差

推出了什么

vLLM 0.22.0 于 2026 年 5 月 29 日标记发布，落地了原生的多层 KV cache 卸载框架（PR #40020）。在此之前，vLLM 可以把 key/value 缓存从 GPU 内存溢出到 CPU DRAM 再取回，但那就是极限了：一旦主机 RAM 填满，块会被驱逐，prefill 必须重新计算。新框架把 CPU DRAM 视为单一的主层，并让一个或多个次层位于其后——本地文件系统、对象存储、key-value 存储，或远端节点。本次发布加入了 Python 文件系统次层（PR #41735）与 Mooncake 磁盘卸载（PR #42689）作为首批具体后端，并一并支持 DeepSeek V4（PR #43142）。

2026 年 6 月 5 日的补丁 0.22.1 是较小的后续：它加入了 JetBrains 的 Mellum v2 代码 MoE，在 AMD Zen CPU 上将 int8 与 GPTQ 线性运算路由经过 zentorch kernels，并修正了一个 DeepSeek-V4 CUTLASS 初始化中断的问题。对于任何在单机上跑长上下文的人来说，重点功能都在 0.22.0。

分层如何运作

此设计（RFC #38260）引入了一个在调度器进程内运行的 TieringManager，以及每个后端都要实现的 SecondaryTierManager 接口。编排规则是“永远级联”：当某个块在 CPU DRAM 中被确认后，管理器会异步地把它下推到每个已注册的次层，使用对 CPU 张量的 zero-copy 视图，使调度器永不因 I/O 而阻塞。当某个请求需要一个已从 DRAM 中老化淘汰的块时，管理器会把它从次层往上提升，而不是触发一次全新的 prefill。块以标准的 CPU 布局（TP rank 1 形式）存储，这正是让在某个 tensor-parallel 度下写入的缓存，能在另一个度下被重复使用的原因。

经济账很简单。GPU HBM 以接近 3.35 TB/s 的速度搬移数据；一颗 PCIe 4.0 NVMe 硬盘约落在 7 GB/s，并具有亚毫秒延迟。在你拿它与替代方案相比之前，这个落差看似残酷，而替代方案并不是“从 HBM 读取”，而是“重新计算整个 prefill”。一旦提示变长，从磁盘加载预先计算好的块就能轻松胜过重新计算。

为何这对本地设备很重要

2026 年的现实是 128K——乃至 1M-token 的窗口已是寻常的工作负载，而吃掉这张卡的正是 KV cache。以下是一个粗略的单机概况，取自在一张 H100 级别卡上以 128K 上下文服务 70B 模型的独立基准测试：

设置	在 128K 下的约略并发用户数
仅 GPU HBM	~1
FP8 KV + CPU swap + 磁盘卸载	~8-10

同一来源指出，当 prefill 以磁盘上的缓存命中方式提供、而非重新计算时，一个 128K 系统提示的首字延迟（time-to-first-token）会从约 11 秒降到约 1.5 秒。（那些数字来自某主机托管厂商于 2026 年 4 月的文章，并非 vLLM 自家的数据，因此请将该倍数视为方向性参考。）对于自建的运营者而言，实际的解锁在于：固定的系统提示或一份长的被检索文档，不再需要在每次请求时付出代价——它住在 SSD 上，并在需要时被提升回来。

同一次发布也收紧了一开始就让 GPU 上占用更小的量化路径：batch-invariant Cutlass FP8 宣称端到端 +28.9%（PR #40408），而一个 padded NVFP4 量化 kernel 增加了 +2.4 到 5.7%（PR #42774）。更小的 KV 块，加上有地方安置溢出，正是这个能让单张卡撑得更开的组合。

实务者提醒

如果你用的是单 GPU 机器，而你的瓶颈在于上下文长度而非纯粹的 token 吞吐量，这里的杠杆是一颗快速的本地 NVMe 加上文件系统或 Mooncake 层，而非第二张 GPU。请用一个贴近现实的共享前缀（一个系统提示或一份固定的 RAG 文档）做基准测试，让缓存命中的路径真的会触发；一个冷的、全部都唯一的工作负载，只会让你看到 I/O 成本，而看不到任何重新计算的节省。在启用磁盘层之前，先钉住一个合理的 CPU DRAM 预算——主层仍是每个块都会经过的暂存区。

较少被考量的角度：多层卸载悄悄地改变了“本地”部署的威胁与可靠性面向。KV 块现在会持久化到磁盘，这意味着你的提示与被检索上下文的内容会在一次请求的生命周期之后仍住在 SSD 上——这是一个当缓存随 GPU 内存一同蒸发时并不存在的隐私与保存考量。而由于块以标准的 TP-rank-1 布局存储，今天建立的缓存可以在你更改 tensor-parallel 度或重启服务器之后被重复使用，这把 KV 存储变成你必须去推敲的持久性状态（驱逐策略、磁盘压力、过时的条目），而非短暂的暂存。近期值得玩味的问题是：一个持久、可跨重启的 KV cache，是否会像向量索引早已成为的那样，在单人设备上成为一项受管理的资产。