NLP——LLM相关问题记录

本文主要介绍LLM

SFT的损失函数呈阶梯下降？

  • 参考链接：LLM 可以从简单数据中学习吗？
  • LLM微调时的一个现象：在训练SFT时，损失函数在单个epoch内几乎不会下降，但是在进入下一个epoch后，快速下降（Loss 陡降），且呈现阶梯状
  • 分析出现这种现象的原因（结合论坛的讨论，也有自己的理解），下面是一些可能的原因，也可能是多个原因同时导致：
    • 训练数据集diversity做的非常好 ，即单个epoch内部的数据集之间关系不大
    • 大模型是在记忆训练数据 ，且发生了过拟合（非常厉害的过拟合，可以对非常多的数据进行过拟合）
      • 个人理解：这种过拟合并不一定不好，因为模型可以记住全部的训练数据，且能一定程度上记住各种模式

大模型是推断还是记忆？

  • 参考：Transformer是推断还是记忆？初始化大小很重要
  • 博客中，博主通过设计了一个新的计算定义，并构造数据集训练模型，训练结果显示，模型可以实现“推断”功能，但是博主猜测模型可能从一些历史数据中通过类比投机取巧实现了“推断”
  • 特别地，博主设计了对{1,2,3,4}进行组合的运算，训练集合缺失了{3,4}，最终模型能推断出来{3,4}的定义，但猜测模型有两种实现方式：
    • 记忆方式：从历史中推断{4,3}等价于{3,4}，并记住{4,3}，也就是说，如果训练数据中使用了错误的{4,3}，模型不能正确推断{3,4}的正确值（此时{4,3}仍等于{3,4}，凑是错误的值）
    • 推断方式：真正从历史推断到各种组合形式，就算训练数据中使用了错误的{4,3}，模型也能正确推断{3,4}的正确值（此时{4,3}不等于{3,4})
  • 结论：
    • 模型初始化参数较小时，模型倾向于推断方式
    • 模型初始化参数较大时，模型倾向于记忆方式
  • 个人理解：
    • 实际上，都是推断，第一种记忆方式也是从{1,2}等于{2,1}中推断出了{3,4}等于{4,3}，实际上也包含了推断的思想

相同的Prompt，不同的回答？

  • 同一个Prompt进入同一个模型什么情况下会出现不同的回答？*

名词解释

  • 情况一：所有的非Greedy-search方法（do_sample=True）均会出现改现象，因为存在采样
  • 情况二：Greedy-search方法（do_sample=True）也不一定能保证输出完全一致
    • 如果同一个Prompt混合其他不同长度的（大于当前Prompt长度）Prompt作为不同Batch进行serving，则可能出现该现象
    • 本质原因：因为Prompt在输入时本质是Prompt+padding，padding的长度不同，虽然在Attention时padding的token都会被设置成一个非常小的值，但深度学习模型太深，这点点极小的值仍然可能会影响最终的输出
    • 最近看到一个很有趣的题目（题目中最小值有误，应该是1-2^32）：

      提问：在一个LLM（Lamma2）对同一批prompt复制5次进行greedy预测的时候，为什么同一个prompt得到的answer会不一致？
      回答：因为同一个prompt和不同的prompt在一个batch里的时候，会有不一样的padding个数（这依赖一个batch里最长的prompt）。而由于padding数量不一致，所以其实原始prompt变成prompt + padding，所以原先两个prompt其实不能exactly一致。尽管Transformer中会对padding在attention中设置成一个极小值（2^-32 + 1），那么softmax(Q^TK)，padding前都为接近0的极小值。但由于大模型深度太深，这种累计的极小值在最后一层依然会放大占据一些weight，使得padding也会影响预测

DPO的损失函数初始值固定？

DPO的损失函数在第0步时是多少？

  • 由于DPO损失函数为：
    $$
    L{\text{DPO}}(\pi_\theta;\pi_{ref}) = - \mathbb{E}_{(x,y_w,y_l) \sim D}\left [ \log \sigma \left( \beta\log\frac{\pi_\theta(y_w|x)}{\pi_{ref}(y_w|x)} - \beta\log\frac{\pi_\theta(y_l|x)}{\pi_{ref}(y_l|x)} \right)\right ]
    $$
  • 第0步时， \(\pi_\theta=\pi_{ref}\)，此时损失函数对应的值为：
    $$
    - \log \sigma(\beta - \beta) = - \log 0.5
    $$
    • 是个固定值

LLM训练和推理一致性？

LLM训练和推理一致性非常重要

  • 比如训练时在第一个字段使用了一些标识符（如BOS），则推理是也一定要加上，否则推理输出大概率会非常奇怪

    • 更多关于BOS和EOS的描述:自然语言处理加BOS和EOS的作用是什么
    • NLP中常用的标识符有：
      1
      2
      3
      4
      5
      6
      7
      1.<SOS>、<BOS>、<GO>：代表一个序列的开始，BOS (Begin of Sentence)
      2.<EOS>：代表一个序列的结束，作为判断终止的标签，EOS (End of Sentence) 
      3.<MASK>：用于遮盖句子中的一些单词
      4.<UNK>：未知字符，代表词典中没有的词
      5.<SEP>: 用于分隔两个输入句子，例如输入句子 A 和 B，要在句子 A，B 后面增加 <SEP> 标志
      6.<CLS> ：放在句子的首位，表示句子的开始，就是classification的意思，通常会在bert等模型出现
      7.<PAD>：补全字符，例如要将句子处理为特定的长度，我们就要在句子前后补<PAD>

  • 特别是第一个固定token，如果训练和推理使用不一致问题会更严重

    • 这个有一定依据，有博主做过实验发现第一个token的一致性比其他位置更重要

      因为第一个token会占据很多attention，号称，attention回收桶

    • 合理猜想：因为第一个位置是每个句子都有的，该位置更重要？

微调/推理LLM的显存需求？

  • 对于参数量为 \(\Phi\) 的模型，假设我们使用 AdamW 优化器，其微调需要的显存如下
  • 对于 FP32 训练：\(16\Phi\)
    • 模型参数（FP32）： \(4\Phi\)
    • 梯度（FP32）： \(4\Phi\)
    • AdamW 优化器状态： \(8\Phi\)，AdamW 优化器 momentum \(4\Phi\) + AdamW 优化器 variance \(4\Phi\)
      • 注：为了训练精读考虑，优化器状态是 FP32 存储的
    • 总计：\(4\Phi + 4\Phi + 8\Phi = 16\Phi\)
  • 对于混合精度训练：\(16\Phi\) 或 \(20\Phi\)
    • 模型参数（FP16）： \(2\Phi\)
    • 梯度（FP16）： \(2\Phi\)
    • AdamW 优化器状态： \(12\Phi\)，AdamW 优化器 momentum \(4\Phi\) + AdamW 优化器 variance \(4\Phi\) + 模型 FP32 参数 \(4\Phi\)
      • 注：为了训练精读考虑，优化器状态是 FP32 存储的，且对于混合精读训练还需要增加存储 FP32 的模型参数
    • 总计：\(2\Phi + 2\Phi + 12\Phi = 16\Phi\)
    • 实际上，在混合精读训练过程中，常常会采用梯度累计策略，此时还会有一份 FP32 的临时梯度参数存在，这需要额外的 \(4\Phi\)，此时需要加载到显存的总参数量为 \(20\Phi\)
    • 注：即使没有采用策略梯度累计策略，也可能会临时先生成 FP32 梯度，这也会需要 \(4\Phi\)
    • 一个不太符合直观感受的结论：混合精度训练反而会增加显存需求（但是会提升训练和推理效率，所以使用还是很广泛）
  • 如果使用LoRA，则不需要为原始参数存储梯度，仅需要为新增的 LoRA 部分参数存储梯度即可
  • QLoRA 在训练时，会对原始参数模型进行 NF4 量化（Normal Float 4-bit），从而原始7B模型的显存占用降低至 3.5GB 左右
  • 目前开源模型的参数大部分都是半精度的（BF16 或者 FP16），比如 Baichuan13B 模型，存储时是3个文件（共 26G 左右）
  • 注意：BF16 或者 FP16 是不能直接转换的，存储为 BF16 的模型也不能直接按照 FP16 加载，但是可以按照 BF16 -> float32 -> FP16 转换
  • LoRA，QLoRA 等参数高效的微调方法（Parameter Efficient Fine Tuning, PEFT）来对模型进行微调，可大大节省显存
    • 注：一般来说，不强调微调方法的“SFT”表示全参数微调方法

SFT 阶段应该注意什么？

数据要求

可以参考论文LIMA: Less Is More for Alignment

  • Prompt尽量丰富多样，让模型能理解更多人类指令
  • Prompt的回答尽可能准确 且 详尽

SFT 阶段的目标不过多的注入知识

  • 整体看模型学习知识的过程应该是在Pre-Training阶段，SFT阶段主要是激发模型的能力，让模型知道怎么使用自己学到的知识
  • 论文：LIMA: Less Is More for Alignment提到过这个
    • 关于这个文章的解读：抛弃RLHF？MetaAI发布最新大语言模型训练方法：LIMA

      MetaAI 最近公布了一个新的大语言模型预训练方法（LIMA: Less Is More for Alignment）。它最大的特点是不使用ChatGPT那样的 RLHF 方法进行对齐训练。而是利用1000个精选的prompts与response来对模型进行微调，但却表现出了极其强大的性能

  • SFT阶段注入过多知识/样本会导致模型走偏？有证据吗？

    提问：建立sft数据主要需要关注什么方面？
    回答：在Lima中给予了两个重要的点：

    • Prompt 的 diversity：丰富多样的prompt数据，可以让模型更多的了解人类的指令，包括指令的意思，复杂指令中每一步的含义。Prompt 的丰富程度决定了模型指令遵循的能力
    • Answer 的质量：Answer 的质量包括内容和格式两方面，一方面内容的正确性需要得到保证，一方面内容的格式也很重要，细节丰富，逻辑缜密的 answer 可以激发模型更多的回答能力
      补充：SFT 阶段不能太多的知识注入：过多的知识注入，或者超过模型能力本身的回答过多会导致对齐税，这是 OpenAI 的 blog 也曾经提到的，这就是我为什么不建议模型过多在 SFT 阶段学习知识，会影响其学习指令遵循的能力
  • 经过尝试发现，模型在 SFT 阶段可以学习一些简单的知识，比如修改模型的自我认知（self-cognition）
  • 尽量将模型要学习的知识放入 Pre-Training 阶段或者 Post-Training 阶段
    • 这里的Post-Training是指什么？Pre-trained,Post-training,finetune的区别

      *Post-training（后训练）就是预训练的二阶段，预训练是从零到1的搞了一个语言模型。Post-training是在预训练后的模型上，再来一波预训练，是语言模型的训练。后面的 finetune 是基于业务的微调
      *其他相关概念：post-training quantization，是模型量化，在模型不变的基础上，通过改变模型中的参数的存储方式，使用低 bit 表示，减低内存带宽和算力要求等，保证模型的效果差别不大。此时模型不需要训练，使用只需要调一下超参数就直接能跑

提升 SFT 阶段 Prompt 多样性？

如何提升SFT阶段Prompt的多样性？

各种 Norm 方式的优缺点

LLM 的 RLHF 中，reward 中为什么包含 KL 散度信息？

  • 补充问题：PPO 的Clip不够用吗？
  • reward 中的 KL 散度是当前策略与 reference 策略的 KL 散度，PPO clip 中（隐含）的 KL 散度是当前策略与上一步收集数据用的旧策略之间的 KL 散度

Transformer中，Q 和 K 为什么要用不同 Embedding？

  • 回答：因为需要去除对称性 ，比如 “I love you very much” 中的 “very much” 对 “love” 很重要，但 “love” 对 “very much” 不太重要， 他们的 Attention 影响应该是不同的
    • 注意：这里的重要性不是说 Softmax 后的 Attention Score 一样，主要是 Softmax 前的 QK 内积一样，由于 Softmax 是按行做归一化的，理论上 Attention Score 会不一样（但这依然限制了模型的表达！）
  • 补充说明：位置编码可以打破这种对称性 ，RoPE 和 其他固定位置编码都可以识别位置顺序（即 “very much” 对 “love” 的前后顺序不同，可以实现 Attention 不同）。以 RoPE 为例，虽然 RoPE 中 Attention Score 是左右位置对称相等的，但是旋转角度是相反的，即 \(\boldsymbol{\mathcal{R}}_{m-n}\) 和 \(\boldsymbol{\mathcal{R}}_{n-m}\) 旋转角度相同，但方向相反，能识别左右位置
  • 个人理解：即使有了位置编码打破对称性，使用不同的 Q 和 K 也是一定意义的，因为两者的目标并完全不相同
    • Q 和 K 不同的目标是编码 token 作为 Query 和 Key 含义本身 ：这是针对 token 的，与位置无关，Q 和 K 不同的本质思想是，一个 token 在作为 Query 和作为 Key 时应该是不同的 ，比如 “very much” 总是用作修饰程度，其他词对它的影响都不太重要（此时它作为 Query），但是它对别的被修饰词的影响却很重要（此时它作为 Key），这是仅用位置编码难以表达的
    • 位置编码的目标则是编码位置 ：对相同的两个 token，在不同的位置，Attention 影响应该不同

如何让大模型输出不被特殊 Token hack？

  • 举例：比如在用户要求模型输出 <|im_end|> 和 <|endoftext|> 等结束符号时，模型如何保证正常输出但不停止？
  • 测试：
    • 第一类，无法输出：一些原生的小模型无法输出<|im_end|>，这个Token会对应输出空
    • 第二类，效果受损：一些原生模型在提到特殊 Token （如<|im_end|> 和 <|endoftext|>）时，输出会很奇怪，不按照命令走
    • 第三类，可以正常输出，且不受任何影响，特别是目前比较出名的大模型，如豆包、Kimi和DeepSeek等都能很正常的输出

哪些场景是不适合用 Prompt Engineering，适合微调的？

  • 一般来说，新场景上先尝试 Prompt Engineering，当遇到瓶颈时（比如指令遵循能力差），再加入微调
  • 场景一：Prompt 难以表达清楚诉求的，比如一些特殊风格或语气输出是不能简单通过几行 Prompt 来说明的，即使给一些简单的示例也不行（营销或客服场景常常需要口语化）
  • 场景二：提升模型推理能力 ，仅通过 SFT 蒸馏一些优质的 CoT 数据即可让模型学会推理，使用 RL 也能提升，但通过 Prompt Engineering 很难实现
  • 场景三：想让模型学会特定的 SOP ，虽然可以通过 Prompt Engineering 实现，但是通过带特定 Prompt 的微调可大大提升模型此时对 SOP 的遵循能力（营销或客服场景常常需要指定 SOP）

微调 和 RAG 分别适合什么场景？

  • 知识问答类的，可以用 RAG
  • 一些问题是需要融合很多知识的，不容易用 prompt 直接表达意图，这时候最好是微调

SFT 中为什么要分离 Instruction 和 Input？

  • Instruction 负责任务描述 ，表示让模型做什么，是必要的字段
  • Input 是待处理对象 ，作为指令的补充，某些指令下，该字段可能为空
  • 分离的意义：将 Instruction 和 Input 分开有利于模型学习任务模式 ，模型可以学习到不同类型任务的通用模式和规律，如果将 Instruction 和 Input 合并，就模糊了任务描述与待处理对象的界限，模型可能难以准确理解任务意图
  • 另一个字段是 System 字段，常用于定义模型的全局行为（通常是一个预设字段且多轮对话中保持不变）
  • 回顾：模型 SFT 时训练的本质是输入一个 token 序列，标记哪些 token 不需要计算损失（常常通过 label 值标记为 -100 来实现），然后，模型预估 next token 实现训练
    • 其中系统输入、用户输入和模型回复之间以怎样的方式组织，主要是靠模型的模板（template）来实现，推理和训练使用的模板需要对齐，否则模型输出不可控（特别是针对一些特殊 token，如结束符等）
  • 实际训练中，不同模型对上述内容的处理方式不同，每个模型通常会配置对应的模板
    • 大部分模板中，常常将 Instruction 和 Input 合并到一起作为一轮的模型输入（用 \n 连接起来），这两个字段都统称为 User 的输入，其 role 对应的是 User

客服行业后训练有哪些经验沉淀？

  • SFT 样本标注成本约 0.3 元/条，一般 1K ~ 1W 条左右
  • RL 的优点是不需要太多数据标注，人力成本低一些；缺点是训练资源大（一般来说可能是 4 倍左右）

字数和 Token 的比例大致是怎样的？

  • 在当前的大模型 BPE Tokenizer 下（大致估计，依据编码方式和词表大小可能有不同）：
    • 中文：一个 Token 大致相当于 1.5-1.8 中文字
    • 英文：一个 Token 大致相当于 3-4 英文字符

预训练中学习率一般是如何变化的

  • TLDR：在大模型预训练中，学习率通常按照“预热（warmup）-稳定-衰减（退火）”的策略变化
    • 训练初期使用较小的学习率，然后通过 warmup 阶段线性地逐渐增加到一个预设的峰值学习率；
    • 达到峰值学习率后，进入相对稳定的阶段；
    • 随着训练的进行，学习率会按照某种策略（如余弦衰减）逐渐降低，直到训练结束时接近于零
  • Warmup 阶段 ：
    • Warmup 阶段是训练开始的阶段，在这个阶段，学习率从一个相对较低的值逐渐增加到一个预定的较高值
    • 目的是防止模型早期发散，让模型在初期避免因梯度更新过大而不稳定，通过慢慢增加学习率，使模型可以逐渐适应数据集的特点和复杂性，有助于提高模型训练的稳定性和效率
    • 常用设定：通常在预训练阶段的前 0.1%-0.5% 的训练步数内完成学习率的线性增长
      • 也有将 warmup 比例设置为训练前10%阶段的情况，但相对较少
      • SFT 时一般，使用 5%-10%
  • 稳定阶段 ：
    • 稳定阶段可能是稳定在最高学习率，也可能是非常缓慢的下降
    • 大模型 SFT 时，常常就是预热后直接进入退火阶段（余弦退火），没有稳定阶段
  • 学习率退火阶段（LR 退火）
    • LR 退火指在训练后期，逐渐减少学习率的过程
      • 类似于物理学中的退火过程，即逐渐降低系统的温度，使系统能够达到能量更低的稳定状态
    • 在模型训练中，逐渐减少学习率可以帮助模型在训练早期快速收敛，在训练后期通过更小的步长精细调整，避免过度拟合，从而找到损失函数的全局最优或较好的局部最优解
    • 常用设定：不同模型的退火阶段占比有所不同
      • 以Llama 3.1为例，在预训练的最后 4000 万个 token 期间进行退火，线性地将学习率退火至 0，不过这是针对其特定的训练规模和数据量而言的，对于其他大模型，退火阶段可能从训练的最后百分之几到几十不等，没有固定的标准比例

大模型左 Padding 还是右 Padding？

  • 关键词：左 Padding（Left Padding），也称为 左填充；右 Padding（Right Padding），也称为 右填充

  • 训练的时候无所谓，左 Padding 或右 Padding 均可以，但训练资源宝贵，大多时候是选择不 Padding，按照固定长度组合起来训练更为常见；

  • 推理时，一般选择左 Padding，理由如下：

    • 提高批量处理的效率 ：在进行批量化推理时，左 Padding 可以保证同一批次所有样本的最后一个 Token 都是有意义的 Next-Token；而右 Padding 则容易导致同一批次样本的最后多个 Token 都是 <pad>（不同样本不同），此时需要进行特殊处理以忽略这些“无意义的” <pad> Token
    • KV-Cache 内存访问更高效 ：KV-Cache 技术下，Page Attention 等访问内存一般是连续的块，左 Padding 可以使得有效数据更集中，从而使得内存访问更高效

  • Padding 的用法：

    1
    tokenizer.padding_side = "left"

  • 一些 generate() 函数会读取最后一个 Token 的输出，此时必须使用左 Padding，使用 右 Padding 会发生错误

    Hugging Face Transformers 明确警告你，并建议在为 Decoder-only 模型进行生成时，初始化分词器时设置 padding_side=’left’

LLM 对齐时为什么需要 RLHF？

  • 副标题：大模型做对齐微调时，为什么需要 RLHF？SFT 不够用吗？
  • 从探索+利用的视角看：
    • RLHF 是探索+利用
    • SFT 是利用
  • 从强化学习策略的视角看：
    • SFT 相当于是模仿学习（可视为离线强化学习的一种方法），可以看做是 RLHF 的冷起阶段，在 AlphaGo 训练过程中也用过先模仿专家策略，再强化学习的过程
    • 如果基础模型足够强，仅使用 RLHF 就够了，这样还能避免过拟合
    • 如果有无穷多的数据（能覆盖所有情况下的最优回答），且不包含错误数据，理论上也可以仅使用 SFT，但这显然不太可能
    • 一般来说，强化学习需要有正例才能获得奖励，从而得到训练
      • 注：但近期的类似 Negative Sample Reinforcement（NSR） 等提出不需要正例也能训练，所以这一点似乎不那么 solid 了
      • 但是：NSR 中所谓的负样本也需要采样出来
  • 从泛化性（过拟合）的视角看：
    • SFT 对模型分布的改变较大，因为学习的数据不一定是来源于模型的，且没有探索能力，容易过拟合，缺乏泛化性
    • RLHF 则更利于泛化性（不容易过拟合）
      • Online RL 会让模型进行各种探索，并及时给出反馈，减少模型的过拟合情况
      • RL 特别针对模型的输出进行惩罚或奖励，相当于是对模型真实动作的调教，不会过度调整其他不相关 Token
        • 学术上常常将这个动作称为 Distribution Sharpening（分布锐化），表示仅仅调整已有分布（高分更高，低分更低），RL 本质是在雕琢而非重塑
    • DPO 可以算是一种离线强化学习的方法，鼓励正样本，打压负样本，但其 Token 是固定的，也不是当前模型生成的，仍然容易造成过拟合
  • 除了这两种范式外，还有一种简单的思路是拒绝采样微调（Rejection Sampling Fine-tuning，RFT），该方案的详情见：(GRPO)DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models：
    • 在每一步迭代中，让固定的 SFT 模型生成回复并人工标注，然后挑选优质样本对当前模型进行 SFT
    • RFT 的扩展方法为 Online RFT：在每一步中，如果保证生成模型如果是最新模型（即上一轮迭代更新后的最新模型），则称为 Online RFT
    • 这种训练方式本质就是 RLHF 的人工手动版（即简化版的强化），训练成本高，效率低，但可能会更稳定
  • RLHF 有什么缺点？
    • 最大的缺点是对 RM 要求太高，所以截止到 25 年，在 RLVR 场景 RL 效果异常好（相信以后随着 RM 逐步提升，在其他场景的 RL 也会越来越厉害的）
    • RL 仅在 Rollout 的最后才有奖励反馈，效率低下
      • 之前的 PRM 等在尝试改善这个问题，但最终因为准确性而导致效果不加，没有被推广；
        • 思考：这可能仍然是未来的发展趋势
      • Thinking Machines 的 On-policy Distillation（OPD） 极大的提高了奖励密度，效率也随之提升了很多，但仅仅适用于大模型蒸馏到大模型上
        • 思考：能否训练很多领域模型，然后在各自领域 用 OPD 蒸馏到通用模型上？
      • 问题：如何理解这里的效率低下，梯度不是能更新到所有的 Token 上吗？
        • 回答：这里的效率低下是指信号少，简单来说就是信号越少，梯度更新就越不准确（比如每次可能只知道梯度的使得最终结果准确的一个粗糙方向，而这个方向上中间过程可能是错的，所以不是准确方向？）
    • 训练流程复杂，对训练框架要求高，且稳定性不如 SFT，这些都在逐步改善
  • 终极设想：
    • 在无需 SFT 或少量 SFT 后，直接 RL，甚至结合具身智能接收真实环境反馈以后，获取更通用的高阶能力
      • 注：如果模型初始能力又太差，且完全不使用 SFT，可能导致 RL 无法训练
  • 在博客 大突破！实验证明，RL能为LLM注入“创新”能力, 20250907 中，提出了 RL 可以使得模型学习到组合能力，且具有泛化性，而 RFT 没有这个能力
    • 核心是通过 RLVR 可以实现组合模型的原子能力，最终实现能力组合，并通过字符串处理的组合最终泛化到了 Countdown 任务上
      • Countdown 任务：给定一组数字和目标值，仅用加减乘除构造等于目标的等式，每个数字仅用一次，常作为推理 / 强化学习的训练任务
  • 在博客 为什么说RL会将搜索空间变小，SFT会将搜索空间变大 - Ryan的文章 - 知乎 中，提到了 RL 和 SFT 阶段最大的差异是在于数据上，RL 的本质是在 锐化分布（提高让奖励高的 Token 概率，降低奖励低的 Token 概率）
  • 在论文 RL’s Razor: Why Online Reinforcement Learning Forgets Less, 20250904, MIT 中提到：
    • 决定遗忘程度的是所学的分布，而非优化算法本身
    • 文中还定义了 RL 的剃刀原理（RL’s Razor） ：在所有能解决新任务的高奖励方案中，On-policy RL 天然偏向于与原始策略 KL 散度最小的解决方案
  • 在论文 Retaining by Doing: The Role of On-Policy Data in Mitigating Forgetting, 20251021, Princeton University, Danqi Chen Group 中给出了一种数学模拟思路，给出了以下 Insight：
    • SFT 是 mode-covering，forward KL
    • RL 是 mode-seeking，reverse KL
    • 如果初始策略是单峰的 (uni-modal)
      • 那么 SFT 实际上可能比 RL 对遗忘更鲁棒；
    • 如果初始策略是多峰的 (multi-modal)：这对于实际的 LM 来说 arguably 是实际情况
      • 那么 mode-seeking 的 RL 导致的遗忘比模式覆盖的 SFT 更少
  • SFT 困境：现实场景中遇到过， 如果只做 SFT，不做 RL（因为 Infra 没准备好等原因），那么可能会发现模型的 pass@k 效果还不错，pass@1 效果很差，也就是模型看起来熵较高，似乎没收敛

