你让 AI 读完一份很长的材料，再一步步写出答案。它每写一个词，都要翻看此前留下的“速查笔记”。材料越长，笔记越厚；当显存放不下时，即使计算芯片还有余力，服务也很难同时处理更多请求。
这份速查笔记叫 KV Cache——模型保存的中间计算结果，可以避免生成新词元时从头重算。词元是模型处理文字的基本单位，大致可以理解为被切分后的文字片段。HBM（High Bandwidth Memory）则是加速器旁边速度很快、但容量有限且成本较高的显存。长上下文推理正在撞上的“显存墙”，很大一部分就来自不断膨胀的 KV Cache。
OasisKV 的思路是：不要强求把整本笔记都摊在桌面上。完整 KV Cache 可以留在容量更大的主机内存或远程内存里，HBM 只保存眼下真正重要的部分。系统还会提前猜下一步要查哪些页，在模型用到之前把它们搬回来。
OasisKV 由 Sukmin Cho 提出，并基于 LLM 推理引擎 vLLM 实现。下文的效果数字均来自论文自身实验，尚不能视为跨模型、跨硬件环境都成立的普遍结论。
难点不在搬出去，而在及时搬回来
“推理”在这里指训练完成的模型实际接收请求并生成结果；“解码”则是模型一个词元接一个词元写出答案的阶段。每一步解码都很短。如果系统等到模型需要某段 KV Cache 时才去主机内存取，搬运就会卡在生成路径上，模型只能停下来等数据。
因此，单纯把缓存移出 HBM 并没有解决问题，只是把容量压力换成了传输延迟。OasisKV 真正要解决的是两个问题：下一步会用到哪些缓存，以及怎样让搬运在后台及时完成。
论文利用了解码期注意力的稀疏性。所谓“注意力”，可以理解为模型生成当前词元时，对此前内容分配不同程度的关注。并非每一步都会同等依赖全部历史词元。OasisKV 因而只保留当前最相关词元对应的 KV entries，也就是缓存中的具体条目。
这仍不是把缓存“完全搬出显存”。HBM 中一直保留一个有限的工作集，并暂存马上要参与注意力计算的条目；完整副本才位于主机或远程内存。
先偷看下一步，再准备资料
OasisKV 的关键线索来自 speculative decoding（推测式解码，简称 SD）。这种技术会先用草稿模型或多词元预测模块，试着写出几个未来词元，再由主模型处理。OasisKV 不只把这些草稿词元用于加速生成，还把它们当成“下一步可能问什么”的提示。
可以把它想成会议助理提前看到发言提纲。助理不必等主讲人真正开口，便能预先把可能引用的文件摆到桌面上。这里的“文件”，就是未来解码步骤可能需要的 KV blocks——按块组织的缓存数据。
草稿词元进入与正常解码共享的前向计算。OasisKV 从中得到未来的查询信号，再扫描压缩后的 key 摘要，为每个注意力头预测重要缓存块。注意力头可以理解为模型内部并行查看上下文的不同视角。摘要只记录每个逻辑块中 key 的坐标最小值和最大值，因此不必把完整 key 搬回 HBM，也能在全上下文范围内进行排序。
这套预测不要求部署者专门训练一个新预测器。不过，提供草稿词元的 draft model（草稿模型）或多词元预测模块本身仍可能经过训练。论文所说的“training-free”，限定在部署 OasisKV 不需要额外设计、训练或调优专用预测器。
搬运必须躲到后台
预测之后还有三件事：找出重要块、比较哪些块已经驻留、把缺少的块搬进 HBM。OasisKV 将它们拆成后台流水线，并为不同阶段使用独立的 CUDA stream——可以理解为 GPU 上并行推进任务的执行通道。
各层的预测、选择和传输可以交错进行。前台在处理当前解码步骤时，后台已经为下一步准备数据；前台到达某一层时，只等待这一层此前发起的传输，不必在整步开头等所有层全部完成。
系统还限制每一步新搬入的块数。它先复用已经驻留且仍被预测为重要的块，再从其余块中优先淘汰最久没有被选中的内容。这样，传输量不会因为预测结果突然变化而无限增长。代价是并非所有新预测出的块都会立刻进入 HBM，准确率、缓存容量与传输带宽之间需要折中。
在缓存管理上，OasisKV 为不同注意力头维护各自的稀疏映射，同时沿用 vLLM 原有的分页式缓存池。请求起初可以密集运行；上下文超过设定阈值后，系统把完整 KV Cache 复制到 CPU 内存，只在 GPU 中留下选中的历史块和局部窗口。
为什么它不只适合单机
OasisKV 也面向 prefill–decode disaggregation，即把“读入提示并建立缓存”的 prefill 阶段与逐词生成的 decode 阶段放到不同节点。传统做法可能先把完整 KV Cache 搬到解码节点的主机内存，再开始解码。这既增加首个词元前的等待，也会占满解码节点的 DRAM（主机内存）。
OasisKV 在交接时只传第一步需要的缓存块、压缩 key 摘要和草稿词元状态。此后若选择结果发生变化，解码节点再从远端按需取回缺少的块。每个块跨网络传输至多一次，从未被选中的块则不传。
这让“稀疏”同时作用于 HBM、网络流量和解码节点的主机内存，而不只是减少一次注意力计算读取的数据。
数字说明了什么
论文在配有八张 80 GB HBM3 NVIDIA H100、2 TB 主机内存的服务器上测试了 OasisKV，覆盖 Qwen3-8B、Qwen3-235B-A22B 和 Llama-3.1-8B-Instruct，并包含单 GPU、多 GPU及分离式部署。
在每个注意力头约 2,048 个词元的 KV budget（即允许驻留和参与选择的缓存预算）下，论文报告其任务指标与 full attention——每步查看完整历史缓存的注意力方式——相差不超过 0.7 points。这里的 points 指相应任务指标的点数，不能直接解释为模型整体准确率。
在 reasoning workload（推理任务负载）中，论文称 OasisKV 相比 dense vLLM 获得 1.69 倍吞吐，同时任务指标损失为 0.1 points。吞吐指系统单位时间处理的输出量。在多 GPU 长上下文服务中，论文报告的最高吞吐提升为 2.1 倍。“最高”意味着这是实验中的最佳结果，并不代表所有设置都能达到。
在 prefill 与 decode 分离的场景中，OasisKV 达到约 2 倍于 dense 基线的吞吐；每接纳一个请求所需的 KV 容量减少 6.5—9.7 倍。它说明这项工作的价值不只是让单个请求少占显存，更在于让同一套设备容纳更多长上下文请求。
为什么值得现在看
长上下文服务的瓶颈正在从“算不动”转向“放不下、搬不及”。OasisKV 的有趣之处，是把推测式解码产生的未来词元变成缓存调度信号：同一份前瞻信息既服务生成，也帮助内存系统提前行动。
它还把预测、缓存淘汰、PCIe 搬运和远程取数放在同一个约束下考虑。说白了，预测得准还不够；数据必须在有限带宽内按时到达，而且不能为了减少传输又把 HBM 塞满。OasisKV 试图把这几个互相牵制的问题一起解决。
局限与未知
- 论文的主要效果来自作者自己的系统实验。模型、上下文长度、并发度、硬件和基线配置都会影响结果，1.69 倍、最高 2.1 倍和约 2 倍不宜脱离这些条件外推。
- 稀疏工作集会带来任务指标与资源效率之间的取舍。论文在约 2,048-token 预算下报告的差距不超过 0.7 points，但这不等于所有任务都能保持同样表现。
- 摘要关于解码节点主机内存“2.2—2.6”变化的原句单位和语法不完整，因此本文不采用该数字。当前原型还会在请求完成前，将完整 KV Cache 保留在 prefill 节点的主机内存中。