1. 一场每小时烧掉20万的RL实验到底在做什么第一次看到“小米直播训练大模型每小时烧掉20万”这个说法我第一反应不是震惊而是好奇这钱到底花在哪了。因为在大模型训练这个圈子里烧钱本身不稀奇稀奇的是“直播训练”这个形式以及“每小时20万”这个量级的成本结构。后来跟几个做强化学习RL和Agent方向的朋友聊了几轮又翻了不少公开的技术分享才把这件事的轮廓拼出来。简单说这是一次把大模型强化学习训练过程公开化、可视化的尝试核心不是炫富而是展示RL在Agent场景下的真实训练开销和工程复杂度。先把这个标题拆开看。小米是主体MiMo是他们的大模型系列RL是强化学习Agent是智能体。这几个词串起来指向的是一个非常具体的工程场景用强化学习的方法去训练一个能作为Agent核心决策模块的大模型。这跟普通的监督微调SFT完全不是一个量级的事情。SFT像是在教室里做题有标准答案RL更像是把模型扔进一个模拟环境里让它自己试错根据结果好坏来调整策略。后者的计算开销、工程复杂度、不稳定因素都是前者的好几倍。那“每小时20万”是怎么来的这个数字不是随便喊的。我按公开的GPU租赁价格和RL训练的资源消耗粗略算过一笔账。假设用的是A100或H100级别的卡单卡每小时租赁成本在10到30元之间浮动具体看渠道和规模。一个中等规模的RL训练任务至少需要几十到上百张卡同时跑因为RL不像SFT那样可以单卡慢慢磨它需要大量的并行环境采样来加速经验收集。再加上RL训练过程中需要维护多个模型副本——策略模型、参考模型、奖励模型、价值模型——显存占用直接翻倍。这样算下来每小时几万到十几万的硬件成本是跑不掉的。如果再加上数据存储、网络带宽、电力散热、以及背后整个工程团队的运维成本20万这个数字并不夸张。但真正让我觉得有意思的不是这个数字本身而是为什么小米要选择直播这种方式。我个人的判断是这背后有两层意图。第一层是技术层面的自信展示说明他们在这个方向上已经跑通了完整的链路从环境搭建到分布式训练到监控告警都有了一套可复用的工程体系。第二层是人才和生态层面的信号释放直播训练过程等于是在告诉外界我们在这个方向上投入了真金白银有真实的工程需求也有真实的技术挑战。这对于吸引RL和Agent方向的人才比任何招聘广告都管用。那这个实验到底解决了什么问题或者说它试图解决什么问题从公开信息来看核心目标是让MiMo模型在Agent场景下具备更强的多步推理和工具调用能力。传统的SFT只能教会模型“看到什么输入输出什么答案”但Agent场景要求模型能够根据当前状态决定下一步该调用哪个工具、该生成什么参数、该不该终止任务。这种序列决策能力靠SFT是教不出来的必须用RL来磨。而RL训练的核心难点在于奖励信号怎么设计、环境怎么搭建、训练怎么稳定、成本怎么控制。这四个问题每一个都是坑。适合谁来参考这篇内容我觉得有三类人。第一类是正在做或准备做RL训练的大模型工程师你们可以从成本结构和工程细节里找到一些参考。第二类是对Agent开发感兴趣的产品和技术人员你们可以理解为什么Agent的“智能”背后需要这么重的训练投入。第三类是对大模型训练成本好奇的从业者你们可以把这个案例当作一个成本估算的锚点。至于完全没接触过大模型训练的小白我建议先看看热闹了解一下这个领域的工程复杂度再决定要不要深入。2. 为什么RL训练比SFT贵这么多2.1 从“做题”到“试错”的本质差异要理解RL训练为什么烧钱得先理解它和SFT的本质区别。SFT的训练过程是给定一个输入模型生成输出然后跟标准答案对比计算损失反向传播更新参数。这个过程是确定性的每个样本的梯度方向是明确的训练曲线通常是平滑下降的。你可以把它想象成学生在做有标准答案的练习题做错了就改改完继续做下一道。RL的训练过程完全不同。模型面对的是一个环境它需要自己决定采取什么动作然后环境给出反馈奖励模型根据奖励来调整策略。这个过程是随机性的因为模型的策略本身带有探索性同一个状态下可能尝试不同的动作。更麻烦的是奖励信号往往是稀疏的、延迟的模型可能做了好几步操作之后才知道最终结果是好是坏。这就像把学生扔进一个模拟驾驶舱让他自己摸索怎么开车撞了才知道错了而且可能撞了好几次才明白哪个操作导致了撞车。这种差异直接导致了计算开销的差异。SFT训练时每个样本只需要一次前向传播和一次反向传播。RL训练时每个训练步需要用当前策略模型在环境中采样若干条轨迹每条轨迹可能包含多步交互然后用这些轨迹计算策略梯度更新模型参数。采样过程本身就需要大量的前向传播而且为了降低方差通常需要采样很多条轨迹。这就意味着RL训练的计算量可能是SFT的几十倍甚至上百倍。2.2 四个模型同时驻留显存的代价RL训练还有一个隐形成本显存占用。在标准的PPO近端策略优化算法中通常需要同时维护四个模型策略模型当前正在训练的主模型、参考模型用于计算KL散度防止策略偏离太远、奖励模型用于给采样轨迹打分、价值模型用于估计状态价值降低方差。这四个模型都需要驻留在显存中而且策略模型和价值模型还需要保存优化器状态。我拿一个具体的配置来算一下。假设MiMo模型的参数量是70B级别用BF16精度存储单个模型副本需要约140GB显存。四个模型就是560GB。再加上优化器状态Adam优化器需要保存一阶矩和二阶矩通常是参数量的两倍策略模型和价值模型的优化器状态又需要额外280GB左右。总共加起来显存需求接近840GB。一张H100有80GB显存这意味着至少需要11张H100才能把模型装下。这还没算上激活值、梯度、通信缓冲区等开销。实际训练时为了并行加速卡数会更多。相比之下SFT训练通常只需要维护一个模型副本加优化器状态显存需求直接减半甚至更多。这就是为什么RL训练的门槛比SFT高得多也是为什么每小时20万的成本里硬件租赁占了大头。2.3 采样效率与并行环境的硬约束RL训练的另一个成本来源是采样效率。在SFT中数据是预先准备好的训练时直接读取就行。在RL中数据是模型在训练过程中实时生成的生成速度取决于环境模拟的速度和模型推理的速度。如果环境模拟很慢或者模型推理很慢整个训练过程就会被拖慢GPU利用率上不去但钱照样在烧。为了解决这个问题通常需要并行启动多个环境实例让模型同时在不同环境中采样。比如同时跑256个环境每个环境独立运行模型轮流处理每个环境的状态。这样可以提高GPU利用率但代价是需要更多的CPU资源来运行环境模拟以及更复杂的通信架构来协调多个环境之间的数据同步。我见过一些团队为了省钱尝试用单环境串行采样结果训练速度慢到无法接受GPU利用率长期低于30%实际上更浪费钱。所以在这个领域并行环境数量是一个关键参数需要根据任务复杂度和硬件配置仔细调优。太少则训练慢太多则通信开销大找到一个平衡点很重要。3. 直播训练背后的工程架构拆解3.1 训练集群的基本拓扑虽然小米没有公开完整的架构细节但根据公开的技术分享和行业通用实践我可以还原出一个典型的RL训练集群拓扑。这个集群通常分为三个主要部分训练节点、推理节点、环境节点。训练节点负责模型参数更新通常由几十到上百张高性能GPU组成通过高速互联如NVLink或InfiniBand连接。推理节点负责用当前策略模型生成动作可以跟训练节点共用硬件也可以独立部署。环境节点负责运行Agent所处的模拟环境通常是CPU密集型任务需要大量的CPU核心和内存。这三个部分之间的数据流是这样的环境节点产生状态发送给推理节点推理节点用策略模型生成动作返回给环境节点环境节点执行动作产生奖励和下一个状态这些交互数据被收集起来发送给训练节点训练节点用这些数据计算梯度更新模型参数更新后的参数再同步给推理节点。这个循环每秒可能执行成千上万次对网络带宽和延迟的要求非常高。3.2 奖励模型的设计与训练在RL训练中奖励模型扮演着“裁判”的角色。它负责给模型生成的轨迹打分告诉模型哪些行为是好的哪些是坏的。奖励模型的质量直接决定了RL训练的效果。如果奖励模型有偏差模型就会学会“钻空子”生成一些能拿高分但实际上没用的行为。奖励模型的训练通常分两步。第一步是收集人类偏好数据让标注人员对模型生成的多个回答进行排序然后训练一个奖励模型来拟合这些排序。第二步是在RL训练过程中用奖励模型给采样轨迹打分作为策略更新的依据。这个过程听起来简单但实际操作中有很多坑。比如奖励模型可能会过拟合到训练数据中的某些模式导致对分布外的样本打分不准。再比如奖励模型的打分尺度可能不稳定导致策略更新时梯度爆炸或消失。我个人的经验是奖励模型的设计需要跟具体任务强相关。对于Agent场景奖励信号通常包括任务是否完成、完成效率如何、工具调用是否正确、输出格式是否合规等。这些信号需要被合理地加权组合才能引导模型学到期望的行为。权重设置没有标准答案需要根据实际效果反复调整。3.3 分布式训练的通信瓶颈RL训练的分布式架构比SFT更复杂因为涉及到多个模型之间的参数同步和数据交换。在SFT中通常只需要在数据并行组之间同步梯度。在RL中除了梯度同步还需要在策略模型和推理节点之间同步参数在环境节点和训练节点之间传输交互数据。这些通信操作如果设计不当很容易成为瓶颈。我见过一些团队在初期版本中每次参数更新后都把完整模型参数广播给所有推理节点结果网络带宽被占满训练速度大幅下降。后来改成只同步增量参数或者用参数服务器架构来管理同步才把瓶颈解决。另一个常见的瓶颈是环境数据的传输。如果环境节点和训练节点之间的网络延迟高采样数据不能及时送达训练节点就会空转。解决方法是尽量让环境节点和训练节点在同一个数据中心内或者用压缩算法减少数据传输量。但这些优化都需要额外的工程投入也是成本的一部分。4. 每小时20万的成本到底花在哪4.1 硬件租赁与折旧的明细账我把RL训练的成本拆成几个主要部分用表格来展示会更清楚。以下是一个基于行业公开信息的估算模型具体数字会因供应商、规模、合同条款而浮动。成本项目估算占比说明GPU租赁55%-65%按H100级别显卡、百卡规模、每小时20-30元估算CPU与内存10%-15%环境模拟需要大量CPU核心内存需求也高网络带宽5%-10%分布式训练对高速互联要求高专线成本不低存储与数据3%-5%训练日志、模型检查点、采样数据需要持久化存储运维人力10%-15%需要专门的团队监控训练状态、处理故障电力散热5%-8%高密度GPU集群的电力消耗和冷却成本从这张表可以看出GPU租赁是绝对的大头。如果按100张H100、每张每小时25元计算光GPU一项就是每小时2500元。但实际训练中为了加速和容错卡数往往更多而且不是所有卡都能满负荷运行。再加上RL训练中推理和训练可能分时复用同一批卡实际利用率可能只有60%-70%。这样算下来每小时几万到十几万的硬件成本是合理的。再加上其他项目20万这个量级并不离谱。4.2 训练不稳定带来的隐性浪费RL训练有一个让人又爱又恨的特点不稳定。训练曲线可能突然崩掉模型性能一夜回到解放前。这种情况在SFT中很少见但在RL中几乎是家常便饭。原因有很多奖励模型打分异常、策略更新步长过大、环境随机性太强、数值精度问题等。每次训练崩溃都意味着之前几个小时的算力白费了。如果崩溃发生在训练后期损失更大。为了应对这个问题通常需要频繁保存检查点以便崩溃后能从最近的检查点恢复。但保存检查点本身也需要时间和存储空间而且恢复后可能再次崩溃。这种反复试错的过程是RL训练成本中不可忽视的一部分。我个人的经验是RL训练的稳定性优化是一个持续的过程。初期可能需要每天处理好几次崩溃随着对任务和算法的理解加深崩溃频率会逐渐降低。但完全避免崩溃几乎不可能只能通过工程手段把损失控制在可接受范围内。4.3 人力成本与时间成本的双重压力除了硬件成本人力成本也不容忽视。RL训练需要一支具备多领域知识的团队懂强化学习算法的、懂分布式系统的、懂环境模拟的、懂奖励模型设计的。这样一支团队的人力成本按市场行情算每月至少几十万。如果训练持续数周甚至数月人力成本会累积到相当可观的数字。时间成本同样重要。RL训练通常需要比SFT长得多的训练周期。SFT可能几天就能看到效果RL可能需要几周甚至几个月。这期间团队需要持续监控、调参、优化。如果方向选错了可能投入了大量资源却得不到预期效果。这种风险是RL训练特有的也是很多团队望而却步的原因。5. Agent场景下RL训练的特殊挑战5.1 多步决策与信用分配问题Agent场景下的RL训练最核心的挑战是信用分配。在一个多步任务中模型可能执行了十几步操作才完成任务。最终的成功或失败应该归因于哪一步是第一步选错了工具还是中间某一步参数填错了还是最后一步输出格式不对这个问题在RL中被称为信用分配问题是强化学习的经典难题。在简单的单步任务中奖励信号直接对应动作信用分配很简单。但在多步任务中奖励信号是延迟的、稀疏的模型很难知道到底是哪一步导致了最终结果。为了解决这个问题通常需要设计更密集的中间奖励或者使用更高级的算法如GAE广义优势估计来更准确地估计每一步的贡献。但这些方法都有各自的局限需要根据具体任务来选择和调优。我试过在一个工具调用任务中只给最终结果奖励结果模型学了很久都没什么进展。后来在中间步骤加了格式奖励和工具选择奖励训练速度明显加快。但中间奖励的权重需要仔细调太重会导致模型只关注中间步骤而忽略最终目标太轻又起不到引导作用。5.2 环境模拟的真实性与成本平衡Agent训练需要一个环境来模拟任务场景。这个环境可以是真实的外部系统如真实的API调用也可以是模拟的沙盒环境。真实环境的好处是数据分布真实训练出来的模型更容易迁移到实际场景。但真实环境的成本很高API调用可能收费、响应速度慢、不稳定、难以并行化。模拟环境的好处是可控、快速、可并行但需要保证模拟的逼真度。如果模拟环境跟真实环境差异太大模型在模拟环境中训练得很好一到真实环境就表现很差。这种“模拟到现实”的差距是Agent训练中一个很头疼的问题。我个人的做法是先用模拟环境快速迭代把模型的基础能力练出来然后再用真实环境做少量微调。这样既能控制成本又能保证最终效果。但模拟环境的开发本身也需要投入而且需要持续维护确保跟真实环境保持同步。5.3 工具调用与格式约束的奖励设计Agent场景下模型需要调用外部工具来完成任务。工具调用有严格的格式要求函数名、参数名、参数类型、返回值处理等。如果格式不对工具调用就会失败。因此在RL训练中格式合规性通常会被作为一个重要的奖励信号。但格式奖励的设计需要小心。如果格式奖励太高模型可能会学会“只输出格式正确的调用但不关心调用结果”导致任务完成率下降。如果格式奖励太低模型又会频繁出现格式错误影响任务执行。我见过一些团队用“格式错误直接给负奖励”的方式效果不错但需要配合其他奖励信号一起使用。另一个问题是工具调用的多样性。如果训练数据中只包含少数几种工具模型可能只会调用这几种工具遇到新工具就不知道怎么办。为了解决这个问题需要在训练数据中引入多样化的工具集或者设计能够泛化到新工具的奖励机制。这又增加了训练数据的准备成本和奖励模型的设计难度。6. 从成本视角看RL训练的未来优化方向6.1 算法层面的效率提升从算法层面看RL训练的效率还有很大的提升空间。目前主流的PPO算法需要同时维护四个模型显存占用和计算开销都很大。一些新的算法尝试减少模型数量比如用同一个模型同时充当策略模型和价值模型或者用更高效的奖励建模方式。这些算法如果成熟可以显著降低RL训练的门槛。另一个方向是离线RL。离线RL不需要在训练过程中实时采样而是用预先收集好的数据进行训练。这样可以避免采样带来的计算开销和环境依赖但代价是需要大量高质量的历史数据而且离线RL的稳定性和效果通常不如在线RL。这个方向目前还在研究中离大规模工程应用还有距离。6.2 工程层面的资源调度优化工程层面的优化空间也很大。比如训练和推理可以分时复用同一批GPU在训练间隙用GPU做推理采样提高利用率。再比如可以用混合精度训练、梯度检查点、模型并行等技术来降低显存占用从而减少所需GPU数量。资源调度方面可以用更智能的调度器来动态分配计算资源。比如在训练稳定期减少监控频率在训练波动期增加资源投入。这些优化需要深入的工程积累但一旦做好可以显著降低成本。6.3 数据层面的复用与合成数据层面的优化可能是最直接的降本手段。RL训练中采样数据是实时生成的用一次就扔。如果能把这些数据有效地复用起来比如用于后续的SFT训练或者奖励模型的迭代就能摊薄单次训练的成本。另一个方向是合成数据。用更强的模型生成高质量的轨迹数据然后用这些数据来训练较小的模型。这种方法在SFT中已经比较成熟在RL中也有探索空间。但合成数据的质量控制和分布匹配是关键难点需要仔细设计生成和筛选流程。7. 一些实操中的避坑经验7.1 训练初期不要追求大规模我见过不少团队一上来就铺几百张卡结果训练不稳定大量算力浪费在崩溃和恢复上。我的建议是先用小规模比如8到16张卡把整个链路跑通确认算法、环境、奖励模型都没有大问题再逐步扩大规模。小规模训练虽然慢但试错成本低而且更容易定位问题。7.2 监控指标要全面且实时RL训练的监控比SFT更重要。除了常规的损失、梯度范数、学习率还需要监控奖励均值、策略熵、KL散度、采样成功率等指标。这些指标能帮你提前发现训练异常。比如策略熵突然下降可能意味着模型过早收敛到局部最优KL散度突然增大可能意味着策略更新步长过大。我习惯把这些指标做成实时看板训练时一直盯着有异常立刻处理。7.3 检查点策略要保守RL训练崩溃是常态所以检查点策略要保守。我通常每半小时保存一次检查点保留最近几个版本。这样即使崩溃最多损失半小时的算力。检查点的存储也要注意不要只存一份最好异地备份防止存储故障导致检查点丢失。7.4 奖励模型要定期评估奖励模型不是训练完就一劳永逸的。随着策略模型的更新奖励模型可能会遇到分布外的样本打分准确性下降。我习惯每隔一段时间就用人工评估一批样本检查奖励模型的打分是否合理。如果发现偏差及时调整或重新训练奖励模型。7.5 环境模拟要尽量逼真环境模拟的逼真度直接影响训练效果。我见过一些团队为了省事用非常简化的环境做训练结果模型在真实环境中表现很差。我的建议是环境模拟至少要覆盖真实环境中的主要边界情况比如超时、错误返回、格式异常等。这些情况在真实环境中经常出现如果训练时没遇到过模型就不知道该怎么处理。8. 这个实验对行业的参考价值回到小米这次直播训练我觉得它的价值不在于展示了多强的技术实力而在于把一个原本封闭的、高成本的训练过程公开出来让更多人看到RL训练的真实面貌。这种透明度在行业里并不多见大多数团队都是闷头做很少分享细节。从成本角度看每小时20万这个数字给行业提供了一个参考锚点。如果你也在做类似的RL训练可以用这个数字来估算自己的成本是否合理。如果你的成本远低于这个数字可能是规模较小或者优化做得很好如果远高于这个数字可能需要检查一下资源利用率或者训练稳定性。从技术角度看这次实验展示了RL在Agent场景下的可行性。虽然具体效果没有公开但至少说明这条路是走得通的。对于正在探索Agent方向的团队来说这是一个积极的信号。从人才角度看这种公开实验有助于吸引对RL和Agent感兴趣的人才。毕竟能接触到真实的大规模训练环境对很多工程师来说是有吸引力的。我个人在实际操作中的体会是RL训练的门槛确实比SFT高很多但一旦跑通模型在复杂任务上的表现提升也是SFT难以达到的。如果你正在考虑是否要投入RL训练我的建议是先想清楚你的任务是否真的需要RL如果SFT就能解决就不要上RL如果确实需要那就做好打持久战的准备从小的规模开始逐步迭代不要指望一次成功。