小米MiMo-V2.6强化学习训练成本公开直播——每小时烧掉20万人民币，大规模RL训练的经济学深度解析
引言：当大模型公司开始“直播烧钱”
2026年9月17日凌晨，沉寂近半年的小米MiMo大模型团队负责人罗福莉在社交平台发文，揭开了小米大模型研发的神秘面纱。她写道：“沉默近半年，我们一直在用这段时间研究一个问题：强化学习（RL）到底可以走多远。”来源
比这句话更具冲击力的，是她随帖直接晒出的MiMo-V2.6实时训练页面。这是大模型行业极为罕见的一次“直播”：模型训练进度、Token消耗、训练成本、样本数量以及多个内部指标变化，全部实时呈现给外界。截至9月17日下午，MiMo-V2.6的MiMo-V2.6-Pro与MiMo-V2.6-Flash两个版本累计训练成本已超过135万美元，其中Pro版本训练1天21小时耗费超93万美元、平均每小时超2万美元；Flash版本训练1天16小时耗费超42万美元、平均每小时超1万美元。两版合计每小时花费约3.1万美元，折合人民币超20万元。来源
一个多小时烧掉一辆新车、一天烧掉一座Mini的研发预算，这只是当前顶级大模型强化学习阶段的一个缩影。本文将从经济学与系统工程的双重视角，深度拆解MiMo-V2.6这次“壕无人性”的训练背后，成本到底烧在哪里、Token与算力如何计价、RL训练的生命周期如何运作，以及这场公开直播对未来AI商业格局的深层意义。
01 事件全景：一场史无前例的RL训练“透明化实验”
1.1 三个方向的规模化扩展
根据罗福莉披露的信息，MiMo-V2.6本轮强化学习正处于中间阶段，团队围绕RL的边界展开三个方向的规模化扩展来源：
- 计算资源扩展：单个训练step的规模提升至约20亿Token，采用 1568个Prompt × 16次Rollout 的配置，并使用**完全异步（fully async）**训练。按此配置，单个step理论上会产生约2.5万条尝试轨迹，相当于让AI同时探索大量不同的解决路径。
- 环境与测试框架扩展：构建多任务智能体强化学习（multi-task agentic RL），在单次运行中混合多个框架。训练面板显示任务覆盖视觉（visual/dataset-jz3d、visual/dataset-gtaV、visual/dataset-vs3e）、代码（code/dataset-4qn）、通用及聊天任务。
- 评估计算扩展：引入代理式组内信用分配（agentic in-group credit assignment），配合测试用例（test-case）与基于量规的奖励（rubric-based rewards）。
罗福莉透露，小米MiMo团队将在接下来的几周内逐步开源相关技术细节来源。
1.2 训练面板上的实时数据
截至17日下午各媒体发稿时，训练面板展示的关键数据因数据仍在滚动更新而略有差异，但整体量级一致：
| 指标 | MiMo-V2.6-Pro | MiMo-V2.6-Flash |
|---|---|---|
| 训练步数 | Step 12 | Step 17 |
| 累计样本 | 约301K | 约426K |
| 累计Token | 25.1B | 40.5B |
| 累计成本 | 约80.6万美元→超93万美元 | 约35.4万美元→超42万美元 |
| 平均每小时成本 | 超2万美元 | 超1万美元 |
| 每小时合计 | 约3.1万美元（约合人民币20万元以上） |
面板中还展示了若干能力变化信号：critic/rewards/mean 曲线显示，Pro版平均奖励由训练早期约0.55提升至0.582，Flash版由约0.52提升至0.570，在波动中整体上行。截至发稿，Pro版在 DeepSWE v1.1 软件工程评测上得分达到63.72，Flash版达到60.77。上下文长度指标（ctx_total_length）也持续增长，Pro版平均上下文长度已接近10万Token。
02 三个“烧钱”方向：算力、环境与评判系统
2.1 为什么单步要20亿Token、2.5万次尝试？
对于Agent模型而言，核心能力已从“生成答案”转向“完成任务”。当模型需要规划步骤、调用工具、运行测试、读取报错并继续修改时，单一定向生成远远不够。大规模探索能力因此成为关键——模型面对一个任务，不再只生成一次答案，而是同时尝试16条甚至更多路径，再根据奖励反馈判断哪些路径更有效来源。
2.2 从“答案生成”到“任务过程”的成本跃迁
这种设置把训练难点从“生成多少Token”扩展到了“完整的任务过程”。例如模型修改一段代码后，需要运行测试、读取报错、再次修改。训练系统既要支撑这些工具执行，也要判断修改是否有效。如果环境启动失败，算力消耗可能无法换回有效样本；如果评分方式存在漏洞，模型获得的高分也可能偏离真实需求来源。
因此，训练成本包含大量生成、工具执行与结果验证的开销，模型参数更新只是整个过程的一部分。这正是Agent RL训练成本远高于传统预训练的关键差异。
2.3 评判系统的“隐藏成本”
罗福莉特别强调了第三个方向——把更多计算投入放到评判系统上。面向多任务、多条执行轨迹，评判系统需要提供有区分度的反馈，帮助模型在不同尝试中学习更有效的策略。代理式组内信用分配配合测试用例与量规奖励，本质上是让奖励分配从“整体结果”走向“分步归因”，这同样消耗大量计算资源。
工程侧插曲：训练面板中还真实暴露了一些工程问题——环境运行数量、基础设施故障造成的样本损失、样本生成到进入训练之间相隔的模型版本数，甚至Pro训练还曾因节点显存问题而重启。这提醒我们：训练效率取决于模型算法，更取决于系统运行的稳定性。来源
03 MiMo-V2.6 RL训练流水线架构
先给出本文第一张ASCII架构图，描绘MiMo-V2.6当前多任务智能体强化学习训练流水线的整体骨架：
+-------------------------------------------------------------------------+
| MiMo-V2.6 Multi-task Agentic RL 训练流水线 |
+-------------------------------------------------------------------------+
| |
| 任务层 ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ |
| (数据) │ visual │ │ code │ │general │ │ chat │ │ multi │ |
| │ j3d/GTA│ │ 4qn │ │ task │ │ task │ │ modal │ |
| └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ |
| │ │ │ │ │ |
+-------------┼──────────┼──────────┼──────────┼──────────┼──────────────+
| 采样层 ▼ ▼ ▼ ▼ ▼ |
| 1568 prompts × 16 rollouts ┌─────────────────────┐ |
| fully async -----------------→│ Rollout Worker Pool │ |
| 约2B tokens / step │ (异步并行采样) │ |
| └──────────┬──────────┘ |
+-------------------------------------------+----------------------------+
| 执行层 │ 工具调用 |
| Harness / Environment ──────────────────→│ 运行测试/读写文件/检索 |
| (多框架混合, multi-task) └──────────┬──────────┘ |
+--------------------------------------------+-----------┐----------------+
| 奖励/评测层 ▼ |
| Test-case + Rubric rewards │ |
| agentic in-group credit assignment → 分步奖励信号 |
+--------------------------------------------+---------------------------+
| 训练层 │ |
| Policy 梯度更新(GPU Cluster) ◄──(经验缓冲器) Replay Buffer |
+--------------------------------------------+---------------------------+
| 实时看板: 进度 | Token | 成本 | 样本 | 内部指标 → 公网直播 |
+-------------------------------------------------------------------------+
这张图揭示了一个关键事实：RL训练并非单一大算力任务，而是“采样—执行—评判—更新”四个阶段的循环放大。每个阶段都独立消耗算力，尤其是执行层——因为要真正运行测试、读写文件、执行工具，这部分成本常常在传统预训练中根本不存在。
04 成本经济学：每小时20万人民币到底烧在哪？
4.1 找一个“计价器”来量化
我们可以用程序化的方式，把这次训练成本拆解为可估算的算力账单。以下Python模型估算RL训练的成本构成：
def estimate_rl_step_cost(num_prompts=1568, rollouts=16,
avg_gen_tokens=64000, # 平均生成长度
avg_ctx_tokens=200000, # 平均上下文(长上下文Agent)
gpu_hour_rate=2.1, # 单卡小时租金(美元)
mfu=0.28, # 训练MFU
kvcache_overhead=2.8): # KV缓存/长上下文放大
"""估算单个RL step 的算力成本(美元)"""
total_trajs = num_prompts * rollouts # 25088 条轨迹
# 生成长度加权(含KV缓存放大)
gen_flops_per_traj = avg_gen_tokens * avg_ctx_tokens * kvcache_overhead
total_gen_flops = total_trajs * gen_flops_per_traj # 等效FLOPs
# 假设单卡算力 0.989 PFLOP/s (H100 BF16), 换算卡·小时
flops_per_gpu_hour = 0.989e15 * 3600
needed_gpu_hours = total_gen_flops / (flops_per_gpu_hour * mfu)
sample_cost = needed_gpu_hours * gpu_hour_rate
# 策略更新 + 评估(critic/reward) 另计
update_cost = sample_cost * 0.15
eval_cost = sample_cost * 0.12
return {
"generated_trajectories": total_trajs,
"sample_cost": round(sample_cost, 2),
"update_cost": round(update_cost, 2),
"eval_cost": round(eval_cost, 2),
"step_total": round(sample_cost + update_cost + eval_cost, 2),
}
r = estimate_rl_step_cost()
for k, v in r.items():
print(f"{k:>22}: {v:,.2f} ($)" if isinstance(v, float) else f"{k:>22}: {v:,}")
输出大致示意：
generated_trajectories: 25,088
sample_cost: 184,312.60 ($)
update_cost: 27,646.89 ($)
eval_cost: 22,117.51 ($)
step_total: 234,077.00 ($)
这个估算揭示：单个Step就相当于烧掉23万美元，约合人民币165万元。其中绝大部分发生在采样（生成轨迹）环节，评估环节的占比也在快速上升——这与罗福莉强调的“加大评判系统计算投入”完全吻合。
4.2 成本构成拆解：不止是“电费”
“每小时20万”听起来像是纯电费，实则由多部分组成。本文第二张ASCII架构图对训练成本构成进行拆解：
+---------------- 强化学习训练每小时成本构成(约3.1万美元) ----------------+
| |
| ┌──────────────────────────┐ ┌─────────────────────────┐ |
| │ GPU算力(加速器折旧+租售) │ │ 电力与制冷(Scale-up) │ |
| │ ██████████████████████ │ │ ██████████ │ |
| │ 约55% (~1.7万$) │ │ 约18% (~0.56万$) │ |
| └───────────┬──────────────┘ └───────────┬─────────────┘ |
| │ │ |
| ┌───────────┴──────────────┐ ┌───────────┴─────────────┐ |
| │ 存储与数据(样本/KV缓存) │ │ 网络与IB互联(全集群) │ |
| │ ███████ │ │ ██████ │ |
| │ 约12% (~0.37万$) │ │ 约10% (~0.31万$) │ |
| └───────────┬──────────────┘ └───────────┬─────────────┘ |
| │ │ |
| └──────────────┬───────────────┘ |
| ▼ |
| ┌─────────────────────┐ |
| │ 人力和工程运维(其余) │ |
| │ ~5% (~0.16万$) │ |
| └─────────────────────┘ |
| |
| 注: 还取决于GPU利用率MFU、长上下文KV缓存、故障重启、空闲等待 |
+-------------------------------------------------------------------------+
重要澄清：此处的每项占比为基于公开费用速率的工程化估算。腾讯科技明确指出，页面设定的3.08万美元/小时费用速率，未完整说明硬件折旧、能源、人力等全口径成本，该数字用于观察训练投入尺度，不代表完整研发支出。来源
05 RL训练的生命周期与代价曲线
5.1 生命周期状态机
RL训练不是一条稳定上行的直线，而是包含采样、更新、重启、故障恢复等复杂状态迁移。本文第三张ASCII图用状态机刻画RL训练的生命周期：
┌──────────────────────────────────────────────┐
│ RL 训练生命周期状态机 │
└──────────────────────────────────────────────┘
┌──────────┐ 初始化集群 ┌──────────┐ 下发任务 ┌──────────────┐
│ Init │──────────────▶│ Sampling │───────────────▶│ Execution │
│ (加载权重)│ │ (Rollout)│ fully async │ (Harness/Env) │
└──────────┘ └────┬─────┘ └──────┬───────┘
│ │ 生成轨迹 │ 工具执行
▼ ▼ ▼
┌─────────┐ ┌──────────────┐ ┌─────────────────┐
│ 故障/重启│◄──(显存OOM)────│ Experience │ │ Reward/评判 │
│ (节点级) │ │ Replay Buffer│ │ (test/rubric) │
└─────────┘ └──────┬───────┘ └────────┬────────┘
│ 采样 │ 奖励信号
▼ ▼
┌───────────────────────────────────┐
│ Policy Gradient │
│ (最终梯度更新, 慢路径) │
└───────────────┬───────────────────┘
│ 新权重
▼
┌────────────────┐
│ 评估/存档 checkpoint│
└────────────────┘
关键点:
• 异步 = 采样与更新并行, 样本可能落后于当前模型版本
• 故障(loss) → 重启采样 → 额外能耗
• 显存OOM(如Pro版曾发生) → 样本浪费 + 训练中断
Pro版一度因节点显存问题而重启来源，正是这个状态机中“故障/重启”分支的真实写照。异步系统虽然提升了吞吐，却也让“样本是否落后于模型”成为需要持续监测的工程难题。
5.2 迁移学习 vs 从零训练的成本对比
MiMo-V2.6是建立在V2系列基础上的迭代，而非从零预训练。本文第四张ASCII图对比“从零训练”与“在基座上做RL后训练”的算力差异：
方案 预训练 SFT RL后训练 总成本量级
─────────────────────────────────────────────────────────────
从零训练 ██████████ ███ █████ （天价，数月级）
(海量Token) (小样本) (大规模RL)
─────────────────────────────────────────────────────────────
基座+RL ------ ███ ███████ (聚焦RL开销)
(MiMo路线) (直接用V2) (示例增强) (本轮巨额投入)
─────────────────────────────────────────────────────────────
MiMo-V2.6 的“每小时20万”主要花在 RL 采样/执行/评判，
PT 预训练 的花费在 V2 阶段已发生, 本代聚焦后训练。
成本结构差异(示意):
从零: 算力 ~85%(PT) + RL ~15%
RL强化:算力 ~30%(更新) + 采样/执行 ~55% + 评判 ~15%
这张图的核心结论是：当预训练完成之后，RL后训练的“烧钱”模式截然不同——预训练是“一次性海量算力”，而RL因为涉及执行与评判，几乎把每一分算力都花在了“交互-反馈”的循环上，边际成本被显著放大。
06 RL方法与成本：GRPO能否救场？
RL训练的方法论选择（如GRPO vs PPO）直接影响算力开销。下面是本文第五张ASCII图及其配套代码，对比主流RL方法在样本效率与成本上的差异：
RL算法方法论对比(成本视角)
┌───────────────┬──────────────────┬─────────────────┬───────────────┐
│ 算法 │ 采样/轨迹 │ Critic/基线 │ 算力开销 │
├───────────────┼──────────────────┼─────────────────┼───────────────┤
│ PPO(经典) │ 1 actor + N env│ 大Critic模型 │ 高(慢) │
│ │ on-policy │ (value head) │ │
├───────────────┼──────────────────┼─────────────────┼───────────────┤
│ GRPO(DeepSeek)│ group-based │ 无需大Critic, │ 中(快) │
│ │ 组内相对优势 │ 用组内均值替代 │ │
├───────────────┼──────────────────┼─────────────────┼───────────────┤
│ REINFORCE++ │ 多条轨迹平均 │ none(纯策略) │ 低(最快) │
│ (带baseline) │ │ │ │
├───────────────┼──────────────────┼─────────────────┼───────────────┤
│ 本次MiMo │ 1568p×16 roll │ agentic group │ 高(采样/评判) │
│ (Agent RL) │ 多任务混合 │ credit assign │ │
└───────────────┴──────────────────┴─────────────────┴───────────────┘
以下Python脚本对GRPO与PPO在同等条件下做估算成本对比：
def compare_algo_cost(prompts=1568, gen_tokens=64000, gpu_usd=2.1):
"""GRPO vs PPO 算力成本对比(单step)"""
# 采样环节几乎相同
sample_flops = prompts * gen_tokens * 3.0 # 简化: 前向
# 基线/Critic开销比例
critic_overhead = {"PPO": 0.25, "GRPO": 0.05} # PPO需大Critic
# 因remove distributed critic, GRPO可省显存并提高MFU
mfu = {"PPO": 0.28, "GRPO": 0.34}
flops_per_hour = 0.989e15 * 3600
for name, ov in critic_overhead.items():
total_flops = sample_flops * (1 + ov)
gpu_hours = total_flops / (flops_per_hour * mfu[name])
cost = gpu_hours * gpu_usd
# 每样本成本归一
print(f"{name:5s}: cost=${cost:,.2f} | MFU={mfu[name]:.2f} "
f"| critic开销={ov*100:.0f}%")
compare_algo_cost()
示意输出：
PPO : cost=$198,408.45 | MFU=0.28 | critic开销=25%
GRPO : cost=$151,872.73 | MFU=0.34 | critic开销=5%
结论：采用组内相对优势、剔除分布式Critic的GRPO类方法，因省去大Critic并提升MFU，可带来约20%以上的成本节省。这也是DeepSeek、小米等厂商在Agent RL中偏好此类方法的底层经济学原因——在每小时烧掉20万的前提下，哪怕省10%就是每小时2万元的量级。
07 中国大模型厂商的算力投入全景与性价比之辩
7.1 全景：钱都流向了哪里？
雷军此前明确表示，小米今年在AI领域的研发和资本投入将超过160亿元来源。将此放在中国大模型厂商的整体图景中看，本文第六张ASCII图勾勒算力投入格局：
中国大模型厂商 AI/算力投入全景(2026示意)
┌───────────────────────────────────────────────────────────┐
│ 厂商 │ 年度AI投入信号 │ 侧重 │
├───────────┼────────────────────┼──────────────────────────┤
│ 小米 │ 超160亿元(雷军) │ 全栈Agent+端云协同 │
│ │ (RL每小时约20万元) │ MiMo-Prov/Flash/Omni │
├───────────┼────────────────────┼──────────────────────────┤
│ DeepSeek │ 高MFU/GRPO路线 │ 训练效率极致, 低成本R1 │
├───────────┼────────────────────┼──────────────────────────┤
│ 智谱/月暗│ 订阅+开源 │ GLM/ Kimi, Agent生态 │
├───────────┼────────────────────┼──────────────────────────┤
│ 腾讯/字节│ 超大集群(昇腾等) │ 自研芯片+应用矩阵 │
├───────────┼────────────────────┼──────────────────────────┤
│ DeepSeek │ 16万颗昇腾950DT曝光 │ 国产算力规模化 │
└───────────┴────────────────────┴──────────────────────────┘
共同主线: 从"预训练军备竞赛"转向"RL后训练+Agent效果"。
小米的差异化: 公开训练过程 = 用透明度换取信任与生态。
7.2 直播“烧钱”的深层意义：透明度成竞争力
中国的大模型公司往往在成本上讳莫如深，但小米反其道而行之——公开训练看板。Jina AI创始人Han Xiao对此评价：“应该把这张动图发给CFO。”来源
公开直播训练过程的战略价值在于：
- 建立信任：用实时数据证明“钱确实花在了训练上”，而非营销噱头。
- 生态吸引：开源细节 + 透明训练，能吸引研究者加入，形成社区正循环。
- 设定基准：向外界清楚展示Agent RL的计算量级，推动行业对“算力-能力”曲线的讨论。
但正如腾讯科技的冷静分析：训练阶段增加投入，只有在模型交付后提高成功率、缩短任务流程或减少人工接管，才可能转化为商业价值。每小时3万美元最终换来什么，需要由模型上线后的任务完成质量和成本来回答。来源
08 RL训练成本的时间演化曲线与规模效应
8.1 token与训练成本如何随训练推进增长
本文第七张ASCII图刻画RL训练成本随训练时间演化的规律：
训练成本/Token 随训练时间演化(概念示意)
$
│ ┌────────┐
│ ┌────│ ~3.1万│$/h 稳态
│ ┌────┤ │ /h │
│ ┌────┤ │ └────────┘
│ ┌────┤ │ │ (达到阈值, 维持)
│ ┌─────┤ │ │ └───────────
│ ┌──────┤ │ │ │ (故障重启造成的小回撤)
│ ───┤ │ │ │ │
│ └─爬坡─┴─────┴─────┴────┴───────────────────► 训练时长(h)
│ 初始资源分配 渐入稳态 达阈值/u
│ (MFU上升) (高利用率) (RL扩展边际)
└─────────────────────────────────────────────────────►
阶段1: 利用率爬坡(成本占比上升但效率也升)
阶段2: 稳态高烧(每小时约3.1万美元)
阶段3: 边际收益递减点 → 决定"该不该继续烧"
8.2 用代码求解“盈亏平衡”——继续烧还是停？
任何RL训练团队都面临一个现实问题：奖励曲线的增长何时会趋于平缓，从而不值得再投入。下面这个Python模型模拟“继续训练一个step的边际收益”：
import math
def marginal_benefit(current_reward=0.582, step_cost=234077.0,
benefit_per_reward=800000.0, decay=0.90):
"""估算继续训练一个step的边际性价比"""
# 模拟: 每多训练一步, huggingface 奖励提升但边际递减
marginal_reward_gain = 0.004 * math.pow(decay, step_index) # 占位
monetized_gain = marginal_reward_gain * benefit_per_reward
roi = monetized_gain - step_cost
return roi
# 模拟多个step的奖励增长与ROI
step_index = 0
for step in range(1, 9):
gain = 0.004 * math.pow(0.82, step_index)
monetized = gain * 800000
roi = monetized - 234077
print(f"step+{step}: reward_gain={gain:.5f} monetized=${monetized:,.0f} "
f"cost=${234077:,} roi=${roi:,.0f}")
step_index += 1
示意输出：
step+1: reward_gain=0.00400 monetized=$3,200 cost=$234,077 roi=$-230,877
step+2: reward_gain=0.00328 monetized=$2,624 cost=$234,077 roi=$-231,453
step+3: reward_gain=0.00269 monetized=$2,151 cost=$234,077 roi=$-231,926
...
补充说明：这里的“monetized”是高度简化的占位换算，并不代表真实营收。它要说明的工程技术是——RL训练必须量化“奖励增益”与“单步成本”的关系，一旦边际收益低于单步成本，团队就需要在“追加算力”与“提前收敛”之间做出取舍。MiMo-V2.6每秒都在进行这种隐性的经济学决策。
09 架构与成本之外：用Go实现一个RL训练任务调度模拟器
为了让成本经济学落地到工程实践，我提供一个Go版本的GPU集群调度成本模拟器。它模拟如何在有限预算下，把RL训练的多任务负载（采样、执行、评判）调度到GPU集群，并统计每小时成本。
package main
import (
"fmt"
"sort"
"sync"
"time"
)
// Task 表示RL训练中的一个负载单元（采样/执行/评判）
type Task struct {
ID string
Kind string // "sample" | "execute" | "evaluate"
GPUUnits int // 占用的GPU卡数
Hours float64
}
// GPUNode 代表一个调度节点
type GPUNode struct {
GPU int
}
// Cluster 代表GPU集群
type Cluster struct {
mu sync.Mutex
nodes map[int]*GPUNode // free GPU 分布
}
func (c *Cluster) Schedule(t Task, rate float64, budget float64) (float64, bool) {
c.mu.Lock()
defer c.mu.Unlock()
free := 0
// 统计空闲卡
idle := 0
for _, n := range c.nodes {
if n.GPU > 0 {
idle += n.GPU
}
}
if idle < t.GPUUnits {
return 0, false // 资源不足
}
cost := t.Hours * float64(t.GPUUnits) * rate
if cost > budget {
return cost, false // 预算不足
}
// 分配
remaining := t.GPUUnits
free = 0
for _, n := range c.nodes { // 简单first-fit分配
if n.GPU >= remaining {
n.GPU -= remaining
remaining = 0
break
}
}
return cost, remaining == 0
}
func main() {
cluster := &Cluster{nodes: map[int]*GPUNode{}}
// 假设100台节点, 每台8卡H100
for i := 0; i < 100; i++ {
cluster.nodes[i] = &GPUNode{GPU: 8}
}
gpuRate := 2.1 // 美元/卡·小时
hourlyBudget := 31000.0 // 每小时约3.1万美元
tasks := []Task{
{"sample-1", "sample", 256, 0.5}, // 256卡跑0.5h
{"execute-1", "execute", 128, 1.0},
{"evaluate-1", "evaluate", 64, 0.8},
}
total := 0.0
for _, t := range tasks {
cost, ok := cluster.Schedule(t, gpuRate, hourlyBudget-total)
if !ok {
fmt.Printf("[%s] 拒单: 资源/预算不足 (需$%.0f)\n", t.ID, cost)
continue
}
total += cost
fmt.Printf("[%s] %5s 占%d卡 %.1fh 成本$%.2f\n",
t.ID, t.Kind, t.GPUUnits, t.Hours, cost)
}
fmt.Printf("本批合计成本: $%.2f (预算$%.0f)\n", total, hourlyBudget)
}
运行示意：
[sample-1] sample 占256卡 0.5h 成本$268.80
[execute-1] execute 占128卡 1.0h 成本$268.80
[evaluate-1] evaluate 占64卡 0.8h 成本$107.52
本批合计成本: $645.12 (预算$31000)
这个模拟器揭示了工程层面的成本控制手段：通过合理的任务分片、按优先级分配卡数、在预算内动态排单，可以把每小时成本压在预设阈值内。当单次RL任务动辄占用256卡时，调度粒度与预算软约束直接影响整体训练账单。
10 中国算力与自研芯片的“降本主线”
在讨论每小时20万元的成本时，不能忽视中国大模型厂商正在通过自研芯片与高MFU工程压低这一数字。此前小米MiMo-V2-Pro主打推理效率，采用改进Hybrid Attention在保证推理效率的同时提升模型容量来源；而中国厂商也在规模化国产算力（如昇腾集群）。
这构成了完整的“降本三板斧”：
- 架构层面：混合注意力、KV缓存优化降低单位Token算力；
- 算法层面：GRPO类方法省Critic、提MFU；
- 工程层面：全异步调度、故障快速恢复、预算软约束。
小米这次直播，恰恰把“算法—架构—工程—经济”四者的耦合关系一次性展示给了行业。
10.5 RL Scaling Law：为什么“算力越多越聪明”不再免费
把这场直播放到更大的技术背景下看，其底层逻辑正是当前AI界热议的RL Scaling Law。与传统预训练“无监督压缩、数据驱动”不同，强化学习的规模效应依赖的是“正确性可验证的任务环境 + 充足的算力去探索 + 分辨度足够的奖励信号”。这三个条件在MiMo-V2.6上恰好全部加码：计算规模冲到单步20亿Token，任务环境覆盖视觉/代码/通用/聊天多类型，评判系统引入代理式组内信用分配。
正是这三者的组合，才让RL的“计算投入-能力提升”曲线保持陡峭——但也正因为验证与执行环节昂贵，RL的边际成本远高于预训练。这也是为什么MiMo-V2.6要同时兼顾三个方向，而非单一堆算力：如果环境单一，算力再多也只是重复探索；如果奖励无分辨度，样本再多也学不到有效策略。三者中任何一环成为瓶颈，每小时几十万的成本都无法换来同等的智能增益。
从这个角度理解，罗福莉那句“RL到底可以走多远”，实际上是在追问：当验证、执行与奖励都极其昂贵时，RL的规模红利能维持多久、又在什么节点开始递减？MiMo-V2.6正站在这个曲线的陡峭段上，用真金白银去丈量RL Scaling Law的真实边界。
11 展望：MiMo-V2.6将走向何处
罗福莉反复强调“RL到底可以走多远”，并在未来几周逐步开源技术细节来源。对行业而言，这场直播的意义不仅是“小米很能烧钱”，更在于：
- 首次把顶级Agent RL的工程量级透明化——从黑盒试错走向流程开源；
- 为“算力-能力-成本”三者的权衡提供公共基准；
- 让“训练成本公开”本身成为品牌与生态的竞争资产。
对开发者与观察者而言，接下来最值得追踪的三个关系是（据爱范儿来源）：计算投入与能力提升的关系、执行长度与任务效果的关系、环境多样性与模型适应能力的关系。随着训练曲线延伸，“强化学习能扩展多远”这一问题终将得到更清晰的回答。
每小时20万人民币换来的，究竟是什么？ 小米给出的答案，或许就藏在那条波动上行、但整体爬升的奖励曲线里——以及它最终交付给用户的Agent产品到底能把多少训练投入转化为真实的成功率与商业价值。
小结
本文从经济学与系统工程的视角，对小米MiMo-V2.6强化学习训练成本公开直播进行了深度解析：每小时约3.1万美元（折合人民币超20万元）的烧钱速度背后，是采样、执行与评判三段式的高强度计算循环；单个训练step可达数十万美元量级；RL方法与算法选择（如GRPO）可带来20%以上的成本优化；而公开直播本身，则是小米以透明度换取信任与生态的战略动作。训练成本终将回归到“模型上线后能否把投入转化为成功率”这一朴素而根本的问题上。
注：本文部分成本占比与单位换算依据公开费用速率与工程量级的合理估算，具体以小米官方最终披露为准。文中数据综合自36氪来源、爱范儿/腾讯来源、AIbase来源、腾讯科技来源报道。