DeepSeek-V3.2 - 开源模型王者归来：推理、效率与Agent能力的三重突破

开源与闭源的差距正在被重新定义

2025年12月1日，DeepSeek发布了正式版V3.2及其高性能变体V3.2-Speciale。这不是一次简单的版本迭代，而是一次开源领域的重量级更新：开源大模型可以在推理能力、计算效率和Agent性能三个维度同时逼近甚至超越顶尖闭源模型。

技术报告开篇就直面了一个尖锐的问题：尽管开源社区持续进步，但闭源模型（GPT-5、Gemini-3.0-Pro）的性能轨迹正在以更陡峭的速度攀升，两者之间的差距不是在缩小，而是在扩大。

DeepSeek的分析指出了开源模型落后的三个关键原因：架构层面过度依赖vanilla attention导致长序列效率低下；后训练阶段的计算投入严重不足；以及在Agent场景下的泛化和指令跟随能力明显落后于闭源竞品。

V3.2的设计目标就是系统性地解决这三个问题，最终实现的效果也让人振奋：V3.2在多项推理基准上达到GPT-5水平；V3.2-Speciale在国际数学奥林匹克（IMO）、国际信息学奥林匹克（IOI）、ICPC世界总决赛等顶级赛事中斩获金牌；在Agent任务上大幅缩小了与闭源模型的差距。

本文以DeepSeek-V3.2技术报告为参考，从架构创新、强化学习优化、Agent能力构建、性能评测四个维度，深入解析这次技术突破背后的相关技术细节。

DeepSeek Sparse Attention：长上下文效率的架构级解决方案

问题的本质：为什么传统注意力机制在长序列上效率低下

标准的Transformer注意力机制具有的计算复杂度，其中是序列长度。当上下文窗口扩展到128K tokens时，这种二次方复杂度会导致计算成本急剧攀升。更糟糕的是，这种低效不仅影响推理部署，还严重制约了后训练阶段的计算扩展——你很难在超长序列上进行大规模强化学习。

一个直观的想法是：既然不是所有token都同等重要，能否只对"重要"的token计算注意力？但问题在于，判断哪些token重要本身就需要进行某种形式的全局计算。如果直接在主注意力的score上做top-k筛选，的计算量已经完全花出去了，稀疏化带来的收益被前置计算抵消。

DSA的核心设计：两级注意力架构

DeepSeek Sparse Attention（DSA）的解决思路是构建一个"两级注意力架构"：用一个极其轻量的网络来判断"哪些token值得关注"，然后只在被选中的少量token上执行昂贵的主注意力计算。

第一级是Lightning Indexer（闪电索引器）。对于每个query token 和历史token ，索引器计算一个相关性分数：

这个公式看起来和标准注意力有些相似，但关键区别在于：索引器使用极少的head数量、紧凑的向量维度，并且可以用FP8低精度实现。虽然索引器仍然是复杂度，但由于参数量和精度都大幅降低，实际算力开销远小于主注意力层。

激活函数选择ReLU而非Softmax或GELU，是工程为导向的决策：ReLU计算简单、易于并行化、对FP8量化友好，这些特性在追求极致吞吐量的场景下就特别重要，这也是DeepSeek注重在技术细节上进行工程优化的体现。

第二级是Fine-grained Token Selection（细粒度token选择）。根据索引器输出的分数，系统为每个query选出Top-2048个最相关的位置，然后只在这些位置上执行标准的MLA注意力计算：

这将核心计算复杂度从降低到，其中远小于。

与MLA的协同设计

V3.2基于DeepSeek系列的MLA（Multi-head Latent Attention）架构实现DSA。MLA本身就通过将Key/Value压缩到潜在向量空间来减少KV存储开销，而DSA则进一步减少了需要参与计算的KV数量。

一个关键的设计决策是DSA直接基于MLA的MQA模式实现。技术报告明确解释了原因，在kernel级别，为了实现计算效率的最大化，每个KV entry必须能被多个query重复利用。MQA的结构天然符合这种硬件友好的访存模式。