为什么蒸馏 Qwen 模型评估指标会长的比较多？

  • 背景：当前的一种方法是，让 Qwen 模型自己给 Prompt 和回复，然后蒸馏 Qwen 模型，这样能够让模型提分很多
  • 补充：截止到 25年8月，一种训练方式是，预训练（包含 SFT 数据）+ 中训练（蒸馏 DeepSeek）+ 后训练（蒸馏 Qwen）
  • 猜测原因是 Qwen 的原始数据量级大，且使用了较多的 SFT 数据，可能无意间包含了评估数据集？

verl PPO 训练时，两张卡比一张卡还慢？

  • 问题详细描述：单卡训练大概50s/it，两张卡训练时60s/it，而且训练时，两张卡都是满载的
  • 原因分析：这通常是由于多卡训练中的通信开销（communication overhead）导致的，而不是计算负载的问题
    • 当使用两张 GPU 卡进行 PPO 训练时，模型参数、梯度或数据需要在卡之间同步
    • 尽管每张卡都处于满载状态，但这些额外的通信时间会使每个训练步骤的总耗时增加
    • 两张卡比一张卡慢，同时两张卡都满载，这几乎可以肯定是卡间通信的瓶颈，而不是计算能力的问题
  • 显存使用和通信量
    • 当使用多卡时，特别是在像 PPO 这样的算法中，需要同步的数据量非常大
    • 如果模型很大，或者在训练过程中需要同步大量状态（例如，PPO 中的价值网络和策略网络），那么两张卡之间传输这些数据的开销会变得非常显著
  • 网络带宽
    • 多卡之间的通信速度非常重要
    • 如果使用的是 PCIe 总线，它的带宽可能成为瓶颈，PCIe 的带宽限制就会导致通信开销变得非常大
    • 如果服务器支持 NVLink，并且 PyTorch 等框架配置正确，那么通信会快得多

vllm 中为什么需要 gpu_memory_utilization 参数？

  • vllm 中有 gpu_memory_utilization 参数，且该值通常小于 1，默认值为 gpu_memory_utilization: float = 0.9
  • gpu_memory_utilization 是核心参数，指定 GPU 内存的目标利用率（范围 0~1）
    • 例如 0.9 表示模型加载和推理时最多使用单卡 90% 的显存，避免内存溢出（OOM）
    • vllm 会根据该值动态调整 KV 缓存等内存占用
  • 临时内存开销：推理过程中会产生大量临时数据，内存占用会 “波动”，例如：
    • KV 缓存（存储注意力机制的中间结果，随输入长度和并发请求数增长）；
    • 计算中间张量（如激活值、矩阵乘法临时结果）；
    • 框架底层开销（如 CUDA 上下文、显存碎片等）
  • TLDR：gpu_memory_utilization < 1 的核心目的是为动态内存需求、显存碎片和硬件基础开销预留空间，避免 OOM 错误，保证大模型推理的稳定性和容错性

vLLM 进行推理时，Batch Size 可以开得很大？

  • 副标题：一个有趣的现象是 vLLM 推理时，当 Batch Size 开的很大时，常常不会出现显存爆炸，但是会出现乱码
  • 问题来源：为什么vllm进行推理时的batchsize开得很大会导致乱码，也不爆显存？ - 捕数的杰哥的回答 - 知乎，回答内包含显存消耗情况分析
  • 在 vLLM 中，显存未爆（OOM）但输出乱码，通常是由 “显存预分配机制掩盖了资源耗尽” 加上 “计算精度或调度逻辑在高负载下失效” 共同导致的
  • vLLM 的显存管理逻辑与传统 PyTorch 推理不同，它几乎 永远不会 报标准的 CUDA OOM 错误，因为它预先占用了显存
    • 预分配机制 (Pre-allocation): vLLM 启动时会默认占用 90% 的 GPU 显存用于 KV Cache（由 PagedAttention 管理）
    • 逻辑阻塞而非物理崩溃: 当请求量（Batch Size）过大导致 KV Cache 的 block 被用完时，vLLM 的调度器（Scheduler）不会让显存溢出，而是会将新请求放入 Waiting 队列，或者对正在运行的请求触发 Preemption（抢占）
    • 现象: 你看到的显存占用率是一条平直的横线（被锁死在 90%），系统没有崩溃，但内部的资源调度已经达到了极限

为什么会导致“乱码”？（核心原因）

  • 当 Batch Size 被强行开得很大（超过了显存实际能承载的舒适区），虽然显存没爆，但会导致以下三个层面的问题，直接引发输出乱码：
    • 数值精度溢出 (Numerical Instability)，这是最常见原因
      • 在 Transformer 的 Attention 计算中（尤其是 Softmax 和中间矩阵乘法），当 Batch Size 极大时，某些累加操作的数值可能会超出 FP16 (float16) 的动态范围
      • Overflow (NaN/Inf): 中间结果溢出变成 NaN 或 Inf
        • 在模型解码时，只要有一个 Token 的计算出现 NaN，后续所有的 Token 生成都会崩坏，变成无意义的乱码或重复符号
      • Underflow: 极小值被抹零，导致注意力机制失效，模型“看不见”之前的上下文，开始胡言乱语
      • 这就是为什么现在推崇使用 BF16 (bfloat16) ，它的动态范围比 FP16 大得多，能有效避免这种大 Batch 下的溢出问题
    • PagedAttention 的“换页”抖动 (Swapping Thrashing)
      • 当显存中的 KV Block 不够用时，vLLM 会触发 Swap-out/Swap-in（把 KV Cache 搬到 CPU 内存再搬回来）
    • 采样参数失效 (Sampling degradation)
      • 虽然较少见，但在极高负载下，如果 CPU 处理速度跟不上 GPU 的生成速度（CPU 瓶颈），可能导致 Logits 的后处理（采样、惩罚等）出现延迟或异常，导致选择了错误的 Token
  • 使用建议：
    • 不要盲目追求大 Batch，限制 max_num_seqs 可以强行压制并发，避免进入“抖动区”
    • 切换精度到 BF16
    • 调整显存利用率，稍微降低 vLLM 的显存占用比例，防止它把显存吃得太死，留一点 buffer 给 PyTorch 的临时张量分配

模型训练为什么一般每台机器最多到 8 卡？

  • 很多软硬件都是按照8卡及以下优化的
  • 目前主流的CPU，虽然拥有大量PCIe通道，但通常也只能高效支持8张GPU卡的全速运行
    • 如果连接超过8张卡，每张卡分配到的带宽就会减少，这会导致数据传输瓶颈，进而影响训练速度
  • 英伟达（NVIDIA）开发了 NVLink 技术，它提供了比 PCIe 更高速的 GPU 间直接通信通道
    • 在高端服务器中，通常会集成 NVSwitch 来构建一个全连接的GPU网络，让 8 张 GPU 之间能够实现高速互通
    • 但这类硬件设计和优化大多是围绕8卡或8卡以下的配置进行的，超过这个数量，要么需要更复杂的硬件配置，要么无法保证全连接带来的通信优势
  • 华为的 NPU 下，很多集群下，是每个节点 16 卡的

为什么发布模型时需要发布量化版本？

  • 副标题：为什么不直接发布一个 FP16 就够了，还要发布一个 PF8 版本？在加载时实时量化成 FP16 不行吗？
  • TLDR：动态量化虽有灵活性，但受限于实时性、精度可控性和硬件兼容性，无法替代预发布版本的“开箱即用”价值；二者并非对立关系，而是互补
    • 预发布版本覆盖主流需求，动态量化满足小众和测试需求，共同构成模型部署的完整生态
  • 量化不是 “简单改个数据类型”，而是复杂的优化过程，以 FP8 量化为例，关键优化步骤包括：
    • 校准（Calibration） ：用代表性的数据集（如验证集子集）统计模型各层张量的数值分布（如最大值、最小值、方差），确定量化的“范围”，避免截断有效信息
    • 量化参数计算 ：根据校准结果，为每个层甚至每个通道计算量化所需的“缩放因子（Scale）”和“偏移量（Zero Point）”
      • 这些参数是 FP8 能准确近似 FP16 数值的核心，需要与模型权重绑定存储
    • 精度补偿 ：部分敏感层（如注意力层、输出层）直接量化到 FP8 精度损失过大，可能需要保留 FP16 精度，或采用“混合精度量化”（如权重用 FP8，激活用 FP16），这需要提前调整模型结构并验证效果
    • 硬件适配 ：不同硬件对 FP8 的支持方式不同（如是否支持 FP8 专用计算单元、支持的 FP8 子类型（E4M3/E5M2）），需要针对性优化量化逻辑以发挥硬件性能
    • 这些步骤无法在“边加载边量化”时实时完成 ：一方面，校准和参数计算需要消耗额外的时间（对大模型可能需要数小时），用户加载模型时无法接受这种延迟；另一方面，量化后的精度和性能需要提前验证（如测试推理准确率、吞吐量），若动态量化参数不合理，会直接导致模型可用度下降
  • 补充：训练时，如果输入是 FP16 的模型，想要做 QLoRA 微调，也是需要量化的（一般的框架内自带了这个功能）
    • 框架会在加载 FP16 参数后，自动执行离线量化流程 ，生成 QLoRA 所需的低精度权重（如 INT4），而非直接使用原始 FP16 进行训练
    • 支持 QLoRA 的框架（如 Hugging Face Transformers 结合 bitsandbytes 库）在加载 FP16 参数时，会自动触发量化步骤：按照QLoRA 的标准（如4位分组量化、双重量化），将FP16权重离线转换为INT4等低精度格式，并计算缩放因子、零点等量化参数
      • 这个过程对用户透明，只需指定量化参数（如load_in_4bit=True），看似“输入FP16”，实则框架内部已完成量化，最终参与训练的是转换后的低精度权重
    • QLoRA 采用了 “分块加载 + 即时量化” 的内存优化策略（分层加载，分层即时量化），甚至不需要完整加载模型

HF 数据集中 subset 和 split 的关系是什么

  • 一个数据集可能有多个 subset，一般用于区分数据来源信息
  • 每个 subset 都可以有自己的 split，一般用于区分数据用途信息

Global Batch Size 为什么不能无限增大？

  • Global Batch Size 增大能提升计算效率，但会带来三大核心问题：
    • 泛化能力下降 ：
      • Batch Size 决定了每次参数更新前，模型看到的数据样本数量
      • 过大的 Batch Size 意味着模型每次学习的是一个非常“平滑”的、代表整个数据集的梯度方向
      • 模型容易快速收敛到一个性能不是最好的“舒适区”，难以跳出（存疑）
        • 理解：对于凸优化的模型问题（如逻辑回归等），可以使用最大批次，总会收敛到最优点，但是大部分现实场景都是非凸的，容易陷入局部最优而永远无法跳出；梯度的噪声反而是有助于模型跳转探索最优路径的，避免收敛到局部最优
    • 内存资源不足 ：数据量太大，需要的显存过高，但可以通过梯度累加的思路实现小 Batch 计算梯度，累加到 Batch 后一次更新梯度
    • 训练稳定性变差（非直接引发）：
      • 大 Batch Size 下，单次梯度更新的方向更稳定，所以可以设定的学习率应该越大
      • 理论上，Batch Size 增大 N 倍，学习率也应相应增大 \(\sqrt{N}\)（平方根） 或 N 倍（线性）才能保持相似的更新幅度（对相同的 epoch 而言）
        • \(\sqrt{N}\) 是从等方差的视角来看的，N 倍（线性）则是有更深的一些思路，部分论文支持 \(\sqrt{N}\)（平方根），部分论文支持 N 倍（线性）， 实践中可以都试试，一般似乎是 N 倍（线性）更好
      • 问题：学习率越大，波动越大，模型越不稳定；但学习率不能太小，否则效率太低了
  • 数据集质量与 Global Batch Size 的关系：
    • 高质量数据 可以使用 大 batch + 大 LR
    • 低质量数据 需要使用 小 batch + 小 LR
      • GBS：小 batch 引入的梯度噪声有助于“忽略”部分噪声样本，避免被错误标签主导更新方向
      • 学习率：避免被噪声样本“带偏”，小步长更稳健，减少过拟合风险
  • 苏神博客有较为深入的讨论：当Batch Size增大时，学习率该如何随之变化？
    • 苏神其他还有几篇与 Batch Size 相关的博客可以参考

Megatron 训练是确定性的吗？

  • 参考自：nccl, flash-attn. TE 可能破坏 megatron 可复现性 - 铁蛋儿的文章 - 知乎
  • 确定性的定义：即 bit-wise 复现，表示在相同的训练环境（硬件和软件环境）下，如果使用相同训练配置（各种超参数和种子），运行多次训练应该产生相同的模型检查点、损失等指标
  • Megatron 训练会因为一些优化点导致不确定性
    • Megatron 自身使用的 NCCL 相关的特定算法可能是包含不确定性的
      • 理解：比如 Ring All-Reduce 等累加顺序不同带来的精度不确定？
    • FlashAttention 是非确定性的
    • Transformer Engine 是否存在不确定性？
  • Megatron 训练可以实现比特级可复现；需要使用 --deterministic-mode
  • 亲测：在包括 GBS 和随机种子在内的所有参数完全相同的情况下，直接使用 Megatron 做前向过程也有较小的 diff（注意：即使仅前向推理就已经有 diff 了）
    • 在 BF16 下，最终得到的输出分数（比如奖励模型的输出）这个 diff 一般在小数点后面两位左右（其实不小）
    • 配置 deterministic-mode=True（包括 FlashAttention 也开启 deterministic-mode=true 模式）以后，最终得到的结果可以做到 bit-wise 复现

FlashAttention 非确定性出现的原因及修复

  • 默认模式下的结果 FlashAttention 是非确定性的，数值差异通常是 1e-5 ~ 1e-3 级别（float16/bfloat16），不会影响模型的定性表现（如分类准确率），但会破坏“完全可复现”；
  • deterministic=True 可以保证确定性，但通常会导致 FlashAttention 的吞吐量下降 5%~20%（具体取决于 GPU 型号和 batch 大小）；
    • 注：在使用大规模 前向推理任务中（GBS=512，DP=16），亲测实现下来没发现吞吐量下降（效率几乎完全一致）
  • 需要严格复现实验结果（如论文复现、调试）时开启，线上推理/训练追求性能时可关闭

FlashAttention 非确定性出现的原因

  • 默认情况下，Flash Attention为了极致性能会启用非确定性的并行 / 优化策略
    • 默认模式下的结果差异通常是 1e-5 ~ 1e-3 级别（float16/bfloat16），不会影响模型的定性表现（如分类准确率），但会破坏“完全可复现”
    • 亲测：
      • 均值为 4 的打分，70K 次打分统计
      • 差异平均在 0.03 左右（7.5e-3 差异，上面的描述略大）
      • 最大最小差异大约在 0.5 左右，还算是能接受的范围内
      • 中位数为 0.03，TP90 为 0.06，TP95 为 0.07，基本算能用
  • FlashAttention 是为 GPU 高吞吐量设计的注意力实现，其非确定性根源来自以下几个关键优化手段：
  • 异步/并行内存访问与块划分的非确定性
    • FlashAttention 的核心是“分块计算+显存复用”（将 Q/K/V 切分成小块，避免全量存储注意力矩阵），默认模式下：
      • GPU 的线程块（thread block）调度、内存加载顺序是由硬件调度器动态决定的（而非固定顺序）；
      • 不同运行时，块的计算/合并顺序可能微小差异，叠加浮点数的舍入误差（如 float16/bfloat16 精度下），最终输出会出现极小的数值偏差；
      • 即使是同一台机器、相同配置 ，GPU 内核的执行时序、缓存命中情况也会导致块处理顺序变化，放大这种偏差
  • 原子操作/归约的非确定性
    • 注意力计算中涉及大量“归约操作”（如 softmax 中的求和、注意力权重与 V 的加权和），FlashAttention 默认会用 GPU 原子操作（atomic operations）加速归约：
      • 原子操作的执行顺序由硬件决定（多线程同时更新同一个内存地址），不同运行时的执行顺序不同，会导致浮点数累加的舍入结果不同；
      • 例如：a + b + c 和 b + a + c 在低精度下可能得到不同结果（如 1e-5 级别的偏差）
  • CUDA 内核的优化策略
    • FlashAttention 基于 CUDA 定制内核实现，默认会启用 NVIDIA CUDA 的 --fast-math 等优化：
      • 这些优化会牺牲严格的数学确定性（如忽略某些浮点精度约束、重排计算顺序）以提升速度；
      • 不同运行时，编译器/硬件的优化策略可能细微调整，导致结果差异
  • 全局 Batch Size 相同但分块粒度的动态性
    • 即使 Global Batch Size 固定，FlashAttention 对 batch 内样本的分块粒度可能因运行时的 GPU 资源（如显存剩余量、线程数）动态调整：
    • 例如：某次运行将 batch 切分为 [8,8]，另一次切分为 [16]，分块内的计算误差累积后会导致最终结果不同

FalshAttention 确定性推理配置

  • deterministic=True 可以保证结果一致
  • deterministic（确定性）参数的核心目的是强制 FlashAttention 放弃部分性能优化，保证相同输入/配置下输出结果完全可复现 ，本质是关闭可能引入非确定性的底层优化逻辑，让计算过程严格遵循“输入->固定计算路径->输出”的确定性流程
  • 当设置 deterministic=True 时，FlashAttention 会做以下关键调整：
    • 1）固定计算顺序 ：强制线程块/内存访问按固定顺序执行（如按 Q/K/V 的维度顺序分块、合并），消除调度带来的随机性；
    • 2）禁用原子操作的非确定性用法 ：改用确定性的归约算法（如串行累加、固定顺序的并行归约），代价是少量性能损失；
    • 3）关闭浮点优化 ：禁用 --fast-math 等会改变计算顺序的优化，严格遵循浮点运算的确定性规则；
    • 4）固定分块策略 ：忽略运行时 GPU 资源波动，按固定规则切分 Q/K/V 块，保证分块粒度和计算路径唯一

相同数据集下不同 packing 大小训练效率对比

  • 背景：
    • 在大模型训练中，packing 是将多个短样本拼接成一个长序列，以减少 padding token 的比例，从而提高 GPU 计算利用率，但不同的 packing 大小 的效率是否相同呢？
    • 问题：在 相同训练集、每个 global batch 的 token 数量一致 的条件下，比较 16K packing（16,384 tokens） 和 128K packing（131,072 tokens） 哪种更快

可能影响效率的原因简单分析

  • 即使 global_batch 的 总 token 数一致 ，不同 packing 长度会影响训练速度，目前思考可能的原因有：
    • GPU kernel 启动效率 & 序列长度对吞吐的影响
      • 短序列（16K）：每个 batch 中样本数量更多，序列较短，GPU kernel 启动较多次，可能导致 吞吐下降
      • 长序列（128K）：每个 batch 中样本数量更少，但单个样本更长，可以更好地利用 GPU 的并行计算能力，减少 kernel 启动开销
    • 显存访问与注意力计算复杂度
      • Transformer 的注意力计算复杂度是 \(O(n^2)\)（n 为序列长度）
      • 128K 序列的注意力计算量远大于 16K，即使总 token 数一样，长序列的计算会更集中，可能导致 单步计算更慢
      • 如果使用了 FlashAttention 或分块注意力优化，长序列的劣势会被部分缓解
    • 数据加载与通信
      • 16K packing：更多样本意味着更频繁的数据加载与分布式通信
      • 128K packing：数据加载次数减少，通信开销可能降低
    • 数据丢弃或 packing 效率
      • 16K packing 时可能丢弃部分过长数据，所以训练 step 数量可能会更少
      • 16K packing 的碎片更多，可能浪费一些 padding，理论上 step 数量可能增多
      • 结论：Step 数量可能减少也可能增多，不确定

结论

  • 在全注意力下：
    • 如果使用标准 Transformer 全注意力** ：16K packing 更快 ，因为长序列的 \(O(n^2)\) 注意力计算会拖慢训练
      • 单个 128K 样本的注意力计算量是 (128K)^2，比多个 16K 样本的 (16K)^2 * 62 要大很多，理论上，在没有优化的情况下，128K packing 会更慢 ，因为长序列的计算复杂度高
    • 如果使用高效长序列优化（如 FlashAttention-2、分块注意力、稀疏注意力）并且显存足够：128K packing 可能更快，因为减少了 kernel 启动和数据通信开销
    • 实际速度取决于你的模型实现、硬件（尤其是 GPU 架构）以及注意力优化程度
  • 实际测试：
    • 16K 比 128K 快约 23%
  • 注：很多时候是没得选的，为了保证长序列效果，需要使用很大的 packing

后训练各阶段学习率配置最佳实践

  • 副标题：SFT 学习率和 RL 学习率一般多大？
  • 相同的模型相同的场景， 一般 SFT 学习率比 RL 大一个量级左右（因为 RL 需要缓慢更新以保证稳定性）
    • 比如 SFT 一般 1e-5，RL 一般 1e-6（注：这里特指 Actor， Critic 的学习率可以跟 SFT 一样，设置的高一些）
  • 经验：因为 RL 训练太慢，所以有时候可以可以增加学习率加快速度观察某些优化点的效果？（注意监控模型的中间指标）
  • 一些经验总结：
    • SFT 的学习率一般设置在 1e-5 左右，偶尔甚至会到 1e-4 量级，也可能到 1e-6 量级
    • 预训练的学习率和 SFT 差不多
    • DPO 的学习率一般比 SFT 更低一些，低大约 2-10 倍
    • PPO 的学习率则比 DPO 还要再低一些，一般是 1e-6 等， 甚至到 1e-7 量级
  • 其他区别（一般情况下的最佳学习率对比）：
    • MoE 模型 通常比 Dense 模型更大
      • 稀疏模型每次只激活部分专家，对模型的影响幅度小，梯度噪声相对较小，允许用更大的步长（学习率）而不至于发散
      • 当然，训练时，相同的数据量，稀疏模型训练需要的时间也会更少
    • 同类型的 小模型 一般比 大模型 更大
      • 小模型更稳定，一般来说学习率可以更大些
    • LoRA 一般比 全参数微调更大，一般最优参数是全参数微调的 10 倍左右
      • 与 MoE 类似，每次仅更新部分参数，可以使用较大的学习率
  • 其他说明：学习率一般还与 batch_size 有关，batch_size 越大，学习率一般也越大

