DeepSeek-V4 技术报告全文

本文译自 DeepSeek-AI 的技术报告 DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence¹，2026 年 4 月 26 日提交于 arXiv。原文 58 页，这里是全文翻译，覆盖摘要、§1 引言、§2 架构、§3 通用基础设施、§4 预训练、§5 后训练、§6 结论、局限与未来方向。附录 A（作者名单、致谢）和附录 B 的评测明细表不在译文范围内——那些表的结论已经写在 §5.4 的正文里；附录 B 的两张案例图（Figure 14、15）保留在 §5.4 末尾。

摘要

我们发布 DeepSeek-V4 系列的预览版，包含两个强大的 Mixture-of-Experts（MoE）语言模型——DeepSeek-V4-Pro，1.6T 参数（激活 49B），以及 DeepSeek-V4-Flash，284B 参数（激活 13B）——两者都支持 100 万 token 的上下文长度。DeepSeek-V4 系列在架构和优化上有几项关键升级：（1）一个混合注意力架构，把 Compressed Sparse Attention（CSA）和 Heavily Compressed Attention（HCA）组合起来以改善长上下文效率；（2）Manifold-Constrained Hyper-Connections（mHC），它强化了传统的残差连接；（3）Muon 优化器，带来更快的收敛和更好的训练稳定性。我们在超过 32T 条多样、高质量的 token 上预训练这两个模型，之后是一套完整的后训练流程，用来释放并进一步增强它们的能力。DeepSeek-V4-Pro-Max，也就是 DeepSeek-V4-Pro 的最大 reasoning effort 模式，重新定义了开源模型的 state-of-the-art，在核心任务上超过了它的前代。同时，DeepSeek-V4 系列在长上下文场景下效率极高。在 100 万 token 上下文的设定下，DeepSeek-V4-Pro 相比 DeepSeek-V3.2 只需要 27% 的单 token 推理 FLOPs 和 10% 的 KV cache。这使我们能够常规性地支持百万 token 上下文，从而让长程任务和进一步的 test-time scaling 变得更可行。模型 checkpoint 已公开发布²。

1 引言

推理模型的出现³⁴确立了 test-time scaling 这一新范式，为大语言模型（LLM）带来了实质的性能提升。然而，这个 scaling 范式从根本上受制于原始 attention 机制⁵的二次计算复杂度，它为超长上下文和推理过程制造了一个难以承受的瓶颈。与此同时，长程场景与任务的出现——从复杂的 agentic 工作流到大规模跨文档分析——也让高效支持超长上下文成为未来进展的关键。虽然近期的开源工作⁶⁷⁸⁹推进了通用能力，但处理超长序列时这一核心的架构低效仍然是主要障碍，它限制了 test-time scaling 的进一步收益，也阻碍了对长程场景与任务的深入探索。

为了打破超长上下文下的效率壁垒，我们开发了 DeepSeek-V4 系列，包括 DeepSeek-V4-Pro 的预览版，1.6T 参数（激活 49B），以及 DeepSeek-V4-Flash，284B 参数（激活 13B）。通过架构创新，DeepSeek-V4 系列在处理超长序列的计算效率上实现了大幅跃升。这一突破使高效支持 100 万 token 的上下文长度成为可能，为下一代 LLM 开启了百万长度上下文的新阶段。我们相信，高效处理超长序列的能力解锁了 test-time scaling 的下一个前沿，为长程任务的深入研究铺路，也为探索 online learning 这类未来范式打下了必要的基础。

与 DeepSeek-V3 架构⁶相比，DeepSeek-V4 系列保留了 DeepSeekMoE 框架和 Multi-Token Prediction（MTP）策略，同时在架构与优化上引入了几项关键创新。为了提升长上下文效率，我们设计了一个混合注意力机制，把 Compressed Sparse Attention（CSA）和 Heavily Compressed Attention（HCA）结合起来。CSA 沿序列维度压缩 KV cache，然后执行 DeepSeek Sparse Attention（DSA）¹⁰；HCA 则对 KV cache 施加更激进的压缩，但保持 dense attention。为了强化建模能力，我们引入了 Manifold-Constrained Hyper-Connections（mHC）¹¹，它升级了传统的残差连接。此外，我们把 Muon¹²¹³ 优化器引入 DeepSeek-V4 系列的训练，带来更快的收敛和更好的训练稳定性。

为了让 DeepSeek-V4 系列的训练和推理都高效、开发也高产，我们引入了几项基础设施优化。第一，我们为 MoE 模块设计并实现了一个单一的 fused kernel，完全重叠了计算、通信和访存。第二，我们采用 TileLang¹⁴——一种领域专用语言（DSL）——来平衡开发效率和运行时效率。第三，我们提供了高效的 batch 不变（batch-invariant）与确定性 kernel 库，确保训练与推理之间的 bit 级可复现。第四，在训练框架上，我们扩展了 autograd 框架，支持 tensor 级 checkpointing 以实现细粒度的重算控制；并通过面向 Muon 的混合 ZeRO 策略、借助重算与 fused kernel 的低成本 mHC 实现、以及管理压缩注意力的两阶段 contextual parallelism 来提升训练效率。第五，在推理框架上，我们设计了异构的 KV cache 结构以及配套的磁盘存储策略，以高效复用共享前缀。另外，在后训练阶段，我们对 MoE expert 权重和 indexer 的 QK 路径引入了 FP4 量化感知训练，以降低显存和计算。

通过混合使用 CSA 与 HCA，加上计算与存储上的精度优化，DeepSeek-V4 系列相比 DeepSeek-V3.2 实现了显著更低的推理 FLOPs 和大幅缩小的 KV cache，长上下文场景下尤其明显。Figure 1 的右半部分展示了 DeepSeek-V3.2 与 DeepSeek-V4 系列的单 token 推理 FLOPs 估计值和累积 KV cache 大小。在 1M token 上下文的场景下，即便是激活参数更多的 DeepSeek-V4-Pro，相对 DeepSeek-V3.2 也只需要 27% 的单 token FLOPs（按等效 FP8 FLOPs 计）和 10% 的 KV cache。更进一步，激活参数更少的 DeepSeek-V4-Flash 把效率推得更远：在 1M token 上下文设定下，它相比 DeepSeek-V3.2 只需要 10% 的单 token FLOPs 和 7% 的 KV cache。此外，对 DeepSeek-V4 系列而言，routed expert 参数使用 FP4 精度。虽然在现有硬件上 FP4 $\times$ FP8 运算的峰值 FLOPs 与 FP8 $\times$ FP8 相同，但理论上在未来硬件上可以实现出多 1/3 的效率，这将进一步提升 DeepSeek-V4 系列的效率。

预训练阶段，我们分别在 32T 和 33T token 上训练 DeepSeek-V4-Flash 和 DeepSeek-V4-Pro。预训练之后，这两个模型都能原生且高效地支持 1M 长度的上下文。在我们的内部评测中，DeepSeek-V4-Flash-Base 凭借更省参数的设计，已经在大多数 benchmark 上超过 DeepSeek-V3.2-Base。DeepSeek-V4-Pro-Base 进一步扩大了这一优势，在 DeepSeek 的基础模型中确立了新的性能标准，在推理、代码、长上下文和世界知识任务上全面领先。

DeepSeek-V4 系列的后训练流程采用两阶段范式：先独立培养领域专家模型，再通过 on-policy distillation¹⁵¹⁶ 统一整合。一开始，对每个目标领域——比如数学、代码、agent 和指令遵循——都独立训练一个单独的专家模型。基础模型先在高质量的领域数据上做 Supervised Fine-Tuning（SFT）以建立基础能力。随后施加强化学习（RL），采用 Group Relative Policy Optimization（GRPO）⁴，在针对具体成功标准定制的奖励模型引导下，进一步把模型优化到与该领域对齐的行为。这一阶段产出一组各有所长的专家。最后，为了整合这些不同的专长，我们通过 on-policy distillation 训练出一个统一模型，其中统一模型作为学生，学习优化对教师模型的 reverse KL loss。

核心评测结果小结：

• 知识。在广义世界知识的评估中，DeepSeek-V4-Pro-Max（DeepSeek-V4-Pro 的最大 reasoning effort 模式）在 SimpleQA¹⁷ 和 Chinese-SimpleQA¹⁸ 上显著优于领先的开源模型。在教育类知识方面——通过 MMLU-Pro¹⁹、HLE²⁰ 和 GPQA²¹ 评估——DeepSeek-V4-Pro-Max 相对开源同行有小幅领先。DeepSeek-V4-Pro-Max 已显著缩小了与领先闭源模型 Gemini-3.1-Pro 的差距，尽管在这些知识类评测上仍落后于它。
• 推理。通过扩展推理 token，DeepSeek-V4-Pro-Max 在标准推理 benchmark 上表现优于 GPT-5.2 和 Gemini-3.0-Pro。不过，它的表现略逊于 GPT-5.4 和 Gemini-3.1-Pro，说明其发展轨迹落后最前沿模型大约 3 到 6 个月。此外，DeepSeek-V4-Flash-Max 达到了与 GPT-5.2 和 Gemini-3.0-Pro 相当的水平，确立了自己作为复杂推理任务上极具性价比的架构。
• Agent。在公开 benchmark 上，DeepSeek-V4-Pro-Max 与 Kimi-K2.6、GLM-5.1 这类领先开源模型持平，但略差于前沿闭源模型。在我们的内部评测中，DeepSeek-V4-Pro-Max 优于 Claude Sonnet 4.5，接近 Opus 4.5 的水平。
• 长上下文。DeepSeek-V4-Pro-Max 在 100 万 token 上下文窗口下的合成任务和真实用例上都有很强的结果，在学术 benchmark 上甚至超过 Gemini-3.1-Pro。
• DeepSeek-V4-Pro 与 DeepSeek-V4-Flash 对比。DeepSeek-V4-Flash-Max 因为参数规模更小，在知识类评测上表现较弱。但在分配更大 thinking budget 的情况下，它在推理任务上能取得相当的结果。在 agent 评测中，DeepSeek-V4-Flash-Max 在若干 benchmark 上追平了 DeepSeek-V4-Pro-Max，但在更复杂、更高难度的任务上仍落后于它更大的同门。

2 架构

总体上，DeepSeek-V4 系列保留了 Transformer⁵ 架构和 Multi-Token Prediction（MTP）模块²²⁶，同时相对 DeepSeek-V3 引入了几项关键升级：（1）首先，我们引入 Manifold-Constrained Hyper-Connections（mHC）¹¹ 来强化传统的残差连接；（2）其次，我们设计了一个混合注意力架构，通过 Compressed Sparse Attention 和 Heavily Compressed Attention 大幅提升长上下文效率；（3）第三，我们采用 Muon¹²¹³ 作为优化器。对于 Mixture-of-Experts（MoE）部分，我们仍然采用 DeepSeekMoE²³ 架构，只在 DeepSeek-V3 的基础上做了少量调整。Multi-Token Prediction（MTP）^2422256 的配置与 DeepSeek-V3 完全相同。所有其他未特别说明的细节都沿用 DeepSeek-V3⁶ 确立的设置。Figure 2 给出了 DeepSeek-V4 的整体架构，细节在下面描述。

2.1 沿用 DeepSeek-V3 的设计

Mixture-of-Experts。和之前的 DeepSeek 系列模型²⁶⁶一样，DeepSeek-V4 系列的前馈网络（FFN）也采用 DeepSeekMoE 范式²³，它设置了细粒度的 routed expert 和 shared expert。与 DeepSeek-V3 不同的是，我们把计算 affinity score 的激活函数从 $\operatorname{Sigmoid}(\cdot)$ 换成了 $\operatorname{Sqrt}(\operatorname{Softplus}(\cdot))$。负载均衡方面，我们同样采用 auxiliary-loss-free 策略²⁷⁶，并额外加上一个轻微的 sequence-wise balance loss，防止单条序列内部出现极端不均衡。对 DeepSeek-V4，我们去掉了对路由目标节点数的限制，并重新精心设计了并行策略以维持训练效率。此外，相比 DeepSeek-V3，我们把最初几个 Transformer block 里的 dense FFN 层替换成了采用 Hash routing²⁸ 的 MoE 层。Hash routing 策略根据一个预定义的、以输入 token ID 为参数的哈希函数来决定每个 token 的目标 expert。

Multi-Token Prediction。和 DeepSeek-V3 一样，DeepSeek-V4 系列也设置了 MTP 模块和目标函数。鉴于 MTP 策略已经在 DeepSeek-V3 中得到验证，我们对 DeepSeek-V4 系列不作修改地沿用同一策略。

2.2 Manifold-Constrained Hyper-Connections

如 Figure 2 所示，DeepSeek-V4 系列引入 Manifold-Constrained Hyper-Connections（mHC）流形约束超连接¹¹，来强化相邻 Transformer block 之间的传统残差连接。相比朴素的 Hyper-Connections（HC）²⁹，mHC 的核心想法是把残差映射约束到一个特定的流形上，从而在保持模型表达力的同时增强信号跨层传播的稳定性。本小节先简要介绍标准 HC，然后描述我们如何为稳定训练设计 mHC。

标准 Hyper-Connections。标准 HC 把残差流的宽度扩展 $n_{\text{hc}}$ 倍。具体来说，残差流的形状从 $\mathbb{R}^{d}$ 扩展到 $\mathbb{R}^{n_{\text{hc}} \times d}$，其中 $d$ 是实际层输入的 hidden size。令 $X_l = [\mathbf{x}_{l,1}; \ldots; \mathbf{x}_{l,n_{\text{hc}}}]^T \in \mathbb{R}^{n_{\text{hc}} \times d}$ 为第 $l$ 层之前的残差状态。HC 引入三个线性映射：输入映射 $A_{l} \in \mathbb{R}^{1 \times n_{\text{hc}}}$、残差变换 $B_{l} \in \mathbb{R}^{n_{\text{hc}} \times n_{\text{hc}}}$、输出映射 $C_{l} \in \mathbb{R}^{n_{\text{hc}} \times 1}$。残差状态的更新写作：

$$ X_{l+1} = B_{l} X_l + C_{l} \mathcal{F}_{l}(A_{l} X_l), $$

其中 $\mathcal{F}_{l}$ 表示第 $l$ 层（比如一个 MoE 层），它的输入和输出形状都是 $\mathbb{R}^{d}$。注意实际的层输入 $A_{l} X_l \in \mathbb{R}^{d}$ 也是 $d$ 维的，所以扩展后的残差宽度不影响内部层的设计。HC 把残差宽度与实际 hidden size 解耦，提供了一条互补的 scaling 轴，而计算开销极小，因为 $n_{\text{hc}}$ 通常远小于 hidden size $d$。然而，尽管 HC 已经展现出提升模型性能的潜力，我们发现堆叠多层时训练会频繁出现数值不稳定，这阻碍了 HC 的 scaling。

流形约束的残差映射。mHC 的核心创新是把残差映射矩阵 $B_l$ 约束到双随机矩阵构成的流形（Birkhoff 多胞形）$\mathcal{M}$ 上，从而增强信号跨层传播的稳定性：

$$ B_l \in \mathcal{M} \coloneq \{ M \in \mathbb{R}^{n \times n} \mid M\mathbf{1}_n = \mathbf{1}_n, \; \mathbf{1}_n^T M = \mathbf{1}_n^T, \; M \geq 0 \}. $$