两阶段继续预训练

V3.2并非从零开始训练，而是在V3.1-Terminus的128K上下文checkpoint基础上继续训练。这种做法的挑战在于：如何让已经适应密集注意力的模型平滑过渡到稀疏模式？

Dense Warm-up阶段：冻结主模型参数，只训练索引器。对于每个query token，计算原始多头注意力在所有历史token上的score分布，然后用KL散度让索引器的输出逼近这个分布：

这个阶段用学习率训练1000步，总计约2.1B tokens。本质上是让索引器先学会"像旧模型那样看世界"。

Sparse Training阶段：引入top-k选择机制，解冻主模型参数，让主模型和索引器同时更新。关键的设计是梯度解耦：索引器的输入从计算图中detach，主模型只根据语言建模损失反向传播，索引器只根据KL损失更新。这避免了"索引器改了导致主模型改变，主模型改变又导致索引器需要重新适应"的恶性循环。

这个阶段用学习率训练15000步，总计约943.7B tokens，接近一次完整的大模型预训练规模。

效率验证：成本曲线的实质性改变

在H800集群的实测中，V3.2相比V3.1-Terminus在长上下文场景下实现了显著的成本降低。Terminus的每百万token成本几乎与序列位置线性相关，越靠后的token越贵；而V3.2的成本增长曲线要平缓得多，尤其是在序列后半段。

值得一提的是，对于短上下文场景，DeepSeek专门实现了一个"用masked MHA来模拟DSA"的模式，在短序列下反而更高效。这意味着生产环境中可以根据输入长度动态选择最优实现路径。

可扩展的强化学习框架：让RL真正吃上算力

一个关键数字：RL计算预算超过预训练成本的10%

技术报告披露了一个RL 主导的LRM范式对LLM成本影响的数字：V3.2的后训练计算预算已经超过预训练成本的10%。这个比例也从侧面验证了RL scaling的有效性。

随着RL训练预算的增加，推理能力持续提升。DeepSeek技术报告推测如果继续投入更多计算资源，性能还能进一步增强。这种"计算换能力"的模型提升路径，可能就是闭源模型一直处于领先但开源模型受限计算能力的一个重要因素，但开源模型通过充分利用已有资源来实现更高效计算能力置换(kimi k2也是这个思路)。

GRPO算法优化：让大规模RL训练稳定运行

要让RL真正吃上这么多算力，首先需要解决训练稳定性问题。V3.2在GRPO（Group Relative Policy Optimization）算法基础上进行了多项关键优化。

无偏KL估计。原始的K3 KL估计器存在系统性偏差，当采样token在当前策略下概率远低于参考策略时（），梯度会给这些token分配过大的权重，导致噪声梯度累积，最终破坏训练稳定性。V3.2通过重要性采样比修正了这个问题，使梯度估计变得无偏。

实践中发现，不同领域对KL正则化的需求强度不同。对于数学等特定领域，使用较弱的KL惩罚甚至完全省略可以获得更好的性能。

Off-Policy序列掩码。为了提高RL系统效率，通常会生成大批量rollout数据，然后分成多个mini-batch进行梯度更新。这种做法本质上引入了off-policy行为。此外，推理框架和训练框架在实现细节上的差异会进一步加剧off-policy程度。

V3.2引入了一个二元掩码机制：当负优势样本的KL散度超过阈值时，将其从损失计算中排除。直觉上，模型从自己的错误中学习收益最大，但高度off-policy的负样本可能产生误导，反而损害优化过程。

Keep Routing。MoE模型通过只激活部分专家来提高效率，但推理和训练框架的差异，加上策略更新，可能导致相同输入在推理和训练时激活不同的专家路由。这种不一致会导致活跃参数子空间的突然变化，破坏优化稳定性。

V3.2的解决方案是：保存推理时使用的专家路由路径，并在训练时强制使用相同的路由。这个"Keep Routing"操作从V3-0324开始就被采用，被证明对MoE模型的RL训练稳定性至关重要。