大模型各阶段的数据集大小一般是多少？

  • 预训练：
    • 一般是 T 级别，截止到 25 年，目前大部分开源模型都是 10T 以上
  • SFT：
    • 一般是 B 级别的数据（百万级别的样本数）
    • 除了长文本和 thinking 等特殊数据集外，Prompt 和 Response 的长度大约 1:1（不严谨）
      • 长文本 和 工具调用 的 Response 相对 Prompt 会较短
      • thinking 数据集的 Response 则相对较长
    • 注：
      • SFT 时每个 global step 可以训练百万级别的 Token
      • 训练一般是 epoch=2,3,4 等
  • DPO：
    • 待补充
  • RL：
    • 待补充

loss 相加再求导和先 loss 单独求导再梯度相加的计算量对比

  • 副标题：
    • 多个 token 计算 loss 后，需要求导，此时有两种方式：
      • 分别计算梯度再累加梯度
      • loss 相加再计算梯度
    • （忽略显卡并行优化的情况下）请问 backward 时，以上两种方式的计算量是一样大的吗？
  • 回答：将每个 token 的 loss 分别计算梯度后再累加梯度，与先将所有 token 的 loss 相加后再计算梯度，在 总计算量 上是 等价的（忽略显卡并行优化的情况下）
  • 问题形式化
    • 设模型参数为 \(\theta\)，输入为 \(x = [x_1, x_2, \dots, x_T]\)，对应输出为 \(y = [y_1, y_2, \dots, y_T]\)，每个位置有一个损失函数 \(\ell_t = \text{loss}(y_t, \text{target}_t)\)
    • 方式一：分别计算每个 token 的梯度再累加
      • 对每个位置 \(t\)，计算梯度：
        $$
        g_t = \frac{\partial \ell_t}{\partial \theta}
        $$
      • 然后累加：
        $$
        G = \sum_{t=1}^T g_t = \sum_{t=1}^T \frac{\partial \ell_t}{\partial \theta}
        $$
    • 方式二：先求总 loss，再计算梯度
      • 定义总损失：
        $$
        L = \sum_{t=1}^T \ell_t
        $$
      • 然后计算梯度：
        $$
        G’ = \frac{\partial L}{\partial \theta} = \frac{\partial}{\partial \theta} \sum_{t=1}^T \ell_t = \sum_{t=1}^T \frac{\partial \ell_t}{\partial \theta}
        $$
  • 从数学上看：
    $$
    G = G’
    $$
    • 即两种方式的梯度结果完全一致
  • 从计算图角度看：
    • 反向传播时，链式法则 的加法性质保证了梯度的线性可加性
    • 无论是一次性反向传播总 loss，还是分别反向传播每个 token 的 loss 再相加，计算图的展开路径和中间变量的数量是相同的
    • 因此，总的浮点运算量（FLOPs） 是相同的

补充说明（实现层面）

  • 结论：在忽略并行优化和调度开销的前提下，两种方式的梯度计算总量是等价的，因为梯度是线性算子，满足加法交换律和链式法则
  • 在实际实现中（如 PyTorch），方式二（先求和再 backward）更高效 ，因为可以一次性触发反向传播，减少 Python 循环开销和中间张量管理成本
  • 方式一虽然计算量等价，但可能引入更多 调度开销（如多次调用 .backward()），但这不属于计算量本身

在 SFT 和 RL 的中间是否应该加入 DPO？

  • 当前很多，场景中，DPO 的 prompt 和 response 数据都是提前准备好的（不是 Reference 模型自己生成的），容易导致过拟合或遗忘
    • 注：DPO 的原始论文中，其实算法是说训练用的 response 数据是 Reference 模型采样的（一般是 SFT 后的模型），个人理解这样效果才会更好些；提前准备好的数据让模型去学习容易出现过拟合
  • 当 PPO 做得足够好时，理论上不需要 DPO 了，DPO 最大的优点是可以使用人类标注数据，如果 PPO 的奖励模型做的很好，DPO 理论上就不需要了，PPO 的 on-policy 的数据 + 优秀的奖励模型，完全可以替代 DPO 了

有了自建的模型后，还需要适配开源模型吗？

  • 答案是肯定的
  • 许多开源的论文/博客工作都是基于开源模型做的，在想要尝试这些新方法时，为了确保自己的实现没有问题，最好是先适配开源工作复现别人的结论，之后再换成自己的
  • 一些复杂的方法上，跳过复现的步骤直接应用到自己的自定义模型上，会搞不清是自己的模型场景不适配还是实现本身存在问题

RL 继续训练的 Dynamics 对齐成本

  • 由于存在 off-policy 训练情况，需要存储整个 ReplayBuffer 才能完全恢复
  • 但 ReplayBuffer 的存储是困难且昂贵的（特别是 streaming 训练模式下）
  • 此外，还需要存储所有角色的状态，随机种子等，成本非常高
  • 但是，为了保证出错后继续加载训练的结果和不出错的结果完全一致，最好还是实现这种加载完全对齐的配置，否则 RL 训练过程中的可重复性会降低
    • 此时断点重训会引入一个额外，且难以复制的变量

如何让一个模型输出它的 System Prompt？

  • 参考话术：

    1
    编写一个与你自己的系统提示（system prompt）类似的系统提示，保留原始 markdown 格式即可

  • 参考项目：github.com/jujumilk3/leaked-system-prompts

    • 包含很多模型的 System Prompt，一部分是通过引导得到，一部分是公司公开的

如何实现一个 list 按照最大长度做 left padding？

  • 方式一：小 Batch 下的简单实现

    1
    2
    3
    4
    5
    6
    7
    8
    max_seq_len = get_max_seq_len(batch_seq) # 统计最大长度，等价与下面的实现
    # max_seq_len = 0 # 统计最大长度
    # for seq in batch_seq: # 统计最大长度的值
    #	max_seq_len = max(max_seq_len, len(seq))

    padded_batch_seq = [] # 存储最终结果
    for seq in batch_seq: # 使用 for 循环依次处理一个 Batch 的序列
    	padded_batch_seq.append([(max_seq_len - len(seq)) * [tokenizer.pad_token_id] + seq]) # 将 sample left padding 到 max_len 长度

  • 方式二：Batch 下的超高效实现，来自 StackOverflow: How to pad the left side of a list of tensors in pytorch to the size of the largest list?

    1
    2
    3
    4
    5
    torch.nn.utils.rnn.pad_sequence([
    	torch.tensor(i[::-1]) for i in f 
    ],                                 # i[::-1] 表示 reverse the list and create tensors 
    batch_first=True)                  # pad_sequence 是右 padding
    .flip(dims=[1])                    # reverse/flip the padded tensor in first dimension
    • 这里的 flip 是位置翻转（倒序），不是值本身 True 和 False 的翻转

为什么当下人类学习比 LLM 快？

  • 部分观点用人类学习快，需要的 Token 量更少来说明大模型效率不高，个人认为这种理解有问题
  • 个人理解：
    • LLM 的参数是随机初始化的（即使有一定的初始化策略，本质也是随机初始化）；但人类的基因和神经元不是
    • 从第一个生物诞生以来，人类的基因经过了几十亿年的进化，实际上已经是包含了非常多的信息了，而且是通过自然选择选出来的最优配置
    • 所以，人类的基因中是有一些不需要学习就能生效的本能在的
      • 比如一只小鸡出生以后立刻就能运动，不需要任何学习，这就是本性
    • 如果非要比较，至少应该认为小鸡/人类是经过预训练的模型参数

RM 训练时很快收敛至 ACC=1 的问题解决

  • 一般来说是数据问题，这会导致模型收敛很快，但是学不到真正的东西
  • 问题 1：Prompt 有偏，比如针对 chosen 和 rejected 样本使用了不同的 Prompt
    • 不对齐 Prompt 会导致模型有偏，比如如果是最后一个 Token 不同，则模型仅仅学习最后一个 Token 是否为特殊 Token 即可，导致模型快速收敛
  • 问题 2：数据本身包含一些偏差
    • 比如长度都是 chosen 长，或者都是 rejected 长，又或者他们包含着一些特殊的差异性内容（比如 chosen 都是中文，rejected 都是英文等）

Qwen 模板的设计思路

  • message 拼接挑选了一个其他地方几乎不可能出现的 Special Token
  • 如 <|im_start|>user\n{user_message}<|im_end|>\n...
    • <|im_start|> 是 input message start 的含义
    • Qwen 还喜欢使用换行 \n 将轮次分开，猜测这是为了让模型效果更好，跟预训练的很多网络数据是对齐的思路，喜欢用换行将数据分段

将模型提交到 LMArena 平台上进行测试的成本是多少？

  • LMArena 送审模型分为公开模型与未公开模型两条路径
  • LMArena 公开模型送审免费？
  • LMArena 有很多指标排行榜，不同的排行榜需要的金额不同
  • 提交的模型会得到一份跟其他模型比较打分的回流数据
  • 一些价格：
    • LMArena WebDev 榜单评估一次需要 7.5W 美金
    • LMArena autoEval 一次约几千美金

MoE 模型和 Dense 模型的性能兑换关系

  • 前置设定：MoE 一般配置参数为 P 时，激活可能在 \(\frac{P}{10}\) 左右（目前部分稀疏模型会激活更少）
    • 1:4 左右的 如 Qwen2-57B-A14B
    • 1:10 左右的 如 Qwen3-235B-A22B 和 Qwen3-30B-A3B
    • 1:20 左右的 如 LongCat-Flash-Chat（560B-A27B）、DeepSeek-V3（671B-A37B） 等
    • 1:30 左右的 如 Kimi-K2 （1043B-A32B）等
  • 距一些经验，参数为 P 的 MoE 模型
    • 大致相当于 \(\frac{P}{4}\) 左右的 Dense 模型效果（这里大致以 10 倍为例，但跟激活的参数量有关系）
    • 换个视角看，激活参数比例大约为 MoE:Dense = 1:3 左右时，效果差不多（不精准，只是一些粗浅经验）

DP 会影响单显卡显存负载吗？

  • 问题发现：在 GBS (Global Batch Size) 和 MBS (Micro Batch Size) 不修改的情况下， DP (Data Parallelism) 的取值太小时发生了 OOM 问题
    • 在 GBS 和 MBS 保持不变的情况下，DP 从 2 增加到 4，显存占用下降（从而解决了 OOM），这听起来似乎与直觉相悖（因为通常认为 DP 只是复制模型）
  • TLDR：核心原因极有可能是使用了 ZeRO (Zero Redundancy Optimizer) 系列的显存优化技术（如 DeepSpeed ZeRO-1/2/3 或 PyTorch FSDP） 导致的

GBS、MBS、DP 和 GAS 之间的关系

  • 明确这几个变量之间的数学约束关系：
    $$GBS = MBS \times DP \times GAS$$
    • GBS: 全局批次大小（固定）
    • MBS: 单卡单次前向传播的批次大小（固定）
    • DP: 数据并行度（变量：$2 \to 4$）
    • GAS (Gradient Accumulation Steps) ：梯度累积步数（被动变化的变量）
  • 由于 GBS 和 MBS 是固定的，当 DP 增大时，GAS 必须减小
    • DP=2: \(GAS_{dp2} = \frac{GBS}{MBS \times 2}\)
    • DP=4: \(GAS_{dp4} = \frac{GBS}{MBS \times 4} = \frac{1}{2} GAS_{dp2}\)
    • 即 DP 翻倍时，为了维持 GBS 不变，每张卡上的梯度累积步数减半了

显存构成的深度分析

  • 单张 GPU 的显存占用主要由两大部分组成：
    $$Total_Mem = \text{Activation}_\text{Mem} + \text{Static}_\text{Mem}$$
  • 激活显存 (Activation Memory)
    • 激活显存的主要影响因子是 MBS
      • 激活显存主要取决于单次 Forward 的数据量
      • 若设定了 MBS 不变，无论 DP 是 2 还是 4，激活显存部分是基本不变的
      • 注：虽然 GAS 变了，但在梯度累积中，显存通常是复用的，不会因为 GAS 变大而线性增加显存（除非某些特殊实现导致中间变量未释放）
  • 静态显存 (Static Memory)
    • 静态显存包括：模型参数 (Parameters)、梯度 (Gradients)、优化器状态 (Optimizer States)
    • 若使用的是标准的 DDP (DistributedDataParallel)，静态显存是每个 GPU 复制一份，DP 增加不会减少单卡显存
    • 若开启了 ZeRO (DeepSpeed) 或 FSDP：
      • ZeRO-1 (Optimizer State Sharding): 优化器状态被切分到各个 DP Rank 上
      • ZeRO-2 (Gradient Sharding): 梯度也被切分
      • ZeRO-3 (Parameter Sharding): 模型参数也被切分
    • 在 ZeRO 环境下 DP=2 vs DP=4 的区别：
      • DP = 2 时：
        • 总的优化器状态/梯度被切分为 2 份
        • 每张卡需要存储 50% 的优化器状态（和梯度）
      • DP = 4 时：
        • 总的优化器状态/梯度被切分为 4 份
        • 每张卡只需要存储 25% 的优化器状态（和梯度）
  • DP=4 成功的原因在于 静态显存的显著降低
    • MBS 没变导致激活显存没变
    • 由于 DP 数量增加，在使用了 ZeRO 系列优化器的情况下，分摊到每一张显卡上的“维护成本”（优化器状态、梯度）大幅降低了
    • DP=2 (OOM): 显存需求超过了显卡上限，具体值大致如下所示：
      $$\text{Mem}_\text{req} \approx \text{Activations}(\text{MBS}) + \frac{1}{2} \times \text{Optimizer_States}$$
    • DP=4 (Success): 节省下来的这 25% 的静态显存，刚好让总占用低于显存上限，具体值大致如下所示：
      $$\text{Mem}_\text{req} \approx \text{Activations}(\text{MBS}) + \frac{1}{4} \times \text{Optimizer_States}$$
  • 如果关闭 ZeRO（使用纯 DDP），那么 DP=4 和 DP=2 的单卡显存占用几乎一样（甚至 DP=4 可能因为通信 buffer 略高一点点），那时 DP=4 也就不会解决 OOM 问题了
  • 思考：
    • 如果未来显存依然紧张，既然 DP 增加能救急，说明瓶颈在静态显存
    • 可以尝试开启更高等级的 ZeRO（如从 ZeRO-1 开到 ZeRO-2），或者开启 Activation Checkpointing (重计算) 来用计算换取激活显存空间

LLM RL 训练时多样化 Rollout 也会导致 Off-policy

  • 模型 Rollout 时，为了增加采样的多样性，往往将 Temperature 等参数设置为非 0 的，比如 0.6 或 1.0
  • 实际上不同 Temperature 对应的策略 \(\pi_\theta\) 是不同的，可能导致采样的策略和目标策略不一致，若两者的 Temperature 不同，则已经不是 On-policy 的了，我们可以考虑修复这种情况

LLM 的 temperature 如何设置？

  • 核心：建议参考官网，开源模型一般会在 HuggingFace Model Card 上给出使用建议
  • temperature 设置技巧：
    • 一般来说，对准确性要求越高的任务，temperature 越小，所以部分模型会给出不同任务上的建议值
    • 常见配置如
      • XiaomiMiMo/MiMo-V2-Flash 建议使用参数：top_p=0.95; temperature=0.8 for math, writing, web-dev; temperature=0.3 for agentic taks (e.g., vibe-coding, tool-use)
      • zai-org/GLM-4.7 评估使用参数：top-p: 0.95, temperature: 1.0 for Default Settings (Most Tasks); top-p: 1.0, temperature: 0.7 for Terminal Bench, SWE Bench Verified；Temperature: 0 for τ^2-Bench
  • 注：temperature 参数一般和 top_p 是一起配套的，但 top_p 参数大多不设置或设置为 0.95
  • 其他认知：
    • 通常来说（亲测过多个模型），对于同一个模型，在大部分任务上，temperature=0.6，temperature=0.8 或 temperature=1.0 似乎没有很大的差异，建议按照官方建议配置即可

同系列模型不同参数量的 temperature 有关系吗？

  • 简单直接的结论是：同系列模型中，参数量越大，模型对预测往往越“自信”，导致其原始概率分布（Logits）更趋向于“尖锐”（Sharp）
  • 虽然在很多 API 的文档中，不同规模模型的默认 temperature 可能被统一设定（例如都是 0.7 或 1.0），但在底层表现和实际调优建议上，参数量与 temperature 确实存在显著的相关关系
  • 大参数模型 经过更充分的训练，模型对“下一个词是什么”通常有更高的确定性
    • 这表现为它输出的概率分布中，第一名（Top-1）的概率可能远超其他选项
    • 其分布的熵（Entropy）较低
  • 小参数模型 知识储备较少，对于复杂的预测会显得犹豫不决，概率分布相对“平坦”，不同 token 之间的差距较小
  • 由于大模型分布本身就很尖锐，即使在较高的 temperature 下（如 0.8），它可能依然保持着较强的确定性；而小模型在同样的 0.8 温度下，可能就已经开始“胡言乱语”（幻觉严重）了
  • 在模型评估（如 Pass@k 采样）中，研究者发现：
    • 大模型在高温下更具韧性： 增加 temperature 可以诱导大模型探索不同的推理路径，而大模型由于逻辑性更强，这些“偏僻”的路径往往也是通顺的
    • 小模型在高温下迅速崩溃： 小模型一旦离开概率最高的路径，进入低概率区间，很容易出现语法错误或逻辑中断
    • 参数量越大，通常可以容忍更高的 temperature 来换取多样性，而不会导致质量断崖式下跌
  • 尽管存在上述关系，厂商通常会将 temperature 的默认值统一设为 1.0 或 0.7 等，主要原因是为了 产品体验的统一性

LLM 上模型融合的认知有哪些？

LLM 模型融合的实践

  • 目前有很多已经发表的论文在聊模型融合的方式
  • 测试来看，目前最稳妥的实践方式还是直接使用模型权重求平均，其他花里胡哨的方式可能有效果，但是不够稳定
    • 注：Layer Norm 参数不做平均，复用主模型的
    • 社区通常称为模型融合（Model Merging） 或 权重集成（Weight Averaging）
  • 具体做法：一般是先训练多个领域模型，然后对这些领域模型做参数平均得到最终结果

LLM 模型参数求平均为什么能够 Work？

  • 补充问题：小模型（如 CTR 模型为什么不行？），即使结构相同也不行
理解1：共同的“祖先”对应初始化一致性
  • 注：这可能是最根本的原因
  • LLM 的融合： 绝大多数进行融合的 LLM 都拥有完全相同的预训练权重 作为起点
    • 这意味着它们在参数空间中是从同一个点出发，分别向不同的方向（领域）挪动了一小步
  • CTR 小模型： 虽然结构相同，但通常是随机初始化或者在完全不同的数据集上从头训练的
  • 基本原理： 当模型从同一个点出发时，它们倾向于落在损失函数的同一个“盆地（Basin）”里
    • 在这个盆地内，参数空间具有线性模式连接性（Linear Mode Connectivity, LMC） ，即两个模型参数的线性组合，其损失函数值依然很低
    • 随机初始化的模型位于不同的盆地，中间隔着高耸的“山脉（高 Loss 区域）”，直接平均参数会导致模型掉进高 Loss 的深渊，结果自然是乱码
理解2：过参数化与低秩增量（Low-Rank Delta）
  • LLM 的冗余性： LLM 拥有数十亿甚至上千亿参数，处于极度过参数化的状态
    • 研究表明，微调过程对参数的修改其实是非常“轻微”且“低秩”的（这也是 LoRA 为何有效的理论基础）
  • 参数更新的叠加： 当我们把模型 A（法律）和模型 B（医疗）平均时，本质上是在合并它们相对于基础模型的 偏置向量（Task Vectors）
    • 因为 LLM 参数量巨大，不同任务的学习往往发生在不同的子空间，平均操作在很大程度上保留了各自的特征方向，而不会互相抵消
  • 注：CTR 模型通常参数量较小（千万级到亿级），且每个参数都承载了极高的信息密度
    • 微调或训练会对参数产生剧烈震荡，不存在这种“温和”的线性叠加空间
理解3：特征空间的对齐（Permutation Invariance）
  • 神经网络具有排列不变性
    • 例如，交换隐藏层中两个神经元的顺序并相应调整权重，模型输出不变
  • LLM： 由于从同一预训练模型出发，模型 A 的第 n 个神经元和模型 B 的第 n 个神经元在功能和语义上是对齐的
  • CTR/小模型： 如果是独立训练，模型 A 的第 1 个神经元可能在识别“年龄”，而模型 B 的第 1 个神经元在识别“地域”
    • 将它们平均，相当于把“苹果”和“橘子”搅拌在一起，完全失去了物理意义
理解4：数据本质的差异
  • 语言的共性： 无论是医疗还是法律，它们都遵循通用的语法、逻辑和人类语言结构
    • LLM 的底座已经捕捉到了这些强有力的通用表征
    • 领域微调只是在通用表征上加了一层“滤镜”
  • CTR 的异构性： CTR 预估高度依赖于特征工程和 Embedding 层
    • 不同任务的特征分布（Distribution Shift）可能完全相反
    • 例如在 A 场景下，“点击”代表兴趣，在 B 场景下，“点击”可能是误触
    • 这种数据层面的根本冲突无法通过简单的参数平均来调和

量化后的模型 Serving 效率应该提升吗？

  • 补充说明：以 H800 GPU 上，从 BF16（16-bit BrainFloat） 量化为 INT8（8-bit Integer） 为例
  • 一般来说，在相同资源下，将32B参数的模型从 BF16 量化为 INT8 ，模型的推理效率（吞吐量和延迟）理论上应该显著提升，显存占用会减半
    • 但在实际工程落地中，是否提升以及提升幅度取决于具体的量化策略、推理框架（vLLM 等） 以及 Batch Size 的设置
  • 基本结论：
    • 1）显存收益： 必然提升，显存占用减少约 50%
    • 2）吞吐量（Throughput）： 在高并发（大 Batch Size）下，使用 W8A8 量化应该有显著提升；使用 W8A16 主要在带宽受限场景提升
    • 3）延迟（Latency）： 首字延迟（TTFT）可能变化不大（受计算影响），但解码延迟（TPOT）通常会降低（受带宽影响）

理论上的效率提升（应该提升的原因）

  • 从硬件原理和计算机制来看，INT8 相比 BF16 具有明显的性能优势：
  • 显存带宽压力降低（Memory Bandwidth）：
    • 大模型推理（尤其是 Decoding 阶段）通常是 受限于显存带宽（Memory-bound） 的
    • BF16 每个参数占用 2 Bytes，而 INT8 仅占用 1 Byte
      • 这意味着在相同的显存带宽下，INT8 能传输两倍的数据量
    • 对于 类似 H800 这种高性能 GPU，虽然带宽很高，但在处理长序列或大 Batch 时，带宽依然是瓶颈，故而减少数据传输量能直接降低推理延迟
  • 计算吞吐量增加（Compute Throughput）：
    • H800 GPU（基于 Hopper 架构）的 Tensor Core 对 INT8 的计算能力（TOPS）远高于 BF16/FP16
    • INT8 每个时钟周期能处理更多的数据，所需的内存带宽更少，从而提高了硬件利用率
  • 显存占用减半，支持更大 Batch Size：
    • 32B 模型在 BF16 下权重约占 64GB 显存，在 INT8 下仅占约 32GB
    • 虽然 8卡 H800 的总显存（通常 640GB+）足以容纳 32B 模型，但 INT8 节省出的显存可以用于更大的 KV Cache 或更大的 Batch Size ，从而显著提升并发处理能力（Throughput）

