训练时扩展：STaR、GRPO、DAPO让小模型匹敌大模型

如果你搜过 STaR 这个缩写，大概率会先看到 GitHub 的 star 数量；但在斯坦福 CS329A《自我改进 AI 智能体》第六讲里，STaR 是 Self-Taught Reasoner——自我训练的推理者。这一讲把 STaR、GRPO、DAPO 放在“训练时扩展，小模型匹敌大模型”这个标题下，在我看来是整个课程里很值得反复读的一讲。

它真正触动我的，是对“小模型”的重新理解。过去我们默认模型不够强就换更大的底座：7B 不行上 13B，13B 不行上 70B。可当训练阶段加入了自我生成、自动筛选、策略优化，小模型不再只是被动吸收语料。它开始像带教老师一样，自己出题，自己答题，自己挑错题，再用错题反复训练自己。结果就是，在数学推理、代码这类答案可验证的任务里，一个经过良好训练时扩展的小模型，完全有可能追平甚至超过没有同等训练的大模型。

这篇文章想把这套思路拆开：先看训练时扩展到底改了什么，再逐一盘 STaR、GRPO、DAPO，最后聊怎么落到自己的实验里。

1. 先把“小模型匹敌大模型”这句话拆开看

1.1 规模不是唯一变量

长期以来，模型能力增长靠的是“参数扩展”。模型参数量上去，训练数据量上去，算力投入上去，能力就会涨。这条路很有效，但代价也很直接：显存变大、部署变贵、推理变慢。对一个只有一两家 GPU 资源的小团队来说，想要追平一个大模型，几乎不可能。

但规模不是唯一变量。

一个模型在下游任务上的表现，取决于两件事：第一，它有没有学到相关知识；第二，它能不能在需要的时候把知识组织成正确的推理过程。大模型学到的知识更多，但“调用知识的方式”并不一定最优。训练时扩展改变的是第二件事。

我在实际做模型评估时经常看到一种现象：小模型如果只是用普通 SFT 训练，遇到复杂问题会有一个漂亮的推理开头，然后在中间某一步突然崩掉。它并不是完全不会这道题，而是缺少把多个步骤串联起来的能力。这时如果只换更大的模型，当然有效，但成本很高。

训练时扩展提供了另一条路径：不换模型，但改变训练过程。让模型自己在训练阶段生成大量推理链，用自动验证器筛掉错误的，再把正确的推理链作为训练数据喂回去。相当于把一次静态培训，变成一次次带反馈的刻意练习。

1.2 训练时扩展到底在扩展什么

先做一个概念区分：

• 参数规模扩展：增加模型参数量，让模型容量更大。
• 训练数据扩展：增大语料覆盖，让模型见到的知识更多。
• 训练时扩展：在固定模型规模下，把更多计算投入训练阶段内部的生成、筛选、强化学习优化，让模型更擅长从已有知识中推演出正确答案。

训练时扩展不改变模型每个前向推理的计算量，但改变了权重更新时模型“看到什么”和“学到什么”。

可以类比成两个同样聪明的学生。一个只背标准答案，另一个大量做错题、看解析、复盘方法。最终考试时，第二个学生的优势不在记忆力，而在面对新题时的推理稳定性。训练时扩展做的就是“有针对性的错题本训练”。

这正好解释为什么小模型能匹敌大模型：它们缺的往往不是知识容量，而是把知识组织成推理路径的训练信号。STaR、GRPO、DAPO 都是在训练阶段生成这种信号。

1.3 为什么 STaR、GRPO、DAPO 适合放在同一讲

这三个算法不是并列的三种工具，而是自我改进训练流水线上的三个阶段。

STaR 解决的是“怎么自动造出高质量思维链数据”。在人类标注推理链太贵、太慢的现实下，它让模型自己生成候选，再用答案正确性做过滤器。