这个约束保证了映射矩阵的谱范数 $\|B_l\|_2$ 有上界 1，于是残差变换是非扩张的（non-expansive），这提高了前向传播和反向传播过程中的数值稳定性。此外，集合 $\mathcal{M}$ 在乘法下是封闭的，这保证了在 mHC 深层堆叠场景下的稳定性。另外，输入变换 $A_l$ 和输出变换 $C_l$ 也通过一个 Sigmoid 函数被约束为非负且有界，以避免信号相互抵消的风险。

动态参数化。三个线性映射的参数是动态生成的，被分解为一个动态（依赖输入）分量和一个静态（不依赖输入）分量。给定输入 $X_l \in \mathbb{R}^{n_{\text{hc}} \times d}$，先把它展平并归一化：$\hat{X}_l = \operatorname{RMSNorm}(\operatorname{vec}(X_l)) \in \mathbb{R}^{1 \times n_{\text{hc}}d}$。然后，我们沿用常规 HC 的做法生成无约束的原始参数 $\tilde{A}_l \in \mathbb{R}^{1 \times n_{\text{hc}}}$、$\tilde{B}_l \in \mathbb{R}^{n_{\text{hc}} \times n_{\text{hc}}}$ 和 $\tilde{C}_l \in \mathbb{R}^{n_{\text{hc}} \times 1}$：

$$ \begin{aligned} \tilde{A}_l &= \alpha_l^\mathrm{pre} \cdot (\hat{X}_l W^\mathrm{pre}_l) + S_l^\mathrm{pre}, \\ \tilde{B}_l &= \alpha_l^\mathrm{res} \cdot \operatorname{Mat}(\hat{X}_l W^\mathrm{res}_l) + S_l^\mathrm{res}, \\ \tilde{C}_l &= \alpha_l^\mathrm{post} \cdot (\hat{X}_l W^\mathrm{post}_l)^T + S_l^\mathrm{post}, \end{aligned} $$

其中 $W^\mathrm{pre}_l, W^\mathrm{post}_l \in \mathbb{R}^{n_{\text{hc}}d \times n_{\text{hc}}}$ 和 $W^\mathrm{res}_l \in \mathbb{R}^{n_{\text{hc}}d \times n_{\text{hc}}^2}$ 是用于生成动态分量的可学习参数；$\operatorname{Mat}(\cdot)$ 把大小为 $1 \times n_{\text{hc}}^2$ 的向量 reshape 成 $n_{\text{hc}} \times n_{\text{hc}}$ 的矩阵；$S_l^\mathrm{pre} \in \mathbb{R}^{1 \times n_{\text{hc}}}$、$S_l^\mathrm{post} \in \mathbb{R}^{n_{\text{hc}}\times 1}$ 和 $S_l^\mathrm{res} \in \mathbb{R}^{n_{\text{hc}} \times n_{\text{hc}}}$ 是可学习的静态偏置；$\alpha_l^\mathrm{pre}$、$\alpha_l^\mathrm{res}$、$\alpha_l^\mathrm{post} \in \mathbb{R}$ 是可学习的门控因子，初始化为很小的值。

施加参数约束。拿到无约束的原始参数 $\tilde{A}_l, \tilde{B}_l, \tilde{C}_l$ 之后，我们对它们施加前面描述的约束以增强数值稳定性。具体来说，对输入和输出映射，我们用一个 Sigmoid 函数 $\sigma(\cdot)$ 来保证非负性和有界性：

$$ \begin{aligned} A_l &= \sigma(\tilde{A}_l), \\ C_l &= 2\sigma(\tilde{C}_l). \end{aligned} $$

至于残差映射 $\tilde{B}_l$，我们把它投影到双随机矩阵的流形 $\mathcal{M}$ 上。这通过 Sinkhorn-Knopp 算法实现：先对 $\tilde{B}_l$ 施加指数函数以保证正性，得到 $M^{(0)} = \exp(\tilde{B}_l)$，然后迭代地做列归一化和行归一化：

$$ M^{(t)} = \mathcal{T}_r(\mathcal{T}_c(M^{(t-1)})), $$

其中 $\mathcal{T}_r$ 和 $\mathcal{T}_c$ 分别表示行归一化和列归一化。这个迭代收敛到一个满足约束的双随机矩阵 $B_l = M^{(t_{\text{max}})}$。我们取 $t_{\text{max}} = 20$ 作为实用取值。

2.3 CSA 与 HCA 的混合注意力

当上下文长度达到极端规模时，attention 机制成为模型中主导的计算瓶颈。对 DeepSeek-V4，我们设计了两种高效的注意力架构——Compressed Sparse Attention（CSA）压缩稀疏注意力和 Heavily Compressed Attention（HCA）重压缩注意力——并采用二者交错的混合配置，这大幅降低了长文本场景下 attention 的计算代价。CSA 同时整合了压缩和稀疏注意力两种策略：它先把每 $m$ 个 token 的 Key-Value（KV）cache 压缩成一个 entry，然后应用 DeepSeek Sparse Attention（DSA）¹⁰，让每个 query token 只 attend 到 $k$ 个压缩后的 KV entry。HCA 追求极端压缩，把每 $m^{\prime}$（$\gg m$）个 token 的 KV cache 合并成单个 entry。CSA 与 HCA 的混合架构显著提升了 DeepSeek-V4 系列的长上下文效率，让百万 token 上下文在实践中变得可行。本小节描述我们混合注意力架构的核心技术，我们也提供了一份开源实现，以无歧义地说明更多细节。

2.3.1 Compressed Sparse Attention

CSA 的核心架构如 Figure 3 所示，它先把每 $m$ 个 token 的 KV cache 压缩成一个 entry，然后应用 DeepSeek Sparse Attention 做进一步加速。

压缩的 Key-Value entry。令 $H \in \mathbb{R}^{n \times d}$ 为一串输入 hidden state，其中 $n$ 是序列长度、$d$ 是 hidden size。CSA 首先计算两组 KV entry $C^{a}, C^{b} \in \mathbb{R}^{n \times c}$ 及其对应的压缩权重 $Z^{a}, Z^{b} \in \mathbb{R}^{n \times c}$，其中 $c$ 是 head 维度：

$$ \begin{aligned} C^{a} &= H \cdot W^{aKV}, \quad C^{b} = H \cdot W^{bKV}, \\ Z^{a} &= H \cdot W^{aZ}, \quad~~ Z^{b} = H \cdot W^{bZ}, \end{aligned} $$

其中 $W^{aKV}, W^{bKV}, W^{aZ}, W^{bZ} \in \mathbb{R}^{d \times c}$ 是可训练参数。接下来，$C^{a}$ 和 $C^{b}$ 里每 $m$ 个 KV entry 会根据它们的压缩权重和可学习的位置偏置 $B^a,B^b \in \mathbb{R}^{m \times c}$ 被压缩成一个 entry，产出 $C^{\text{Comp}} \in \mathbb{R}^{\frac{n}{m} \times c}$。每个压缩 entry $C^{\text{Comp}}_{i} \in \mathbb{R}^{c}$ 按下式计算：

$$ \begin{aligned} [S^a_{mi:m(i+1)-1};S^b_{m(i-1):mi-1}] &= \operatorname{Softmax}_{\text{row}}([Z^{a}_{mi:m(i+1)-1} + B^a;Z^{b}_{m(i-1):mi-1} + B^b]), \\ C^{\text{Comp}}_{i} &= \sum_{j=mi}^{m(i+1)-1} S^a_j \odot C^{a}_{j} + \sum_{j=m(i-1)}^{mi-1} S^b_j \odot C^{b}_{j}, \end{aligned} $$

其中 $\odot$ 表示 Hadamard 积；$\operatorname{Softmax}_{\text{row}}(\cdot)$ 表示沿行维度的 softmax 操作，它在来自 $Z^a$ 和 $Z^b$ 的总共 $2m$ 个元素上做归一化。当 $i=0$ 时，$Z^b_{m(i-1):mi-1}$ 用负无穷填充，$C^b_{m(i-1):mi-1}$ 用零填充。注意每个 $C^{\text{Comp}}_{i}$ 由 $2m$ 个 KV entry 导出，但用于 $C^{\text{Comp}}_{i}$ 的 $C^b$ 下标和用于 $C^{\text{Comp}}_{i-1}$ 的 $C^a$ 下标是重叠的。因此，CSA 实际上把序列长度压缩到了 $\frac{1}{m}$ 倍。

用于稀疏选择的 lightning indexer。拿到压缩 KV entry $C^{\text{Comp}}$ 之后，CSA 应用 DSA 策略为 core attention 选出 top-k 个压缩 KV entry。首先，CSA 对 indexer key 执行与 $C^{\text{Comp}}$ 相同的压缩操作，得到压缩 indexer key $K^{\text{IComp}} \in \mathbb{R}^{\frac{n}{m} \times c^I}$，其中 $c^I$ 是 indexer 的 head 维度。然后，对一个 query token $t$，我们以低秩方式产生 indexer query $\{\mathbf{q}_{t, 1}^{I};\mathbf{q}_{t, 2}^{I};...;\mathbf{q}_{t, n_{h}^{I}}^{I}\}$：

$$ \begin{aligned} \mathbf{c}_{t}^{Q} &= \mathbf{h}_{t} \cdot W^{DQ}, \\ [\mathbf{q}_{t, 1}^{I};\mathbf{q}_{t, 2}^{I};...;\mathbf{q}_{t, n_{h}^{I}}^{I}] = \mathbf{q}_{t}^{I} &= \mathbf{c}_{t}^{Q} \cdot W^{IUQ}, \end{aligned} $$

其中 $\mathbf{h}_{t} \in \mathbb{R}^{d}$ 是 query token $t$ 的输入 hidden state；$\mathbf{c}_{t}^{Q} \in \mathbb{R}^{d_c}$ 是 query 的压缩 latent 向量；$d_c$ 表示 query 压缩维度；$n_{h}^{I}$ 表示 indexer query head 的数量；$W^{DQ} \in \mathbb{R}^{d \times d_c}$ 和 $W^{IUQ} \in \mathbb{R}^{d_c \times c^I n_h^I}$ 分别是 indexer query 的下投影和上投影矩阵。接下来，query token $t$ 与它前面的一个压缩块 $s$（$s < \operatorname{Floor}(\frac{t}{m})$）之间的 index score $I_{t, s} \in \mathbb{R}$ 按下式计算：

$$ \begin{aligned} [w_{t, 1}^I; w_{t, 2}^I; ...; w_{t, n_{h}^{I}}^I] = \mathbf{w}_t^I & = \mathbf{h}_{t} \cdot W^w, \\ I_{t, s} & = \sum_{h=1}^{n_h^I} w_{t, h}^I \cdot \text{ReLU}\left(\mathbf{q}^{I}_{t, h} \cdot K^{\text{IComp}}_{s}\right), \end{aligned} $$

其中 $W^w \in \mathbb{R}^{d \times n_{h}^{I}}$ 是一个可学习矩阵；$w_{t, h}^I \in \mathbb{R}$ 是第 $h$ 个 indexer head 的权重。对一个 query token $t$，给定它的 index score $I_{t, :}$，我们用一个 top-k 选择器有选择地保留一个压缩 KV entry 的子集 $\mathcal{C}^{\text{SprsComp}}_t$，供后续的 core attention 使用：

$$ \mathcal{C}^{\text{SprsComp}}_t = \left\{ C^{\text{Comp}}_{s} ~\Big|~ I_{t, s} \in \operatorname{Top-k} (I_{t, :}) \right\}. $$

共享 Key-Value 的 MQA。选出稀疏的 KV entry 之后，CSA 以 Multi-Query Attention（MQA）³⁰ 的方式执行 core attention，其中 $\mathcal{C}^{\text{SprsComp}}_t$ 里的每个压缩 KV entry 同时充当 attention 的 key 和 value。具体来说，对一个 query token $t$，我们先从压缩 latent 向量 $\mathbf{c}_{t}^{Q}$ 产生 attention query $\{\mathbf{q}_{t, 1};\mathbf{q}_{t, 2};...;\mathbf{q}_{t, n_{h}}\}$：

$$ [\mathbf{q}_{t, 1};\mathbf{q}_{t, 2};...;\mathbf{q}_{t, n_{h}}] = \mathbf{q}_{t} = \mathbf{c}_{t}^{Q} \cdot W^{UQ}, $$

其中 $n_{h}$ 表示 query head 的数量；$W^{UQ} \in \mathbb{R}^{d_c \times c n_h}$ 是 query 的上投影矩阵。注意 latent query 向量 $\mathbf{c}_{t}^{Q}$ 与 indexer query 用的是同一个。接下来，我们在 $\{\mathbf{q}_{t, i}\}$ 和 $\mathcal{C}^{\text{SprsComp}}_t$ 上执行 MQA：

$$ \mathbf{o}_{t,i} = \operatorname{CoreAttn}\left( \texttt{query=}\mathbf{q}_{t,i}, \texttt{key=}\mathcal{C}^{\text{SprsComp}}_t, \texttt{value=}\mathcal{C}^{\text{SprsComp}}_t \right), $$

其中 $\mathbf{o}_{t,i} \in \mathbb{R}^{c}$ 是第 $t$ 个 token 上第 $i$ 个 head 的 core attention 输出；$\operatorname{CoreAttn}(\cdot)$ 表示 core attention 操作。

分组输出投影。在 DeepSeek-V4 的配置里，$c n_h$ 相当大。因此，直接把 core attention 操作的输出 $[\mathbf{o}_{t,1}; \mathbf{o}_{t,2}; ...; \mathbf{o}_{t,n_h}]=\mathbf{o}_{t} \in \mathbb{R}^{c n_h}$ 投影到 $d$ 维的 hidden state 会带来很大的计算负担。为了缓解这个代价，我们设计了一个分组输出投影策略。具体来说，我们先把 $n_h$ 个输出分成 $g$ 组，然后对每组输出 $\mathbf{o}^G_{t, i} \in \mathbb{R}^{c \frac{n_h}{g}}$，把它投影到一个 $d_g$ 维的中间输出 $\mathbf{o}^{G'}_{t, i} \in \mathbb{R}^{d_g}$，其中 $d_g < c \frac{n_h}{g}$。最后，我们把中间输出 $[\mathbf{o}^{G'}_{t, 1}; \mathbf{o}^{G'}_{t, 2}; ...; \mathbf{o}^{G'}_{t, g}] \in \mathbb{R}^{d_gg}$ 投影到最终的 attention 输出 $\mathbf{\hat{o}}_{t} \in \mathbb{R}^{d}$。

2.3.2 Heavily Compressed Attention

HCA 的核心架构如 Figure 4 所示，它以更重的方式压缩 KV cache，但不采用稀疏注意力。

压缩的 Key-Value entry。大体上，HCA 的压缩策略与 CSA 类似，但采用更大的压缩率 $m^{\prime}$（$\gg m$），并且不做重叠压缩。令 $H \in \mathbb{R}^{n \times d}$ 为一串输入 hidden state，HCA 首先计算原始 KV entry $C \in \mathbb{R}^{n \times c}$ 及其对应的压缩权重 $Z \in \mathbb{R}^{n \times c}$：

$$ \begin{aligned} C &= H \cdot W^{KV}, \\ Z &= H \cdot W^{Z}, \end{aligned} $$

其中 $W^{KV}, W^{Z} \in \mathbb{R}^{d \times c}$ 是可训练参数。接下来，$C$ 里每 $m^{\prime}$ 个 KV entry 会根据压缩权重和可学习的位置偏置 $B \in \mathbb{R}^{m^{\prime} \times c}$ 被压缩成一个，产出 $C^{\text{Comp}} \in \mathbb{R}^{\frac{n}{m^{\prime}} \times c}$。每个压缩 entry $C^{\text{Comp}}_{i} \in \mathbb{R}^{c}$ 按下式计算：

