这次我们来看斯坦福 CS329A《自我改进 AI 智能体》第六讲的核心内容：训练时扩展（Test-Time Training / Training-Time Scaling）如何让小模型在推理任务上逼近甚至匹敌大模型。课程重点讲了三个算法——STaR、GRPO、DAPO，以及它们背后的强化学习训练链路。
这一讲的信息量很大，而且非常实用。如果你正在做开源模型的推理能力增强、数学推理 / 代码生成任务，或者在纠结“小模型到底能不能通过训练策略追平大模型”，这篇文章可以直接收藏。我会把课程主线拆成三部分：训练时扩展解决什么问题；STaR、GRPO、DAPO 三个算法的设计思路和区别；以及这套方法落到工程上时，环境准备、训练配置、效果验证和常见坑分别是什么。
外部推理模型往往存在三个问题：一是调用成本高，二是延迟不可控，三是在特定垂直场景下效果不稳定。而训练时扩展的核心思路是：与其在推理时依赖更大的模型，不如在训练阶段让模型通过自我生成、自我评判、自我改进来提升能力。这个思路在数学推理、代码生成、Agent 任务规划等场景里已经被验证有效。
需要先说明一点：本文是基于课程公开材料与技术原理做的梳理，不包含任何未经确认的本地实测数据。文中涉及的显存占用、训练时长、收益曲线等，都需要按实际代码库和硬件环境重新验证。
1. 核心能力速览
| 能力项 | 说明 |
|---|---|
| 课程来源 | 斯坦福 CS329A《自我改进 AI 智能体》第六讲 |
| 核心主题 | 训练时扩展（Training-Time Scaling）与小模型推理能力增强 |
| 关键算法 | STaR、GRPO、DAPO |
| 适用任务 | 数学推理、代码生成、Agent 规划、多步决策 |
| 模型规模 | 重点讨论小模型（如 1B~7B 级别）通过训练策略匹敌大模型 |
| 训练范式 | 自我生成理由 -> 过滤正确样本 -> 策略优化迭代 |
| 推理阶段 | 不需要额外的大模型参与，运行的是训练好的小模型 |
| 显存需求 | 取决于基座模型和训练框架，需按实际环境测试 |
| 奖励信号 | 可验证奖励（答案正确性 / 测试用例 / 规则）优于模型评判 |
| 接口能力 | 训练完成后可导出为标准 HF 模型，接入推理服务 |
| 批量任务 | 训练阶段支持批量采样和批量过滤，适合离线任务 |
从材料看，这一讲的核心主张是：推理能力的提升并不只能靠“把模型做大”，还可以靠“把训练策略做对”。STaR、GRPO、DAPO 三个算法分别代表了这个方向的三个关键节点。
2. 三个算法拆解：STaR、GRPO、DAPO
2.1 STaR：自我训练推理器
STaR 全称 Self-Taught Reasoner，是训练时扩展最早期的代表性方法之一。它的思路非常直接，可以概括为四步循环：
- 让模型对训练问题生成推理过程和答案。
- 根据最终答案是否正确来过滤样本。
- 把生成正确的推理样本混入训练集，继续微调模型。
- 重复这个过程，模型逐步学会产生更可靠的推理链。
STaR 的核心贡献在于证明了“自我生成 + 正确性过滤”就能持续提升推理能力，而不需要额外的人工标注推理过程。原始训练数据只需要问题和答案，推理链由模型自己生成。
这个方法的局限也很明显：如果模型能力太弱，生成正确推理的概率很低，过滤后的有效样本会非常少，训练效率不高。所以 STaR 后续还有一些改进版本，例如对生成失败的样本提供答案提示后重新生成，或者混合多个模型生成结果来增加多样性。
从工程角度看，STaR 最适合作为基线方法。它的实现成本低，训练循环容易理解，适合先用它验证“训练时扩展是否对当前任务有效”。
2.2 GRPO：去掉 Critic 模型的策略优化
GRPO 全称 Group Relative Policy Optimization，是 DeepSeekMath 中提出的强化学习训练算法。它在 PPO 基础上做了一处关键简化：不再训练一个独立的 Critic 价值模型，而是通过组内相对比较来计算优势函数。
具体做法是：对同一个问题采样一组回答，然后根据奖励对这组回答排序或打分，用“当前回答在组内的相对位置”代替绝对价值函数。这样做有几个明显的好处：
- 省掉了 Critic 模型的训练和推理开销，显存和算力需求明显下降。
- 优势估计完全基于组内相对比较，对奖励尺度不敏感，训练更稳定。
- 更适合使用规则奖励的场景，比如数学答案匹配、代码测试用例通过率。
GRPO 的损失函数仍然保留了策略比率和裁剪机制，但去掉了价值函数项。这个设计让强化学习训练可以更轻量地跑在小规模模型上。
从这一讲的角度看，GRPO 是训练时扩展里最值得工程化的算法之一。它解决了策略优化阶段“需要额外模型参与”的问题，让小模型训练链路更加闭环。
2.3 DAPO：开放环境下解决 GRPO 的不稳定问题
DAPO 全称 Decoupled Alignment and Policy Optimization，是 2025 年提出的改进算法，重点关注 GRPO 在开放任务和长时间推理场景中的不稳定问题。
课程中重点提到 DAPO 的几个改进点：
- Clip-Higher：放宽策略更新的上限裁剪，避免模型在探索阶段因为裁剪过于激进而停止改进。
- 动态采样：根据模型当前能力动态调整采样策略，避免无效样本占比过高。
- Token 级策略梯度损失：让模型在长推理链的每一步都能获得更细粒度的更新信号，而不是只在整个序列结束后统一更新。
- 过短惩罚：鼓励模型生成更完整的推理链，防止模型学会“偷懒式”的短回答。
DAPO 的意义在于它把训练时扩展从“能跑”推向了“稳定地跑”。在数学推理、代码生成这类奖励信号清晰的任务上，DAPO 的收敛速度和最终效果通常优于原始 GRPO。
2.4 三个算法的关系
| 算法 | 核心思路 | 关键改进 | 适用阶段 |
|---|---|---|---|
| STaR | 自我生成 + 正确性过滤 + 迭代微调 | 无需人工标注推理链 | 冷启动、baseline |
| GRPO | 组内相对优势替代 Critic 模型 | 去掉价值模型，降低 RL 成本 | 策略优化主阶段 |
| DAPO | 改进 GRPO 在开放任务中的稳定性 | Clip-Higher、动态采样、Token 级 loss | 长推理、复杂任务 |
三个算法不是互斥关系，而是可以组合成一条完整训练链路：先用 STaR 让模型学会生成基础推理链，再用 GRPO 或 DAPO 做策略优化，最后用过滤后的高质量样本做一轮监督微调。
3. 训练时扩展 vs 推理时扩展
这一讲的核心概念是“训练时扩展”。为了理解它，需要先把它和“推理时扩展”区分开。
推理时扩展的代表方法是 Chain-of-Thought 和 Best-of-N 采样。它的思路是：在推理阶段让模型生成更多候选推理链，然后选一个最好的。这种方式不需要改动模型权重，但每次推理都要付出额外计算成本，而且如果模型本身不会生成高质量推理链，采样再多也意义不大。
训练时扩展的思路则完全不同。它把“生成更好推理链”的能力直接写进模型权重里。在训练阶段，模型反复生成推理链、接收正确性反馈、更新策略。训练完成后，模型本身就具备更强的推理能力，推理时不再需要额外的大模型参与。
从成本结构来看：
- 推理时扩展：推理成本随采样数量线性增长，适合偶尔需要高准确率的场景。
- 训练时扩展：训练成本集中在一段时间内，推理时成本与普通模型一致，适合高频调用场景。
课程观点是这两者可以结合。如果预算充足，可以在训练时扩展的基础上再叠加推理时 Best-of-N 采样，效果通常优于单独使用任何一种。
4. 小模型凭什么匹敌大模型
这一讲最有冲击力的结论是：小模型在训练时扩展之后，可以在特定任务上匹敌大模型。这个结论背后有三个技术支撑。
第一，任务难度集中在特定类型时，小模型的容量瓶颈并不明显。数学竞赛题、代码题、逻辑推理题，这些任务的难度主要来自推理链的长度和正确性，而不是知识广度。小模型在知识储备上不足，但通过大量正确推理链的训练，可以学会“如何推理”这件事本身。
第二，可验证奖励让训练信号更干净。大模型评判可能存在偏差，但数学答案是否匹配、代码能否通过测试用例，这类信号是客观的。小模型只要能从训练数据中学会“哪种推理方向更容易通向正确答案”，能力就会快速提升。
第三，强化学习阶段允许模型探索超出监督数据范围的推理路径。监督微调只能让模型模仿训练数据中的推理方式，而 RL 阶段模型可以自由尝试新的推理链，只要最终答案正确就给予正向奖励。这个探索空间是训练时扩展能够超越传统微调的关键原因。
从实际效果看，训练时扩展并不能让小模型在所有任务上都追平大模型。它更适合任务结构清晰、奖励信号可验证、推理链可复现的场景。
5. 实验环境准备与前置条件
如果你打算复现 STaR、GRPO 或 DAPO 的训练流程，需要准备以下环境。
5.1 硬件环境
训练阶段对硬件的要求主要取决于基座模型规模和训练框架。以下是通用参考，具体数值需结合实际代码库确认：
| 模型规模 | 最低显存参考 | 推荐配置 |
|---|---|---|
| 1B 级别 | 24GB 左右 | 单张 A100 / 4090 |
| 7B 级别 | 40GB 以上 | 多卡并行或单张 A100 80G |
| 13B 及以上 | 80GB 以上 | 多机多卡 |
如果是纯 CPU 环境，可以跑通数据生成和过滤流程，但策略优化阶段不建议在 CPU 上训练，收敛速度过慢。
5.2 软件环境
需要安装的基础组件包括：
- Python 3.10 或更高版本。
- PyTorch 2.x，CUDA 版本需匹配显卡驱动。
- Transformers、Accelerate、DeepSpeed。
- 如果你要复现 GRPO / DAPO，建议使用支持这些算法的 RL 框架，例如 veRL、OpenRLHF 或 TRL。
安装命令示例：
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install transformers datasets accelerate deepspeed pip install trl不同 RL 框架的安装方式差异较大，建议先阅读对应项目的 README。不要直接混装多个 RL 框架的依赖，容易冲突。
5.3 数据准备
需要准备的数据格式通常包含：
- 问题文本。
- 标准答案或验证器脚本。
- 可选：提示词模板。
数学推理任务的数据可以组织成以下形式：
{ "question": "一个矩形的长是 8，宽是 5，求面积。", "answer": "40" }代码生成任务需要准备测试用例验证器，例如：
{ "prompt": "编写一个函数，输入两个整数，返回它们的和。", "test_cases": [ {"input": [1, 2], "expected": 3}, {"input": [10, -5], "expected": 5} ] }推荐把所有原始数据放在独立目录，不要与训练代码混在一起。
6. 训练流程设计与测试方案
6.1 阶段一：STaR 基座推理能力预热
先让模型学会生成基础推理链。伪代码逻辑如下：
for epoch in range(num_epochs): for batch in train_data: # 让模型生成推理链和答案 outputs = model.generate( batch["question"], max_new_tokens=512, temperature=0.7, do_sample=True ) # 判断答案是否与标准答案一致 correct_mask = verify_answer(outputs, batch["answer"]) # 过滤出正确样本 selected_samples = select_correct(outputs, correct_mask) # 将正确推理链作为监督数据继续微调 if len(selected_samples) > 0: train_loss = supervised_finetune(model, selected_samples)这一步的关键观察点有两个：
- 过滤后的样本数量是否充足。如果正确率太低，说明基座模型能力与任务难度差距太大，建议先做一轮任务相关的监督微调。
- 迭代后验证集正确率是否持续上升。如果两轮迭代后没有明显提升，需要考虑增加采样数量或更换基座模型。
6.2 阶段二：GRPO / DAPO 策略优化
在 STaR 预热之后，进入策略优化阶段。以 GRPO 为例，训练循环大致是：
for step in range(total_steps): # 采样一组问题 questions = sample_questions(batch_size=8) # 对每个问题生成一组回答 responses = policy_model.generate(questions, num_return_sequences=8) # 计算规则奖励 rewards = compute_rule_rewards(questions, responses, verifier) # 计算组内相对优势 advantages = compute_group_relative_advantages(rewards, group_size=8) # 更新策略模型 policy_loss = grpo_loss(responses, advantages, old_logprobs) policy_model.backward(policy_loss) policy_model.step()GRPO 训练时要注意两个关键参数：
group_size：每个问题采样的回答数量。太小会导致优势估计不稳定，太大会增加显存和训练时长。从课程和常见实践看，8 到 16 是常用区间。clip_range：策略更新的裁剪范围。如果训练过程出现 loss 剧烈波动，考虑调小裁剪范围。
如果你用的是 DAPO，需要在 GRPO 基础上额外开启 Clip-Higher 和 Token 级损失。具体开关名称以你选择的 RL 框架文档为准。
6.3 阶段三：效果验证
训练完成后，不要只看训练集 loss。建议做一个独立的验证脚本，包含以下检查项：
- 从验证集中随机抽取 100 到 200 道题。
- 使用基础模型和训练后模型分别生成答案。
- 统计答案正确率。
- 统计推理链平均长度。
- 检查是否有明显退化的回答格式。
一个可用的验证脚本模板：
from transformers import AutoModelForCausalLM, AutoTokenizer model_name = "./trained_model" model = AutoModelForCausalLM.from_pretrained(model_name) tokenizer = AutoTokenizer.from_pretrained(model_name) questions = load_validation_questions() correct = 0 total = 0 for q in questions: prompt = build_prompt(q["question"]) inputs = tokenizer(prompt, return_tensors="pt") outputs = model.generate( **inputs, max_new_tokens=512, temperature=0.0, do_sample=False ) response = tokenizer.decode(outputs[0], skip_special_tokens=True) if verify_answer(response, q["answer"]): correct += 1 total += 1 print(f"Accuracy: {correct / total:.4f}")判断训练是否成功的标准要提前定好：是正确率绝对值，还是相对基座模型的提升幅度，还是推理链可读性。不同任务，标准不一样。
7. 资源占用与性能观察方法
训练时扩展的资源占用集中在两个阶段：数据采样阶段和策略更新阶段。
数据采样阶段，模型做的是生成任务，显存占用与max_new_tokens和batch_size直接相关。如果你在 24GB 显存环境下跑 7B 模型，建议把batch_size调小到 1，同时减少num_return_sequences。
策略更新阶段，显存占用除了模型参数外，还要保存优化器状态、梯度、旧策略的 logprobs。这里有几个降低显存的方法：
- 使用 DeepSpeed ZeRO Stage 2 或 Stage 3。
- 开启梯度累积，增大有效 batch size 而不增加单步显存。
- 使用混合精度训练，在训练开始前测试 fp16 或 bf16 是否稳定。
- 把采样和训练拆成两个进程，采样完成后释放生成缓存再做策略更新。
性能观察建议重点看这几个指标：
- 每步训练时间：如果单步超过预期，优先检查采样速度。
- 有效样本率：GRPO 训练中，如果组内奖励普遍偏低，说明模型还在探索阶段，可以考虑降低任务难度或增加采样数。
- KL 散度：策略模型和参考模型之间的差异如果增长过快，说明策略更新太激进，需要调小学习率或增大 KL 惩罚系数。
8. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| STaR 过滤后有效样本太少 | 基座模型能力不足或任务难度过高 | 统计生成答案的正确率 | 先做任务相关 SFT 预热，或使用答案提示重新生成 |
| GRPO 训练 loss 剧烈波动 | clip_range 过大或组内奖励方差过高 | 查看组内奖励分布和 KL 散度 | 调小 clip_range、增加 group_size、调大 KL 系数 |
| 推理链越训越短 | 奖励函数没有鼓励长推理链 | 检查输出长度统计 | 引入过短惩罚或 DAPO 的长度激励 |
| 显存不足 | batch size / 采样数过大 | 观察 OOM 时的显存占用 | 开启梯度累积、减小 num_return_sequences、使用 DeepSpeed |
| 验证集正确率没有提升 | 训练数据和验证数据分布差异大 | 检查数据来源 | 统一数据格式，增加领域内验证集 |
| 策略模型输出格式混乱 | 奖励函数没有约束格式 | 检查生成样例 | 在提示词中强格式输出，并在奖励函数中加入格式项 |
| 多个 RL 框架依赖冲突 | 同时安装了多个训练框架 | 检查 pip list | 使用独立 conda 环境隔离依赖 |
| 训练卡住不更新 | 数据加载器阻塞或采样进程死锁 | 查看日志和进程状态 | 减小 DataLoader 预取数量，设置超时时间 |
9. 最佳实践与使用建议
9.1 先小规模验证再全量训练
不要直接上几千条数据跑全量训练。先用 100 条数据验证数据格式、奖励函数和训练循环没有问题，再逐步扩大到全量。这样可以避免在数据格式错误或奖励函数设计有误时浪费算力。
9.2 奖励函数优先用可验证信号
数学任务用标准答案匹配，代码任务用测试用例通过率，Agent 任务用环境返回的成功标志。可验证信号比模型评判更稳定，更不容易被模型钻空子。
9.3 完整保留训练中间产物
建议把每个阶段的模型权重、采样数据、过滤后的样本、训练日志都保存下来。这样训练效果不理想时，可以回溯到具体阶段排查问题。
9.4 合规与授权提醒
使用训练时扩展技术时，需要注意以下几点：
- 训练数据必须来自合法渠道，不得包含未授权的内容。
- 如果任务涉及人脸、声音、隐私信息，必须确认数据授权范围。
- 模型发布或商用前，要评估训练数据中是否存在版权风险。
- 小模型的能力提升不代表可以绕过内容安全审核，上线前要做内容安全测试。
9.5 训练链路需要版本管理
STaR / GRPO / DAPO 的训练脚本、数据版本、模型版本、奖励函数版本都建议纳入版本管理。这组训练流程迭代周期长，没有版本管理很容易出现“训练结果复现不出来”的问题。
10. 总结与下一步
这一讲最值得记住的点是：小模型匹敌大模型不是靠参数量，而是靠训练策略把推理能力逼出来。STaR 负责让模型学会生成推理链，GRPO 负责用强化学习增强推理策略，DAPO 负责解决开放任务中的训练不稳定问题。三者组合起来，就是一套完整的训练时扩展方案。
建议你最先验证的功能是：用一个小规模的数学推理数据集，先跑通 STaR 的“生成-过滤-微调”循环，再接入 GRPO 做策略优化。整个链路跑通之后，你会发现最大的坑通常不在算法本身，而在数据格式、奖励函数和超参配置上。
最容易踩的坑有两个：一是奖励函数设计得不够干净，模型会钻空子生成格式正确但逻辑错误的推理链；二是策略更新的稳定性控制不好，模型在探索过程中出现能力退化。
下一步可以关注的扩展方向包括：训练时扩展与推理时扩展的组合使用、多轮 Agent 任务上的规则奖励设计、以及如何把训练好的小模型部署到实际业务系统里做高频推理。建议先把这一讲里的三个算法吃透，再逐步扩展应用场景。
