vLLM 为 GLM 5.3 引入混合稀疏卸载，缓解百万上下文显存压力

导语

长上下文模型真正难以部署的地方，往往不是一次请求能否跑通，而是多条请求同时增长时，KV Cache 会持续挤占 GPU 显存。对于包含大量工具调用和多轮交互的智能体应用，传统方案要么在缓存耗尽后抢占请求、重新预填充，要么把 KV 搬到主机内存，但在密集注意力下仍需要把完整历史重新放回 GPU，并发能力很快触顶。

vLLM 在面向 GLM 5.3 的优化中，引入了 Hybrid HiSparse，试图把稀疏注意力的访问模式转化为内存管理优势。

核心要点

• 只在有压力时卸载。 KV Cache 默认继续驻留 GPU；只有共享的 GPU block pool 变紧张时，系统才按页面释放较旧数据，避免无压力场景承担额外的 CPU-GPU 传输成本。
• 利用 sparse MLA 的 Top-K 访问。 GLM 5.3 的索引器会从历史中选出少量 token。HiSparse 将未被选中的大部分 KV 放到 CPU，仅把索引器需要的行载入 GPU 热缓冲区。索引器 KV 本身不由 HiSparse 接管，可继续使用常规卸载机制。
• 热缓冲区与普通 KV 共用资源。 热页不是一块独立的特殊内存，而是由 vLLM Hybrid Memory Allocator 从同一 block pool 中动态租用。因此，请求可以同时拥有 GPU 常驻页、CPU 页和热缓冲页，并在压力变化时调整状态。
• 避免请求反复重算。 当某些历史页被淘汰后，解码仍可读取 CPU 中被选中的行；命中热缓冲区时直接复用，未命中时再从固定主机内存复制单行数据。这样，缓存被部分释放的请求不必等待完整 KV 恢复，也不必重新预填充。
• 兼容 vLLM 现有组件。 该方案作为共享 HMA 池上的驻留策略和连接器运行，其他缓存组、前缀缓存、P/D 分离导入以及推测解码仍可沿用相应机制。

工作方式与测试

系统为每个请求维护三种状态：完整驻留、混合驻留和无 GPU 驻留。完整驻留时，稀疏 MLA 的 KV 都在 GPU 上，同时将已完成的前缀页提前复制到主机；进入混合状态后，尾部仍留在 GPU，较旧页面只保存在 CPU，而索引器需要的 token 进入热缓冲区；新请求复用仅存在于 CPU 的前缀时，则从占位符和热页开始，按实际注意到的历史逐行加载。

由于热页和常规 KV 页使用同一个张量布局，解析器可以把两类数据交给同一套行 ID 和聚合逻辑。vLLM 还将稀疏 MLA 各层的预备复制合并为一次启动，并利用 GPU 流顺序和 CUDA 事件处理跨线程并行环境下的数据可见性。这使解码路径不需要等待 CPU 做出新的驻留决策，也保留了 CUDA Graph 捕获的可能性。

官方在单个 8×H200 节点上，使用 GLM 5.3、MTP3、FP8 KV Cache 和 OpenHands 多轮智能体工作负载进行对比测试。基线是常规 KV 卸载，实验方案则把主机预算分配给 HiSparse 和普通卸载。测试覆盖不同上下文长度与并发设置，重点观察交互延迟、逻辑 token 吞吐及运行中请求数。素材显示，Hybrid HiSparse 能让请求在缓存受压时继续解码，并在更长上下文下维持更高并发；具体收益仍取决于模型访问稀疏度、主机内存带宽和工作负载形态。

意义与局限

这项设计的关键并不是简单增加一个 CPU 缓存，而是把“哪些 token 会被访问”纳入 KV 驻留决策。对 GLM 5.3 这类采用 sparse MLA 的模型，GPU 不必长期保存完整历史，只需优先保留尾部和近期会被索引器选中的内容。由此，系统可以在显存紧张时平滑降级，而不是在抢占和完整恢复之间二选一。

不过，收益并非无条件存在。热缓冲区命中率、CPU-GPU 互联速度、请求的上下文增长方式都会影响传输开销；索引器 KV 仍然需要 GPU 空间，且不同模型的稀疏注意力结构不能直接照搬这一策略。vLLM 计划在后续版本中扩大 Hybrid HiSparse 的可用范围。对部署者而言，它更适合作为长上下文、多并发服务的内存调度补充，而不是替代所有传统 KV 卸载方案。

来源：vLLM Blog