DeepSeek-R1 的训练思路与开源影响

2025 年初，很多人第一次认真看到“推理模型”这个词，不是在论文课上，而是在一段模型回答里：它会花更多时间拆解问题、检查条件、修正答案，然后再给出结论。更让人惊讶的是，这类能力不再只是少数闭源实验室的展示，DeepSeek-R1 的公开技术报告、模型和蒸馏版本，把训练思路带到了开源社区的桌面上。

我当时最感兴趣的，并不是“谁的榜单分数更高”，而是另一个问题：一个模型为什么会开始愿意多想几步？过去我们习惯把模型能力理解为参数规模、训练数据和指令微调的函数；R1 让更多工程师看到，推理时花多少计算、奖励怎样设计、模型是否可以通过试错获得策略，同样会改变能力边界。

当然，任何技术报告都不应该被简化成一个神话。R1 的训练依赖大量工程细节、数据筛选、验证器和基础模型能力；“只要加强化学习就会自动出现推理”是危险的误读。真正值得学习的，是它把可验证任务、强化学习和推理时计算组合成了一条可研究、可复现、也可质疑的路线。

一、R1-Zero：先让模型在奖励里寻找能力

R1-Zero 的核心想法可以用一句白话概括：不给模型太多人工写好的推理示范，直接在数学、代码等可验证任务上进行强化学习，让它通过结果反馈逐渐学会更有效的解题行为。

传统流程往往是：人或更强模型先写出高质量推理过程，再用监督微调教模型模仿。这个方法稳定，也容易控制格式，但模型学到的可能主要是“像这样写答案”。R1-Zero 路线更激进，它把重点放在最终结果是否正确，让模型在探索中发现分解问题、回看计算和延长推理等策略。

训练过程可以抽象成：

问题 q
  ↓
模型生成多个候选答案
  ↓
验证器判断答案是否正确
  ↓
正确获得奖励，错误获得较低奖励
  ↓
更新策略，提高高奖励轨迹的概率

这条路线的吸引力在于，它减少了对人工逐步标注的依赖，也让模型有机会发现训练者没有明确写出来的解法。但它很快暴露出工程难题：输出可能变得很长，格式不稳定，语言混杂，早期训练容易不稳定；模型也可能学会钻验证器漏洞，而不是真正解决问题。

所以 R1-Zero 更像一次重要的实验：它证明了在合适的可验证任务和训练设置下，推理行为可以通过奖励驱动逐渐涌现；它并不意味着所有任务都能用同样办法训练。

二、为什么冷启动数据仍然重要

后来公开讨论里有一个很容易被忽略的平衡：即使强化学习很重要，冷启动的高质量示范仍然有价值。一个完全没有格式习惯的模型，可能知道答案对错，却不会稳定地产生可读、可解析、可继续训练的轨迹。

冷启动数据可以告诉模型一些基本规则：怎样理解问题、怎样组织推导、什么时候检查结果、怎样在不确定时表达限制。它不必规定每一个 token，但可以把探索空间缩小到更容易学习的区域。

这与软件工程很像。你可以让程序通过测试驱动逐渐修正，但如果项目连目录规范、输入输出和错误格式都没有，测试反馈会变得嘈杂。先提供一套可用的接口习惯，再让系统通过反馈优化，通常比从完全随机的行为开始更稳。

因此更现实的训练路线往往是：

基础模型
   ↓
少量高质量冷启动示范
   ↓
可验证任务上的强化学习
   ↓
拒绝采样与数据筛选
   ↓
再次监督微调 / 强化学习
   ↓
安全、格式与通用能力评测

冷启动不是对强化学习的否定，而是给强化学习一个更好的起跑位置。

三、可验证奖励是整条路线的地基

推理训练最理想的奖励来自可以自动检查的任务。数学题可以重新计算，代码可以运行测试，SQL 可以在隔离数据库执行，结构化输出可以经过 Schema 和业务规则校验。验证器不需要理解模型全部过程，只要能可靠判断关键结果。

type Verification = {
  passed: boolean
  score: number
  evidence: string[]
}

function verifyReasoningAnswer(
  expected: number,
  candidate: { answer: number; expression: string },
): Verification {
  const recalculated = evaluateSafely(candidate.expression)
  const passed =
    recalculated !== null && Math.abs(recalculated - expected) < 1e-6

  return {
    passed,
    score: passed ? 1 : 0,
    evidence: passed
      ? [`表达式重新计算得到 ${recalculated}`]
      : ['表达式计算结果与标准答案不一致'],
  }
}

这段代码只是概念示意，真实的表达式执行必须放在隔离环境中，不能直接运行模型生成的任意代码。验证器还要防止格式投机、整数溢出、超时和资源消耗攻击。

可验证奖励的另一面，是它的覆盖范围有限。数学和代码容易检查，不代表开放式研究、产品设计和伦理判断也能被一个数字完整描述。对不可完全验证的任务，必须组合参考答案、裁判模型、人工抽检和安全规则，不能把一个粗糙分数冒充真理。

四、GRPO 为什么成为重要的配套方法

R1 的训练讨论里，GRPO 经常和它一起出现。GRPO 不依赖一个单独的价值模型去精确估计每个状态的长期回报，而是让同一个问题生成一组答案，在组内比较奖励并计算相对优势。

