SparseEngine：让长上下文智能体推理从稀疏缓存开始

长上下文正在成为 LLM 智能体基础设施的现实压力。智能体每次对话、工具调用和任务迭代都会留下历史记录，这些内容通常需要以 KV cache 形式保留。随着上下文变长，缓存不仅消耗更多显存，也会扩大注意力计算量。稀疏注意力和 KV 淘汰可以缓解问题，但不同方法往往采用不同的缓存布局、保留策略和执行流程，因此很难直接嵌入 vLLM 等通用推理引擎。

SparseEngine 的思路不是在现有引擎上增加少量稀疏优化，而是从稀疏场景出发重新设计服务层。其核心是一个共享的生命周期契约：每种方法可以自行决定 KV 如何表示、哪些内容被保留以及如何执行计算；公共服务基础设施则负责协调请求处理过程中的状态转换。这样，算法实现与调度、请求管理等通用能力之间形成了更清晰的边界。

核心要点

• 系统支持四类、共 15 种稀疏或 KV 管理方法，覆盖不同的缓存表示与工作流。
• Chain Cache 面向跨请求场景，可利用保留下来的历史，让 KV 淘汰方法在后续请求中继续工作，而不是每次从完整上下文重新开始。
• 可控的 Prefix-Cache Pruning 能删除指定历史区域中的 KV，同时保留逻辑上的前缀匹配关系，兼顾缓存复用与上下文压缩。
• 论文报告称，在 KV 淘汰场景中吞吐提升超过 10 倍；在相同并发度下，解码速度超过 vLLM 的 2.5 倍；智能体基准端到端速度提升超过 2 倍。摘要未给出这些测试的硬件、模型和具体配置，因此这些数字应结合论文正文理解。

这项工作的意义在于，它把稀疏推理从单个算法优化提升为服务架构问题。对于长上下文智能体，真正困难的不只是减少一次注意力计算，还包括在多轮请求之间正确保存、恢复、裁剪和复用状态。若这种统一接口能够覆盖更多稀疏策略，开发者就不必为每种 KV 表示分别改造一套服务系统。不过，实际部署效果仍会取决于模型、上下文分布、缓存命中率和质量容忍度。SparseEngine 更像是一个面向研究与工程探索的基础设施起点，而不是对所有工作负载都成立的通用加速结论。

代码已公开，项目地址为 https://github.com/CURRENTF/SparseEngine。

来源：Hugging Face Daily Papers