本文主要介绍LLM
- 参考链接：
- 比较全面的总结：每天学习一点点—大模型知识学习
- 一些问题解答：swtheking-知乎用户-南京大学-百度，本文许多问题参考自该账号
- transformer和大模型等技术博客：【必看】历史技术文章导航——知乎-猛猿-伊利诺伊大学厄巴纳-香槟分校 信息管理硕士
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
71.<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回收桶
- 合理猜想：因为第一个位置是每个句子都有的，该位置更重要？
- 这个有一定依据，有博主做过实验发现第一个token的一致性比其他位置更重要
微调/推理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来对模型进行微调，但却表现出了极其强大的性能
- 关于这个文章的解读：抛弃RLHF？MetaAI发布最新大语言模型训练方法：LIMA
- 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 表示，减低内存带宽和算力要求等，保证模型的效果差别不大。此时模型不需要训练，使用只需要调一下超参数就直接能跑
- 这里的Post-Training是指什么？Pre-trained,Post-training,finetune的区别
提升 SFT 阶段 Prompt 多样性？
如何提升SFT阶段Prompt的多样性？
- #INSTAG: INSTRUCTION TAGGING FOR ANALYZING SUPERVISED FINE-TUNING OF LARGE LANGUAGE MODELS
- 基本思想：打Tag?【TODO】
- Self-evolved diverse data sampling for efficient instruction tuning
- 基本思想：Prompt经过模型后，最后一层的输出拿来做embedding，相似的就去掉，减少重复
- WizardCoder: Empowering Code Large Language Models with Evol-Instruct
- 基本思想：对Prompt进行多样变化，即使表达同一个含义，改成不同复杂度的问题也会有收益？
各种 Norm 方式的优缺点
- 参考RUC的Survey论文：A Survey of Large Language Models
- 参考链接：大模型八股答案（一）——基础知识
- 不同模型选择的Norm方式
- LLaMA使用RMSNorm，GPT使用LayerNorm，GLM使用Post DeepNorm
- 不同Norm的计算公式
- RMSNorm是对LayerNorm的一个改进
- 没有re-center操作，相当于LayerNorm计算标准差 \(\sigma\) 和去中心化时 \(x-\mu\) 中的 \(\mu=0\)
- 没有 \(\beta\) 参数，相当于LayerNorm的 \(\beta=0\)
- RMSNorm是对LayerNorm的一个改进
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
- 大部分模板中，常常将 Instruction 和 Input 合并到一起作为一轮的模型输入（用
客服行业后训练有哪些经验沉淀？
- 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，不过这是针对其特定的训练规模和数据量而言的，对于其他大模型，退火阶段可能从训练的最后百分之几到几十不等，没有固定的标准比例
- LR 退火指在训练后期，逐渐减少学习率的过程
大模型左 Padding 还是右 Padding？
关键词：左 Padding（Left Padding），也称为 左填充；右 Padding（Right Padding），也称为 右填充
训练的时候无所谓，左 Padding 或右 Padding 均可以，但训练资源宝贵，大多时候是选择不 Padding，按照固定长度组合起来训练更为常见；
- 但：LLM 左填充(left padding) VS 右填充(right padding) - LLMCat的文章 - 知乎 中提到自回归训练会偏向右填充
推理时，一般选择左 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 对模型分布的改变较大，因为学习的数据不一定是来源于模型的，且没有探索能力，容易过拟合，缺乏泛化性
- On the Generalization of SFT: A Reinforcement Learning Perspective with Reward Rectification 给出了另一个视角，SFT 和 RL 的损失函数上也相差了一个权重
- RLHF 则更利于泛化性（不容易过拟合）
- Online RL 会让模型进行各种探索，并及时给出反馈，减少模型的过拟合情况
- RL 特别针对模型的输出进行惩罚或奖励，相当于是对模型真实动作的调教，不会过度调整其他不相关 Token
- 学术上常常将这个动作称为 Distribution Sharpening（分布锐化），表示仅仅调整已有分布（高分更高，低分更低），RL 本质是在雕琢而非重塑
- DPO 可以算是一种离线强化学习的方法，鼓励正样本，打压负样本，但其 Token 是固定的，也不是当前模型生成的，仍然容易造成过拟合
- SFT 对模型分布的改变较大，因为学习的数据不一定是来源于模型的，且没有探索能力，容易过拟合，缺乏泛化性
- 除了这两种范式外，还有一种简单的思路是拒绝采样微调（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 上吗？
- 回答：这里的效率低下是指信号少，简单来说就是信号越少，梯度更新就越不准确（比如每次可能只知道梯度的使得最终结果准确的一个粗糙方向，而这个方向上中间过程可能是错的，所以不是准确方向？）
- 之前的 PRM 等在尝试改善这个问题，但最终因为准确性而导致效果不加，没有被推广；
- 训练流程复杂，对训练框架要求高，且稳定性不如 SFT，这些都在逐步改善
- 终极设想：
- 在无需 SFT 或少量 SFT 后，直接 RL，甚至结合具身智能接收真实环境反馈以后，获取更通用的高阶能力
- 注：如果模型初始能力又太差，且完全不使用 SFT，可能导致 RL 无法训练
- 在无需 SFT 或少量 SFT 后，直接 RL，甚至结合具身智能接收真实环境反馈以后，获取更通用的高阶能力
- 在博客 大突破！实验证明，RL能为LLM注入“创新”能力, 20250907 中，提出了 RL 可以使得模型学习到组合能力，且具有泛化性，而 RFT 没有这个能力
- 核心是通过 RLVR 可以实现组合模型的原子能力，最终实现能力组合，并通过字符串处理的组合最终泛化到了 Countdown 任务上
- Countdown 任务：给定一组数字和目标值，仅用加减乘除构造等于目标的等式，每个数字仅用一次，常作为推理 / 强化学习的训练任务
- 核心是通过 RLVR 可以实现组合模型的原子能力，最终实现能力组合，并通过字符串处理的组合最终泛化到了 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 生成都会崩坏，变成无意义的乱码或重复符号
- 在模型解码时，只要有一个 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
- 数值精度溢出 (Numerical Instability)，这是最常见原因
- 使用建议：
- 不要盲目追求大 Batch，限制
max_num_seqs可以强行压制并发，避免进入“抖动区” - 切换精度到 BF16
- 调整显存利用率，稍微降低 vLLM 的显存占用比例，防止它把显存吃得太死，留一点 buffer 给 PyTorch 的临时张量分配
- 不要盲目追求大 Batch，限制
模型训练为什么一般每台机器最多到 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 自身使用的 NCCL 相关的特定算法可能是包含不确定性的
- 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 内核的执行时序、缓存命中情况也会导致块处理顺序变化，放大这种偏差
- FlashAttention 的核心是“分块计算+显存复用”（将 Q/K/V 切分成小块，避免全量存储注意力矩阵），默认模式下：
- 原子操作/归约的非确定性
- 注意力计算中涉及大量“归约操作”（如 softmax 中的求和、注意力权重与 V 的加权和），FlashAttention 默认会用 GPU 原子操作（atomic operations）加速归约：
- 原子操作的执行顺序由硬件决定（多线程同时更新同一个内存地址），不同运行时的执行顺序不同，会导致浮点数累加的舍入结果不同；
- 例如：
a + b + c和b + a + c在低精度下可能得到不同结果（如1e-5级别的偏差）
- 注意力计算中涉及大量“归约操作”（如 softmax 中的求和、注意力权重与 V 的加权和），FlashAttention 默认会用 GPU 原子操作（atomic operations）加速归约：
- CUDA 内核的优化策略
- FlashAttention 基于 CUDA 定制内核实现，默认会启用 NVIDIA CUDA 的
--fast-math等优化：- 这些优化会牺牲严格的数学确定性（如忽略某些浮点精度约束、重排计算顺序）以提升速度；
- 不同运行时，编译器/硬件的优化策略可能细微调整，导致结果差异
- FlashAttention 基于 CUDA 定制内核实现，默认会启用 NVIDIA CUDA 的
- 全局 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 数量可能减少也可能增多，不确定
- GPU kernel 启动效率 & 序列长度对吞吐的影响
结论
- 在全注意力下：
- 如果使用标准 Transformer 全注意力** ：16K packing 更快 ，因为长序列的 \(O(n^2)\) 注意力计算会拖慢训练
- 单个 128K 样本的注意力计算量是
(128K)^2，比多个 16K 样本的(16K)^2 * 62要大很多，理论上，在没有优化的情况下，128K packing 会更慢 ，因为长序列的计算复杂度高
- 单个 128K 样本的注意力计算量是
- 如果使用高效长序列优化（如 FlashAttention-2、分块注意力、稀疏注意力）并且显存足够：128K packing 可能更快，因为减少了 kernel 启动和数据通信开销
- 实际速度取决于你的模型实现、硬件（尤其是 GPU 架构）以及注意力优化程度
- 如果使用标准 Transformer 全注意力** ：16K packing 更快 ，因为长序列的 \(O(n^2)\) 注意力计算会拖慢训练
- 实际测试：
- 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 类似，每次仅更新部分参数，可以使用较大的学习率
- MoE 模型 通常比 Dense 模型更大
- 其他说明：学习率一般还与 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 分别计算梯度后再累加梯度，与先将所有 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}
$$
- 对每个位置 \(t\)，计算梯度：
- 方式二：先求总 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
8max_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
5torch.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 变大而线性增加显存（除非某些特殊实现导致中间变量未释放）
- 激活显存的主要影响因子是 MBS
- 静态显存 (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 = 2 时：
- 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
- XiaomiMiMo/MiMo-V2-Flash 建议使用参数：
- 一般来说，对准确性要求越高的任务，
- 注：
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 计算
- 这才是真正能发挥计算加速的模式，但实现难度大，精度损失风险高
- Weight-Only Quantization (如 W8A16)：
- 软件栈与 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 的生成延迟
- 推理（特别是生成式任务）是自回归的（Autoregressive），即生成下一个 Token 依赖于上一个 Token
通信模式与带宽利用
- PP（训练更友好）：通信量小，点对点
- PP 只需要在流水线阶段的边界（即两个 GPU 之间）传输激活值（Activations）和梯度
- 通信量相对较小，且是点对点（P2P）通信
- PP 非常适合跨节点（Inter-node）扩展
- 当模型大到需要跨多台服务器训练时，节点间的网络带宽（Ethernet/Infiniband）通常远低于节点内（NVLink）
- PP 对带宽要求较低，适合跨机
- PP 只需要在流水线阶段的边界（即两个 GPU 之间）传输激活值（Activations）和梯度
- TP（部署更友好）：通信量大，全互联
- TP 在每一层（Layer）的计算后都需要进行一次
All-Reduce通信来同步结果 - 通信频率极高，通信量大
- TP 要求极高的通信带宽和极低的通信延迟
- TP 通常限制在单机内部（Intra-node） ，利用 NVLink 这种高速互联
- 部署时通常尽量将模型塞在一个节点内（或少数节点），正好发挥 TP 优势，利用多卡显存带宽加速解码
- TP 在每一层（Layer）的计算后都需要进行一次
显存与计算的权衡
- 训练时的显存压力 ：
- 训练不仅要存参数，还要存梯度（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 参数
- Critic 的拟合目标 \(V_{target}\) 通常被设定为 \(V_{target} = V_{old}(s_t) + A^{GAE}_t\)（即估计的真实回报 Returns）
NLP 多语言分类
- FastText 官方开源了一个语言检测模型，专门用于识别文本所属的自然语言，是 Facebook AI 团队（FAIR）开源的官方预训练模型之一
- 下载地址：lid.176.bin
- 轻量版（压缩后，加载速度更快，效果基本一致）：lid.176.ftz（
.ftz是FastText的压缩模型格式，同样用fasttext.load_model()加载） - 注：
.bin是FastText的原生模型格式，包含模型的权重、词汇表、训练参数等完整信息，只能通过fasttext.load_model()加载使用
- 轻量版（压缩后，加载速度更快，效果基本一致）：lid.176.ftz（
- 能识别 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
23import 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 和 PPO 谁的上限更高，为什么？
- 两者的本质区别是：
- GRPO 不需要训练 Critic 模型，范式上更简单，超参数更少，适合作为第一版 Baseline 模型
- GRPO 可以组内做归一化，放大分差较小的组的 Advantage，让模型天然更关注这部分样本
- GRPO 是使用 Group 内部均值替代 Critic 模型去估计 \(V(S)\)
- GRPO 的 Advantage 是 Sequence-level 的，同一个 Sequence 的所有 Token 相同 Advantage
- 个人认知结论：PPO 的上限更高，但需要精细调参和设计等
- 1）估值准确性方面：如果 PPO 的 Critic 能够训练的很好，理论上会比 GRPO 这种 Group 内部均值替代 Critic 模型去估计 \(V(S)\) 的蒙特卡洛方式更加准确，虽然都是无偏估计，但理论上 Critic Model 的方差更小
- 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，有些会互相抵消（其实是一种浪费），因为虽然 GRPO 的 Group 内部均值是 \(V(S)\) 的无偏估计，但理论上估值也不一定准确，因为存在方差（除非采样的 Rollout 非常多，这样效率会大幅下降）
- 举例：如果多个正负 Rollout 的前半部分是相同的：
- 但 PPO 需要保证训练 Critic 模型到收敛，冷启动时间长，后续 Actor 学习率大也容易导致 Critic 模型学习来不及，所以整体看，训练相同的 Step，PPO 不一定比 GRPO 高效（相同的 Rollout 的话，PPO 可能能做到更好些）
- 理论上 PPO 的 Token 学习效率应该更高，因为 PPO 是 Token-level 做 Advantage 精细训练的
- 调参难度：
- PPO 训练过程中，需要监控 Critic 的训练收敛性等，否则容易导致一些位置的特有偏差
- 加上 Actor 学习率太大会导致 Critic 学习跟不上，PPO 的调参难度更大
- GRPO 需要大量采样 Rollout，在 Rollout 成本高昂的今天，要特别注意这部分成本（当然，PPO 中训练 Critic Model 本身也是比较难的）
RLVR 场景中，GRPO 为什么比 PPO 效果好？
- 主要归功于 GRPO 摒弃了 PPO 中难以调教的 Critic/Value Model 网络，利用群体采样的相对优势来优化策略
- 注：这里不提计算资源与显存效率（最核心优势）
- TLDR：RLVR 场景下，GRPO 通过移除 Critic 模型 并利用组内相对奖励 ，在大幅降低计算成本的同时，提供了比 PPO 更稳定、更准确的梯度信号，从而更有效地激发模型的推理能力
优势1：Baseline 估计的准确性与稳定性
- 强化学习的核心在于计算 Advantage ，即当前动作比“平均水平”好多少
- PPO 的方式（依赖模型）：
- PPO 使用一个神经网络（Critic）来预测 \(V(s)\) 作为基线
- 注：训练 Critic 本身非常困难
- 如果 Critic 估算不准（在推理任务中，价值往往在 0 和 1 之间剧烈跳变，很难拟合），计算出的优势就不准，导致 Policy 训练崩溃或震荡
- GRPO 的方式（依赖群体统计）：
- GRPO 对于同一个 Prompt 采样一组输出，例如生成 \(G\) 个解
- 它直接使用这组输出的平均奖励作为 Baseline
- 这种基于当前 Batch 的统计平均值是一个无偏且低方差的基线
- 不需要训练额外的网络去“猜”分值，而是直接看“在这个 Prompt 下，当前输出相对于其他 \(G-1\) 个输出是好是坏”
- 这在 RLVR 场景下极其有效，因为数学/代码的奖励通常是二元的（对/错），组内对比能提供非常清晰的梯度信号
优势2：适应 RLVR 的长链条推理
- RLVR 场景目前通常是涉及一些复杂推理步骤的
- PPO 的局限： PPO 通常依赖“Token 级别的奖励”或者需要 Critic 在每一步都能评估价值
- 但在长思维链中，中间步骤的价值很难评估（一个小的计算错误可能导致最后全错，Critic 很难捕捉这种长程依赖）
- GRPO 的适应性： GRPO 关注的是最终结果（Outcome-based）
- 通过对比一组生成的长思维链，模型能自动学会：“那些最终答案正确的思维链，其内部的推理模式是好的”
- 由于没有 Critic 带来的估值噪声，模型更容易涌现出自我修正和长程规划的能力（如 DeepSeek-R1 中观察到的现象）
- 注：长 CoT 中，这个优势也不是绝对的，因为 GRPO 是 Sequence-level 的 Advantage，越长的回复，把所有 Token 的 Advantage 都设置成一样的越危险！
训练超参数与复杂度的简化
- PPO： 需要调节 Actor 和 Critic 的学习率比例、GAE（Generalized Advantage Estimation）的参数等
- Critic 的 Loss 如果不下降，Actor 也学不好
- GRPO： 只有 Policy 的 Loss
- 超参数更少，训练流程更接近标准的 SFT，工程实现的稳定性更高
开放 QA（BT RM）场景适合用 GRPO 吗？
- 回答是肯定的，数学上只要有准确的奖励信号，GRPO 就适合
- 但需要注意通用回答使用 BT RM 输出是一个标量，很容易出现分差较小的情况
- 一方面，当 BT RM 分数较为准确时，GRPO 可以针对这部分小分差做出更大的学习率（此时组内归一化会放大 Advantage，PPO 的 Batch 内部做 Token-level 的 Advantage 归一化等则不会过分放大这部分分差），此时可以加速学习（注：实践上可以看到这个学习速度很快）
- 另一方面，当 BT RM 分数不太准确时，特别是分差较小时不容易估准，此时，正因为 GRPO 会把很小的分差也学的很仔细，很可能因为 BT RM 本身被 Hack 了（这个 hack 分数差异本来较小，但是使用 GRPO 的组内归一化以后就变得很大了），从而快速学到如何 Hacking 模型，导致快速出现 Reward Hacking 问题
- 注：如果是真实的分数，即使分差较小，出现这个 hacking 的风险也会小一些
- 根源还是在 BT RM 的打分不是 RLVR 场景的 Ground Truth 场景，同时还可能出现
- 注：增加 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，可以大幅减少（甚至在 Dense 模型上看到 kl spike 现象消失）
- 其他推测：对 std 做 Clip 也可以解决问题
- 问题分析：
- 总结来看，在开放 QA 场景，GRPO 往往也更容易在训练集上拿到更高的 Reward，但也更容易导致 Reward Hacking
GRPO 归一化时，Advantage 的最大值是多少？
- 可以证明，若方差使用有偏估计（分母为 N），则 N 个数字归一化以后的结果，最大值是 \(\sqrt{N-1}\)，详情见本人 GRPO 解读博客
在不同情况下分别用什么 KL 散度估计器？
- 直接添加到 Loss 上的（GRPO）：k3 估计器
- 添加到 Reward 上的（REINFORCE++）：k2 估计器
- 文章附录中讨论了 REINFORCE++ 这种情况下 k2 估计器 和 k3 估计器的区别，在 REINFORCE++ 这种奖励设计下，k3 估计器无偏，但是梯度有偏
- 其他讨论：Reinforce++和它的KL Loss选择 - 长琴的文章 - 知乎
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 信号作为辅助
- 笔者遇到过的情况：长度惩罚 + RLVR 要求出现 4 个
- 容易出现的问题：
- 约束之间互相矛盾
- 约束不够全面，留下太多 Reward Hacking 的空间
- 约束与 Query 不契合，比如 Query 要求写一首中文古诗，但 约束要求输出英语等
- RLVR 信号需要准确而全面：一般来说 RLVR 信号如果不够全面就容易 Reward Hacking
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 级别的 Advantage 与 RM 的长度偏好有关
- Response 级别的 Advantage 均值为 0 是因为 GRPO 会在组内做归一化（减去均值会导致期望为 0）
- 注：理论上，不考虑 Response 过滤行为， Response 级别的 Advantage 均值应该是绝对为 0 的（各组均值为 0 的 Response 展开均值也为 0）
- 显示场景中也遇到过一些问题，详情见下文的附录
- Token 级别的 Advantage 均值与 RM 长度偏好有关，以每组两个 Reponse 为例：
- 若 RM 倾向于长的 Reponse：
- 两个样本的 Advantage 均值为 0，两者 Advantage 相反
- 长 Response、短 Response 的每个 Token 都被赋予各自相同的 Advantage 值
- 整体按照 Token 求平均以后 Advantage 均值大于 0
- 若 RM 倾向于短的 Reponse：
- 与上面相反，得到的结果是 均值小于 0
- 若 RM 倾向于长的 Reponse：
附录：记一次 GRPO 问题排查过程
问题描述：现实场景中发现过 GRPO 训练时，大 部分 Step 的 GBS 内部 Advantage 均值微微大于 0 的情况（约 5e-3 量级）
问题确认：
最终经过排查发现似乎是因为归一化时，全等的数据因为计算误差出现了均值不为 0 的情况（此时除以特别小的标准差以后得到的值较大）
表现为同一个 Group 内部归一化后的值相等（均值计算出现误差导致），且归一化后正值的概率大于负值的概率（不同原始值得到的正负误差是确定的，我们的场景更容易出现某个正误差的相同值，所以一直偏正）
解决方法1：切换到精度更高的
torch.float64(PyTorch 默认为torch.float32)1
2
3
4
5original_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
4if 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就知道这是为了复现结果，无需额外解释。
- 既然 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引擎
- TIS 和 MIS 等功能会用到，也方便记录
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 的回答
- 比如：训练初期，收敛不平缓，假设要求正确答案在前面输出一个特殊格式，在这个格式被学到之前（极少样本采样到这个特殊格式），模型的熵偏低
- 在大部分场景中，RL 本质是在锐化分布，让模型策略朝着正确答案的方向更新，所以熵一般是下降的
- 一定有问题的情况：
- 熵下降非常快的情况（一般伴随着 KL 散度下降特别快）
- 模型可能 hacking 到了一种错误模式，常见的如输出重复
- 熵提升非常快的情况
- 熵下降非常快的情况（一般伴随着 KL 散度下降特别快）
- 个人理解对熵的期望：熵先下降（可短暂上升），然后持平或微弱波动
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))$$
- 无论是将 \(\pi(y|x)\) 拆解为（Token-level），还是将其视为一个整体概率（Response-level），概率的表达式都是一样的：
- 问题：如果把 \(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 的建模目标是最大化整个轨迹整体的最大累计奖励（隐含了当前决策本质并不是贪心的，而是考虑当前决策对未来行为和奖励的影响的）
- 在 RLHF 中，通常优化的目标是：
- 但是，在实际操作中，这种等价性会因为以下原因被打破：
- 1）信用分配 (Credit Assignment):
- Token-level 建模可以通过 Value Function (如 PPO 中的 Critic 网络) 评估每一个 Token 对最终奖励的贡献
- Response-level 建模将整个序列视为黑盒，无法区分是哪个词写得好，哪个词写得差
- 这在长文本生成中会导致训练效率低下
- 2）搜索空间与探索:
- Token-level 在每一步都在进行概率分布的调整，探索空间是“树状”的
- Response-level 的探索是“点状”的（即对整个句子的采样）
- 在动作空间极大的情况下（LLM 的输出空间几乎是无限的），Response-level 往往依赖于离线数据（Offline RL），而非在线探索
- 1）信用分配 (Credit Assignment):
- 但这是“策略等价”而非“优化过程等价”
- 实际中，由于优化算法、探索、稳定性的差异，它们往往收敛到不同的局部最优
其他讨论
- 补充：如果是 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？
- 实践视角：
- 一些文章（如 (Sequence-level MIS)When speed kills stability: Demystifying RL collapse from the training-inference mismatch, 20250927, ByteDance）中观察到，只有 当 vLLM 概率 \(\color{red}{\pi^\text{vllm}_\theta}\) 趋近于零时，不一致程度往往更为显著
- 梯度视角：
- 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时一般不需要特别修复（一般默认 Policy 的logprobs就是使用 默认temperature=1.0来算的）- 当
temperature != 1.0时，需要考虑对齐两者的 temperature 参数（当前策略的logprobs计算跟 Rollout 参数对齐），否则会导致训推不一致问题
- 当
- 注意：若 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 策略无法对齐），这会导致训练出现异常
- 比如 vllm 中的参数应该是需要使用默认值：
训练时该不该加 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 信号可以大幅缓解一些针对性问题（如语言混乱）
- GDPO 的基本思路是解耦信号
- 问题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 级别起作用：
$$ 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 级别计算 Advantage
- Critic 模型在训练时，预测的是“包含 KL 惩罚的综合回报”
- PPO 能感知到模型在某个特定 Token 上偏离参考模型带来的惩罚，从而提供非常细粒度、稠密的梯度信号
- 原因2：符合标准 MDP 设定：
- 传统 RL 框架中，算法本身（PPO）是一个黑盒优化器，它只认环境给的 Reward
- 把 KL 惩罚作为环境 Reward 的一部分，使得 PPO 算法的内部逻辑（包括 PPO 的 Surrogate Loss 和 Value Loss）不需要做任何修改，工程实现上非常优雅和解耦
- PPO 中，将 KL 作为损失和加入 Reward 是等价的吗？
- 虽然两者都在 Token 级别惩罚了偏离，但因为 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 的预知能力
- kl in Reward 时，Critic 的“预判”能力能提前避开高 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 的更新完全不受影响（因为此时只是通过梯度传播）
- KL in Reward 时，PPO 使用 GAE 计算优势，GAE 会将未来的奖励（包括未来的 KL 惩罚）向回传导
- Clipping 机制的表现不同
- PPO 的 Surrogate Loss 中包含
clip操作，防止策略更新步子太大 - KL in Reward 时，KL 作为标量值被算进了优势中
- 当计算 Policy Loss 时，如果当前策略相比旧策略变化太大触发了 Clip，那么包含 KL 信号在内的整个梯度都会被截断（停止更新） ，这是一种非常温和、受控的更新
- KL in Loss 时，KL 作为独立的正则项加在 Loss 后面
- 不受 PPO Clip 机制的管辖
- 无论 Policy 怎么 Clip，KL 梯度始终存在，且始终在死死地把模型往参考模型方向拉
- 这有时会导致在当前策略偏离旧策略很多的 轨迹/Token 上正则化过强，把模型参数拉偏
- PPO 的 Surrogate Loss 中包含
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] $$
- 在 GRPO 的论文中，其目标函数直接包含了 KL 散度：
- 原因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 的极大方差会掩盖原始的正确性（奖励）信号
- 如果把 KL 惩罚加到 \(r_i\) 里（即 \(r_i’ = r_i - \beta \text{KL}\)），然后再去算 mean 和 std，会产生严重的问题：
- 原因2： 无 Critic 模型时的直接正则化
- 因为 GRPO 没有 Critic 模型，它不需要像 PPO 那样去拟合包含 KL 的期望回报
- 既然不需要拟合 Value，最直接、数学上最清晰的做法就是将 KL 散度作为策略更新时的正则化项（Regularization Term）直接加在 Loss 上
- 这在优化时等价于：“在最大化任务优势的同时，拉近当前策略和参考策略的分布”
- 原因3：Token 级别的精确 KL 约束
- 在 GRPO 中，优势 \(A_i\) 通常是 Sequence 级别的（一个回答每个 Token 的 \(A_i\) 想通）
- 如果使用 kl in reward：
- 只能把 Token 级别的 KL 累加成 Sequence 级别的标量，这会丢失 Token 级别的细粒度约束
- 可能会导致模型为了降低 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 而去选择错误的答案
- 假设一个奖励 A 是正确回答，但偏离原始策略过多，那么：
- 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，会导致极端样本的梯度权重变小）
- 若按照 Group 归一化，此时得到的 Advantage 约为：
- 比如当一个 Group 的原始 Reward 为 1 个 1 和 7 个 0 时
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] $$
- 要求轨迹 \(y\) 是由 Teacher 采样的（即 Off-policy，类似传统的 SFT 或标准 KD）
- 严格的序列级 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] $$
- 要求轨迹 \(y\) 是由 Student 采样的（即 On-policy，例如 MiniLLM）
- 混合做法（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 “如何纠正或继续”
- 传统的 Forward KL（Teacher 采样）中，Student 永远只看到正确的、高质量的前缀
- 2） 包含性（Inclusive）与模式覆盖 ：
- Token 级别的 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）会非常大
/Algorithm1.png)
/Figure2.png)
/Figure3.png)
/Figure4.png)
/Figure6.png)
/Figure7.png)
/Figure8.png)
/Figure9.png)
/Figure10.png)
/Figure11.png)
/Figure12.png)
/Figure13.png)
/Figure14.png)
/Figure15.png)
/Figure16.png)
/Figure17.png)
/Figure18.png)
/Figure19.png)
/Table4.png)
* 核心，MLA 将 Q 和 K 拆开成 引入 RoPE 和 不引入 RoPE（NoPE）两部分，两者的 q 和 k 分别做 concat，本质是 qk 相乘以后做加法
