企业官网建设流程全解析

1. 每小时20万到底烧在了哪里

第一次看到"每小时烧掉20万"这个数字，我的反应和大多数人一样：这是在烧钱还是在烧显卡？后来跟几个做强化学习训练的朋友聊过之后才明白，这个量级的开销在RL（强化学习）训练里其实并不夸张，尤其是当你的训练规模到了小米这个体量。

先把账算清楚。20万每小时，按当前主流云端GPU租赁价格倒推，大致对应数百张高端加速卡的并发占用。这个数字背后包含的不只是显卡租金，还有几块容易被忽略的成本：环境交互的算力开销、奖励模型的前向推理成本、数据存储与传输的带宽费用，以及失败重跑带来的隐性浪费。很多人只盯着训练卡的数量，却忘了RL和传统监督学习最大的区别——它需要模型不断与环境交互，每一次交互都是一次完整的前向计算。

我拿一个具体的例子来说明。假设你在训练一个Agent去完成多步推理任务，每一步动作都需要调用一次策略模型生成，然后由奖励模型打分。如果平均一条轨迹有10步，batch size是256，那么一个训练step就要做2560次策略前向加2560次奖励前向。这还没算上环境本身的模拟开销。传统SFT（监督微调）一个step可能只需要一次前向加一次反向，RL的算力消耗轻松就是它的5到10倍。

提示：评估RL训练预算时，不要只算训练卡的账，要把"采样算力+奖励算力+训练算力"三者相加，这才是真实成本。

小米这次实验之所以引人关注，不只是因为钱多，而是它代表了一种趋势：消费电子厂商开始把大模型能力往Agent方向推。MiMo作为小米的大模型系列，如果只是做对话，其实用不上RL这套重武器。一旦要做Agent——能调用工具、能多步规划、能在真实场景里完成任务——RL就成了绕不开的路。因为Agent的核心能力"决策"，恰恰是RL最擅长的事情。

这也是为什么"每小时20万"这个数字值得单独拿出来讲。它不是炫富，而是在告诉整个行业：Agent能力的门槛，首先是一道算力门槛。你想让模型学会在复杂环境里做对决策，就得给它足够多的试错机会，而每一次试错都要真金白银地买单。

2. RL训练大模型和普通微调的本质区别

2.1 从"模仿"到"试错"的范式切换

普通微调，不管是全参微调还是LoRA，本质都是模仿学习。你给它一堆"问题-标准答案"的配对，它学着去复现这些答案。损失函数是交叉熵，优化目标是让输出分布尽量贴近标注分布。这个过程是静态的、离线的、可复现的。

RL训练完全是另一回事。它不给标准答案，只给一个奖励信号。模型自己生成回答，环境根据回答给一个分数，模型根据分数调整策略。这里的关键在于：模型探索的空间是开放的，它可能生成训练数据里从未出现过的回答，而这些新回答可能比标注数据更好，也可能更差。RL的价值就在于，它能把这个探索过程导向"更好的方向"。

我打个比方。微调像是让学生抄标准答案，抄多了自然就会了。RL像是让学生自己做题，做对了给糖，做错了不给，学生自己摸索出解题套路。后者显然更难，但也更可能摸索出标准答案之外的更优解法。

2.2 奖励模型才是真正的成本黑洞

很多人以为RL训练贵在策略模型，其实奖励模型（Reward Model）才是隐藏的成本大头。原因很简单：策略模型每生成一个回答，奖励模型就要评估一次。如果策略模型生成10个候选回答做对比（比如PPO里的采样），奖励模型就要跑10次前向。而且奖励模型往往和策略模型规模相当，这就意味着奖励推理的算力开销可能和策略采样持平甚至更高。

更麻烦的是奖励模型本身也需要训练。你得先有一批人类偏好数据，训练出一个能打分的奖励模型，然后才能用它来指导策略优化。这个奖励模型的训练成本，加上它在线推理的成本，加起来经常超过策略模型本身的训练开销。

这张表能解释为什么RL的账单是微调的5到10倍。每一项单独看都不算离谱，叠在一起就是数量级的差距。

2.3 稳定性问题带来的隐性浪费

RL训练最让人头疼的不是贵，而是不稳定。策略模型可能在某个训练阶段突然"崩掉"，输出变得毫无逻辑，奖励分数断崖式下跌。这时候你只能回滚到上一个checkpoint重跑，而重跑意味着之前烧掉的那几个小时全部打水漂。

我在实际项目里遇到过类似情况：训练到第3天，模型突然开始输出重复的乱码，排查了半天发现是KL散度约束设得太松，策略跑偏了。回滚重跑，直接损失了十几个小时的算力。这种隐性浪费在预算表里是看不到的，但它真实存在，而且频率不低。

所以"每小时20万"这个数字，如果算上失败重跑，实际的有效训练成本可能还要再上浮30%到50%。这也是为什么大厂做RL训练时，会专门配一个团队盯着训练曲线，一旦发现异常立刻干预——盯盘的人力成本，也是成本。

3. Agent能力为什么必须靠RL喂出来

