导读

阿里云 Tair KVCache 团队联合 SGLang HiCache Team 、蚂蚁 AI Infra-推理服务团队、阿里云服务器震旦异构计算团队，共同推出面向 Sparse Attention 的分层稀疏化框架，本文详细介绍该框架的架构设计与实现细节。

在前文《智能体式推理对 KVCache 的挑战与 SGLang HiCache 技术深度剖析》中，我们详细介绍了 HiCache 如何通过分层存储架构（GPU → CPU → 远端存储）突破 KVCache 的容量瓶颈，将有效缓存容量从 40GB 扩展至 TB 级别，使长上下文、高并发的 LLM 推理服务得以规模化部署。

然而，当上下文长度跨越 128K 甚至迈向百万 Token 时，两个新的瓶颈开始凸显：

• 计算瓶颈：Attention 计算成本随序列长度线性增长，并受限于 HBM 带宽。动态稀疏注意力（DSA）通过"Select-then-Compute"范式选择 Topk Token 参与 Attention 计算，成功突破了这一瓶颈。
  
• 容量瓶颈：引入 DSA 后，主要瓶颈从 HBM 带宽转移到了 HBM 容量——为确保低延迟，全量 KV Cache 仍需驻留 GPU，导致并发推理能力受限。
  

本文引入了分层稀疏化——将全量 KV Cache 存储在 CPU，GPU 中仅维护 Top-k 的 LRU Buffer——为破解这一双重约束提供了可行路径。本文将系统性介绍 SGLang 的分层稀疏化框架设计，包括：

• 整体架构：SparseCoordinator、Algorithm、BackendAdaptor、SparseKVCacheManager 的模块化设计；
  
• 核心机制：Sparse Diff Kernel 的增量传输、I/O Kernel 的高性能传输优化；
  
• 实践案例：DeepSeek DSA 的深度集成，实现单请求显存占用从 8GB 降至 200MB，3倍单机吞吐提升；
  

分层稀疏化标志着 KVCache 管理范式的又一次跃迁：从 HiCache 的"分层存储 → 扩展容量"，到本文的"稀疏化 + 分层 → 突破带宽与容量双重约束"，为超长上下文推理开辟了全新的技术路径。(注：此项目目前处于开发阶段，尚未正式发布。)

本系列技术文章将系统性拆解面向智能体推理的KVCache技术演进路径：

1.智能体式推理对 KVCache 的挑战与 SGLang HiCache 技术深度剖析

2.3FS-KVCache 工程化落地：企业级部署、高可用运维与性能调优实践

3.Hybrid Model Support：SGLang 对 Mamba-Transformer 等混合架构模型的支持方案

4.Tair KVCache Manager：企业级全局 KVCache 管理服务的架构设计与实现

5.KVCache 仿真分析：高精度的计算和缓存模拟设计与实现

6. 本文｜Hierarchical Sparse Attention：分层稀疏注意力框架下的 KV 分层管理与按需加载

7. 展望：KVCache驱动的软硬结合演进

1. 引言：双重瓶颈与协同破解之道

1.1 HiCache：容量扩展的胜利与新的战场

在前文《智能体式推理对 KVCache 的挑战与 SGLang HiCache 技术深度剖析》中，我们详细介绍了 HiCache 如何通过分层存储架构（GPU 显存 → CPU 内存 → 3FS 远端存储）突破 KVCache 的容量瓶颈。通过智能的热度感知调度与异步预取机制，HiCache 将原本仅有 40GB 的 GPU 显存扩展至 TB 级别的有效缓存容量，使得长上下文、高并发的 LLM 推理服务得以实现规模化部署。

在真实生产环境中，HiCache 已展现出显著价值：缓存命中率从 40% 提升至 80%，平均 TTFT 下降 56%，推理 QPS 提升 2 倍。

然而，当我们将目光投向更极致的长上下文场景——例如 128K 甚至百万级别的上下文窗口时，新的瓶颈开始浮现。

1.2 长上下文的 HBM 带宽墙：从线性增长到稀疏化破局

1.2.1 Attention 计算的带宽瓶颈

