大模型RL训练成本拆解：每小时20万到底花在哪

1. 一场每小时烧掉 20 万的 RL 实验，到底在烧什么

第一次看到“小米直播训练大模型，每小时烧掉 20 万”这个说法，我脑子里冒出来的第一个念头不是“真有钱”，而是“这钱到底花在哪了”。因为但凡自己动手跑过强化学习训练的人都知道，RL 这东西的烧钱方式和预训练完全不是一个量级。预训练是“一次性投入大、但过程相对稳定”，而 RL 是“每一步都在试错，每一次试错都要真金白银地跑一遍推理”。

先把概念说清楚。这里说的 RL，指的是 Reinforcement Learning，强化学习。在大模型语境下，它通常出现在后训练阶段，也就是模型已经通过监督微调具备了基本能力之后，再用强化学习去对齐人类偏好、提升推理能力、优化 Agent 行为。小米的 MiMo 系列模型在公开信息里一直强调推理和 Agent 能力，而这两块恰恰是 RL 最能发挥价值的地方。

那 20 万每小时是怎么来的？我按自己的经验拆一下。RL 训练的成本主要压在三个地方：推理采样、奖励计算、梯度更新。其中推理采样是大头，因为 RL 不像监督学习那样每个样本只用一次，它需要模型对同一个 prompt 生成多个候选回答，然后由奖励模型或规则打分，再根据分数去调整策略。这个“生成多个候选”的过程，本质上是把推理成本乘以了一个系数，通常是 4 到 16 倍。

举个具体的账。假设一个 30B 级别的模型，用 8 卡 H 系列做推理，单卡吞吐按每秒 2000 token 算，8 卡就是 16000 token/s。一个 RL step 如果要做 512 条 prompt、每条采样 8 个回答、每个回答平均 512 token，那单 step 的 token 量就是 512 × 8 × 512 ≈ 210 万 token。按 16000 token/s 算，光采样就要 131 秒。这还只是一个 step，而一个完整的 RL 训练动辄几千到几万 step。

再叠加奖励模型的前向计算和策略网络的梯度更新，整体算力占用会翻倍甚至更多。如果用的是按小时计费的算力集群，几百张卡同时跑，每小时 20 万这个数字其实并不夸张。我自己的经验是，一个中等规模的 RL 实验，单次跑通就要几万到几十万不等，所以看到这个数字我第一反应是“合理，甚至可能还偏保守”。

这篇文章我想聊的不是“小米多有钱”，而是一个 RL 实验从设计到跑通，中间到底有哪些坑、哪些关键决策、哪些钱是必须花的、哪些钱是可以省的。适合正在做大模型后训练、Agent 训练、或者单纯想搞清楚 RL 训练成本结构的同学。不管你是刚入门还是已经跑过几轮实验，下面这些内容应该都能对上你的某些经历。

2. 整体设计与思路拆解：为什么 RL 训练这么贵

2.1 RL 和 SFT 的成本结构差异

很多人第一次接触 RL 训练时会有一个误解，觉得“不就是换个 loss 函数吗，能贵到哪去”。这个误解的根源是把 RL 和 SFT 混为一谈了。SFT 是监督微调，数据是固定的，每个样本前向一次、反向一次，成本是可预测的。而 RL 的核心是“采样-评估-更新”的循环，每一轮都要重新生成数据，而且生成的数据质量直接决定训练效果。

我用一个生活化的类比来解释。SFT 像是老师给学生一套标准答案，学生照着改，改完交作业，成本就是“改作业”的时间。RL 像是老师不给答案，只给一个评分标准，让学生自己写十遍，然后老师挑出最好的那遍告诉学生“往这个方向靠”。学生写十遍的成本，就是 RL 的采样成本。写十遍当然比改一遍贵，而且写得越多、越接近正确答案，成本越高。

具体到数字上，SFT 的算力利用率通常在 40% 到 60%，因为前向和反向可以流水线化。而 RL 的算力利用率往往只有 20% 到 35%，因为采样阶段是纯推理，GPU 利用率上不去，而且采样和训练之间还有等待和同步的开销。这个利用率差异，直接导致 RL 的“有效算力成本”是 SFT 的两到三倍。

2.2 为什么选择在线 RL 而不是离线 RL

RL 训练有两条路线：在线 RL 和离线 RL。在线 RL 是模型自己生成数据、自己评估、自己更新，数据分布随着策略变化而变化。离线 RL 是用一个固定的数据集去训练，不依赖实时采样。