Keep Sampling Mask。Top-p和top-k采样通过截断低概率token来提高生成质量，但这种截断会导致旧策略和当前策略的动作空间不匹配，违反重要性采样的原则。V3.2保存采样时的截断掩码，并在训练时将其应用到当前策略，确保两者共享相同的动作子空间。实验表明，这种方法能有效保持RL训练过程中的语言一致性。

专家蒸馏与混合RL训练

专家蒸馏是V3.2后训练流程的第一步。从同一个预训练checkpoint出发，针对六个专门领域分别训练specialist模型：数学、编程、通用逻辑推理、通用Agent任务、Agentic coding、Agentic search。每个领域同时支持thinking mode（长链式推理）和non-thinking mode（直接响应）。

每个specialist都投入大规模RL算力训练，目标是在各自领域"卷到极致"。训练完成后，这些专家模型用于生成高质量的领域特定数据，再用于训练最终的通用模型。实验表明，用蒸馏数据训练出的模型性能只比原始专家略差，经过后续RL后差距基本抹平。

混合RL训练将推理、Agent和人类对齐三个目标合并到单一RL阶段同时优化。这避免了多阶段RL常见的灾难性遗忘问题——后面的训练阶段"洗掉"前面学到的能力。对于推理和Agent任务，使用基于规则的结果奖励、长度惩罚和语言一致性奖励；对于通用任务，使用生成式奖励模型，每个prompt对应自己的评分rubric。

大规模Agent任务合成：合成数据的agent泛化潜力

开源模型在Agent场景的短板

技术报告直接指出：在Agent场景下，开源模型在泛化能力和指令跟随能力上明显落后于闭源竞品。这种差距阻碍了开源模型在真实部署场景的应用。

要解决这个问题，关键是获取大规模、高质量、多样化的Agent训练数据。但真实的Agent交互数据难以大规模获取，而且往往局限于特定场景。V3.2的解决方案是：系统性地合成Agent训练任务。

思考上下文管理：让推理能力服务于工具调用

DeepSeek-R1已经证明，引入thinking过程可以显著增强模型解决复杂问题的能力。V3.2希望将这种能力整合到工具调用场景中。

一个直接的挑战是token效率。如果像R1那样在收到第二轮消息时丢弃所有推理内容，模型会被迫为每次工具调用重新推理整个问题，造成巨大的token浪费。

V3.2设计了专门针对工具调用场景的上下文管理策略：只有当新的用户消息加入对话时才丢弃历史推理内容；如果只是添加工具相关消息（如工具输出），推理内容会在整个交互过程中保留；当推理轨迹被移除时，工具调用历史和结果仍然保留在上下文中。

需要注意的是，某些Agent框架（如Roo Code、Terminus）通过用户消息模拟工具交互，这类框架可能无法充分利用上述推理持久化机制。对于这些架构，建议使用non-thinking模式。

冷启动：用提示工程统一推理与工具调用

在拥有推理数据（非Agent）和非推理Agent数据的情况下，一个简单的整合策略是通过精心设计的提示来引导模型。V3.2假设模型具有足够的指令跟随能力，可以通过显式指令将工具执行无缝整合到推理过程中。

具体做法是设计三类系统提示：纯推理提示（要求模型在<think></think>标签中输出推理过程）、Agent提示（包含工具调用指南）、以及融合提示（指导模型在推理过程中执行多次工具调用）。

虽然这种"推理中使用工具"的模式一开始可能不太稳健，但模型偶尔能生成期望的轨迹，这为后续的强化学习阶段提供了基础。

大规模Agent任务合成流水线

V3.2使用的Agent任务来源于四类场景：

搜索Agent数据采用基于V3.2的多Agent流水线生成。首先从大规模网络语料中采样长尾实体，然后用问题构建Agent使用搜索工具探索每个实体，将发现的信息整合成问答对。多个配置不同的答案生成Agent为每个问答对生成候选响应，验证Agent通过多轮搜索验证所有答案，只保留ground-truth正确且所有候选都可验证错误的样本。

