DeepSeek-V4 FlashMemory：长上下文KV Cache压缩至1/10评测

先说一个核心判断：长上下文模型的能力确实在持续进化，但真正落到推理服务时，显存很快就会成为最现实的硬约束——更具体地说，是KV Cache。

大模型在自回归生成过程中，每生成一个token，都需要回顾之前读过的上下文。为了避免每一步都重新计算历史内容，推理系统会把历史token对应的Key和Value缓存下来。上下文越长，这部分缓存就越膨胀。到了128K、500K甚至更长的上下文长度，KV Cache往往是长上下文服务中占比最高的显存开销。

FlashMemory-DeepSeek-V4: Lightning Index Ultra-Long Context via Lookahead Sparse Attention 这篇论文讨论的，正是如何进一步压缩这笔显存“支出”。

结果先行：KV Cache压到约1/10

论文提出了一套针对DeepSeek-V4的方案：FlashMemory-DeepSeek-V4。其核心机制叫Lookahead Sparse Attention，简称LSA。思路很直接：让模型在生成过程中学会“提前判断”——接下来到底需要回忆哪一部分历史上下文，然后只把真正可能用到的KV chunk拉回GPU。

论文给出的结果很亮眼：在LongBench-v2、LongMemEval、RULER等长上下文评测集上，FlashMemory把平均物理KV Cache占用压到了full-context baseline的13.5%。换算下来，平均KV Cache被压缩到了原来的约1/7；而在256K、512K这类更长上下文下，这一比例更是接近1/10。

与此同时，论文报告称FlashMemory在整体平均准确率上比DeepSeek-V4-Flash高了0.6个百分点。

图注：FlashMemory-DeepSeek-V4的性能与硬件效率总览

上图是论文最核心的结果图。左侧是LongBench-v2的表现，FlashMemory在S、M、L三个长度档位上都优于DeepSeek-V4-Flash。尤其是接近493K的LongBench-v2-L上，准确率从68.1%提升到70.0%。中间是RULER的结果，这里注意，FlashMemory并非在每个长度上都全面领先：在128K、256K上略低一些；但在64K和512K上，它又分别达到95.0%和89.6%，都高于DeepSeek-V4-Flash。

右侧是最关键的KV Cache Overhead。在64K/128K/256K/512K四个长度下，FlashMemory的显存开销大约是0.04GB/0.06GB/0.09GB/0.18GB，而DeepSeek-V4-Flash对应大约是0.23GB/0.47GB/0.94GB/1.87GB。对比非常直观：上下文越长，节省的显存越明显。到了512K，KV Cache开销只有baseline的约9.6%，下降了约90%。

长上下文的昂贵点

长上下文能力听起来很直接：模型能读更多token，就能处理更长的文档、更大的代码仓库、更复杂的Agent轨迹。但工程上，问题很快变得现实。模型读过的上下文不会凭空消失。推理时，系统要把历史token的Key/Value保存下来，后续每生成一个新token，都可能继续用到这部分历史信息。

这就是KV Cache。

对于8K、32K上下文，KV Cache已经是显存成本中很重要的一部分。到了128K、500K甚至更高长度时，它会变成长上下文服务里最难绕开的成本。DeepSeek-V4这类模型已经做了很多注意力层面的压缩设计，例如通过分层、稀疏和压缩机制减少计算量。但论文指出，即使注意力计算已经被优化，KV Cache的显存开销依然会随上下文长度增长。

换句话说，模型已经变得更会“省着算”，但还需要进一步学会“省着存”。

FlashMemory的出发点就在这里。论文作者观察到，在大量长上下文请求里，很多时候模型并不真的需要调用完整历史。超过90%的64K以上上下文请求，仅靠最后8K token就能完成。这说明，大量历史KV在当前生成步骤里只是占着显存，并没有真正参与预测。

当然，历史信息也不能简单丢掉。有些任务确实依赖远距离上下文，比如从很长的文档里找前后分散的证据、处理跨越几十万token的记忆检索，或者在长代码库里追踪某个接口的定义和调用。对于这些任务，只看最近窗口会明显不够。

所以FlashMemory面对的问题很明确：能不能把大部分历史KV放在更便宜的位置，只在需要的时候，把真正关键的部分提前取回GPU？

LSA让模型预判KV chunk

FlashMemory-DeepSeek-V4的核心机制叫Lookahead Sparse Attention。这里最重要的词是Lookahead。它并不等到模型生成到某一步才临时发现需要历史信息，而是提前预测：在接下来一小段decoding window里，哪些历史KV chunk可能会被用到。

整个机制可以拆成三个环节。首先，大量历史KV不再默认长期留在GPU上。FlashMemory会把历史KV放到CPU侧的Cold Pool里，GPU主要保留最近窗口、本地必要KV，以及被判定为当前生成真正需要的历史KV。其次，系统引入一个Neural Memory Indexer。这个Indexer会根据当前token的hidden state，预测未来一段生成可能会用到哪些历史chunk。最后，只有被判定为重要的chunk，才会被召回GPU。这些被召回的KV会参与后续attention计算，其余暂时无关的历史信息继续留在CPU侧。