在长上下文推理中，Attention 计算呈现出独特的性能特征。每个 Decode 步骤需要将完整的 KV Cache 从 HBM 加载到计算单元，执行Attention计算。由于 KV Cache 随序列长度线性扩展，Attention 计算成本也随之线性增长。

关键问题在于 Attention 的计算强度（Arithmetic Intensity）过低——相对于海量的访存操作，实际的浮点运算量不足以饱和 GPU 的计算单元。这使得 Attention 成为典型的 memory-bound 操作，Attention 计算受限于 HBM 带宽。随着上下文长度从 32K 扩展至 128K 甚至百万级别，这一带宽瓶颈成为长上下文推理的主要性能制约因素。

1.2.2 动态稀疏注意力（DSA）的 Select-then-Compute 范式

为突破带宽瓶颈，动态稀疏注意力算法（Dynamic SparseAttention, 后文简称 DSA）从 Attention 机制的本质特性出发：在自回归生成过程中，并非所有历史 Token 都对当前输出贡献相同的权重。研究发现，Attention 分布往往呈现显著的长尾特征——少数关键 Token 占据了绝大部分的 Attention Score，而大量 Token 的贡献可以忽略不计。更重要的是，这些关键 Token 的集合在不同 Query 间动态变化，无法通过静态规则预先确定。

DSA 将这一观察转化为 "Select-then-Compute" 工作流，通过三个协同阶段实现稀疏化：

• 分块与元数据抽象：将 KV Cache 划分为固定大小的块（block size 通常为 32 tokens），每个块维护轻量级的元数据结构。这些元数据可以是 Key 向量的统计摘要（均值、方差）、Bounding Box（每维度的最大/最小值）、或经过降维的紧凑表示。元数据的存储开销通常不到完整 KV Cache 的 1%，可以常驻 GPU 内存。
  
• 快速重要性评估：对于每个新生成的 Query Token，算法无需访问完整的 Key Cache，而是基于元数据快速计算每个块的 Criticality Score。这一评估过程的计算量远小于完整 Attention（通常为 O(n/32) vs O(n)），且可以高效并行化。随后通过 Top-k 选择算法（如 heap-based selection），筛选出最相关的 k 个块（典型值 k=2048，对应 64 个块）。
  
• 按需稀疏计算：仅对选中的 Top-k 块加载其完整的 Key 和 Value Cache，执行标准的 Scaled Dot-Product Attention。未被选中的块则完全跳过，避免了不必要的 HBM 访问。
  

代表性 DSA 算法包括：

• Quest：训练无关的启发式算法，利用 Query-Key Bounding Box 的几何关系近似估计 Attention Score 上界。通过维护每个块在各维度上的 Key 最大/最小值，Quest 可以在不访问完整 Key 的情况下，快速排除不重要的块。
  
• ClusterKV: 将 Prefill 阶段的所有 Keys 向量进行聚类（如 K-means），生成 C 个聚类中心；每个原始 key 被映射到其最近的 centroid; Decode 阶段 Query 跟聚类中心计算，获取最具相关的 Topk。
  
• DeepSeek DSA：作为模型原生的稀疏注意力机制，通过专门训练的 Indexer 模块动态预测 Token 重要性，Indexer 的输出直接指导 Top-k 选择。
  

1.3 隐形的显存墙：稀疏计算的容量困境

尽管稀疏注意力在计算层面取得突破，但其执行流程存在固有的先后依赖关系：

在 Stage 1 中，算法需要评估每个 Token/Page 的重要性（计算 ）；在 Stage 2 中，基于评分选择 Top-k；只有在 Stage 2 完成后，Stage 3 才知道应该对哪些 KV 进行计算。

这一依赖链导致了一个根本性问题：在确定 Top-k 之前，系统无法预知需要哪些 KV 数据，因此必须将全量 KVCache 保留在 GPU 中。

关键约束：稀疏化实现了计算复杂度的降低（O(n) \rightarrow O(k)），但显存占用复杂度依然保持 O(n)；也即采用 DSA 后，主要性能瓶颈从 HBM 带宽转移到了 HBM 容量；这一容量约束导致：

1. HBM 容量利用率低下（Poor HBM Capacity Utilization）：98.4% 的 KV Cache 在每步中未被访问，却占据宝贵的 HBM 空间。

