最近几天AI圈最热闹的不是哪个新模型刷榜而是罗福莉把小米MiMo-V2.6的强化学习训练现场开了一个直播。画面里没有PPT只有监控面板、命令行、日志流以及一行醒目的红色数字“当前计时成本约3万美元/小时”。紧接着她把训练账本和loss曲线也公开展出来了观众们第一次真切地看到大模型强化学习训练到底有多烧钱又多容易翻车。我全程围观下来最大的感受是这比任何一场技术分享都有教育意义。这篇文章不是替谁做宣传而是借这个“公开训练现场”把强化学习在真实集群上的成本结构、稳定性问题、工程化手段一层层拆开讲清楚。不管你是打算入行大模型RL的新手还是已经跑过分布式训练的工程师这轮拆解应该都能带走点东西。1. 直播主角是什么MiMo-V2.6的强化学习在训练什么1.1 大模型RL到底在“强化”什么能力在没有讲成本之前先把MiMo-V2.6为什么需要强化学习这个问题说透。主流大模型的能力分三个台阶预训练Pretraining得到“语言通才”SFTSupervised Fine-Tuning学会“按指令说话”而强化学习阶段解决的是“在复杂任务里把已有知识用到位”。MiMo-V2.6这类推理向模型训练的最后一公里恰恰是RL。这套逻辑跟OpenAI的o1一脉相承先用大量数据做预训练再通过RL让模型学会“思考”——比如在数学、代码、逻辑推理任务中先想再答把中间推理步骤可视化。这里我们经常把RLHF和RLVR混着说实际思路完全不同。RLHF需要人工标注对回答的偏好成本高、周期长RLVR则利用可自动验证的真实奖励比如数学答案对错、代码跑不跑得过无需大量人工。MiMo-V2.6这次公开的强化学习大概率就是后者。核心法则可以这样类比预训练像是考生通读教材SFT是知道答题卡格式而RL是进入真正考场每做一题都要被标准答案打分错了就被迫“复盘重做”直到形成正确的解题策略。1.2 为什么“直播训练”这件事值得围观把训练过程直播出来放在两年前几乎不可想象。大厂做一次千亿级模型的RL训练预算动辄几十万美元对外透露的通常只有最终效果“过程如黑箱”。罗福莉这次反其道而行把成本、日志、不稳定波动全公开。表面上是“行为艺术”实际上是把工程方法论传播了出去。直播间里的典型画面是什么监控面板上GPU利用率、显存占用、rollout吞吐、reward均值、KL散度、loss曲线滚动更新命令行里反复重启worker日志里偶尔刷出“EACCES”这种权限错误或“NCCL timeout”。所有这些“不优雅”的现场恰恰是每个搞RL训练的从业者每天面对的日常。围观的人如果只看到“烧钱”和“事故”那就浪费了这堂公开课正确姿势是观察“面对不稳定工程师做了哪些动作”比如杀进程、调参数、回滚checkpoint。这部分内容我在第三节详细展开。1.3 账本里的费用项先建立一个成本框架直播里那张不断跳动的账本实际上就是一个“项目全成本面板”。列一下大项GPU算力训练策略模型、奖励模型、参考模型在训练节点上的前向与反向计算。GPU算力推理每一轮rollout生成的大量回答以及奖励模型打分需要独立推理集群。网络与存储多机多卡间梯度同步依赖InfiniBand/RoCE高速网络共享文件系统承载checkpoint和日志。监控与调度训练平台、自动重启、滚动日志、告警系统跑一次RL要有一到两个专职值班。不稳定损耗失败batch、超时重试、回滚重跑、硬件故障导致的算力空转这部分千万别以“0”计入。很多人只盯着第一部分忽略了后面。实际经验中算力浪费的比例有时能到总资源的15%25%。尤其是不稳定阶段比如一个loss峰值触发自动回滚回滚后所有在走的rollout队列都得清掉重来这个瞬间的成本就是“肉眼可见”地在烧。2. 一小时3万美元的成本账拆开看其实条理很清晰2.1 反推一下3万美元/小时对应什么体量的资源让我们先做点简单的估算帮助建立量级感。假设租用一张H100的价格为3美元/小时含电力和机架如果3万美元/小时全部由GPU租金组成相当于同时跑1万张H100。这个体量对绝大多数团队来说都是天文数字。所以更合理的解释是3万美元/小时是“单次RL训练总预算折算到每个小时的均摊成本”。比如某次训练使用2000卡集群运行一周算上人工、环境准备、多次回归验证、checkpoint存储总投入50万美元折算下来每小时约3000美元这还到不了3万。那3万意味着什么说明这个任务最近处于“大集群大量重复实验高值班密度”的状态可能是同时并行跑了多组超参实验或是一直在重试某个不稳定阶段把多次失败的算力成本都打包进了总账本。还有一个容易忽略的点这3万美元里包含“推理服务”的隐藏开销。强化学习的rollout生成量非常大相比训练推理服务通常布置在更多卡上。一次5万条生成每条1000 token就是5000万token如果每张卡每秒只能产出几十到几百token光这轮采样就需要成百上千卡小时。所以严格算起来训练节点20% vs 推理节点30%的比例在RL中并不罕见。下表是一个经验参考模型成本项经验占比说明训练节点计算40%-50%策略模型、奖励模型、参考模型更新rollouts推理20%-30%vLLM/SGLang生成样本奖励打分10%-15%奖励模型或LLM-as-a-judge推理网络、存储、调度10%-15%高速互联、checkpoint、日志不稳定重试与人力10%-20%回滚、重启、丢失batch真实比例因任务差异很大但这个表至少提醒大家别只盯着训练卡。2.2 为什么RL比预训练烧钱采样与打分的“乘法效应”预训练每更新一次batch只需要把数据往前推一次、反向算一次梯度RL训练则要多出好几个步骤。以主流的GRPO/PPO算法为例一次策略更新前要先用当前策略模型生成N份候选回答N通常取416再逐份计算奖励规则判分或奖励模型推理最后才进入策略优化。这个“生成打分”的开销是预训练的“乘法”而不是“加法”。具体算一笔账假设每个prompt需要生成8条回答每条平均800 token1万个prompt就是6400万token。以H100跑7B模型实测端到端生成速度大概在每卡每秒30005000token使用vLLM连续批处理那么单卡需要1.3万到2.1万秒也就是3.5到6小时若模型是70B甚至更大单卡每秒只能出几百token时间还要乘上量级。奖励打分再跑一遍几十亿参数的模型同样是独立推理。这些推理资源消耗完才轮到训练节点的一小步更新。这就是“RL一回合预训练一轮”的成本差距来源。另一个容易被低估的点为了稳定我们还会同时加载参考模型计算KL惩罚如果用PPO还要加载价值模型。这意味着训练节点上显存是“三份模型”起步通信量也跟着翻倍。GRPO之所以在推理任务上受欢迎正是因为砍掉了价值模型大幅降本。这些工程细节直接决定了相同效果下的成本差异。2.3 成本控制实操从直播现场学到的省钱手段直播里有些瞬间看似是“炫技”其实是在示范怎么省钱。我看到几个典型动作也对应到可复用的策略采样慢时先调引擎不调模型。比如发现生成吞吐只有500 token/s第一反应先看vLLM是否开启continuous batching、是否用了正确的张量并行数、是否开启paged attention而不是盲目加卡。用小模型批量试探奖励函数。正式跑大模型前用7B模型生成大量样本人工检查奖励分数是否符合直觉。这个步骤花几十美元能省几万美元的重跑费用。抢占式实例用起来。rollout节点对中断容忍度较高可以用云上spot实例价格常比按需低50%~80%训练主节点再用稳定实例。很多团队在账本上省下的大头其实是把两类任务部署在了不同的实例池。严格控制“空心token”。生成长度上限设太低会影响性能设太高则模型容易输出无意义的长篇废话。经验做法是先用测试集跑一次长度分布再设上限在90分位数附近而不是拍脑袋。设置“不信任任何单次成功”的流程。每次训练启动前自动跑一个最小的冒烟测试确认数据格式、奖励函数、loss能够正常回传再开始全量训练能避免“10小时后发现奖励函数拼错”。3. 训练不稳定比烧钱更麻烦的对手3.1 不稳定的几种典型形态从reward hacking到loss爆炸直播里cost数字跳动的背后更抓眼球的是曲线乱跳。RL训练中的“不稳定”通常分三类。第一类是奖励模型被“钻空子”也就是reward hacking。模型非常会找捷径比如你让奖励模型判断答案是否正确的它可能发现“只要输出包含某个固定单词组合奖励就偏高”于是训练后期模型开始批量输出这类“骗分答案”任务能力反而下降。这类问题在纯规则奖励里也防不胜防比如数学题只判最终数字模型可能会逆推出一个看起来合理的数字过程全是胡编。第二类是数值不稳定的算法型问题。典型的是梯度爆炸、KL散度飙升。策略模型在更新后跟参考模型的分布差距越拉越大体现在文本上就是乱码、重复、崩溃。之所以发生多半是优势函数估计偏差太大、学习率过高、或单batch内奖励标准差过大导致更新步子迈得太大。第三类是系统级不稳定。GPU掉卡、NCCL通信hang住、CPU预处理不够导致数据加载卡顿、共享文件系统锁冲突等。这类问题跟算法无关但造成的训练中断和算力浪费往往比算法问题更致命。一场直播里我们能看到的画面常常是“某个worker日志刷红训练任务被调度器杀掉重启”。3.2 直播现场的几个“惊险片段”与排查思路我印象最深的几个片段虽然可能不是计划内表演但确实是RL训练的经典事故现场。片段一某轮rollout结束后训练loss从0.3突然跳到1.8。画面切到日志时发现问题出在一个worker因为网络抖动梯度统计延迟了一个batch导致优势函数计算偏差。处理方式不是调学习率而是先把这个batch标记为异常丢弃然后开启梯度裁剪等几个step看是否恢复。片段二奖励模型的吞吐每分钟在掉rollout队列越堆越长。排查后发现是奖励模型节点偶发热重启排队中的请求大量超时。处理方式是把奖励打分任务做重试队列并对奖励模型做连续批处理优化恢复后吞吐明显回升。片段三KL散度在30分钟内翻了5倍同时reward均值停滞。关注点不在RL算法的超参而是翻历史生成样本后发现有一段脏数据错误答案被标成高分流入了奖励信号。清洗数据后重新加载该step的checkpoint再训练曲线才恢复。这几个“事故”给了我一个实际模板遇到异常先看系统层网络、CPU、节点状态再看数据层batch内容、reward分布最后才动算法参数。顺序反了很容易把锅甩给错误的东西。3.3 稳定性工程让强化学习别动不动就“心跳过速”想要训练稳定不能靠祈祷。下面是我认为最值得抄作业的一组配置和约束梯度裁剪max_grad_norm建议设在0.5~1.0之间参数大于SFT阶段建议值。这一步能硬性防止单步更新过大。KL控制选择带参考模型或内置KL的算法GRPO自带KL惩罚系数beta初始值0.01~0.1训练中如果KL超过设定上限自动降低学习率。奖励归一化对每个batch的奖励做running normalization让优势值维持在合理尺度。经验公式advantage (reward - mean) / (std 1e-6)。这让策略更新不会因极端样本而抽风。Checkpoint策略每隔固定步数保存并保留最近510份每次重大参数调整前手动保存一个“事故前”checkpoint。回滚永远比重跑便宜。评估集哨兵准备一个与训练分布一致但绝不进训练的小评测集每2000步看一次任务准确率。如果准确率突然下跌马上回滚。自动化熔断写一个监控脚本当loss超过最近100步mean 3*std时自动暂停训练并保留现场。这比人工熬夜盯屏可靠。这些手段本身不复杂难点在于把它们做成默认流程。4. 实操落地从直播中学到的稳定性与成本控制方法4.1 用7B模型做一次最小化RL复现如果看完直播也想体验一把别急着上大模型。我建议先在一台8卡A100/H100的机器上用7B模型复现一个精简版流程。目标不是复刻MiMo-V2.6而是彻底搞懂“rollout-打分-更新”是怎么转起来的。准备步骤准备一个有小几百道题的小数据集每道题有标准答案。用GSM8K的子集就行。写一个简单的奖励函数最终答案数字和标准答案相同得1分格式不对得0分再对长度做一个软惩罚。奖励函数越简单越容易定位问题。使用开源RL库例如TRL的GRPO脚本设num_generations8、max_length1024、beta0.04、learning_rate1e-6。配置vLLM作为rollout推理引擎观察其吞吐和时延。训练时同时记录reward均值、KL散度、loss、每秒生成token数以及每小时的GPU费用。训练跑1~2个小时看模型在测试集上是否提升。因为模型小、数据少预期不要太高关键是理解“管线”。一个参考的命令雏形具体参数以你下载的版本为准accelerate launch trl/grpo.py \ --model_name_or_path mistralai/Mistral-7B-v0.1 \ --dataset_name my_math_subset \ --num_generations 8 \ --max_length 1024 \ --beta 0.04 \ --learning_rate 1e-6 \ --reward_func format_and_answer \ --output_dir ./grpo_exp注意这里只是示意不同版本接口差异很大我不会贴一段你复制就跑的代码假装自己全知。真正动手时先看官方examples再把奖励函数换成自己的。4.2 中小团队省钱策略与替代方案如果你所在团队算力并不充沛完全可以从“在线RL”降级到“离线偏好优化”。DPODirect Preference Optimization不需要在线rollout不依赖奖励模型打分只需要一对偏好样本好答案vs坏答案成本比GRPO低一个数量级。适用场景是“让模型更懂风格、更听话”但对“让模型学会做题”这种任务RLVR仍然更合适。我整理了一个对比表方法成本稳定性适合场景PPO最高中需要互动/较长序列的通用RLHFGRPO中高较高推理类任务、数学代码DPO低高风格迁移、安全对齐、偏好优化预算实在有限时还可以走“以数据为中心”的路线不重训模型而是把失败case收集起来做SFT数据增强再反复DPO。很多垂直场景下效果不输一轮大模型RL。4.3 算清楚“有效成本”这次训练到底值不值直播里那个“3万美元/小时”确实吓人但单看这个数字没有意义。我们更应该关注“有效成本”每提升1个百分点的任务准确率花了多少钱。举例如果训练目标是让模型在某个推理benchmark上提升5个百分点花掉20万美元那有效成本就是4万美元/百分点但如果只提升了0.2个百分点同样的钱就打了水漂。实际操作中我们会做一个评估驱动的工作流在训练前固定一个评测集避免多人改题导致分数失真每N步用一个相对固定的prompt模板跑几次推理看输出质量和稳定性训练结束后不只报“最高分”还要报“中位步数才达到该分数”以及“是否出现回退”。这样能清楚地判断花出去的算力到底转化成了模型能力还是变成了日志里的噪音。5. 对行业的影响与理性看待成本透明5.1 透明账本会改变什么罗福莉把账本和不稳定一起挂出来这件事的影响不是“一次直播”而是给行业定了一个新的透明度基准。以前我们习惯于看到论文里“我们的方法超越了SOTA”背后成本却是一团迷雾现在公开更多成本细节至少能让后来者对自己要踩的坑有预期。更进一步如果越来越多的团队公开训练成本和失败经验那么行业整体的试错成本会下降很多谁也不必再花冤枉钱走别人走过的弯路。当然透明也不是没代价。公开成本容易引起误读比如有人看到3万美元/小时就以为做大模型RL必须这么烧钱举个例子用单卡跑7B模型的GRPO实验可能一天才几百美元效果评估照样有意义。所以透明账本需要配套“上下文”解读而不是一个孤零零的数字。5.2 从这次直播里我建议你带走的三个“认知”第一强化学习训练是“算力密集型运维密集型”技术含量不在“能训练”而在“稳定地训练”。第二模型大小、任务类型、采样策略决定了成本上下限能差两个数量级没有“标准价格”。第三不稳定才是最大的隐性成本一次回滚可能吞噬掉之前几小时的进度所以稳定性投资永远划算。这三条如果能在你的团队里形成共识那么这场直播的价值比新闻标题里那个3万美元的数字值钱得多。看完直播后我一直在琢磨一个问题如果要把这套流程搬到自己的小集群上第一笔钱我会花在哪儿答案不是买更多卡而是先把监控、checkpoint、自动回滚这些“安全网”铺好。很多团队失败不是死在算法的创新上而是死在一次毫无预警的loss爆炸里连现场证据都没留下来。我自己的经验是先花一两天把日志和告警体系搭好再开机训练哪怕前期规模小一点后期省下的重跑成本也远超投入。最后再分享一个小技巧怀疑模型学崩了的时候先抽样看几段生成文本而不是只看指标曲线。文本一旦开始重复、结构单一大概率是KL约束或者reward shaping出了问题这时候回滚比硬扛更有效。希望下次哪家再直播训练现场时我们都能带着从容的复盘视角去看而不是只看热闹。