$$ \begin{aligned} S_{m^{\prime}i:m^{\prime}(i+1)-1} &= \operatorname{Softmax}_{\text{row}}(Z_{m^{\prime}i:m^{\prime}(i+1)-1} + B), \\ C^{\text{Comp}}_{i} &= \sum_{j=m^{\prime}i}^{m^{\prime}(i+1)-1} S_j \odot C_{j}. \end{aligned} $$

通过这个压缩操作，HCA 把序列长度压缩到 $\frac{1}{m^{\prime}}$ 倍。

共享 Key-Value 的 MQA 与分组输出投影。HCA 也和 CSA 一样采用共享 KV 的 MQA 和分组输出投影策略。KV 压缩之后，对一个 query token $t$，HCA 先以低秩方式产生 attention query $\{\mathbf{q}_{t, 1};\mathbf{q}_{t, 2};...;\mathbf{q}_{t, n_{h}}\}$：

$$ \begin{aligned} \mathbf{c}_{t}^{Q} &= \mathbf{h}_{t} \cdot W^{DQ}, \\ [\mathbf{q}_{t, 1};\mathbf{q}_{t, 2};...;\mathbf{q}_{t, n_{h}}] = \mathbf{q}_{t} &= \mathbf{c}_{t}^{Q} \cdot W^{UQ}, \end{aligned} $$

其中 $\mathbf{h}_{t} \in \mathbb{R}^{d}$ 是 query token $t$ 的输入 hidden state；$n_{h}$ 表示 query head 的数量；$W^{DQ} \in \mathbb{R}^{d \times d_c}$ 和 $W^{UQ} \in \mathbb{R}^{d_c \times c n_h}$ 分别是 query 的下投影和上投影矩阵。接下来，我们在 $\{\mathbf{q}_{t, i}\}$ 和 $C^{\text{Comp}}$ 上执行 MQA：

$$ \mathbf{o}_{t,i} = \operatorname{CoreAttn}\left( \texttt{query=}\mathbf{q}_{t,i}, \texttt{key=}C^{\text{Comp}}, \texttt{value=}C^{\text{Comp}} \right), $$

其中 $\mathbf{o}_{t,i} \in \mathbb{R}^{c}$ 是第 $t$ 个 token 上第 $i$ 个 head 的 core attention 输出。接下来，和 CSA 一样，HCA 把 $n_h$ 个输出分成 $g$ 组，对每组输出 $\mathbf{o}^G_{t, i} \in \mathbb{R}^{c \frac{n_h}{g}}$，HCA 把它投影到一个 $d_g$ 维的中间输出 $\mathbf{o}^{G'}_{t, i} \in \mathbb{R}^{d_g}$，其中 $d_g < c \frac{n_h}{g}$。最后，HCA 把中间输出 $[\mathbf{o}^{G'}_{t, 1}; \mathbf{o}^{G'}_{t, 2}; ...; \mathbf{o}^{G'}_{t, g}] \in \mathbb{R}^{d_gg}$ 投影到最终的 attention 输出 $\mathbf{\hat{o}}_{t} \in \mathbb{R}^{d}$。

2.3.3 其他细节

除了上面描述的 CSA 与 HCA 核心架构，我们的混合注意力还包含若干其他技术。为了行文清晰，我们把这些附加技术从上面的介绍中略去，在本小节简要说明。同样，本小节只聚焦它们的核心思想，为简洁起见可能省略一些细枝末节。我们鼓励读者参考我们的开源实现以获得无歧义的细节。

query 与 Key-Value entry 的归一化。对 CSA 和 HCA，我们都在 core attention 操作之前，对 query 的每个 head 和压缩 KV entry 的唯一那个 head 额外做一次 RMSNorm。这个归一化避免了 attention logits 爆炸，也可能改善训练稳定性。

部分 Rotary Positional Embedding。对 CSA 和 HCA，我们都对 attention query、KV entry 和 core attention 输出部分地施加 Rotary Positional Embedding（RoPE）³¹。具体来说，对 CSA 和 HCA 中用到的每个 query 向量和 KV entry 向量，我们对它的最后 64 维施加 RoPE。由于 KV entry 同时充当 attention 的 key 和 value，朴素的 core attention 输出 $\{\mathbf{o}_{t,i}\}$ 会携带绝对位置编码，这是 KV entry 加权和带来的。作为对策，我们也对每个 $\mathbf{o}_{t,i}$ 的最后 64 维施加位置为 $-i$ 的 RoPE。这样一来，core attention 的输出也会携带相对位置编码——每个 KV entry 对 core attention 输出的贡献也会与 query 和该 KV entry 之间的距离相关。

额外的 sliding window attention 分支。为了在 CSA 和 HCA 中严格保持因果性，每个 query 只 attend 到它前面的压缩 KV 块。因此，一个 query 无法访问它自己所在压缩块内其他 token 的信息。同时，在语言建模中，越靠近的 token 通常与 query token 的相关性越大。基于这些原因，我们给 CSA 和 HCA 都引入了一条 sliding window 形式的补充注意力分支，以更好地建模局部依赖。具体来说，对每个 query token，我们额外产生 $n_{\text{win}}$ 个未压缩的 KV entry，对应最近的 $n_{\text{win}}$ 个 token。在 CSA 和 HCA 的 core attention 里，这些滑动窗口内的 KV entry 会与压缩 KV entry 一起使用。

Attention sink。在 CSA 和 HCA 的 core attention 中，我们采用 attention sink 这个技巧³²³³。具体来说，我们设置一组可学习的 sink logit $\{z^{\prime}_1, z^{\prime}_2, ..., z^{\prime}_{n_h}\}$。对第 $h$ 个 attention head，$\operatorname{Exp}(z^{\prime}_h)$ 会被加到 attention score 的分母上：

$$ s_{h, i, j} = \frac{\operatorname{Exp}(z_{h, i, j})}{\sum_k \operatorname{Exp}(z_{h, i, k}) + \operatorname{Exp}(z^{\prime}_h)}, $$

其中 $s_{h, i, j}, z_{h, i, j} \in \mathbb{R}$ 表示第 $h$ 个 attention head 在第 $i$ 个 query token 与第 $j$ 个在前的 token 或压缩块之间的 attention score 和 attention logit。这个技巧允许每个 query head 把自己的 attention score 总和调整为不等于 1，甚至接近 0。

2.3.4 效率讨论

由于采用了 CSA 与 HCA 的混合，加上低精度的计算与存储，DeepSeek-V4 系列的 attention 模块在 attention FLOPs 和 KV cache 大小两方面都达到了出色的效率，长上下文场景下尤其如此。第一，我们对 KV entry 采用混合存储格式：RoPE 那部分维度用 BF16 精度，其余维度用 FP8 精度。这种混合表示相比纯 BF16 存储把 KV cache 缩小了将近一半。第二，lightning indexer 内部的 attention 计算用 FP4 精度执行，这在极长上下文下加速了 attention 操作。第三，相对 DeepSeek-V3.2，DeepSeek-V4 系列选择了更小的 attention top-k，从而提升了模型在短文本和中等长度文本上的效率。最后也最重要的，压缩注意力和混合注意力技术大幅降低了 KV cache 大小和计算 FLOPs。

以 head 维度为 128 的 BF16 GQA8³⁴（LLM attention 的常见配置之一）作为基线，在 1M 上下文设定下 DeepSeek-V4 系列的 KV cache 大小可以被大幅压到该基线的约 $2\%$。此外，即便与 DeepSeek-V3.2¹⁰——一个本身已经很高效的基线——相比，DeepSeek-V4 系列在效率上仍有显著优势。它们的推理 FLOPs 和 KV cache 大小对比见 Figure 1 的右半部分。

2.4 Muon 优化器

我们对 DeepSeek-V4 系列的大多数模块采用 Muon¹²¹³ 优化器，因为它收敛更快、训练更稳定。我们的 Muon 优化的完整算法总结在 Algorithm 1 中。

Algorithm 1  DeepSeek-V4 的 Muon 优化器

Require: 学习率 η，momentum μ，weight decay λ，更新缩放因子 γ
 1: for 每个训练步 t do
 2:     for 每个逻辑独立的权重 W ∈ R^(n×m) do
 3:         G_t = ∇_W L_t(W_{t-1})                    ▷ 计算梯度
 4:         M_t = μ M_{t-1} + G_t                     ▷ 累积 momentum buffer
 5:         O'_t = HybridNewtonSchulz(μ M_t + G_t)    ▷ Nesterov trick 与混合 Newton-Schulz
 6:         O_t = O'_t · sqrt(max(n, m)) · γ          ▷ 重新缩放更新量的 RMS
 7:         W_t = W_{t-1} · (1 - η λ) - η O_t         ▷ 执行 weight decay 并更新
 8:     end for
 9: end for

基本配置。我们对 embedding 模块、prediction head 模块、mHC 模块的静态偏置与门控因子，以及所有 RMSNorm 模块的权重，保留 AdamW³⁵ 优化器。所有其他模块都用 Muon 更新。沿用 Liu 等人¹³的做法，我们也对 Muon 参数施加 weight decay、使用 Nesterov³⁶¹² 技巧，并重新缩放更新矩阵的 Root Mean Square（RMS）以便复用我们的 AdamW 超参数。与他们不同的是，我们用混合 Newton-Schulz 迭代来做正交化。

混合 Newton-Schulz 迭代。给定一个矩阵 $M$，设它的奇异值分解（SVD）为 $M = U \Sigma V^T$。Newton-Schulz 迭代的目标是把 $M$ 近似正交化为 $UV^T$。通常 $M$ 会先被归一化为 $M_0=M / ||M||_F$，以确保它的最大奇异值不超过 1。然后，每次 Newton-Schulz 迭代执行下面的操作：

$$ M_k = a M_{k-1} + b (M_{k-1} M_{k-1}^T) M_{k-1} + c (M_{k-1} M_{k-1}^T)^2 M_{k-1}. $$

我们的混合 Newton-Schulz 分两个阶段执行 10 次迭代。前 8 步用系数 $(a, b, c) = (3.4445, -4.7750, 2.0315)$ 来驱动快速收敛，把奇异值带到接近 1。最后 2 步切换到系数 $(a, b, c) = (2, -1.5, 0.5)$，它们把奇异值精确地稳定在 1。

避免 attention logits 爆炸。DeepSeek-V4 系列的注意力架构允许我们直接在 attention query 和 KV entry 上施加 RMSNorm，这有效防止了 attention logits 爆炸。因此，我们的 Muon 优化器里没有采用 QK-Clip 技术¹³。

3 通用基础设施

3.1 Expert Parallelism 中的细粒度通信-计算重叠

Mixture-of-Experts（MoE）可以通过 Expert Parallelism（EP）来加速。然而 EP 需要复杂的跨节点通信，对互联带宽和延迟提出了很高的要求。为了缓解 EP 中的通信瓶颈，并在更低的互联带宽要求下取得更高的端到端性能，我们提出一个细粒度 EP 方案，把通信和计算融合进单个流水线化的 kernel 来实现通信-计算重叠。

通信延迟是可以被隐藏的。我们 EP 方案的关键洞察是：MoE 层里的通信延迟可以被有效地隐藏在计算之下。如 Figure 5 所示，在 DeepSeek-V4 系列中，每个 MoE 层大体可以分解为四个阶段：两个通信瓶颈阶段 Dispatch 和 Combine，以及两个计算瓶颈阶段 Linear-1 和 Linear-2。我们的 profiling 显示，在单个 MoE 层内部，通信的总时间小于计算的总时间。因此，把通信和计算融合进一条统一的流水线之后，计算仍然是主导瓶颈，这意味着系统可以容忍更低的互联带宽而不损害端到端性能。

细粒度 EP 方案。为了进一步降低互联带宽需求、放大重叠带来的收益，我们引入一个更细粒度的 expert 划分方案。受 FlashMoE³⁷、 Comet³⁸ 等许多相关工作的启发，我们把 expert 切分并调度成 wave。每个 wave 由一小部分 expert 组成。一旦某个 wave 内的所有 expert 都完成了通信，计算就可以立刻开始，不必等待其他 expert。在稳态下，当前 wave 的计算、下一个 wave 的 token 传输、以及已完成 expert 的结果回送三者同时进行，如 Figure 5 所示。这在 expert 之间形成了一条细粒度流水线，让计算和通信在整个 wave 期间都保持连续。这种基于 wave 的调度在诸如强化学习（RL）rollout 这类极端场景下加速效果尤为明显——这类场景通常会遇到长尾的小 batch。

性能与开源的 mega-kernel。我们在 NVIDIA GPU 和华为昇腾 NPU 两个平台上验证了这个细粒度 EP 方案。相对很强的非融合基线，它在通用推理负载上取得 $1.50 \sim 1.73\times$ 加速，在 RL rollout、高速 agent 服务这类延迟敏感场景下最高达到 $1.96\times$。我们已经把基于 CUDA 的 mega-kernel 实现开源，命名为 MegaMoE，作为 DeepGEMM 的一个组件。

观察与建议。我们分享 kernel 开发中的观察与经验，并向硬件厂商提出一些建议，希望有助于高效的硬件设计和更好的软硬件协同设计：

• 计算-通信比。完全的通信-计算重叠取决于计算-通信比，而不是单看带宽。记峰值算力吞吐为 $C$、互联带宽为 $B$，当 $C/B \leq V_{\text{comp}} / V_{\text{comm}}$ 时通信可以被完全隐藏，其中 $V_{\text{comp}}$ 表示计算量、$V_{\text{comm}}$ 表示通信量。对 DeepSeek-V4-Pro，每个 token-expert 对需要 $6hd$ FLOPs（SwiGLU 的 gate、up、down 三个投影），但只需要 $3h$ 字节的通信（FP8 Dispatch + BF16 Combine），于是可以简化为：

$$ \frac{C}{B} \leq 2d = 6144 \; \mathrm{FLOPs/Byte}. $$

也就是说，每 GBps 的互联带宽足以隐藏 6.1 TFLOP/s 算力所对应的通信。一旦带宽达到这个阈值，它就不再是瓶颈，把更多硅片面积投入到进一步提升带宽上会带来递减的回报。我们鼓励未来的硬件设计瞄准这样的平衡点，而不是无条件地扩张带宽。

• 功耗预算。极致的 kernel 融合会同时把算力、显存、网络都推到高负载，使功耗降频成为关键的性能限制因素。我们建议未来的硬件设计为这类完全并发的负载提供足够的功耗余量。

• 通信原语。在 dispatch 阶段，我们采用 pull 式方案，每个 GPU 主动从远端 GPU 读取 activation，从而避免细粒度 push 所带来的高通知延迟。未来若硬件能提供更低延迟的跨 GPU 信令，push 就会变得可行，也能支持更自然的通信模式。

• 激活函数。我们建议把 SwiGLU 换成一个低成本的 element-wise 激活函数，不含指数或除法运算。这能直接降低 GEMM 后处理的开销，避免 GEMM 流水线被激活函数计算拖住，从而提升整体的计算吞吐和资源利用率。

3.2 用 TileLang 做灵活高效的 kernel 开发

实践中，我们精心设计的模型架构本来会产生数百个细粒度的 Torch ATen 算子。我们采用 TileLang¹⁴ 开发了一套 fused kernel 来替换其中的绝大多数，以最小的投入换来最优的性能。它也让我们在验证阶段能快速对 attention 变体这类算子做原型。这些 kernel 在模型架构开发、大规模训练，以及最终推理服务的生产部署中都扮演关键角色。作为一种领域专用语言（DSL），TileLang 平衡了开发效率与运行时效率，既支持快速开发，也支持在同一份代码里做深入的迭代优化。此外，我们与 TileLang 社区紧密协作，一起打造更敏捷、高效、稳定的 kernel 开发流程。