GRPO 解决的是“如何用可验证反馈做强化学习”。它不再需要像 PPO 那样维护一个巨大的价值模型，而是用同一个 prompt 下的一组样本算相对优势，直接驱动策略更新。

DAPO 解决的是“强化学习从单机实验走向大规模训练时，稳定性怎么保证”。它针对 GRPO 在大规模场景下的熵塌缩、无效样本、裁剪干扰等问题做了工程化修正。

换句话说，STaR 是数据层的自我改进，GRPO 是优化层的自我改进，DAPO 是工程层的自我改进。三者放在一起，才能构成完整的“自我改进 AI 智能体”训练闭环。

2. STaR：从“自我生成正确推理链”开始

2.1 最小流程

STaR 的基本思想并不复杂。它假设我们有一堆问题，每个问题有标准答案，但人类没有给推理过程。模型要做的，是自己把过程补出来。

一轮 STaR 通常是这样：

1. 用少量带标注推理链的数据微调一个基座模型，让模型先具备最基本的推理格式。
2. 拿大量只有问题和答案的数据，让模型生成推理链和最终答案。
3. 用规则验证器判断答案是否正确。
4. 只保留答案正确的样本，丢弃错误样本。
5. 在保留的正确推理链上继续微调模型。
6. 重复多轮，每轮之后模型的正确率理论上会提升，也有能力挑战更难的题。

用一个伪码示意，大概是这样的结构：

# 示意：STaR 的一轮迭代循环，不是正式训练脚本 for round_idx in range(max_rounds): generated = model.generate(prompts, temperature=0.8, top_p=0.95) kept = [] for prompt, response in zip(prompts, generated): answer = extract_answer(response) if verify_answer(answer, prompt["expected_answer"]): kept.append({"prompt": prompt["question"], "response": response}) if len(kept) < min_safe_samples: break trainer.train(kept, epochs=2)

这里最关键的判断条件是verify_answer。验证器设计得好不好，直接决定数据飞轮能不能转起来。

2.2 为什么它能让小模型变强

STaR 的价值不在“让模型自己生成”，而在“自动筛选后形成数据飞轮”。

每次迭代，模型在问题空间里做一次探索，生成一批候选推理链。验证器像阅卷老师一样淘汰错误样本，只留下能得出正确答案的推理链。这些高质量的推理链再被训练回模型。模型变强之后，又能解锁更难的问题。这样循环往复，模型会在某个任务子集上越来越强。

这等于给训练数据做了一次非常强的信噪比过滤。普通 SFT 数据里有大量低质量推理过程，模型学会的可能是“啰嗦但不严谨”的表达。STaR 只保留“最终能得到正确答案”的推理链，相当于让模型反复阅读高分答卷。

但这里有一个容易忽略的冷启动问题：如果模型初始能力太弱，对所有问题都生成错误答案，那过滤之后一条有效样本都没有，飞轮根本转不起来。

常见的解法是在 STaR 流程里加入 rationalization：当模型生成错误答案时，不直接丢弃，而是把正确答案给模型，让它反推一个看似合理的推理链，再挑选其中比较合理的一小部分作为种子数据。这相当于先把一个成绩一般的学生放进“有答案的练习册”情境里，让他先学会模仿，再慢慢过渡到独立解题。

注意：冷启动阶段不要追求一步到位。先用少量题目、理性化答案把模型基础推理格式稳定下来，再逐渐放开难度，数据飞轮反而更稳。

2.3 一个最小实验的判断标准

不是所有用 STaR 的实验都能成功。我一般会用三个标准判断一轮 STaR 是否有效：

• 验证集准确率到底有没有提升。只看训练集生成准确率没有意义，因为模型可能过拟合了训练题。
• 生成的推理链有没有保持多样性。如果一轮迭代后模型开始疯狂输出同一套模板，说明探索性在下降。
• 困难题目的通过率是否在变化。如果只提升简单题，说明训练数据难度分布有问题。

