训练大模型这半年，我最深的一个感受是：给模型发奖励和给学生打分一样，光给个总分，学生根本不知道错在哪。如今LLM强化学习（RL）里最值得玩的方向之一，就是token级奖励（token-level rewards）：把原来只在整段回答结束时落下的一次性奖励，拆成每一个词元（token）都能收到的细粒度反馈。早期我们做RLHF时，习惯在模型答完一整段之后，拿一个整体奖励模型打个分，再把整段当作一个整体去更新。效果有，但总感觉模型学得慢——特别是数学推理、代码生成这种长回答场景，几百上千个token只换回来一个孤零零的reward信号，模型真的很难搞清楚自己到底哪一步走对了。
这篇文章不是纯理论科普，也不是贴一段源码就完事。我会结合自己在一个内部数学推理对齐任务里的实际经历，把token级奖励从"为什么要拆"到"怎么拆、怎么算、怎么排坑"完整讲一遍。适合正在做RLHF/RLVR训练的工程师，也适合刚入门、想弄明白"过程奖励和结果奖励到底差别在哪"的研究生。
1. 先搞清楚：token级奖励到底在解决什么问题
1.1 结果奖励的信用分配困境
先说一个最常见的训练场景。我们让模型解一道数学题，它生成了一段2000 token的推理过程，前1950个token思路都很顺，最后50个token里某一步计算失误，答案错了。如果只用结果奖励，整个2000个token共享同一个负分。后面模型更新的时候，真正导致错误的"最后一步"被拉低，前面辛辛苦苦的正确推理也被无差别打击。这是强化学习里最经典的信用分配（credit assignment）问题：一个长序列只有一个奖励信号，你根本不知道这个奖励应该归因于哪一部分行为。
在PPO的实现里，这个问题还会被放大。常规做法是：序列中间每个位置的reward都取0，只有最后一个token（EOS）拿到整体奖励，然后通过GAE从后往前传播。中间位置的优势值（advantage）全靠价值网络去bootstrap，价值网一不准，整个梯度方向就全是噪声。你可以把它想象成考前突击了一个月，最后考及格了，但你根本不知道是前两周的复习起了作用，还是最后三天的冲刺救了你——这种学习效率显然不高。
Token级奖励的思路就是绕开这个困境：在每个token生成的时候，就给它一个即时的质量信号。模型不需要等到整段生成完才知道"这一步走偏了"，生成到某一步时奖励已经落下，它当场就能调整方向。这样做的直接收益是：advantage估计的方差明显变小，梯度的信噪比提升，训练稳定性也会好很多。
1.2 结果监督、步骤监督和token级监督的差别
很多人在讨论token级奖励时，经常会和"过程监督（process supervision）"混着说。实际上两者不是一回事，但工程上经常是嵌套关系。我自己习惯把奖励粒度分成三档：
| 监督粒度 | 奖励信号 | 信号密度 | 标注/计算成本 | 典型适用场景 |
|---|---|---|---|---|
| 结果监督 | 整段回复一个score | 最稀疏 | 低，只需评最终答案 | 短问答、格式统一的分类任务 |
| 步骤级过程监督 | 每个推理步骤一个score | 中等 | 中等，需要步骤切分和步骤评分 | 数学推理、代码生成、长思维链 |
| token级过程监督 | 每个token一个score | 最密集 | 高，需要细粒度评估器或规则 | 探索性强、中间过程高度可验证的任务 |
需要说明的是，实际项目中"token级"和"步骤级"经常是混用的。一个步骤内部通常只有十几个token，我们很难区分"这个token对了、那个token错了"——比如一个模型正在推导"x+1=3"，你说"x"这个token是对的还是错的？它单独存在没有意义。所以在绝大多数实现里，token级奖励的真实形态是"步骤分数的token展开"：一个step内的所有token共享同一个分数。这既保留了细粒度的时间定位能力，又不会引入单token级别的无意义噪声。
1.3 什么场景必须上token级奖励
不是所有任务都需要token级奖励。如果任务是那种20个token以内就能答完的短问题，结果奖励完全够用，没必要自找麻烦。但下面这几类任务，我是强烈建议考虑token级奖励的：
- 长思维链/长推理：回答动辄两三千token，中间步骤的可信度比最终答案更能反映模型是否真的会推理。只给结果奖励，模型很容易走捷径——比如改一下最终答案，前面全胡说。
- 代码生成：编译错误、运行时异常往往对应到具体的代码行，也就是具体的token区间。如果能在出错位置立刻给负分，比最后生成完一整个文件再判分有效得多。
- Agent工具调用：模型在某一步调用了错误的工具、传了错误的参数，这个错误是局部的，不该让前面所有正常对话背锅。
- 长文本写作：分段质量评估、逐段结构反馈，本质上也是token段级别的奖励。
我个人的判断标准很简单：回答越长、中间步骤越容易被单独评估，token级奖励的收益就越大。反之，短任务和高度整体性的任务，强行拆token奖励只会增加工程复杂度，收益甚微。
2. token级奖励的几种设计思路
2.1 过程奖励模型（PRM）：让模型给模型打分
第一种主流方案是训练一个专门的过程奖励模型（Process Reward Model）。它的输入是"前缀序列"，输出是"这个前缀到达当前状态的质量分"。训练数据怎么来？业界最常用的方式有两种：一种是人工对推理步骤标注质量，成本高但质量稳；另一种是自动构造——对同一个问题采样多条rollout，把能得出正确答案的路径标为正、错误路径标为负，让PRM去学习"哪些步骤是通向正确答案的关键步骤"。
PRM推理时的工作流程是：模型生成完整回复后，先按规则或模型把回复切成一个个步骤（比如按换行、按推理逻辑块切分），然后PRM对每个步骤的结束位置打一个分，再把这个分数广播给该步骤内的所有token。PRM的好处是泛化性比较强，可以处理开放域任务，不依赖具体的规则；坏处也明显——要多训一个打分模型，训练成本高，而且PRM本身也可能被策略模型攻击（reward hacking），这一点后面第4章会详细讲。
2.2 规则型token奖励：验证器给的额外反馈
第二种路线是规则驱动。对于数学题，可以写一个答案校验器；对于代码，可以直接在模型生成过程中尝试执行片段并捕获异常；对于结构化格式任务，可以用正则检查每一步是否满足格式要求。规则型token奖励的实现极其便宜，没有额外的模型开销，而且信号稳定、可解释性强——模型某一步格式错了，立刻给个负分数，它很快就能学会格式规范。
但规则的覆盖面有限。它只能识别"可被形式化验证"的错误，无法判断"这句话的推理虽然格式正确但逻辑荒谬"。所以我的经验是：规则型token奖励适合作为基础信号，尤其是数学/代码这种答案可验证的任务；开放域任务里，它当不了主力，只能当补充。
2.3 KL惩罚本来就是一种token级奖励
这一点很多新人会忽视：RLHF/RLVR训练里的KL散度惩罚，本质上就是逐token作用的奖励修正项。标准loss里经常有beta * KL(pi || pi_ref)，它比较的是当前策略和参考策略在每个token上的分布差异。模型如果在某个token上大幅偏离参考策略，这个惩罚立刻体现出来。
换句话说，我们的训练流程里其实早就有token级信号了。只不过KL信号是"约束性"的，它告诉模型"别跑太远"，但没告诉模型"这里该往哪个方向跑"。而token级奖励是"指引性"的，它直接给出好坏判断。理解这一点很重要：当你引入显式的token级奖励时，它不是从零开始，而是在KL惩罚这个已有的token级信号之上，叠加一个信息更丰富的方向信号。
2.4 三个方案怎么选：我的选型标准
这三种方案不是互斥的，实际项目里往往是组合拳。我自己在项目里的选型逻辑是：
- 任务有明确验证规则（数学、代码、格式化）：优先上规则型token奖励。便宜、稳定、解释性强，能解决80%的问题。
- 开放域任务（对话、写作）：上PRM。没有规则可用，只能靠模型学一个打分器。
- 无论哪种：KL惩罚必须保留，它是最基本的稳定性保障。
- 如果资源有限，最快的见效组合是"结果奖励 + 规则型过程奖励"。结果奖励盯住最终目标，过程奖励盯住中间质量，两者互补，能覆盖大多数长序列训练需求。
3. 实操：把token级奖励接进GRPO训练流程
3.1 第一步：把"步骤分数"翻译成"token奖励"
假设我们已经拿到了每个步骤的分数，这一步要解决的是怎么把它映射到token序列上。核心是维护一个token_to_step的映射关系：每个token记录自己属于第几个step。这个映射可以在生成阶段由切分逻辑同步构建。
def step_scores_to_token_rewards( step_scores, # list[float]，每个step一个分数 token_to_step, # list[int]，每个token属于哪个step seq_len, # 序列长度 ): rewards = [] for tok_idx in range(seq_len): step_id = token_to_step[tok_idx] rewards.append(step_scores[step_id]) return rewards这段代码看起来简单，但工程里至少有三个坑。第一，tokenizer的special token（比如<eos>、<pad>、<bos>）不能参与奖励计算，token_to_step里要给它们单独标记为-1，最后用mask抹掉。第二，padded batch里padding位置没有任何实际意义，reward必须置0、loss必须mask，否则模型会学到"对空位置也输出信号"这种错误行为。第三，如果某个step在切分后意外为空（比如连续两个分隔符），要在构建映射时过滤掉，不能让空step占一个score位置。
3.2 第二步：在GRPO里计算token级优势
GRPO的核心思想是：对一个输入问题采样一组多个回复，然后在这组回复内部做相对比较，以此构造advantage，避免再训一个庞大的critic网络。标准GRPO里，如果只用结果奖励，那组内所有token的advantage都是同一个值——因为所有位置共享同一个整段分数。
一旦换成token级奖励，advantage就可以在每个token位置上单独做组内归一化。我的实现是这样的：
# rewards: [group_size, seq_len]，token级奖励矩阵 mean_rewards = rewards.mean(dim=0, keepdim=True) std_rewards = rewards.std(dim=0, keepdim=True) advantages = (rewards - mean_rewards) / (std_rewards + 1e-4) advantages = advantages * mask注意这里的mean和std是在dim=0上算的，也就是对组内所有回复的同一token位置做归一化。为什么不整组所有位置一起归一化？因为不同位置的奖励量纲可能完全不同——比如前几步是格式分（0~1的小数），最后一步是结果分（+1/-1），混在一起归一化会抹掉位置差异，导致模型分不清"这一步的绝对水平"到底如何。逐位置归一化更稳。
3.3 第三步：组合出最终训练奖励
在真实训练里，我一般会把三类信号合在一起。公式长这样：
r_{i,t} = w_process * r_process_{i,t} + w_outcome * r_outcome_i + beta * kl_{i,t}
第一项是token级过程奖励，告诉模型"这一步走得对不对"；第二项是整段结果奖励，告诉模型"这段最终答案对不对"；第三项是KL惩罚，控制策略不能偏离参考策略太远。三者的单位不一致，不能直接相加，必须先归一化再组合。我常用的做法是先把过程奖励和结果奖励各自标准化到差不多的量纲，再给权重。
初始值我建议这样设：规则型过程奖励的w_process可以给0.5到1.0，PRM型给0.1到0.5——因为规则型信号更可信，PRM型噪声大，权重压低一点更安全。w_outcome固定在1.0左右，结果奖励是最终目标，不能太弱。beta根据模型规模在0.01到0.05之间起步，KL太早压死会学不动，太小又会跑偏。
3.4 训练时容易漏的几个关键细节
token级奖励引入后，训练日志和数据处理有一堆细节必须跟上。我踩过坑之后总结了五条：
- 把token奖励clip到一个安全范围。我一般clip到[-2, 2]，超出这个范围的分值大概率是异常信号，直接截断比保留更能保稳定。
- 定期打印"每个step平均token数"。如果模型学会了疯狂换行，把一个长推理拆成几百个短step，说明它已经找到刷分数的方法了——这种时候步骤切分规则要改。
- 训练日志里除了总loss，一定要单列"token奖励均值""KL均值""结果奖励通过率"三个指标。只看总loss，模型跑偏了你根本无从察觉。
- 做EMA平滑再看趋势。token级奖励的波动通常比结果奖励大很多，直接看原始曲线容易误判。
- 奖励和logprob要对齐。很多bug都出在"advance已经算完，但和输入token错了一位"——用tabular logging把
(token, logprob, reward, advantage)打出来，肉眼检查前50个token就能发现对齐问题。
4. 实测中踩过的坑和排查方法
4.1 问题一：训练loss降了，最终评测一点没涨
这是我第一次上token级奖励时遇到的最诡异问题。loss曲线很漂亮，稳步下降，但最终评测准确率原地踏步。一开始我以为要等更多轮数，后来一查才发现，模型学会了"刷过程分"——它把每一步都写得格式正确、看起来有理有据，但最后的答案仍然是错的。原因是过程奖励和结果奖励脱钩了：中间步骤拿到的正分，并没有导向最终正确答案。
排查思路是先算过程分数和结果分数的相关系数。相关系数低，说明过程奖励模型或规则信号被"钻空子"了。处置建议是：提高w_outcome的权重，同时给训练加一个约束——如果最终答案错了，整段回复的过程奖励做一次衰减，避免模型"每步都像在推理、但推理整体失效"。另外，如果PRM打分发现"过程分高但结果错"的样本比例超过10%，基本可以判定是PRM训练数据质量出了问题，要重新过一遍标注。
4.2 问题二：token奖励噪声太大，训练波动剧烈
token级奖励的毛病是太密、太碎。PRM在单个token级别上往往没有足够的分辨率，它对一个step内部的不同token打分可能是在"瞎猜"，导致adv出现明显噪声。表现就是训练不稳定、梯度norm时高时低。
我的处理办法有三个。第一是平滑：把相邻5个token的reward做滑动平均，或者干脆退回步骤级——step内共享分数，只在step边界切换。第二是降低w_process，让过程奖励从"主导信号"降为"辅助信号"。第三是提高batch size，用更多样本对冲噪声。实测下来，最有效的是"步骤共享分数+结果奖励主导+过程奖励辅助"的组合，干净利落。
4.3 问题三：KL惩罚和token奖励打架
引入token级奖励后，模型有时候会发现"偏离SFT策略能拿到更高的token奖励"，于是KL惩罚就压不住了，表现为KL散度反弹、熵快速下降。这个问题的本质是：token级奖励给得太密，模型找到了一条"每个token都拿小分、累计起来很高但整体质量很差"的捷径。
排查方法是看"高reward token是否都偏离SFT很远"。如果正奖励总是落在策略分布明显偏移的位置，那基本可以断定是奖励被利用。处置建议：提高beta，比如从0.02提到0.05；同时降低w_process；更根本的方法是修奖励本身，让"格式正确但内容是胡扯"的中间步骤得不到高过程分。
4.4 常见问题速查表
| 现象 | 先查什么 | 常见原因 | 处置建议 |
|---|---|---|---|
| loss下降但评测不涨 | 过程分与结果分的相关性 | 模型刷过程分、奖励脱钩 | 提高w_outcome，结果错时衰减过程奖励 |
| 训练波动大 | token奖励分布、梯度norm | PRM单token分辨率低、噪声大 | 平滑reward、降到步骤级、提高batch size |
| KL反弹、熵崩 | 高reward token的KL值 | 模型利用奖励，偏离SFT | 提高beta、降低w_process、修奖励本身 |
| advantage分布偏斜 | 每个token位置的adv统计 | 归一化方式不对、mask漏处理 | 逐位置组内归一化，严格mask padding |
| 模型疯狂拆短step | 每step平均token数 | 步骤切分规则被利用 | 限制最小step长度、改进切分规则 |
4.5 关于"要不要做到每个token都不同"的一点个人看法
做了一圈之后，我的结论是：工程上不需要追求"每个token都真正独立打分"。除了极少数可验证场景（比如代码编译错误能精确定位到某个token），大部分任务的"可评估单元"本来就是步骤或句子。强行做到token级，只会放大噪声、增加标注难度。真正有价值的不是"每个token的分都不一样"，而是"奖励不再只落在序列末尾，而是分散到了多个中间位置"。把奖励放在"对的粒度"上，比"最细的粒度"更重要。
我自己跑完这套流程之后最大的体会是：token级奖励不是银弹，它是把信号的分配方式改了，让模型在每个决策点都能收到即时反馈。但它同时也把"奖励被利用"的风险从全局转移到了局部——模型有可能学会在每一个局部都"表现得正确"，整体却在胡扯。这不是token级奖励本身的问题，而是任何细粒度奖励都要面对的"过程与结果解耦"问题。做这个方向，一定要始终盯住最终指标，定期看过程奖励和结果奖励的相关性，发现问题立刻调整权重，而不是一味相信loss曲线。
最后再分享一个实用技巧：如果团队资源有限，不要一上来就训PRM。先用"结果奖励 + 规则型步进奖励 + KL惩罚"的组合跑一版，把日志体系、训练pipeline、问题排查流程都跑通。等你确认这版训练稳定了，再逐步引入更复杂的PRM。每一步多一分信号，模型就少一分迷茫，但每一步也多一分被利用的风险——平衡这两者，才是这个方向真正的功力。