这样一来，KV Cache的管理方式就发生了变化。过去是完整历史常驻GPU，FlashMemory则变成了关键历史按需召回。

图注：LSA与原始CSA的架构对比

上图为整篇论文最重要的机制图。黑色路径对应DeepSeek-V4原本的CSA pipeline，红色路径对应FlashMemory新增的LSA/Memory Indexer机制。

这张图最关键的地方，是画出了CPU和GPU的分层。历史压缩KV entries可以存放在CPU侧，GPU侧只保留sliding window attention、本地窗口KV，以及被召回的query-critical KV entries。右侧的Memory Indexer会周期性触发，它根据query token的hidden state生成Memory Indexer Queries，再去匹配compressed indexer keys。左侧的Recall/Threshold Selector负责决定哪些历史entries应该被拉回GPU。

这里有一个值得注意的设计：FlashMemory没有简单地使用固定Top-k，而是通过Sigmoid分数和阈值判断，把超过阈值的历史KV entries召回。这样召回数量就可以更灵活。如果某一段生成确实需要更多历史，系统可以多取一点；如果当前生成只依赖最近上下文，系统就可以少取很多。

可检索的KV Cache

FlashMemory这篇论文有意思的地方，不只在于显存压缩数字。它真正有启发的点是：把KV Cache管理做成了一个检索问题。

直觉上，想让模型学会判断“哪些历史上下文重要”，很容易想到端到端训练：把整个大模型连同Indexer一起训练，让它自己学会保留和召回。但这样做的成本非常高，工程负担也很重。

FlashMemory选择了一个更轻量的方案：把Memory Indexer做成一个独立的dual-encoder检索器。具体来说，历史侧的compressed indexer keys会提前离线抽取并冻结。训练时主要学习query这一侧的encoder，让它根据当前hidden state，去预测未来窗口里需要哪些历史chunk。

这样做的好处很明显：训练Memory Indexer时，不需要把完整的大模型backbone加载进GPU。论文里提到，Memory Indexer可以在单张H20 GPU上约1小时内收敛。作者还使用8张H20 GPU，在一周内完成了大约500次训练，用来搜索更合适的结构和训练策略。

这是一条很工程化的路线。它没有把所有东西都压到一次巨大的端到端训练里，而是把长上下文推理里的“记忆调度”拆了出来，做成一个可以独立训练、独立迭代的模块。

训练标签的选择

Memory Indexer要训练，就需要知道：某个生成时刻，未来真正需要哪些历史chunk？

最直接的办法，是去看原始Lightning Indexer或CSA层在未来窗口里选择了哪些Top-k历史条目。但论文发现，这种做法会产生大量噪声。原因也很简单：固定Top-k会强行选满。即使某些历史chunk相关性并不强，它们也可能因为排名靠前而被当成正样本。

论文里提到，朴素做法会让每个token window产生接近10,000个正样本。经过过滤之后，数量会下降到大约100到1,000个。作者使用的办法叫Cross-Layer Majority Voting。

可以把它理解成三步。第一步，对不同CSA层的原始indexer logit做归一化，让不同层的分数更可比较。第二步，使用类似nucleus threshold的方法，只保留高置信度条目。第三步，看多个layer是否共同选择了同一个历史entry。只有获得足够多层共识的entry，才会被标记为golden entry。

这一步很关键。FlashMemory的目标并不是随便删掉90%的历史KV，而是尽可能找出真正有价值的那一小部分历史记忆。换句话说，重点在于“看对”。

Memory Indexer放哪里

论文还讨论了一个很重要的工程取舍：Memory Indexer应该放在哪些层？

作者没有把Indexer塞进所有层里。浅层表示通常更偏向低级token统计，对于长距离语义依赖的判断并不理想；如果Indexer放得太多，又会导致召回结果过松，拉回GPU的历史chunk变多，显存节省效果被削弱。

最终，论文选择在第10、12、20层放置Memory Indexer。推理时，这3个Indexer使用OR-mode routing聚合结果。只要其中一个Indexer判断某个历史chunk重要，这个chunk就会被召回。

这是一个偏稳妥的选择。它会牺牲一点极致压缩率，但可以降低漏掉关键上下文的风险。对于长上下文任务来说，漏召回往往比多召回更危险。

实验结果

论文主要比较了四种方案：标准DeepSeek-V4-Flash，也就是全量KV Cache baseline；加入Memory Indexer的FlashMemory版本FM-DS-V4；只保留最近8K和解码窗口的Recency Only；以及随机保留10%全局历史CSA chunks的Random 10%。

表1：不同方案在主要长上下文评测中的系统性能与物理KV Cache占用

实验覆盖LongBench-v2、LongMemEval和RULER。从表1可以看到，FM-DS-V4的平均准确率是77.5，略高于DS-V4-Flash的76.9；同时，平均GPU memory overhead从0.93GB降到了0.10GB。