同一个问题
 ├─ 候选 A：正确，奖励高
 ├─ 候选 B：错误，奖励低
 ├─ 候选 C：正确但冗长
 └─ 候选 D：格式错误
          ↓
       组内比较
          ↓
   提高好轨迹，降低坏轨迹

这个方法降低了价值建模的一部分负担，但不代表训练成本消失了：同一个问题要采样多个答案，验证器要运行多次，显存和推理吞吐仍然是大问题。GRPO 的效果还高度依赖组内奖励差异，如果一组答案全部一样好或一样差，学习信号就会变弱。

它真正带来的启发是：在可验证问题上，模型可以从“同题不同解”的相对反馈中学习。相对比较不需要我们对每个中间状态给出完美的绝对分数，但仍然需要可靠的任务定义和验证器。

五、推理时计算为什么重新成为能力变量

过去讨论模型性能，常把一次回答的 Token 数看成成本；推理模型让我们看到，它也可以是能力预算。简单问题用一次短回答，复杂问题允许更多尝试、检查和搜索，系统就能用更多计算换取更高正确率。

推理预算增加
      ↓
候选路径更多 / 检查机会更多
      ↓
复杂任务的正确率可能提高
      ↓
延迟、Token 和 GPU 成本同步上升

这里的关键字是“可能”。多花计算不是无条件收益。模型可能重复同一个错误，生成更长的废话，或者在已经找到答案后继续空转。因此生产系统需要动态预算：根据任务难度、历史表现和验证结果决定是否继续，而不是让每个问题都使用最大推理长度。

评测也要同时报告质量和资源：准确率、通过率、平均 Token、P95 延迟、单位任务成本和超时率。只看榜单分数，会把推理时计算的账单藏起来；只看成本，又会错过复杂任务上的能力提升。

六、蒸馏让成果进入更小的模型

R1 生态里另一个重要影响，是高能力推理轨迹可以用于训练更小的模型。大模型负责生成候选和高质量解法，经过验证和筛选后，作为监督数据或偏好数据教给小模型。

强推理模型生成轨迹
          ↓
验证、去重、过滤和脱敏
          ↓
构造小模型训练数据
          ↓
SFT / 偏好优化 / 强化学习
          ↓
更低成本的专用模型

蒸馏不是简单复制文本。长轨迹里可能有错误分支、无效重复和不适合目标模型的表达，需要筛选和压缩；大模型解决问题的方式也不一定适合小模型的上下文和算力。蒸馏后的模型必须重新评测，确认它没有只记住题型表面。

这条路线对开源社区很重要，因为不是每个团队都有资源从头训练超大模型，但可以利用公开模型生成的数据、验证器和微调框架，在更小的参数规模上做任务专用优化。

七、开源影响不只是放出一个权重文件

R1 的开源影响至少有四个层面。

第一，更多团队开始认真研究推理时计算，而不只追逐参数规模。第二，可验证任务和奖励工程从研究论文走进普通开发者的学习路线。第三，蒸馏版本和量化部署降低了实验门槛，个人开发者也能在有限硬件上观察推理模型行为。第四，模型训练的讨论变得更开放：数据、验证器、采样策略和评测方法开始被更多人拆解和复现。

但开源不等于自动可用。权重许可证、训练数据来源、模型安全、输出偏差和部署成本仍然需要使用者自己负责。一个模型能在公开数学集上表现很好，不代表它能安全处理企业权限、医疗建议或生产代码发布。

开源最大的价值，是让更多人有机会提出问题、做实验和发现边界；它不是替使用者免除验证责任。

八、如何避免把 R1 学成几个口号

如果要真正学习这条路线，我建议按四步做一个小实验：

准备一组可验证的数学或代码题，先写好独立验证器。
对每道题采样多个答案，观察奖励分布和错误类型。
用组内相对奖励做一个小规模训练或排序实验，记录质量与成本变化。
在没有参与调参的测试集上评测，并人工阅读一批失败轨迹。

实验重点不是复刻论文规模，而是亲手看见奖励如何影响行为。你会发现，模型可能正确率提高了，却变得更长；格式变好了，却开始重复模板；训练奖励上升了，独立测试却没有进步。这些现象比一张漂亮的最终曲线更能教会你什么叫训练目标错位。

九、我的总结：R1 改变的是问题的问法

DeepSeek-R1 最值得记住的地方，不是“某个模型突然会推理了”，而是它把一个长期存在的疑问变得更具体：我们能不能用可验证的反馈，让模型在推理时投入更多计算，并通过试错学会更好的解题策略？

这个问题没有被一个模型彻底解决，但它已经形成了一条清楚的研究和工程路径：用冷启动数据建立基本行为，用可验证奖励判断结果，用组内比较提供学习信号，用推理时计算换取复杂任务能力，再用蒸馏把能力带到更小、更便宜的模型上。

我研究完这段发展史后，最大的感受不是兴奋，而是警醒。模型真正优化的是进入目标函数的东西，而不是我们口头上说的“理解”“深度”和“可靠”。验证器写得差，模型就学会钻空子；评测只看最终答案，就看不见过程退化；只报告准确率，就看不见推理成本。

所以学习 R1，别只记住模型名称和榜单。去写一个验证器，去看一条失败轨迹，去测一次 Token 成本，去问清楚“这个奖励究竟鼓励了什么”。当你能从这些细节理解模型为何变强、又为何会变坏时，才算真正读懂了推理模型时代带来的变化。