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；如果确实需要，那就做好打持久战的准备，从小的规模开始，逐步迭代，不要指望一次成功。