2. 并行能力受限（Limited Parallelism）：小 Batch Size 无法充分发挥 GPU 的并行计算能力，推理吞吐难以提升；例如对于 DeepSeek V32，单个 128K 请求的 Latent Cache 占 8 GB，H200 扣除模型权重后，最多只能支持 Batch=5，这严重限制了 GPU 并行计算能力的发挥。

3. 分层存储价值受阻（Value Blockage）：传统的 KV Cache Offload 方案要求所有数据在 Decode 前加载到 HBM，无法与 DSA 的动态选择特性协同工作。

1.4 分层稀疏化：存储与计算的协同优化

破解显存墙的关键洞察在于：既然 Attention 计算只需要 Topk 部分，何不只在 GPU 中存储 Topk 部分，并结合 CPU HICache，在计算完 Topk 后动态加载增量的 Topk 部分？

分层稀疏化的关键是改变 KVCache 的存储位置和加载时机（下面以 DeepSeek DSA 为例）：

• 传统流程：完整 Latent Cache 必须驻留在 GPU 显存中。Decode 阶段执行 Indexer 选择 Top-2k，然后对选中的部分进行 Attention 计算。单个 128K 请求，虽然理论计算量降低了 60+ 倍，但显存占用依然是 O(n)，占用 8 GB，H200 最多支持 Batch=5；
  
• 分层稀疏化流程：Prefill 后将完整 Latent Cache（8 GB）Offload 至 Host 内存，GPU 仅保留轻量 Sparse Indexer 元数据。Decode 时基于元数据在 GPU 执行 Indexer 选择 Top-2k，Host 筛选对应的 Latent 子集并增量传输至 GPU，最后执行 Attention 计算；

• 单请求 GPU 显存占用降至 < 200 MB，单 GPU 可支持 ；
  
• 其中， 代表单卡可分配的最大 CPU 内存容量；B_{SLO}代表满足 SLO 延迟要求的最大 Batch Size。
  

核心优势：

• 完整 KVCache 存储在 Host，突破 GPU 显存物理空间限制；
  
• GPU 侧只需存储轻量 Sparse 元数据和 Topk 部分 KVCache，Req 显存占用从O(n)降至 O(k)；
  
• 高性能传输：结合 HICache IO Kernel 实现 Topk Cache 高性能传输，单层 IO 延迟控制在 us 级别；并结合 Overlap 能力将 IO 延迟隐藏在计算中。
  

分层稀疏化不仅解决了计算问题，更从根本上破解了显存容量的刚性约束，实现了计算效率与存储效率的协同优化，为超长上下文推理开辟了全新的技术路径。

2. SGLang 分层稀疏化框架设计

2.1 整体框架设计

SGLang 的分层稀疏化框架采用模块化、可插拔的三层架构设计，通过标准化接口实现算法解耦、后端兼容与非侵入式集成。框架核心由以下模块构成：

• SparseCoordinator（协调层）：通过生命周期钩子编排三大功能模块的协同工作

• Algorithm（算法层）：提供可插拔的 Top-k 选择策略实现；
  
• BackendAdaptor（适配层）：完成稀疏索引到物理地址的转换与后端对接；
  
• SparseKVCacheManager（传输层）：基于 Diff & IO Kernel 实现 Host-GPU 间的高效、增量数据传输。
  

• RequestTrackers（状态管理）：维护每个请求的稀疏化状态管理。
  

该架构既原生支持模型内置的稀疏化机制（如 DeepSeekV32 DSA），也允许 Training Free 的稀疏化算法（Quest / SnapKV）与通用 Attention 后端（FlashAttention / Triton）灵活组合，为长上下文推理场景提供统一且高度可扩展的分层稀疏化方案。

2.2 SparseCoordinator：稀疏化流程编排器

SparseCoordinator 是分层稀疏化框架的中枢控制器，通过生命周期钩子函数（Lifecycle Hooks）在模型推理的关键节点精确编排 Algorithm、BackendAdaptor 和 SparseKVCacheManager 三大模块的协同工作。其设计遵循事件驱动模式，将 Retrievable Sparse 的完整流程解耦为标准化的钩子接口，实现了算法与模型的零侵入集成。

