1. 为什么“万亿参数 强化学习”是后训练里最昂贵的组合先把结论放这儿万亿参数模型做强化学习后训练如果按传统全参数方案硬推卡数需求不是“多一点”而是直接翻一个数量级。我见过不少团队在预训练阶段省吃俭用结果到了 RL 阶段一下把家底全填进去。原因不是 RL 本身有多玄而是它的资源消耗模型和预训练完全不一样。先说强化学习后训练到底在做什么。简单讲它是在一个已经学会“预测下一个词”的模型基础上通过奖励信号的引导让模型学会“在特定任务上产出更好的结果”。比如代码题要能通过测试用例数学题要答案和推理路径都对对话场景要更符合人类偏好。这个阶段数据量不大但计算开销却非常夸张因为每一轮策略更新都要先让模型自己去生成一堆候选答案再根据奖励反馈去调整权重。这里有一个核心差异预训练是“读文档”RL 是“做题加批改”。建模要生成大量文本而且这些生成结果的好坏直接影响训练信号。一个万亿参数模型即使只生成几百条样本每条几百 token算上 beam search 或多次采样前向计算量就会把整卡集群拖住。更麻烦的是生成结束之后还要做策略更新这意味着模型参数要来回搬动显存和带宽同时告急。我们拿显存算一笔账就清楚了。假设模型总参数 1 万亿BF16 权重也要 2TB 起步。全参数训练时除了权重本身还要有 FP32 主权重4TB、Adam 的两个动量项各 4TB、梯度2TB加一起接近 16TB 的额外状态。注意这 16TB 还不算任何激活值、KV cache 和临时缓冲。也就是说全参数训练一个万亿模型光优化器状态就要 200 张 80GB 的卡才勉强装得下紧接着前向反向的通信开销又会把可用带宽吃光实际集群规模远不止这个数。而强化学习还有一个额外的讨厌之处需要同时维护策略模型和参考模型。参考模型用于计算 KL 散度防止策略在优化奖励时彻底漂移。参考模型不训练但推理要跑所以权重要常驻显存。如果策略和参考模型都按全参维护显存直接翻倍。一个 1 万亿参数的全参 RL 工程现实里至少要四五十台以上 8 卡机器才能转起来而且转起来之后吞吐率还不一定好看。这种模式基本是资源自杀式玩法。所以我看到“用 10% GPU 跑通万亿参数 RL”这种方案时第一反应不是质疑而是想拆开看它到底省在哪。事实证明它并不是什么魔法而是把 RL 的各个环节重新拆解了一遍把“哪些参数必须更新”“哪些计算必须同步”“哪些显存可以省掉”这三个问题想透了。后面几节我就按这个思路展开。2. 核心思路把“全参数 RL”拆成并行流水线的三刀2.1 第一刀冻结主干只训练 LoRA 增量第一个决策也是整个方案的基石策略模型主干全部冻结只训练 LoRA 低秩适配器。LoRA 的数学形式不复杂——对权重矩阵 W 附加一个低秩分解 BA前向变成 Wx BAx训练时只更新 B 和 A 这两个小矩阵。它的可训练参数量通常只有主干的 0.1% 到 1%也就是万亿模型只更新大约十亿到百亿级别的参数。这一刀下去优化器状态直接从 16TB 缩到几十 GB。哪怕 LoRA 参数有 20 亿优化器状态也就 32GB 左右一张卡就能放下。训练侧的显存压力瞬间消失反向传播只需要把梯度传到 LoRA 矩阵就停下冻结部分根本不用保存梯度。这对显存是降维打击。有人担心 LoRA 会不会影响效果。我直接说在后训练阶段基座模型已经具备很强的语言能力和知识储备RL 要改变的是输出策略是“如何组织答案、往哪个方向搜索推理路径”这种变化是模块化的低秩适配完全够用。数学推理、代码生成、指令遵循类任务LoRA 微调的表现已经被大量验证过。当然如果任务是让模型大规模吸收新知识或改变事实性记忆那 LoRA 可能不够但那是预训练或持续预训练的事不属于 RL 后训练的典型场景。2.2 第二刀把 rollout 生成和策略更新拆成异步流水线全参数 RL 最常见的浪费点在于同步等待。传统 PPO 流程里模型先生成一批样本然后立即用这批样本计算 loss更新一次策略再等策略更新完继续采样。每一步都被最慢的环节卡住。在万亿参数规模下生成一段长文本可能要几秒到几十秒而训练一步可能只需要几百毫秒两边速度完全不匹配。如果强制同步GPU 大部分时间都在空转。方案的做法是把 rollout 生成和策略更新拆成两条独立流水线中间用一个经验池缓冲。推理侧常驻策略模型的当前权重持续从任务池里取 prompt批量生成样本写入经验池。训练侧从经验池里取最新样本做策略更新更新完把最新的 LoRA 权重同步给推理侧。两边各跑各的谁也不用等谁。这个设计的关键在于“延迟更新”的容错。推理侧拿到的策略版本永远比训练侧落后几步这样会产生一些 off-policy 偏差。但 RL 本身就有一定的 off-policy 容忍度而且我们在后面的 KL 修正里会补这部分偏差。实测下来只要把滞后步数控制在合理范围内效果反而更稳因为生成样本的多样性更好了不会因为策略在某一小步里过拟合而突然产出同质化内容。2.3 第三刀激活重计算加优化器状态 offload再抠一块显存冻结主干之后训练侧仍然要跑完整的前向反向激活值依然会占不少显存。万亿模型的 hidden state 哪怕只有几万维在长序列、大 batch 下也可能把显存重新顶爆。解决方案是开启激活重计算也就是前向时只存必要中间量反向时再重新计算一遍。这是典型的“用计算换显存”在冻结主干场景下非常划算因为反向后不需要更新主干权重重计算出来的梯度只用喂给 LoRA 部分。优化器状态 offload 是再进一步把 LoRA 的优化器状态放到 CPU 内存或者 NVMe 缓存里每步只拷贝需要的部分到 GPU 更新。LoRA 参数本来就小这个开销很低。不过我们实际跑下来发现当 LoRA 参数量在 5 亿以下时offload 收益不明显直接放显存更省事。只有当 LoRA 做到二三十亿参数时offload 才值得开。2.4 一张表看配额10% 的 GPU 到底省在哪经常有人问“10% 是卡数少 90% 还是显存少 90%”。我们按卡数算。对比同一个万亿参数基座模型做数学推理 RL全参数方案和 LoRA 方案的资源大致如下资源项全参数方案LoRA 方案说明训练侧优化器状态约 16TB约 50GB这是最大的差距训练侧梯度约 2TB忽略不计冻结部分不回传梯度参考模型需要另存一份完整权重与主干共用只加一层命中统计省掉一整份权重rollout 阶段与训练共用同一批卡互相等待独立推理池持续产出空闲时间被填满预计卡数40 台 8 卡起步4 台 8 卡可以跑通这就是 10% 的来源这张表我想强调最后一行。不是说 LoRA 方案只需要 10% 的算力而是它把资源需求里最不合理的部分——全参优化器状态和同步等待——去掉了。剩余的开销主要是骨干网络的前向计算和 KV cache 存储这些在推理阶段本来就要花RL 只是把它复用了一遍。所以“10% GPU”不是压缩出来的是精算出来的。3. 10% GPU 资源的真实跑法与关键配置3.1 资源清单与实际规模方案复现时我们用的配置大概是一个总参数 1.2T 的 MoE 基座模型激活参数约 300B单卡 80GB8 卡一台机器。训练侧用 3 台机器推理侧用 1 台机器合计 4 台 32 张卡。作为对比之前同项目做全参数 PPO 预演时方案规划是 32 台起的实际因为集群限制根本没跑起来。这个差距就是“10%”的现实写照。MoE 结构帮了不少忙。万亿参数听起来吓人但每次生成 token 只激活一部分专家实际参与计算的参数远小于总量。混合多头注意力和路由部分仍然要全部加载但计算压力至少缓解了一半。如果改成稠密 1 万亿模型4 台机器是跑不动的至少得把训练侧加到 8 台再靠 4bit 量化主干才能勉强塞下。所以这套方案对 MoE 特别友好标题里说的“万亿参数”基本默认是 MoE。3.2 核心配置示例训练侧的 LoRA 配置和 RL 超参大概长这样。这个配置是我们反复试出来的基线不同任务可以在此基础上微调model: base_dtype: bf16 activation_checkpointing: true load_in_8bit: false lora: r: 32 alpha: 64 dropout: 0.1 target_modules: [q_proj, v_proj, o_proj, gate_proj] optimizer: lr: 2e-5 weight_decay: 0.01 lr_scheduler: cosine warmup_steps: 50 rl: kl_coef: 0.01 clip_range: 0.2 batch_size_per_update: 256 rollout_buffer_size: 4096 max_policy_update_lag: 32 reward_shaping: function_validation几个参数我想特别解释一下max_policy_update_lag: 32是异步流水线的安全阀。它表示训练侧最多可以比推理侧领先 32 个优化步超过这个数就暂停训练等推理侧把新策略权重同步过去。这个值设太小流水线就卡成同步了设太大off-policy 偏差会失控。32 是我们这个吞吐量下的甜点位。kl_coef: 0.01看起来不小但对于有明确验证器的任务很合适。奖励信号是稀疏但准确的KL 系数大一点可以有效防止策略跑到奖励函数的盲区里去“钻空子”。如果任务的奖励是学习出来的 RM那这个系数可能要降到 0.001 甚至更低否则策略会变得特别保守什么都不敢生成。alpha: 64是 LoRA 的缩放系数。我们试过 alpha 等于 r也试过两倍 r。alpha 太小适配器更新幅度不够RL 信号推不动策略alpha 太大几十步之后 KL 就开始飙升。alpha 设为 r 的两倍是我们实测中平衡点最好的选择。3.3 推理侧怎么同时 serve LoRA 权重推理侧不能简单拿原始主干权重去生成必须把最新的 LoRA 适配器合并进去。这里有一个容易被忽略的工程点如果推理引擎支持动态加载 LoRA确实方便但频繁更新适配器会有额外开销。我们实际做法是让推理侧定期拉取训练侧产出的 LoRA checkpoint先把权重合并进主干副本再刷新推理引擎。合并一次权重在单机上只需要十几秒但能保证生成吞吐始终最高。奖励计算也单独做了优化。数学和代码类任务可以用函数验证器也就是让模型生成代码或公式直接用测试用例跑结果成本几乎为零。只有涉及开放式写作或对话偏好的任务才需要加载一个单独的奖励模型。奖励模型也绝不能用和策略同规模的模型我们用的是一类相对小的二分类头部只在最后一层输出分数单卡显存占用不到 20GB。4. 实测中的三个翻车现场与对应修复这套方案听着清爽实际跑起来还是踩了不少坑。挑三个最典型的翻车现场说每个都对应一类容易被忽略的问题。4.1 翻车一rollout 吞吐突然崩掉卡在采样端而非训练端第一次联调时预期推理侧每秒生成的 token 数量应该能支撑训练侧持续消费结果一启动就发现训练侧经常在等数据。查了半天问题不在显存也不是网络而是我们把 LoRA 权重以“动态插拔”的方式挂在了推理引擎里。推理引擎每次生成都会动态计算 LoRA 增量这个操作在引擎内部没有真正优化导致前向时间比合并权重后慢了将近三倍。修复很简单把 LoRA 合并进主干权重再加载。这个动作如果手工做每步都要重启推理引擎但实际训练时我们不是每步都刷新推理侧而是每积累二十到三十个优化步才同步一次权重。这样一次合并的开销会被大量生成任务摊平吞吐自然就回满了。做这套方案之前最好先确认一下目标推理引擎对权重更新的支持方式不要想当然地认为热插拔适配器一定更快。4.2 翻车二KL 直接崩了策略输出比起始模型偏到没法看中间有一轮实验我们把 LoRA 学习率调到了 1e-4KL 系数还维持之前的 0.001。结果跑了不到两百步模型输出的平均长度明显变短答案风格也变得极其单一一看 KL 曲线已经飙到初始值的十倍以上。问题本质是LoRA 虽然参数量小但因为只更新一小部分权重同等学习率下对输出的影响反而会被放大再加上低秩结构会让某些方向更新特别激进KL 一失守策略就开始坍缩。修复动作有两个。第一把学习率降到 2e-5和主干预训练阶段的微调学习率保持一个量级甚至更低第二把 KL 系数从 0.001 提回 0.01并且开启 KL 的实时监控超过阈值自动报警。这一步的经验是LoRA RL 场景学习率比 KL 系数更敏感宁可学习率小一点、多跑几步也别让它推猛了再往回拉。4.3 翻车三延迟策略反而救了训练稳定性但滞后太大也会震荡异步流水线跑起来之后我们注意到一个小规律当训练侧滞后推理侧大约二十步时训练 loss 曲线很平稳但当某一轮 rollout 特别长、滞后超过五十步后指标反而开始振荡。细想其实就是 off-policy 偏差的双向作用。适度滞后时旧策略生成的样本相当于天然的探索噪声能帮训练跳出局部震荡滞后太多时样本分布和当前策略差异过大KL 修正已经补不齐了损失函数就跟着乱跳。这个坑没有一次性修复方案只有运行时观察和调参。我们在配置里加上了max_policy_update_lag并且让推理侧把每个批次生成时的策略版本号也写进经验池训练侧按版本号过滤样本超过阈值的直接丢弃。这样即使推理侧偶尔卡顿训练侧也不会消费过期太久的样本。实测之后loss 和奖励曲线的稳定性都明显改善。这三个翻车有一个共同点都不是模型结构的问题而是异步训练系统中“状态同步”的问题。跑这套方案时建议多留几个监控指标尤其是 rollout 吞吐、策略版本号差距、平均 KL 这三个它们比 loss 值更能说明系统是否健康。5. 这套方案能抄到哪里哪些场景别硬搬5.1 适合直接复用的条件先总结适合这套方案的场景特征。第一基座模型已经足够稳定语言能力和基础知识都过关RL 只是定向提升某个能力第二奖励信号可以自动化验证器、测试用例、格式规则都算不需要大规模人工标注第三输出文本长度中等不至于每轮生成几万 token 把 KV cache 直接打爆第四任务目标是能力增强型比如数学、代码、逻辑推理而不是价值观对齐或风格大改。我们的实践里最顺的是代码生成任务。模型输出一段代码直接用一组单元测试判断正确率奖励信号又稀疏又硬LoRA 更新起来方向感非常强。数学题类似只要验证器写得好整个 RL 流程几乎不需要人工介入。这类项目完全可以按刚才的配置抄作业。5.2 别硬搬的场合需要明确的是这套方案不是万能钥匙。如果任务是做安全对齐比如让模型学会拒绝某些请求这往往需要让模型整体行为发生改变低秩适配可能只改动了表面风格深层价值观并没有真正调整。全参数训练在这种场景下仍然无法替代哪怕它贵。如果模型还需要大规模注入新知识比如某个垂直行业的数据要持续学习这也别用 RL 加 LoRA。知识性修改适合持续预训练或 SFT 阶段做硬塞进 RL 流程只会又贵又低效。再一个是超长上下文任务比如让模型基于几十万字文档做分析每轮的 KV cache 就可能超过百 GB推理侧哪怕只有一小撮卡也扛不住这种情况下与其上异步流水线不如先把序列长度和生成长度砍下来。5.3 下一步可以怎么扩展这套方案的扩展方向其实很明确。一个方向是压缩推理侧资源把主干权重量化到 8bit 甚至 4bit 再合并 LoRA前提是接受一点训练稳定性损失另一个方向是把推理侧做成多机池用更多小机器扛更长上下文的 rollout还有一个方向是训练侧多任务并行同一个推理池同时服务多个 LoRA 任务的样本生成进一步提升 GPU 利用率。后两个我都在陆续试后面有结论再拿出来聊。说到底用 10% GPU 跑通万亿参数 RL靠的是把“训练思维”转成“流水线思维”。全参数训练时我们盯着梯度、优化器、并行策略但 RL 后训练真正烧钱的地方是重复生成和等待而不是参数的微调。想省资源先想清楚哪部分参数真正需要更新再把生成与训练之间的时间差利用起来。这个思路本身比任何具体配置都值钱。