简介DeepSeek-R1技术报告论文面向大模型研究者、算法工程师及对强化学习推理感兴趣的进阶学习者系统呈现了如何通过大规模强化学习激发LLM推理能力。报告围绕DeepSeek-R1-Zero与DeepSeek-R1两代模型展开前者在无监督微调条件下经RL训练自然涌现出推理行为却存在可读性差、语言混杂等问题后者引入多阶段训练与冷启动数据加以改进推理表现可与OpenAI-o1-1217媲美。资源为单个PDF文件压缩包约1.27MB内容涵盖贡献总结、评估结果、强化学习算法、奖励建模、训练模板、蒸馏方法及Codeforces、GPQA Diamond、MATH-500、MMLU、SWE-bench等基准测试数据并开源了1.5B至70B六个蒸馏模型。已有5205人学习下载适合希望深入理解推理模型训练路径、复现实验或撰写相关综述的读者参考。1. 从 DeepSeek-R1 技术报告看推理模型训练范式的转向很多人第一次翻 DeepSeek-R1 技术报告是冲着“开源复现 o1”这个标签去的但真正值得读的不是榜单数字而是它把强化学习在大模型后训练里的位置重新摆了一遍。过去做推理增强主流路径是堆监督微调数据、请人写长思维链成本高且天花板明显R1 这条线则把重点放在用可验证奖励驱动的强化学习上让模型自己在数学、代码这类有明确对错的任务里长出长推理。对做算法、做后训练、做评测的工程师来说这份技术报告的价值在于它给出了一套相对完整的训练流程描述冷启动数据怎么造、RL 怎么稳定、蒸馏怎么落地、失败尝试长什么样。读懂它等于拿到一张“推理模型后训练”的施工图而不是只记住一个模型名字。2. DeepSeek-R1 技术报告里的训练流程拆解2.1 从 DeepSeek-V3 基座到 R1-Zero 的纯 RL 路线技术报告里最反直觉的一点是 R1-Zero 这条线几乎不依赖监督微调直接在基座模型上跑大规模强化学习。它的奖励设计很克制主要分两类一类是准确性奖励比如数学题答案是否匹配、代码是否通过单元测试另一类是格式奖励要求模型把推理过程放进指定标签里。这种设计的好处是奖励信号客观、可自动判定不需要训练一个容易被人钻空子的奖励模型。常见做法是用 GRPOGroup Relative Policy Optimization这类算法它对每个问题采样一组回答用组内相对得分来估计优势省掉了单独的价值网络。下面是一段简化到能跑通逻辑的伪代码用来理解奖励和优势是怎么算的# 简化版 GRPO 单步逻辑仅用于理解数据流 def compute_advantages(rewards): # rewards: 同一问题下 G 个采样回答的得分列表 mean_r sum(rewards) / len(rewards) std_r (sum((r - mean_r) ** 2 for r in rewards) / len(rewards)) ** 0.5 # 组内归一化得到每个回答的相对优势 return [(r - mean_r) / (std_r 1e-8) for r in rewards] def rule_reward(answer, gold, fmt_ok): # 准确性奖励答案匹配给 1否则 0 acc 1.0 if extract_final(answer) gold else 0.0 # 格式奖励推理标签完整给 0.5否则 0 fmt 0.5 if fmt_ok else 0.0 return acc fmt逻辑说明compute_advantages把同一问题下的多个回答放在一起比较避免绝对奖励尺度波动导致训练不稳rule_reward体现“规则奖励”思路答案对错和格式合规分开给分。参数上采样数 G 一般取 8 到 16太小优势估计噪声大太大显存吃不消格式奖励权重不宜过高否则模型会为了凑标签牺牲推理质量。提示纯 RL 路线在训练早期会出现输出变长、可读性下降的情况技术报告里也提到过语言混杂问题工程上通常靠加入少量冷启动数据来缓解。2.2 冷启动数据与 R1 的监督微调阶段R1-Zero 证明了纯 RL 能激发推理能力但它的输出可读性差、中英混杂直接拿去用体验不好。所以 R1 正式版本加了一步冷启动先收集一批高质量的、带完整思维链的样本对基座做一次监督微调让模型先学会“怎么把推理写清楚”再进入 RL 阶段。这一步的数据构造是关键常见来源包括人工标注、用已有强模型生成后筛选、以及对可验证任务做拒绝采样。拒绝采样rejection sampling是这里最实用的技巧对同一问题生成多条推理只保留答案正确且格式规范的样本。下面这段代码演示如何从候选里筛出可用数据def rejection_sample(candidates, gold, max_keep2): kept [] for c in candidates: # 只保留答案正确、且推理标签完整的样本 if extract_final(c) gold and has_reasoning_tag(c): kept.append(c) if len(kept) max_keep: break return kept逻辑说明extract_final负责从长文本里抽出最终答案has_reasoning_tag检查推理过程是否被正确包裹。参数max_keep控制每个问题保留几条一般 1 到 3 条太多会引入重复模式。冷启动数据量不需要很大技术报告强调的是“质量优先”几百到几千条精标数据往往比几万条噪声数据更有效。2.3 蒸馏把 R1 的推理能力搬到小模型技术报告里另一条被广泛复现的线是蒸馏。做法是用 R1 生成大量带推理过程的回答把这些数据拿去微调更小的稠密模型比如 7B、14B 级别。这样小模型不用自己跑 RL也能获得不错的推理表现。工程上这一步最容易被低估的是数据配比数学、代码、通用推理的比例会直接影响蒸馏后模型的能力分布。蒸馏数据类型典型占比作用注意事项数学推理40% 左右强化长链推理答案必须可验证代码任务30% 左右提升结构化推理需过滤无法运行的样本通用逻辑20% 左右保持泛化避免过拟合到模板格式样本10% 左右稳定输出结构不宜过多注意蒸馏数据里如果混入大量错误推理小模型会学到“自信地犯错”筛选环节不能省。3. 复现 DeepSeek-R1 思路时的关键参数与踩坑3.1 强化学习阶段的学习率与 KL 约束复现 RL 阶段时学习率是最容易翻车的参数。太大模型输出会迅速崩坏出现重复、乱码太小训练几乎不动。常见做法是把策略学习率设在 1e-6 量级并对参考模型加 KL 惩罚防止策略偏离基座太远。KL 系数一般从 0.01 到 0.04 之间调任务越开放系数可以适当调大。# 以常见 RL 训练框架的参数风格示意非某框架官方命令 python train_grpo.py \ --model deepseek-base \ --lr 1e-6 \ --kl_coef 0.02 \ --group_size 8 \ --max_new_tokens 4096 \ --reward_fn rule_reward逻辑说明--lr控制策略更新幅度--kl_coef约束新策略与参考策略的距离--group_size对应前面说的组内采样数--max_new_tokens决定推理链最长能写多长。参数之间是联动的max_new_tokens调大后显存和训练时间都会明显上升需要同步调整 batch 配置。3.2 奖励函数设计里的常见误用很多人复现时直接把“答案对”当成唯一奖励结果模型学会只写答案不写推理长链能力反而退化。正确做法是准确性奖励和格式奖励配合并且对推理过程做长度或结构上的软约束。另一个坑是奖励黑客如果奖励函数里用了容易被绕过的规则模型会找到捷径。比如用字符串匹配判答案时模型可能把多个候选答案都写上去碰运气。def safe_reward(answer, gold): final extract_final(answer) # 只取最后一个明确答案避免多答案碰运气 if final is None: return 0.0 return 1.0 if final.strip() gold.strip() else 0.0逻辑说明extract_final只取最后一个明确标注的答案减少模型堆砌答案的概率。参数上答案抽取规则要和评测脚本保持一致否则训练奖励和最终评测会对不上。3.3 训练不稳定的排查顺序RL 训练不稳定时建议按固定顺序排查而不是乱调参数。先看奖励曲线是否在上升如果奖励不动多半是奖励函数或数据有问题再看输出长度如果长度爆炸通常是 KL 系数太小或学习率太大最后看显存和吞吐判断是不是 batch 配置不合理导致梯度噪声过大。现象可能原因优先调整奖励不上升奖励函数判定错误检查答案抽取逻辑输出重复学习率过大降低 lr 或加大 KL长度爆炸KL 约束不足提高 kl_coef中英混杂冷启动数据不足补充格式样本提示排查时一次只改一个变量RL 训练对参数组合很敏感同时改多个参数会让你无法定位原因。4. 从技术报告到落地评测、蒸馏与工程取舍4.1 用可验证任务做快速验证想验证自己复现的推理模型有没有效果最省事的办法是选可自动判定的任务比如数学竞赛题、代码单元测试。这类任务不需要人工评分跑一遍就能看出差距。常见做法是固定一批测试题对比基座模型和训练后模型的通过率同时记录平均推理长度判断能力提升是来自真实推理还是单纯输出变长。def eval_pass_rate(model, dataset): correct 0 for item in dataset: out model.generate(item[question]) # 用与训练一致的抽取逻辑判分 if extract_final(out) item[gold]: correct 1 return correct / len(dataset)逻辑说明eval_pass_rate直接给出通过率extract_final必须和训练时一致否则评测结果不可信。参数上测试集要和训练数据去重避免模型靠记忆刷分。4.2 蒸馏小模型的取舍不是所有团队都有资源跑完整 RL蒸馏是更现实的选择。取舍点在于蒸馏能快速拿到一个推理能力不错的小模型但它无法超越教师模型的上限而且对教师数据的质量极度依赖。如果目标是特定垂直场景比如只做数学或只做代码蒸馏数据可以更聚焦效果往往比通用蒸馏更好。4.3 一个容易被忽略的技巧控制推理长度推理模型落地时输出太长会直接推高推理成本。一个实用技巧是在奖励里加入长度惩罚或者对超长输出做截断重采样。惩罚系数要小否则模型会为了短而牺牲正确率。实践中可以先不加长度约束跑一版观察正确率和长度的关系再决定惩罚力度。这个平衡点因任务而异数学题通常需要更长推理而简单分类任务短输出就够。把长度当成一个可调旋钮而不是固定规则是让 R1 思路真正落地到生产环境的关键一步。本文还有配套的精品资源点击获取