SparseCoordinator 将稀疏化推理划分为两个核心阶段：

• Representation Construction Phase（Prefill 结束或 Decode 初期）：通过 attention_end hook 调用 Algorithm 的 construct_representations() 和 update_representations() 方法，将原始 KVCache 压缩为语义表示并存入 Representation Pool，此阶段执行完整 Attention 计算以确保表示质量；
  
• Query-Guided Decoding Phase：每个 Decode Step 在 attention_begin hook 中，Coordinator 驱动 Algorithm 基于当前 Query 从 Representation Pool 中执行 retrieve_topk() 选择最相关的 Top-k 表示，随后由 BackendAdaptor 完成逻辑索引到物理索引的转换并触发 SparseKVCacheManager 的增量数据传输（通过 Diff Kernel 计算 Topk 集合差异，仅加载变化部分），最终动态重构 Attention Metadata（如 FlashAttention 的 PageTable）供 Attention 后端执行稀疏化计算；
  
• 通过这种"捕获-计算-转换-注入"的闭环设计，SparseCoordinator 在保持框架灵活性的同时，实现了高效的 KVCache 分层管理。
  

2.3 可插拔的稀疏化策略

在 SparseCoordinator 的编排下，Algorithm 和 BackendAdaptor 作为两个核心功能模块，分别负责"选择什么"和"如何映射"的问题，通过清晰的接口定义实现了高度的可插拔性和扩展性。

2.3.1 Algorithm：抽象的 Top-k 选择策略

Algorithm 层采用抽象基类 BaseSparseAlgorithm 定义统一接口，将稀疏化算法的核心逻辑解耦为三个标准化方法：

• retrieve_topk(queries, layer_id, ...)：

• 基于当前 Query 从 Representation Pool 中检索 Top-k 重要 Token/Page 的逻辑索引；
  
• 算法只需返回"逻辑索引"（Token ID 或 Page ID），无需关心底层 KVCache 的物理存储布局和 Attention 后端的实现细节（FlashAttention / Triton）。
  

• construct_representations(...)：在 Prefill 阶段或 Decode 阶段初期构建用于检索的 Representation Pool 语义表示（如 Key 的压缩表示）。
  
• update_representations(...)：在 Decode 阶段增量更新 Representation Pool。
  以 Quest 算法为例：
  
• Quest 是一个 Training Free 的 page-wise 稀疏注意力算法，通过为每个 KV Page 维护 per-dimension 的 Key Bounding Box（min/max 值）来避免完整的 Query-Key 点积计算；
  
• 在 construct_representations 阶段，算法遍历所有 Pages 提取 Keys 并计算 Keys 在每个维度的最小/最大值存入 page_k_min/max Representation Pool （内存开销约为完整 Key 存储的 1%）；
  
• 在 retrieve_topk 阶段，通过 criticality 计算 Attention Score 的上界估计，快速筛选 Top-k Pages 后交由 BackendAdaptor 完成物理地址转换。
  

2.3.2 BackendAdaptor：索引转换与后端对接的桥梁

BackendAdaptor 层解决了"逻辑世界"到"物理世界"的映射问题。不同的 Attention 后端（DSA Backend、FlashAttention、Triton FA3）对输入数据的格式和索引方式有不同要求，Adaptor 负责屏蔽这些差异。

以 FlashAttention Adaptor 为例：FlashAttentionAdaptor 通过 req_to_token 映射表将逻辑 Page IDs 转换为物理页号，重构 PageTable 并更新序列长度元数据（cache_seqlens, cu_seqlens_k），使 FlashAttention 能够基于 Top-k 选中的稀疏页执行注意力计算。

2.4 DeepSeek DSA 接入实践

2.4.1 DeepSeek SparseAttention 介绍

和 DeepSeek-V3.1 相比，DeepSeek-V3.2 的架构改动是在继续训练过程中引入了 DeepSeek Sparse Attention（DSA）。

DSA的原型设计由两部分进行构成，Lightning Indexer（闪电索引器）和 Fine-grained Token Selection Mechanism（细粒度 Token 选择机制）。其首先通过一个轻量级的索引器，进行快速筛选出与当前查询 Token 最相关的候选 Tokens，然后仅在这部分稀疏的候选集上执行高精度的注意力计算。

