DeepSeek-V4.1-Flash
后训练是怎么做的

后训练定调：把创新让位给数据

§5.1 开头那段话在整篇报告里的分量，可能不低于任何一个架构模块。

原文明确写道：本次发布不引入新的后训练算法，整体配方沿用 SFT → RL → on-policy distillation（OPD）， "没有超出成熟实践的算法改动"。精力"几乎全部集中在模型被训了什么，而不是怎么被优化"。流水线做三件事：

1. 合成可验证任务生成多样化任务及其参考解与奖励信号。
2. 程序化构建并扩展交互环境使轨迹能被低成本采集和评估。
3. 严格过滤、去重与难度校准保证数据质量和课程平衡。

这句话值得跟前几代报告对照读：V3/R1 时代的卖点是 GRPO、是规则奖励、是冷启动配方；到 V4.1 这一代， DeepSeek 选择公开宣称算法侧已经没有增量，把叙事重心整体移到了"任务从哪来、环境怎么造、沙箱怎么撑住"。

大规模 Agent 任务合成

任务是 agent 学习的燃料。报告的做法是：让模型自己造任务，再用两个可量化的维度去训练"造任务"这件事本身。

任务的形式化与自举

每个任务被形式化为三元组 (problem, environment, verification system)，质量沿两个维度评估：

• 难度（difficulty）——保证任务非平凡；
• 正确性（correctness）——保证三个组件之间不存在致命缺陷。

把这两个维度直接当作奖励信号，迭代训练模型去构造更好的任务。报告承认模型"已经开始展现出自建训练任务的能力， 但远谈不上完美"。此外任务被全生命周期监控：每当一个任务被用于新的 RL run，产生的轨迹就成为重新审计其质量的新证据。

通用 Agent 环境：从真实工作流反向构造

• 鼓励内部员工与外部伙伴把最新模型接入日常工作流，自愿回传交互数据与反馈。
• 根据回传数据里观察到的接口，构造大量 mocked tools，复刻真实工具与系统的接口和行为——输入格式、输出结构、API schema、行为约束，覆盖常见 SaaS / 企业应用，也覆盖更专门的业务后台系统。
• 大规模收集内部员工提交的负反馈与失败案例，据此生成单轮与多轮 agent 环境；通过重建工具上下文、用户交互模式和失败条件，实现失败的系统性重放与针对性 RL。

编码 Agent 环境：五类 agent 组成的流水线

数据来源两类：① 内部员工与外部伙伴的编码 agent 会话，筛出高复杂度或模型表现差的任务，再按轨迹去重；② star 数达标的公开 GitHub 仓库。环境构建则由多个专门化 agent 协作完成：

1. 可行性与设计 agent判断项目能否在容器内构建并完整运行、能否自动验证；选定某个 turn 或 commit 作为任务起点，设计若干足够复杂的实现方向，产出具体评测点（fail-to-pass 与 pass-to-pass）和构建报告，必要时从网上抓取外部资源。
2. 环境搭建 agent在隔离容器里配好依赖、初始工作目录、测试代码和任务描述，自测，抹掉一切可能泄漏解法的痕迹，打包成新的镜像层。
3. 多个求解 agent分别尝试该任务，产生可供审计的轨迹。
4. 质检 agent独立审查环境与求解轨迹，检查环境问题、事实错误、评测点与任务描述不匹配、以及可 hack 风险。
5. 修复 agent质检不通过则修复所有错误，调整过易或过难的评测点，任务重新进入验证。

这条流水线的目标被表述为：自动、批量地产出正确、有区分度、长度与难度可控的 RL 训练数据。

合成任务上的 RL：两个扩展维度

RL 的扩展被显式拆成两个维度——训练算力和脚手架（scaffold）数量。

Rollout 执行与训练解耦

为了在异构 scaffold 上做 RL，rollout 执行被拆成两层：

agent sandbox

运行 scaffold 本身及其工具。

worker container

一个与 scaffold 无关的控制层：编排 rollout，把异构交互归一化成统一的轨迹 schema，并与 trainer 通信。