如果连续三轮迭代，验证集准确率没有任何变化，通常不是算法有什么神秘问题，而是任务本身太难、验证器设计有问题，或者基座模型能力起点太低。这时候应该先调整任务难度或验证器，而不是盲目增加迭代轮数。

3. GRPO：用组内相对比较替代价值模型

3.1 传统 PPO 在可验证任务里有点笨重

GRPO 的完整名称是 Group Relative Policy Optimization，分组相对策略优化。它的出现，很大程度上是因为 PPO 在 LLM 强化学习场景里太笨重了。

PPO 在做 RLHF 时，通常要同时维护四个模型：Actor 模型、Critic 价值模型、Reward 奖励模型、Reference 参考模型。Critic 模型要预测每个 token 的未来总回报，但训练一个稳定的价值模型非常难。对于数学题、代码这类有标准答案的任务，奖励本来就是规则算出来的，根本不需要用一个神经网络去预测未来的累计奖励。

而且价值模型预测不准时，优势估计会引入大量方差，训练很快就震荡。GRPO 的思路很简单：既然同一个问题下可以采样多个候选答案，那直接把这几个候选的奖励做组内比较，不就行了？

3.2 GRPO 的核心操作

GRPO 的基本流程是：

1. 给定一个 prompt。
2. 当前策略模型采样 G 条 response。
3. 用规则验证器或奖励模型给每条 response 打分。
4. 在组内对奖励做归一化，得到相对优势。
5. 用这个优势驱动策略更新：好的 response 概率变大，差的 response 概率变小。

归一化方式通常是：

advantage_i = (reward_i - group_mean) / (group_std + eps)

公式看起来简单，但它隐含了一个重要变化：策略更新不再依赖绝对奖励值，只依赖样本在组内的相对排序。即使整个奖励模型有系统性偏差，只要同一个 prompt 下的候选排名相对合理，GRPO 仍能学习到正确的策略方向。

一个极简的训练循环示意如下：

# 示意：GRPO 单 batch 更新逻辑，简化版本 responses = model.sample(prompt, n=G) # 当前策略采样 G 条 rewards = reward_fn(prompt, responses) # 规则校验或奖励模型 group_mean = rewards.mean() group_std = rewards.std() + 1e-4 advantages = (rewards - group_mean) / group_std # 再让 advantage 通过 PPO 式的 ratio * advantage 更新策略 # 具体实现里通常还会加 KL 正则，防止策略偏离参考模型太远

这个机制对可验证任务尤其友好。数学题的答案正误是确定的，组内相对优势基本没有歧义。模型不需要阴谋式地学习“哪种话术更容易讨好奖励模型”，只需要学习“哪个推理过程更容易得到正确答案”。

3.3 参数选择与工程注意点

GRPO 的工程参数不算多，但都很敏感。

组大小 G 是第一个关键参数。G 太小，组内均值方差噪声大，优势估计不稳定；G 太大，显存和采样成本按比例涨。常见实践里可以先从 4 或 8 开始，观察 reward 分布是否已经有区分度。

第二个关键是 KL 约束。如果完全放开策略更新，模型会很快跑到奖励分布边缘，生成一些“碰巧能得高分但人类读起来很奇怪”的文本。通常会在 GRPO 训练里加一个对参考模型的 KL 惩罚，避免策略漂移太严重。

第三个关键是奖励函数本身。GRPO 只能放大奖励信号，不能凭空创造奖励区分度。如果一组样本全是 0 分或全是满分，组内归一化之后优势照样趋近于零，梯度信息非常弱。所以在跑 GRPO 之前，先统计一下当前采样池里奖励是否有梯度，是很重要的一步。

GRPO 适合先跑通，再谈规模化。

4. DAPO：当自我改进训练进入规模阶段

4.1 大规模强化训练为什么会不稳定

GRPO 在单卡、小规模实验里表现很好，但一旦把采样数量、batch size、训练轮数拉上去，就会碰见一些在论文里不那么明显的问题。