3.1 工具调用不是"教"出来的，是"练"出来的

Agent的核心能力之一是工具调用。你让模型学会在合适的时候调用搜索、计算器、代码执行器，这件事用监督微调能做到及格，但做不到优秀。原因是工具调用的场景太发散了：什么时机调、调哪个工具、参数怎么填、返回结果怎么用，这些决策的组合空间极大，标注数据根本覆盖不全。

RL在这里的优势就体现出来了。你只需要定义一个奖励函数：任务完成了给正分，没完成给负分，中间过程可以给一些稠密奖励做引导。模型自己会去探索"什么情况下调工具能拿高分"。这个探索过程可能产生一些人类标注者想不到的巧妙策略，这正是RL的魅力所在。

我见过一个很典型的例子：模型在训练初期乱调工具，奖励很低；训练中期学会了"先思考再调工具"，奖励上升；训练后期甚至学会了"调工具失败后换一个工具重试"，这种容错能力是纯监督学习很难教出来的。

3.2 多步规划需要延迟奖励

Agent的另一个核心能力是多步规划。一个复杂任务往往需要十几步甚至几十步操作，而奖励只在任务结束时给出。这就是RL里的**延迟奖励（Delayed Reward）**问题：模型怎么知道前面哪一步做对了、哪一步做错了？

这个问题在监督学习里几乎无解，因为你没法给每一步都标注"对错"。但RL有成熟的方法论来处理它，比如**价值函数（Value Function）**估计、**优势函数（Advantage Function）**计算、**GAE（广义优势估计）**等。这些方法能把最终奖励合理地分配到每一步，让模型知道"虽然最后成功了，但第5步其实走错了，只是运气好被后面救回来了"。

小米做Agent，绕不开这些技术。而每一个技术点的实现，都对应着实打实的算力开销。价值函数要和策略模型一起训练，优势估计要做额外的反向传播，这些都是钱。

3.3 真实场景的奖励设计是门手艺

奖励函数设计是RL里最玄学的部分。设计得好，模型学得又快又稳；设计得差，模型会钻空子（Reward Hacking），找到一些"拿高分但没真正完成任务"的歪门邪道。

举个经典的坑：如果你用"回答长度"作为奖励的一部分，模型很快会学会输出又臭又长的废话来刷分。如果你用"用户点击率"作为奖励，模型可能学会标题党。这些坑在Agent场景里更隐蔽，因为Agent的任务链条更长，奖励信号更稀疏。

注意：奖励函数一定要做对抗测试，专门找一批"看起来能拿高分但实际没完成任务"的样本来验证，否则训练到一半才发现模型在钻空子，损失就大了。

小米这种体量的实验，奖励设计大概率是团队里最核心的几个人在把关。因为奖励函数一旦定错方向，后面烧的所有钱都是在错误的方向上狂奔。这也是为什么RL训练的前期准备时间往往比训练本身还长——想清楚要什么，比埋头训练重要得多。

4. 从MiMo看消费电子厂商做Agent的路径选择

4.1 为什么是小米而不是纯AI公司先跑通

纯AI公司做大模型，往往聚焦在通用能力上，因为它们的商业模式是卖API或者卖订阅。但小米不一样，它有硬件入口和场景闭环。手机、音箱、汽车、家居设备，这些都是Agent天然的落地场景。

这意味着小米做Agent有一个别人没有的优势：它可以直接在真实场景里收集反馈。用户对着手机说"帮我订个明早的闹钟并同步到手表"，这个任务成功没成功，小米的系统直接就知道。这种真实反馈是训练Agent最宝贵的数据，而纯AI公司只能靠模拟环境或者人工标注来近似。

所以小米愿意花每小时20万去跑RL实验，逻辑是通的：它不是在烧钱做研究，而是在为未来的产品能力做投资。一旦Agent能力成熟，它可以立刻铺到几亿台设备上，这个回报是纯AI公司给不了的。

4.2 MiMo的技术路线推测

从公开信息看，MiMo系列一直在往"端侧+云侧"协同的方向走。端侧跑小模型做快速响应，云侧跑大模型做复杂推理。这个架构对Agent特别友好，因为Agent的任务可以拆解：简单决策端侧做，复杂规划云侧做。

RL训练在这个架构里扮演什么角色？我推测主要是训练云侧大模型的规划能力和端云协同的调度策略。前者是让模型学会拆解复杂任务，后者是让模型学会"什么时候该把任务交给云侧"。这两个能力都很难用监督学习教，必须靠RL在真实交互里磨。

4.3 成本控制的几个现实手段

每小时20万听着吓人，但实际工程里有很多手段能把有效成本压下来：

• 课程学习（Curriculum Learning）：先用简单任务训练，模型能力上来了再上难任务。简单任务的轨迹短、采样快，能大幅降低前期成本。
• 经验回放（Experience Replay）：把历史交互数据存下来重复利用，减少重复采样。这在离线RL里是标配，在线RL里也能用。
• 异步采样：采样和训练解耦，采样进程持续跑，训练进程按自己的节奏消费数据。这样GPU利用率更高，不会出现"采样时训练卡闲着"的浪费。
• 奖励模型蒸馏：把大奖励模型蒸馏成小模型，推理成本能降一个数量级，精度损失可控。

