本文对《DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models》技术报告进行了详尽解读。文章指出，DeepSeek-V3.2 在推理能力上已追平 GPT-5-High，其高算力版本 Speciale 在数学和编程领域接近 Gemini-3.0-Pro。实现这些突破的关键在于三项核心技术：首先，**DeepSeek 稀疏注意力（DSA）**将长上下文计算复杂度从 O(L²)降至 O(Lk)，显著提升了**长上下文处理能力和**效率而不牺牲性能；其次，**大规模后训练加码**，其计算预算超过预训练的 10%，通过专家蒸馏和 GRPO 混合 RL 训练，有效避免了多阶段训练的灾难性遗忘，并**大幅提升了模型在难任务上的表现**；最后，**大规模智能体数据合成**，通过生成 1，800 个环境和 85，000 个“难解易验”任务，极大地提升了模型在智能体场景下的泛化能力。文章还详细阐述了 V3.2 在**Thinking in Tool-Use**方面的优化，即在工具返回结果时不丢弃推理内容，提高了工具调用效率。最后，报告坦诚地指出了 DeepSeek-V3.2 在世界知识、Token 效率和最难任务上的局限性。
这是一篇报告解读，原文是《DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models》
先说结论
DeepSeek-V3.2
在推理能力上追平 GPT-5-High，在部分指标上超越
DeepSeek-V3.2-Speciale（高算力版）
在 2025 年 IMO 和 IOI 拿了金牌，推理能力接近 Gemini-3.0-Pro
怎么做到的？三件事
DSA（DeepSeek Sparse Attention）
一种稀疏注意力机制，大幅降低长上下文的计算成本
后训练加码
把后训练的计算预算提到预训练的 10% 以上
大规模合成数据
生成了 1,800 个环境、85,000 个任务，全是合成的
下面一个一个说
DSA：把注意力从 O(L²) 降到 O(Lk)
传统的 Transformer 注意力机制是 O(L²) 复杂度，L 指的是序列长度
简单说一下
计算机领域，通常用 O(x) 来说明复杂度：比如 O(L) 的含义是随着 L 增加，则复杂度线性增加；而 O(L²) 的意思是按长度的平方倍增加。
文本长度翻 2 倍，计算量翻 4 倍；长度翻 10 倍，计算量翻 100 倍
这长上下文场景中，这个复杂度就成了大问题，推理慢，后训练也很难做
所以你很少会见到超过 128k 的上下文（ GPT-3.5 最早默认 4k 上下文）
DeepSeek 的解决方案是 DSA，核心思路是：
并非每个 token 都看全部上下文，只看最相关的 k 个 token
这样计算量就变成 O(Lk)，k 是个固定值（2048），不再随文本长度爆炸式增长
具体实现分两步：
第一步：Lightning Indexer
一个轻量级的打分器，给每个历史 token 打分，决定哪些值得关注
这个打分器用 ReLU 激活函数，可以跑在 FP8 精度，算力开销很小
第二步：Fine-grained Token Selection
根据 Lightning Indexer 的打分，只选 top-k 个 token 做真正的注意力计算
在 DeepSeek-V3.2 里，k = 2048
虽然 Lightning Indexer 本身还是 O(L²)，但它比主注意力轻很多，整体效率大幅提升
DSA 训练的两个阶段
阶段一：Dense Warm-up
先冻住主模型，只训练 Lightning Indexer
训练目标是让 Indexer 的输出分布对齐主注意力的分布
用 KL 散度做 loss
只训练了 1000 步，共 2.1B tokens
阶段二：Sparse Training
放开所有参数，让模型适应稀疏注意力模式
继续用 KL 散度对齐 Indexer 和主注意力
训练了 15000 步，共 943.7B tokens
效果怎么样？
在 128K 长度的 prefilling 阶段，V3.2 的成本基本不随位置增长，V3.1-Terminus 是线性增长
并且：性能没降
在 ChatbotArena 的 Elo 评分上，V3.2-Exp 和 V3.1-Terminus 基本持平
在独立的长上下文评测（AA-LCR、Fiction.liveBench）上，V3.2-Exp 甚至更好
后训练加码：预算超过预训练的 10%
过去，开源模型的后训练投入普遍不足，这限制了它们在难任务上的表现
DeepSeek 的做法是：大力出奇迹
具体数字是：后训练的计算预算超过预训练成本的 10%
这是很激进的配置
后训练流程分两步
第一步：专家蒸馏（Specialist Distillation）
为每个任务领域训练一个专门的「专家模型」
六个领域：数学、编程、通用逻辑推理、通用智能体、代码智能体、搜索智能体
每个领域都支持 thinking 和 non-thinking 两种模式
每个专家都用大规模 RL 训练
训练好之后，用专家模型生成领域数据，给最终模型用
第二步：混合 RL 训练（Mixed RL Training）
把推理、智能体、人类对齐三类任务合并成一个 RL 阶段
用 GRPO（Group Relative Policy Optimization）算法
这样做的好处是：避免多阶段训练的灾难性遗忘
GRPO 的几个关键改进
论文详细说了四个稳定化技巧：
1. Unbiased KL Estimate
原来的 K3 estimator 在某些情况下会给低概率 token 分配过大的梯度权重，导致训练不稳定
DeepSeek 用重要性采样修正了这个问题
Off-Policy Sequence Masking
把偏离当前策略太远的负样本 mask 掉
直觉是：从自己的错误里学比从不相关的错误里学更有效
Keep Routing
MoE 模型的专家路由在推理和训练时可能不一致
DeepSeek 保存推理时的路由路径，训练时强制复用
Keep Sampling Mask
Top-p 采样时的截断 mask 也保存下来，训练时复用
保证采样策略和训练策略一致
大规模智能体数据合成
泛化能力，是大模型在智能体场景的另一个短板
原因很简单：没有足够多样的训练环境
DeepSeek 的解决方案是：自己合成
具体数据
代码智能体24,667个任务（真实环境，提取的提示）
搜索智能体50,275个任务（真实环境，合成的提示）
通用智能体4,417 个任务（合成环境，合成提示）
代码解释器5,908个任务（真实环境，提取的提示）
合成流程，很有意思
-
1. 给定一个任务类型（比如旅行规划），agent 先用 bash 和搜索工具从网上拉数据，存到沙箱数据库
-
2. Agent 合成一套任务相关的工具函数
-
3. Agent 先提出一个简单任务，写好解决方案和验证函数
-
4. 迭代增加任务难度，同时更新解决方案和验证函数
-
5. 如果现有工具不够用，agent 会自动扩展工具集
最终得到了 1,827 个环境，4,417 个任务
有个 Trip Planning 的例子
从杭州出发的三天旅行，要求不重复城市/酒店/餐厅/景点，第二天的预算有复杂的条件约束...
任务很难解，但验证很简单——只要检查所有约束是否满足
这类「难解易验」的任务特别适合 RL
合成数据真的有用吗？
论文做了消融实验
用 V3.2-SFT 只在合成的通用智能体数据上做 RL，测试在 Tau2Bench、MCP-Mark、MCP-Universe 上的效果
结果是：显著提升
作为对照，只在代码和搜索环境上做 RL，这三个 benchmark 上没有提升
简而言之，这么做，确实带来了泛化能力
Thinking in Tool-Use
让推理和工具调用融合，是 v3.2 在工程上的关键设计
DeepSeek-R1 证明了「thinking」对解决复杂问题很有帮助
但 R1 的策略是：第二轮消息到来时，丢弃之前的推理内容
这在工具调用场景下很浪费——每次工具返回结果，模型都要重新推理一遍
DeepSeek-V3.2 的设计是：
-
• 只有新的用户消息到来时才丢弃推理内容
-
• 如果只是工具返回结果，保留推理内容
-
• 丢弃推理内容时，工具调用历史保留
注意
Roo Code、Terminus 这类用「用户消息」模拟工具交互的框架，无法享受这个优化；论文建议这类框架用 non-thinking 模式
Cold-Start
怎么让模型学会「边推理边调工具」，这个能力需要教
DeepSeek 的做法是设计专门的 system prompt：
-
• 告诉模型可以在
<think></think>标签内多次调用工具 -
• 最多 20 次
-
• 最终答案不能包含工具调用
虽然这样训练出来的模式一开始不太稳定，但偶尔能产生正确的轨迹
有了这些种子数据，后续的 RL 就能持续优化
结果对比
到这里，我们看一下模型的性能，自己看图，不赘述了
这个是 DeepSeek-V3.2 的
这个是 DeepSeek-V3.2-Speciale 的竞赛成绩
需要说明的是：Token 效率，是 DeepSeek-V3.2 的一个短板
举个例子，在 Codeforces 中，Gemini-3.0-Pro 用 22k tokens 拿 2708 分，DeepSeek-V3.2 用 42k tokens 才拿 2386 分，Speciale 版本用 77k tokens 拿 2701 分
Speciale 版本为了达到更高性能，输出 token 数明显更多
具体的看这张图
其他：上下文管理策略
搜索智能体场景有个问题：经常撞到 128K 的上下文限制
DeepSeek 试了几种策略：
-
1. Summary：超限后总结轨迹，重新开始
-
2. Discard-75%：丢弃前 75% 的工具调用历史
-
3. Discard-all：丢弃所有工具调用历史（类似 Anthropic 的 new context tool）
-
4. Parallel-fewest-step：并行采样多个轨迹，选步数最少的
结果有点反直觉：
最简单的 Discard-all 效果最好，BrowseComp 从 53.4% 提升到 67.6%
Summary 效率最低，虽然也能提升性能
还差什么
DeepSeek 团队坦诚说了三个局限：
1. 世界知识不够丰富
训练算力有限，知识广度不如 Gemini-3.0-Pro
计划未来扩大预训练规模
2. Token 效率低
达到同样输出质量，需要生成更多 token
需要优化推理链的「智能密度」
这个上文提了
3. 最难的任务还有差距
在最顶尖的复杂任务上，和 Gemini-3.0-Pro 还有差距
我觉得吧，这三个局限其实指向同一个问题：算力
预训练算力不够，知识就不够广
后训练算力不够，token 效率就上不去
基础模型能力不够，最难的任务就做不好
但反过来说，DeepSeek 在有限算力下能做到这个程度，也或许说明...技术路线是对的？
总结
这篇论文，大致说了这三件事儿
-
• DSA 解决了效率问题，让大规模后训练成为可能
-
• 大规模后训练，带来了更高的训练回报
-
• 大规模合成数据，让智能体能力的泛化成为可能
三件事串起来，让 DeepSeek v3.2，在推理能力上追平了 GPT-5
