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 散度最小的解决方案

为什么蒸馏 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）：即学习新任务通常会导致旧任务的性能急剧下降
  • 特点：常在顺序学习任务中出现；在跨不同数据集或任务训练的模型中尤其常出现
  • 解法：通过在包含新旧信息的组合数据集上重新训练模型，模型可以在适应新数据的同时保持其在先前学习的任务上的性能