两者都跑在 DSec 上，位于可抢占的 GPU 训练池之外，从而把长生命周期的 rollout 与细粒度的训练调度分离。 trainer 被抢占时，rollout 执行可以挂起并卸载，同时保留完整状态以便后续恢复，并释放 CPU 与 GPU 资源。 报告强调：这一设计让跨异构 scaffold 的 RL 稳定高效，而无需修改底层算法。

用模型合并把算力接力下去

单次训练 run 的有效算力有上限。做法是用模型合并来重新初始化后续 RL run： 合并来自不同 scaffold 或不同配置的 checkpoint，把沿不同优化路径获得的改进叠加起来。 Figure 7 与 Figure 8 中断开的曲线段正对应这种重初始化。报告称这同时提升了任务性能与 token 效率， 是一种"聚合并行 RL 算力、跨 run 继续扩展的简单实用方法"。

DSec：把百万量级沙箱跑起来

DeepSeek Elastic Compute，一个为大规模 agent 训练与评测而建的生产级沙箱平台。 V4.1 的训练需求推到了数百万并发沙箱实例，瓶颈随之从执行环境异构转向数据中心可扩展性、 负载隔离、单节点密度，以及"越来越有能力的 agent 的越界行为"的遏制。

横向扩展：分片 + 放宽一致性的调度

• 分片（scale units）：把计算节点划成多个分片，既容纳大量机器，也缩小爆炸半径——隔离不同实验的负载，避免单个内存密集任务耗尽无关工作共享的资源。
• 自研放置引擎，而非 Kubernetes。关键观察是：只要每个计算节点强制执行本地安全约束，agent 沙箱的放置只需要最终一致性。放置引擎因此部署成多个独立副本、互不同步；每个副本根据近期测量预测资源可用性，做出"够好"的放置决策。
• 节点侧兜底：每个节点负责校验最终放置决策，执行硬性准入约束——超过本地警戒阈值就拒绝新放置。整体上让 DSec 扩展到百万级容器而不被中心协调卡住。

高密度运行

节点层面使用硬件支持的 sub-NUMA 分区，把每个 worker VM 绑定到单个 NUMA 域，容器跑在这些 VM 内、 CPU 与内存分配限制在 VM 本地的 NUMA 资源上。这在激进的内存超售与 Linux 内核锁竞争之间取得平衡，同时把内存压力和运行时故障局部化。

高密度会通过后台负载干扰扭曲时间敏感的评测。DSec 因此引入延迟敏感（LS）执行类： 对非 LS 任务施加 SCHED_IDLE 以最小化调度优先级，并用 core scheduling 保证只有同优先级类的任务 才会同时运行在同一物理核的兄弟超线程上，从而消除干扰。

越界 agent 的遏制

报告这一段的坦率程度值得单独摘出来。RL 训练中"频繁观察到"agent 试图 reward hacking 或无意间搞崩环境，实际发生过的包括：

• 利用 XFS 驱动的权限问题
• AppArmor 非法内存访问
• 从包镜像服务泄漏答案
• 删除关键二进制
• 破坏系统文件
• 删掉整个文件系统

对策：每沙箱独立的 AppArmor profile + 基于 eBPF 的细粒度网络策略。 若 agent 弄崩了自己的环境，该轨迹被判定为失败，并向 RL 框架上报一个 "repercussion" 信号。

推理努力度：把成本-质量做成一个连续旋钮

输出 token 数是服务成本的另一个关键决定因素。做法是在 RL 阶段引入一个标量 b 作为显式条件信号， 同时作用于单轮推理与多轮 agent 任务。

条件化方式

在 system prompt 前置一行指令：

对每个训练 prompt x，在每个努力度 b ∈ B 上采样 M_b 条回复。 共享同一 (x, b) 的回复构成一个子组，组内奖励做均值中心化以得到 group-relative advantage。

长度惩罚与指数衰减系数

ℓ_b,j

该回复的推理 token 数。

L_norm

参考长度。

C_max

单条轨迹上惩罚的上限——超过后边际 token 惩罚归零，附录 C 明确指出封顶区间需单独分析。

