INCOMING TRANSMISSION

💡 GRPO相比PPO主要优势： 1. 训练更稳定 引入 KL 散度惩罚项，有效控制策略更新的幅度，避免策略崩溃，提高训练的稳定性 GRPO用组内相对优势替代value model，消除了value估计误差 通过组内归一化，自动消除reward scale和bias的影响 实验中发现GRPO的advantage方差比PPO小30%左右，训练崩溃率更低 2. 工程更简单 只需要1-2个模型（policy + reference），而PPO需要4个 显存占用减少50%以上，训练速度提升2-3倍 超参数更少，更容易调优 3. 相对奖励机制 通过对同一输入生成的多个输出进行比较，GRPO 能够更稳定地估计优势函数，减少了训练过程中的方差 背景 GRPO是 DeepSeek-Math model中提出的对PPO方法的改进策略： 强化学习(RL)在提升模型数学推理能力方面被证明是有效的 传统PPO算法需要较大训练资源 GRPO作为PPO的变体被提出,可以更高效地优化模型 PPO Vs GRPO PPO回顾 PPO的目标函数为: \[\begin{aligned}J_{PPO}(\theta) =...

概述 投机解码（Speculative Decoding）也叫预测解码/投机采样，它会利用小模型来预测大型模型的行为，从而提升模型在解码（decoding）阶段的解码效率问题，加速大型模型的执行。其核心思路如下图所示，首先以低成本的方式（以小模型为主，也有多头，检索，Early Exit 等方式）快速生成多个候选 Token（串行序列、树、多头树等），然后通过一次并行验证阶段快速验证多个 Token的正确性，只要平均每个 Step 验证的 Token 数 > 1，就可以一次性生成多个token，进而减少总的 Decoding 步数，实现加速的目的。 下图左侧是自回归解码模型，右侧是投机解码机制。 从本质上来说，投机解码希望在推理阶段在不大幅度改变模型的情况下，通过更好利用冗余算力来并行"投机"地猜测出模型接下来要输出的token。作为对比，也有一种方案是通过路由的方式组合多个不同规模和性能的模型。路由方式在调用之前已经确定好需要调用哪个模型，直到调用结束。而投机解码在一个 Query 内会反复调用大小模型。 背景 我们都知道，生成式 LLM 大部分是 Decoder-only...

比起两年前，NLG任务已经得到了非常有效的发展，transformers模块的使用广泛程度也达到前所未有的程度。在模型推理预测时，一个核心的语句就是 model.generate() ，本文就来详细介绍一下generate方法是如何运作的。在生成的过程中，包含了诸多生成策略，本文将以最常用的beam search为例，尽可能详细地展开介绍。 随着各种LLM的出现，transformers中与generate相关的代码发生了一些变化，主要区别在于： generate的源码位置发生了改变； generate方法中，采用一个 generation_config 参数来管理生成相关的各种配置，并优化了逻辑，使得逻辑更加清晰。 generate的代码位置 在之前版本的transformers中（transformers~=4.9），generate方法位于 transformers.generation_utils.py ，这个方法是 GenerationMixin 类的一个方法。 而在新版本的transformers中（transformers~=4.42），generate方法被转移到了...

概述 https://github.com/FasterDecoding/Medusa Medusa 是自投机领域较早的一篇工作，对后续工作启发很大，其主要思想是 multi-decoding head + tree attention + typical acceptance(threshold)。Medusa 没有使用独立的草稿模型，而是在原始模型的基础上增加多个解码头（MEDUSA heads），并行预测多个后续 token。 正常的LLM只有一个用于预测 \(t\) 时刻token的head。Medusa 在 LLM 的最后一个 Transformer层之后保留原始的 LM Head，然后额外增加多个（假设是 \(k\) 个） 可训练的Medusa Head（解码头），分别负责预测 \(t+1,t+2,...,\) 和 \(t+k\) 时刻的不同位置的多个 Token。 Medusa 让每个头生成多个候选 token，而非像投机解码那样只生成一个候选。然后将所有的候选结果组装成多个候选序列，多个候选序列又构成一棵树。再通过树注意力机制并行验证这些候选序列 。 原理...

分布式深度学习里的通信严重依赖于规则的集群通信，诸如 all-reduce, reduce-scatter, all-gather 等，因此，实现高度优化的集群通信，以及根据任务特点和通信拓扑选择合适的集群通信算法至关重要。 本文以数据并行经常使用的 all-reduce 为例来展示集群通信操作的数学性质。 All-reduce 在干什么？ 图 1：all-reduce 如图 1 所示，一共 4个设备，每个设备上有一个矩阵（为简单起见，我们特意让每一行就一个元素）， all-reduce 操作的目的是，让每个设备上的矩阵里的每一个位置的数值都是所有设备上对应位置的数值之和。 图2 如图 2 所示， all-reduce 可以通过 reduce-scatter 和 all-gather 这两个更基本的集群通信操作来实现。基于 ring 状通信可以高效的实现 reduce-scatter 和 all-gather，下面我们分别用示意图展示其过程。 reduce-scatter 的实现和性质 图 3：通过环状通信实现 reduce-scatter 从图 2...

一个在内存中运行的应用程序。每个进程都有自己独立的一块内存空间，一个进程可以有多个线程，比如在Windows系统中，一个运行的xx.exe就是一个进程。 线程 进程中的一个执行任务（控制单元），负责当前进程中程序的执行。一个进程至少有一个线程，一个进程可以运行多个线程，多个线程可共享数据。 与进程不同的是同类的多个线程共享进程的堆和方法区资源，但每个线程有自己的程序计数器、虚拟机栈和本地方法栈，所以系统在产生一个线程，或是在各个线程之间作切换工作时，负担要比进程小得多，也正因为如此，线程也被称为轻量级进程。 Java 程序天生就是多线程程序，我们可以通过 JMX 来看一下一个普通的 Java 程序有哪些线程，代码如下。 public class MultiThread { public static void main(String[] args) { // 获取 Java 线程管理 MXBean ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean(); // 不需要获取同步的 monitor 和...