2026 年 4 月 24 日,DeepSeek 终于发布了万众期待的 V4 的预览版本并同步开源。令人眼前一亮的是,这次发布的 DeepSeek-V4-Pro 和 DeepSeek-V4-Flash 两个版本模型都默认支持 1M(一百万)Tokens 的超长上下文。其中的关键不是“能装下 100 万的 Tokens”,而是在此前提下仍能显著降低推理成本:
V4-Pro 相比 V3.2 仅需 27% 的单 token 推理 FLOPs 与 10% 的 KV cache 大小;
V4-Flash 进一步降低到约 10% 的 FlOPs 和 7% 的 KV cache 大小。
这意味着基于超长文本、代码仓库、企业知识库的 AI 会话和执行多轮复杂 Agent 任务,开始有机会从“昂贵的奢侈品”变成“真正普惠”的产品能力。
那么 DeepSeek V4 又是如何做到这种极致的成本控制?对于未来的 AI 存储系统又有哪些启示?让我们从 DeepSeek 发布的技术报告中一探究竟。
翻开 DeepSeek-V4 的技术报告,我们可以看到为了达到上述能力 DeepSeek 不是简单的堆大参数,而是用压缩注意力、FP4 量化感知训练、 KV cache 优化等多个手段,达到大幅压低上下文成本的目的。这其中注意力架构的改进和异构 KV cache 的精细管理起到了至关重要的作用。
混合注意力机制
从模型架构上节省 KV Cache 与算力
注意力机制上 DeepSeek-V4 不再依赖传统全量 attention,而是把它拆成两类压缩注意力:CSA 和 HCA,并交替使用它们。CSA 负责“压缩 + 稀疏选择”,HCA 负责“更强压缩 + dense attention”,二者共同降低长上下文下的 FLOPs 和 KV cache。
压缩稀疏注意力(CSA)
Compressed Sparse Attention 核心架构
压缩稀疏注意力(CSA)是 DeepSeek-V4 支持 1M 上下文的核心技术之一。传统大模型即使采用 GQA/MQA 等方式减少 KV 头数,只要注意力模式仍接近 Full Attention,在百万上下文下仍会面临很高的计算、缓存成本。另外 Sliding Window、Sparse Attention 这类单纯的局部窗口或稀疏注意力则容易丢失长程信息。
CSA 可以理解成在传统路线上把“KV 压缩”和“稀疏选择” 合在了一起:先把长序列的 KV Cache 压缩成更短的 Compressed KV,再用一个轻量的 Lightning Indexer 为每个 Query 选出最相关的 Top-k Compressed KV。最后对这些被选中的 KV 做 core attention,从而同时减少 KV cache 和 attention FLOPs。
重度压缩注意力(HCA)
Heavily Compressed Attention 核心架构
虽然 CSA 已经做了压缩和稀疏选择,但是在 1M 上下文场景下,DeepSeek-V4 还需要一种更便宜的方式提供全局背景信息,所以同时又引入了重度压缩注意力(HCA)。
HCA 是把一大段 token 的 KV cache 重度压缩成很少的 compressed KV entries,然后在这些高度压缩后的 KV 上做 dense attention。它不做 CSA 那样的 top-k 稀疏选择,而是用更高压缩率换取低成本的全局上下文建模。
在 DeepSeek-V4 的模型配置中:
CSA:每 4 个 token 压缩成一个 compressed KV,配合 lightning indexer 做 top-k 的稀疏选择;
HCA:每 128 个 token 压缩成一个 compressed KV,不再做稀疏选择。
CSA 和 HCA 两种压缩注意力本质上是互补关系。CSA 负责精细检索,HCA 负责全局感知;CSA 用较低压缩率保留细节,HCA 用高压缩率控制成本。
滑动窗口注意力(SWA)
由于 CSA 和 HCA 关注的都是长程 KV 的压缩,如果请求所在的压缩块还没有完成或者请求与同一个压缩块内的其他 token 有局部依赖,CSA/HCA 就无法直接访问这些信息。但是在大模型中相近的 token 往往非常重要,例如请求中涉及短语搭配、函数内部上下文、“最近的一句话”等情况。
为了补偿 CSA/HCA 对于这种局部信息的缺失,DeepSeek-V4 又额外增加了一条滑动窗口注意力(SWA)分支 。它会保留最近 n_win(window size)个 token 的未压缩 KV,然后在 CSA/HCA 的 core attention 中把这些 KV 和 compressed KV 一起使用。让模型在高效处理远程上下文的同时,仍能够保留短程局部依赖和当前压缩块附近的细粒度信息。
从 DeepSeek-V4 的技术报告中可以看出,V4-Pro 和 V4-Flash 在长上下文注意力机制上采用相同的核心路线:主体层使用 CSA/HCA 交替结构,并在 CSA/HCA 中加入 SWA 分支。但两者在前 2 层注意力类型、模型规模、CSA top-k、query heads、query compression dim 等配置上存在差异。
DeepSeek-V4 两种模型在混合注意力上的配置差异
DeepSeek-V4 通过 CSA 和 HCA 交替组成混合注意力机制,把长上下文 attention 从“对所有历史 token 做全量注意力”改造成“压缩 KV、稀疏选择、重度压缩、局部窗口补偿”的系统,从而在保持 1M 上下文可用性的同时,大幅降低 FLOPs 和 KV cache 成本。
推理框架优化
专为 KV Cache 的精细化管理
重新设计的异构 KV Cache 管理
DeepSeek-V4 的混合注意力机制虽然减少了 KV cache 的整体大小,但是它也不再是普通 Transformer 那种“每层结构一致、每个 token 一份 KV”的简单形态。因此需要专门设计了一套 KV cache layout 来管理这些异构的 KV。
DeepSeek-V4 异构 KV cache 布局
普通大模型的 KV cache 通常比较规则:每层都有 KV、每个历史 token 有一份 KV、block 大小 和 cache policy 也比较统一。但是 DeepSeek-V4 的混合注意力机制直接打破了 PagedAttention 背后的这种假设:
CSA 和 HCA 的 KV cache 都是经过压缩的、稳定的 KV block。可以按 block 进行管理和落盘复用,有较长的生命周期。
SWA 的 KV cache 是未压缩的,随着 decode 不断滑动,只保留最近的 n_win 个 token。它更像“当前工作记忆”,而不是长期历史缓存。
此外,还没有凑够一个完整压缩块的 tokens 则会形成一个 uncompressed tail states。它同样只是个临时状态,本质上是“待归档的新内容”,并不适合长期保存。
为了应对这些“异构”的 KV cache,DeepSeek 设计了两个主要的组件:classical KV cache 和 state cache。前者用于管理 CSA/HCA 中已经完成压缩的长程 KV,利用这些 KV 稳定、易对齐的特点最大化节省存储空间。后者则用于管理 SWA 所依赖窗口 KV 以及还不能被压缩的尾部 tokens 和它的 hidden states,匹配它们生命周期短、大小有上限的特点。
相比于将这些不同特征的 KV 混在一起,分而治之的做法明显更加高效。这也是模型在实际部署中能够支持百万上下文的关键。
On-Disk KV Cache 存储
进入百万上下文时代,prefill 的重复计算变得愈发昂贵和不可接受。虽然 DeepSeek-V4 已经通过 CSA/HCA 等技术大幅压缩了 KV cache,但是在企业知识库问答、代码仓库 Agent、长文档对话等场景,请求的 prefix 的 KV 仍然可能很大。
在实际运行 DeepSeek-V4 服务时,DeepSeek 则是利用 on-disk KV cache 存储机制选择性的将这些需要共享的 prefix 数据落到磁盘中以备后续复用。避免 prefill 阶段大量重复计算的同时,有效节省了宝贵的显存和内存资源。
On-disk KV cache 存储机制的 KV cache 写入策略
由于 V4 的 KV cache 是异构的,DeepSeek 同样采取了不同的 on-disk 存储策略。对于 CSA/HCA 压缩过的 KV entries 处理相对简单:直接存到磁盘,当新请求命中 prefix 时读取对应的 KV entries,一直复用到最后一个完整的压缩块。如果尾部存在不完整的块,则直接通过重算来恢复。
对于 SWA 的 KV entries,由于它不存在压缩(体积是 CSA/HCA 压缩的 KV entries 的近 8 倍),直接存到磁盘会造成存储占用剧增、SSD 写入压力大等问题。DeepSeek 设计了三种可选策略:
Full SWA Caching
将所有 token 的 SWA KV entires 都存到磁盘。好处是请求命中时完全不需要重算 SWA KV,缺点则是对存储的开销和压力大。
Periodic Checkpointing
每隔 p 个 token 保存一次最近 n_win 个 token 的 SWA KV checkpoint。这是一个折中方案,通过可调的 p 参数来平衡存储与重算压力。
Zero SWA Caching
完全不保存 SWA KV,当请求命中时需要通过重算恢复 SWA KV。
DeepSeek 也明确指出,实际部署时要根据具体场景来灵活选择上述策略,以达到存储与计算的最佳平衡点。
从 DeepSeek V4 看推理系统趋势
DeepSeek-V4 的发布引领百万上下文能力进入普惠时代,它通过一整套效率工程将超长上下文的推理成本压到极致。可以看出大模型的竞争正在从“模型参数和 benchmark”扩展到“长上下文、低成本推理、KV cache 管理、数据复用和存储系统协同”。
在超长上下文场景中,KV cache 正在从普通的运行时缓存变成了可持久化的新型数据资产。它既不是原始文档,也不是向量数据或者训练 checkpoint 数据,而是推理过程中生成的可复用、和模型强相关的中间资产。同时模型架构的不断创新也决定了 KV cache 的“异构”将变成一种常态,这对于 KV cache 的管理和存储都提出了更高的要求。
On-disk KV cache 存储机制的设计,进一步证明了 KV cache 的持久化存储与复用对于超长上下文推理场景的重要性。存储开始进入推理关键路径,存储系统的延迟、吞吐和扩展能力,围绕 KV cache、prefix 的管理和感知能力都将直接影响大规模推理系统的运行表现。
专为推理设计的 KV Cache 存储
MeshFusion 推理存储,正是顺应上述趋势的新一代 KV cache 持久化方案。MeshFusion 以完全自研的方式为推理框架提供持久化、低延迟、可横向扩展的上下文内存,在设计之初就将 KV cache 作为一种全新的数据类型进行管理。
有别于传统的混闪架构,MeshFusion 采用全对称分布式架构,消除热点瓶颈,任一节点可访问全局数据,实现性能线性扩展。底层融合 RDMA 与智能选路,保障毫秒级故障切换。更通过 usrbio 技术绕过内核,实现数据直达 GPU 显存,在大幅降低 CPU 开销的同时,彻底释放 AI 极致吞吐性能。
MeshFusion 通过以下核心技术满足推理系统对于存储极致的吞吐和极低延迟的要求:
原生 KV cache chunk 接口
推理侧的 KV cache Chunk 直接映射为 MeshFusion 的存储 Chunk,砍掉所有协议转换开销,构建最短 I/O 路径。
用户态零拷贝 IO
基于 Kernel Bypass 架构,数据在从 NVMe 闪存流向 GPU 显存的过程中,实现零拷贝、零上下文切换,彻底消除操作系统层面的延迟抖动。
Shared-Everything 并行化架构
允许任何节点上的 IO 进程直接访问所有数据和元数据。统一池化管理全体闪存与网络带宽,天生免疫单点瓶颈。在面对 Agent 时代多租户、多业务的高并发读写时,依然能保证一致的极低尾延时。
FlexPath 智能网络引擎
专为高并发 KV 读写定制,支持多路径聚合、智能选路、RDMA 优先(TCP 回退)以及大小 I/O 智能路由,确保底层网络传输的稳定。
热门跟贴