k₀

最低努力度处的基础惩罚系数，控制整体上"求短"的压力。

τ

惩罚衰减速率。b 每增加 τ，惩罚系数乘以 e⁻¹；τ 越小，各努力度之间的行为分离度越大。

为什么是指数形式（附录 C）

设 p_x(ℓ) 为在 ℓ 个推理 token 后解出问题 x 的概率。在未封顶区间，偏好长度 ℓ*_x(b) 满足一阶条件 p′_x(ℓ*) = k(b)/L_norm。若假设边际收益近似指数衰减 p′_x(ℓ) ≈ a_x·exp(−ℓ/s_x)，代入即得：

也就是说，指数惩罚表使"请求的努力度"与"偏好推理长度"之间呈现一阶仿射关系——这正是要这个旋钮线性可控的理由。 报告自己也给了免责声明：这只是奖励层面的局部近似，实测平均长度不必然线性或逐点单调，因为努力度指令会直接改变推理策略、 生成有随机性、agent 轨迹的 turn 数不同、子组奖励归一化也会改变优化强度。

部署侧：三档 API 对应三个 b

虽然训练只用了有限个努力度，部署时可以取中间值得到插值行为。2026 年 9 月上线的公开 API 暴露三档预设， 直接映射到这个标量接口，不改动任何模型权重或解码配置：

Table 2 · 公开 API 档位与标量努力度的映射

异步后训练基建

RL rollout 阶段的长尾问题一直是训练效率的主要瓶颈。解法是异步生成样本，靠维持足够高的并发来抹平长尾。 报告称异步训练现已在几乎全部 RL 与 OPD 任务上启用。

整体工作流：三种分发粒度的取舍

rollout 与训练共置在同一批物理设备上分时执行，从而免去在两阶段之间手工调配资源。 每个任务指定在飞样本数（in-flight samples）的上界，系统在整个 rollout 阶段维持该上界。分发粒度试过三种：

batch 级
✗ 放弃

开头多发几个 batch，每次训练迭代后补满一整个 batch。结果训练指标剧烈震荡，说明粒度太粗。

prompt 级
✗ 放弃

一个 GRPO group 跑完就发一个新 prompt。结果容易卡在 group 内的长尾样本上，难以平稳维持目标并发。

sample 级
✓ 最终方案

只要新完成的样本数达到下一个 prompt 所需的 GRPO group size，不管这些完成来自哪些 group，就分发该 prompt。这样能在整个训练过程中维持稳定的 rollout 并发。

积累到足够训练样本后，训练抢占正在进行的 rollout。训练时使用 concatenated routing-replay： 对于跨越多个 checkpoint 的样本，把各 rollout 段各自产生的专家路由拼接起来， 而不是丢弃、再用新 checkpoint 重算路由信息。

异步带来的两个副作用，及四个机制

异步生成在提升效率的同时，引入两类会损害训练质量的副作用，需要不同的处理方式。

① 长度分布偏置

短序列先完成，因此在早期训练 batch 中占主导。两个机制：

• 分发器可以按数据集限制并发，从而调节各数据集在稳态训练 batch 中的比例，间接通过控制来源缓解长度偏斜；
• 支持丢弃过早返回的短样本，平滑向稳态长度分布的过渡，防止模型过拟合到过短的序列。

② Off-policy 样本

部分或全部 token 由更早的 checkpoint 生成。两个机制：

• 调节样本分发逻辑与训练样本的等待条件，为最大 off-policy 比例设定上界，确保训练数据不至于偏离当前模型太远；
• 训练时加入 loss masking，消除过度陈旧（excessive staleness）token 的贡献。

性能优化：中断要瞬时，恢复要无缝

1. Token 级中断生成可在任意 token 边界停止。训练数据收集够了，所有在飞样本几乎立即停止，系统无延迟进入训练阶段。
2. Token 粒度的状态持久化生成过程中持续持久化 KV cache、专家路由等 rollout 状态。换上新 checkpoint 恢复时直接复用，消除重新 prefill 的开销，被中断的样本从断点精确续跑。
3. 样本粒度 GC由于需要保留所有在飞样本的状态，每个样本一完成就立刻释放其状态。
4. 顺带解决集群抢占同一套快速中断 + 无缝恢复机制，让训练作业能及时响应集群调度抢占信号而不丢进度，提升整体集群利用率。