最常见的是熵塌缩。模型在强化学习过程中，会迅速把输出分布集中到少数几个模板上。这种塌缩在训练曲线上看起来像 loss 在下降，但其实是模型的探索性没了。一旦遇到训练分布范围外的新题，模型很难通过多步推理找到答案。

第二个问题来自有效样本稀疏。对困难任务来说，模型多次采样都可能得不到正奖励。如果把这些无效样本全部送进梯度计算，不仅浪费算力，还会让 loss 被“无意义样本”主导。

第三个问题来自 clip 机制。PPO/GRPO 里通常会限制策略更新幅度，目的是防止策略一次跳太远。但这种统一约束会把正优势和负优势放在同一个框架里处理，结果可能是：该加的加不上去，该减的也减不下来，整个优化过程变得保守又缓慢。

第四个问题是序列长度带来的噪声。一个长回答里，可能只有几个 token 对最终奖励负责。如果按完整序列算 loss，相关 token 的梯度会被大量无关 token 稀释。

4.2 DAPO 的四个关键修正

DAPO 这个名字，通常被认为强调“解耦裁剪”和“动态采样”。它不是在理论层面另起炉灶，而是针对上述生产环境问题，做了一组工程化修正。

第一个修正：解耦裁剪。它对正优势样本和负优势样本使用不同的裁剪处理，避免同一个 clip 边界同时约束“应该增强”和“应该削弱”的 token。这样做的好处是保留探索性，避免策略很快变成复读机。

第二个修正：动态采样。在每次更新前，筛选掉那些 reward 全部为 0 或无法贡献梯度的 prompt。简单说，只让真正有效的样本参与策略更新，计算资源集中在能学习的部分。

第三个修正：过采样。对困难 prompt 增加采样次数，提高有效样本覆盖率。困难问题一次采样拿不到正奖励很正常，但多采样几次，总有机会拿到能产生梯度信号的样本。

第四个修正：token 级 loss 裁剪。在 token 粒度上做 loss 裁剪，避免长序列中无关 token 稀释关键 token 的学习信号。这相当于让模型在长回答里也能精准识别“哪个思考步骤是真正起作用的”。

示意配置如下，具体参数要根据环境和任务调整：

{ "decoupled_clip": true, "dynamic_sampling": true, "oversample": 8, "token_level_clip": true, "kl_coef": 0.01 }

注意：DAPO 的配置并不是拿到手就能直接复制。首先要跑一个小规模基线，确认 reward 分布有区分度，再逐步把采样数和训练规模拉大。

4.3 落地的监控指标

训练时扩展最怕的就是“看训练曲线没问题，但模型实际能力没涨”。我建议至少盯住五个指标：

• policy entropy：是否在快速下降。如果前几百步就塌到接近 0，说明探索性不够。
• 有效样本率：每个 prompt 的采样结果中，有多少比例能产生正 reward。
• advantage 分布：是否长期集中在 0 附近。如果是，奖励函数区分度不够。
• KL 距离：策略模型离参考模型是否越来越远。太远容易失控。
• 训练集与验证集同向性：训练 reward 上涨的同时，验证集准确率也必须同步变化。不同步就是过拟合或奖励黑客。

把这些指标做成一张监控表，比单看 loss 曲线有用得多。

5. 三套算法的关系：一条完整的自我改进生产线

5.1 生成-筛选-优化-再生成

把 STaR、GRPO、DAPO 放到同一条生产线上，理解会更具体。

第一步，任务定义。选一个答案可验证的任务。数学题、代码题、结构化抽取都可以。

第二步，探索生成。让模型以较高温度采样，生成多种推理链。STaR 在这里负责尽可能多地产生候选。

第三步，自动筛选。用规则验证器、单测用例或奖励模型评估候选，筛掉错误答案。STaR 的过滤逻辑和 GRPO 的组内奖励都可以在这一层发挥作用。