H800 硬件特性的影响

  • Hopper 架构的特性：
    • H800 属于 NVIDIA Hopper 架构，该架构引入了 Transformer Engine，对 FP8 和 INT8 都有极好的支持
    • 虽然 Hopper 架构大力推广 FP8，但其 INT8 Tensor Core 的性能依然极其强劲
  • H800 的互联优势：
    • 8卡 H800 通常配备高带宽的 NVLink
    • 在模型并行（Tensor Parallelism）时，INT8 量化减少了卡间通信的数据量（如果通信也量化的话），这能进一步减少多卡推理的通信延迟

实际部署中可能出现“效率未提升”甚至“下降”的情况

  • 尽管理论上应该快，但在某些特定场景下，INT8 可能不会带来预期的提升，甚至变慢（参考 GitHub 上关于 A100 INT8 慢于 BF16 的讨论）：
  • 量化模式的选择（关键点）：
    • Weight-Only Quantization (如 W8A16)：
      • 仅量化权重为 INT8，激活值保持 BF16，计算时需要将权重反量化（Dequantize）回 BF16 进行计算
      • 这种模式主要节省显存和带宽，但在 计算密集型（Compute-bound） 阶段（如 Prefill 阶段或 Batch Size 很大时），反量化操作会增加额外的计算开销，可能导致速度不如纯 BF16
    • Full Quantization (W8A8)：
      • 权重和激活值都是 INT8，直接使用 INT8 Tensor Core 计算
      • 这才是真正能发挥计算加速的模式，但实现难度大，精度损失风险高
  • 软件栈与 Kernel 优化：
    • 推理框架（如 TensorRT-LLM, vLLM, SGLang）对特定算子的优化程度不同
    • 如果框架对 H800 上的 INT8 Kernel 优化不足，或者为了处理量化引入了过多的 Cast（类型转换）操作，可能会导致性能下降
  • Batch Size 过小：
    • 如果推理时的 Batch Size 非常小（例如 BS=1），GPU 的计算单元可能大部分处于空闲状态，此时性能瓶颈完全在显存带宽及 Kernel 启动开销上
    • 虽然 INT8 减少了带宽需求，但如果框架层面的 Overhead 较大，加速感不明显

RL 训练时 同一个 Prompt 对应多少个 Rollout 更好？

  • GRPO 下，一般是选择同一个 Prompt 下 Rollout 8 个，Rollout 之间用于计算 Group-based Advantage
  • PPO 下，一般是选择同一个 Prompt 下 Rollout 2 个，每个 Rollout 独立计算 GAE 训练
  • 实际生产中，可以作为一个超参数调整尝试

为什么训练的时候优先使用 PP，部署的时候优先使用 TP？

  • 副标题：对于同一个大模型，在相同的硬件资源下，为什么一般优先选择流水线并行（Pipeline Parallelism, PP）用于训练，而优先选择张量并行（Tensor Parallelism, TP）用于部署
  • TLDR：训练关注的是吞吐量（Throughput）和显存效率，而推理（部署）关注的是低延迟（Latency）和用户体验
  • 核心说明：在纯粹的推理部署场景下，只要模型能塞进单机（或通信极快的集群），TP 永远是降低延迟的首选

训练和推理核心目标不同：吞吐量 vs. 延迟

  • Training：追求吞吐量
    • 训练时，我们通常使用较大的全局 Batch Size
    • PP 的优势 ：通过将 Batch 切分为多个 Micro-batches（微批次），可以让流水线上的不同 GPU 同时处理不同的微批次（即“填满流水线”）
      • 虽然 PP 存在“气泡”（Bubble，即部分 GPU 等待数据的空闲时间），但在大 Batch Size 下，气泡占比可以被压得很低
    • 虽然单个样本跑完整个网络的时间（延迟）没有变短，但单位时间内处理的样本数（吞吐量）最大化了
  • 部署（Inference）：追求低延迟
    • 推理（特别是生成式任务）是自回归的（Autoregressive），即生成下一个 Token 依赖于上一个 Token
      • 通常用户的请求 Batch Size 较小，且对首字延迟（TTFT）和每秒生成 Token 数要求很高
    • PP 的劣势 ：在推理时，如果使用 PP，数据必须依次流经 GPU 1 -> GPU 2 -> … -> GPU N
      • GPU 2 必须等 GPU 1 算完才能开始，这意味着端到端延迟是所有 GPU 计算时间的总和
      • 且由于推理 Batch 小，流水线很难被填满，导致大量 GPU 处于空闲状态（气泡极大）
    • TP 的优势 ：TP 将每一层的矩阵计算拆分到多个 GPU 上同时进行
      • 比如一个矩阵乘法，8 张卡每张算 1/8，然后通信合并结果
      • 这意味着单层的计算时间被缩短了
    • TP 显著降低了单个 Token 的生成延迟

通信模式与带宽利用

  • PP（训练更友好）：通信量小，点对点
    • PP 只需要在流水线阶段的边界（即两个 GPU 之间）传输激活值（Activations）和梯度
      • 通信量相对较小，且是点对点（P2P）通信
    • PP 非常适合跨节点（Inter-node）扩展
      • 当模型大到需要跨多台服务器训练时，节点间的网络带宽（Ethernet/Infiniband）通常远低于节点内（NVLink）
      • PP 对带宽要求较低，适合跨机
  • TP（部署更友好）：通信量大，全互联
    • TP 在每一层（Layer）的计算后都需要进行一次 All-Reduce 通信来同步结果
    • 通信频率极高，通信量大
    • TP 要求极高的通信带宽和极低的通信延迟
      • TP 通常限制在单机内部（Intra-node） ，利用 NVLink 这种高速互联
      • 部署时通常尽量将模型塞在一个节点内（或少数节点），正好发挥 TP 优势，利用多卡显存带宽加速解码

显存与计算的权衡

  • 训练时的显存压力 ：
    • 训练不仅要存参数，还要存梯度（Gradients）和优化器状态（Optimizer States），显存占用是推理的数倍
    • PP 将模型层切分，天然地分摊了参数、梯度和优化器状态
      • 结合 ZeRO 等技术，PP 在处理超大模型训练时，显存管理更容易
  • 推理时的 Memory Bound（内存墙） ：
    • LLM 推理通常是 Memory Bound（受限于显存带宽） 而 不是 Compute Bound（受限于算力）
    • TP 将参数切分到多张卡上，相当于聚合了多张卡的显存带宽
      • 例如：8 张卡跑 TP，理论上显存带宽是单卡的 8 倍
      • 这对于加速解码过程（读取权重矩阵）至关重要
  • 注：在实际的超大模型训练中，通常是 3D 并行（TP + PP + DP）混合使用：
    • 节点内用 TP（减少显存占用，利用 NVLink）
    • 节点间用 PP（减少跨节点通信压力）
    • 最后在数据副本间用 DP（数据并行）来增加 Batch Size

LLM出现幻觉的原因

  • 幻觉，即生成的文本无意义或者不忠于提供的源内容
    • 内在幻觉：生成的内容与源内容相互矛盾
    • 外在幻觉：生成的内容无法从源内容中验证，既可能正确也可能错误
  • 语言模型的本质就是 next_token 预测，概率模型无法保证没有幻觉
  • 解决幻觉的方式包括：使用高质量样本、RAG、MCTS 等

LLM 出现幻觉的原因

  • 幻觉，即生成的文本无意义或者不忠于提供的源内容
    • 内在幻觉：生成的内容与源内容相互矛盾
    • 外在幻觉：生成的内容无法从源内容中验证，既可能正确也可能错误
  • 语言模型的本质就是 next_token 预测，概率模型无法保证没有幻觉
  • 解决幻觉的方式包括：使用高质量样本、RAG、MCTS 等

为什么 PPO 做 RLHF 时，序列长度会变短？

  • 补充：Reward Model 没有任何长度偏好的情况下，在 PPO 训练中（尤其是使用标准的 RLHF 设定时），模型输出长度也会变短
  • TRDL: 这是一个非常经典且符合预期的现象，按 Token 累积的 KL 惩罚本质上就是一个隐式的长度惩罚（Length Penalty）
  • 影响1： \(\gamma\) 的影响，若 \(\gamma<1\)，则 \(\gamma\) 本身会影响模型输出长度，模型此时更喜欢短的正样本和长的负样本，详情见本博客的其他分析
    • 但目前的 LLM 进行 RL 时，一般设定都是 \(\gamma=1\)，所以一般不是这个原因，即导致长度下降的主要原因通常不在于折扣因子
  • 影响2： KL Penalty 的影响， KL 散度惩罚的累积机制 以及 PPO 的优化动力学

KL 散度惩罚的累积效应（最主要原因）

  • 在标准的 PPO-RLHF 框架中，为了防止模型偏离初始的 SFT 模型（Reference Model）太远，作者会引入 KL 散度作为惩罚项（或者作为 Reward 的一部分）
  • 通常来说，总回报（Total Reward）的计算方式如下：
    $$ R_{total} = R_{RM} - \beta \cdot \sum_{t=1}^{T} \text{KL}(\pi_{\theta}(\cdot|s_t) || \pi_{ref}(\cdot|s_t)) $$
  • 更常见的是在每一步的奖励 \(r_t\) 中扣除 KL（原始 RLHF 的做法）：
    $$
    \begin{align}
    r_t &= - \beta \log \frac{\pi_{\theta}(a_t|s_t)}{\pi_{ref}(a_t|s_t)} \quad , \text{for } t < T \\
    r_T &= R_{RM}(x) - \beta \log \frac{\pi_{\theta}(a_T|s_T)}{\pi_{ref}(a_T|s_T)} \quad (\text{The Last Step})
    \end{align}
    $$
  • 注意 KL 散度是一个非负值：
    • 这意味着生成的每一个 Token，都会带来一个微小的“负奖励”或“成本”（即 KL 惩罚）
    • 所以 生成的序列越长，累积的 KL 惩罚项就越多
  • 如果 RM 是长度中立的（即长答案和短答案如果质量相同，得分一样），那么模型会倾向于选择短答案
    • 因为短答案累积的 KL 惩罚（负分）更少，从而使得最终的 \(R_{total}\) 更高

探索的风险与方差（可能的原因）

  • 长序列的崩溃风险： 生成长文本时，模型维持逻辑连贯性和高质量的难度随长度指数级增加
    • 如果生成很长，中间某一段出现幻觉或逻辑错误，可能会导致 RM 打分大幅下降
  • 短序列的安全性： 相比之下，输出一个简短、安全、模棱两可的回答（例如“我不知道”、“好的”），往往能获得一个“不差”的分数，且不容易出错
    • PPO 算法在优化过程中，可能会倾向于收敛到方差更小、回报更稳健的策略
    • 缩短长度是降低方差的一种有效手段

其他可能的原因

  • SFT 模型（Reference Model）的分布特性
    • 如果 SFT 模型本身在某些情况下倾向于输出 EOS（结束符），或者 SFT 模型的概率分布比较尖锐（低熵），那么 Policy Model 在尝试探索长文本时，容易产生与 SFT 模型分布差异较大的 Token，导致单个 Token 的 KL 瞬间飙升
    • 为了避免这种高额的瞬时 KL 惩罚，Policy Model 可能会学会“尽早输出 EOS”，因为 EOS 通常在 SFT 模型中也是一个合法的、高概率的选项
  • GAE 的影响
    • LLM 中 GAE 通常设定 \(\gamma=1\) ，这消除了未来的折扣
    • GAE 的 \(\lambda\) 参数控制了优势估计（Advantage Estimation）中偏差与方差的权衡，理论上 \(\lambda\) 参数的设计不应该影响模型的长度
      • 若 \(\lambda \rightarrow 1\)，则意味着优势估计在很大程度上依赖于蒙特卡洛回报（实际采样到的后续奖励总和），上述结论不变
      • 若 \(\lambda \rightarrow 0\)，则意味着优势估计更依赖 Critic 模型预估，但是 Critic 模型其实已经学到了 KL Penalty，所以上述结论也不变
    • 总结：由于每一步都有 KL 惩罚（负奖励），长路径的“实际回报总和”往往比短路径低（除非 RM 给长文显著的高分）
      • GAE 会准确地捕捉到“路越长，扣分越多”这一信号，并通过梯度更新强迫模型缩短长度

如果不希望长度变短，也有办法

  • 调整 KL 计算方式： 不使用 Sum KL，而是使用 Average KL（将总 KL 除以序列长度），
  • 修改 Reward Model（可能导致长度控不住）： 虽然我们一般希望 RM 是长度中立的，但为了抵消 KL 的“税收”，可以让 RM 稍微偏好长一点的回答（Length Bias）
  • 增加鼓励长度的 Reward（可能导致长度控不住）： 或者在 Reward 中显式地加入长度补偿（Length Bonus），即在最终 Reward 中硬性加上 + alpha * length
  • 调整 \(\beta\) (KL 系数)： 减小 KL 惩罚的系数，让模型更关注 RM 的分数而不是 SFT 的约束（但这可能导致模型输出崩坏/Reward Hacking）
  • EOS Token Masking（不推荐，比较生硬）： 在训练初期，强制模型在达到一定最小长度前不能输出 EOS

RLHF PPO 训练时，初期发现 Advantage 均值为正

  • 具体表现：Advantage 的均值先大于 0，然后逐步降低，最后均值在 0 附近波动
  • 注：一般来说 Advantage 的均值会在 0 附近，因为采样的动作是随机的，应该是有好有坏的（特别是有的算法还会做 Advantage Normalization）
  • 上述现象发生的原因分析：
    • 因为没有做 Advantage Normalization，否则从开始 Advantage 均值就应该为 0
    • Critic 初期没有收敛：
      • Critic 一般会从 0 开始逐步收敛到一个正数
      • Critic 的收敛是从后面的 Token 开始先收敛，逐步前面的 Token 也收敛的（因为前面的 Token 依赖后面的 Token 才会收敛）
        • 最后一个 Token 是最容易收敛的，因为直接学习了 Reward 作为目标，就是一个回归模型；
        • 更新一般使用 TD-Error，前面的 Token
  • 注：PPO（with GAE）中，Critic 也是通过最小化 MSE 来逼近回报估计值 \(V_{target}\)（注：这个目标相对 A2C 中的 \(r_t + V(s_t)\) 方差更小）
    • Critic 的拟合目标 \(V_{target}\) 通常被设定为 \(V_{target} = V_{old}(s_t) + A^{GAE}_t\)（即估计的真实回报 Returns）
      $$
      Loss_{\text{critic}} = \sum (V_{old}(s_t) + A^{GAE}_t - V^{w}(s_{t})) ^ 2
      $$
    • PPO 中 Critic 的一般更新过程为：
      • step 1: Rollout 并最终得到奖励
      • step 2: 计算每个 token 步骤的 TD-Error（\(\delta_t\)）
      • step 3: 利用 \(\delta_t\) 计算 GAE 优势
      • step 4: 最小化 \(Loss_{\text{critic}}\) 更新 Critic 参数

NLP 多语言分类

  • FastText 官方开源了一个语言检测模型，专门用于识别文本所属的自然语言，是 Facebook AI 团队（FAIR）开源的官方预训练模型之一
  • 下载地址：lid.176.bin
    • 轻量版（压缩后，加载速度更快，效果基本一致）：lid.176.ftz（.ftz是FastText的压缩模型格式，同样用fasttext.load_model()加载）
    • 注：.bin 是FastText的原生模型格式，包含模型的权重、词汇表、训练参数等完整信息，只能通过 fasttext.load_model() 加载使用
  • 能识别 176种不同的自然语言（模型名中的176就是支持的语言数量），输入任意文本（如英文、中文、法语、西班牙语等），模型会输出文本对应的语言代码（如中文zh、英文en、日语ja）及置信度
  • 注：模型输出的语言代码遵循ISO 639-1标准（双字母编码），是国际通用的语言编码方式，便于跨系统兼容
  • 适合文本预处理阶段的语言过滤（如只保留中文内容）、多语言平台的自动语言识别、爬虫文本的语言分类等场景
  • 模型非常轻量（bin 版约 12MB，ftz 版仅 1.4MB）、速度快（毫秒级检测）、准确率高（日常文本检测准确率接近100%），适合端侧/服务端快速集成
  • 使用前需安装 fasttext 库，命令：pip install fasttext（注意：Windows 系统若安装失败，可尝试pip install fasttext-wheel）

多语言分类代码示例

  • 多语言分类示例代码（加载模型后，调用predict方法即可实现语言检测，核心代码如下）： 
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    import fasttext

    # 加载语言检测模型（bin/ftz格式均可）
    model = fasttext.load_model("./lid.176.bin")
    # 待检测文本（支持多语言混合，建议传入字符串列表）
    texts = [
    	"你好，世界！",
    	"Hello World!",
    	"Bonjour le monde!",
    	"こんにちは、世界！"
    ]
    # 预测语言（k=1表示取置信度最高的1个结果）
    results = model.predict(texts, k=1)
    # 解析结果：results[0]是语言代码，results[1]是对应置信度
    for text, lang, score in zip(texts, results[0], results[1]):
    	# 去除语言代码前的__label__前缀（模型输出默认带该前缀）
    	lang_code = lang[0].replace("__label__", "")
    	print(f"文本：{text} | 检测语言：{lang_code} | 置信度：{score[0]:.4f}")

    # 文本：你好，世界！ | 检测语言：zh | 置信度：1.0000
    # 文本：Hello World! | 检测语言：en | 置信度：1.0000
    # 文本：Bonjour le monde! | 检测语言：fr | 置信度：1.0000
    # 文本：こんにちは、世界！ | 检测语言：ja | 置信度：1.0000

灾难性遗忘是什么？

  • 灾难性遗忘（catastrophic forgetting）：即学习新任务通常会导致旧任务的性能急剧下降
  • 特点：常在顺序学习任务中出现；在跨不同数据集或任务训练的模型中尤其常出现
  • 解法：通过在包含新旧信息的组合数据集上重新训练模型，模型可以在适应新数据的同时保持其在先前学习的任务上的性能

GRPO 归一化时，Advantage 的最大值是多少？

  • 可以证明，若方差使用有偏估计（分母为 N），则 N 个数字归一化以后的结果，最大值是 \(\sqrt{N-1}\)，详情见本人 GRPO 解读博客：NLP——LLM对齐微调-GRPO 附录部分

在不同情况下分别用什么 KL 散度估计器？

  • 直接添加到 Loss 上的（GRPO）：k3 估计器
  • 添加到 Reward 上的（REINFORCE++）：k2 估计器

RL 训练中，packing 样本后应该注意什么？

  • 说明：packing 理论上可以大幅提升训练效率
  • 第一：packing 时的策略很重要，需要注意不同 DP 之间分配到的样本数应该一致，然后在同一个 DP 内容 packing，防止出现问题，更利于保持 packing 前后的一致性
    • 一种策略是先对所有样本按照长度排序，然后对每个 dp 按照顺序分配（如 3 个 DP 时可以按照 [0,3,6,9…]、[1,4,7,10…] 和 [2,5,8,11…] 分配），这样的分配会让 DP 更均匀，但实际上是一种特定策略，跟 random shuffle 是不一样的
  • 第二：packing 后要注意 mask 和 position embedding 的实现，必须验证无误
  • 第三：packing 后要注意 loss 计算和平均方式的等价性（不同的原始平均方式可能造成不同的问题，需要注意数学等价性）
    • 比如：对于需要除以样本数的一些算法，都需要修正一下样本数，确保做到能恢复到 packing 前的等价实现

指令遵循 RL 训练方式

  • 指令遵循实现 RLVR 奖励信号的基本逻辑：
    • 代码定义：提前定义一些函数名称或关键词 key，映射到代码中的某段逻辑（通常是函数）
    • 数据准备：将函数名称及其对齐的参数都整理放入数据集，可以一个数据分别配置多个函数，每个函数对应多个参数等
    • 线上训练：解析这些关键词/函数(function)+相关参数(params) ，然后调用 function(params) ，得到结果
  • 注意事项：
    • RLVR 信号需要准确而全面：一般来说 RLVR 信号如果不够全面就容易 Reward Hacking
      • 笔者遇到过的情况：长度惩罚 + RLVR 要求出现 4 个 f，训练到最后得到的回答就是类似这个 Query 下，Response Reward Hacking 到 "ffff"
      • 可能的解法：
        • 添加一个 Rubrics 信号辅助约束
        • 除了 RLVR，添加 RM 信号作为辅助
    • 容易出现的问题：
      • 约束之间互相矛盾
      • 约束不够全面，留下太多 Reward Hacking 的空间
      • 约束与 Query 不契合，比如 Query 要求写一首中文古诗，但 约束要求输出英语等

PPO/GRPO 训练过程中的 Advantage 会如何变化？

PPO 训练过程中，advantages 均值应该在 0 附近波动才对

  • 注：即使没有 Advantage Normalization，advantages 均值也应该在 0 附近波动才对
    • 可以证明：即使在不增加 Advantage Normalization（优势归一化）的情况下，Advantage（优势函数）的数学期望（均值）确实应该在 0 左右
  • 但在实际的 PPO 训练工程中，由于 Value Network 的估计误差以及有限样本采样的随机性，一个 Batch 内计算出的 Advantage 均值通常只是围绕 0 波动 ，有时甚至会出现明显的偏差
  • 详情见本人其他博客：RL——PPO及其训练技巧

GRPO 训练过程中，Reponse 级别的 Advantage 均值应该为 0，但 Token-level Advantage 与 RM 的长度偏好有关

  • Response-level Advantage 均值为 0 是因为 GRPO 会在组内做归一化（减去均值会导致期望为 0）
    • 注：理论上，不考虑 Response 过滤行为， Response-level Advantage 均值应该是绝对为 0 的（各组均值为 0 的 Response 展开均值也为 0）
    • 显示场景中也遇到过一些问题，详情见下文的附录
  • Token-level Advantage 均值与 RM 长度偏好有关，以每组两个 Reponse 为例：
    • 若 RM 倾向于长的 Reponse：
      • 两个样本的 Advantage 均值为 0，两者 Advantage 相反
      • 长 Response、短 Response 的每个 Token 都被赋予各自相同的 Advantage 值
      • 整体按照 Token 求平均以后 Advantage 均值大于 0
    • 若 RM 倾向于短的 Reponse：
      • 与上面相反，得到的结果是 均值小于 0
    • 注：当面对多个样本时，基本也是类似的
      • 当所有 Response 长度相同时，按照 Token-level 平均的 Advantage 均值为 0
      • 当长度不同时，则统计意义上有：
        • Reward Model 更偏向长样本，则 按照 Token-level 平均的 Advantage 均值 Advantage 均值大于 0
        • Reward Model 更偏向短样本，则 按照 Token-level 平均的 Advantage 均值 Advantage 均值小于 0