代码Agent数据通过挖掘GitHub上的Issue-PR对构建大规模可执行环境。自动化环境设置Agent处理包安装、依赖解析和测试执行，只有当应用gold patch后测试从失败变成功且没有引入回归时，环境才被认为构建成功。最终成功构建了数万个跨越Python、Java、JavaScript、TypeScript、C、C++、Go、PHP等多种语言的可复现Issue解决环境。

通用Agent数据是最具创新性的部分。V3.2开发了一个自动化环境合成Agent，合成了1,827个面向任务的环境。合成工作流包括：

1. 给定任务类别和配备bash/搜索工具的沙箱，Agent首先生成或检索相关数据并存储到沙箱数据库
2. Agent合成一组任务特定工具，每个工具实现为一个函数
3. Agent提出一个简单任务及其解决方案和验证函数，然后迭代增加任务难度并更新相应的解决方案和验证函数

技术报告给出了一个旅行规划的合成任务示例，展示了这类任务的特点：搜索满足所有约束的方案很困难，但验证给定方案是否满足约束相对简单。

合成任务的有效性验证

一个自然的问题是：合成任务是否足够有挑战性？随机抽取50个通用合成任务进行评测，V3.2-Exp只达到12%准确率，即使是顶尖闭源模型GPT-5-Thinking也只有62%。这表明合成数据确实包含了对当前最强模型都有挑战性的任务。

更重要的问题是：在合成数据上的RL是否能泛化到不同任务或真实环境？实验表明，在合成数据上进行大规模RL后，模型在Tau2Bench、MCP-Mark、MCP-Universe等基准上相比SFT checkpoint有显著提升；而如果只在代码和搜索场景上进行RL，这些基准上的性能并没有提升。这验证了合成数据的泛化潜力。

性能评测：开源模型的新高度

推理能力：达到GPT-5水平

在多项推理基准上，V3.2达到了与GPT-5-High相当的性能：

• AIME 2025：93.1%（GPT-5: 94.6%，Gemini-3.0-Pro: 95.0%）
• HMMT Feb 2025：92.5%（GPT-5: 88.3%，Gemini-3.0-Pro: 97.5%）
• LiveCodeBench：83.3%（GPT-5: 84.5%，Gemini-3.0-Pro: 90.7%）
• Codeforces Rating：2386（GPT-5: 2537，Gemini-3.0-Pro: 2708）

与Kimi-K2-Thinking相比，V3.2在输出token数显著更少的情况下达到了相当的分数。例如AIME 2025，K2-Thinking使用24k tokens达到94.5%，V3.2用16k tokens达到93.1%。

技术报告指出，V3.2的性能受到长度约束奖励模型的限制，这是为了在性能和成本之间取得平衡。移除这个限制后，性能还能进一步提升。

V3.2-Speciale：挑战推理能力的极限

V3.2-Speciale是放宽长度约束后训练的实验性变体，同时整合了DeepSeekMath-V2的定理证明能力。它的目标是将开源模型的推理能力推向极致。

V3.2-Speciale在AIME和HMMT上超越了Gemini-3.0-Pro，达到了开源模型的新高度。

更具说服力的是竞赛实战成绩：

然而，V3.2-Speciale的token效率仍然显著低于Gemini-3.0-Pro。为了降低部署成本和延迟，官方V3.2在训练时施加了更严格的token约束。提升推理链的"智能密度"仍然是未来工作的重要方向。

Agent能力：大幅缩小与闭源模型的差距

在Agent评测上，V3.2展现出开源模型的新水平：

代码Agent：

• SWE Verified: 73.1%（GPT-5: 74.9%，Gemini-3.0-Pro: 76.2%）
• SWE Multilingual: 70.2%（GPT-5: 55.3%，显著超越）
• Terminal Bench 2.0: 46.4%（Gemini-3.0-Pro: 54.2%）