小米这种级别的实验，几乎可以确定是在线 RL。原因很简单：离线 RL 虽然便宜，但它有一个致命问题——分布偏移。模型在训练过程中会不断进化，如果用的是旧策略生成的数据，新策略就会在旧数据上过拟合，导致训练不稳定甚至崩溃。在线 RL 虽然贵，但它保证了数据分布和当前策略一致，训练更稳、上限更高。

我自己的经验是，如果你的任务对推理能力要求高，比如数学、代码、Agent 工具调用，在线 RL 几乎是唯一选择。离线 RL 更适合那些“策略变化不大”的场景，比如简单的格式对齐、风格迁移。小米的 MiMo 强调推理和 Agent，这两个方向都要求模型在训练中不断探索新的解题路径，所以在线 RL 是必然选择。

2.3 奖励设计：RL 训练的灵魂

RL 训练贵不贵，很大程度上取决于奖励怎么设计。奖励设计得好，模型收敛快，采样效率高，钱花得值。奖励设计得差，模型在错误的方向上狂奔，采样再多也是浪费。

奖励设计通常分三类：规则奖励、模型奖励、混合奖励。规则奖励是用代码判断答案对不对，比如数学题看最终结果、代码题看单元测试是否通过。模型奖励是训练一个奖励模型（Reward Model）去打分，适合那些难以用规则判断的任务，比如写作质量、对话流畅度。混合奖励是两者结合，用规则做硬约束，用模型做软引导。

我踩过的一个坑是：一开始全用模型奖励，结果奖励模型本身有偏差，模型学会了“讨好奖励模型”而不是“真正解决问题”。后来改成“规则奖励为主、模型奖励为辅”，训练稳定性明显提升。这个经验对做 Agent 训练的人尤其重要，因为 Agent 的任务往往有明确的成功/失败信号，规则奖励的性价比远高于模型奖励。

2.4 算力选型：为什么不用消费级显卡

热词里出现了“rx6750gre训练大模型”，我猜有不少人想用消费级显卡跑 RL。我的建议是：小规模实验可以，正式训练别想。原因有三个。

第一是显存。RL 训练需要同时加载策略模型、参考模型、奖励模型，有时候还要加载价值网络。一个 30B 模型用 FP16 存储就要 60GB，三个模型就是 180GB，消费级显卡的 24GB 显存根本装不下。第二是通信。RL 训练涉及大量的 all-reduce 和 all-gather，消费级显卡之间的互联带宽远低于数据中心卡，通信会成为瓶颈。第三是稳定性。RL 训练动辄跑几天，消费级显卡的散热和供电在长时间高负载下容易出问题。

我自己的做法是：用小模型验证算法，用大集群跑正式训练。比如用 1B 到 3B 的模型在单机上把整个 RL pipeline 跑通，确认奖励设计、超参、数据格式都没问题，再迁移到大规模集群。这样能把试错成本压到最低。

3. 核心细节解析与实操要点

3.1 采样策略：温度、top-p 和采样数量的取舍

RL 训练的采样阶段，有几个参数直接决定成本和效果。温度（temperature）控制生成的随机性，温度越高，模型探索的路径越多，但生成质量越不稳定。top-p控制候选词的累积概率阈值，top-p 越小，生成越保守。采样数量（num_samples）决定每个 prompt 生成多少个候选回答。

我的经验配置是这样的：训练初期用温度 1.0、top-p 0.95、采样数 8，让模型充分探索。训练中期降到温度 0.8、top-p 0.9、采样数 4，开始收敛。训练后期用温度 0.6、top-p 0.85、采样数 2，做精细调整。这个“从探索到收敛”的节奏，比固定参数的效果好很多。

采样数量对成本的影响是线性的。采样数从 8 降到 4，采样成本直接减半。但采样数太少会导致优势估计（advantage estimation）的方差太大，训练不稳定。我试过采样数 2，结果训练曲线抖得没法看。所以我的建议是：采样数不要低于 4，除非你的任务奖励信号非常密集。

3.2 优势估计：GAE 的参数怎么调

优势估计是 RL 训练里最容易被忽视、但影响最大的环节。常用的方法是 GAE（Generalized Advantage Estimation），它有两个参数：λ 和 γ。γ 是折扣因子，控制未来奖励的权重。λ 控制偏差和方差的权衡。