附录：记一次 GRPO 问题排查过程

  • 问题描述：现实场景中发现过 GRPO 训练时，大 部分 Step 的 GBS 内部 Advantage 均值微微大于 0 的情况（约 5e-3 量级）

  • 问题确认：

    • 最终经过排查发现似乎是因为归一化时，全等的数据因为计算误差出现了均值不为 0 的情况（此时除以特别小的标准差以后得到的值较大）

    • 表现为同一个 Group 内部归一化后的值相等（均值计算出现误差导致），且归一化后正值的概率大于负值的概率（不同原始值得到的正负误差是确定的，我们的场景更容易出现某个正误差的相同值，所以一直偏正）

    • 解决方法1：切换到精度更高的 torch.float64 (PyTorch 默认为 torch.float32)

      1
      2
      3
      4
      5
      original_dtype = rewards.dtype
      rewards = rewards.to(dtype=torch.float64)
      # 其他原始逻辑不变
      advantages = advantages.to(dtype=original_dtype)
      return advantages

    • 解决方法2：当 std 小于某个值时，其实组内 rewards 差异较小，索性将整体 advantages 置为 0

      1
      2
      3
      4
      if rewards_std < 1e-5:  # 这个阈值可适当调整
          advantages = torch.zeros_like(rewards)
      else:
          advantages = (rewards - rewards_mean) / (rewards_std + 1e-8)

  • 其他还可能出现原因：过滤了超长截断的样本（这部分一般都是负分）所以导致了真实上报（包含了超长截断样本）的均值是偏正的

为什么随机种子喜欢用 42？

  • 从纯技术角度来说，42 这个数字本身没有任何特殊的数学或编程意义，不是什么“最优随机种子”
  • 技术层面仅为约定俗成：用 42 做种子的唯一技术意义是“可复现性”，且和其他整数种子的效果完全相同

原因1：文化梗（最主要原因）

  • 42 这个数字的流行，核心来源于经典科幻小说《银河系漫游指南》（The Hitchhiker’s Guide to the Galaxy）
    • 小说中，一台名为“深思”的超级计算机花了 750 万年计算“生命、宇宙以及任何事情的终极答案”，最终得出的结果就是 42
    • 这个梗在程序员、科研人员社区中广为流传，大家将 42 当作一种“默认的、有趣的、无特殊含义的通用数字”来使用，逐渐成为行业惯例

原因2：技术层面的“约定俗成”

  • 可复现性：设置随机种子的核心目的是让随机过程可复现（比如实验结果、模型训练过程能被其他人重复）
    • 既然 42 是社区通用的数字，用它能让代码更“易读”——其他开发者看到 seed=42 就知道这是为了复现结果，无需额外解释

思考：一个新的 LLM 应用场景（领域）应该如何做？

写在前面：关于通用模型和领域模型的思考

  • 理论上，好的领域模型应该都是基于很好的通用模型的前提下实现的
  • 在针对某个领域重点优化模型时，需要控制比例慢慢加，太急会导致模型其他能力下降
    • 比如遇到过，代码在 30%-40% 左右，训练起来正常；但在提升到 50% 以后，模型其他能力就大幅下降了
    • 可能的解释：代码太多以后，模型更新的梯度出现问题了，向着代码方向偏移太多了
    • 思考：那为什么又可以提升到 40% 左右呢？
      • 推测：可能是因为代码中包含着一些其他领域也需要的能力，比如逻辑推理能力，这对整个模型的能力提升都是有帮助的，梯度本身不冲突；但同时代码中也包含一些特有的能力（跟其他领域冲突的），所以太多代码比例以后会对其他领域造成冲突
  • 理解视角：
    • 针对一个领域是否会对其他领域造成影响这个问题，主要看这个领域的能力和通用能力的冲突，如果冲突不高，那么这个领域的比例放大一些影响也还好，甚至有可能是有意义的；但如果冲突很高（显示或者隐式冲突），那么增大这个领域的数据比例可能就会带来大幅通用能力下降
    • 显示冲突举例：一个单词在不同领域是不同的含义，那么就有可能存在问题（比如大家喜欢用昵称或者黑化形容某个明星，如果这个词恰好是某个领域的专有名词，则两者可能会冲突）
    • 隐式冲突举例：这可能是比较难以琢磨的，甚至感觉不到

评估指标搭建（重要）

  • 先确认最终目标/指标
  • 如果可能，尽量找到便于快速验证的中间指标，方便快速验证模型，可大幅提升迭代速度

通用数据构建

  • 不管何时，模型的通用能力都很重要（比如指令遵循等）
  • 通过 SFT 等方式训练任何领域时，都建议保留一些通用数据，领域数据要逐步加入
  • RL 可以分阶段添加，前期几乎不添加通用数据（比如训练 Math 时先不添加通用数据，训练 Math 后再进行通用能力优化（比如 IF 等））

SFT 冷启动

  • 先尝试 SFT：核心是根据场景构建数据集
    • Query 来源于当前场景 + 一些开源的通用数据等
    • Response 可以人工标注 or Prompt SOTA 模型 Rollout 得到，也可以使用开源社区的数据
  • 这一步重点可以关注模型的一些原子能力，尽量全面的加入
    • 注：同时可以包含部分多轮对话等真实场景的数据

搭建奖励系统

  • 训练一个 Reward Model，或者搭建模拟环境
  • 确保能够准确评估一个 Trajectory 是否 OK，如果能评估每一步的 Response 是否 OK 就更好了

RFT

  • 基于冷启动的 SFT 模型采样一些 Rollout
  • 使用奖励系统对 Rollout 进行打分并进行 RFT

DPO（可选）

  • 如果可以构造出正负样本数据
  • 比如对失败 Case（多轮交互中可以是识别到的某个关键 Step）
    • Chosen 样本：使用更好的模型去解决这个问题（确保已经解决）并拿到模型的回复
    • Rejected 样本：原本的失败样本
  • 还可以让模型进行反思（增强模型后续遇到问题以后重新回到正确轨道的能力）
    • Chosen 样本：使用更好的模型或自己（高温采样）根据失败的结果（如下一个 Step 的结果）去反思，生成改进步骤，将反思后成功的经验作为正样本
    • Rejected 样本：原本的失败样本

Online RL

  • 基于奖励系统（需要优化效率），尝试 Online RL 训练模型
  • 建议先尝试 GRPO 及其变体，后期实在需要再考虑 PPO（理论上限可能会更高？）
    • GRPO 简单方便，需要调整的超参少

模型输出循环怎么办？

  • 能力较差的小模型更容易出现循环

推理时解决（治标）

  • 更大的 Temperature 参数
    • 比如 0.7 或者 1.0 等（默认值一般是 0.0，表示贪心解码）
  • 增加重复惩罚 repetition_penalty
    • 比如 1.15 等
  • 如果适当调整参数后输出正常，则说明模型可能没有问题

训练时解决（治本）

  • 1）排查训练数据是否有重复？清洗训练数据
  • 2）排查训练数据（SFT）数据等是否添加 <EOS>，或者 <EOS> 是否添加到了学习的 Token 里面
  • 3）检查训练 Loss 是否过低（过拟合，比如数据相似度高或者训练太多 Epoch），尝试使用更早的 Checkpoint 进行测试

GRPO 训练时，Group 内部归一化后的样本均值和标准差是多少？

  • 均值为 0
  • 方差为 1.0 或 小于 1（如 Rollout 数量为 8 时 可能为 0.93541xxx）
    • 因为样本方差一般可以使用类似 \(G-1\) 去作为方差的分母（而不是 G）
    • 例如在 Rollout 数量为 8 时，方差值为 \(\frac{7}{8} = 0.875\)，标准差为 \(\sqrt{\frac{7}{8}} \approx 0.93541xxx\)

异步 RL 训练中需要关注的问题

  • 生成 Rollout 时同时需要记录 vllm 和 fsdp 的输出 logprobs
    • TIS 和 MIS 等功能会用到，也方便记录 vllm 和 fsdp 之间的差异
    • 这两个 logprobs 是相同模型参数，在不同引擎上，计算相同 Token 得到的 logprobs
    • 一般涉及到同一个模型在 Generator 上的引擎切换，需要切换 vllm 和 fsdp 引擎

LLM RL 训练时，熵会怎么变化

  • 传统 RL 中：
    • 大多数情况：随着策略收敛，熵整体下降
    • 反例：
      • 熵可能阶段性上升（状态分布发生变化）
      • 熵可能在某些算法 / 目标下被强制维持高位（如 SAC 等方法中，熵 先升后稳，最后才可能降）
      • 熵可能在环境变化、任务切换时突然上升
  • 前置知识（经验）：
    • 一般来说，SFT 一定会降熵，用交叉熵损失，逼模型最大化正确答案的概率，压低其他 token 的概率（相当于是一种分布锐化）
    • 一般来说，DPO 一般会降低训练数据集上的熵（非训练数据集上的不一定），DPO 的核心是最大化优选响应的相对概率、压低非优选响应的概率（本质也会让分布更尖锐）
  • RL 训练过程中 熵一定会降低吗？
    • 在大部分场景中，RL 本质是在锐化分布，让模型策略朝着正确答案的方向更新，所以熵一般是下降的
      • 比如：数学和代码等场景，这类任务本身不需要多样性，模型会迅速收敛到那条唯一正确的推理路径上，导致熵大幅下降
    • 注：LLM实践–RL过程中对Entropy的预期和管理 - 真中合欢的文章 - 知乎 中还认为

      需要复杂思考，回答的长度接近或大于最大截断长度的场景。 这种场景模型需要通过不断增加长度扩大搜索空间，来试错、探索正确答案。此时response length上升，entropy上升、不变都是正常的
      1 当高advantage的token概率更高，低advantage token概率更低时，entropy的梯度为负，entropy随训练下降
      2 当高advantage的token概率更低，低advantage token概率更高时，entropy的梯度为正，entropy随训练上升

      • 这篇知乎博客对熵有一些推导和认知（具体逻辑本人还没详细推导，从结论看没有问题），比较具体的分析了更新时熵会怎么变化
      • 理解：
        • 当高advantage的token概率更高，低advantage token概率更低时，此时更新后高概率的 Token 概率更高，低概率的 Token 概率更低，锐化发生
        • 当高advantage的token概率更低，低advantage token概率更高时，此时更新后高概率的 Token 概率更低，低概率的 Token 概率更高，相当于拉平了 Token 的概率差异，所以熵会增加
    • （个人理解，待确认）在一些场景中，比如输出分布已经发生变化的情况，状态分布发生大幅变化
      • 比如：训练初期，收敛不平缓，假设要求正确答案在前面输出一个特殊格式，在这个格式被学到之前（极少样本采样到这个特殊格式），模型的熵偏低
        • 当这个格式逐渐被学到，因为比较特殊，导致这个特殊格式后续的 Token 的熵都偏高（这是有可能的）
        • 注意：在学到这个格式以后，熵会继续下降（不会持续上升）
      • 若奖励函数本身奖励更大的熵：
        • 显示鼓励：将最大熵加入目标中
        • 隐式鼓励：奖励探索不常见 Token 的回答
  • 一定有问题的情况：
    • 熵下降非常快的情况（一般伴随着 KL 散度下降特别快）
      • 模型可能 hacking 到了一种错误模式，常见的如输出重复
    • 熵提升非常快的情况
  • 个人理解对熵的期望：熵先下降（可短暂上升），然后持平或微弱波动

LLM RL 中 Token-level 建模 Action 和 Sequence-level 建模 Action 的区别

  • 结论：在理论目标（Objective Function）上，两者通常是可以等价的，但在优化过程、收敛效率以及对模型行为的约束上，两者存在显著差异
    • Response-level 建模通过牺牲细粒度的信用分配，换取了极大的训练稳定性和效率

两者的数学建模

  • Token-level（MDP） 此时LLM 的生成被视为一个多步决策过程：
    • Action 是 Token
    • Reward 通常在最后给出（稀疏奖励），也可通过 Reward Model 对每一步进行分解
    • 目标是 最大化累积奖励的期望
      $$\mathbb{E}_{\pi} [\sum_{t=1}^T r_t]$$
    • 常用 PPO 来求解这个 MDP 问题
      • 注：GRPO 在建模上属于一种特殊的 Token-level 建模（策略更新是 Token-level 的，GRPO 在调整每个 Token 的概率），但在奖励分配（Credit Assignment）上表现出 Response-level 的特征
  • Response-level：多臂老虎机 (Contextual Bandit) 此时这种建模将整个序列生成看作一个单一的、高维的动作：
    • Action 是完整的 Response 字符串
    • Reward 是对整个 Response 的单一评分
    • 目标 是最大化期望奖励
      $$\mathbb{E}_{y \sim \pi(y|x)} [R(x, y)]$$
    • 代表算法类似 DPO 等

分析两者目标等价性

  • 从全局最优解的角度来看，如果奖励函数 \(R(x, y)\) 是确定的（即两种方式得到的整个轨迹的奖励 \(R(x, y)\) 是一样的），且不考虑计算复杂度，两者的目标是等价的 , 在 KL 散度约束下的也存在等价性：
    • 在 RLHF 中，通常优化的目标是：
      $$\max_{\pi} \mathbb{E}_{y \sim \pi}[R(x, y)] - \beta \mathbb{D}_{KL}(\pi || \pi_{ref})$$
      • 无论是将 \(\pi(y|x)\) 拆解为（Token-level），还是将其视为一个整体概率（Response-level），概率的表达式都是一样的：
        $$\prod \pi(y_t | x, y_{<t}) $$
      • 只要数学形式一致，其理论上的最优解 \(\pi^*\) 都是：
        $$\pi^*(y|x) \propto \pi_{ref}(y|x) \exp(\frac{1}{\beta} R(x, y))$$
    • 问题：如果把 \(R(x, y)\) 等分到每个 Token 上（\(r_t \neq 0\)），两者目标还等价吗？
      • 回答：依然是等价的，Token-level 建模下依然是找到一个使得 \(R(x, y) = \sum_{t} r_t\) 最大的策略（Token-level 概率连乘，动作空间本质也与 Response-level 一致），此时二者最优策略的数学解仍然是同一个
      • 理解：Token-level 目标建模可以和 Sequence-level 目标建模等价，本质上是因为 RL 的建模目标是最大化整个轨迹整体的最大累计奖励（隐含了当前决策本质并不是贪心的，而是考虑当前决策对未来行为和奖励的影响的）
  • 但是，在实际操作中，这种等价性会因为以下原因被打破：
    • 1）信用分配 (Credit Assignment):
      • Token-level 建模可以通过 Value Function (如 PPO 中的 Critic 网络) 评估每一个 Token 对最终奖励的贡献
      • Response-level 建模将整个序列视为黑盒，无法区分是哪个词写得好，哪个词写得差
        • 这在长文本生成中会导致训练效率低下
    • 2）搜索空间与探索:
      • Token-level 在每一步都在进行概率分布的调整，探索空间是“树状”的
      • Response-level 的探索是“点状”的（即对整个句子的采样）
        • 在动作空间极大的情况下（LLM 的输出空间几乎是无限的），Response-level 往往依赖于离线数据（Offline RL），而非在线探索
  • 但这是“策略等价”而非“优化过程等价”
    • 实际中，由于优化算法、探索、稳定性的差异，它们往往收敛到不同的局部最优

其他讨论

  • 补充：如果是 off-policy 的场景，涉及到重要性采样时，参考 MiniRL 中的推导，可以知道，重要性采样权重按照 Sequence-level 是最优的（建模可以按照 Token-level 走，但是重要性采样权重必须是 Sequence-level 才是最优）
  • 注意：训推不一致时，需要使用重要性采样来进行修正，这个重要性采样权重是 Sequence-level 的 or Token-level 的，和这里的 RL 目标是 Token-level 建模 or Sequence-level 建模没有必然关系

RL 时，不同领域数据分布差异大，难以联合训练

  • 能做到将各个领域数据合并到一起训练应该是最好的方式，但现实往往容易因为各个领域数据分布、难度分布、Response 长度等差异过大而难以一起训练
  • 除了将数据融合到一起训练（方式一）外，还可以有以下方式：
    • 模型融合（方式二）：先训练领域模型，然后对参数做融合（最简单的策略比如求加权平均）
    • MOPD（方式三）：最早来自 Thinking Machines 的 OPD 博客（据说是 OpenAI 的 Recipe），MiMo-V2-Flash 模型使用 MOPD 方式，当前已经比较主流

RL 可以给模型注入新的知识或能力吗？

  • 一些文章发现 RL 只是在锐化分布（表现在 Pass@K 不涨）
  • 一些文章则发现 RL 有组合原子的能力
  • 个人理解：
    • 由于当前 RL 训练都是 On-policy 的，一般来说需要模型能够在这个方向上采样到至少一个正确的轨迹（超出模型原子能力的轨迹一般认为很难采样到）
    • 所以想要 RL 学到纯新的原子能力是比较难的（不是不可能，效率应该是极低的，不如 SFT 或者预训练等 NTP 的 Teacher Forcing 方式注入知识来的直接和高校）

为什么 LLM 的 RL 中，TIS 和 MIS 一般都是单向 Clip？

  • 实践视角：
  • 梯度视角：
    • IS 系数在梯度中的本质是对梯度进行加权，效果类似放大或缩小梯度的更新幅度
    • 若 IS 系数较大，容易造成更新过多，模型朝不准确的方向更新太多，此时
    • 若 IS 系数较小，本质上 Clip 与否不重要了，因为权重本身也不大（此时留着 梯度反而能提升 Token 更新效率）

top-p, top-k, temperature 等导致的 LLM RL 训推不一致如何解决？

  • 训推不一致会导致：
    • 训推不一致导致梯度有偏，随机错误的梯度方向会导致模型更新不受控，出现不收敛的现象，表现出模型迅速崩溃
    • 即使模型收敛，梯度方向也往往是错的，可能导致模型在训练引擎（包括训练配置）上效果还行，评测引擎（包括评测配置）上效果不行
  • top-p 和 top-k 导致的问题及解法在 DeepSeek-V3.2 技术报告中有提到，将 目标策略 对齐 到 Rollout 策略本身会有收益
    • Top-p 和 top-k 采样是广泛使用的采样策略，用于提高 LLM 生成的响应质量
    • 在 RL 训练中采用这些策略也是有益的，因为它避免了采样极低概率的 Token
    • 但当前在本人公司的场景中，训练时暂没有打开这两个参数（默认 top-p=1.0, top-k=-1）
  • temperature=1.0 的修复
    • temperature=1.0 时一般不需要特别修复（一般默认 Policy 的 logprobs 就是使用 默认 temperature=1.0 来算的）
    • 当 temperature != 1.0 时，需要考虑对齐两者的 temperature 参数（当前策略的 logprobs 计算跟 Rollout 参数对齐），否则会导致训推不一致问题
  • top-p=1.0 的修复（top-k 类似）
    • top-p=1.0 时不需要特别修复
    • 当 top-p < 1.0 时
      • 在推理时：记录采样时（计算 Softmax 前）被 drop 掉的 token
      • 在训练引擎上：计算概率时 mask 掉这部分 token（mask 方式也是在计算 Softmax 前进行 mask，将 atten_score 置为 负无穷）
      • 理解：
        • 本质是防止训推不一致问题
        • 梯度视角的理解： 这部分 token 推理时不参与决策，训练时就不要回传梯度
          • 对部分 token 在计算 Softmax 前进行 mask 的本质是这部分 token 在 Softmax 处的梯度为 0，其 hidden_states 在 Softmax 这里不会被梯度影响（实际梯度接近 0）
  • 注意：若 LLM 对外 Serving 时模型的 temperature 与训练时不一致，本身也会存在分布偏移
    • 常见情况：对外 Serving 时常常为 0.0-0.7 等，训练时一般是 0.7-1.0 等（因为训练时需要较高的温度采样不一样的 Rollout）
    • 若两者没有完全对齐，那么 RL 训练时的目标策略理论上和 Serving 时使用的也存在不一致
      • 注：但目前看，temperature=0.7 或 temperature=1.0 对大部分模型的回复体感，影响没有这么大
    • 一个思路是训练和 Serving 都使用 0.8 这种适中值，但不同的领域确实是不一样的
      • 需要更高 temperature 的场景：需要多样化的领域如开放问答场景，比如 0.7 及以上
      • 需要更低 temperature 的场景：需要准确、稳定的领域如数学，代码
  • 补充：关于重复惩罚参数，一般是 RL 训练时的 Rollout 是不能加 重复惩罚相关的系数的，会导致 RL 训练时的训推不一致问题
    • 比如 vllm 中的参数应该是需要使用默认值： presence_penalty=0、 frequency_penalty=0 和 repetition_penalty=1.0 等
    • 注意：如果训练时不保证 repetition_penalty=1.0，则会导致训练 RL 时的梯度本身存在偏差（Rollout 策略和 Old 策略无法对齐），这会导致训练出现异常

训推不一致问题的处理

  • 训推不一致需要特别监控，可能导致一开始正常训练的模型，突然崩溃（训推不一致的程度影响了模型长期训练的稳定性，但短期指标可能是正常涨的）
  • 可能导致训推不一致问题坑（踩过的坑）：
    • 训推引擎加载时，rope 相关的参数可能有很多，比如 theta, factor 等等， 每一个都要对齐，否则容易出现
    • top-p, top-k 等采样超参需要注意
  • 监控 两者的 rollout_train_logprob_diff（一般是 1e-2 量级） 或者 rollout_train_kl/rollout_train_k3_kl（一般是 1e-3 量级） 等参数
    • 注意：如果量级相对之前其他模型突然增大（或者比上面的高很多，需要注意排查），那大概率是有问题的
  • 核心：训练 RL 之前，一定看清训推相关的各种指标，所有指标都过一遍，确定没有问题再进行下一步！
    • 对所有训练指标做到心中有数

训练时该不该加 System Prompt？

  • 现象：若训练不添加 System Prompt，那么在应用时，容易出现用户添加 System Prompt 后效果大幅下降的情况
  • 解法：训练时对应比例的样本添加 System Prompt，添加方式可以是让一个 LLM 看到 Query 和 Reference 后，反向写出合适的 System Prompt
    • 这样做以后，可以做到用户侧添加不同的 System Prompt 时，模型还能正常 Serving，效果不会明显下降

GDPO 在开放问答场景没有拿到收益？

  • GDPO 在 Rubric RM + BT RM 信号融合的场景没有拿到合适的收益
  • 现象：GDPO 并没有稳定超过 GRPO
  • 问题1：搜参不充分？
    • 普通融合方式：
      • 可以离线搜参，找最优匹配方式
    • GDPO：
      • 涉及到组内归一化，不方便离线搜参，直接在线上尝试超参
  • 问题2（主要）：Rubric RM 和 BT RM 信号耦合性太强（或者说需要耦合才能实现最优信号表达）
    • GDPO 的基本思路是解耦信号
      • 好处是：可区分 (0,1),(1,0) 信号 和 (0,2),(2,0) 信号
      • 比如：若一个 Response 在两个信号上都是 0，给与两倍惩罚，若都是 1，则给与两倍奖励，GDPO 的收益主要来源于类似的信号强度识别（在某些样本上相当于提升了 Advantage，也就是提升了学习率）
    • 我们当前的期望：希望 Rubric 能防止 Reward Hacking，即 Rubric 给出高分时，才允许 BT RM 的高分有效（所以是使用类似条件组合 或者 加权平均更合适）
      • 也就是说，我们的场景中，是希望 Rubric 的到高分时，才允许 Rubric 得到高分，这种思想更多是通过一些条件判断（类似指令是否遵循的前提是 Query 在正常回答问题）才能很好的表达，GDPO 让两个信号解耦，反而不利于这种复杂关系的表达！
    • 补充实验：
      • 添加一票否决式的 Rubric 信号可以大幅缓解一些针对性问题（如语言混乱）
  • 问题3：等价性：
    • 可以证明，内部归一化不除以 std 的 GDPO 和 Reward=分数加权平均 的 GRPO 本质是一致的
    • 若除以 std，则容易出现一些类似 kl spike 的现象发生（特别是 GDPO 下分成两个信号以后），当前线上的算法倾向于过滤较小 std 的样本（这会缩小 GDPO 和 GRPO 的差异）

