SparseEngine：稀疏优先的大模型推理引擎 SparseEngine: Sparse-First Inference Engine
以生命周期契约为核心的稀疏优先推理引擎，支持15种稀疏方法并实现最高10×解码吞吐提升
前置知识
KV缓存（KV Cache）
Transformer自回归生成时，注意力层每一步都要访问历史所有token的Key/Value张量。为避免逐步重算，推理引擎把这些张量驻留在显存中，即KV缓存。其容量随上下文长度与批大小线性增长，而注意力计算量随长度增长，长上下文Agent场景下数万token的对话与工具历史会同时挤占显存和拖慢每步解码，是推理系统的核心瓶颈。
本文的全部工作——稀疏注意力、KV驱逐、Chain Cache、前缀剪枝——都围绕KV缓存的表示、存储与生命周期展开，不理解KV缓存就无法理解论文的动机与设计取舍。
稀疏注意力（Sparse Attention）四大家族
稀疏注意力只让每个query与部分历史token计算注意力以省算力和显存。论文将其分为四类：动态稀疏（Quest、OmniKV等按query选页但保留完整历史）、KV驱逐（H2O、SnapKV等物理删除不重要条目）、KV压缩（Palu、DeltaKV等用紧凑表示替换KV）、KV量化（KIVI、TurboQuant等降低数值精度）。四类方法的状态语义、更新时机与元数据需求差异巨大。
SparseEngine的核心目标就是用一个统一生命周期契约同时容纳这四类方法，理解它们的语义差异是理解抽象设计的关键。
前缀缓存与Radix树（Prefix Caching）
前缀缓存把已完成请求的KV按token前缀组织成基数树（radix tree），新请求若与历史共享相同前缀（如系统提示词、多轮对话开头）可直接复用已算好的KV，只需对新后缀做prefill，大幅降低首token延迟。其隐含前提是历史KV必须完整驻留，任何物理删除都会破坏前缀匹配与复用。
Chain Cache与前缀剪枝正是对这一机制在稀疏场景下的重构：让被驱逐过KV的历史依然可匹配、可复用，这是论文跨请求状态管理两大创新的基础。
连续批处理与分页缓存（Continuous Batching & Paged Cache）
连续批处理在每个解码步之间动态插入或移除请求，使GPU始终保持高利用率；分页缓存借鉴操作系统的虚拟内存，把逻辑token位置映射到物理KV块，消除显存碎片并支持灵活的容量管理。二者是vLLM等现代推理引擎共享服务能力的基石，任何接入引擎的方法都不应破坏它们。
论文反复强调稀疏方法必须与continuous batching和方法兼容的prefix caching共存，Figure 1正是以这两项能力衡量各引擎的方法覆盖面。
GQA与MLA（分组查询/多头潜在注意力）
GQA让多个query头共享同一组KV头以压缩缓存，是Llama、Qwen等主流模型的配置；MLA把KV压缩为低维潜在向量，被DeepSeek、GLM系列采用。两者的KV物理布局与访问模式完全不同，对稀疏服务系统而言意味着异构挑战：内核、元数据与容量估算都要分别适配。
实验同时覆盖GQA与MLA模型（GLM-4.7-Flash），而竞品HiSparse和Tangram不支持MLA、Vortex在GLM 128K下批1即OOM，引擎的通用性正是借此得到检验。
研究动机
长上下文LLM智能体在编码、研究、推理等迭代式工作流中通过反复调用工具和推理链快速膨胀上下文历史，KV缓存容量与注意力计算延迟构成双重GPU瓶颈。稀疏注意力方法虽能选择性计算或压缩KV来缓解成本，但要在真实引擎中落地却困难重重：现有引擎把接口围绕特定缓存布局或工作流组织——Vortex只暴露页中心操作，SPIN通过GPU-CPU流水线管理分区，Tangram专为非均匀头级KV保留设计。这类接口适合部分方法却限制其他方法：Quest需要按query动态选页，而H2O还需要在生成全程维护持久注意力分数并执行物理KV驱逐。结果是方法覆盖面狭窄：实测中Vortex在GLM-4.7-Flash的128K输入下即使批大小为1也显存溢出，HiSparse和Tangram完全不支持MLA架构。此外，传统Radix前缀缓存假设历史KV完整驻留，驱逐类方法一旦删除条目便无法跨请求复用，让多轮Agent场景的缓存管理雪上加霜。
本文的目标是论文要回答一个核心问题：共享服务基础设施与方法对KV状态和计算的专属控制之间，抽象边界应该划在哪里。具体目标是构建一个从零开始、稀疏优先的推理引擎SparseEngine：其一，通过统一的生命周期契约让每种稀疏方法自定义KV表示与计算工作流，同时无修改地接入请求调度、注意力执行等公共设施，使引擎容纳横跨动态稀疏、KV驱逐、KV压缩、KV量化四大类别的15种方法；其二，把稀疏状态管理从单请求扩展到跨请求——Chain Cache让驱逐类方法跨轮复用压缩后的历史状态，可控前缀剪枝允许应用指定历史区间删除KV却不破坏逻辑前缀匹配；其三，在忠实保持各方法原有任务质量的前提下，实现KV驱逐下超10×聚合解码吞吐、同等并发下超2.5×解码加速、Agent基准上超2×端到端加速。
与已有工作不同的是，作者从编程语言设计获得启发：MATLAB的矩阵运算简化数值计算却难表达不规则控制流，SQL擅长关系查询却需递归扩展才能写迭代算法，Rust的所有权保证内存安全却约束可变状态共享——对数据或状态的假设决定了哪些计算易于表达。现有稀疏推理引擎同理：SPIN固定Index→Offload→Select→Retrieve→Attention工作流，Vortex固定缓存更新→页选择→注意力流程，都是把抽象锚定在特定计算工作流或布局上。SparseEngine的独特切入点是把边界锚定在模型原生模块执行顺序这一不变量上：沿Transformer前向路径暴露细粒度钩子，让方法自己编排计算流程而不必修改模型实现。更进一步，论文把稀疏状态管理提升到跨请求层面——Chain Cache保留被驱逐后残余KV的逻辑前缀供匹配，前缀剪枝允许应用指定区间（如失去价值的工具返回）删除物理KV却维持前缀复用，这是此前系统从未提供的能力。
核心方法
SparseEngine的直觉是：与其让引擎规定方法怎么算，不如让方法告诉引擎何时、何地做何事。技术上由三个组件构成生命周期契约：SparseController沿模型原生执行顺序暴露细粒度钩子——步骤准备、注意力前后、层结束、步结束，方法注册SparseMethodRuntime回调；CacheManager由方法自定义，拥有KV表示、物理布局、位置映射及分配、写入、更新、释放操作与持久元数据；AttentionView把方法状态连接到注意力执行，按 $View_{\ell,t}=\mathrm{BuildView}(\mathcal{C}_{\ell,t},\mathcal{I}_{\ell,t})$ 构造视图再计算 $o_{\ell,t}=\mathrm{Attention}(q_{\ell,t},View_{\ell,t})$，其中 $\mathcal{C}_{\ell,t}$ 为持久缓存状态、$\mathcal{I}_{\ell,t}$ 为选中的token或页。调度器经MemoryOracle查询方法容量需求并协调多GPU rank。在此之上，Chain Cache与可控前缀剪枝把方法状态延伸到跨请求生命周期。
核心创新是把抽象边界锚定在模型原生模块执行顺序这一不变量上，而非任何特定缓存布局或工作流。SPIN与Vortex把方法套进预定义流水线，导致Quest的页选择与H2O的分数累积加物理驱逐难以共存；SparseEngine的钩子只规定何时（prefill块、解码步、层与步边界），做什么完全由方法决定，因此同一份模型实现可执行不同稀疏方法，无需LlamaSnapKV、Qwen3H2O这类方法特定模型副本。第二个关键区分是物理驱逐与逻辑选择：前者改变驻留集、把槽位归还分配器并更新上下文长度，后者只改变注意力读取哪些驻留条目——这一语义分离让存储与访问方式迥异的方法共享同一生命周期。第三，AttentionView作为状态与内核的解耦层：Quest视图是选中KV页，OmniKV视图按跨层选择引用驻留KV，DeltaKV视图按需重建，KIVI甚至暴露量化页加残差区。最后，Chain Cache突破前缀缓存要求KV完整驻留的假设，使被压缩的历史也能跨轮复用，这是稀疏优先设计自然生长出的高层能力。
方法步骤详情
第一步，prefill：提示词切成chunked prefill块逐块前向，H2O在finish_step钩子用累积注意力分数做块级驱逐，SnapKV在最后一块后触发选择与驱逐。第二步，解码：build_decode_selection在注意力前执行Quest的query依赖页选择，finish_step更新H2O累积分数并在线驱逐；on_layer_end配合使OmniKV、DeltaKV把观察层索引复用到后续层。第三步，CacheManager存储操作：驱逐更新驻留位置映射、统计量与可用容量，KIVI管理量化页与残差区，被逐槽位归还分配器。第四步，AttentionView按 $View_{\ell,t}=\mathrm{BuildView}(\mathcal{C}_{\ell,t},\mathcal{I}_{\ell,t})$ 构造视图交给注意力后端，支持CUDA图。第五步，跨请求：请求完成时以chain_id标识的ChainCacheIndex保留每层残余KV与元数据，后续匹配逻辑前缀的请求只prefill新后缀，容量不足按LRU回收。第六步，剪枝：应用提交token_ids与区间 $[L,R)$，$\mathcal{T}=\{i\mid L\le i<R\}$，评分策略返回掩码且只对空闲块应用，得 $P'=P,\ \mathcal{R}'=(\mathcal{R}\setminus\mathcal{T})\cup\mathcal{I}$，物理释放而逻辑前缀不变。
技术新颖性
新颖性体现在三个层面。抽象层面：此前系统以方法族或布局为中心——SPIN的分区流水线、Vortex的页路由、Tangram的预算预留加Ragged Paging、HiSparse的主机内存全量KV加按需拉取——SparseEngine首次以生命周期契约为边界，钩子细到注意力前后与层、步边界，足以同时表达选择、驱逐、压缩、量化四类语义迥异的方法，实测接入15种。能力层面：Chain Cache是首个让驱逐类方法（SnapKV、KVzip、H2O）跨请求复用压缩状态的机制，并处理了不同层保留不同token位置、H2O需要持久累积分数等难题；可控前缀剪枝把KVzip式评分限定在应用指定的历史区间，在释放物理容量的同时保持逻辑前缀匹配。实证层面：论文证明通用性不以效率为代价——方法匹配对比中Quest达Vortex的1.24×、HiSparse的1.55×，SnapKV达Tangram的1.55×吞吐。讨论章节还前瞻了Agent辅助的方法集成与服务原生稀疏模型（DeepSeek-V3.2、NSA、IndexCache）的方向。
实验结果
论文围绕性能与保真两条线。性能：128K输入解码中，SnapKV凭物理驱逐支撑更大并发，Qwen3-30B-A3B以B=30达2026.0 tok/s、GLM-4.7-Flash以B=55达2799.6 tok/s，约为vanilla vLLM（B=3约211.5 tok/s）的10×；Quest/OmniKV同批下达vLLM的1.5×–2.6×。方法匹配对比中批2时Quest达Vortex的1.24×、HiSparse的1.55×，SnapKV达Tangram的1.55×。质量：LongBench V1/V2共20组总体分对比平均仅差+0.17分（方差0.32平方分）；AIME 2024全注意力81.7%，OmniKV 80.0%（1.51×）、SnapKV(8k) 80.0%（1.33×）。Agent：SWE-bench Lite上SnapKV+Chain Cache在GLM达24.7%（vanilla 25.0%）、Qwen3上8.3%反超vanilla的5.3%；Claw-Eval上OmniKV 68.0分超vanilla 67.4。端到端：Gasai上SnapKV(8K)+Chain Cache达2.24×（777.3 tok/s），SWE-lite上H2O达2.02×（610.8 tok/s）；剪枝lag=4解决率25.0%高于vanilla的23.7%。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 长上下文解码吞吐（128K输入） | 聚合解码吞吐 | SparseEngine+SnapKV：Qwen3-30B-A3B 2026.0 tok/s（B=30）；GLM-4.7-Flash 2799.6 tok/s（B=55） | vanilla vLLM v0.26.0 约211.5 tok/s（B=3） | 约10× |
| 同并发方法匹配对比（128K，B=2，Qwen3） | 解码吞吐倍数 | Quest达Vortex的1.24×、HiSparse的1.55×；SnapKV达Tangram的1.55× | Vortex / HiSparse / Tangram 专用系统 | 1.24×–1.55× |
| 长上下文质量（LongBench V1/V2，9种方法） | 总体分相对原实现的平均差 | 20组总体分对比平均差+0.17分，总体方差0.32平方分 | 各稀疏方法的原始官方实现 | 质量基本无损（Δ≈0） |
| 数学推理（AIME 2024，Qwen3-4B-Thinking） | 准确率 / 端到端加速 | OmniKV 80.0%/1.51×；SnapKV(8k) 80.0%/1.33×；Quest 76.7%/1.28× | 全注意力 81.7%/1.00× | 1.3×–1.5×加速且准确率基本保持 |
| 多轮Agent（SWE-bench Lite，mini-SWE-agent） | 解决率 | SnapKV+Chain Cache：GLM 24.7%、Qwen3 8.3%；OmniKV 26.0% | vanilla全注意力：GLM 25.0%、Qwen3 5.3% | 质量持平至反超 |
| 端到端Agent轨迹回放（Gasai） | E2E加速 / 输出吞吐 | SnapKV(8K)+Chain Cache 2.24×、777.3 tok/s（最大批72） | vanilla 1.00×、346.3 tok/s（批32） | 2.24× |
| 工具结果前缀剪枝（SWE-bench Lite 300题） | 解决率 | KVzip剪枝+lag=4：25.0% | vanilla 23.7%；无lag直接剪枝会轻微掉点（OmniKV 22.3%） | +1.3个百分点且释放KV容量 |
局限与改进
作者承认的局限：top-p采样随机性叠加LongBench V2子任务样本量小，个别子任务分数波动明显；稀疏预算过激会显著伤质量——AIME上SnapKV低预算4k仅58.3%、PyramidKV 53.3%、StreamingLLM 18.3%；H2O在GLM的SWE-bench Lite上跌至13.0%（vanilla 25.0%）；Quest在Gasai回放中0.85×慢于vanilla；前缀剪枝需要lag=4的手工延迟策略才能恢复性能。我自己的观察：主实验集中在少数模型，对70B级稠密模型及其他MLA实现未验证；Chain Cache按LRU回收，多会话高并发下可能出现链状态反复重建的抖动，缺乏压力测试；剪枝区间与保留率需应用方指定，缺少自动机制；AIME加速比（1.05×–1.66×）明显低于128K场景，因短上下文中注意力占比小，收益强依赖上下文长度与批规模的组合。
独立分析的弱点
独立分析三点弱点。第一，稀疏预算需要人工调参：同一SnapKV在4k/8k/16k预算下AIME准确率从58.3%到85.0%剧烈波动，Agent任务中过高或过低预算都劣化表现，实践缺乏自动选择预算的方法——改进方向是把预算选择建模为在线质量监控下的自适应控制，利用Chain Cache已保存的方法元数据做事后校验与回滚。第二，前缀剪枝策略手工且保守：lag=4只是简单保护最近四轮工具结果不剪，本质是承认KVzip全局评分无法区分近期将再用的证据，改进方向是引入使用统计（哪些区间被后续注意力频繁命中）指导剪枝，甚至训练轻量预测器估计历史区间的未来效用，实现真正的自适应记忆管理。第三，通用性与极限性能的差距依然存在：虽然方法匹配对比领先，但每层的钩子调用、视图构建和元数据维护在稀疏收益小的工作负载（如Gasai上的Quest仅0.85×）会变成纯开销——改进方向是运行时剖面检测稀疏收益低于阈值时自动退回全注意力快路径，并把钩子逻辑编译进CUDA图以消除launch开销。
未来方向
作者在讨论章节明确提出两个方向：一是Agent辅助的方法集成——构建集成测试框架引导编码Agent参照参考模块实现新稀疏方法，并自动检查方法保真度与缓存生命周期正确性，借编码Agent降低的实现成本换取每个方法更大的自由度，加速方法接入；二是服务原生稀疏模型——DeepSeek-V3.2已把稀疏注意力内置进模型架构，NSA学习原生稀疏模式，IndexCache跨层复用选择索引，这些机制与生命周期钩子天然契合：钩子恰好暴露选择状态何时产生与复用；原生稀疏执行还为保留状态上的驱逐、量化、压缩打开组合空间。基于论文成果可以延伸的方向：把Chain Cache与前缀剪枝组合成Agent记忆分层（热KV驻留、温KV剪枝压缩、冷KV落盘）以支持数天跨度的长程任务；将剪枝评分与Agent工具语义结合，例如工具返回被总结后自动触发区间剪枝；在RL训练中复用Chain Cache加速轨迹采样与回放；以及对15种方法做系统的质量-效率帕累托分析，形成场景化的方法选择指南。
复现评估
复现条件较好。代码开源于 https://github.com/CURRENTF/SparseEngine；评测全用公开基准：LongBench V1/V2、AIME 2024（每题2次采样共60次响应）、SWE-bench Lite（300题）、Claw-Eval及Gasai轨迹回放；模型均为开源权重（Llama-3.1-8B、Qwen3-4B-Thinking、Qwen3-30B-A3B、GLM-4.7-Flash、Qwen3.6-27B），覆盖GQA、MoE、MLA、线性注意力混合架构。附录C完整记录评测协议、方法超参（SnapKV预算4k/8k/16k、剪枝lag=4、KVzip保留20%）与硬件配置，基线（vLLM v0.26.0、Vortex、HiSparse、Tangram）均有公开实现。主要门槛在算力：主结果需H100/H20级GPU运行30B MoE并跑到B=55以上批量，GLM还需TP=2；不过4090/5090也在支持之列，单卡复现质量对比（8B/4B模型）是可行起点，完整吞吐复现需数据中心级资源。
论文图表
把稀疏推理方法按四大类别（动态稀疏、KV驱逐、KV压缩/量化）与服务能力（前缀缓存、连续批处理、批量推理）画在一张覆盖图中，轮廓线圈出代表性实现：SPIN、Vortex、SparseFrontier、Tangram等系统只覆盖部分方法与能力组合，Quest、H2O、SnapKV、KIVI、Palu等方法的能力需求各不相同，而SparseEngine的轮廓包含全部15种方法及共享服务能力。
一图道出论文动机：现有系统覆盖面窄、方法多样性与服务能力难以兼得，SparseEngine的目标正是补齐整个方法-能力空间。