DeepSeek-V4 发布：面向智能体任务的百万 token 上下文

DeepSeek 今天发布了 V4。Hub 上有两个 MoE 检查点：DeepSeek-V4-Pro 总参数 1.6T，激活 49B；DeepSeek-V4-Flash 总参数 284B，激活 13B。两者都有 1M token 的上下文窗口。基准测试成绩有竞争力，但并非 SOTA。这并不重要。真正的创新在于 DeepSeek v4 如何为高效支持超长上下文而设计，因此成为 agentic 任务的最佳候选之一。

聚焦于长时间运行的 agentic 工作负载。如今把前沿开源模型当作 agent 来运行，会以可预测的方式出问题。模型停下来。你重新提示。轨迹超出上下文预算，或者 KV 缓存填满 GPU，或者工具调用往返在长任务进行到一半时退化。V4 就是为了修复这些已知故障而构建的，并为社区指明方向。

本文涵盖三件事：架构做了哪些不同，使长上下文推理变得廉价；在此基础上叠加的、针对 agent 的后训练决策；以及论文中一些有助于理解这些变化的要点。

agent 的 KV 缓存问题

1M 上下文窗口只是容量，不是性能。你能否用上它，取决于在该深度下每次前向传播的成本。对于一个运行长工具使用轨迹的 agent（一个 SWE-bench 任务、一次多步浏览会话、一个包含数百条命令的终端会话），每个工具结果都会追加到上下文中，而后续每个 token 都要对之前所有内容付出完整的注意力成本。

有两个数字很重要：单 token 推理 FLOPs 和 KV 缓存大小。两者都随序列长度增长。在 1M token 时，DeepSeek-V4-Pro 所需的单 token 推理 FLOPs 是 DeepSeek-V3.2 的 27%，因此在相同硬件上运行更快。它还只使用 10% 的 KV 缓存内存。V4-Flash 把这些数字进一步降低：10% 的 FLOPs 和 7% 的 KV 缓存。

如果我们把 KV 缓存内存与一种成熟架构（如 8 个头的分组查询注意力，以通常的 bfloat16 格式存储）相比，DeepSeek v4 所需的缓存大小大约只有 2%。这使得部署超长上下文处理容易得多。

图 1：基准测试对比（左），每 token FLOPs 和累积 KV 缓存随序列长度的变化（右）。

混合注意力：CSA 和 HCA

效率提升来自把注意力拆成两种机制，并在各层之间交错使用。

压缩稀疏注意力（CSA）使用带学习位置偏置的 softmax 门控池化，沿序列维度把 KV 条目压缩 4 倍。一个闪电索引器（FP4，ReLU 评分的多头点积）为每个查询挑选 top-k 压缩块。它继承了 V3.2 中 DeepSeek 稀疏注意力的稀疏选择思路，但运行在已经比原始序列短 4 倍的块上。索引器的搜索空间也随之缩小。

图 3：CSA。压缩器把每 4 个 token 折叠成一个压缩 KV 条目。闪电索引器为每个查询挑选 top-k 压缩块。一个滑动窗口分支处理最近的未压缩 token。

重度压缩注意力（HCA）把 KV 条目压缩 128 倍，并去掉稀疏选择。每个查询都稠密地关注每个压缩块。压缩后的序列足够短，因此稠密注意力很便宜。

图 4：HCA。更重的压缩器（128x 对比 4x），随后对压缩流进行密集注意力，并带有相同的滑动窗口分支以处理近期内容。

各层在 CSA 和 HCA 之间交替。不同层承载不同的注意力模式，强行在所有层上使用同一种机制会浪费容量。在 V4-Pro 的 61 层堆叠中，第 0–1 层为 HCA，第 2–60 层交替使用 CSA 和 HCA，末尾的 MTP 块仅运行滑动窗口。

两条路径对大多数 KV 条目使用 FP8 存储，仅对 RoPE 维度使用 BF16。CSA 内部的闪电索引器以 FP4 运行。这些存储选择与压缩比叠加，共同产生了 2% 的 KV 缓存数据。