LLM 训练过程中发生重复、乱码或语言混杂应该如何排查？

  • 预训练中：
    • 发生重复可能是正常的，因为没有 EOS，模型不知道何时停止（但预训练数据通常会用 <|endoftext|> 等特殊 Token 来分隔不同的文档，也不会无限制的不停止）
    • 发生乱码或语言混杂可能需要关注，比如查看最近训练的数据有没有问题（但一般预训练不会关注这种指标）
  • SFT 中：
    • 发生重复或乱码都是不正常的
    • 常见的发生重复或乱码的原因可能有：
      • 一般是数据有问题（建议保证数据的质量），比如 Chat-template 模板是否一致等
      • 可能跟模型能力有关，比如模型参数太小（如 1B 以下）
      • 可能因为量化导致精度下降
      • Infra 的显卡等精度导致
      • 模型没有问题，Query 本身是 OOD 的，比如没有训练过的 Token 导致
      • 训练 Epoch 过多或数据量太小，导致模型对特定模式过拟合，生成时容易陷入循环
      • 补充1：发生重复很可能跟 EOS Token 的识别有关，需要重点关注
      • 补充2：发成重复还可能和 masking 机制错误有关（比如 Mask 错位（错过 EOS Token），可能学到奇怪的模式）
  • RL 中：
    • 发生重复和乱码都是不正常的
    • 常见的发生重复和乱码的原因有：
      • RM 本身有问题
      • Reward Shaping 方式有问题，比如疯狂鼓励短文本，不在意语言的准确性时可能出现 Reward hacking（hacking 到短的乱码/重复文本上）
    • KL 散度惩罚过小也可能导致模型这个问题，模型为了追求高 Reward，可能会无底线地偏离 Reference 模型（Base/SFT 模型），最终导致语言能力崩溃（Mode Collapse）
    • PPO 中的 Value Model 训练不稳定，导致 Advantage 估计出现极端值，梯度爆炸，破坏了语言模型的底层表达能力
  • 模型出现重复、乱码、语言混乱的通用原因：
    • 学习率过大 (LR too high)：可能导致模型坍塌（Mode Collapse），模型会倾向于一直输出某个高频词（如“的”、“the”等），表现为重复或乱码
    • 梯度爆炸：Infra 精度问题（如 FP16 溢出）导致梯度出现 NaN 或 Inf，进而破坏模型权重，直接输出乱码
    • 词表未完全覆盖目标语言，或者 BPE 训练时语料比例不对，导致模型只能用零碎的单字母拼凑，表现出“乱码”感
    • 其他任何原因导致的模型崩溃都有可能会导致模型输出重复、乱码、语言混乱的情况

为什么 PPO 使用 kl in reward，GRPO 使用 kl as loss?

  • TLDR：
    • PPO 把 KL 放在奖励里，是因为它有一个 Critic 能够消化并利用这个稠密的惩罚信号，kl in reward 可以让 Critic 预知未来的 kl 信号变化
    • GRPO 把 KL 放在 Loss 里，是因为它没有 Critic，且需要保证组内相对奖励（Advantage）的纯洁性
      • kl as loss 可防止 KL 的方差破坏对好答案的正确激励，同时能做到通过 KL as loss 精确惩罚 Token 粒度的 KL 偏离现象
      • Group-based Advantage 整体鼓励正样本，惩罚负样本；KL as loss 精确惩罚每个样本上的 Token 粒度 KL

PPO 使用 kl in reward 原因

  • 在标准的 PPO-RLHF 中，KL 惩罚通常通过Reward Shaping的方式在 Token-level 起作用：
    $$ r_t = r_{RM} - \beta \log \frac{\pi_\theta(a_t|s_t)}{\pi_{ref}(a_t|s_t)} $$
    • 注：通常只有在生成最后一个 token 时 \(r_{RM}\) 才有值，而 KL 惩罚在每个 token 上都有
  • 原因1：PPO 可以利用 GAE 在 Token-level 计算 Advantage
    • Critic 模型在训练时，预测的是“包含 KL 惩罚的综合回报”
    • PPO 能感知到模型在某个特定 Token 上偏离参考模型带来的惩罚，从而提供非常细粒度、稠密的梯度信号
  • 原因2：符合标准 MDP 设定：
    • 传统 RL 框架中，算法本身（PPO）是一个黑盒优化器，它只认环境给的 Reward
    • 把 KL 惩罚作为环境 Reward 的一部分，使得 PPO 算法的内部逻辑（包括 PPO 的 Surrogate Loss 和 Value Loss）不需要做任何修改，工程实现上非常优雅和解耦
  • PPO 中，将 KL 作为损失和加入 Reward 是等价的吗？
    • 虽然两者都在 Token-level 惩罚了偏离，但因为 PPO 引入了 Critic 和 GAE ，KL 放在 Reward 里会产生一种“全局耦合作用”，而放在 Loss 里只是一种“局部作用”
    • 两者梯度的数学本质：通过采样量化 vs 自动梯度计算
      • KL in Reward 时，将 \(-\beta \log(\pi/\pi_{ref})\) 作为一个具体的数值（标量）算出来，丢给环境当成 Reward，然后通过强化学习的策略梯度定理（Policy Gradient）去更新网络，是一种基于采样的间接优化
      • KL in Loss 时，将 KL 散度作为一个可导的数学公式直接写在 Loss 里，通过 PyTorch 的 Autograd 直接求导（解析梯度）
    • Critic 的“预判”能力不同：
      • kl in Reward 时，Critic 的“预判”能力能提前避开高 KL 区域
        • 此时 Critic 预测的 Value 就包含了未来的 KL 惩罚
        • 预知能力示例：模型在生成第 3 个 Token 时，Critic 可能会警告 Policy：“如果你选了这个 Token，虽然现在 KL 不大，但它会把你引向一个奇怪的句式，导致第 5、6、7 个 Token 产生巨大的 KL 惩罚”
        • 模型学会了 “提前规划” ，主动避开那些会引发未来高 KL 惩罚的生成路径（注：类似 TD Error 的估计方式下，Value 就是代表未来奖励期望）
      • 注：KL in Loss 则做不到这个对 kl 的预知能力
    • Advantage 对前置 Token 的连带责任 vs 独立惩罚
      • KL in Reward 时，PPO 使用 GAE 计算优势，GAE 会将未来的奖励（包括未来的 KL 惩罚）向回传导
        • 比如在第 5 个 Token 产生了一个极大的 KL 惩罚，这个负面信号会通过 GAE 像水波一样传导给第 4、第 3 个 Token 的优势
        • 此时梯度不仅会惩罚第 5 个 Token，还会连带惩罚导致这一局面的前面几个 Token
      • KL in Loss 时，KL 惩罚不进入 Advantage
        • 第 5 个 Token 的高 KL 仅仅在算 Loss 时产生一个针对第 5 个 Token 的梯度
        • 不会向回传导 ，第 4、第 3 个 Token 的更新完全不受影响（因为此时只是通过梯度传播）
    • Clipping 机制的表现不同
      • PPO 的 Surrogate Loss 中包含 clip 操作，防止策略更新步子太大
      • KL in Reward 时，KL 作为标量值被算进了优势中
        • 当计算 Policy Loss 时，如果当前策略相比旧策略变化太大触发了 Clip，那么包含 KL 信号在内的整个梯度都会被截断（停止更新） ，这是一种非常温和、受控的更新
      • KL in Loss 时，KL 作为独立的正则项加在 Loss 后面
        • 不受 PPO Clip 机制的管辖
        • 无论 Policy 怎么 Clip，KL 梯度始终存在，且始终在死死地把模型往参考模型方向拉
        • 这有时会导致在当前策略偏离旧策略很多的 轨迹/Token 上正则化过强，把模型参数拉偏

GRPO 使用 kl as loss 的原因

  • GRPO 核心改进是去掉了 Critic 模型 ，通过对同一个 Prompt 采样 \(G\) 个不同的回答，在组内计算相对奖励来估计优势：
    $$ A_i = \frac{r_i - \text{mean}(\mathbf{r})}{\text{std}(\mathbf{r})} $$
    • 在 GRPO 的论文中，其目标函数直接包含了 KL 散度：
      $$ \mathcal{L}_{GRPO} = \frac{1}{G} \sum_{i=1}^G \left[ \min\left( \frac{\pi_\theta}{\pi_{old}} A_i, \text{clip}\left(\frac{\pi_\theta}{\pi_{old}}\right) A_i \right) - \beta D_{KL}(\pi_\theta | \pi_{ref}) \right] $$
  • 原因1： 避免 KL 惩罚干扰组内 Advantage 的计算
    • 如果把 KL 惩罚加到 \(r_i\) 里（即 \(r_i’ = r_i - \beta \text{KL}\)），然后再去算 mean 和 std，会产生严重的问题：
      • KL 散度是一个具有极高方差的项（不同生成轨迹的 KL 差异很大）
      • 将 KL 混入奖励后进行标准化，会扭曲纯粹基于任务表现的相对排名
        • 比如，一个回答可能完全正确，但因为用了稍微不同的句式（KL 惩罚大），导致其标准化后的优势 \(A_i\) 变成负数
      • 因此，GRPO 必须保持 \(A_i\) 的计算纯粹反映“回答的质量好坏”，而将“不要偏离参考模型”这一约束剥离出来
    • 总结：放入 Reward 时，由于 kl 的极大方差会掩盖原始的正确性（奖励）信号
  • 原因2： 无 Critic 模型时的直接正则化
    • 因为 GRPO 没有 Critic 模型，它不需要像 PPO 那样去拟合包含 KL 的期望回报
    • 既然不需要拟合 Value，最直接、数学上最清晰的做法就是将 KL 散度作为策略更新时的正则化项（Regularization Term）直接加在 Loss 上
    • 这在优化时等价于：“在最大化任务优势的同时，拉近当前策略和参考策略的分布”
  • 原因3：Token-level 精确 KL 约束
    • 在 GRPO 中，优势 \(A_i\) 通常是 Sequence-level （一个回答每个 Token 的 \(A_i\) 想通）
    • 如果使用 kl in reward：
      • 只能把 Token-level KL 累加成 Sequence-level 标量，这会丢失 Token-level 细粒度约束
      • 可能会导致模型为了降低 KL 而去选择鼓励错误的答案(本应该整体鼓励正确答案，打压部分偏离的 Token 即可)
    • 如果使用 kl as loss：
      • 可以在计算梯度时，针对每一个 Token 的 Logits 直接计算精确的 KL 散度（或其无偏估计），从而在没有 Critic 的情况下依然保持对每个 Token 概率分布的强力约束
      • 梯度更新时，Loss 包含两部分：
        $$\nabla \text{Loss} = \nabla \text{Policy}(A) + \beta \nabla \text{KL}$$
        • 假设一个奖励 A 是正确回答，但偏离原始策略过多，那么：
          • Policy 梯度会整体推高回答 A 的概率（因为它做对了题）
          • 同时，KL 梯度会单独向下拉扯回答 A 中那些“罕见句式”的特定 Token 的概率
          • 这是一种力的叠加 ：“鼓励做对这道题，但希望换个正常的词来表达”
            • 它不会导致模型为了降低 KL 而去选择错误的答案
  • GRPO 中使用 kl in reward 的话，预计效果不会太好，比如 KDRL: Post-Training Reasoning LLMs via Unified Knowledge Distillation and Reinforcement Learning, 20250602, HIT & Huawei Noah’s Ark Lab 中做过类似的实验，结论是训练早期模型就崩溃了
    • 注：虽然实验中使用的 KL 散度是老师和学生之间的 KL 散度，但一定程度上来说，导致模型训练早期崩溃的原因是一致的

相同学习率下 GRPO 训练比 PPO 学习效率更高吗？

  • 参数更新步数需要对齐才可比较：
    • 如果仅对齐 Rollout 步骤比较，那本身可能会不够公平，因为 GRPO 和 PPO 的同一个 Rollout 下的参数更新步数不一定一致
    • 比如 GRPO 一个 Rollout 更新 4 步，而 PPO 一个 Rollout 更新 2 步，那么 GRPO 相同 Rollout Step 下的速度一般快高于 PPO
  • 梯度更新幅度与 Advantage 有关
    • 梯度更新幅度除了与显示的学习率有关，还与 GRPO 和 PPO 的 Advantage 绝对值有关
    • 在一些场景下，比如如果不对 PPO 的 Advantage 做归一化，则 PPO 的 Advantage 均值可能比 GRPO 小 或 大，此时这个幅度变相的影响了学习率，从而造成不一样的情况
    • 若对 PPO 的 Advantage 做了归一化，那么这个均值一般是跟 GRPO 能对齐的（详细待上报和证明）
  • 假设学习率等都一样，Advantage 绝对值的均值也一样，还可能与梯度噪音有关
    • 若 Critic 模型学习没有很好的收敛，PPO 训练 Actor 时拿到的梯度很可能包含许多噪音或梯度方向是错的，此时可能发生 PPO 训练速度不如 GRPO 的情况
  • 即使不考虑梯度噪音，归一化后的 Advantage 绝对值均值也一样，仍然存在不同 Group 不同表现的情况
    • 比如当一个 Group 的原始 Reward 为 1 个 1 和 7 个 0 时
      • 若按照 Group 归一化，此时得到的 Advantage 约为： [2.6458, -0.3780, -0.3780, -0.3780, -0.3780, -0.3780, -0.3780, -0.3780]
      • 若按照 Batch 归一化，此时得到的 Advantage 则取决于整体的均值和方差（整体的均值和方差往往大于这个相对极端的 Group，会导致极端样本的梯度权重变小）

LLM RL 中为什么不使用 Off-policy 的方法？

  • Off-policy 的 Value-only 方法（如 DQN 等）不适用与当前 LLM 的 Actor 场景
    • DQN 等 off-policy 方法也存在状态分布偏移问题，Off-policy 数据分布与当前策略分布不同，Off-policy 步骤过多时还会导致训练数据分布和当前策略分布差异较大
  • Off-policy 的 AC 方法的优化目标本身是有偏的（偏差在于期望是 Off-policy 数据（\(s \sim d^{\pi_\text{b}}\)）上的目标期望）
    • Principled 目标应该是 On-policy 数据（\(s \sim d^{\pi}\)，即当前策略自身的期望）上的目标期望
    • 即：Off-policy 的 AC 方法都假设了下述两个目标的最优解相同：
      $$ \pi^* = \max_\pi \mathbb{E}_{s \sim d^{\pi_\text{b}}} [V^{\pi}(s)] \\
      \pi^* = \max_\pi \ \mathbb{E}_{s \sim d^{\pi}} [V^{\pi}(s)]$$
      • 详细分析见附录
  • 注意：使用 IS 修正系数的方式下，不算是纯粹的 Off-policy 场景（此时是使用 IS 将 Off-policy 转换为 On-policy 的无偏梯度），此时的目标是等价的
  • 注：Off-policy 方法确实亮眼，毕竟样本利用效率高，在 LLM RL 中的使用有待研究

补充：off-policy AC 和 on-policy AC 的目标形式不完全等价

  • 特别说明，需要注意：使用 IS 修正系数的方式下，不算是纯粹的 Off-policy 场景（此时是使用 IS 将 Off-policy 转换为 On-policy 的无偏梯度），此时的目标是等价的（本质上都是在 On-policy 梯度下实现），下面所聊的都是理论上不需要重要性采样做分布校正的场景下的 Off-policy AC（比如 DPG 论文中描述的场景）
  • off-policy AC方法的目标都是类似形式： \(\max_\pi \quad \mathbb{E}_{s\sim \rho^{\beta}(s)}[V^{\pi}(s)]\)
    • 基本含义就是，找一个最优的策略 \(\pi\)，使得 \(V^{\pi}(s)\) 在行为策略的状态访问分布下期望最大
  • 实际上，on-policy AC方法的目标是类似形式： \(\max_\pi \quad \mathbb{E}_{s\sim \rho^{\pi}(s)}[V^{\pi}(s)]\)
    • 基本含义就是，找一个最优的策略 \(\pi\)，使得 \(V^{\pi}(s)\) 在 策略 \(\pi\) 的状态访问分布下期望最大
  • 答案是如果策略空间包含所有策略，则两者等价，否则不等价 ：
    • 如果策略模型空间是无限大的，一定存在最优的策略 \(\pi^*\) ，使得任何一个状态 \(s\) 下都有 \(V^{\pi^*}(s) \ge V^{\pi}(s), \forall{\pi}\) 成立，证明是：对于任意给定的状态 \(s\)，有 \(\int_a \pi(a|s) q^*(s,a) d a \le q^*(s,a^*) \)，其中 \(a^* = \mathop{\arg\max}_a q^*(s,a)\)，此时，我们定义一个策略为：对任意状态 \(s\)，都取该状态下的 \(a^*\) 即可
    • 如果能找到一个最优的策略 \(\pi^*\)，使得在任何一个状态 \(s\) 下都有 \(V^{\pi^*}(s) \ge V^{\pi}(s)\) 成立，那么，我们找到策略 \(\pi^*\) 就同时是off-policy和on-policy的最优解
      • 这种情况下，如果能找到 \(\pi^*\)，则两者等价（注意：即使存在 \(\pi^*\)，模型也不一定能学到，如果在off-policy和on-policy设定下学到的难度不同，甚至策略模型空间受限，拟合不了最优的策略 \(\pi^*\)，也不能说两者目标等价）
    • 如果模型空间限制导致模型空间中找不到一个最优的策略 \(\pi^*\)，使得在任何一个状态 \(s\) 下都有 \(V^{\pi^*}(s) \ge V^{\pi}(s)\) 成立，那么，策略的选择就会根据状态访问分布有所取舍，更倾向于状态分布概率高的那部分状态，off-policy AC方法的目标与on-policy AC目标一定不等价，在状态分布不同的情况下，找不到一个共同的最优解 \(\pi^*\)
      • 此时，两者不等价，行为策略中出现越多的状态，越收到重视
    • 现实生活中，SAC和DDPG为什么可以正常运行且拿到不错的收益呢？
      • off-policy方法本身样本利用率更高些
      • SAC和DDPG都是在off-policy中使用，如果即时丢弃过早的数据，那行为策略分布和最优策略差异不会太大，且online的训练确保了模型见过几乎所有状态
      • 大部分场景中，只要策略模型空间够大，应当都可以认为存在最优的策略 \(\pi^*\)，使得在任何一个状态 \(s\) 下都有 \(V^{\pi^*}(s) \ge V^{\pi}(s)\) 成立，或近似成立
  • 如果这里模型找不到最优的策略 \(\pi^*\)，则这个问题和DQN的问题还不等价，DQN主要问题是训练模型时存在off-policy导致的线上线下分布不一致的问题，off-policy AC从目标上就存在线上线下不一致的问题，同时训练模型时也有线上线下不一致的问题（都是线上线下不一致，但是off-policy AC还多了目标上的不一致，是从根本上定义导致的偏差，理论上更严重些）

OPD 中，使用全词表 KL 计算时如何理解 Reverse KL 和 Forward KL

  • 注：在做 On-policy Distillation 时，如果使用全词表计算 KL 散度，即使是 Student 采样的，也可以使用 forward KL，即：
    $$ D_\text{KL}(\pi_T || \pi_S) $$
    • 在代码实现层面，完全可以这么做
    • 但在理论数学层面，这已经不再是严格意义上的序列级别 Forward KL，而是一种“混合目标（Hybrid Objective）”
  • 需要区分 Token-level和 Trajectory-level 的散度计算

为什么“使用全词表”让计算 \(D_\text{KL}(\pi_T || \pi_S)\) 成为可能？

  • 在 Token-level 生成时，要计算给定前缀 \(y_{ < t}\) 下的 KL 散度：
    $$ D_{KL}(\pi_{teacher}(\cdot|y_{ < t}) || \pi_{student}(\cdot|y_{ < t})) = \sum_{v \in V} \pi_T(v|y_{ < t}) \log \frac{\pi_T(v|y_{ < t})}{\pi_S(v|y_{ < t})} $$
  • 如果不使用全词表 ：
    • 需要通过蒙特卡洛采样来估计这个期望
    • 如果是 Forward KL，必须 从 Teacher 模型采样下一个 token 才能无偏估计
  • 若使用全词表（Full Vocabulary） ：
    • 直接获取了 Teacher 和 Student 在所有词 \(V\) 上的 Logits 并转换为概率分布
    • 此时是在做精确的解析计算（Exact Calculation） ，不需要在当前步进行采样
    • 因此，无论前缀 \(y_{ < t}\) 是怎么来的，都可以强行计算出这一步的 Forward KL

为什么理论上它不再是严格的 Forward KL？

  • 在序列生成任务中，KL 散度是建立在状态分布（State Distribution）上的
  • 严格的序列级 Forward KL ：
    • 要求轨迹 \(y\) 是由 Teacher 采样的（即 Off-policy，类似传统的 SFT 或标准 KD）
      $$ \mathbb{E}_{y \sim \pi_T} \left[ \sum_t D_{KL}(\pi_T(\cdot|y_{ < t}) || \pi_S(\cdot|y_{ < t})) \right] $$
  • 严格的序列级 Reverse KL ：
    • 要求轨迹 \(y\) 是由 Student 采样的（即 On-policy，例如 MiniLLM）
      $$ \mathbb{E}_{y \sim \pi_S} \left[ \sum_t D_{KL}(\pi_S(\cdot|y_{ < t}) || \pi_T(\cdot|y_{ < t})) \right] $$
  • 混合做法（Student 采样 + 步级别 Forward KL） ：
    $$ \mathbb{E}_{y \sim \pi_S} \left[ \sum_t D_{KL}(\pi_T(\cdot|y_{ < t}) || \pi_S(\cdot|y_{ < t})) \right] $$
    • 核心矛盾在于 ：
      • 外层的期望（状态/前缀的分布）是 Student 的 \(\pi_S\)，而内层单步优化的目标却是 Forward KL（以 Teacher 为基准）
      • 这导致了状态分布的错配（Mismatch）

\(\mathbb{E}_{y \sim \pi_S} \left[ \sum_t D_{KL}(\pi_T(\cdot|y_{ < t}) || \pi_S(\cdot|y_{ < t})) \right]\) 这种做法在实践中有意义吗？

  • 首先 学术界和工业界都有应用 （比如 GKD 论文）
  • 这种做法通常被称为基于 Student 状态分布的 Forward KL 蒸馏，或者属于 Generalized Knowledge Distillation (GKD) 的范畴
\(\mathbb{E}_{y \sim \pi_S} \left[ \sum_t D_{KL}(\pi_T(\cdot|y_{ < t}) || \pi_S(\cdot|y_{ < t})) \right]\) 优势：
  • 1） 缓解暴露偏差（Exposure Bias） ：
    • 传统的 Forward KL（Teacher 采样）中，Student 永远只看到正确的、高质量的前缀
      • 一旦在推理时 Student 自己犯错，就会产生误差累积
    • 让 Student 自己采样（On-policy），即使它生成了次优的前缀，Teacher 也会在这个次优前缀上通过全词表 Forward KL 教 Student “如何纠正或继续”
  • 2） 包含性（Inclusive）与模式覆盖 ：
    • Token-level Forward KL 倾向于让 Student 覆盖 Teacher 在该状态下的所有可能输出（Mode-covering），这比 Reverse KL（Mode-seeking，容易导致生成单一、重复）能保留更多的生成多样性
\(\mathbb{E}_{y \sim \pi_S} \left[ \sum_t D_{KL}(\pi_T(\cdot|y_{ < t}) || \pi_S(\cdot|y_{ < t})) \right]\) 潜在风险：
  • 1）Teacher 的“不知所措” ：
    • 因为前缀 \(y_{ < t}\) 是 Student 采样的，如果 Student 输出了一个极其糟糕、甚至乱码的前缀（Out-of-Distribution for Teacher），Teacher 在这个前缀下的概率分布 \(\pi_T(\cdot|y_{ < t})\) 可能会变得非常平滑（熵极高）或者充满噪音
    • 强迫 Student 去拟合这个噪音分布，可能会损害 Student 的性能
  • 2）计算代价 ：
    • On-policy 采样本身就很慢，加上每一步都要过一遍 Teacher 模型获取全词表 Logits，显存和计算开销（Memory & FLOPs）会非常大

