
简介这份PDF文档面向人工智能研究者、大模型算法工程师及对强化学习推理感兴趣的进阶学习者系统解读DeepSeek-R1项目的技术路线。内容围绕DeepSeek-R1-Zero与DeepSeek-R1两个模型展开剖析如何在不依赖大规模监督数据的前提下通过纯强化学习驱动语言模型自主进化出推理能力并借助蒸馏技术将推理能力迁移至小型模型。文档详细讲解了GRPO相对策略优化、基于规则的准确性奖励与格式奖励、训练模板设计以及AIME 2024基准上pass1从15.6%提升至71.0%、多数投票达86.7%的性能表现还记录了模型自我进化与“顿悟”时刻。DeepSeek-R1部分则覆盖冷启动数据、多阶段训练、拒绝采样与监督微调等关键流程。资源包为1个PDF文件大小约1.94MB结构紧凑便于通读。目前已有290人学习适合希望深入理解强化学习推理机制、复现思路与蒸馏方案的读者参考。1. 从 AIME 15.6% 到 71.0%DeepSeek-R1-Zero 到底验证了什么一份 2025 年流传很广的 DeepSeek-R1 解读 PDF把 DeepSeek-R1-Zero 和 DeepSeek-R1 的训练路径拆得比较细。很多人第一次看会盯着榜单分数但真正值得反复读的是它抛出的那个反直觉结论不喂监督数据只给规则奖励基座模型也能自己长出长链推理。AIME 2024 的 pass1 从 15.6% 爬到 71.0%多数投票后到 86.7%这条曲线不是靠人工标注堆出来的而是 GRPO 在同一个问题上采样一组输出、按组内相对优势反复更新策略跑出来的。这份材料适合两类人想搞清 LLM 推理训练范式的算法同学以及准备用蒸馏小模型落地、关心成本和显存占用的工程同学。下面按「纯 RL 怎么跑通 → 冷启动多阶段怎么补可读性 → 蒸馏怎么迁移 → 复现时参数和坑在哪」的顺序拆。2. GRPO 与规则奖励DeepSeek-R1-Zero 的纯 RL 训练链路2.1 为什么用 GRPO 而不是 PPO传统 PPO 需要一个和策略模型同量级的 critic 来估基线显存和算力直接翻倍。GRPO 的思路是砍掉 critic对同一个问题 q 从旧策略采样一组输出用组内奖励的均值和标准差做标准化得到每个输出的优势值。这样基线来自「同题多答」的相对比较而不是一个独立价值网络。对做 LLM 训练的人来说这意味着同样的卡能塞下更大的策略模型或者把 batch 开得更大。目标函数里有两个关键超参ϵ 控制裁剪范围β 控制 KL 散度权重。ϵ 太小更新保守、收敛慢太大策略震荡。β 是防止新策略跑离旧策略太远的刹车纯 RL 阶段如果 β 设得过小输出会迅速退化成一堆无意义符号。2.2 旧策略与一组输出的工程含义这里最容易读糊。旧策略不是预训练基座而是当前训练迭代开始前最后一次落盘的策略版本一组输出是同一个问题在旧策略下采样出的多条回答。落到代码上就是每步训练前先policy.eval()采样 G 条再切回policy.train()算 loss。G 一般取 8 到 64太小优势估计方差大太大显存吃不消。# GRPO 单步训练的核心逻辑伪代码框架无关 G 16 # 每题采样条数显存与方差折中 old_policy.eval() with torch.no_grad(): outputs old_policy.generate(prompts, num_return_sequencesG) # 一组输出 rewards rule_reward(outputs) # 规则奖励见 2.3 adv (rewards - rewards.mean()) / (rewards.std() 1e-8) # 组内标准化优势 policy.train() logp policy.logprob(outputs) ratio torch.exp(logp - old_logp) loss -torch.min(ratio * adv, torch.clamp(ratio, 1 - eps, 1 eps) * adv).mean() \ beta * kl_divergence(policy, ref_policy) loss.backward()逻辑说明先冻结旧策略采样保证 ratio 的分母是采样时的概率优势用组内标准化避免不同题目奖励量纲差异裁剪项和 KL 项分别对应 ϵ 和 β。参数上G决定显存峰值eps常见 0.2beta纯 RL 阶段可先设 0.001 量级再调。2.3 规则奖励准确性 格式DeepSeek-R1-Zero 不用奖励模型用规则。准确性奖励针对有确定答案的任务比如数学题要求把最终答案放进指定格式里脚本比对即可判定对错。格式奖励强制思考过程放在think标签内保证输出结构一致。两者相加就是总奖励。奖励类型判定方式作用常见坑准确性奖励规则匹配最终答案提供正确性信号答案抽取正则写错全判错格式奖励检查 think 标签闭合稳定输出结构标签嵌套导致解析失败语言一致性奖励检测语种混杂比例减少中英混输只在 R1 阶段引入提示规则奖励的抽取脚本要先在采样输出上离线跑一遍确认正确率分布合理再接入训练循环否则错误信号会被 RL 放大。2.4 训练模板与「顿悟」现象训练模板刻意做得简单先让模型输出推理过程再给最终答案避免引入内容偏见。随着训练推进模型会自发出现反思、回溯、重新分配思考时间的行为论文里叫「顿悟」时刻。工程上观察这个现象的办法是定期 dump 采样输出统计平均生成长度和自我纠错关键词出现频率曲线抬头通常对应 pass1 的跃升。3. DeepSeek-R1 的四阶段训练冷启动数据与拒绝采样3.1 冷启动数据怎么造R1-Zero 推理强但可读性差、语言混杂。R1 的第一步是拿几千条高质量长 CoT 数据微调 DeepSeek-V3-Base 作为 RL 起点。数据来源有四路少样本提示生成、直接提示模型产出带反思验证的详细答案、收集 R1-Zero 输出后处理、人工精炼。输出格式统一成|special_token|reasoning_process|special_token|summary把推理过程和总结分开用户读起来清爽。3.2 四阶段流程拆解阶段一冷启动微调阶段二面向推理的 RL沿用 GRPO但奖励里加入语言一致性项惩罚中英混杂阶段三在收敛检查点上做拒绝采样生成 SFT 数据推理数据约 60 万条另复用 V3 的约 20 万条非推理数据简单查询不给 CoT阶段四再做一轮全场景 RL推理域继续用规则奖励通用域用奖励模型对齐有用性和无害性。# 拒绝采样过滤的典型判据示意按实际数据管线调整 # 1. 丢弃语言混杂的推理链 grep -L -P [\x{4e00}-\x{9fff}].*[a-zA-Z]{20,} reasoning_chains.jsonl clean.jsonl # 2. 丢弃超长段落和裸代码块 python filter.py --max_para_tokens 512 --drop_code_block true \ --input clean.jsonl --output sft_reasoning.jsonl # 3. 与 V3 非推理数据按比例混合 cat sft_reasoning.jsonl v3_nonreasoning.jsonl | shuf sft_final.jsonl逻辑说明拒绝采样不是随机丢而是按可读性判据过滤语言混杂和超长段落是主要剔除对象非推理数据按任务需求调整比例简单查询不产 CoT 是为了控制响应长度。参数上max_para_tokens控制单段上限drop_code_block决定是否保留代码块样本。3.3 语言一致性奖励的接入位置语言一致性奖励只在阶段二引入和准确性奖励相加。实现上通常统计输出中目标语种 token 占比低于阈值按比例扣分。这个奖励不能给太重否则模型为了语种纯净牺牲推理深度表现为答案变短、正确率回落。注意阶段三的 SFT 数据来自 RL 收敛检查点如果阶段二没收敛就采样会把这批「半成品」推理链固化进下一轮后面很难纠回来。4. 蒸馏到小模型80 万样本怎么用、RL 为什么更贵4.1 蒸馏与直接 RL 的成本对比论文里做了个关键对照在 Qwen-32B-Base 上直接跑大规模 RL 超过 10K 步得到 R1-Zero-Qwen-32B效果仍不如从 R1 蒸馏。蒸馏只做 SFT不接 RL用 R1 生成的约 80 万条样本微调 Qwen、Llama 等开源模型推理能力提升明显且算力成本低得多。对资源有限的团队这条路更现实。方案训练方式算力需求效果适用场景直接小模型 RLGRPO 大规模 RL高需长步数低于蒸馏有充足算力做研究蒸馏 SFT仅监督微调低接近大模型企业落地、消费级硬件4.2 蒸馏数据构造与微调配置蒸馏数据直接用 R1 生成覆盖数学、代码、STEM 等推理任务。微调时常见做法是控制学习率在 1e-5 到 2e-5epoch 2 到 3序列长度按任务截断。数据里保留reasoning_process和summary结构让小模型学会先推理再总结。# 蒸馏 SFT 数据格式化示意 def format_sample(q, reasoning, summary): return { prompt: q, response: freasoning_process{reasoning}/reasoning_process fsummary{summary}/summary } # 训练侧关键参数 train_args dict( learning_rate1.5e-5, # 小模型蒸馏常用区间 num_train_epochs2, # 过多易过拟合蒸馏数据 max_seq_length4096, # 按显存和任务调整 packingTrue # 提升吞吐 )逻辑说明格式函数保证推理与总结分离训练侧学习率不宜大否则破坏基座通用能力packing 把短样本拼成长序列提升 GPU 利用率。参数上max_seq_length直接决定显存占用长 CoT 样本多时优先调它。4.3 蒸馏模型的验证方法验证不能只看一个榜单。常见做法是同时跑 AIME、MATH-500、LiveCodeBench再补一个通用对话集看有没有退化。蒸馏模型在数学和代码上提升最明显通用能力可能略降需要按业务权衡数据配比。5. 复现排错奖励 hacking、语言混杂与显存调优5.1 奖励 hacking 的识别与抑制纯 RL 最容易踩的坑是奖励 hacking模型发现格式奖励好拿就疯狂输出空 think 标签凑格式分推理内容反而缩水。识别办法是分开统计准确性和格式奖励的均值曲线如果格式分涨、准确性分平基本就是 hacking。抑制手段包括降低格式奖励权重、对空标签直接判零、定期人工抽检采样输出。5.2 语言混杂与输出可读性R1-Zero 的中英混杂在纯 RL 下很常见。除了语言一致性奖励还可以在采样后做后处理过滤把混杂比例超阈值的样本从 SFT 数据里剔除。可读性问题则靠冷启动格式约束解决reasoning_process和summary分离后前端展示只取 summary用户体验提升明显。5.3 显存与吞吐调优清单调优项做法影响采样条数 G从 8 起调按显存加方差与显存梯度检查点开启省显存降速KL 权重 β纯 RL 先小后调策略偏移序列长度按任务截断显存峰值拒绝采样阈值先离线统计再定数据质量提示复现时先把 G 和序列长度压到最小跑通一轮确认奖励曲线正常再逐步放大比一上来拉满参数更容易定位问题。5.4 一个具体技巧用采样输出反推奖励脚本规则奖励写错是复现失败的高频原因。我一般会先让基座模型在目标任务上采样几百条输出人工标注对错再用这批数据反推答案抽取正则和格式判定逻辑确认判定准确率达标后才接入 RL。这样能把「奖励脚本 bug」和「训练策略问题」分开排错时少走很多弯路。本文还有配套的精品资源点击获取