第四步，策略优化。GRPO 把筛选结果转成相对优势，驱动策略更新；DAPO 保证这一步在大规模训练时不会因为熵塌缩、无效样本、裁剪干扰而崩掉。

第五步，再生成。模型变强后，重新去生成更难样本，开启下一轮循环。

很多团队只实现了其中一两层，就误以为把整套自我改进跑通了。实际上，真正稳定的自我改进，必须同时考虑数据筛选、策略优化和工程稳定性三层。

5.2 什么时候选 STaR，什么时候选 GRPO/DAPO

这三者并不冲突，但切入点不同。

如果团队没有 RL 训练基础设施，只有微调脚本，最合适的切入点是 STaR。它结构简单，GPU 要求低，不需要维护 reward model，也不需要处理策略梯度稳定性。缺点是上限有限，因为它在本质上是过滤后的 SFT，不是真正的强化学习。

如果团队已经有可验证任务，计算资源也够，GRPO 是更合适的方向。它让模型在奖励信号的引导下自主学习，理论上比纯 SFT 有更高的上限。缺点是需要处理强化学习的不稳定问题。

如果把训练规模推得很大，或者想把自我改进做成长期迭代机制，DAPO 里的思路很值得参考。它不一定适合所有人直接复现，但它指出了规模化 RL 训练里最值得关注的四个细节。

我的选择逻辑很朴素：先跑通 STaR 收集数据，再上线 GRPO 做策略优化，最后根据训练稳定性决定是否引入 DAPO 式修正。

5.3 一个可复用的取舍框架

在决定要不要用训练时扩展这套方法之前，可以拿这个清单过一遍：

1. 任务结果是否可以被自动校验？不能校验，后面所有筛选和奖励都是空中楼阁。
2. 基座模型是否具备基础推理能力？如果连最简单的提示都做不了，飞轮转不起来。
3. 算力能支撑多少次采样？训练时扩展的本质是用算力换训练信号，采样量太小没有效果。
4. 团队是否愿意维护评估集和监控指标？没有评估集，你只是在自嗨。

四个条件里至少满足前三个，才值得投入。

6. 自己动手跑一个最小实验

6.1 实验配置建议

第一次做这类实验，不要直接挑战大规模 RL。我建议用以下配置起手：

• 数据：500 到 2000 道数学题，答案必须能通过规则验证。
• 基座模型：7B 到 14B，优先选择本身已经有一定推理能力的开源模型。
• 采样参数：temperature 0.7 到 0.9，top_p 0.9 到 1.0，保证多样性。
• 训练方式：先用 LoRA 微调，成本低、实验周期短。
• 验证器：不要只看字符串匹配，要能提取答案并做数值比较。
• 评估：固定一个测试集，每轮迭代之后跑 few-shot 评估。

一个最小流程大概是：

# 示意命令结构，具体依赖以实际环境为准 python generate_samples.py --model your_base_model --data train.jsonl --temperature 0.8 --num_samples 4 python filter_and_export.py --input samples.jsonl --output high_quality.jsonl python train_lora.py --model your_base_model --data high_quality.jsonl --epochs 2 python evaluate.py --model your_lora_model --test test.jsonl

跑通之后，再逐步替换掉手工流程。

6.2 结果怎么评估

不要只看“训练集准确率上升了”就宣布成功。训练时扩展最常见的错觉，是模型已经过拟合了训练题格式，换个问法就崩。

我一般会关注四个维度：

• 测试集准确率是否提升。
• 模型能否用多种路径解同一道题，而不是所有输出都变成相似模板。
• 对同一道题换表述后，结果是否稳定。
• 困难子集是否在迭代中逐步可解。

这四个维度的变化，比训练曲线更能说明模型是否真正变强。

6.3 排查链路

实验出问题时，按顺序排查，不要上来就调参：