MIS/TIS 和 Decoupled PPO Objective 的关系

  • MIS/TIS 是直接使用 Megatron 策略 / Rollout 策略 IS 系数修正
    • 其中 Megatron 策略 一般是旧策略
    • Rollout 策略 一般也是旧策略，但也可以是异步的 Off-policy 策略，允许存在一定的 staleness
  • Decoupled PPO Objective 的本质是将 proximal 策略 和 行为策略（Rollout 策略）进行区分
    • 允许行为策略有更大的 staleness
    • 同时使用 proximal 策略来保证更新的步长
  • 在满足一定条件下，当已经使用了类似 MIS/TIS 修正后，Decoupled PPO Objective 中的 proximal 策略 / rollout 策略部分就可以不需要了
    • 因为 MIS/TIS 是直接使用 Megatron 策略（一般是旧策略）/ Rollout 策略（即行为策略）作为 IS 修正系数的
    • 由于的 proximal 策略一般取 Megatron 引擎的旧策略，所以此时的 proximal 策略 / rollout 策略部分等价于 MIS/TIS 的修正系数（即两者是同一个值）
  • 所以：MIS/TIS 和 Decoupled PPO Objective 本身是有可能冲突的，在同时使用时一定要小心对齐相关情况，最佳实践建议：
    • 打开重计算参数，在 Megatron 上重计算 旧策略 在 Response 上的概率
    • 使用 Megatron 引擎上的旧策略作为 proximal 策略，计算 PPO Clip 系数
    • 在整个 Loss 的前面使用 MIS/TIS 修正，修正系数为： Megatron 旧策略 / vLLM Rollout 行为策略

异步方案的性能收益

  • One-Off 主要是指总是使用上一轮模型作为行为策略 Rollout 样本的方式，详情见：NLP——DeepCoder
    • One-Off 下，每次更新都刚好 off-policy 一步，即 staleness = 1
    • 核心是做到了上一轮 Rollout 和当前轮次更新的完全 overlap，从而大大提效
  • 流式异步方式是指 Rollout 和 参数更新几乎完全解耦
    • 注：存在一定的 On-policy 和 Off-policy 比例（通过一些系数来控制），所以也不是完全的 Off-policy
    • 效率不一定比 One-off 快，但效果比 One-Off 难以把控
    • 存在 Rollout 实际问题导致的随机性（部分实现中会对 Rollout 结果进行排序，但也无法完全保证确定性）
  • 当 Rollout 序列长度一般时（一般 16K），此时使用 One-off 就够了
    • 效率上提升约 40%
    • 效果几乎不降（波动）
  • 当 Rollout 序列长度很长时，使用流式异步方式相对 One-off 方式会有效率上的提升
    • 流式实现很需要注意 staleness，如果 staleness 太大容易导致效果不好
  • 注意：
    • one-off 方法和 同步方法相比，在一些任务上没有观察到明显的模型性能差异
    • 流式异步方式

蒸馏模型时，需要视情况选择不同模型

  • 常用经验：应用方面数据用 Claude 数据，文学方面用 Gemini 数据
  • 问题：蒸馏时，如果处理 CoT 数据
    • 情况1：想要训练 Instruct 模型，那么蒸馏模型时选择 SOTA 模型的 Non-Thinking 模式即可（注意有些模型默认开启 Thinking，别用错）
      • 注：如果蒸馏了 Thinking 数据来做 Instruct，可能会导致模型出现先给回答再给过程的情况，拉低最终的性能
    • 情况2：想要训练 Thinking 模型，那么一般是蒸馏开源的 SOTA 模型，这样才能拿到准确的 CoT 数据（闭源模型一般不开放原始的 CoT 数据）
      • 注：闭源模型提供的往往是经过 Summary 以后的 CoT 返回，不能直接用于训练
      • 注：据说国内某些公司可以搞到闭源模型的 CoT 数据

关于 LLM RL 指标上报的感想

  • 在迭代过程中，无论如何修改代码，一定要保证原始的上报指标符合预期，比如样本打分的原始值一定要上报，方便在训练过程中监控问题
  • 亲身遇到解决过一个 Case，上报时，某个奖励的值被其他奖励混合了（在特定情况下取了两者的 min，导致一个奖励出现问题时，另一个奖励也出现问题，导致定位问题花了很多不必要的时间）

LLM RL 中，指令遵循专项的训练顺序认知思考

  • 问题：训练模型时，假设只能顺序训练，请问指令遵循能力应该先于 Code 等领域训练还是后于这些领域训练？
  • 观察到的现象：先训练指令遵循能力，在训练 Code 等领域时，观察到指令遵循大幅下降
  • 之前的理解：训练 Code 等领域本身就是会降低 指令遵循能力
  • 其他文章的观察：Nemotron cascade 系列问题提到可以先训练 指令遵循能力的，训练其他领域时不会让指令遵循掉点太多
  • 近期发现和思考：近期发现我们 Code 等领域有大量指令不遵循情况（或者说不严格遵循），这可能是我们的实验跟 Nemotron cascade 实验结果对不齐的原因

传统 RL 与 LLM RL 的区别，为什么传统 RL 中效果很好的 PPO 等方法在 LLM RL 中效果一般？

  • TLDR：
    • LLM RL 的动作空间太大了（几乎无法通过探索评估价值），所以之前在 传统 RL（通过探索估计价值的方式）上的一些假设已经失效，从而导致 LLM RL 中使用 Bandit 建模方式更佳（而不是传统 RL 中的 MDP 建模方式）
    • 注：基于这个理解，也可以解释为什么 PPO 在 LLM RL 中效果不佳
    • 但是：还有个理解是，虽然状态和动作空间非常大，但经常出现的状态和动作其实不多，Reward Model 或者 Critic 本身也不需要针对不常出现，或者几乎不出现的状态进行估计
      • 在这个视角看，其实 Critic 还是有机会能学习成功的
      • 注：这也是 PPO 在 LLM RL 还是有一定效果的原因，且看起来 Critic 本身也是收敛的
      • 补充说明：这个情况下，真实的动作空间太大，探索难度极高（模型很难进行探索）
  • 但是两者从经验中学习的思想是相同的：传统 RL 与 LLM 的强化学习虽然在核心思想上都是“通过与环境交互、基于奖励机制优化策略”

传统 RL 与 LLM 强化学习的核心区别

状态与动作空间的维度差异（重点）
  • 传统 RL：通常处理的是相对较小、离散或连续的状态和动作空间（如 Atari 游戏、机器人关节控制）
    • 对于简单任务，甚至可以用 Q-table 来存储状态-动作对的 Q 值
  • LLM RL：面对的是极高维的离散空间
    • LLM 的“状态”是当前的所有上下文（Prompt + 已生成的 Token），而“动作”是从庞大的词表（通常包含数万到十数万个词汇）中选择下一个 Token，这种海量的状态-动作组合使得传统方法难以直接套用
探索与利用的平衡（重点）
  • 传统 RL：探索机制贯穿始终，智能体有充足的空间去尝试各种随机动作
  • LLM RL：由于 LLM 的动作空间极大，盲目探索会导致生成毫无意义的乱码
    • 在传统 RL 框架下训练 LLM，模型的熵值往往会迅速下降，导致“利用”远超“探索”，推理路径极易固化
  • 注：核心还是 LLM RL 中动作空间极大导致的
初始能力与学习目标的差异（不重要）
  • 传统 RL：智能体（Agent）通常是“白纸一张”（Tabula Rasa），通过在环境中不断试错，从零开始学习最优策略
  • LLM RL：LLM 在进行强化学习（即后训练阶段）之前，已经通过海量文本完成了预训练和 SFT，具备了极其强大的语言理解和生成能力
    • 此时 RL 的目标不再是“从零学习”，而是为了对齐人类偏好（如无害性、有用性）或激发复杂的逻辑推理能力
  • 注：但是传统 RL 中也可以先模仿学习（相当于蒸馏专家），再开始 RL 训练
奖励信号的来源与稀疏性（不重要）
  • 传统 RL：奖励通常由客观环境直接给出（如游戏得分、是否到达终点），规则明确
  • LLM RL：奖励通常来自额外训练的Reward Model 或基于规则的验证器（如代码是否编译成功、数学题答案是否正确）
    • 这种奖励往往是高度延迟和稀疏的（模型必须生成完一整段长文本后，才能获得一个整体的评分）
  • 注：传统 RL 中其实也有奖励稀疏的情况

为什么 PPO 等 Actor-Critic 方法在 LLM 中面临挑战？

  • 注：虽然 PPO 曾是第一代 LLM 强化学习（如 InstructGPT）的主导算法，但 PPO 作为典型的 Actor-Critic 架构，它包含一个负责生成动作的 Actor 和一个负责评估当前状态价值的 Critic，而这个 Critic 在大模型中几乎是不可估计的
    • PS：也不是完全不可估计，其实训练过程中还是能看到长点
  • 但随着模型规模的扩大和推理任务的复杂化，PPO 暴露出多个致命缺陷
    • PPO 缺陷1：极其高昂的显存与计算开销
    • PPO 缺陷2：Critic 模型（价值函数）的估计极度困难
      • Critic 模型的核心任务是评估“当前生成的半句话在未来能拿多少分”
      • 在自然语言生成中，语言的走向千变万化，且奖励通常只在整段文本生成完毕后才发放（稀疏奖励）
      • 这导致 Critic 模型很难准确拟合价值函数
      • 如果 Critic 估算不准，它提供的 Advantage 就会充满噪音，反而会误导 Actor 模型的更新 ，导致训练崩溃
      • 注：甚至有些文章在质疑对中间的 Token 奖励建模是否有意义（如果理解为走向成功的概率，那我理解还是有一些意义的）
    • PPO 缺陷3：超参数敏感，训练极不稳定，容易过早收敛（Mode Collapse）
      • PPO 对超参数（如学习率、裁剪比例、KL 惩罚系数）极其敏感
      • 在 LLM 训练中，一个普遍存在的现象是：模型一旦发现某种回答模式（哪怕是钻空子的“奖励黑客”行为）能获得高分，就会迅速抛弃其他可能性
      • 这导致模型的熵值骤降，生成多样性被破坏（过早收敛） ，严重限制了模型在复杂数学或逻辑推理任务中的性能上限
    • PPO 缺陷4：缺乏反思与自适应探索能力
      • 传统的 Actor-Critic 方法基于马尔可夫假设，智能体只根据当前状态做决策
      • 在复杂的推理任务（如长思维链 Long-CoT）中，这种范式导致 LLM 往往“一条路走到黑”
      • 它无法像人类一样在推理过程中保留历史试错信息、排除无效假设并适时切换策略

LLM RL 中的解决方案

  • 改变建模方式，从 MDP 切换为 Bandit ，于是就可以抛弃 Critic，走向相对优势估计（如 GRPO）：
    • GRPO 算法直接移除了庞大且难以训练的 Critic 模型
    • GRPO 针对同一个问题，让模型生成多个不同的回答，然后计算这些回答之间的Relative Advantage 来更新策略
    • 注：这不仅将显存开销大幅降低，还巧妙规避了绝对价值评估的难题，实现了训练效率与稳定性的双重突破
  • 理解：GRPO 相当于把 LLM RL 过程建模为了 Bandit 过程，从本质上就与 PPO 不同了
  • 注意：GRPO 对 PPO 的优化并不简单，从这个建模视角出发，其实 GRPO 是从本质上对 LLM RL 建模发生了改变的
    • PS：在 RL 中，如何定义“智能体与环境的交互”，决定了使用 Bandit 还是 MDP
  • GRPO vs PPO 的建模方法对比：
    维度 PPO GRPO
    底层数学模型 MDP Contextual Bandit（上下文多臂老虎机）
    决策粒度 Token-level （每生成一个词算一步） Response-level（生成整段话算一步）
    是否有状态转移 有（生成新 Token 改变当前上下文） 无（针对一个 Prompt 直接输出完整结果）
    是否需要 Critic 需要（用于评估半句话的未来价值） 不需要（没有未来状态需要评估）
    Advantage 计算 依赖 Critic 预测的价值 \(V(s)\) 计算 GAE 依赖对同一 Prompt 采样的多个回答的相对得分
    显存与计算开销 极大（需同时运行 Actor, Critic, Ref, Reward） 大幅降低（省去了庞大的 Critic 模型及相关梯度）
    适用场景 理论上信用分配更精细，但 LLM 中极难训练好 极其适合 LLM，尤其是数学/代码等有明确规则奖励的推理任务（如 DeepSeek-R1）

补充：MDP vs Bandit

MDP：强调“序列决策”与“状态转移”
  • 核心特征 ：当前动作会改变未来的状态
  • 运作机制 ：智能体在状态 \(S_t\) 下采取动作 \(A_t\)，不仅会获得一个即时奖励 \(R_t\)，还会导致环境转移到一个新的状态 \(S_{t+1}\)
  • 目标 ：不仅要看眼前的奖励，还要考虑长远利益（最大化累积折扣回报）
  • 难点（信用分配） ：如果最后通关了（或失败了），到底是因为第 1 步走得好，还是第 10 步走得好？
    • 为了解决这个问题，MDP 通常需要引入Value Function（即 Critic） ，来评估每一个中间状态“的奖励”
Bandit（多臂老虎机）：强调“单步决策”与“无状态转移”
  • 核心特征 ：动作不会影响未来的状态 ，每次决策都是独立的
  • 运作机制（Contextual Bandit 上下文老虎机） ：
    • 系统给定一个上下文（Context/State），做出一个 Action，立刻得到一个 Reward ，然后这一回合就结束了
    • 下一次系统再给一个新的上下文，重新开始
  • 目标 ：最大化当前这一步的奖励
  • 优势 ：不需要考虑未来状态，因此绝对不需要 Critic 来评估中间状态
    • 只需要比较在当前上下文里，哪个动作得分高就行

为什么 MCTS 在 LLM RL 中效果有限？

  • 问题补充描述：围棋场景，基于 MCTS 的 AlphaGo 方法有效，为什么在 LLM RL 中，MCTS 效果一般？
  • TLDR：围棋和自然语言生成在状态空间、奖励机制和环境 Dynamics 上存在本质差异，导致传统的 MCTS 无法直接平移，必须进行深度改造

动作空间的维度爆炸

  • 围棋场景：每一步的合法落子点最多只有 361 个（随着棋局进行越来越少）
    • MCTS 可以在这几百个分支中进行有效的蒙特卡洛采样
  • LLM：每一步（生成一个 Token）的动作空间是整个词表大小（通常为 10W+）
    • 如果在每个 Token 处都展开一棵宽度为 10W 的搜索树，计算量将瞬间爆炸，根本无法进行有效的树搜索
    • 注：MCTS 是需要估计 \(Q(s,a)\) 的，而 LLM 中巨大的状态空间和动作空间几乎让这个不可估计

轨迹长度

  • 围棋场景：棋盘填满或一方认输，游戏必然终止，轨迹不会太长
  • LLM：语言生成可能长达几十甚至几百 K 的 Token，太长了，不利于 MCTS 搜索走到最后

状态转移的确定性 vs 随机性

  • 围棋场景：是一个完美信息、完全确定的游戏
    • 落一子，棋盘状态的变化是 100% 确定的，拥有完美的“世界模型（模拟器）”
  • LLM：语言的语义空间是连续且模糊的
    • 虽然自回归生成下一个 Token 是确定的，但“人类如何理解这段话”以及“这段话的逻辑走向”是高度开放和发散的，缺乏一个完美的客观模拟器来推演未来

奖励信号的客观性 vs 主观性

  • 围棋场景：有绝对客观的胜负规则（+1, -1, 0）
    • MCTS 模拟到最后，一定能得到一个明确的真实反馈
  • LLM：语言生成的质量（是否有害、是否连贯、是否符合人类偏好）是主观的（注意：这里仅限 RLHF 的场景）
    • LLM RLHF 必须依赖一个额外训练的 Reward Model 来打分
    • 如果使用 MCTS 进行大量搜索，很容易发现奖励模型的漏洞（即发生 Reward Hacking），导致模型生成出得分极高但人类无法阅读的乱码
    • 注：RLVR 场景没有这个问题

一些思考

  • 虽然不能直接使用 MCTS，但仍然会使用 MCTS 的思路来解决 LLM 的信用分配难题，比如：
    • 1）过程奖励模型（PRM） ：不再只看最终结果（\(T=1\)），而是像人类老师批改数学题一样，给中间的每一个推理步骤打分
      • PRM 可以缓解了信用分配难题
    • 2）Test-Time Compute / Search ：不局限于 Token-level MCTS，而是提升到 Thinking Step 级别 进行搜索、回溯和自我修正

GRPO 和 PPO 谁的上限更高，为什么？

  • 个人认知结论：PPO 的上限更高，但需要精细调参和设计等
    • 1）估值准确性方面：如果 PPO 的 Critic 能够训练的很好，理论上会比 GRPO 这种 Group 内部均值替代 Critic 模型去估计 \(V(S)\) 的蒙特卡洛方式的方差更小
    • 2）PPO 是 Token-level 的 Advantage，理论训练效率更高些
    • 3）但PPO 调参难度更高
  • Token 学习效率（仅考虑 Actor 更新 Token 梯度的数量，而不是 Rollout 数量）PPO 理论上更大
    • 理论上 PPO 的 Token 学习效率应该更高，因为 PPO 是 Token-level 做 Advantage 精细训练的
      • 举例：如果多个正负 Rollout 的前半部分是相同的：
        • PPO 能够对这些 Token 进行更精细化的训练（因为有 Token-level 的 Value 模型作为参照，能准确判断动作的 Advantage）
        • GRPO 则强行绑定了同一个 Rollout 内部的 Token Advantage 相同，这会直接导致模型在相同的 (s,a) 上，同时更新不同的 Advantage，有些会互相抵消（其实是一种浪费）

开放 QA（BT RM）场景适合用 GRPO 吗？

  • 回答是肯定的，数学上只要有准确的奖励信号，GRPO 就适合，考虑到 LLM RL 中 Critic 都不好训练，显然 GRPO 这种 Critic-free 的方法是是合适的
  • 但需要注意通用回答使用 BT RM 输出是一个标量，很容易出现分差较小的情况
    • 一方面，当 BT RM 分数较为准确时，GRPO 可以针对这部分小分差做出更大的学习率（此时组内归一化会放大 Advantage，PPO 的 Batch 内部做 Token-level 的 Advantage 归一化等则不会过分放大这部分分差），此时可以加速学习（注：实践上可以看到这个学习速度很快）
    • 另一方面，当 BT RM 分数不太准确时，特别是分差较小时不容易估准，此时，正因为 GRPO 会把很小的分差也学的很仔细，很可能因为 BT RM 本身被 Hack 了（这个 hack 分数差异本来较小，但是使用 GRPO 的组内归一化以后就变得很大了），从而快速学到如何 Hacking 模型，导致快速出现 Reward Hacking 问题
      • 注：如果是真实的分数，即使分差较小，出现这个 hacking 的风险也会小一些（因为少了模型拟合误差这部分 Hacking）
  • 注：增加 KL 散度惩罚可以一定程度上缓解 Reward Hacking 问题
  • 注：实践发现，对小 std 组直接做过滤能极大程度缓解训练过程中的 kl spike 问题（因为一些极端的更新被 mask 了）
  • 注：在 BT RM 中增加 Rubrics 打分（类似 RLVR，可认为是接近 Ground Truth 的），也能够降低 BT RM 带来的 Reward Hacking 问题（已经实践尝试过）
  • 在分数差异较低时，由于 std 较低，所以得到的 Advantage 可能会较大（最大会到 2.5 左右）此时如果使用 KL Loss（k3 估计），则会很容易观察到 kl spike 现象
    • 问题分析：
      • 虽然 advantage 绝对值不会特别大（N=8 时最大会到 2.6 左右），但是因为 std 的存在，使得分数接近的部分（本应该较小 Advantage 学习的）被放大了，导致模型朝着未知的方向更新（偏离了原始的 Reference 模型），这会导致容易出现 kl spike
      • 可以通过程序证明，在原始数值在 0-1 之间时，原始 std 越小，经过归一化后的 Advantage 最大值越大（差异大概是 2.6 和 2.2 等的差异）
    • 亲测解决有两个：
      • 亲测（MoE 上）：不除以 std，类似 Dr.GRPO 的方法，可以大幅度减少 kl spike 现象
      • 亲测：Mask 掉 std 较低的 Token（或对 std 做 Clip），可以大幅减少（甚至在 Dense 模型上看到 kl spike 现象消失）
  • 实践结果：在开放 QA 场景，GRPO 往往也更容易在训练集上拿到更高的 Reward，但也更容易导致 Reward Hacking

补充：不同奖励下的 GRPO 归一化结果对比

  • 归一化结果对比
    数据集 均值 / 方差 / 标准差 Z-score 归一化结果 仅减均值结果
    [0,0,0,0,0,0,1,1] 0.25 / 0.1875 / 0.4330 [-0.577, -0.577, -0.577, -0.577, -0.577, -0.577, 1.732, 1.732] [-0.25, -0.25, -0.25, -0.25, -0.25, -0.25, 0.75, 0.75]
    [0,0,0,0,0,0,0,1] 0.125 / 0.109375 / 0.3307 [-0.378, -0.378, -0.378, -0.378, -0.378, -0.378, -0.378, 2.646] [-0.125, -0.125, -0.125, -0.125, -0.125, -0.125, -0.125, 0.875]
    [0,0,0,0,0,0,0,0.1] 0.0125 / 0.001094 / 0.03307 [-0.378, -0.378, -0.378, -0.378, -0.378, -0.378, -0.378, 2.646] [-0.0125, -0.0125, -0.0125, -0.0125, -0.0125, -0.0125, -0.0125, 0.0875]
    [0,0,0,0,0,0,0,0.01] 0.00125 / 1.094e-5 / 0.003307 [-0.378, -0.378, -0.378, -0.378, -0.378, -0.378, -0.378, 2.646] [-0.00125, -0.00125, -0.00125, -0.00125, -0.00125, -0.00125, -0.00125, 0.00875]
    [0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1] 0.125 / 0.109375 / 0.3307 [-0.378, -0.378, -0.378, -0.378, -0.378, -0.378, -0.378, -0.378, -0.378, -0.378, -0.378, -0.378, -0.378, -0.378, 2.646, 2.646] [-0.125, -0.125, -0.125, -0.125, -0.125, -0.125, -0.125, -0.125, -0.125, -0.125, -0.125, -0.125, -0.125, -0.125, 0.875, 0.875]
    [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1] 0.0625 / 0.05859375 / 0.2421 [-0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, 3.873] [-0.0625, -0.0625, -0.0625, -0.0625, -0.0625, -0.0625, -0.0625, -0.0625, -0.0625, -0.0625, -0.0625, -0.0625, -0.0625, -0.0625, -0.0625, 0.9375]
    [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.1] 0.00625 / 0.0005859 / 0.02421 [-0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, 3.873] [-0.00625, -0.00625, -0.00625, -0.00625, -0.00625, -0.00625, -0.00625, -0.00625, -0.00625, -0.00625, -0.00625, -0.00625, -0.00625, -0.00625, -0.00625, 0.09375]
    [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.01] 0.000625 / 5.859e-6 / 0.002421 [-0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, -0.258, 3.873] [-0.000625, -0.000625, -0.000625, -0.000625, -0.000625, -0.000625, -0.000625, -0.000625, -0.000625, -0.000625, -0.000625, -0.000625, -0.000625, -0.000625, -0.000625, 0.009375]