用 Host Codegen 降低调用开销。随着加速器性能持续提升，CPU 侧的编排开销变得越来越突出。对小而高度优化的 kernel，这种固定的 host 开销很容易成为利用率和吞吐的天花板。这类开销的一个常见来源是：host 侧逻辑（比如运行时的契约检查）为了灵活性通常用 Python 写，因而带来每次调用的固定成本。

我们用 Host Codegen 来缓解这一开销，它把大部分 host 侧逻辑挪进生成的 host 代码。具体来说，我们先在 IR（Intermediate Representation）层面协同生成 device kernel 和一个轻量的 host launcher，把从语言前端解析出来的必要元数据——比如数据类型、rank/shape 约束、stride/layout 假设——嵌进去。然后 launcher 被降低为构建在 TVM-FFI³⁹ 框架之上的 host 源码，它紧凑的调用约定和零拷贝的 tensor 互操作共同把 host 侧开销压到最低。运行时，这份生成的 host 代码负责校验和参数打包，把所有每次调用的检查都移出 Python 执行路径。我们的测量显示，CPU 侧校验开销从每次调用几十到几百微秒降到不足一微秒。

SMT solver 辅助的形式化整数分析。TileLang kernel 涉及复杂的 tensor 下标运算，需要很强的形式化整数分析能力。在 layout 推断、内存冲突检测、边界分析这些编译 pass 中，编译器必须验证整数表达式是否满足特定性质，才能启用对应的优化。因此，更强的形式化分析能力可以解锁更高级、更复杂的优化机会。

为此，我们把 Z3 SMT solver⁴⁰ 集成进 TileLang 的代数系统，为 tensor 程序中的大多数整数表达式提供形式化分析能力。我们把 TileLang 的整数表达式翻译成 Z3 的无量词非线性整数算术（QF_NIA），在计算开销和形式化表达力之间取得平衡。QF_NIA 基于整数线性规划（ILP）求解器，可以无缝地解决 kernel 中常见的标准线性整数表达式；更进一步，它内在的非线性推理能力也能有效应对诸如在可变 tensor shape 上做向量化这类高阶挑战。在合理的资源限制下，Z3 提升了整体的优化效果，同时把编译时间开销限制在几秒之内。它的影响在向量化、barrier 插入、代码化简等多个 pass 上都很显著。

数值精度与 bit 级可复现。在生产环境里，数值正确性和可复现性和裸吞吐同样关键。因此我们默认优先保证精度：在编译器层面关掉 fast-math 优化，影响精度的近似只作为显式的、需要主动开启的前端算子提供（比如 T.__exp、T.__log、T.__sin）。反过来，当需要严格的 IEEE-754 语义时，TileLang 提供带显式舍入模式的 IEEE 兼容内建函数（比如 T.ieee_fsqrt、T.ieee_fdiv、T.ieee_add），让开发者能精确指定数值行为。

我们也把 bit 级可复现作为目标，用来把 kernel 与手写 CUDA 基线对照验证。我们把 TileLang 的代数化简与 lowering 规则对齐到主流 CUDA 工具链（比如 NVCC），避免引入意外的 bit 级差异的变换。Layout 标注（比如 T.annotate_layout）还允许用户固定依赖 layout 的 lowering 决策，让求值和累加顺序与参考 CUDA 实现保持一致，从而在需要时得到 bit 完全一致的输出。

我们的评估表明，这些面向精度与可复现性的设计选择并没有牺牲性能：在保守的默认设置下，TileLang kernel 依然有竞争力，同时又暴露出可以选择性放松数值约束以换取更高速度的旋钮。

3.3 高性能的 batch 不变与确定性 kernel 库

为了实现高效的训练与推理，我们开发了一整套高性能计算 kernel。除了基础功能和最大化硬件利用率，另一个关键的设计目标是保证训练可复现，以及预训练、后训练、推理三条流水线之间的 bit 级对齐。因此，我们以极小的性能开销实现了端到端 bit 级 batch 不变（batch-invariant）且确定性的 kernel。这些 kernel 对调试、稳定性分析和一致的后训练行为都很有帮助。

Batch 不变性。Batch 不变性保证任意给定 token 的输出保持 bit 级一致，无论它在 batch 中处于什么位置。要实现 batch 不变性，主要挑战如下：

• Attention。为了实现 batch 不变性，我们不能使用 split-KV 方法⁴¹——它把单条序列的 attention 计算分散到多个 Stream Multiprocessor（SM）上以均衡 SM 负载。然而放弃这项技术会导致严重的 wave-quantization 问题，进而不利地影响 GPU 利用率。为了解决这一点，我们为 batch 不变的 decoding 设计了双 kernel 策略。第一个 kernel 在单个 SM 内部完成整条序列的 attention 输出，为完全占满的 wave 提供高吞吐。第二个 kernel 为了压低最后那个部分填充 wave 的延迟、从而缓解 wave-quantization，用多个 SM 处理单条序列。为了让这两个 kernel bit 级一致，我们精心设计了第二个 kernel 的计算路径，确保它的累加顺序与第一个 kernel 相同。此外，第二个 kernel 在 thread-block cluster 内部使用 distributed shared memory，实现跨 SM 的高速数据交换。这个双 kernel 方法有效地把 batch 不变 decoding 的开销压到可以忽略。

• 矩阵乘法。传统的 cuBLAS 库⁴²无法做到 batch 不变。因此我们端到端地用 DeepGEMM⁴³ 替换了它。此外，对非常小的 batch size，常规实现通常会用 split-k⁴⁴ 技术来提升性能。可惜 split-k 技术无法保证 batch 不变性——而这在 DeepSeek-V4 里是一个关键特性。因此我们在大多数场景下放弃了 split-k，但这可能导致性能退化。为了应对这一点，我们引入一套优化，让我们的矩阵乘法实现在大多数主要场景下能追平甚至超过标准 split-k 的性能。

确定性。确定性训练对排查硬件或软件问题非常有益。此外，当训练出现 loss spike 这类异常时，确定性让研究者能更容易定位数值层面的原因，进而改进模型设计。训练中的非确定性通常来自非确定的累加顺序，往往是使用了原子加指令。这个问题主要出现在反向传播过程中，尤其是下面这些部分：

• Attention 反向。在稀疏注意力反向传播的常规实现里，我们用 atomicAdd 为 KV token 累加梯度。由于浮点加法不满足结合律，这引入了非确定性。为了解决这个问题，我们为每个 SM 分配独立的累加 buffer，然后对所有 buffer 做一次全局确定性求和。

• MoE 反向。当来自不同 rank 的多个 SM 并发地往接收 rank 上的同一个 buffer 写数据时，协商写入位置也会引入非确定性。为此我们在每个单 rank 内部设计了一套 token 顺序预处理机制，配合跨多 rank 的 buffer 隔离。这个策略同时保证了 expert parallelism 发送结果的确定性和 MoE 反向中累加顺序的确定性。

• mHC 中的矩阵乘法。mHC 涉及一次输出维度只有 24 的矩阵乘法。对非常小的 batch size，我们不得不使用 split-k⁴⁴ 算法，而它的朴素实现会带来非确定性。为了克服这一点，我们把每个 split 部分分别输出，在后续的一个 kernel 里做确定性 reduction，从而同时保住性能和确定性。

3.4 训练框架

我们的训练框架构建在为 DeepSeek-V3⁶ 开发的可扩展、高效的基础设施之上。训练 DeepSeek-V4 时，我们继承了这个稳健的基础，同时引入几项关键创新来适配它新的架构组件——具体是 Muon 优化器、mHC 和混合注意力机制——同时保持高训练效率与稳定性。

3.4.1 Muon 的高效实现

Muon 优化器需要完整的梯度矩阵来计算参数更新，这在与 Zero Redundancy Optimizer（ZeRO）⁴⁵ 结合时构成了挑战。传统 ZeRO 是为 AdamW 这类 element-wise 优化器设计的，其中单个参数矩阵可以被切分到多个 rank 上分别更新。为了解决这一冲突，我们为 Muon 设计了一套混合的 ZeRO bucket 分配策略。

对 dense 参数，我们限制 ZeRO 并行的最大规模，并用一个背包算法把参数矩阵分配到这些 rank 上，确保每个 rank 管理的负载大致均衡。每个 rank 上的 bucket 会被 padding 到与跨 rank 最大的 bucket 一样的大小，以便高效执行 reduce-scatter。在我们的设置下，每个 rank 管理不超过五个参数矩阵，这种 padding 通常带来不到 10% 的显存开销。当数据并行的总规模超过 ZeRO 的上限时，我们会在多出来的数据并行组上冗余地计算 Muon 更新，用计算换取更小的 bucket 总显存。

对 MoE 参数，我们独立优化每个 expert。我们先把所有层所有 expert 的 SwiGLU⁴⁶ down 投影矩阵展平，接着是展平的 up 投影矩阵和 gate 矩阵。然后我们对这个展平的向量做 padding，确保能把它均匀分到所有 rank 上而不会切开任何一个逻辑独立的矩阵。由于 expert 数量很多，我们对 MoE 参数不设 ZeRO 并行上限，padding 开销也可以忽略。

此外，在每个 rank 上，形状相同的连续参数会被自动合并，从而能批量执行 Newton-Schulz 迭代以获得更好的硬件利用率。进一步地，我们观察到 Muon 里的 Newton-Schulz 迭代在用 BF16 矩阵乘法计算时依然稳定。利用这一点，我们用随机舍入（stochastic rounding）的方式把需要跨数据并行 rank 同步的 MoE 梯度量化到 BF16 精度，把通信量减半。为了避免低精度加法器引入累加误差，我们把常规的树形或环形 reduce-scatter 集合通信换成两阶段方案：先用一次 all-to-all 在各 rank 之间交换本地梯度，然后每个 rank 在 FP32 下做本地求和。这个设计维持了数值鲁棒性。

3.4.2 mHC 的低成本、省显存实现

相比常规残差连接，引入 mHC 会同时增加 activation 显存占用和流水线阶段之间的通信量。为了缓解这些代价，我们实施了几项优化策略。

第一，我们为训练和推理都精心设计并实现了 mHC 的 fused kernel。第二，我们引入一个有选择地 checkpoint 中间 tensor 的重算策略。具体来说，我们重算层间的大多数 hidden state 和所有归一化后的层输入，同时避免重算计算密集的操作。这在省显存与计算开销之间取得了平衡。第三，我们调整了 DualPipe 的 1F1B 重叠方案，以适配增加的流水线通信，并让 mHC 中的一些操作可以并发执行。

这些优化合起来把 mHC 的 wall-time 开销限制在重叠后 1F1B 流水线阶段的仅 6.7%。工程优化的更多细节可以在专门的 mHC 论文¹¹中找到。

3.4.3 面向长上下文注意力的 Contextual Parallelism

常规的 Context Parallelism（CP）切分序列维度，每个 rank 维护连续的 $s$ 个 token。这给我们的压缩注意力机制（即 CSA 和 HCA）带来两个挑战。一方面，训练样本是由多条序列打包而成，每条序列独立地按 $m$（或 $m^{\prime}$）倍压缩，末尾不足 $m$ 个的 token 会被丢弃。于是压缩后的 KV 长度通常小于 $\frac{s}{m}$，并且各 rank 之间不一致。另一方面，压缩需要 $m$ 个连续的 KV entry，而它们可能跨在两个相邻 CP rank 的边界上。

为了应对这些挑战，我们设计了一个两阶段通信方案。第一阶段，每个 rank $i$ 把自己最后 $m$ 个未压缩的 KV entry 发给 rank $i+1$。然后 rank $i+1$ 把收到的其中一部分 entry 与本地的 $s$ 个未压缩 KV entry 一起压缩，产出固定长度 $\frac{s}{m}+1$ 的压缩 entry，其中存在一些 padding entry。第二阶段，跨所有 CP rank 做一次 all-gather，收集本地压缩好的 KV entry。然后一个融合的 select-and-pad 算子把它们重组成完整的压缩 KV entry 集合，总长度为 $\texttt{cp\_size}\cdot\frac{s}{m}$。所有 padding entry 都被放在尾部。对 HCA 和 CSA 中的 indexer，每个 query token 可见的压缩 KV entry 范围可以按规则预先计算。对 CSA 中的稀疏注意力，top-k 选择器会显式指定每个 query 可见的压缩 KV entry 下标。

3.4.4 支持灵活 activation checkpointing 的扩展自动微分

常规的 activation checkpointing 实现以整个 module 为粒度，决定反向传播时是保留还是重算它的输出 activation。这种粗粒度常常导致重算成本与 activation 显存占用之间的权衡并不理想。另一种做法是手工实现整层的前向和反向逻辑，显式管理 tensor 的 checkpoint 状态。这种方法虽然能做细粒度控制，但失去了自动微分框架的便利，大幅增加开发复杂度。

为了在不牺牲编程效率的前提下实现细粒度控制，我们实现了一套带自动微分支持的 tensor 级 activation checkpointing 机制。有了这个机制，开发者只需要实现前向，并有选择地把个别 tensor 标注为需要自动 checkpoint 与重算。我们的框架用 TorchFX⁴⁷ 来 trace 完整的计算图。对每个被标注的 tensor，它做一次反向遍历，找出重算该 tensor 所需的最小子图。我们把这些最小子图定义为重算图，并把它们插入到反向逻辑中、恰好在对应的梯度计算之前。

与手工实现相比，这个设计在训练期间不引入任何额外开销。这个框架里的重算是通过直接释放被标注 tensor 的 GPU 显存、并复用重算得到的 tensor 的存储指针来实现的，不需要任何 GPU 显存拷贝。此外，由于图 trace 是具体地执行模型，我们可以追踪每个 tensor 底层的存储指针，这使得共享存储的 tensor（比如一次 reshape 操作的输入和输出）能自动去重重算。这让开发者在标注重算时不必再推理底层的显存细节。

3.5 推理框架

我们的推理框架大体继承自 DeepSeek-V3，差别主要在 KV cache 管理上。

3.5.1 KV cache 结构与管理

为了高效管理 DeepSeek-V4 混合注意力机制所产生的异构 KV cache，我们设计了一套定制的 KV cache layout。这个 layout 如 Figure 6 所示，下面详细展开。

DeepSeek-V4 中的异构 KV entry。DeepSeek-V4 系列的混合注意力机制引入了多种类型的 KV entry，它们有不同的 KV cache 大小和更新规则。用于稀疏选择的 lightning indexer 给 KV cache 引入了额外维度，其 embedding 大小与主注意力不同。CSA 和 HCA 采用的压缩技术分别把序列长度缩短到 $\frac{1}{m}$ 和 $\frac{1}{m^{\prime}}$，从而降低了整体 KV cache 大小。结果就是不同层之间 KV cache 大小各不相同。此外，Sliding Window Attention（SWA）层也有各自不同的 KV cache 大小，以及独立的 cache 命中和淘汰策略。在压缩分支里，每 $m$ 个 token 生成一个 KV entry。当剩余 token 数不足以做压缩时，所有待处理 token 及其关联的 hidden state 必须保留在一个 buffer 里，直到压缩操作能够执行。这些被缓冲的 token 代表了一种由位置上下文决定的序列状态，也在 KV cache 框架内统一管理。