(注：图片出自 DeepSeek 论文)

2.4.2 DeepSeek DSA 整体接入流程

关键设计包括：

• 双缓存映射：系统维护两套独立的物理地址映射表（DSADecodeReqToTokenPool）：req_to_token 中存储每个 Req 对应的  Latent Cache LRU Buffer 页表（LRU Size = 2～4KB），req_to_dsa_index_k 存储 indexer_k 页表。Prefill 阶段，Indexer 模块为每个 Token 生成 index_k，存储至 GPU 端；同时完整的 Latent Cache 被 Offload 至 CPU 内存。Prefill 阶段结束后，每个 Req 占用的显存空间会固定在 LRU Size。
  
• 增量传输机制：Decode 阶段，每个 Token 生成时，Indexer 基于当前 Query 和历史缓存的 index_k 高效计算出 Top-2K Tokens 逻辑索引；随后 Sparse Diff Kernel 通过集合差分算法比较 prev_topk 和 curr_topk，精确计算出需要新加载的索引变化量 Δ；SparseKVCacheManager 据此调用 load_to_device_per_layer 仅传输 Δ 对应的 Latent Cache 块到 GPU 的 LRU Buffer，最小化 PCIe 带宽消耗。
  
• 零侵入集成：DeepSeek DSA 通过 SparseCoordinator 的生命周期钩子与模型解耦集成，DeepSeekDSAAlgorithm 作为 Algorithm 层的具体实现直接调用模型原生的 Indexer；DSABackendAdaptor 负责将逻辑 Top-k 索引转换为物理设备地址并触发增量传输；最终由 DSA Backend（支持 flashmla_sparse/flashmla_kv/fa3 等多种实现）基于稀疏页表执行 Attention 计算。这一设计使得 128K 长上下文推理的 GPU 显存占用从约 8GB 降至约 200MB。
  

2.4.3 Sparse Diff Kernel: 增量 Cache 传输基石

动机：时间局部性带来的优化空间

DSA 的 Top-k 选择结果在时间维度上呈现显著的局部性：相邻 Decode Steps 的 Top-k 集合高度重叠。实验表明，相邻 Steps 的 Top-k 重合度通常达到 80%～90%，这意味着每个 Decode Step 理论上仅需加载不到 20% 的新 Cache，为增量传输提供了天然的优化空间。

Buffer 容量与命中率的权衡

然而，随着序列长度的增长，Top-k 选择的候选范围线性扩展，相邻步的差异逐渐放大。不同的 LRU Buffer 容量配置会直接影响 Cache 命中率。

可以看到，当 Buffer 容量仅为 Top-k 大小（2K）时，长序列场景下命中率显著下降，I/O 延迟成为瓶颈。而将 Buffer 扩大至 4K～8K，可以用可控的显存开销换取成倍的 I/O 效率提升。

LRU Diff Kernel 设计与实现

为充分利用 DSA 的时间局部性，我们设计了基于 LRU 淘汰策略的 Diff Kernel。其核心思想是：在 GPU 侧维护一个 Top-k 的 2～4 倍容量的 LRU Buffer（典型配置为 4K～8K Token），通过智能淘汰策略容纳 Top-k 的短期波动。

Kernel 工作流程分为三个阶段：

阶段 1：集合交集计算

比较 prev_topk 和 curr_topk，识别出两步共同选中的 Token。这部分 Cache 已驻留 GPU，无需重新加载，直接更新 PageTable（curr_device_indices）以复用现有数据。

阶段 2：LRU 淘汰决策

这是与严格 Top-k Buffer 的核心差异。Kernel 不会简单驱逐所有 prev_topk 中未在 curr_topk 出现的 Token，而是：

• 仅当 Buffer 空间不足时才触发淘汰；
  
• 优先淘汰过去多个 Step 中均未被命中的 Cache 页（基于 LRU 策略）；
  
• 计算 evict_device_indices，标记最冷的物理页位置可被覆写。
  

阶段 3：增量加载映射