这些手段叠加起来，能把账面成本压掉一半以上。所以"每小时20万"更可能是峰值成本或者账面成本，实际有效成本要低不少。但即便如此，这个量级的投入也不是小团队能玩的。

5. 想复现类似实验，个人和小团队该怎么起步

5.1 别一上来就碰全参RL

如果你是个体开发者或者小团队，看到小米的实验心痒痒，我的建议是：先从LoRA+RLHF的小规模实验做起。全参RL训练7B以上的模型，没有几十张卡根本跑不动。但用LoRA做策略微调，配合一个小的奖励模型，单机8卡甚至4卡就能跑起来。

具体路径我建议这样走：

1. 先找一个开源的小模型（1B到3B），用SFT把它调到一个"能正常对话"的水平。
2. 用公开的偏好数据集（比如HH-RLHF）训练一个小的奖励模型。
3. 用PPO或者DPO做RL微调。DPO比PPO简单很多，不需要单独的奖励模型，适合入门。
4. 跑通之后再逐步加规模、加复杂度。

这条路走下来，单次实验成本能控制在几百到几千块，是个人能承受的范围。

5.2 环境搭建的坑

RL训练的环境搭建比SFT麻烦得多，因为涉及多个组件的协同。我踩过的坑包括：

• 版本冲突：RL框架（如TRL、verl）对PyTorch和CUDA版本很敏感，装错一个版本就各种报错。建议用官方推荐的Docker镜像，别自己配环境。
• 显存爆炸：策略模型、奖励模型、价值模型、参考模型，四个模型同时驻留显存，7B模型轻松吃掉80G。解决办法是用LoRA减少可训练参数，或者用vLLM做推理加速和显存优化。
• 通信瓶颈：多卡训练时，采样和训练之间的数据传输可能成为瓶颈。用NVLink或者高速网络能缓解，但成本上去了。

提示：第一次跑RL，先用最小的配置（1B模型、单卡、小数据集）把整个流程跑通，确认每个环节都正常，再往上加规模。直接上大配置，出错了你都不知道是哪个环节的问题。

5.3 奖励设计的入门方法

奖励设计对新手最难。我的经验是：先用规则奖励，别急着上模型奖励。规则奖励就是写代码判断任务是否完成，比如"代码能不能跑通""答案对不对""格式符不符合要求"。规则奖励虽然粗糙，但胜在稳定、可解释、零成本。

等规则奖励跑通了，再考虑引入模型奖励来处理那些规则覆盖不到的情况。模型奖励的训练数据可以来自规则奖励的筛选结果，形成一个迭代循环。

5.4 成本监控要做在前面

不管规模大小，成本监控一定要做在前面。我见过太多人训练到一半发现预算超了，只能中途停掉，前面的投入全废。建议在训练脚本里加一个成本计数器，实时显示已消耗的算力时长和预估费用，设一个硬性上限，到了就自动停。

这个习惯在大规模实验里是保命符。小米那种每小时20万的实验，如果没有严格的成本监控，一天就能烧掉几百万。大厂有专门的成本管理团队，个人开发者只能靠自己写脚本。

6. 这场实验对整个行业的信号意义

小米愿意在RL训练上砸这个量级的钱，传递出的信号很明确：Agent是下一个必争之地，而RL是通往Agent的必经之路。过去两年大家都在卷预训练和SFT，把模型的"知识"和"对话"能力推到了很高的水平。但Agent需要的是"决策"能力，这个能力SFT给不了，只能靠RL。

我判断接下来会有几个趋势：

第一，RL训练的基础设施会成为新的竞争焦点。谁的训练框架更稳定、更高效、更省钱，谁就能在Agent竞赛里跑得更快。现在开源的RL框架（verl、OpenRLHF、TRL）还在快速迭代，但离"开箱即用"还有距离。

第二，奖励模型的重要性会被重新认识。过去大家把奖励模型当成RL的一个配件，未来它可能会独立成一个核心能力。谁能训出更准、更稳、更难被钻空子的奖励模型，谁就掌握了Agent训练的钥匙。

第三，端云协同的Agent架构会成为主流。纯云侧的Agent延迟高、成本高，纯端侧的Agent能力弱。端云协同是平衡点，但协同策略本身就需要RL来优化。这是一个新的技术方向，目前还没有成熟的方案。

对个人开发者来说，这些趋势意味着机会。大厂在卷基础设施和规模，个人可以在垂直场景的Agent上找突破口。比如专门做某个行业的Agent，用RL在小规模上打磨出极致的效果，这种"小而美"的路线是大厂顾不上的。

我自己最近在尝试用DPO做垂直场景的Agent微调，成本可控，效果也还不错。等跑出稳定结果了再单独写一篇分享。RL这条路确实烧钱，但烧得值不值，取决于你想解决什么问题。如果只是想做个聊天机器人，SFT足够了；但如果想让模型真正"会做事"，RL这关绕不过去。