管理混合注意力 KV cache 的挑战。混合注意力机制违背了 PagedAttention 及其变体背后的基本假设。尽管近期的混合 KV cache 管理算法（比如 Jenga⁴⁸、Hymba⁴⁹）针对通用混合注意力模型或特定结构，但有两个主要障碍阻止我们在 PagedAttention 框架下把所有层的 KV cache 统一起来：

• 多样的 cache 策略，比如 Sliding Window Attention 所用的那种。
• 高性能 attention kernel 施加的约束，包括对齐要求。

为了高效管理 DeepSeek-V4 的 KV cache，我们针对这两个挑战设计了相应策略。

为 SWA 和未压缩尾部 token 设计的 state cache。为了应对第一个障碍，我们采用一种替代的 cache 管理机制。既然 SWA 的设计目标是在有限 KV cache 大小下提升性能，把它——连同压缩分支的未压缩尾部 token 一起——当作一个状态空间模型来看待是合理的。于是对应的 KV cache 可以被视为一种只依赖当前位置的、序列专属的状态。相应地，我们预分配一个固定且有限大小的 state cache 池，动态地分配给每条序列。

稀疏注意力 kernel 协同设计。至于第二个障碍，常规的高性能 attention kernel 通常假定每个 block 有固定的 $B$ 个 token 以优化性能，这在 CSA 里对应 $B\cdot m$ 个原始 token、在 HCA 里对应 $B\cdot m^{\prime}$ 个。通过采用高性能的稀疏注意力 kernel，不同层可以容纳每 block 可变的 token 数而不产生性能退化。要做到这点，需要协同设计 KV cache layout 和稀疏注意力 kernel。比如把 block padding 到与 cache line 对齐可以提升性能。因此，对压缩率为 $m$ 的 CSA 和压缩率为 $m^{\prime}$ 的 HCA，每个 block 的原始 token 数可以是 $\operatorname{lcm}(m,m^{\prime})$——这两个压缩率的最小公倍数——的任意整数倍。

3.5.2 KV cache 的磁盘存储

在部署 DeepSeek-V4 时，我们利用一套磁盘上的 KV cache 存储机制，消除共享前缀请求的重复 prefill。对 CSA/HCA 中的压缩 KV entry 和 Sliding Window Attention（SWA）中的未压缩 KV entry，我们设计了各自独立的存储管理方案。

对 CSA 和 HCA，我们直接把所有压缩 KV entry 存到磁盘。当一个请求命中已存储的前缀时，我们读取并复用该前缀对应的压缩 KV entry，一直到最后一个完整的压缩块。特别地，对尾部那个不完整块里的前缀 token，我们仍然需要重算它们来恢复未压缩的 KV entry，因为 CSA 和 HCA 里的未压缩 KV entry 并不存储。

对 SWA 的 KV entry，由于它们不做压缩而且每一层都存在，其体积大约是压缩后的 CSA 和 HCA KV entry 的 8 倍。为了高效处理这些庞大的 SWA KV entry，我们提出并实现了三种不同的磁盘 SWA KV entry 管理策略，每种在存储开销和计算冗余之间给出不同的权衡：

• 完整 SWA 缓存。这个策略存储所有 token 的完整 SWA KV entry，保证计算零冗余。在这个策略下，命中前缀的 SWA KV entry 只需读取该前缀内最后 $n_{\text{win}}$ 个 token 的磁盘缓存就能重建。尽管计算上零冗余，这个策略对现代基于 SSD 的存储系统而言效率不高——每个命中请求只会访问所存 SWA KV cache 的一小部分，导致写密集的、不均衡的访问模式。

• 周期性 checkpoint。这个策略每 $p$ 个 token 就 checkpoint 一次最近 $n_{\text{win}}$ 个 token 的 SWA KV entry，其中 $p$ 是可调参数。对命中的前缀，我们加载最近一次 checkpoint 的状态，然后重算剩余的尾部 token。通过调 $p$，这个策略能按需在存储与计算之间做权衡。

• 零 SWA 缓存。这个策略不存储任何 SWA KV entry。对命中的前缀，我们需要做更多重算来恢复 SWA KV entry。具体来说，在每个 attention 层里，每个 token 的 SWA KV entry 只依赖上一层最近 $n_{\text{win}}$ 个 token 的 SWA KV entry。因此，借助已缓存的 CSA 和 HCA KV entry，对一个 $L$ 层的模型，只需重算最后 $n_{\text{win}}\cdot L$ 个 token 就足以恢复最后 $n_{\text{win}}$ 个 SWA KV entry。

根据具体的部署场景，我们选择最合适的策略来达成期望的存储-计算权衡。

4 预训练

4.1 数据构建

在 DeepSeek-V3 预训练数据的基础上，我们努力构建一个更多样、质量更高、有效上下文更长的训练语料。我们持续打磨数据构建流水线。对来自网页的数据，我们实施过滤策略去除批量自动生成和模板化的内容，从而降低模型崩塌（model collapse）的风险⁵⁰。数学和编程语料仍然是训练数据的核心组成部分，我们还在 mid-training 阶段加入 agentic 数据来进一步增强 DeepSeek-V4 系列的代码能力。对多语言数据，我们为 DeepSeek-V4 构建了更大的语料，改善它对不同文化中长尾知识的捕捉。对 DeepSeek-V4，我们特别强调长文档数据的整理，优先选取科研论文、技术报告以及其他体现独特学术价值的材料。以上合起来，我们的预训练语料超过 32T token，包含数学内容、代码、网页、长文档以及其他高质量类别。

对预训练数据，我们基本沿用 DeepSeek-V3 的预处理策略。分词方面，在 DeepSeek-V3 tokenizer 的基础上，我们引入了少量用于上下文构建的 special token，词表大小仍保持 128K。我们也从 DeepSeek-V3 继承了 token-splitting⁶ 和 Fill-in-Middle（FIM）⁵¹ 策略。受 Ding 等人⁵²启发，我们把来自不同来源的文档打包成合适的序列，以最小化样本截断。与 DeepSeek-V3 不同，我们在预训练中采用 sample 级别的 attention masking。

4.2 预训练设置

4.2.1 模型设置

DeepSeek-V4-Flash。我们把 Transformer 层数设为 43，hidden 维度 $d$ 设为 4096。前两层用纯 sliding window attention。后续各层交错使用 CSA 和 HCA。对 CSA，我们把压缩率 $m$ 设为 4，indexer query head 数 $n_{h}^{I}$ 设为 64，indexer head 维度 $c^{I}$ 设为 128，稀疏注意力选中的 KV entry 数（即 attention top-k）设为 512。对 HCA，我们把压缩率 $m^{\prime}$ 设为 128。CSA 和 HCA 都把 query head 数 $n_{h}$ 设为 64，head 维度 $c$ 设为 512，query 压缩维度 $d_{c}$ 设为 1024。输出投影分组数 $g$ 设为 8，每个中间 attention 输出的维度 $d_{g}$ 设为 1024。对额外的 sliding window attention 分支，窗口大小 $n_{\text{win}}$ 设为 128。我们在所有 Transformer block 里都用 MoE 层，但前 3 个 MoE 层用 Hash routing 策略。每个 MoE 层由 1 个 shared expert 和 256 个 routed expert 组成，每个 expert 的中间 hidden 维度为 2048。routed expert 中，每个 token 会激活 6 个。Multi-token prediction 深度设为 1。至于 mHC，扩展因子 $n_{\text{hc}}$ 设为 4，Sinkhorn-Knopp 迭代次数 $t_{\text{max}}$ 设为 20。在这个配置下，DeepSeek-V4-Flash 总参数量 284B，每个 token 激活 13B。

DeepSeek-V4-Pro。我们把 Transformer 层数设为 61，hidden 维度 $d$ 设为 7168。前两层用 HCA。后续各层交错使用 CSA 和 HCA。对 CSA，我们把压缩率 $m$ 设为 4，indexer query head 数 $n_{h}^{I}$ 设为 64，indexer head 维度 $c^{I}$ 设为 128，稀疏注意力选中的 KV entry 数（即 attention top-k）设为 1024。对 HCA，我们把压缩率 $m^{\prime}$ 设为 128。CSA 和 HCA 都把 query head 数 $n_{h}$ 设为 128，head 维度 $c$ 设为 512，query 压缩维度 $d_{c}$ 设为 1536。输出投影分组数 $g$ 设为 16，每个中间 attention 输出的维度 $d_{g}$ 设为 1024。对额外的 sliding window attention 分支，窗口大小 $n_{\text{win}}$ 设为 128。我们在所有 Transformer block 里都用 MoE 层，但前 3 个 MoE 层用 Hash routing 策略。每个 MoE 层由 1 个 shared expert 和 384 个 routed expert 组成，每个 expert 的中间 hidden 维度为 3072。routed expert 中，每个 token 会激活 6 个。Multi-token prediction 深度设为 1。至于 mHC，扩展因子 $n_{\text{hc}}$ 设为 4，Sinkhorn-Knopp 迭代次数 $t_{\text{max}}$ 设为 20。在这个配置下，DeepSeek-V4-Pro 总参数量 1.6T，每个 token 激活 49B。

4.2.2 训练设置

DeepSeek-V4-Flash。我们对大多数参数采用 Muon 优化器¹²¹³，但对 embedding 模块、prediction head 模块和所有 RMSNorm 模块的权重采用 AdamW 优化器³⁵。对 AdamW，我们把超参数设为 $\beta_{1}=0.9$、$\beta_{2}=0.95$、$\varepsilon=10^{-20}$、$\mathrm{weight\_decay}=0.1$。对 Muon，我们把 momentum 设为 0.95、weight decay 设为 0.1，并把每个更新矩阵的 RMS 重新缩放到 0.18 以便复用 AdamW 的学习率。我们在 32T token 上训练 DeepSeek-V4-Flash，和 DeepSeek-V3 一样也采用 batch size 调度策略，把 batch size（以 token 计）从一个较小值增长到 75.5M，然后在训练的大部分时间里保持 75.5M。学习率在前 2000 步线性 warmup，在训练的大部分时间里维持在 $2.7\times 10^{-4}$。训练接近结束时，我们最终按 cosine 调度把学习率衰减到 $2.7\times 10^{-5}$。训练从 4K 序列长度开始，我们逐步把训练序列长度扩展到 16K、64K 和 1M。至于稀疏注意力的设置，我们先用 dense attention 对模型做前 1T token 的 warmup，在 64K 序列长度时引入稀疏注意力，并在余下的训练中一直保持稀疏注意力。引入 attention 稀疏性时，我们先设一个短阶段来 warmup CSA 中的 lightning indexer，然后在训练的大部分时间里以稀疏注意力训练模型。对 auxiliary-loss-free 负载均衡，我们把 bias 更新速度设为 0.001。对 balance loss，我们把权重设为 0.0001，以避免单条序列内部出现极端不均衡。MTP loss 权重在训练的大部分时间里设为 0.3，学习率开始衰减时改为 0.1。

DeepSeek-V4-Pro。除了具体的超参数取值，DeepSeek-V4-Pro 的训练设置与 DeepSeek-V4-Flash 大体一致。我们对大多数参数采用 Muon 优化器，但对 embedding 模块、prediction head 模块和所有 RMSNorm 模块的权重采用 AdamW。AdamW 和 Muon 的超参数与 DeepSeek-V4-Flash 相同。我们在 33T token 上训练 DeepSeek-V4-Pro，同样采用 batch size 调度策略，最大 batch size 为 94.4M token。学习率调度策略与 DeepSeek-V4-Flash 大体相同，但峰值学习率设为 $2.0\times 10^{-4}$、末端学习率设为 $2.0\times 10^{-5}$。训练同样从 4K 序列长度开始，逐步扩展到 16K、64K 和 1M。相比 DeepSeek-V4-Flash，DeepSeek-V4-Pro 一开始的 dense attention 阶段更长，而引入稀疏注意力的策略与 DeepSeek-V4-Flash 相同，遵循两阶段训练方法。对 auxiliary-loss-free 负载均衡，我们把 bias 更新速度设为 0.001。对 balance loss，我们把权重设为 0.0001，以避免单条序列内部出现极端不均衡。MTP loss 权重在训练的大部分时间里设为 0.3，学习率开始衰减时改为 0.1。

4.2.3 缓解训练不稳定

训练万亿参数级别的 MoE 模型带来显著的稳定性挑战，DeepSeek-V4 系列也不例外。训练过程中我们遇到了明显的不稳定问题。简单的回滚虽然能暂时恢复训练状态，但作为长期方案并不够，因为它无法阻止 loss spike 再次出现。经验上，我们发现 spike 的发生一致地与 MoE 层里的 outlier 相关，而路由机制本身似乎加剧了这些 outlier 的产生。因此我们试图从两个维度解决这个问题：打破路由诱发的恶性循环，以及直接抑制异常值。所幸我们发现了两个能有效维持训练稳定的实用技术。尽管对其底层机制的完整理论理解目前仍是开放问题，我们还是把它们公开分享出来，以促进社区的进一步探索。

Anticipatory Routing（前瞻路由）。我们发现，把主干网络与路由网络的同步更新解耦，能显著改善训练稳定性。因此在第 $t$ 步，我们用当前的网络参数 $\theta_{t}$ 做特征计算，但路由下标是用历史网络参数 $\theta_{t-\Delta t}$ 计算并施加的。实践中，为了规避两次加载模型参数的开销，我们在第 $t-\Delta t$ 步就提前取出第 $t$ 步的数据。我们"前瞻地"计算并缓存稍后第 $t$ 步要用的路由下标，这也是我们把这个方法命名为 Anticipatory Routing 的原因。我们也在基础设施层面对它做了大量优化。第一，考虑到预计算路由下标只需要在数据上做一次前向，我们精心编排了流水线执行以及计算与 Expert Parallelism（EP）通信的重叠，成功把 Anticipatory Routing 的额外 wall-clock 开销限制在约 20%。第二，我们引入一个自动检测机制，仅在出现 loss spike 时触发一次短回滚并启用 Anticipatory Routing；在这个模式下运行一段时间后，系统再回到标准训练。最终，这种动态启用让我们能在整体额外训练开销可忽略的前提下避开 loss spike，而且完全不损害模型性能。

SwiGLU Clamping。在此前的文献⁵³⁵⁴中，clamping 已被明确用来约束数值范围，从而增强训练稳定性。在我们实际的训练过程中，我们经验性地发现施加 SwiGLU clamping³³ 能有效消除 outlier，对稳定训练过程有实质帮助，同时不损害性能。在 DeepSeek-V4-Flash 和 DeepSeek-V4-Pro 的整个训练过程中，我们把 SwiGLU 的线性分量 clamp 到 $[-10,10]$ 区间，同时把 gate 分量的上界压在 10。

4.3 评测

4.3.1 评测 benchmark

对基础模型的评测，我们考虑覆盖四个关键维度的 benchmark：世界知识、语言理解与推理、代码与数学，以及长上下文处理。

世界知识类 benchmark 包括 AGIEval⁵⁵、C-Eval⁵⁶、CMMLU⁵⁷、MMLU⁵⁸、MMLU-Redux⁵⁹、MMLU-Pro¹⁹、MMMLU⁶⁰、MultiLoKo⁶¹、Simple-QA verified⁶²、SuperGPQA⁶³、FACTS Parametric⁶⁴ 和 TriviaQA⁶⁵。

语言理解与推理类 benchmark 包括 BigBench Hard（BBH）⁶⁶、DROP⁶⁷、HellaSwag⁶⁸、CLUEWSC⁶⁹ 和 WinoGrande⁷⁰。

代码与数学类 benchmark 包括 BigCodeBench⁷¹、HumanEval⁷²、GSM8K⁷³、MATH⁷⁴、MGSM⁷⁵ 和 CMath⁷⁶。

