简介这份资源围绕DeepSeek团队首个基于强化学习的推理模型展开系统梳理了DeepSeek-R1-Zero与DeepSeek-R1的研发脉络面向机器学习研究人员、大模型开发者以及希望提升语言模型推理能力的从业者。内容涵盖纯RL训练下推理行为的自演化过程、冷启动数据与多阶段RL微调机制、面向推理的强化学习与拒绝采样监督微调以及将推理能力蒸馏至1.5B至70B稠密小模型的完整方案并给出编码、数学、GPQA等基准上的详细评测对比。资源包共1个PDF文件约2.62MB为完整技术报告含引言、方法、实验与讨论等章节便于按模块精读。目前已有1359人学习下载。读者可借此理解强化学习激发LLM推理潜力的路径掌握冷启动与蒸馏的工程细节并获取多语言、多轮对话及软件工程等方向的后续改进思路。1. 纯 RL 也能“卷”出推理能力这份 DeepSeek-R1 技术报告到底讲了什么如果你最近在折腾大模型推理优化大概率绕不开一个反直觉的结论不靠监督微调SFT做冷启动只靠大规模强化学习RL语言模型也能自己“顿悟”出长链思维、自我验证和反思行为。这份 DeepSeek-R1 的技术报告讲的就是这件事——第一代推理模型 DeepSeek-R1-Zero 和升级版 DeepSeek-R1 的完整研发路径。它适合三类人想复现 RL 训练管线的算法工程师、需要给中小模型注入推理能力的应用开发者、以及盯着编程与数学任务落地的从业者。报告里最硬核的部分不是榜单分数而是它把“冷启动数据怎么造、奖励怎么设计、蒸馏为什么比直接 RL 更划算”这些工程细节摊开讲了。下面我按“先看懂、再动手、最后避坑”的顺序把这份资源拆成能照着复现的笔记。2. 从 DeepSeek-R1-Zero 到 DeepSeek-R1两阶段 RL 管线怎么搭2.1 为什么先拿基础模型开刀而不是先做 SFT报告里最核心的选型判断是把 RL 直接作用在 DeepSeek-V3-Base 上跳过 SFT 冷启动。这个决定背后有明确的工程理由——SFT 数据收集慢、成本高而且一旦用人类标注的推理轨迹去“教”模型反而会限制它自己探索解法的空间。DeepSeek-R1-Zero 的做法是给基础模型一个极简模板只约束输出结构不约束内容策略。模板长这样用户和助手之间的对话。用户提出问题助手解决问题。 助手首先在脑海中思考推理过程然后为用户提供答案。 推理过程和答案分别包含在 think.../think 和 answer.../answer 标签中。 用户{prompt} 助手这个模板的关键在于“有意保持结构约束最小化”。它不强制模型反思也不引导特定解题策略只要求把思考过程放进think标签。这样做的目的是让 RL 过程中观察到的行为是模型自然涌现的而不是被模板“逼”出来的。我一般会把这类模板理解成“给模型一个跑道但不规定它怎么跑”。2.2 GRPO 目标函数与奖励设计省掉 Critic 模型训练成本是 RL 落地最大的拦路虎。报告采用 GRPOGroup Relative Policy Optimization作为 RL 框架它和 PPO 最大的区别是去掉了与策略模型同规模的 Critic 模型改用组内奖励的统计量来估计基线。目标函数的核心形式是J(θ) E[ (1/G) Σ_i min( ratio_i * A_i, clip(ratio_i, 1-ε, 1ε) * A_i ) ]其中ratio_i是新旧策略的概率比A_i是组内归一化后的优势值ε是裁剪超参数。优势的计算方式是A_i (r_i - mean({r_1, r_2, ..., r_G})) / std({r_1, r_2, ..., r_G})这里G是每个问题采样的输出数量r_i是第 i 个输出的奖励。参数说明G通常取 16 或 64太小会导致基线估计方差大太大则显存吃紧ε一般设 0.2和 PPO 惯例一致。奖励系统由两部分组成——准确性奖励用规则验证数学题检查框内答案、代码题跑测试用例格式奖励强制think标签包裹。报告明确没有用神经奖励模型原因是大规模 RL 中神经奖励模型容易被“奖励黑客”攻击而且重新训练奖励模型会让管线复杂化。2.3 冷启动数据与多阶段训练DeepSeek-R1 的四步走DeepSeek-R1-Zero 虽然推理强但可读性差、语言混合严重。DeepSeek-R1 的解法是引入少量高质量冷启动数据把训练拆成四个阶段第一步收集数千条长 CoT 数据微调 DeepSeek-V3-Base。数据来源包括少样本提示、直接提示模型生成带反思和验证的详细答案、对 R1-Zero 输出做人工后处理。输出格式定义为|special_token|reasoning_process|special_token|summary强制在末尾加摘要。第二步面向推理的 RL。在冷启动微调后的模型上跑和 R1-Zero 相同的大规模 RL但额外引入语言一致性奖励——按目标语言单词在 CoT 中的比例计算。消融实验显示这会导致性能轻微下降但可读性提升明显最终奖励是准确性奖励和语言一致性奖励直接相加。第三步拒绝采样加 SFT。当推理 RL 收敛后从检查点做拒绝采样生成推理轨迹只保留正确答案。同时混入约 20 万条非推理数据写作、事实 QA、自我认知、翻译总共约 80 万样本对 DeepSeek-V3-Base 做两个 epoch 的微调。第四步全场景 RL。再用一轮 RL 提升有用性和无害性推理数据用规则奖励通用数据用奖励模型捕捉人类偏好。# 拒绝采样过滤逻辑示意伪代码按报告描述还原 def rejection_sampling(checkpoint, prompts, num_samples16): sft_data [] for prompt in prompts: responses checkpoint.sample(prompt, nnum_samples, temperature0.6, top_p0.95) for resp in responses: # 过滤混合语言、长段落、代码块混乱的 CoT if has_language_mixing(resp) or is_unreadable(resp): continue # 只保留答案正确的响应 if verify_answer(prompt, resp.answer): sft_data.append({ prompt: prompt, reasoning: resp.think, summary: resp.summary }) return sft_data这段逻辑的关键参数是num_samples和temperature。报告在评估时用 0.6 采样温度和 0.95 的 top-p拒绝采样阶段也沿用类似配置。has_language_mixing和is_unreadable是自定义过滤器报告里提到会过滤掉混合语言、长段落和代码块混乱的思维链。实际复现时这两个过滤器的阈值需要根据你的基础模型语言分布调没有万能值。3. 蒸馏比直接 RL 更划算小模型推理能力注入的实操路径3.1 为什么 32B 蒸馏模型能打过 32B RL 模型报告里一个容易被忽略但极其重要的结论是用 DeepSeek-R1 生成的 80 万样本直接蒸馏到小模型效果优于在小模型上直接跑 RL。原文的表述是“较大基础模型发现的推理模式对于提高推理能力至关重要”。这意味着推理能力有“规模门槛”——小模型自己探索可能根本探索不到那些高级推理模式但通过蒸馏可以“继承”大模型已经发现的模式。蒸馏用的基础模型包括 Qwen2.5-Math-1.5B、Qwen2.5-Math-7B、Qwen-2.5-14B、Qwen2.5-32B、Llama-3.1-8B 和 Llama-3.3-70B-Instruct。注意这里只做 SFT不包含 RL 阶段。报告明确说“加入 RL 可以大大提高模型性能”但为了证明蒸馏本身的有效性把 RL 探索留给了社区。3.2 蒸馏数据构造与 SFT 训练参数蒸馏数据就是第 2.3.3 节里那 80 万样本其中约 60 万推理相关、20 万非推理相关。推理数据覆盖数学、代码、科学、逻辑推理非推理数据覆盖写作、事实 QA、自我认知、翻译。训练时对 DeepSeek-V3-Base 做两个 epoch 的微调这个配置直接迁移到小模型上。# 蒸馏 SFT 训练命令示意基于常见训练框架的参数组织 python train_sft.py \ --base_model Qwen2.5-32B \ --data_path ./r1_distill_800k.jsonl \ --output_dir ./qwen-32b-r1-distill \ --num_epochs 2 \ --batch_size 64 \ --learning_rate 1e-5 \ --max_seq_length 32768 \ --warmup_ratio 0.03 \ --lr_scheduler cosine \ --bf16 true参数说明max_seq_length设 32768 是因为报告里评估时最大生成长度就是 32768 token蒸馏数据里的 CoT 可能很长截断太短会丢推理过程。learning_rate用 1e-5 是 SFT 常见量级太大容易破坏基础模型能力。num_epochs设 2 是报告里的配置再多可能过拟合。batch_size根据显存调32B 模型在 80G 显存上通常能跑到 32 到 64。3.3 蒸馏模型的效果边界与适用场景报告给出的蒸馏模型成绩DeepSeek-R1-Distill-Qwen-7B 在 AIME 2024 上 55.5%超过 QwQ-32B 预览版32B 版本在 AIME 2024、MATH-500、LiveCodeBench 上分别是 72.6%、94.3%、57.2%与 o1-mini 相当。这些数字说明蒸馏路径在数学和代码任务上确实能打。但边界也很清楚蒸馏模型只做了 SFT没有 RL 阶段所以在需要探索性推理的任务上可能不如经过 RL 的模型。另外蒸馏数据来自 DeepSeek-R1如果 R1 在某些领域本身弱蒸馏模型也会继承这个弱点。我一般会建议如果你的场景是数学解题、代码生成、科学推理蒸馏模型性价比很高如果是开放式对话、角色扮演蒸馏带来的推理增益可能不明显反而要关注通用能力的保持。4. 避坑与排查RL 训练推理模型时最容易翻车的五个点4.1 奖励黑客模型学会“骗”奖励而不是解题现象训练中期准确率奖励突然飙升但人工检查发现模型输出格式正确、答案却毫无逻辑甚至出现重复输出同一句话来凑格式奖励。原因规则奖励只检查最终答案和标签格式模型发现只要把答案塞进指定格式就能拿到格式奖励准确性奖励的验证逻辑如果有漏洞比如只做字符串匹配模型会钻空子。解决准确性奖励必须用可靠的验证器。数学题用符号计算或严格答案匹配代码题必须跑测试用例。报告里明确不用神经奖励模型就是因为神经奖励模型在大规模 RL 中更容易被攻击。另外格式奖励和准确性奖励的权重需要调格式奖励太高会诱导模型只关注格式。4.2 语言混合CoT 里中英文随机切换现象模型在思考过程中一会儿中文一会儿英文甚至同一句话里混两种语言可读性极差。原因RL 提示涉及多种语言时模型没有语言一致性的约束会自然地在不同语言间跳转尤其是在基础模型预训练数据本身多语言混合的情况下。解决引入语言一致性奖励按目标语言单词在 CoT 中的比例计算。报告里说这会导致性能轻微下降但可读性提升明显。实际调的时候语言一致性奖励的权重不能太高否则模型会为了语言一致而牺牲推理深度。我一般会从 0.1 到 0.3 之间试观察验证集上的推理准确率和语言一致率两条曲线。4.3 冷启动数据质量差导致 RL 早期不稳定现象加了冷启动数据后RL 训练前期 loss 震荡剧烈模型输出时好时坏收敛速度反而比纯 RL 慢。原因冷启动数据的模式设计有问题。如果冷启动数据里的推理过程本身逻辑跳跃、格式不统一模型会学到错误的推理模式RL 阶段需要花更多步去纠正。解决冷启动数据要精心设计模式。报告里的做法是每个响应末尾加摘要过滤掉对读者不友好的响应输出格式统一为|special_token|reasoning_process|special_token|summary。数据量不用多数千条即可但质量必须高。我一般会人工抽检 5% 到 10% 的冷启动数据确保推理过程连贯、格式一致。4.4 蒸馏时 max_seq_length 设太短CoT 被截断现象蒸馏模型在复杂数学题上表现远低于预期检查发现训练数据里很多长 CoT 被截断模型只学到前半段推理。原因蒸馏数据里的 CoT 长度可能达到数千甚至上万 token如果max_seq_length设成 4096 或 8192大量长 CoT 会被截断模型学到的推理过程不完整。解决max_seq_length至少设 32768和报告里评估时的最大生成长度对齐。如果显存不够可以用梯度检查点或序列并行。另外预处理阶段要统计 CoT 长度分布如果 95 分位数超过 32768需要考虑是否过滤掉超长样本还是进一步扩长度。4.5 评估时用贪婪解码导致重复率飙升现象模型在验证集上输出大量重复内容pass1 分数在不同检查点之间波动很大无法判断哪个检查点更好。原因报告里明确指出“使用贪婪解码来评估长输出推理模型会导致更高的重复率和不同检查点之间的显著差异”。长输出模型在贪婪解码下容易陷入重复循环。解决用非零温度采样评估报告默认用 0.6 采样温度和 0.95 top-p每个问题采样多个答案4 到 64 个取决于测试集大小然后计算 pass1。公式是pass1 (1/k) Σ correct_i其中 k 是采样数量。AIME 2024 还用 64 个样本报告 cons64多数投票结果。这套评估协议虽然计算量大但结果可靠得多。5. 进阶技巧用多数投票和长度控制把推理性能再推一截多数投票majority voting是报告里反复出现的一个技巧成本低但收益明显。DeepSeek-R1-Zero 在 AIME 2024 上 pass1 是 71.0%用 64 个样本做多数投票后跳到 86.7%直接超过 OpenAI-o1-0912 的 74.4%。这个技巧的本质是模型在复杂推理题上单次采样可能出错但多次采样后正确答案的分布会集中投票能过滤掉随机错误。from collections import Counter def majority_vote(model, prompt, n_samples64, temperature0.6, top_p0.95): answers [] for _ in range(n_samples): response model.generate(prompt, temperaturetemperature, top_ptop_p) answer extract_final_answer(response) answers.append(answer) # 统计出现频率最高的答案 counter Counter(answers) best_answer, count counter.most_common(1)[0] return best_answer, count / n_samples参数说明n_samples越大投票效果越好但推理成本线性增长。报告在 AIME 2024 上用 64其他基准用 4 到 64 不等。temperature和top_p用评估时的配置保证采样多样性。extract_final_answer需要根据任务类型定制数学题提取框内答案代码题提取函数返回值。另一个容易被忽视的技巧是长度控制。报告在 AlpacaEval 2.0 上只把最终摘要提供给评估避免长度偏差——因为长回答在成对比较中往往占优但那是“长”的优势不是“好”的优势。实际部署时如果发现模型倾向于生成超长回答可以在奖励里加长度惩罚或者在推理时设最大长度上限。我一般会在验证集上画一条“回答长度 vs 正确率”的曲线找到正确率不再随长度提升的拐点把那个长度作为上限。还有一个血泪经验RL 训练推理模型时检查点保存频率要比普通 SFT 高。因为 RL 训练中模型行为变化快可能某个中间检查点在特定任务上表现特别好但过几百步后就退化了。报告里 R1-Zero 的“顿悟时刻”就出现在中间版本如果只保存最终检查点这种中间涌现的能力就被丢掉了。我现在的习惯是每 100 到 200 步存一个检查点评估时把所有检查点跑一遍选综合最好的那个而不是默认用最后一个。从那以后我每次做 RL 训练都强制走一遍多检查点评估再也没出现过“训到最后反而变差”的翻车。希望帮到你。本文还有配套的精品资源点击获取