从 curr_topk 中提取新增的 Token（未命中部分），生成一对一的加载映射关系：

• load_host_indices：这些 Token 在 Host Memory 中的物理地址；
  
• load_device_indices：它们在 GPU 中的目标物理页号（复用阶段 2 淘汰的位置）。
  

这种启发式策略充分利用了 DSA Top-k 选择的时间连续性，为每个 Request 动态维护一个高效的缓存窗口, 使得系统可以用较少的 GPU 缓存空间维持长序列场景下至少 80%+ 的缓存命中率，达到空间和效率的动态平衡。

2.4.4 I/O Transfer Kernel: 高性能传输利器 TODO

为了实现 GPU-CPU 异构内存层次间的高效数据迁移，SGLang HiCache 设计了专门的 IO Kernel 传输引擎。该引擎采用 CUDA 底层优化技术，通过 warp-level 细粒度并行最大化 PCIe 带宽利用率。

IO Kernel 支持多种内存布局模式（layer_first、page_first、page_head），实现了对 MHA和 MLA 架构的统一抽象。在 CPU 侧采用 pinned memory 和 CUDA host register 机制确保零拷贝传输，结合 per-layer 和 all-layer 两种传输粒度的动态调度策略，在 prefill 阶段后进行批量全层 offload，在 decode 阶段进行增量单层传输，有效平衡了传输延迟与带宽开销。

实测表明，通过 NUMA 绑定，该 IO Kernel 在 8×H20 上可达到接近~40GB/s per GPU，为分层 KV cache 架构提供了低延迟、高吞吐的数据搬运基础设施。

3. 性能评估

我们在 SGLang 分层稀疏注意力框架上接入了 DeepSeek V32 DSA，并在长上下文推理场景下进行了系统性能评估。实验采用 DeepSeek-V32 模型，针对 16k、32k 和 64k 三种序列长度配置，在 8×H200 GPU With 1TB 内存上测试了不同 batch size 下的输入吞吐量（input tokens/s）。

实验结果表明，相较于传统的全量 KV cache 方案，分层稀疏注意力方案（Hierarchical Sparse）通过结合KV cache 分层管理、GPU-CPU 异构存储以及动态 TopK 检索机制，在长序列场景下展现出显著的性能优势。具体而言：

1. 内存效率&吞吐量突破：传统方案受限于 GPU 显存容量，在 64k/32k/16k 序列长度下分别仅能支持最大 batch size 为 32/64/128，而 Hierarchical Sparse 方案通过将 KVCache Offload 至 CPU 内存，可支持的最大 batch size 分别达到 160/304/600，实现了 5 倍的批处理能力提升，2～3 倍的 Through 提升。

2. 可扩展性验证：随着 batch size 增加，Hierarchical Sparse 方案的吞吐量呈现近线性增长趋势，验证了分层缓存架构和稀疏注意力机制在大规模并发推理场景下的良好扩展性。

该结果证明了分层稀疏注意力架构在突破 GPU 显存墙、支持超长上下文大规模并发推理方面的有效性。

4. 展望与Roadmap

技术深化方向：

• 算法与后端扩展：适配更多 Sparse 算法（如 StreamingLLM、PQCache）与 Attention 后端（如 FlashInfer、Triton），提升框架的生态兼容性。
  
• 性能优化：

• IO 掩藏：通过 TwoBatch Overlap、Kernel Fused 等技术进一步降低 I/O 延迟开销，逼近理论性能上限。
  
• 异步检索： 基于相邻 Token 的 Query 具有高度相似性原则，通过前序 Token 的 Query 提前异步检索 当前 Step 的 Topk，减少检索开销。
  

架构演进方向：随着超节点架构的普及，GPU 通过 Scale-Up 网络访问共享内存池的带宽已显著超越传统 PCIe 带宽。在此硬件趋势下，KVCache 的内存池化管理（Memory Pooling）成为自然选择。我们将协助实现超节点内的 KVCache 统一池化调度，充分发挥 Scale-Up 网络的带宽优势，突破传统 PCIe 瓶颈，为超长上下文推理提供更高效的分层稀疏化基础设施。

5. 了解更多

欢迎搜索钉钉群号：109765011301入群与技术专家交流！