1. 有效样本率是否为 0。先看验证器和 prompt，不要怪模型。
2. 模型是否在生成阶段就开始重复。如果是，先提高 temperature，或检查是否过早进入低探索状态。
3. 训练后测试集不涨。看训练样本是否过少、验证器是否太宽松，或者模型是否过拟合了训练题格式。
4. training loss 下降但评估掉点。大概率是训练分布和测试分布不一致，需要增加难度梯度，不能只刷易题。
5. 奖励分数越来越高，但下游质量变差。优先怀疑 reward hacking，检查验证器是不是被某种表面特征骗了。

这组排查链路，基本能覆盖第一轮实验里绝大多数问题。

7. 适用边界：什么任务值得这样训练，什么任务不要碰

7.1 适合的场景

训练时扩展最适合的场景，是那些“答案可以被自动判断是否对”的任务。

典型例子是数学题。答案是否正确，可以通过数值比较自动判断；代码题可以通过编译和单测判断；结构化抽取可以通过字段匹配或规则判断；逻辑推理题也可以设计比较确定的对错标准。

这类任务有一个共同特点：奖励信号不需要主观人工判断。模型生成的推理链错了就是错了，对照答案就能看出来。这让自动筛选和强化学习都有了可靠的指挥棒。

另一个适合场景是算力有限、但希望垂直场景效果更好的团队。与其花很高成本部署一个 70B 模型，不如用一个 7B 模型在特定任务上做深度的训练时扩展，把模型练到在垂直任务上能打。

7.2 不适合的场景

主观创意、情感分析、开放对话这类没有明确“正确答案”的任务，不适合直接用 STaR/GRPO/DAPO。原因很简单：你无法设计一个可靠的自动验证器，去判断一段开放文本是否“足够好”。强行用奖励模型，也会因为奖励信号的噪声太大，导致训练不稳定。

一次性任务也不适合。训练时扩展的前期投入包括数据准备、验证器开发、采样、训练、评估。如果任务只跑一次，还不如直接让大模型做推理时采样。只有当训练收益可以被多个任务或长期迭代摊薄时，投入才划算。

没有评估集的任务，也不要碰。没有评估集，你根本无法判断模型是在变强，还是在过拟合训练题。最后只能靠感觉调参，这是比没有训练更可怕的结果。

安全对齐要求极高的场景，要格外谨慎。训练时扩展可以让模型在某个指标上飞速提升，但如果奖励函数覆盖不全面，模型学会的可能是围绕奖励取巧，而不是真正理解规则。这类场景需要额外加入安全约束、人工抽检和细粒度反馈。

7.3 训练时扩展和推理时扩展不是一回事

标题里的“训练时扩展”很容易被人误解成“推理时多跑几次”。这是一个需要区分的点。

推理时扩展，或者叫测试时扩展，是指在服务阶段让模型多采样几次、用搜索或投票等方式选择最佳结果。它不改变模型权重，只是用更多推理计算换取更好输出。

训练时扩展则发生在权重更新阶段。模型通过自我生成、自动筛选、强化学习优化，最终把能力写进了权重里。推理时模型仍然是单次前向输出，但推理质量已经因为训练过程而提升。

两者可以结合。先通过训练时扩展让模型在某个任务上变强，再通过推理时采样投票进一步提升稳定性。但不要把二者混为一谈，因为它们的成本模型和工程实现完全不同。

回到开头那个问题：小模型为什么能匹敌大模型？关键不在“小”，而在“是否被正确训练”。一个 7B 模型，如果在训练阶段完成了几万次自我生成、自动筛选和策略优化，它对某个任务的熟练程度，完全可以超过一个虽然参数更大但没有针对性训练的大模型。

我现在判断一个任务值不值得投入训练时扩展，会先卡一个标准：能不能被自动验证。如果能，就值得用 STaR 收集数据，用 GRPO 做策略优化，再用 DAPO 的方式解决规模化稳定性问题。这三个算法给我的真正启发，不是“哪个方法更好”，而是它们把“能够被验证”变成了“可以被学习”。模型的能力上限，不只是参数上限，也是训练方法的上限。