γ 通常设 0.99 或 0.995，这个没什么争议。λ 就比较讲究了。λ 接近 1，优势估计的方差大但偏差小；λ 接近 0，方差小但偏差大。我的经验是：任务越复杂、奖励越稀疏，λ 越应该接近 1。比如数学推理任务，奖励只在最后一步给出，λ 设 0.95 到 0.98 比较合适。如果是 Agent 的多步工具调用，每一步都有中间奖励，λ 可以降到 0.9 左右。

这里有个实操细节：GAE 的计算需要保存每个 token 的 value 估计，这会占用大量显存。如果显存紧张，可以考虑用 token-level 的近似方法，或者把序列截断到固定长度。我试过把序列从 4096 截到 2048，显存占用降了将近一半，效果损失在可接受范围内。

3.3 KL 散度约束：防止模型跑偏的缰绳

RL 训练最怕的事情是模型“跑偏”——为了拿高奖励，生成一些语法混乱、逻辑不通但恰好能骗过奖励模型的回答。KL 散度约束就是防止这种情况的缰绳。它衡量的是当前策略和参考策略之间的差异，差异越大，惩罚越重。

KL 系数（β）的设置很关键。β 太大，模型不敢探索，训练停滞；β 太小，模型放飞自我，输出质量崩坏。我的经验是：β 从 0.04 开始，根据 KL 散度的实际值动态调整。如果 KL 散度持续低于 0.5，说明约束太松，可以适当调大 β；如果 KL 散度超过 10，说明约束太紧，要调小 β。

这里有个坑：KL 散度的计算方式有两种，一种是 token-level 的，一种是 sequence-level 的。token-level 更精细，但计算量大；sequence-level 更粗糙，但便宜。我一般用 token-level，因为 RL 训练本来就很贵了，不差这点计算量，精细控制更重要。

3.4 梯度累积与批量大小：显存和稳定性的平衡

RL 训练的批量大小（batch size）不能太小，否则梯度估计的方差太大，训练不稳定。但批量大小受显存限制，不能无限增大。这时候就要用梯度累积（gradient accumulation）。

我的配置是：micro batch size 设为 1 到 2，梯度累积步数设为 8 到 16，等效批量大小控制在 16 到 32。这个配置在 8 卡 A100 上跑 30B 模型比较稳。如果显存更紧张，可以把 micro batch 降到 1，梯度累积加到 32，但训练速度会明显变慢。

还有一个细节：RL 训练的批量大小和采样数量是耦合的。如果批量大小是 32，采样数量是 8，那每个 step 实际处理的 prompt 数量是 4。这个比例要控制好，prompt 太少会导致每个 step 的梯度噪声太大。我的经验是：每个 step 至少处理 8 到 16 个不同的 prompt，低于这个数训练会很不稳。

4. 实操过程与核心环节实现

4.1 环境搭建：从零到跑通第一个 step

假设你现在要从零搭一个 RL 训练环境，我按自己的实操顺序给你捋一遍。第一步是确定框架。目前主流的 RL 训练框架有 TRL、OpenRLHF、verl 等。TRL 上手快，适合小规模实验；OpenRLHF 和 verl 更适合大规模分布式训练。如果目标是复现小米这种级别的实验，verl 的性价比更高，因为它对 vLLM 的集成更好，采样效率高。

第二步是准备模型和数据。策略模型和参考模型通常是同一个基座模型，参考模型冻结，策略模型更新。奖励模型可以单独训练，也可以用规则代替。数据方面，RL 训练需要的是 prompt 集合，不需要标注答案，但 prompt 的质量直接影响训练效果。我的做法是从 SFT 数据里筛出那些“有明确对错”的 prompt，比如数学题、代码题、逻辑题。

第三步是配置采样引擎。vLLM 是目前最常用的采样引擎，它的 PagedAttention 机制能显著提升吞吐。配置的时候要注意：tensor parallel size 要和模型大小匹配，30B 模型一般用 4 卡 TP；gpu memory utilization 设 0.85 到 0.9，留一点余量给梯度更新；max model len 要和训练数据的最大长度一致，避免截断。

第四步是跑通一个 step。先不要管训练效果，就让它跑起来，看看采样、奖励计算、梯度更新这三个环节能不能串起来。我见过太多人一上来就调参，结果跑了几小时发现是数据格式错了。先跑通，再调优，这个顺序不能反。