搜索Agent：

• BrowseComp: 51.4%（使用上下文管理后67.6%）
• BrowseCompZh: 65.0%（GPT-5: 63.0%，超越）

工具使用：

• τ²-bench: 80.3%（GPT-5: 80.2%，持平）
• MCP-Universe: 45.9%（GPT-5: 47.9%，接近）
• Tool-Decathlon: 35.2%（GPT-5: 29.0%，超越）

值得注意的是，MCP基准使用的环境和工具集在RL训练中从未见过，这证明了V3.2将推理策略泛化到分布外Agent场景的能力。

测试时计算扩展：上下文管理策略

即使有128K的上下文窗口，Agent工作流（特别是搜索场景）也经常触及最大长度限制。V3.2引入了上下文管理策略来扩展测试时计算：

• Summary：总结溢出的轨迹并重新开始
• Discard-75%：丢弃前75%的工具调用历史
• Discard-all：重置上下文，丢弃所有之前的工具调用历史

在BrowseComp基准上，Summary策略将平均步数从140扩展到364，分数从53.4提升到60.2。Discard-all策略在效率和可扩展性上表现最好，达到67.6分，与并行扩展相当但使用的步数显著更少。

技术报告指出，测试时计算可以通过上下文管理串行扩展，也可以通过并行采样扩展，两者都能有效延伸模型的问题解决能力。如何找到串行和并行扩展的最优组合，仍然是未来工作的关键方向。

局限性与未来方向

尽管取得了显著进展，技术报告坦诚承认了V3.2相比Gemini-3.0-Pro等顶尖闭源模型仍存在的差距：

世界知识的广度。由于总训练FLOPs较少，V3.2的世界知识覆盖仍然落后于领先的闭源模型。未来计划通过扩大预训练计算来弥补这个差距。

Token效率。V3.2通常需要更长的生成轨迹才能匹配Gemini-3.0-Pro的输出质量。未来工作将聚焦于优化推理链的"智能密度"。

复杂任务能力。在解决复杂任务方面仍然落后于顶尖模型，这推动团队继续改进基础模型和后训练配方。

结语

V3.2代表了开源大模型的一次系统性能力提升。它的核心贡献可以概括为三个层面：

架构层面，DSA通过两级注意力结构将长上下文的计算复杂度从降至，在几乎不损失性能的前提下大幅提升效率。这为大规模后训练和长上下文部署扫清了架构障碍。

训练层面，可扩展的GRPO框架通过无偏KL估计、Off-Policy序列掩码、Keep Routing等技术，让RL训练能够稳定地吃上超过预训练10%的计算预算。这是开源社区在后训练投入上的重要突破。

Agent能力层面，大规模Agent任务合成流水线系统性地解决了开源模型在泛化和指令跟随上的短板。1800+合成环境和85000+复杂指令的训练数据，让V3.2在工具使用场景大幅缩小了与闭源模型的差距。

V3.2-Speciale在IMO、IOI等顶级竞赛中斩获金牌，证明了开源模型在推理能力上已经可以与最强的闭源系统一较高下。

如果说有什么更深层的启示，那就是：开源与闭源的差距不是命中注定的，而是计算投入、架构创新和数据工程共同作用的结果。 当开源社区在后训练上持续坚持投入，扎实做好理论研究和工程化，如Deepseek投入10%+的预训练计算，构建大规模的Agent训练数据流水线，并且从工程效率层面实施上下文管理等策略，是可以让我们再次看到，开源与闭源的差距是有希望被追平的。

Deepseek V3.2的发布，再次拉响开源模型攀登AGI之路的号角，开源模型不会错过，也不能错过智能平权的伟大时代。

参考资料

• DeepSeek-V3.2 Technical Report
• DeepSeek-V3.2 Hugging Face
• DeepSeek-V3.2-Speciale Hugging Face
• DeepSeek-V3.2-Exp GitHub
• DeepSeek API Documentation