kvcached 把虚拟内存搬进 KV cache：共享 GPU 上的弹性显存到底怎么落地
Virtualized Elastic KV Cache for Dynamic GPU Sharing and Beyond
秒懂
- 它是什么？
- kvcached 用虚拟地址与物理显存解耦的思路，让 vLLM 和 SGLang 的 KV cache 按需占用显存。它解决的是多模型共卡时的显存碎片问题，代价是引入了一层运行时映射和一套需要自己维护的版本适配。
- 适合谁用？
- 如果你的场景是多模型或在线离线混部在同一张卡上，且显存被静态切分浪费严重，kvcached 值得在测试环境里按 examples 目录的脚本跑一遍；如果你的部署是单模型独占 GPU、负载平稳，引入这层映射只会增加调试面。上手前先确认三件事：你的 vLLM 或 SGLang 版本是否落在 README 表格给出的区间内，你要用的注意力类型（MLA、sliding window、hybrid）是否在支持列表里，以及 kvcached CLI 的显存上限配置能否覆盖你的峰值。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它要解决的不是显存不够，而是显存切得太死
传统做法是给每个模型或每个实例预分配一块固定显存，KV cache 的容量在启动时就定死了。负载低的时候这块显存空着，负载高的时候又不够用，只能靠重启或者调参。kvcached 的切入点就在这里：它把 KV cache 的容量从启动时确定改成运行时按需增长。README 里把它描述为给 LLM 系统引入操作系统风格的虚拟内存抽象，让显存分配变成弹性的、由需求驱动的。目标用户是那些在一张或几张 GPU 上同时跑多个模型、或者需要在线流量与离线任务共存的团队。单模型独占整卡的部署从这个项目里拿不到什么好处。
虚拟地址与物理显存解耦的具体做法
机制的核心是分离两件事：GPU 虚拟地址的预留，和物理显存的绑定。按照 README 的说明，服务引擎启动时只预留虚拟内存，等 KV cache 真正被使用时才把物理显存接上去。这个解耦带来两个直接结果，一是分配可以按需发生，二是不同模型之间可以共享同一块物理显存池，而不必在启动时划清边界。README 用 decoupling GPU virtual addressing from physical memory allocation 来描述这一步。需要说明的是，仓库材料里没有给出映射表的数据结构、页粒度或回收触发条件，这些只能从源码里看。README 提到的 memory control CLI 用来施加显存上限，也就是说弹性是有边界的，不是无限增长。
接入方式：跟着 examples 目录走
README 没有给出完整的安装命令，只提供了 examples 目录作为入口，例如前缀缓存的示例在 examples/09_prefix_caching。可确认的接口信息有这些：支持 SGLang 与 vLLM 两个引擎，SGLang 要求不低于 v0.4.9（测试到 v0.5.15），vLLM 要求不低于 v0.8.4（测试到 v0.24.0），Python 版本范围是 3.9 到 3.13。显存限制通过 kvcached CLI 施加，前缀缓存通过配置项设定内存上限，README 把这项能力称为 automatic prefix caching 并说明它带有 configurable memory bound。前端路由和 sleep mode 是另一个可配置的部分，用于把请求导向目标模型并在空闲时让模型休眠。具体参数名和默认值在 README 里没有展开，需要以 examples 和 CLI 的帮助输出为准。
版本区间和模型支持是硬约束
这个项目对上游引擎版本的依赖很紧。README 的表格把支持范围写成区间而不是「兼容最新版」，本身就说明问题：vLLM 从 v0.8.4 到 v0.24.0，SGLang 从 v0.4.9 到 v0.5.15，超出这个范围的行为没有承诺。注意力类型方面，MHA、GQA、MLA、sliding window 和 hybrid 都在列表内，示例模型包括 DeepSeek-V3、Qwen3-8B、GPT-OSS-20B 等。README 还专门指向 issue #425 查看每个模型在各引擎上的 KV layout 结果，也就是说逐模型的支持情况并没有全部写进主文档。升级上游引擎时，这一层适配需要跟着动，这是使用成本里最容易被低估的部分。
什么时候它反而添乱
最明显的不适用场景是单模型独占 GPU。虚拟内存映射本身有开销，也有调试成本，当显存本来就够用、负载又平稳时，这层抽象只增加了故障面。第二个风险点是版本漂移：如果你的生产环境固定在某个 vLLM 或 SGLang 版本上，而该版本不在测试区间内，那么出问题时你无法判断是引擎的问题还是映射层的问题。第三个是注意力类型，README 虽然列出了 MLA 和 hybrid 的支持，但明确把逐模型结果放在 issue 里，说明这部分仍在演进。此外，仓库材料没有提供性能数字、延迟影响或显存回收的失败模式描述，任何关于吞吐提升幅度的说法都无法从这里得到支持。
和静态切分方案的差别在哪
常见的替代做法是 MPS 或 MIG 这类 GPU 分区方案，以及各引擎自带的显存比例参数。分区方案在硬件或驱动层把 GPU 切成固定份额，切完之后每份的大小不再变化，隔离性强但灵活性差，碎片无法被其他实例回收。kvcached 走的是另一条路：不切硬件，而是在同一块物理显存上做虚拟地址到物理页的动态映射，让空闲容量可以被其他模型用上。代价是隔离性变弱，多个模型共享同一个显存池，一个模型的行为会影响池子的可用容量。选择取决于你要的是硬隔离还是高利用率，这两者在设计上是对立的。
维护成本与许可证
版本节奏可以参考已发布的 tag：v0.1.3 在 2026 年 1 月，v0.1.4 在 2026 年 3 月，v0.1.5 在 2026 年 4 月，大致是每两到三个月一个版本。但真正决定维护成本的不是 kvcached 自己的发版频率，而是它所依赖的 vLLM 和 SGLang 的升级节奏。每次上游引擎改动 KV cache 的内部结构，这层映射就需要重新验证，README 里那张带版本区间的表格就是这个现实的直接体现。项目采用 Apache-2.0 许可证，允许商用和修改，具体义务以 LICENSE 文件为准，这里不做法律层面的解读。
已经在生产里用它的例子
README 提到 Red Hat 在 2026 年 4 月介绍了基于 kvcached 的 Sardeenz 项目，用于在 Kubernetes 和 OpenShift 上做动态多模型服务，场景是在资源受限的生产环境里运行 LLM。这是仓库材料里唯一一个第三方生产使用的记录，可以作为参考，但它不构成对你自身负载的适用性证明。如果你的部署形态和这个例子接近，即多模型、资源受限、有编排层，那么它值得优先评估；如果你的形态差别很大，这个例子的参考价值就有限。
编辑结论
如果你的场景是多模型或在线离线混部在同一张卡上，且显存被静态切分浪费严重，kvcached 值得在测试环境里按 examples 目录的脚本跑一遍；如果你的部署是单模型独占 GPU、负载平稳，引入这层映射只会增加调试面。上手前先确认三件事：你的 vLLM 或 SGLang 版本是否落在 README 表格给出的区间内，你要用的注意力类型（MLA、sliding window、hybrid）是否在支持列表里，以及 kvcached CLI 的显存上限配置能否覆盖你的峰值。这三点任何一条不满足，问题都会出现在运行时的显存映射阶段，而不是安装阶段。
社区笔记