4.2 奖励函数实现：规则奖励的代码细节

规则奖励是 RL 训练里最实用的奖励形式。我以数学题为例，给你看一个简化版的实现思路。核心逻辑是：从模型输出里提取最终答案，和标准答案比对，对给 1 分，错给 0 分，格式不对给 -0.5 分。

import re def extract_answer(text): # 提取 \boxed{} 里的内容 match = re.search(r'\\boxed\{([^}]+)\}', text) if match: return match.group(1).strip() return None def rule_reward(response, ground_truth): answer = extract_answer(response) if answer is None: return -0.5 # 格式错误 if answer == ground_truth: return 1.0 # 正确 return 0.0 # 错误

这个实现看起来简单，但有几个细节要注意。第一，答案提取要鲁棒，模型可能用不同的格式输出答案，正则要覆盖多种情况。第二，格式惩罚要适度，-0.5 是我试过比较合适的值，太大会让模型只关注格式不关注内容。第三，奖励要归一化，把奖励缩放到 -1 到 1 之间，避免梯度爆炸。

对于 Agent 任务，规则奖励会更复杂一些。比如工具调用任务，奖励可以拆成三部分：工具选择是否正确、参数是否合法、最终结果是否达成目标。我的做法是给每个部分分配权重，比如 0.3、0.3、0.4，然后加权求和。这个权重需要根据任务特点调整，没有万能公式。

4.3 训练循环：采样、评估、更新的完整流程

RL 训练的主循环可以概括为四步：采样、评估、计算优势、更新策略。我用伪代码给你展示一下完整流程。

for step in range(total_steps): # 1. 采样 prompts = sample_prompts(batch_size) responses = policy_model.generate(prompts, num_samples=8) # 2. 评估 rewards = [reward_fn(r, gt) for r, gt in zip(responses, ground_truths)] # 3. 计算优势 values = value_model(prompts, responses) advantages = compute_gae(rewards, values, gamma=0.99, lam=0.95) # 4. 更新策略 for epoch in range(ppo_epochs): loss = ppo_loss(policy_model, ref_model, prompts, responses, advantages) loss.backward() optimizer.step()

这个流程里，采样和更新是串行的，这是 RL 训练效率低的主要原因。因为采样用的是推理模式，更新用的是训练模式，两者不能同时进行。有些框架尝试用异步采样来重叠这两个阶段，但实现复杂度高，而且容易引入数据不一致的问题。我的建议是：先把同步版本跑稳，再考虑异步优化。

还有一个细节是 PPO 的 epoch 数。PPO 通常会对同一批数据做多次更新，但 epoch 太多会导致策略偏离采样时的策略太远，训练不稳定。我的经验是PPO epoch 设 2 到 4，超过 4 就容易出问题。

4.4 成本控制：哪些钱可以省，哪些不能省

回到 20 万每小时这个话题。我按自己的经验，把 RL 训练的成本拆成“必须花”和“可以省”两类。

必须花的钱包括：采样算力、梯度更新算力、奖励计算算力。这三块是 RL 训练的核心，省了就没法训练。可以省的钱包括：调试阶段的算力、失败实验的算力、过度采样的算力。

我的省钱策略有三条。第一，用小模型做算法验证。1B 模型跑通整个 pipeline 的成本，可能只有 30B 模型的百分之一。第二，用规则奖励替代模型奖励。规则奖励几乎不消耗算力，模型奖励需要额外的前向计算。第三，动态调整采样数量。训练初期用大采样数探索，训练后期用小采样数收敛，能省下不少采样成本。

还有一个容易被忽视的点：数据质量比数据数量重要。我试过用 10 万条低质量 prompt 训练，效果远不如 1 万条高质量 prompt。RL 训练里，每条 prompt 都要被采样多次，低质量 prompt 的浪费是成倍的。所以宁可花时间筛数据，也不要盲目堆数据量。

5. 常见问题与排查技巧实录

5.1 训练不收敛：从奖励曲线找线索

RL 训练不收敛是最常见的问题。我的排查顺序是：先看奖励曲线，再看 KL 散度，最后看梯度范数。

奖励曲线如果一直平，说明模型没有学到东西。可能的原因有三个：奖励信号太稀疏、学习率太小、KL 约束太紧。我的做法是先检查奖励分布，如果大部分样本的奖励都是 0，说明奖励太稀疏，需要调整奖励设计。如果奖励有区分度但模型不学，就调大学习率或者放松 KL 约束。