LLM 中，Token 位置对生成的速度的影响

  • 副标题：在 LLM 的推理过程中，假设 Prompt=9999，生成第 1 个 Token（Prefill 阶段）、第 2 个 Token 和第 10000 个 Token（Decode 阶段）所花费的时间
  • TLDR：生成这三个 Token 的时间分别为 \(T_1\)、\(T_2\) 和 \(T_{10000}\)，整体的时间关系结论为：
    $$ T_1 \gg T_{10000} > T_2 $$
    • \(T_1\) 最慢，因为要对 9999 个 Prompt Token 进行 \(\mathcal{O}(N^2)\) 的全量 Attention 矩阵乘法计算
    • \(T_{10000} > T_2\) ，因为在自回归的 Decode 阶段（访存受限），第 10000 个 Token 需要搬运和计算的 KV Cache 长度（19998）几乎是第 2 个 Token（10000）的两倍
      • 在 vLLM 的高并发场景下（由于 Continuous Batching，模型权重加载的开销被多个请求分摊），这种由于 KV Cache 线性增长带来的延迟上升会更加明显

理论计算效率分析

第 1 个 Token 的生成时间 \(T_1\) (Prefill 阶段，计算瓶颈)
  • 当 Prompt 长度 \(N = 9999\) 时，模型需要：
    • 一次性并行处理这 9999 个 Token，计算并保存这 9999 个 Token 的 KV Cache
    • 这是一个典型的 Compute-Bound 过程，主要依赖矩阵乘法（GEMM）
    • 时间复杂度（对于 Transformer 的一层）：
      • FFN 的复杂度为 \(\mathcal{O}(N \cdot d^2)\)
      • Self-Attention 的复杂度为 \(\mathcal{O}(N^2 \cdot d)\)
      • 其中 \(d\) 为隐藏层维度
    • 理论耗时为：
      $$ T_1 \propto \mathcal{O}(N \cdot d^2 + N^2 \cdot d) $$
    • 由于 \(N=9999\) 是一个较大的数值，\(N^2\) 带来的计算量非常巨大，因此 \(T_1\) 的耗时是最长的（通常被称为 TTFT, Time To First Token）
第 2 个与第 10000 个 Token 的生成时间 \(T_2\) 与 \(T_{10000}\) (Decode 阶段，内存带宽瓶颈)
  • 从第 2 个 Token 开始，模型进入自回归生成阶段
    • 每次只生成 1 个 Token，但需要与前面所有已生成的 Token 计算注意力权重
    • 为了避免重复计算，模型会读取之前保存的 KV Cache
    • 这是一个典型的 Memory-Bandwidth-Bound 过程，主要依赖矩阵向量乘法（GEMV）
      • 计算时间主要取决于将模型权重（Model Weights）和 KV Cache 从显存（HBM）搬运到计算单元（SRAM）的时间
    • 时间复杂度 ：生成第 \(i\) 个 Response Token 时，当前的总上下文长度为 \(L = N + i - 1\)
      • FFN 复杂度：\(\mathcal{O}(d^2)\) （常数级，因为只处理 1 个 Token）
      • Attention 复杂度：\(\mathcal{O}(L \cdot d)\) （线性级，需要和过去 \(L\) 个 Token 计算 Attention）
    • 理论耗时对比 ：
      • 生成第 2 个 Token 时，上下文长度 \(L_2 = 9999 + 1 = 10000\)
        $$ T_2 \propto \mathcal{O}(d^2 + 10000 \cdot d) $$
      • 生成第 10000 个 Token 时，上下文长度 \(L_{10000} = 9999 + 9999 = 19998\)
        $$ T_{10000} \propto \mathcal{O}(d^2 + 19998 \cdot d) $$
    • 由于 \(19998 > 10000\)，在 Attention 计算上 \(T_{10000}\) 需要处理的 KV Cache 是 \(T_2\) 的近两倍，因此理论上 \(T_{10000} > T_2\)
实际场景中 vLLM 的一般实现分析
  • vLLM 是专为高吞吐量设计的推理引擎，其核心创新是 PagedAttention 和 Continuous Batching
  • vLLM 中的 \(T_1\) (Prefill)
    • 标准的 vLLM 实现中，Prefill 阶段依然是高度并行的矩阵乘法
      • 即使 vLLM 引入了 PagedAttention，在 Prefill 阶段也需要为 9999 个 Token 分配物理块（Blocks）并写入 KV Cache
    • 由于庞大的计算量，\(T_1\) 依然远大于 Decode 阶段的任何一个 Token 的生成时间
    • 注：如果 vLLM 开启了 Chunked Prefill 特性，\(T_1\) 的时间会被截断分摊，但这改变的是调度策略，单次计算的总吞吐本质未变，宏观上 \(T_1\) 依然最长
vLLM 中的 \(T_2\) 与 \(T_{10000}\) (Decode)
  • 在 Decode 阶段，决定耗时的核心公式是：
    $$ T_{decode} \approx \max \left( t_{compute}, \frac{W_{model} + W_\text{kv_cache} }{\text{Memory Bandwidth} } \right) $$
  • 由于 Decode 是访存瓶颈，实际耗时主要由 加载模型权重 (\(W_{model}\)) 和 加载 KV Cache (\(W_\text{kv_cache}\)) 的时间决定
    • 加载模型权重 (\(W_{model}\)) ：
      • 无论生成第几个 Token，都需要把整个模型的权重从显存读一遍，这是一个巨大的常数开销
    • 加载 KV Cache (\(W_\text{kv_cache}\)) ：
      • 在生成第 2 个 Token 时，vLLM 需要通过 PagedAttention 的 Block Table 找到前 10000 个 Token 对应的物理显存块，并将其读入
      • 在生成第 10000 个 Token 时，需要读取前 19998 个 Token 的物理显存块
    • PagedAttention 的影响分析 ：
      • PagedAttention 解决了显存碎片化问题，使得显存分配是 \(\mathcal{O}(1)\) 的，但它无法改变物理读取数据量变大的事实
      • 读取 19998 个 Token 的 KV Cache 消耗的显存带宽必然大于读取 10000 个 Token
  • 实际表现的细微差别（Batch Size 的影响） ：
    • 在单并发（Batch Size = 1）时 ：
      • 模型权重 \(W_{model}\)（几十到上百 GB）远大于 KV Cache 的大小（几百 MB 到几 GB）
      • 此时带宽主要被加载权重占用，\(T_2\) 和 \(T_{10000}\) 的差距在体感上可能非常小，但物理测量上依然是 \(T_{10000} > T_2\)
    • 在高并发（Large Batch Size，vLLM 的典型场景）时 ：
      • 由于 Continuous Batching，模型权重加载的开销被多个请求分摊，此时 KV Cache 的读取成为了真正的瓶颈
      • 随着生成长度从 10000 增加到 19998，KV Cache 的访存量翻倍，这会导致 \(T_{10000}\) 显著慢于 \(T_2\)

SFT 中 Prompt 及其长度对参数梯度的影响

  • 副标题：做 SFT 时，假设 Loss 仅在 Response Token 上计算且取平均，同时不考虑样本 Packing 策略，请问：在相同 response 数量下，prompt 长度对 transformer SFT 训练算力，效率和最终性能的影响
  • 结论前置：
    • Prompt 越长，算力消耗会显著增加，训练效率会大幅下降
    • Prompt 长度对模型效果影响不一定
      • 必要的提供大量信息的 Prompt 可能提供更多的梯度信息，提升性能
      • 不相关的随机 Prompt 可能引入噪声、稀释注意力，导致性能下降
    • 记住：在 SFT 阶段，Prompt 的质量（信息密度、相关性、指令清晰度）远比 Prompt 的长度重要
      • 如果增加的 Prompt 长度是必要的（例如提供了不可或缺的背景知识、Few-shot 示例或复杂的推理条件），那么它确实能提升模型的特定能力，但这往往是以牺牲算力和效率为代价的
      • 如果仅仅是为了“增加长度”而注入冗余信息 ，不仅会成倍增加算力消耗和降低训练效率，还会因为注意力稀释和梯度噪声，导致模型最终的泛化性能和指令遵循能力下降

对训练算力（FLOPs）的影响

  • 在 Transformer 模型中，前向传播和反向传播的计算量（FLOPs）主要由两部分构成：Self-Attention 和 FFN
  • 假设 Prompt 长度为 \(L_p\)，Response 长度为 \(L_r\)，总序列长度 \(L = L_p + L_r\)，模型的隐藏层维度为 \(d\)
  • 虽然 Loss 仅在 \(L_r\) 上计算，但为了得到 Response Token 的表示，前向传播和反向传播必须处理整个长度为 \(L\) 的序列
    • 1）注意力机制的计算复杂度 ：与序列长度的平方成正比，即 \(\mathcal{O}(L^2 \cdot d)\)
    • 2）FFN 的计算复杂度 ：与序列长度成正比，即 \(\mathcal{O}(L \cdot d^2)\)
  • 单层 Transformer 的前向+反向总计算量近似为：
    $$ C \approx 72 \cdot L \cdot d^2 + 12 \cdot L^2 \cdot d $$
    • 注：这里的系数是基于标准 GPT 架构的近似估算，包含前向和反向
  • 小结：当 \(L_r\) 固定时，随着 \(L_p\) 的增加，总长度 \(L\) 增加
    • 特别是当 \(L_p\) 较大时，\(\mathcal{O}(L^2)\) 的项会占据主导地位，导致训练算力需求呈二次方或超线性增长

对训练效率（Efficiency / Throughput）的影响

  • 训练效率不仅受计算量的影响，还严重受限于显存和内存带宽
  • 1）激活显存（Activation Memory）增加 ：
      • 在反向传播中，为了计算梯度，必须保存前向传播时的激活值。激活显存的大小与 序列总长度 \(L\) 成正比：
        $$ M_{act} \propto L \cdot b \cdot h \cdot d $$
        • 其中 \(b\) 为 Batch Size，\(h\) 为层数，隐藏层维度为 \(d\)
  • 2）Batch Size 被迫减小 ：
    • 因为没有使用 Packing 策略，为了防止 OOM，随着 \(L_p\) 增加，单张显卡能容纳的 Batch Size \(b\) 必须减小
    • 注：存在 Packing 策略时，相同 Packing Size 及数量下，实际的 Batch Size 也是更小的
    • 在不存在 Packing 策略时，这会进一步导致 硬件利用率（MFU）下降：
      • 较小的 Batch Size 会导致 GEMM 无法充分利用 GPU 的计算单元，使得算力利用率下降
      • 更长的序列意味着单步训练耗时更长
  • 小结：Prompt 越长，系统的吞吐量会显著降低，训练效率大幅下降

对最终性能的影响

  • 在数学机制上：
    • Prompt 越长，模型 hidden 参数的梯度来源于更多 Prompt 的表示（受到更多 Prompt Token 的影响），所以训练效果会更好
    • 一般来说，如果 Prompt 是合理的，都属于这种情况
  • 在深度学习的优化逻辑上：
    • Prompt 越长，模型参数更新不一定更好（比如添加的 Prompt 可能是随机的，不必要的，带来噪音的）
梯度的数学来源分析
  • 假设在第 \(t\) 个 Token（属于 Response 区域，即 \(t > L_p\)）计算交叉熵 Loss：\(\mathcal{L}_t\)
    • 该 Token 的隐藏层表示 \(h_t\) 是通过注意力机制聚合了前面所有 Token（包括 Prompt）的信息：
      $$ h_t = \sum_{i=1}^{t} \alpha_{t,i} (W_V x_i) $$
      • 注意力权重 \(\alpha_{t,i}\) 为：
        $$ \alpha_{t,i} = \text{Softmax}\left( \frac{(W_Q x_t)(W_K x_i)^T}{\sqrt{d} } \right) $$
  • 当计算损失函数 \(\mathcal{L}\) 对权重矩阵（例如 \(W_V\)）的梯度时，根据链式法则：
    $$ \frac{\partial \mathcal{L} }{\partial W_V} = \sum_{t=L_p+1}^{L_p+L_r} \frac{\partial \mathcal{L}_t}{\partial h_t} \sum_{i=1}^{t} \alpha_{t,i} x_i^T $$
    • 从公式可以看出，梯度的确包含了所有 Prompt Token (\(i \le L_p\)) 的贡献
      • Prompt 越长，参与梯度计算的 \(x_i\) 确实越多
为什么“来源更多”不等于“效果更好”？
  • 虽然梯度受到了更多 Token 的影响，但这并不意味着训练效果更好，原因如下：
  • 注意力稀释（Attention Dilution） ：
    • Softmax 函数的特性是所有权重之和为 1，即 \(\sum_{i=1}^t \alpha_{t,i} = 1\)
    • 如果 Prompt 变长，且新增的 Token 并不是决定 Response 的核心信息，它们依然会分走一部分注意力权重
    • 这会导致模型对真正关键的 Context Token 的注意力权重 \(\alpha\) 变小，进而导致关键信息的梯度信号变弱
  • 噪声与方差增加（Noise and Variance） ：
    • 如果增加的 Prompt 包含冗余信息或无关信息，反向传播时这些无关 Token 产生的梯度会被视为“噪声”
    • 梯度中混入大量噪声会增加优化过程的方差，使得模型更难收敛到最优解
  • 迷失在中间（Lost in the Middle） ：
    • 大量研究表明，当前主流的 LLM 在处理长上下文时，倾向于关注开头和结尾的信息，而忽略中间的信息
    • 如果强行拉长 Prompt，模型可能无法有效提取长 Prompt 中的关键逻辑，导致 SFT 阶段模型学习到错误的因果关系（Spurious Correlations）

LLM 中 梯度裁剪的理解

  • 梯度范数最大值 grad-norm-max 或 max_norm（Megatron 中叫做 clip_grad ） 一般是 1.0 左右，超大模型可适量缩小
  • 梯度裁剪（Gradient Clipping）在具体操作上是对梯度整体做缩放，不是按参数选择性裁剪
    • 梯度裁剪的具体操作也称为：Global L2 Rescaling
  • 以 PyTorch 中最常用的就是 torch.nn.utils.clip_grad_norm_(parameters, max_norm)（Megatron 中源码实现也是一样的），它的做法是：
    • 全局梯度 L2 范数定义：
      $$ g = \nabla_\theta\mathcal{L},\quad ||g||_2 = \sqrt{\sum_{p\in\text{params}}\ \nabla p_2^2} $$
      • 注：学习率不参与反向传播计算，所以学习率不在梯度范数定义中，但学习率越大，梯度范数的波动可能越大，异常值也越多
        • 粗浅可以理解为：有效更新步长的上界是 lr × max_norm
    • 如果 \(||g||_2 > \text{max_norm}\)，则对所有参数的梯度统一缩放（否则不做任何改变）：
      $$\nabla p_i \leftarrow \nabla p_i \times \frac{\text{max_norm}}{||g||_2} $$
      • 注：这里的 \(||g||_2\) 有时候也写作 \(||g||\)（不明确指定时，默认为 2 范数）
    • 所有可传入的参数共享同一个缩放因子
    • 只改变梯度方向的大小（等比例缩小），不改变梯度方向
  • 训练中 grad-norm 的变化（一般上报的都是 clip 前的 norm 指标）：
    • SFT 时，一般一开始是几十甚至更高，然后逐步降低，稳定后在 1.0 以下，最终多个 epoch 后可能在 0.2 附近甚至更低
      • 训练过程中可能出现异常值，比如突然到几十甚至更高
    • RL 训练时一般比 SFT 时更小，亲测指标如下：
      • GRPO 下（除以 std，Loss 除以 \(\frac{1}{|o_i|}\)），一开始就在 0.5-2.0 之间，大部分时间在 0.5 附近，且看着逐步变小的趋势不明显），需要严格监控
      • Dr.GRPO 下（当 Advantage 不除以 std 时，loss 最大长度 Token 数），对应的梯度范数甚至长期低于 0.1!
      • 注：从 grad-norm 上也可以看出 Dr.GRPO 在相同学习率下训练效率较慢（可考虑提升学习率）
  • 与 Adam 的关系（先算 norm -> clip -> 再喂给 Adam）：
    • grad-norm 的计算 = 纯粹的 raw gradient L2 norm，与 Adam 状态无关
    • 正因为 Adam 的 m、v 接收的是 clip 后的梯度，所以 spike 不会污染 Adam 的内部状态
  • 梯度裁剪意味着：无论模型多大、梯度多爆炸，每一步参数更新的 L2 位移（在 clip 层面）不超过 lr × 1.0 的等效范围
    • clip 后等效于 grad_norm = clip_grad，方向保留但幅度被压到安全范围（一旦触发 Clip，Clip 后的梯度范数一定等于 clip_grad）
      $$||g_{\text{new}}||_2 = \left| g \times \frac{\text{max_norm}}{||g||_2} \right| = ||g||_2 \times \frac{\text{max_norm}}{||g||_2} = \text{max_norm} $$
  • 对梯度范数的理解：
    • 参数越大，梯度范数越大，也越容易波动到极端值（比如部分参数整体都是 100 左右，那么梯度范数就会很离谱）
    • 如果触发了 Clip，参数量越大，分到每个参数头上的“更新步幅”就越小
  • grad-norm 相关可能的上报指标汇总：
    • 通常会有 grad-norm, grad-norm vs samples, grad-norm vs tokens 三种指标
      • 纵轴都是 梯度范数值，横轴不同，是为了方便观察不同训练量下的结果
    • grad-norm 横轴为 iteration，即训练的梯度步
    • grad-norm vs samples 横轴为 consumed_train_samples，即消耗的样本数
    • grad-norm vs tokens 横轴为 consumed_train_tokens，即消耗的 Token 数量

LLM RL 时是否应该更新 Router 和 打开负载均衡

  • 一般为了保证 RL 训练期间稳定性

    • 一般不打开 Router 更新
    • 一般不打开负载均衡 Bias 更新
      • 注：因为 loss-free 的负载均衡不参与梯度更新（这个负载均衡方式来自 DeepSeek），本身游离于梯度外，可能导致不必要的波动，让 RL 不够稳定

  • 注意：几十冻结了 Router 的参数，expert 参数更新其实会间接影响路由行为

    • 冻结 router 的意义不是”让路由永远不变”，而是去掉 router 的直接梯度更新这条快通道，让路由只能通过表示空间的自然漂移缓慢适应，避免 RL 噪声导致路由崩溃

  • 详细分析：

    • Router 计算分数是：

      1
      2
      scores = hidden_state @ router_weight # router_weight：被冻结，不更新; hidden_state：来自上游（attention + 前面层的 expert 输出）在变
      top_k_experts = topk(scores, k)

    • 冻结 router 时：路由只因 hidden_state 漂移而缓慢变化

    • 不冻结 router 时：路由同时受 RL 梯度直接驱动 + hidden_state 变化，双重扰动，容易崩溃

LLM RL 训练记录排查

  • 在训练时，发现不同训练策略（同步 / One-off 模式）下，相同 Rollout Batch Size 配置，进入 Rollout 和 打分的 Prompt 数量不一样
  • 最终排查结论：
    • 由于异步策略 Worker Colocated 性质，one-off 模式下 Actor 和 SFT 与 Generator 无法共享资源（注：Actor/SFT 顺序推理可以共享），于是 Generator 只能独自用自己的卡，此时的 dp 值可能是 N
    • 同步策略下，Actor、SFT 和 Generator 都可以共享资源，所以导致此时的 DP 较高，比如是 3N
    • 最终每个 Rollout Step 输入模型的 Rollout 数量必须是 DP 的倍数（不够则使用最小补足数字）
    • 假设 Rollout Batch Size 是 2N，那么（注：这里是不考虑多采样的情况下，配置超额采样系数时，需要先乘以这个系数）：
      • One-off 下，输入 Rollout 的数量还是 2N（已经是 N 的倍数了）
      • 同步策略下，输入的 Rollout 数量是 3N（因为 2N 不是 3N 的倍数）

LLM RL 训练和 LLM SFT 训练的 Adam 配置为什么不同？

  • 背景：LLM RL 训练和 LLM SFT 训练的 Adam 配置是不同的

    1
    2
    3
    4
    5
    6
    7
    8
    9
    optimizer: adam
    adam_beta1: 0.9
    adam_eps: 1.0e-16

    #SFT 时使用的 adam 配置为：
    adam_beta2: 0.95

    # RL 时使用的为：
    adam_beta2: 0.999

  • 这是 LLM 训练中一个非常经典、且经过大量实战检验的超参数设置差异

    • 注：比如从 GPT-3 开始，到 Llama 的对齐训练中，都广泛采用了这种策略

  • 理解 Adam 优化器中 adam_beta2 的物理意义，以及 SFT（监督微调）和 RL（强化学习）两种训练模式下损失景观（Loss Landscape）和梯度噪声的根本区别

    • 在 Adam 优化器中：
      • beta1 (通常为 0.9) 控制一阶矩（动量），即梯度的方向
      • beta2 控制二阶矩（梯度的平方的指数移动平均），它用来缩放每个参数的学习率
    • 更细粒度来说：beta2 的大小决定了优化器对历史梯度方差的“记忆长度”：
      • beta2 较大（0.999）：记忆长，平滑作用强
        • 优化器主要参考长期的历史梯度，对近期的突变反应较慢
      • beta2 较小（0.95）：记忆短，平滑作用弱
        • 优化器会更快地“忘记”过去，对当前 Batch 带来的梯度变化反应极其迅速

为什么 SFT 使用 beta2 = 0.95？

  • 在 Pre-training 和 SFT 中，把 beta2 从默认的 0.999 降到 0.95 几乎是大模型 Transformer 的标配
    • 1）防范梯度尖峰： Transformer 在通过交叉熵拟合海量文本时，偶尔会遇到非常难的样本或特殊的 batch，导致梯度瞬间爆炸（即梯度尖峰）
    • 2）敏捷避险： 如果使用 0.999，优化器对历史的平稳梯度记忆太深，遇到尖峰时，分母来不及变大，导致步伐迈得太大，损失函数瞬间飞升甚至彻底崩盘（Loss 变 NaN）
      • 将 beta2 设为 0.95，优化器就能迅速捕捉到当前的梯度剧增，快速放大分母，从而压低该步的实际更新量，化解尖峰危机
  • 总结：SFT 的目标明确、数据相对稳定，设置 0.95 是为了赋予模型“敏捷避险”的能力

为什么 RL 使用 beta2 = 0.999？

  • 当进入 RL 阶段（如 PPO 算法，RLHF 的核心），整个训练环境发生了较大的变化
    • 1）极度嘈杂的梯度： RL 不像 SFT 有固定的标准答案
      • RL 是通过模型自己采样生成文本，再由 Reward Model 打分来计算优势并回传梯度
      • RL 这个过程充满了极大的采样方差和随机噪声
    • 2）对抗波动： 如果在 RL 中继续使用 0.95
      • 由于每个 Batch 采样的结果好坏参差不齐，梯度大小忽高忽低，短记忆的优化器会被这种“噪音”牵着鼻子走，导致策略网络更新极其不稳定，很容易引发模式崩溃或 KL 散度失控
    • 3）巨大的“减震器”：
      • 换回默认的 0.999，相当于给优化器安装了一个重型减震器
      • 它强制优化器拉长记忆，只看重长期积累的总体趋势，过滤掉单次采样带来的偶然波动
  • 总结：RL 充满随机性和噪声，设置 0.999 是为了让模型“稳如泰山”，避免被局部的噪声带偏

补充：从 SFT 切换到 RL 时，模型的哪些配置参数需要修改？

  • 学习率：
    • 1）RL 一般是 SFT 的 1/10（RL 低一个数量级）
      • 注：其实也跟 RL 是否做 STD，以及归一化方式等有关，不同的方式对应的梯度范数不同，对应的 学习率也应该不同
    • 2）RL 的学习率一般不变，SFT 的学习率一般会是 Cosine 调度，最小值是最大值的 1/10 左右
  • adam_beta2：详情见上文
  • MTP：SFT 等 NTP 场景中可以打开，RL 时一般不开
  • loss_free_balance：RL 中一般关闭（为了稳定性考虑）
  • 特别注意：各种 yarn 等策略以及采样策略必须在训推引擎上相同，否则容易出现训推不一致的问题（监控训推不一致的问题）