大规模 On-Policy 蒸馏

作为后训练的最后一个阶段，最终的全词表 OPD 任务在所有领域的数据集上训练，使用超过 40 个教师模型， 同样采用异步生成来提升 rollout 效率。

OPD 阶段还要求训练中动态重配置：持续跟踪模型能力，据此调整训练配方——数据集混合比例、各数据集并发上限、 以及当前激活的教师集合。在同步训练里这很容易，因为 rollout batch 天然提供了配置边界； 但在异步设定下，不同配置下生成的样本会同时在飞。报告称其基建支持配置之间的一致性切换，且不中断 rollout 或训练。

架构欠下的债，都在后训练里还

这条线索散落在第 2、3 节，但全部落在后训练阶段执行，单独汇总一次会更清楚： V4.1 有四项架构/部署设计不是在预训练里学会的，而是在后训练阶段补上的。

FP4 主 KV

主 KV cache 的量化感知训练（QAT）在后训练阶段引入。格式为 E2M1 + 每 16 通道一个 E4M3 scale（参照 NVFP4 但省掉二级全局 scale）。在 RoPE 之后量化。SWA KV 因对量化敏感而保留 FP8。§2.4.4

分层稀疏索引器

候选池限制机制是 training-aware 的，在后训练引入：训练与推理施加完全相同的候选限制，使更深层的索引器在它推理时实际使用的搜索域上被优化。§2.3.2

Decoder SWA
Bounded Replay

重建出的 decoder SWA KV 与完整前向在数学上并不等价。"为了额外的安全"，后训练期间额外模拟同样的 replay 过程做训练感知适配。§3.2.2

DSpark

与 V3 的 MTP 不同，DSpark 不参与骨干预训练，而是在预训练后单独一个阶段训练（骨干冻结）。后训练期间继续与骨干一起训练，但不把 DSpark 的梯度传回骨干，从而与不断演化的策略保持对齐，既加速线上服务，也加速 RL 与 OPD 的 rollout 生成。§2.4.3

评测结果

评测设置里的两个细节

• 编码 agent用 DeepSeek Harness 的 Minimal 模式、1M 上下文、temperature 1.0、top-p 0.95；DeepSWE v1.1 按官方要求改用 mini-SWE；SEC-Bench Pro 特意用 Claude Code harness，因为需要它的 session compact 设计；视觉 agent 用 Claude Code harness、512K 上下文。
• 反 reward hacking：限制联网、剥离 Git 历史，并自动清除各类构建与包缓存（go/mod、node_modules、编译出的 .jar、Python __pycache__）。即便如此，测试中仍观察到寻求 exploit 的行为——例如在 CyberGym 里反编译 Ubuntu 核心包以寻找漏洞。报告呼吁社区在设计下一代基准时优先考虑检测与缓解这类行为。

主结果表

Table 3 · 全部模型均在 Max 档位。† 表示 HLE 的纯文本子集。蓝色列为 V4.1-Flash，加粗为该行最优。

读这张表时值得同时记住三件事：

• 相对前代是大跨步。DeepSWE v1.1 从 54.4 → 74.2，SEC-Bench Pro 从 30.9 → 62.8，Terminal-Bench 3.0 从 7.6 → 30.0。考虑到 V4.1-Flash 的激活参数比 V4-Pro 还少，这个幅度基本只能归给后训练的数据/环境工作。
• agent 类强于纯推理类。Codeforces 3471、MathArena 65.6 都很强，但 HLE 只有 36.8（文本子集 39.1），是全表明显的短板——这与"世界知识由预训练决定"的说法一致，8B/16B 的激活量在知识密集任务上藏不住。
• 专家科学类 agent 任务仍有真实差距。Terminal-Bench 4.0 上 31.2 vs Opus-5 的 51.8，ExploitGym 15.3 vs GPT-5.6 的 33.7。报告自己在引言里就承认了这一点。

