DeepSeek-V4为代理实现实用的百万token上下文
Hugging Face Blog··作者 ben burtenshaw
关键信息
V4-Pro在百万token下相比V3.2减少27%的FLOPs和10%的KV缓存；V4-Flash进一步降至10%和7%。该架构交替使用CSA和HCA层，并通过FP8/FP4存储优化将缓存大小降至传统GQA模型的2%。
资讯摘要
DeepSeek-V4通过重新设计注意力机制解决了长期代理工作流中的关键瓶颈，如KV缓存溢出和工具调用退化问题。它将注意力分为两部分：压缩稀疏注意力（CSA）将键值压缩4倍并为每个查询选择前k个块；重度压缩注意力（HCA）则压缩128倍并在压缩流上进行密集注意力计算。
这些层在模型堆栈中交替排列，并通过滑动窗口处理最近的token。结合FP8存储和MoE前馈层，显著降低了计算成本和内存占用，使百万token上下文不仅可能而且实用。
资讯正文
DeepSeek-V4：一个代理真正能用的一百万token上下文
专注于长时间运行的代理工作负载。如今，将前沿开源模型作为代理运行时，会出现可预测的崩溃：模型会停止运行，你需要重新提示，追踪记录会超出上下文预算，或者KV缓存填满GPU，又或者在长任务中途，工具调用轮次性能下降。V4的设计正是为了修复这些已知问题，并为社区指明前进方向。
本文涵盖三个方面：架构如何不同地实现低成本的长上下文推理、在此基础上叠加的代理专用后训练决策，以及论文中的一些洞见，有助于理解这些变化。
一个100万token的上下文窗口只是容量，而非性能。能否使用它取决于每个前向传播在该深度下的成本。对于执行长时间工具使用轨迹的代理（例如SWE-bench任务、多步骤浏览会话，或包含数百条命令的终端会话），每次工具结果都会被追加到上下文中，而后续的每个token都要对之前所有内容支付完整的注意力计算成本。
两个数字至关重要：单token推理所需的FLOPs（浮点运算次数）和KV缓存大小。两者都随序列长度增长。在100万token时，DeepSeek-V4-Pro相比DeepSeek-V3.2仅需27%的单token推理FLOPs，因此在相同硬件上运行更快；同时KV缓存内存占用仅为10%。V4-Flash进一步降低这两项指标：FLOPs降至10%，KV缓存降至7%。
如果我们把KV缓存内存与成熟架构如8头分组查询注意力（GQA）进行对比——后者通常以bfloat16格式存储——DeepSeek V4所需的缓存大小约为其2%。这使得处理超大上下文更加容易部署。
图1：基准对比（左图），每token FLOPs及累积KV缓存随序列长度的变化（右图）。
效率提升来自于将注意力机制拆分为两种机制，并在层之间交错使用。
压缩稀疏注意力（CSA）通过softmax门控池化并加入学习的位置偏置，将KV条目沿序列维度压缩4倍。闪电索引器（FP4，ReLU评分多头点积）为每个查询选择最相关的k个压缩块。它继承了DeepSeek V3.2稀疏注意力中的稀疏选择思想，但作用于已经比原序列短4倍的块上，索引器的搜索空间随之缩小。
图3：CSA。压缩器将每4个token合并为一个压缩的KV条目。闪电索引器为每个查询挑选top-k压缩块。滑动窗口分支负责处理最近未压缩的token。
高度压缩注意力（HCA）将KV条目压缩128倍，并省略稀疏选择。每个查询密集地关注每一个压缩块。由于压缩后的序列足够短，密集注意力变得廉价。
图4：HCA。更强的压缩器（128倍 vs 4倍）后接对压缩流的密集注意力，同样配有滑动窗口分支以保留近期信息。
DeepSeek-V4：一个百万token上下文，代理可以真正使用的版本
层在CSA和HCA之间交替。不同的层具有不同的注意力模式，如果强制所有层都使用同一种机制，会浪费计算资源。在V4-Pro的61层结构中，第0–1层为HCA，第2–60层则交替使用CSA和HCA，最后的MTP模块仅运行滑动窗口机制。
两条路径都对大多数KV条目使用FP8存储，仅对RoPE维度使用BF16。CSA内部的闪电索引器（lightning indexer）则运行在FP4精度下。这些存储选择与压缩比结合，最终产生了2%的KV缓存占用率。
图2：整体架构。注意力层在CSA和HCA之间交替，前馈层采用DeepSeekMoE。残差连接被流形约束超连接（mHC）替代。
高效的长上下文注意力对于代理工作流是必要的，但并不足够。论文描述了三项后训练和基础设施方面的选择，直接针对代理使用场景进行优化。
V3.2版本会在工具调用结果轮次之间保留推理痕迹，但在收到新用户消息时就会丢弃这些痕迹。对于单轮交互的代理任务来说这没有问题；但对于多轮代理流程——即用户在代理已经链式调用多个工具之后发送后续请求——模型会丢失累积的推理过程，不得不重新构建状态。
V4版本在对话包含工具调用时，能够在用户消息边界之间保留推理内容。模型会完整保留所有轮次的推理历史，包括跨用户回合的信息。这使得模型能在长期代理任务中形成连贯且累积的思维链条。对于不使用工具的对话场景，则保留旧行为：每轮都会清空推理内容，以保持上下文简洁。
图7：带工具思考（顶部）在所有轮次中保留推理内容；不带工具思考（底部）在每次新用户消息到来时丢弃推理内容。
V4引入了一个特殊的 |DSML| 标记以及基于XML的工具调用格式。相比JSON字符串嵌套形式的工具调用，XML格式能显著减少转义错误，这是模型输出嵌套引号内容时常出现的问题。
该格式将字符串参数（以string="true"传递）与结构化参数（以JSON格式传递，string="false"）区分开来，从而消除了一类因数字和布尔值解析错误而导致的常见JSON工具调用失败。
代理行为通过强化学习（RL）在真实工具环境中进行训练。论文详细介绍了为此目的构建的沙箱基础设施。DeepSeek Elastic Compute（DSec）是一个基于Rust开发的平台，通过统一的Python SDK暴露四种执行环境：函数调用、容器、微虚拟机（Firecracker）和完整虚拟机（QEMU）。一个集群可同时运行数十万个并发沙箱。
DSec的三个特性对代理训练至关重要：通过分层3FS存储实现快速镜像加载（使RL回放无需等待容器启动），支持中断安全的轨迹重放（确保训练中断后无需重复执行工具调用即可恢复），以及跨执行环境的统一API（使训练框架可在不重写代码的情况下适配函数调用或完整虚拟机）。这些基础设施决策支撑了代理基准测试得分。
DeepSeek-V4：一个百万token上下文，代理模型真正可用
知识和推理能力处于竞争水平但并非领先。在代理任务上，V4-Pro-Max才真正脱颖而出。
来自表格6中代理部分的具体数据：
- Terminal Bench 2.0：V4-Pro-Max得分为67.9，高于GLM-5.1（63.5）和K2.6（66.7），低于GPT-5.4-xHigh（75.1）和Gemini-3.1-Pro（68.5）。
- SWE Verified：解决了80.6个问题，与Opus-4.6-Max（80.8）和Gemini-3.1-Pro（80.6）相差不到1分。
- MCPAtlas Public：得分为73.6，仅次于Opus-4.6-Max（73.8）。
- Toolathlon：得分为51.8，高于K2.6（50.0）、GLM-5.1（40.7）和Gemini-3.1-Pro（48.8）。
在论文内部研发编码基准测试中，针对PyTorch、CUDA、Rust和C++共30个精心挑选的任务，V4-Pro-Max的通过率为67%，而Sonnet 4.5为47%，Opus 4.5为70%。在对85名使用V4-Pro作为日常开发工具的DeepSeek开发者进行的一项调查中，52%的人表示它已准备好替代他们当前的主要编程模型，另有39%倾向于这样认为。
图9：MRCR 8针检索。V4-Pro-Max在256K上下文中保持得分高于0.82，在1M上下文中稳定在0.59。
Hub上有四个检查点。指令模型使用FP4存储MoE专家权重，其余部分使用FP8。基础模型全程使用FP8。
- deepseek-ai/DeepSeek-V4-Pro（1.6万亿参数 / 490亿激活参数，指令模型）
- deepseek-ai/DeepSeek-V4-Flash（2840亿参数 / 130亿激活参数，指令模型）
- deepseek-ai/DeepSeek-V4-Pro-Base（1.6万亿参数 / 490亿激活参数，基础模型）
- deepseek-ai/DeepSeek-V4-Flash-Base（2840亿参数 / 130亿激活参数，基础模型）
两个指令模型支持三种推理模式：Non-think（快速模式，无思维链）、Think High（在<think>标签内显式推理）和Think Max（最大推理强度，配有专用系统提示）。Think Max需要至少384K token的上下文窗口。所有模式推荐的采样参数均为temperature=1.0，top_p=1.0。
V4-Pro在SWE Verified、MCPAtlas以及内部研发基准上的表现，使其在代理任务上达到与前沿闭源模型相当的水平。尚未解决的问题是，社区的工具调用框架如何适配|DSML|规范，以及这种交错推理的优势是否能迁移到域外的代理框架中。
本博客文章中的图表均来自DeepSeek_V4.pdf技术报告。
来源与参考
收录于 2026-04-25