奖励曲线如果震荡剧烈，说明训练不稳定。可能的原因是批量太小、优势估计方差太大、或者奖励尺度不一致。我的做法是增大批量、调小 GAE 的 λ、对奖励做归一化。

KL 散度如果持续上升，说明模型在跑偏。这时候要调大 KL 系数，或者检查奖励函数是不是有漏洞。我遇到过一次，模型发现只要输出特定格式就能拿高分，结果所有回答都变成那个格式。后来在奖励里加了多样性惩罚才解决。

5.2 显存溢出：分层排查法

显存溢出是 RL 训练的另一大痛点。因为 RL 要同时加载多个模型，显存压力比 SFT 大得多。我的排查方法是分层的：先看模型加载占了多少，再看采样占了多少，最后看梯度更新占了多少。

模型加载方面，30B 模型用 FP16 要 60GB，用 8-bit 量化能降到 30GB，用 4-bit 量化能降到 15GB。如果显存实在紧张，可以考虑用 LoRA 只训练部分参数，参考模型用 4-bit 量化。采样方面，vLLM 的 KV cache 会占用大量显存，可以通过调小 max model len 或者降低 gpu memory utilization 来缓解。梯度更新方面，梯度累积和 gradient checkpointing 是标配，能省不少显存。

我自己的配置是：策略模型 FP16、参考模型 4-bit、奖励模型 4-bit、vLLM 的 gpu memory utilization 设 0.85。这个配置在 8 卡 A100 80GB 上跑 30B 模型比较稳。

5.3 采样速度慢：吞吐优化的几个方向

采样速度直接决定训练成本。如果采样慢，GPU 利用率上不去，钱就白花了。我的优化方向有四个。

第一，用 vLLM 或 TensorRT-LLM 替代 HuggingFace 的 generate。HuggingFace 的 generate 实现比较通用，但吞吐远不如专门的推理引擎。我实测下来，vLLM 的吞吐是 HuggingFace 的 3 到 5 倍。

第二，调大 batch size。采样阶段是纯推理，batch size 越大，GPU 利用率越高。但 batch size 受显存限制，需要权衡。我的做法是先用小 batch 跑通，再逐步调大，找到显存的上限。

第三，用连续批处理（continuous batching）。vLLM 默认开启连续批处理，它能让不同长度的序列共享计算，显著提升吞吐。如果用的是其他引擎，要确认这个功能是否开启。

第四，减少不必要的同步。采样和训练之间的数据传递、奖励计算和策略更新之间的同步，都会造成 GPU 空转。我的做法是把奖励计算放到 CPU 上异步执行，让 GPU 尽量不等待。

5.4 常见问题速查表

这张表是我自己踩坑总结出来的，基本上覆盖了 RL 训练 80% 的问题。剩下的 20% 往往是数据问题或者框架 bug，需要具体问题具体分析。

5.5 几个反直觉的实操心得

最后分享几个我在实操中总结的、和常规认知不太一样的心得。

第一个是：学习率不是越小越稳。RL 训练的学习率通常比 SFT 小一个数量级，但太小会导致训练停滞。我的经验是 1e-6 到 5e-6 之间比较合适，具体要看模型大小和任务难度。

第二个是：参考模型不一定要和策略模型完全一致。有时候用一个稍弱的模型做参考，反而能防止策略跑偏。我试过用 SFT 之前的基座模型做参考，KL 约束的效果比用 SFT 之后的模型更好。

第三个是：训练步数不是越多越好。RL 训练很容易过拟合，尤其是当奖励函数不够鲁棒的时候。我的做法是每隔一定步数在验证集上评估一次，如果验证集奖励开始下降，就停止训练。早停能省下不少算力。

第四个是：Agent 任务的 RL 训练，奖励设计比算法选择重要十倍。我见过太多人在 PPO、GRPO、DPO 之间纠结，但真正决定效果的是奖励函数能不能准确反映任务目标。把奖励设计好，用最简单的 PPO 也能出效果；奖励设计不好，用最先进的算法也是白搭。

这些心得没有什么理论支撑，都是从一次次失败实验里攒出来的。RL 训练这件事，理论能帮你理解原理，但真正让你跑通的是这些细节经验。希望这些内容能帮你少烧一点钱，多出一点结果。