DeepSeek-V4 FlashMemory：KV Cache压缩至十分之一的实测解析

大型语言模型在处理长文本时，能力持续突破，但真正部署到推理服务后，显存瓶颈迅速暴露——核心症结在于KV Cache。自回归生成过程中，每输出一个token，模型都需要回顾已处理的所有上下文。为避免重复计算，推理系统会将历史token对应的Key和Value缓存起来。上下文越长，缓存越大。当长度达到128K、500K甚至更高时，KV Cache往往成为长上下文服务中占比最重的显存开销。

本文讨论的论文《FlashMemory-DeepSeek-V4: Lightning Index Ultra-Long Context via Lookahead Sparse Attention》，核心议题正是如何进一步压缩这笔显存成本。

关键结果：KV Cache压缩至约十分之一

论文提出面向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等更长上下文场景下，KV Cache开销甚至接近原来的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。对比直观：上下文越长，FlashMemory节省显存越显著。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，参与后续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，还需要更聪明的记忆调度能力。