长上下文类 benchmark 包括 LongBench-V2⁷⁷。

4.3.2 评测结果

在 Table 1 中，我们给出 DeepSeek-V3.2、DeepSeek-V4-Flash 和 DeepSeek-V4-Pro 三个基础模型的详细对比，全部在统一的内部框架下、以严格一致的设置评测。

Table 1：DeepSeek-V3.2-Base、DeepSeek-V4-Flash-Base 与 DeepSeek-V4-Pro-Base 的对比。所有模型都在我们的内部框架中评测并共享相同的评测设置。分差不超过 0.3 的成绩视为同一水平。每行最高分加粗，第二高用斜体。

类别	Benchmark（指标）	# Shots	DeepSeek-V3.2-Base	DeepSeek-V4-Flash-Base	DeepSeek-V4-Pro-Base
	架构	-	MoE	MoE	MoE
	激活参数量	-	37B	13B	49B
	总参数量	-	671B	284B	1.6T
世界知识	AGIEval (EM)	0-shot	80.1	82.6	83.1
	MMLU (EM)	5-shot	87.8	88.7	90.1
	MMLU-Redux (EM)	5-shot	87.5	89.4	90.8
	MMLU-Pro (EM)	5-shot	65.5	68.3	73.5
	MMMLU (EM)	5-shot	87.9	88.8	90.3
	C-Eval (EM)	5-shot	90.4	92.1	93.1
	CMMLU (EM)	5-shot	88.9	90.4	90.8
	MultiLoKo (EM)	5-shot	38.7	42.2	51.1
	Simple-QA verified (EM)	25-shot	28.3	30.1	55.2
	SuperGPQA (EM)	5-shot	45.0	46.5	53.9
	FACTS Parametric (EM)	25-shot	27.1	33.9	62.6
	TriviaQA (EM)	5-shot	83.3	82.8	85.6
语言与推理	BBH (EM)	3-shot	87.6	86.9	87.5
	DROP (F1)	1-shot	88.2	88.6	88.7
	HellaSwag (EM)	0-shot	86.4	85.7	88.0
	WinoGrande (EM)	0-shot	78.9	79.5	81.5
	CLUEWSC (EM)	5-shot	83.5	82.2	85.2
代码与数学	BigCodeBench (Pass@1)	3-shot	63.9	56.8	59.2
	HumanEval (Pass@1)	0-shot	62.8	69.5	76.8
	GSM8K (EM)	8-shot	91.1	90.8	92.6
	MATH (EM)	4-shot	60.5	57.4	64.5
	MGSM (EM)	8-shot	81.3	85.7	84.4
	CMath (EM)	3-shot	92.6	93.6	90.9
长上下文	LongBench-V2 (EM)	1-shot	40.2	44.7	51.5

把 DeepSeek-V4-Flash-Base 与 DeepSeek-V3.2-Base 对比，能看到一个很有说服力的效率故事。尽管激活参数量和总参数量都显著更小，DeepSeek-V4-Flash-Base 在一大批 benchmark 上都超过了 DeepSeek-V3.2-Base。这个优势在世界知识任务和有挑战的长上下文场景下尤为明显。这些结果说明，DeepSeek-V4-Flash-Base 的架构改进、更精细的数据质量以及训练优化，即便在更紧凑的参数预算下也能带来更好的性能，在多数评测上有效地超越了更大的 DeepSeek-V3.2-Base。

更进一步，DeepSeek-V4-Pro-Base 展现出又一次决定性的能力跃升，对 DeepSeek-V3.2-Base 和 DeepSeek-V4-Flash-Base 几乎形成全面压制。在几乎所有类别都有提升的情况下，DeepSeek-V4-Pro-Base 在最苛刻的 benchmark 上把 DeepSeek 基础模型的性能推到了新高。在知识密集型评测上它带来了戏剧性的增益，同时也大幅推进了长上下文理解。在大多数推理和代码 benchmark 上，DeepSeek-V4-Pro-Base 也超过了前面两个模型。这种全面提升确认了 DeepSeek-V4-Pro-Base 是 DeepSeek 系列中最强的基础模型，在知识、推理、代码和长上下文各方面都优于它的前代。

5 后训练

5.1 后训练流程

预训练之后，我们进行一个后训练阶段来产出 DeepSeek-V4 系列的最终模型。尽管训练流程大体上沿袭 DeepSeek-V3.2，但有一处关键的方法替换：混合强化学习（RL）阶段被 On-Policy Distillation（OPD）¹⁵¹⁶ 完全取代。

5.1.1 专家模型训练

领域专家模型的开发是通过改造 DeepSeek-V3.2 的训练流程完成的。具体来说，每个模型依次经过一个初始的 fine-tuning 阶段，以及随后由领域专属 prompt 和奖励信号引导的强化学习（RL）。RL 阶段我们实现了 Group Relative Policy Optimization（GRPO）算法，超参数与我们此前的研究⁴¹⁰保持紧密一致。

Reasoning effort（推理投入）。人们普遍认识到，模型在推理任务上的表现从根本上受所投入的计算量支配。因此，我们在不同的 RL 配置下训练不同的专家模型，以便开发出为不同推理容量优化的模型。如 Table 2 所示，DeepSeek-V4-Pro 和 DeepSeek-V4-Flash 都支持三种具体的 reasoning effort 模式。对每种模式，我们在 RL 训练中施加不同的长度惩罚和上下文窗口，这导致推理时的输出 token 长度各不相同。为了整合这些不同的推理模式，我们使用由 <think> 和 </think> token 界定的专用回复格式。此外，对"Think Max"模式，我们会在 system prompt 开头前置一段特定指令来引导模型的推理过程，如 Table 3 所示。

Table 2：三种推理模式对比

推理模式	特征	典型使用场景	回复格式
Non-think	基于习惯或简单规则的快速、直觉式回复。	日常例行任务、紧急反应、低风险决策。	</think> 摘要
Think High	有意识的逻辑分析，更慢但更准确。	复杂问题求解、规划、中风险决策。	<think> 思考 token </think> 摘要
Think Max	把推理推到极致。慢但强大。	探索模型推理能力的边界。	1. 开头加一段特殊 system prompt；2. <think> 思考 token </think> 摘要

Table 3：“Think Max"模式注入 system prompt 的指令。

Injected Instruction

Reasoning Effort: Absolute maximum with no shortcuts permitted.
You MUST be very thorough in your thinking and comprehensively decompose the problem
to resolve the root cause, rigorously stress-testing your logic against all potential
paths, edge cases, and adversarial scenarios.
Explicitly write out your entire deliberation process, documenting every intermediate
step, considered alternative, and rejected hypothesis to ensure absolutely no
assumption is left unchecked.

Generative Reward Model（生成式奖励模型）。通常，易于验证的任务可以用简单的规则式 verifier 或测试用例来有效优化。相反，难以验证的任务传统上依赖 Reinforcement Learning from Human Feedback（RLHF），这需要大量人工标注来训练一个标量奖励模型。然而在 DeepSeek-V4 系列的后训练阶段，我们摒弃了这些传统的标量式奖励模型。取而代之，为了应对难以验证的任务，我们整理了 rubric 引导的 RL 数据，并用一个 Generative Reward Model（GRM）来评估策略轨迹。关键在于，我们直接对 GRM 本身施加 RL 优化。在这个范式下，actor 网络原生地充当 GRM，使模型的评判（judging）能力可以与它标准的生成能力一起被联合优化。通过统一这两个角色，模型内部的推理能力被内在地融入它的评估过程，得到高度鲁棒的打分。此外，这个方法只需要极少量多样的人工标注就能取得更好的性能，因为模型是用自己的逻辑在复杂任务上做泛化。

Tool-call schema 与 special token。与上一个版本一致，我们用一个专门的 <think></think> 标签来划出推理路径。在 DeepSeek-V4 系列中，我们引入了一种新的 tool-call schema，它使用特殊的 |DSML| token 并采用基于 XML 的格式来发起工具调用，如 Table 4 所示。我们的实验表明，XML 格式有效缓解了转义失败、降低了 tool-call 错误，为模型与工具的交互提供了更鲁棒的接口。

Table 4：DeepSeek-V4 系列的 tool-call schema。

## Tools

You have access to a set of tools to help answer the user's question. You can invoke tools by writing a "<|DSML|tool_calls>" block like the following:

<|DSML|tool_calls>
<|DSML|invoke name="$TOOL_NAME">
<|DSML|parameter name="$PARAMETER_NAME" string="true|false">$PARAMETER_VALUE</|DSML|parameter>
...
</|DSML|invoke>
<|DSML|invoke name="$TOOL_NAME2">
...
</|DSML|invoke>
</|DSML|tool_calls>

String parameters should be specified as is and set `string="true"`. For all other types (numbers, booleans, arrays, objects), pass the value in JSON format and set `string="false"`.

If thinking_mode is enabled (triggered by <think>), you MUST output your complete reasoning inside <think>...</think> BEFORE any tool calls or final response.

Otherwise, output directly after </think> with tool calls or final response.

### Available Tool Schemas

{Tool Definition...}

You MUST strictly follow the above defined tool name and parameter schemas to invoke tool calls.

Interleaved Thinking（交错思考）。DeepSeek-V3.2 引入了一种上下文管理策略：跨 tool-result 轮次保留推理痕迹，但在新的 user message 到来时丢弃它们。这个做法虽然有效，但在复杂的 agentic 工作流里仍然造成了不必要的 token 浪费——每一个新的 user 轮次都会冲掉所有累积的推理内容，迫使模型从零重建它的解题状态。借助 DeepSeek-V4 系列扩展到 1M token 的上下文窗口，我们进一步改进这个机制，以最大化 agentic 环境下交错思考的效果：

• Tool-calling 场景。如 Figure 7(a) 所示，整段对话中所有推理内容都被完整保留。与每逢新 user 轮次就丢弃思考痕迹的 DeepSeek-V3.2 不同，DeepSeek-V4 系列跨所有轮次保留完整的推理历史，包括跨越 user message 边界。这让模型能在长程 agent 任务上维持一条连贯、累积的思维链。

• 通用对话场景。如 Figure 7(b) 所示，原有策略被保留：新的 user message 到来时丢弃此前轮次的推理内容，让上下文在"持久推理痕迹收益有限"的场景下保持简洁。

和 DeepSeek-V3.2 一样，那些通过 user message 来模拟工具交互的 agent 框架（比如 Terminus）可能不会触发 tool-calling 的上下文路径，因此也无法从增强的推理持久化中获益。对这类架构，我们仍然推荐使用 non-think 模型。

Quick Instruction（快速指令）。在 chatbot 场景里，生成回复之前必须先执行若干辅助任务（比如判断是否要触发网页搜索、意图识别等）。按惯例这些任务由一个独立的小模型处理，而由于它无法复用已有的 KV cache，就需要冗余的 prefill。为了突破这个限制，我们引入 Quick Instruction。我们直接在输入序列后追加一组专用 special token，每个 token 对应一个具体的辅助任务。通过直接复用已经算好的 KV cache，这个机制完全避免了冗余 prefill，并让生成搜索 query、判定权威性与领域这类任务可以并行执行。因此，这个方案显著降低了用户感知的首 token 时间（TTFT），也消除了维护和迭代一个额外小模型的工程开销。支持的 Quick Instruction token 汇总在 Table 5 中。

Table 5：用于辅助任务的 Quick Instruction special token。

Special token	描述	格式
<|action|>	判断用户 prompt 是需要网页搜索还是可以直接回答。	...<|User|>{prompt}<|Assistant|><think><|action|>
<|title|>	在第一次 assistant 回复之后生成一个简洁的会话标题。	...<|Assistant|>{response}<|end_of_sentence|><|title|>
<|query|>	为用户 prompt 生成搜索 query。	...<|User|>{prompt}<|query|>
<|authority|>	对用户 prompt 在信息源权威性上的需求做分类。	...<|User|>{prompt}<|authority|>
<|domain|>	识别用户 prompt 所属的领域。	...<|User|>{prompt}<|domain|>
<|extracted_url|> <|read_url|>	判断用户 prompt 里的每个 URL 是否应该被抓取和阅读。	...<|User|>{prompt}<|extracted_url|>{url}<|read_url|>

5.1.2 On-Policy Distillation

在通过专门的 fine-tuning 和强化学习训练出多个领域专家之后，我们采用多教师的 On-Policy Distillation（OPD）¹⁵¹⁶ 作为把专家能力合并进最终模型的主要技术。OPD 已经成为一种有效的后训练范式，能高效地把领域专家的知识与能力迁移到单个统一模型上。它的做法是让学生在自己生成的轨迹上学习教师模型的输出分布。形式化地，给定一组 $N$ 个专家模型 $\{\pi_{E_{1}},\pi_{E_{2}},\dots,\pi_{E_{N}}\}$，OPD 的目标函数定义为：

$$ \mathcal{L}_{\text{OPD}}(\theta) = \sum_{i=1}^{N} w_i \cdot \text{D}_{\text{KL}}\left(\pi_\theta \parallel \pi_{E_i}\right). $$

这个式子里，$w_{i}$ 表示分配给每个专家的权重，通常由该专家的相对重要性决定。计算反向 KL loss $\text{D}_{\text{KL}}\left(\pi_{\theta} \parallel \pi_{E_{i}}\right)$ 需要从学生 $\pi_{\theta}$ 采样训练轨迹，以维持 on-policy 学习。其底层逻辑保证了统一策略 $\pi_{\theta}$ 会有选择地向与当前任务上下文相关的那个专家学习（比如数学推理任务对齐数学专家、编程任务对齐代码专家）。通过这个机制，物理上分离的专家权重所携带的知识经由 logits 层面的对齐被整合进统一的参数空间，实际上规避了传统权重合并或混合 RL 技术常遇到的性能退化。这一阶段，我们用了覆盖各个领域的十多个教师模型来蒸馏出单个学生模型。