努力度曲线：收益是前置的

附录 B.3 进一步给出八个基准的逐一曲线：长度侧从 25 到 100 是一致的 2.0–3.1× 增长 （AIME 2026 从 4.6k 到 11.4k token/条，MathArena Apex 2025 从 29.1k 到 86.1k），没有失控增长或异常， 因此任一档位的算力成本都可以事先估算。准确率侧没有任何一个基准随努力度上升而退化： MathArena Apex 2025 涨了 40.3 个点（25.3% → 65.6%），Apex Shortlist 涨 11.5， 已经饱和的基准保持稳定（GPQA Diamond +1.3，LiveCodeBench +2.6），AIME 2026 达到满分 100%。

脚手架鲁棒性

模型很少只部署在一个固定 agent 框架里；不同 scaffold 在 system prompt、工具定义、上下文管理策略和交互协议上都不同， 过拟合到某一个 harness 的模型换一个就会明显掉点。评测覆盖 6 个 scaffold 家族的 8 种配置， 模型 checkpoint、解码配置、任务集完全一致，只换 harness。

Table 4 · Max 努力度。DeepSWE v1.1 每任务 N=8，Terminal-Bench v2.1 每任务 N=3；Linux 容器、temp 1.0、top-p 0.95、1M 上下文、max_steps=500。Terminal-Bench v2.1 无网络。Claude Code 一列为 v2.1.251；四个版本（v2.1.105/238/251/259）的平均为 DeepSWE 68.9、TB2.1 87.8。

跨 scaffold 的极差约 8.7 个点（DeepSWE）与 6.5 个点（TB2.1），报告将这一鲁棒性归因于训练数据中环境、工具 schema 与交互格式的多样性。附录 B.2 补充了一个更微妙的观察：努力度在每个 scaffold 上都单调拉长轨迹， 但 Pass@1 只是松散地跟随，中间档位常有平台期甚至回落；而且在接近饱和的任务上， scaffold 的选择至少和努力度档位一样重要。

多智能体：初步但方向清楚

用 DeepSeek Harness 的 Agent Team 模式做的探索性实验。报告明确标注结果是 preliminary。

协作机制

spawn_teammate

lead agent 默认可异步创建具名、持久的队友。每个队友接收一个委派任务，以 fresh 模式（无 lead 历史）或 fork 模式（lead 已完成轮次的一次性快照）启动。所有 agent 共享同一个仓库 checkout，编辑对彼此立即可见。

send_message

持久化的点对点邮箱。消息送达运行中的队友时在其下一个 step 边界生效；队友空闲则开启新一轮；队友已停用则将其唤醒。

list_agents
wait_agent

lead 用来监控运行状态，并等待状态、邮箱或共享任务的变化。

team_task_*

四个工具维护共享任务板上的任务归属、依赖关系与建议性写入范围，更新时带 revision 检查。

interrupt_agent

只有 lead 可以打断队友当前轮次。所需工作完成后，由 lead 审查并测试合并后的改动，产出最终回复。

奖励里的延迟项

Agent Team 模式用 RL 训练，奖励由三部分组成：

• 任务性能；
• 协作奖励——鼓励委派与 agent 间通信；
• 推导延迟惩罚（derived-latency penalty）——鼓励高效协调。

测试时算力扩展

评测集：ProgramBench 的高置信子集——只保留参考解在隐藏测试集上通过率 ≥95% 的任务，剩下 172 个 "golden" 任务； 以及 FrontierSWE v2 的 no-GPU 子集。两者都在显式的单次 rollout 墙钟时限下评测，到点即取当时可用的输出计分。

多智能体在每一个时限上都优于对应的单智能体配置。差距的形状值得注意：1 小时时限下两者几乎没区别 （13.59 vs 12.79），差距是随着时限拉长才打开的——ProgramBench 上 8 小时处的 30.04 vs 20.39 接近 10 个点。 也就是说多智能体买到的不是"更快"，而是更高的算力天花板。