图 2：整体架构。注意力层在 CSA 和 HCA 之间交替。前馈层使用 DeepSeekMoE。残差连接被替换为流形约束超连接（mHC）。

对智能体的变化

高效的长上下文注意力对智能体工作流是必要的，但并不充分。论文描述了三个直接针对智能体用例的后训练和基础设施选择。

跨工具调用的交错思考

V3.2 在工具结果轮次之间保留了推理轨迹，但每当新的用户消息到达时就将其丢弃。对于处理单个用户轮次的智能体来说，这没问题。对于多轮智能体工作流，即用户在智能体已经串联了多个工具调用之后发送后续消息，模型会丢失其累积的推理，不得不重建状态。

当对话包含工具调用时，V4 在用户消息边界之间保留推理内容。模型保留所有轮次（包括跨用户轮次）的完整推理历史。这使得在长时程智能体任务中能够形成连贯、累积的思维链。对于不使用工具的对话式使用，旧行为得以保留：每轮刷新推理以保持上下文简洁。

图 7：带工具思考（上）在所有轮次中保留推理。不带工具思考（下）在每条新用户消息时丢弃推理。

带专用 token 的工具调用模式

V4 引入了 |DSML| 特殊 token 和基于 XML 的工具调用格式。与字符串内 JSON 的工具调用相比，XML 格式减少了转义失败，后者是模型输出嵌套引号内容时常见的失败模式。

该模式将字符串参数（使用 string="true" 原样传递）与结构化参数（使用 string="false" 以 JSON 传递）分开。这消除了一类围绕数字和布尔值的解析错误，而 JSON 工具调用格式经常遇到这类错误。

DSec：为 RL 部署构建的沙箱

智能体行为是通过针对真实工具环境的 RL 训练出来的。论文描述了为此目的构建的沙箱基础设施。DeepSeek Elastic Compute（DSec）是一个 Rust 平台，在一个 Python SDK 背后暴露四种执行基板：函数调用、容器、microVM（Firecracker）和完整 VM（QEMU）。单个集群可运行数十万个并发沙箱。

DSec 有三项特性对智能体训练至关重要：通过分层 3FS 存储实现快速镜像加载（这样 RL rollout 就不必等待容器启动）、抢占安全的轨迹回放（这样被中断的训练步骤无需重新运行工具调用即可恢复），以及跨底层基质的统一 API（这样训练框架就能以函数调用或完整 VM 为目标而无需重写）。这些基础设施决策支撑着智能体基准测试的分数。

智能体基准测试结果

知识与推理方面的数字具有竞争力，但并非领先。智能体方面的数字才是 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）相差不到一个点。
• 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-needle 准确率在 256K token 以内保持在 0.82 以上，在 1M 时保持在 0.59。

图 9：MRCR 8-needle 检索。V4-Pro-Max 在 256K 以内保持在 0.82 以上，在 1M 时保持在 0.59。

使用模型

Hub 上有四个检查点。instruct 模型的 MoE 专家权重使用 FP4，其余全部使用 FP8。base 模型全程使用 FP8。

• deepseek-ai/DeepSeek-V4-Pro（1.6T / 49B 激活，instruct）
• deepseek-ai/DeepSeek-V4-Flash（284B / 13B 激活，instruct）
• deepseek-ai/DeepSeek-V4-Pro-Base（1.6T / 49B 激活，base）
• deepseek-ai/DeepSeek-V4-Flash-Base（284B / 13B 激活，base）

两个 instruct 模型均支持三种推理模式：Non-think（快速，无思维链）、Think High（在 <think> 块中进行显式推理）和 Think Max（通过专用系统提示实现最大推理努力）。Think Max 需要至少 384K token 的上下文窗口。所有模式推荐的采样参数为 temperature=1.0, top_p=1.0。

V4-Pro 在 SWE Verified、MCPAtlas 和内部研发基准测试上的数字使其在智能体任务上与前沿闭源模型持平。悬而未决的问题是社区的工具框架如何适应 |DSML| schema，以及交错思考带来的增益是否能迁移到域外智能体框架。

本博文中的图表来自技术报告 DeepSeek_V4.pdf。