在处理上述 OPD 目标时，此前的工作通常把全词表 KL loss 简化为每个 token 位置上的 token 级 KL 估计，并复用 RL 框架，把 $\texttt{sg}\big[\log\frac{\pi_{E_{i}}(y_{t}|x,y_{

5.2 后训练基础设施

我们的后训练基础设施构建在为 DeepSeek-V3.2 开发的可扩展框架之上。具体来说，我们集成了 §3.4 描述的同一套分布式训练栈，以及前面介绍的用于高效自回归采样的 rollout 引擎。在这个基础上，本工作引入了下面这些主要增强。这些设计使超长上下文 RL、以及涉及十多个不同教师模型的 OPD 合并任务都能高效执行，从而大幅加快了模型发布的迭代周期。

5.2.1 FP4 量化感知训练

为了在部署时实现推理加速并降低访存流量，我们在后训练阶段引入量化感知训练（Quantization-Aware Training，QAT）⁷⁸，让模型——包括教师模型和参考模型——适应量化带来的精度损失。我们把 FP4（MXFP4）量化⁷⁹ 施加在两个组件上：（1）MoE expert 权重，它是 GPU 显存占用的主要来源³³；（2）CSA 的 indexer 里的 Query-Key（QK）路径，其中 QK activation 完全以 FP4 缓存、加载和相乘，从而在长上下文场景下加速 attention score 计算。此外，在这个 QAT 过程中，我们还把 index score $I_{:,:}$ 从 FP32 量化到 BF16。这项优化让 top-k 选择器获得 $2\times$ 加速，同时保持 KV entry 的 99.7% 召回率。

对 MoE expert 权重，按照 QAT 的通行做法，优化器维护的 FP32 master 权重先被量化到 FP4，再反量化回 FP8 用于计算。值得注意的是，我们的 FP4 到 FP8 反量化是无损的。原因在于 FP8（E4M3）相比 FP4（E2M1）多两个指数位，提供了更大的动态范围。因此，只要每个 FP8 量化块（$128\times 128$ tile）内部各 FP4 子块（$1\times 32$ tile）的最大与最小 scale factor 之比不超过某个阈值，细粒度的 scale 信息就可以被 FP8 扩展的动态范围完全吸收。我们经验性地验证了当前权重满足这个条件。这使得整条 QAT 流水线可以完全复用既有的 FP8 训练框架而无需任何修改。反向传播时，梯度是相对前向中同一份 FP8 权重计算的，并直接传回 FP32 master 权重，等价于对量化操作施加 Straight-Through Estimator（STE）。这也避免了重新量化转置权重的需要。

在 RL 训练的推理与 rollout 阶段——它们不涉及反向传播——我们直接使用原生的 FP4 量化权重，而不是模拟量化。这保证了采样期间的模型行为与线上部署完全一致，同时也减少了 kernel 的显存加载以获得实际加速，并显著降低显存占用。CSA 的 indexer 里的 QK 路径我们也做类似处理。

5.2.2 面向全词表 OPD 的高效教师调度

我们的框架支持全词表 On-Policy Distillation（OPD），教师数量实际上没有上限，每个教师都可能有万亿级参数。为了做到这点，所有教师权重都 offload 到一个集中的分布式存储，在教师前向时按需加载，并采用类 ZeRO 的参数切分来同时缓解 I/O 和 DRAM 压力。此外，对所有教师朴素地物化词表大小 $|V|>100\text{k}$ 的 logits 是不可承受的，即便把它们暂存到磁盘也一样。我们的应对方式是：前向时只把最后一层的教师 hidden state 缓存到一个集中 buffer 里；训练时再取出这些缓存状态，过一遍对应的 prediction head 模块，即时重建完整 logits。这个设计带来的重算开销可以忽略，同时完全绕开了显式物化 logits 所带来的显存负担。为了压低教师 prediction head 的 GPU 显存占用，我们在数据分发时按教师下标给训练样本排序。这个安排保证每个不同的教师 head 在每个 mini-batch 内只加载一次，并且任意时刻设备显存里最多只有一个教师 head。所有参数和 hidden state 的加载/offload 操作都在后台异步进行，不阻塞关键路径上的计算。最后，教师与学生 logits 之间精确的 KL 散度是用一个专门的 TileLang kernel 计算的，它既加速了计算，也抑制了动态显存分配。

5.2.3 可抢占、容错的 rollout 服务

为了最大化 GPU 资源利用率，同时又能为高优任务快速腾出硬件，我们的 GPU 集群采用集群级的抢占式任务调度器，任何正在运行的任务都可能在任意时刻被抢占。此外，大规模 GPU 集群中硬件故障也很常见。为此，我们为 RL/OPD 的 rollout 实现了一个可抢占、容错的 LLM 生成服务。

具体来说，我们为每个生成请求实现了 token 粒度的 Write-Ahead Log（WAL）。每当一个请求生成出新 token，我们立刻把它追加到该请求的 WAL 里。抢占发生时，我们暂停推理引擎并保存未完成请求的 KV cache。恢复时，我们用持久化的 WAL 和保存下来的 KV cache 继续 decode。即便发生致命的硬件错误，我们也可以用 WAL 里持久化的 token 重跑 prefill 阶段来重建 KV cache。

重要的是，把未完成的请求从头重新生成在数学上是不正确的，因为这会引入长度偏差。由于较短的回复更容易在中断中"存活”，从头重生成会让模型在每次中断发生时更倾向于产出更短的序列。如果推理栈是 batch 不变且确定性的，这个正确性问题也可以通过在重生成时为采样器的伪随机数生成器使用一致的种子来解决。但这个方案仍然要付出重跑 decoding 阶段的额外成本，远不如我们的 token 粒度 WAL 方法高效。

5.2.4 把 RL 框架扩展到百万 token 上下文

我们为百万 token 序列上的高效 RL 与 OPD 引入了针对性优化。rollout 阶段，我们采用 §5.2.3 详述的可抢占、容错 rollout 服务。推理与训练阶段，我们把 rollout 数据格式分解为轻量的元数据和沉重的 per-token 字段。数据分发时，可以只加载整份 rollout 数据的元数据来执行全局 shuffle 和打包 layout 的计算。沉重的 per-token 字段通过共享内存 data loader 加载，以消除节点内的数据冗余，并在 mini-batch 粒度上一旦消费完就立即释放，大幅降低 CPU 和 GPU 两侧的内存压力。设备上 mini-batch 的数量根据负载动态确定，从而在计算吞吐与 I/O 重叠之间做出高效权衡。

5.2.5 面向 Agentic AI 的沙箱基础设施

为了满足后训练与评测期间 agentic AI 多样的执行需求，我们搭建了一个生产级的沙箱平台 DeepSeek Elastic Compute（DSec）。DSec 由三个 Rust 组件构成——API 网关（Apiserver）、单机 agent（Edge）和集群监控（Watcher）——它们通过自定义 RPC 协议互联，并在 3FS 分布式文件系统⁸⁰之上横向扩展。生产环境中，单个 DSec 集群管理数十万个并发沙箱实例。

DSec 的设计动机来自四点观察：（1）agentic 负载高度异构，从轻量的函数调用一直到完整的软件工程流水线，对操作系统和安全性的要求各不相同；（2）环境镜像数量多、体积大，却必须快速加载并支持迭代式定制；（3）高密度部署要求高效利用 CPU 和内存；（4）沙箱生命周期必须与 GPU 训练调度协同，包括抢占和基于 checkpoint 的恢复。基于这些观察，下面我们逐一详述 DSec 的四项核心设计。

统一接口背后的四种执行基座。DSec 暴露单一的 Python SDK（libdsec），抽象了四种执行基座。Function Call 把无状态调用派发到预热的容器池，消除冷启动开销。Container 完全兼容 Docker，并利用 EROFS⁸¹ 的按需加载做高效的镜像组装。microVM 基于 Firecracker⁸² 构建，为安全敏感的高密度部署增加了 VM 级隔离。fullVM 基于 QEMU⁸³ 构建，支持任意 guest 操作系统。四者共享同一套 API 界面——命令执行、文件传输和 TTY 访问——在它们之间切换只需要改一个参数。

通过分层存储实现镜像快速加载。DSec 通过分层的按需加载，在快速启动与一个庞大且不断增长的环境镜像库之间取得调和。对容器，基础镜像和文件系统 commit 以 3FS 支撑的只读 EROFS 层形式存储，直接挂载进 overlay 的 lowerdir。我们在挂载时就让文件元数据在本地磁盘上随时可用；同时数据块按请求从 3FS 拉取。对 microVM，DSec 使用 overlaybd⁸⁴ 磁盘格式：只读基础层放在 3FS 上以便跨实例共享，写入则落到本地的 copy-on-write 层。这样的快照可以串联，便于高效的版本管理和毫秒级恢复。

大规模并发下的密度优化。为了在单集群容纳数十万个沙箱，DSec 解决了两个资源瓶颈。第一，它缓解了虚拟化环境中重复的 page cache 占用，并施加内存回收以支持安全的超卖。第二，它减轻了容器运行时中的自旋锁竞争，从而降低每个沙箱的 CPU 开销，显著提升单机的装箱密度。

轨迹日志与抢占安全的恢复。DSec 为每个沙箱维护一份全局有序的轨迹日志，持久化记录每一次命令调用及其结果。这份轨迹有三个用途：（1）客户端快进——训练任务被抢占时，沙箱资源依然保留；恢复时 DSec 会重放此前已完成命令的缓存结果，既加速任务恢复，也避免非幂等操作重复执行带来的错误；（2）细粒度溯源——每一次状态变更的来源和相应结果都可追溯；（3）确定性重放——任何历史 session 都可以从它的轨迹忠实复现。

5.3 标准 benchmark 评测

5.3.1 评测设置

知识与推理。知识与推理数据集包括 MMLU-Pro¹⁹、GPQA²¹、Human Last Exam²⁰、Simple-QA Verified⁶²、Chinese-SimpleQA¹⁸、LiveCodeBench-v6⁸⁵、CodeForces（内部 benchmark）、HMMT 2026 Feb、Apex⁸⁶、Apex Shortlist⁸⁶、IMOAnswerBench⁸⁷ 和 PutnamBench⁸⁸。

代码方面，我们在 LiveCodeBench-v6 和一个内部 Codeforces benchmark 上评测 DeepSeek-V4 系列。对 Codeforces，我们收集了 14 场 Codeforces Division 1 比赛，共 114 道题（2025 年 5 月至 2025 年 11 月）。Elo 分按如下方式计算。对每场比赛，我们为每道题生成 32 个候选解。对每道题独立地，我们从这些解里无放回地抽 10 个，并随机排序构成提交序列。每次提交都由领域专家构建的测试套件评判。解出题目的得分遵循 OpenAI（2025）的罚分方案：模型获得那些以相同的先前失败次数解出同一题的人类参赛者的中位分。这样每个抽样提交序列都得到一个比赛总分，再转换为比赛排名，进而通过标准 Codeforces 评分系统转换为估计 rating。比赛级的期望 rating 定义为：在每题 10 次提交的所有可能抽样与排序上，对这个估计 rating 取期望。模型的总体 rating 是全部 14 场比赛这些比赛级期望 rating 的平均。

对推理与知识任务，我们把 temperature 设为 1.0，Non-think、High、Max 三种模式的上下文窗口分别设为 8K、128K 和 384K token。对数学任务（比如 HMMT、IMOAnswerBench、Apex 和 HLE），我们用下面的模板评测：

{question}
Please reason step by step, and put your final answer within \boxed{}.

对 DeepSeek-V4-Pro-Max 在数学任务上，我们用下面的模板来激发更深的推理：

Solve the following problem. The problem may ask you to prove a statement, or ask
for an answer. If finding an answer is required, you should come up with the answer,
and your final solution should also be a rigorous proof of that answer being valid.

{question}

对形式化数学任务，我们在 Lean v4.28.0-rc1⁸⁹ 上以 agentic 方式评测，模型可以访问 Lean 编译器和一个语义 tactic 搜索引擎（Figure 8 左侧的 Practical Regime 用的是开源的 LeanExplore⁹⁰ 而非闭源搜索工具），在最大 reasoning effort 下最多执行 500 次工具调用。此外，我们还评测了一条计算量更大的流水线：先生成候选的自然语言解并用 self-verification⁹¹ 过滤，保留下来的解再作为指引交给形式化 agent 去证明对应的 Lean 命题。这个设计用非形式化推理来改善探索，同时通过形式化验证保持严格的正确性。只有当严格的 verifier Comparator 在两种设定下都接受，一次提交才被计为正确。

我们把 K2.6 和 GLM-5.1 的一些条目留空了，因为它们的 API 太忙，没能返回我们查询的响应。

1M token 上下文。由于 DeepSeek-V4 系列支持 1M token 上下文，我们选择 OpenAI MRCR⁹² 和 CorpusQA⁹³ 作为 benchmark 来评测长上下文场景下的模型表现。我们在这些任务上重新评测了 Claude Opus 4.6 和 Gemini 3.1 Pro，目的是让所有模型的配置标准化。我们没有评测 GPT-5.4，因为它的 API 对我们相当大一部分查询没有响应。

Agent。Agent 数据集包括 Terminal Bench 2.0⁹⁴、SWE-Verified⁹⁵、SWE Multilingual⁹⁶、SWE-Pro⁹⁷、BrowseComp⁹⁸、MCPAtlas 的公开评测集⁹⁹、GDPval-AA¹⁰⁰¹⁰¹ 和 Tool-Decathlon¹⁰²。

对代码 agent 任务（SWE-Verified、Terminal-Bench、SWE-Pro、SWE Multilingual），我们用内部开发的评测框架来评测 DeepSeek-V4 系列。这个框架只提供一套最小工具集——一个 bash 工具和一个文件编辑工具。最大交互步数设为 500，最大上下文长度设为 512K token。关于 Terminal-Bench 2.0，我们承认 GLM-5.1 指出的环境相关问题。不过为了一致性，我们仍然报告在原始 Terminal-Bench 2.0 数据集上的成绩。在 Terminal-Bench 2.0 Verified 子集上，DeepSeek-V4-Pro 取得约 72.0 分。

对搜索 agent 任务（BrowseComp、带工具的 HLE），我们同样使用内部 harness，配备 websearch 和 Python 工具，最大交互步数设为 500，最大上下文长度设为 512K token。对 BrowseComp，我们采用与 DeepSeek-V3.2¹⁰ 相同的 discard-all 上下文管理策略。

5.3.2 评测结果

DeepSeek-V4-Pro-Max 与其他闭源/开源模型的对比见 Table 6。我们也评测了 DeepSeek-V4-Flash 和 DeepSeek-V4-Pro 的不同模式，结果见 Table 7。

Table 6：DeepSeek-V4-Pro-Max 与闭源/开源模型的对比。“Max”、“xHigh”、“High” 表示 reasoning effort。最佳结果加粗，次佳用斜体。

类别	Benchmark（指标）	Opus-4.6 Max	GPT-5.4 xHigh	Gemini-3.1-Pro High	K2.6 Thinking	GLM-5.1 Thinking	DS-V4-Pro Max
知识与推理	MMLU-Pro (EM)	89.1	87.5	91.0	87.1	86.0	87.5
	SimpleQA-Verified (Pass@1)	46.2	45.3	75.6	36.9	38.1	57.9
	Chinese-SimpleQA (Pass@1)	76.4	76.8	85.9	75.9	75.0	84.4
	GPQA Diamond (Pass@1)	91.3	93.0	94.3	90.5	86.2	90.1
	HLE (Pass@1)	40.0	39.8	44.4	36.4	34.7	37.7
	LiveCodeBench (Pass@1)	88.8	-	91.7	89.6	-	93.5
	Codeforces (Rating)	-	3168	3052	-	-	3206
	HMMT 2026 Feb (Pass@1)	96.2	97.7	94.7	92.7	89.4	95.2
	IMOAnswerBench (Pass@1)	75.3	91.4	81.0	86.0	83.8	89.8
	Apex (Pass@1)	34.5	54.1	60.9	24.0	11.5	38.3
	Apex Shortlist (Pass@1)	85.9	78.1	89.1	75.5	72.4	90.2
长上下文	MRCR 1M (MMR)	92.9	-	76.3	-	-	83.5
	CorpusQA 1M (ACC)	71.7	-	53.8	-	-	62.0
Agentic	Terminal Bench 2.0 (Acc)	65.4	75.1	68.5	66.7	63.5	67.9
	SWE Verified (Resolved)	80.8	-	80.6	80.2	-	80.6
	SWE Pro (Resolved)	57.3	57.7	54.2	58.6	58.4	55.4
	SWE Multilingual (Resolved)	77.5	-	-	76.7	73.3	76.2
	BrowseComp (Pass@1)	83.7	82.7	85.9	83.2	79.3	83.4
	HLE w/ tools (Pass@1)	53.1	52.0	51.6	54.0	50.4	48.2
	GDPval-AA (Elo)	1619	1674	1314	1482	1535	1554
	MCPAtlas Public (Pass@1)	73.8	67.2	69.2	66.6	71.8	73.6
	Toolathlon (Pass@1)	47.2	54.6	48.8	50.0	40.7	51.8

Table 7：DeepSeek-V4 系列不同规模与模式的对比。“Non-Think”、“High”、“Max” 表示 reasoning effort。

类别	Benchmark（指标）	Flash Non-Think	Flash High	Flash Max	Pro Non-Think	Pro High	Pro Max
知识与推理	MMLU-Pro (EM)	83.0	86.4	86.2	82.9	87.1	87.5
	SimpleQA-Verified (Pass@1)	23.1	28.9	34.1	45.0	46.2	57.9
	Chinese-SimpleQA (Pass@1)	71.5	73.2	78.9	75.8	77.7	84.4
	GPQA Diamond (Pass@1)	71.2	87.4	88.1	72.9	89.1	90.1
	HLE (Pass@1)	8.1	29.4	34.8	7.7	34.5	37.7
	LiveCodeBench (Pass@1-COT)	55.2	88.4	91.6	56.8	89.8	93.5
	Codeforces (Rating)	-	2816	3052	-	2919	3206
	HMMT 2026 Feb (Pass@1)	40.8	91.9	94.8	31.7	94.0	95.2
	IMOAnswerBench (Pass@1)	41.9	85.1	88.4	35.3	88.0	89.8
	Apex (Pass@1)	1.0	19.1	33.0	0.4	27.4	38.3
	Apex Shortlist (Pass@1)	9.3	72.1	85.7	9.2	85.5	90.2
长上下文	MRCR 1M (MMR)	37.5	76.9	78.7	44.7	83.3	83.5
	CorpusQA 1M (ACC)	15.5	59.3	60.5	35.6	56.5	62.0
Agentic	Terminal Bench 2.0 (Acc)	49.1	56.6	56.9	59.1	63.3	67.9
	SWE Verified (Resolved)	73.7	78.6	79.0	73.6	79.4	80.6
	SWE Pro (Resolved)	49.1	52.3	52.6	52.1	54.4	55.4
	SWE Multilingual (Resolved)	69.7	70.2	73.3	69.8	74.1	76.2
	BrowseComp (Pass@1)	-	53.5	73.2	-	80.4	83.4
	HLE w/ tools (Pass@1)	-	40.3	45.1	-	44.7	48.2
	MCPAtlas Public (Pass@1)	64.0	67.4	69.0	69.4	74.2	73.6
	GDPval-AA (Elo)	-	-	1395	-	-	1554
	Toolathlon (Pass@1)	40.7	43.5	47.8	46.3	49.0	51.8

知识。在通用世界知识的评测中，DeepSeek-V4-Pro-Max——DeepSeek-V4-Pro 的最大 reasoning effort 模式——在开源大语言模型中确立了新的 state-of-the-art。以 SimpleQA-Verified 为例，DeepSeek-V4-Pro-Max 以 20 个绝对百分点的幅度显著超过所有现有开源基线。尽管有这些进展，它目前仍落后于领先的闭源模型 Gemini-3.1-Pro。在教育类知识与推理领域，DeepSeek-V4-Pro-Max 在 MMLU-Pro、GPQA 和 HLE 上小幅优于 Kimi 和 GLM，但落后于领先的闭源模型。总体上，DeepSeek-V4-Pro-Max 标志着开源模型在世界知识能力提升上的一个重要里程碑。

此外，DeepSeek-V4-Flash 与 DeepSeek-V4-Pro 在知识类任务上存在显著性能差距；这是预期之内的，因为更大的参数量有利于预训练中保留更多知识。值得注意的是，两个模型在分配更高 reasoning effort 时，知识 benchmark 上的结果都有改善。

推理。DeepSeek-V4-Pro-Max 在推理 benchmark 上全面超过此前所有开源模型，并在许多指标上追平 state-of-the-art 闭源模型；更小的 DeepSeek-V4-Flash-Max 在代码和数学推理任务上也超过了此前最好的开源模型 K2.6-Thinking。同时，DeepSeek-V4-Pro 和 DeepSeek-V4-Flash 在编程竞赛上表现突出。按我们的评测，它们的表现与 GPT-5.4 相当，这是开源模型首次在这项任务上追平闭源模型。在 Codeforces 排行榜上，DeepSeek-V4-Pro-Max 目前在人类选手中排第 23 位。DeepSeek-V4 在形式化数学任务上，无论 agentic 设定还是算力密集设定，都表现强劲。在 agentic 设定下它取得 state-of-the-art 结果（见 Figure 8），超过了 Seed Prover¹⁰³ 等此前的模型。用算力更密集的流水线，性能进一步提升，超过了包括 Aristotle¹⁰⁴ 在内的系统，并追平该设定下已知的最好结果。

Agent。DeepSeek-V4 系列在评测中展现出强劲的 agent 表现。在代码 agent 任务上，DeepSeek-V4-Pro 取得与 K2.6 和 GLM-5.1 相当的结果，不过这些开源模型仍都落后于它们的闭源对手。DeepSeek-V4-Flash 在代码任务上不及 DeepSeek-V4-Pro，在 Terminal Bench 2.0 上尤其明显。其他 agent 评测也观察到类似趋势。值得一提的是，DeepSeek-V4-Pro 在 MCPAtlas 和 Toolathlon——这两个包含大量工具与 MCP 服务的评测集——上表现良好，说明我们的模型有出色的泛化能力，而不是只在内部框架上表现好。

1M token 上下文。在衡量上下文内检索能力的 MRCR 任务上，DeepSeek-V4-Pro 超过 Gemini-3.1-Pro，但仍落后于 Claude Opus 4.6。如 Figure 9 所示，检索性能在 128K 上下文窗口内保持高度稳定。虽然超过 128K 之后可以看到性能衰减，但模型在 1M token 处的检索能力相比闭源和开源同行都依然相当强。与 MRCR 不同，CorpusQA 更接近真实场景，其评测结果同样表明 DeepSeek-V4-Pro 优于 Gemini-3.1-Pro。

Reasoning effort。如 Table 7 所示，在 RL 中使用更长上下文和更弱长度惩罚的 Max 模式，在最有挑战的任务上优于 High 模式。Figure 10 给出 DeepSeek-V4-Pro、DeepSeek-V4-Flash 与 DeepSeek-V3.2 在代表性推理和 agentic 任务上性能与成本的对比。通过扩展 test-time 算力，DeepSeek-V4 系列相比前代取得了实质性提升。此外，在 HLE 这类推理任务上，DeepSeek-V4-Pro 展现出比 DeepSeek-V3.2 更高的 token 效率。

5.4 真实任务上的表现

标准化 benchmark 往往难以捕捉多样的真实任务的复杂性，这在测试结果与实际用户体验之间造成了落差。为了弥合这个落差，我们开发了内部专有指标，优先关注真实使用模式而非传统 benchmark。这个做法确保我们的优化能转化为实际收益。我们的评测框架专门针对 DeepSeek API 和 Chatbot 的主要使用场景，让模型性能与实际需求对齐。

5.4.1 中文写作

DeepSeek 的主要使用场景之一是中文写作。我们在功能性写作和创意写作上做了严格评测。原文 Table 12（附录 B）给出 DeepSeek-V4-Pro 与 Gemini-3.1-Pro 在功能性写作任务上的成对比较。这些任务由常见的日常写作 query 构成，prompt 通常简洁直白。我们选择 Gemini-3.1-Pro 作为基线，因为在我们的评测中它是中文写作上表现最好的外部模型。结果表明 DeepSeek-V4-Pro 以 62.7% 对 34.1% 的总体胜率超过基线；这主要是因为在中文写作场景下，Gemini 偶尔会让自己内在的文风偏好压过用户明确提出的要求。

原文 Table 13 给出创意写作的对比，从两个维度评测：指令遵循和写作质量。相比 Gemini-3.1-Pro，DeepSeek-V4-Pro 在指令遵循上取得 60.0% 的胜率、在写作质量上取得 77.5%，前者是小幅改善，后者是大幅领先。尽管在总体用户 case 分析上 DeepSeek-V4-Pro 结果更优，但若把评测限制在最有挑战的 prompt 上——具体是那些涉及高复杂度约束或多轮场景的——就会发现 Claude Opus 4.5 相对 DeepSeek-V4-Pro 仍保有优势。如原文 Table 14 所示，Claude Opus 4.5 取得 52.0% 的胜率，对方为 45.9%。

5.4.2 搜索

搜索增强问答是 DeepSeek chatbot 的一项核心能力。在 DeepSeek 网页版和 App 上，“non-think” 模式采用检索增强搜索（RAG），而 “thinking” 模式采用 agentic search。

检索增强搜索。我们做了 DeepSeek-V4-Pro 与 DeepSeek-V3.2 在客观和主观两类问答上的成对评测。如原文 Table 11 所示，DeepSeek-V4-Pro 大幅超过 DeepSeek-V3.2，在两个类别上都表现出一致的优势。增益最明显的是单值搜索和攻略计划类任务，说明 DeepSeek-V4-Pro 擅长定位精确的事实性答案、以及从检索到的上下文中综合出结构化的方案。不过 DeepSeek-V3.2 在对比和推荐类任务上仍相对有竞争力，说明 DeepSeek-V4-Pro 在需要对搜索结果做平衡的、多视角推理的场景下还有提升空间。

Agentic search。与标准 RAG 不同，agentic search 让模型可以对每个 query 迭代式地调用搜索和抓取工具，显著提升整体搜索性能。对 DeepSeek-Chat 的 thinking 模式，我们优化了 agentic search 功能，以在预设的"thinking budget"内最大化回答准确率。如原文 Table 9 所示，agentic search 一致地优于 RAG，在复杂任务上尤为明显。此外它的成本仍然很高效，agentic search 只比标准 RAG 略贵一点（见原文 Table 10）。

5.4.3 白领任务

为了严格评估模型在复杂企业生产力场景下的效用，我们构建了一套包含 30 个高阶中文专业任务的综合测试集。这些工作流刻意涵盖高层次的认知需求，包括深度信息分析、综合性文档生成和细致的文档编辑，横跨 13 个关键行业（比如金融、教育、法律和科技）的多样谱系。评测在一个配备 Bash 和网页搜索等基础工具的内部 agent harness 中进行。

考虑到这些任务的开放性，自动化指标通常无法捕捉高质量回复的细微之处。因此我们做了人工评测，把 DeepSeek-V4-Pro-Max 与 Opus-4.6-Max 对比。标注者在盲测条件下从四个维度评估模型输出：

• 任务完成度（Task Completion）：核心问题是否被成功解决。
• 指令遵循（Instruction Following）：对具体约束和指示的遵守程度。
• 内容质量（Content Quality）：事实准确性、逻辑连贯性和专业语气。
• 格式美观（Formatting Aesthetics）：排版可读性和视觉呈现。

如 Figure 11 所示，DeepSeek-V4-Pro-Max 在多样的中文白领任务上超过 Opus-4.6-Max，取得令人印象深刻的 63% 非负率（non-loss rate），并在分析、生成和编辑任务上都表现出一致的优势。Figure 12 展示的细分维度得分突出了模型在任务完成度和内容质量上的主要长处。具体来说，DeepSeek-V4-Pro-Max 会主动预判用户的隐含意图，经常提供补充性洞察和自我验证步骤。它在长文生成上也很出色，能给出有深度、连贯的叙述，而不是像 Opus-4.6-Max 那样频繁依赖过度简化的 bullet point。此外，模型严格遵循正式的专业规范，比如标准的中文层级编号。不过在指令遵循方面，它偶尔会忽略特定的格式约束，略逊于 Opus。模型在把大量文本输入压缩成简洁摘要方面也不够熟练。最后，在演示幻灯片的整体视觉设计上，它的格式美观度仍有很大提升空间。Figure 13、14、15 给出若干测试案例；由于某些输出篇幅很长，只展示了部分页面。

5.4.4 代码 Agent

为了给我们的编程 agent 能力做基准测试，我们从真实的内部研发负载中整理任务。我们从 50 多位内部工程师那里收集了约 200 个有挑战的任务，覆盖特性开发、bug 修复、重构和诊断，跨越 PyTorch、CUDA、Rust、C++ 等多样技术栈。每个任务都配有原始仓库、对应的执行环境和人工标注的打分 rubric；经过严格的质量筛选，保留 30 个任务作为评测集。如 Table 8 所示，DeepSeek-V4-Pro 显著超过 Claude Sonnet 4.5，接近 Claude Opus 4.5 的水平。

Table 8：研发编程 benchmark 上的对比（外部模型仅用于评测目的）。

模型	Haiku 4.5	Sonnet 4.5	DeepSeek-V4-Pro-Max	Opus 4.5	Opus 4.5 Thinking	Opus 4.6 Thinking
Pass Rate (%)	13	47	67	70	73	80

在一项针对 DeepSeek 开发者和研究员（$N=85$，全部都有在日常工作中用 DeepSeek-V4-Pro 做 agentic coding 的经验）的调查中，我们问他们：相比其他前沿模型，DeepSeek-V4-Pro 是否已经可以作为他们默认的主力编程模型？52% 说是，39% 倾向于是，不到 9% 说否。受访者认为 DeepSeek-V4-Pro 在大多数任务上给出令人满意的结果，但也指出它会犯些琐碎错误、误解模糊的 prompt，偶尔会过度思考。

6 结论、局限与未来方向

在本工作中，我们发布 DeepSeek-V4 系列的预览版，目标是打破超长上下文处理效率壁垒的下一代大语言模型。通过组合一个整合 CSA 与 HCA 的混合注意力架构，DeepSeek-V4 系列在长序列效率上实现了戏剧性的跃升。这些架构创新加上大量的基础设施优化，使百万 token 上下文的高效原生支持成为可能，也为未来的 test-time scaling、长程任务，以及 online learning 这类新兴范式打下了必要的基础。评测结果表明，DeepSeek-V4-Pro-Max——DeepSeek-V4-Pro 的最大 reasoning effort 模式——重新定义了开源模型的 state-of-the-art。它在知识 benchmark 上大幅超过此前的开源模型，取得接近前沿闭源模型的优越推理性能，并交付有竞争力的 agent 能力。同时，DeepSeek-V4-Flash-Max 在保持高性价比架构的前提下，达到了与领先闭源模型相当的推理性能。我们相信 DeepSeek-V4 系列为开源模型开启了百万长度上下文的新时代，也为更好的效率、规模与智能铺平了道路。

在追求极致长上下文效率的过程中，DeepSeek-V4 系列采用了一个大胆的架构设计。为了把风险降到最低，我们保留了许多经过初步验证的组件和技巧，它们虽然有效，却让架构变得相对复杂。在未来的迭代中，我们会做更全面、更有原则的研究，把架构提炼到最本质的设计，让它在不牺牲性能的前提下更优雅。同时，尽管 Anticipatory Routing 和 SwiGLU Clamping 已被证明能有效缓解训练不稳定，它们背后的原理仍然理解得不够充分。我们会积极研究训练稳定性的基础问题、加强内部指标监控，力求以更有原则、更有预测力的方式实现稳定的大规模训练。此外，在 MoE 和稀疏注意力架构之外，我们也会主动探索沿新维度的模型稀疏性——比如更稀疏的 embedding 模块¹⁰⁵——以在不损害能力的前提下进一步提升计算与显存效率。我们还会持续研究低延迟架构与系统技术，让长上下文的部署与交互更有响应感。更进一步，我们认识到长程、多轮 agentic 任务的重要性与实用价值，会在这个方向上继续迭代与探索。我们也在着手把多模态能力纳入我们的模型。最后，我们致力于开发更好的数据整理与合成策略，在越来越广泛的场景与任务上持续增强模型的智能、鲁棒性和实用性。