这个结果可以拆成两层来看。第一，FlashMemory确实把显存开销降下来了。从0.93GB到0.10GB，平均KV Cache开销大约只有baseline的10.8%，这也是“压到约1/10”的核心依据。第二，它没有用明显性能损失来换显存节省。平均准确率反而略高0.6个百分点。

对比另外两个baseline，更能看出Memory Indexer的价值。Recency Only的平均准确率只有33.3，说明只保留最近窗口完全不够，很多长上下文任务确实需要远距离历史信息。Random 10%的平均准确率是38.7，说明随机保留一部分历史KV也不够。关键在于，系统必须知道哪些历史KV真正可能在后续生成中被用到。

FlashMemory的优势就在这里。它并不是单纯减少缓存，而是让模型提前预测：接下来真正可能用到哪些历史KV。

更少上下文带来的准确率提升

这篇论文里还有一个挺有意思的现象：FlashMemory在部分任务上不仅更省显存，准确率还更高。比如LongBench-v2-L，DeepSeek-V4-Flash的准确率是68.1%，FlashMemory提升到了70.0%。

这个现象有点反直觉。按常规理解，模型能看到的历史越完整，信息应该越充分。但长上下文里有大量无关内容，它们进入attention之后，可能会稀释真正重要的信息，甚至干扰模型判断。

论文作者把FlashMemory的这种效果称为attention denoiser。也就是说，Memory Indexer在召回历史KV的同时，也起到了一层过滤噪声的作用。模型少看了一些无关历史，反而更容易聚焦到真正相关的上下文上。

这也是FlashMemory比较有意思的地方。它带来的收益不只是节省显存，也可能改善长上下文attention的质量。

局限性：密集记忆任务与长度泛化

FlashMemory的结果很亮眼，但它的边界也比较清楚。论文里主要暴露出两类限制：一类来自任务本身，另一类来自上下文长度泛化。

MRCR：密集全局记忆下的失败案例

论文在MRCR（Multi-Range Context Retrieval）上记录了一个明显失败案例：FM-DS-V4的准确率从baseline的76.0%掉到了48.0%。

为了判断问题出在哪里，作者又做了一组oracle simulation。他们先用DS-V4-Flash的完整解码路径，为每个样本预先计算全局golden attention weights；然后按照累计attention density对历史blocks排序，只加载Top 50%、25%或10%的高权重chunks到核心MQA层里。

结果显示，在LongBench-v2、LongMemEval和RULER上，只保留10%或25%的golden CSA chunks，再配合全局HCA layers，就足以维持baseline的完整准确率。但MRCR不一样，即使提供50%由oracle预先确认的高权重chunks，准确率仍然比full-context cache低约2%。

这说明MRCR对全局、密集、分散的历史记忆依赖更强。它需要更高覆盖率的全局记忆。对于这种任务，只靠轻量的dual-encoder Memory Indexer，很难把所有关键上下文召回完整。

论文也总结了几个限制。第一，历史key表示是冻结的，当前主要训练query这一侧，历史侧表示没有一起联动优化。第二，检索交互能力还比较有限，现有方案主要依赖粗粒度点积相似度，未来可能需要更强的late interaction结构，例如类似ColBERT的方式。第三，Memory Indexer和backbone是解耦训练的，这种方式训练成本更低、工程上更灵活，但它也缺少端到端联合优化，对自回归生成过程中的动态分布适应还不够完整。

512K训练长度之外的泛化问题

论文里还有一个很重要的观察：Memory Indexer的长度泛化并没有想象中那么自然。

作者最初希望，既然Indexer做的是point-wise chunk matching，那么在较短上下文上训练后，也许可以扩展到更长上下文。但实验结果并不乐观。论文发现，Indexer基本只能安全泛化到训练长度范围内。一旦明显超过训练时见过的上下文长度，选择质量会退化，甚至接近随机。

作者认为，这和位置编码在超长范围下的分布外问题有关。所以，FlashMemory的结果需要放在它的实验范围内理解。更准确地说，它是在论文覆盖的benchmark和512K量级上下文中，把平均物理KV Cache压到了13.5%，并在500K规模附近把KV Cache开销降低超过90%。

这已经是一个很强的结果，但它并不自动意味着同样方法可以无损扩展到1M、2M或更长上下文。

整体来看，FlashMemory已经证明了LSA在长上下文KV Cache压缩上的潜力。但在更密集、更复杂的全局记忆任务上，以及超过训练长度的上下文场景里，它还需要更强的召回机制和更完整的训练方式。

论文小结

FlashMemory-DeepSeek-V4最值得关注的地方，是它把长上下文推理里的KV Cache管理，从“尽量塞进显存”推进到了“按需调度记忆”。

这条路线的意义在于，长上下文能力继续往前走，瓶颈不会只来自模型能读多长，也会来自系统能不能便宜、稳定地保存和调用这些历史信息。窗口变大只是第一步，真正难的是让模型知道哪些内容值得保留、什么时候该被召回。

从这个角度看，FlashMemory更像是一次关于“模型记忆系统”的工程实验。它还有边界，但方向很清楚：未来的超长上下文模型，可能需要的不只是更大的context window，还需要更聪明的记忆调度能力。