MiniMax-M1: Scaling Test-Time Compute Efficiently with Lightning Attention

1 · 动机:为什么 reasoning 模型必须换 attention

1.1 历史脉络:test-time compute 这条新 scaling 维

2024 年下半年起,LLM 社区出现了两条并行的 scaling 路线:

• 训练时 scaling(老路): 更多参数 + 更多数据,以 Chinchilla 律为标。
• 推理时 scaling(新路): 让模型在生成阶段"多想几步",以 CoT / reflection / search 为标。代表作 OpenAI o1, DeepSeek-R1, Kimi-1.5, Seed-Thinking-v1.5, QwQ。

新路的特征是 response 长度爆炸: 一个 AIME 题的 reasoning trace 从 ~500 tokens 涨到 20,000–100,000 tokens。论文中列的实测:在 RL 训练里 AIME 平均 response 从 12K 涨到 22K 仍未饱和,LiveCodeBench 同样冲到 22K。

1.2 别的方案为什么"够呛"

"减少 long-CoT 计算"这个目标可以从多个角度切:

论文的"立场"很清楚: 已经有一个 1M-context 的 hybrid base (MiniMax-Text-01) 可用,RL 派生 reasoning 版本就是顺势而为。但顺势而为不等于平凡——下一节展开。

1.3 但为什么"hybrid + RL"非平凡?

Inference 时 hybrid lightning 已经被 MiniMax-Text-01 跑通了,但 RL post-training 是另一码事:

• Linear attention 的训练 / 推理 kernel 必须严格一致 — 任何精度漂移都直接破坏 RL 的 importance sampling 修正,使 reward 不增。在 dense softmax 模型上没出现的"LM head 高幅激活 → FP16 溢出"问题在 hybrid 上凸显。
• Long-CoT 的 token-level loss 与 GRPO clipping 撞车 — reasoning 关键词("Wait", "However", "Recheck")在 base 上概率本来就低,IS ratio 自然大,被 PPO/GRPO 的 clip 一刀砍掉,等于掐死了反思能力的萌芽。
• 不同 lightning 层的 decay rate 不同 → 浅层学局部、深层学远端 — context 从 32K 一步扩到 1M 会造成"早期层跟不上后期层"的 gradient explosion。
• RL 出 80K 长度 = 一条 trajectory 拖慢整批 rollout — 每个 rollout step 受最长 trace 拖累。Pattern collapse / 重复 token 的早期检测变成 systems 必修课。
• 负样本越长越多 — RL 训练里 generation 一旦顶到 80K 上限,负 advantage 在尾部累积,token-level loss 让尾部 gradient 失衡,模型生成质量崩溃。

2 · 背景速查

2.1 关键术语

2.2 PPO / GRPO 的 token-clipping 复习

关键点:这个 min/clip 一旦触发,就把整个 token的梯度置零(乘以0)。当 base model 对某个反思 token 概率极低,θ_new 想把概率从 0.001 抬到 0.05 时 r=50,远超 1+ε(典型 0.2),clip 之后这个 token 不再贡献梯度——RL 永远学不会用这个词。

2.3 GRPO 的 group advantage

每个 prompt 采 G(e.g. 16)条 response,advantage = 自己的 reward 在组内的 z-score。优点: 不需要 value model;缺点: 当某个 prompt 里所有 response 都对/都错时 std=0, 退化。

3 · Hybrid Lightning Attention 架构

3.1 拼接配方:每 7 个 lightning + 1 个 softmax

具体一点:推理 100K context 时,FLOPs 怎么走?

设 d=4096(typical),L=100,000:

• 纯 softmax (R1): attention FLOPs ∝ L² · d ≈ 10¹⁰ · 4096 ≈ 4 × 10¹³ per layer
• Lightning: ∝ L · d² ≈ 10⁵ · 1.7×10⁷ ≈ 1.7 × 10¹² per layer (慢约 ~1/24)
• Hybrid M1 (7:1): 总 attention FLOPs ≈ 7/8 × lightning + 1/8 × softmax ≈ 主导项是 softmax 那 1/8
• 归一化后,M1 vs R1 的整体 attention 计算量约是 1/8 + 小项 ≈ 论文报告的 25%(还包含 MLP 等不变项)

3.2 为什么这样设计 (反向论证)

"全 lightning 行不行?" — 不行。早期 linear attention(RWKV、Performer)在 needle-in-haystack 类 long-range recall 任务上明显不如 softmax。Hybrid 把 1/8 的层"还给" softmax 是用 1/8 的 long-range 精度换 7/8 的速度。

"为什么是 7:1 而不是 3:1 或 15:1?" — 论文(其实是 base 的 MiniMax-01)的实验结果。比例越高越快但 recall 越差,7:1 是 sweet spot。

4 · CISPO 算法: clip IS-weight, 不要 clip token

4.1 问题: GRPO 在 hybrid 上为什么"扼杀反思"

RL 想让模型学会用 "Wait", "However", "Recheck" 这类反思 token——它们在 reasoning trace 里是"思路 fork"的标志。问题是:

1. Base model (continual pretraining 后) 对 "Wait" 这种 token 概率往往是 1e-4 数量级
2. 采样得到的 trajectory 里,新 policy 对 "Wait" 的概率可能升到 0.01,r = 0.01/1e-4 = 100
3. PPO/GRPO 的 clip(r, 0.8, 1.2) 立刻把这个 token 的梯度置零
4. 下一轮 off-policy update(论文用 16 轮),这个 token 仍然不学 → 反思能力永远涨不起来

这在 dense + softmax 模型上影响小,但在 hybrid 架构上特别明显——论文给出的解释:hybrid 模型 base 阶段的 token 概率分布更"尖",低概率反思词更稀缺。

4.2 CISPO 的设计:把 clip 从 token 上挪到 IS-weight

4.3 公式

区别 PPO 公式的三处:

1. 用 REINFORCE 形式而非 surrogate min/clip: 对 log π 直接求梯度,r̂ 只作系数
2. 对 r̂ 套 stop-gradient: 防止 clip 边界处的梯度奇异
3. 论文实践中只设 ε_high,不设 ε_low(把 ε_low 设巨大让它名存实亡): 因为 reasoning RL 的关键是给低概率 token 抬升机会,而不是限制下降

没有 KL penalty,也没有 trust region 约束(与 DAPO 类似)。dynamic sampling 和 length penalty 来自 DAPO。

4.4 worked example: 一个 AIME 题的 RL update

设 prompt = "证明 √2 是无理数",采 G=16 条 response。其中第 7 条在中段出现 token "Wait" 启动反思,最终答对,reward=1。

1. group reward {R_i}: 大约 9 条对(R=1)、7 条错(R=0)
2. 第 7 条 advantage Â₇ = (1 − 0.56)/std ≈ +0.88
3. "Wait" token 上 base π_θold("Wait")=0.0008, π_θ_new("Wait")=0.04, 故 r=50
4. GRPO: clip(50, 0.8, 1.2)=1.2 → 与 r·Â=44 取 min → 取 1.2·Â=1.06,但因 Â>0 且 r>1+ε,trust-region 触发,梯度=0(GRPO 实际行为)
5. CISPO: r̂ = clip(50, _, 1.2) = 1.2,sg 后乘 Â=0.88,贡献到 ∇ log π → "Wait" 概率被推高

4.5 实测数据

论文 Figure 2 的 Qwen2.5-32B-base 控制实验:

"用 50% 步数追平 DAPO" — 这就是 abstract 里的 "2× speedup"。

5 · RL 工程坑及解

5.1 训练 / 推理 kernel 精度漂移 (FP32 LM head)

worked example: 假设某 token logit 在 LM head 输出 [4.2, 28.3, 5.1, ...]。FP16 的 max ≈ 65504,28.3 还在范围内但 softmax(exp(28.3))=2 × 10¹² 已超 FP16,导致 inference kernel 中数值溢出,training kernel(混精度通常对 logits 转 FP32)却没溢出 → 同一 token 两份概率分别是 0.94 和 0.78,r = 0.78/0.94 = 0.83 不再是 1.0,IS 修正彻底失效。

5.2 AdamW 参数

5.3 重复检测早停

简单 string match 抓不住"换词重复"。论文用 token 概率作为信号:连续 3000 个 token 都 prob > 0.99 → 立刻截断。直觉: 一旦掉进 repetition mode,模型对每个新 token 都极其确定(因为它在抄前面的)。这条规则同时保护稳定性和省 generation cost。

6 · 阶梯 length 扩展: 40K → 80K 的工程

6.1 为什么扩到 80K 比扩到 1M 难

RL 阶段每条 trajectory 都要"想完",window 上限决定了:(a)单条 rollout latency, (b) negative sample 在 window 边界的累积。Long-context base 训练只对 cross-entropy 负责,RL 还要对 reward + advantage 累积负责,而后者对长尾分布更敏感。这就是为什么 base 1M 已经没问题、但 RL 把 thinking budget 从 40K 推到 80K 还要小心翼翼。

6.2 Worked example: 一条会崩溃的 trajectory

1. Window=72K,prompt 是一个难数学题
2. Trace 写到 65K 还没解出来 → reward 几乎肯定 0(负 advantage)
3. token-level loss 把 65K 个 token 的负 gradient 平均累积
4. 而 positive trajectory 通常 25K 就结束了 — 短得多,梯度量级远小
5. Net effect: 模型尾部 25K–72K 段被超量负向更新,生成质量塌陷,出现 garbled 文本

三条解药:重复检测早停切掉胡乱长样本;sample-level normalization 让短/长 traj 权重对等;调小 grad clip 和 ε_high 进一步稳定。

7 · 数据 & curriculum: verifiable + non-verifiable 混合

7.1 Curriculum: verifiable 先,general 后

启动阶段只喂可验证任务 → 模型学会"严格 step-by-step"。中段开始混入 general → 学会"在不可验证场景里自适应"。这与 R1 的两阶段 RL 思路一致,但 M1 把这种过渡做得更平滑(动态加权)。

7.2 GenRM 长度偏好的在线监控

非可验证任务的最大坑:GenRM 喜欢长答案 → policy 学到的不是"想得好"而是"写得多"。论文:

• 预先离线减弱(数据多样性 / 对抗样本)— 不够
• RL 训练期间持续监控 length-vs-reward 关联 → 一旦发现"长且无质量提升",触发 GenRM 重训(recalibration)
• 同步开 reward shaping / value clipping / normalization 三件套兜底

8 · 关键 benchmark 结果解读

8.1 RL Scaling 曲线

论文 Figure 4 给出 4000 step 的训练轨迹:

• AIME 2024: 68% → 80%+,response 12K → 22K(都还在涨)
• AIME 2025: 50% → 78%,response 14K → 28K
• LiveCodeBench v5: 55% → 70%,response 14K → 22K

"response 长度和 accuracy 强相关"是论文最强的实证: 模型自己学会了"想得长 = 想得对",而 RL 只提供了 reward,没要求长度。这是 test-time compute scaling 思想在 RL 训练里的直接证据。

8.2 80K vs 40K

同一 base + 同一 RL recipe,只是 thinking budget 翻倍:

• AIME 2024: 83.3 → 86.0 (+2.7)
• AIME 2025: 74.6 → 76.9 (+2.3)
• LiveCodeBench: 62.3 → 65.0 (+2.7)
• ZebraLogic: 80.1 → 86.8 (+6.7) 长 logic 增益最大

边际收益不大但稳定,且每一项都是难任务上更明显。换言之:thinking budget 加倍,M1 把它实实在在地用了出来——这是 lightning attention 的"商业模式"在 ROI 层面成立的最终证明。

9 · 与同类 reasoning model 对比

9.1 与 R1-0528 的"角色对调"

R1-0528 走"短(32K input/64K output)+ 深"路线: 数学 / 编程极强,适合做 reasoning 引擎核。M1 走"长(1M/80K)+ 广"路线: 适合做 agent backbone(长记忆 + 工具调用)。这两类其实不是替代,是分工。

9.2 与 GPT-OSS / QwQ 的差异

GPT-OSS 和 QwQ 是"小一两个数量级"的 reasoning model(20B–32B 级别),适合 single-GPU。M1 是 frontier scale (456B total)——开源 reasoning 模型里目前的"上限"。架构上 M1 是唯一同时押注 hybrid linear + 大规模 RL 的开源工作。

10 · 局限 / 个人 take / 待验证问题

论文承认的局限

• 纯数学竞赛和 LiveCodeBench 仍输 R1-0528;dense recall 类任务上 hybrid 损失了一点点
• GenRM 长度偏好需要在线监控,工程复杂度不低
• Hybrid 架构的 kernel 兼容性 / FP16 精度问题需要专门修复(LM head 升 FP32),不像 dense softmax 那么"开箱即用"
• 456B / 45.9B 活跃参数对端侧不友好,产业界使用门槛高

我的疑问

1. CISPO 对 reasoning RL 的 advantage 在 dense softmax 模型上是否同样大? 论文只在 Qwen2.5-32B 上验证了一次。如果 dense 也有 2× speedup,那 CISPO 可能就是新的 RL 默认。
2. "Wait/However 等反思 token r 极大,被 clip 砍掉" — 这一现象的本质,究竟是 hybrid 架构特有,还是 base model 训练分布的副作用? 如果是后者,SFT 阶段加点反思样本可能就化解了。
3. 1M context 的 RL 训练实测效率论文未给。80K thinking budget 已经做到了,但 1M context 的 RL rollout 是否真的可承受? 抑或 1M 只是 inference 的能力,RL 训练只到 80K?
4. M1 的 lightning attention 在 RL rollout 中的内存优势如何量化? 论文主打 FLOPs 优势,但内存 (KV cache) 才是大模型 inference 的真正瓶颈。线性注意力的 state 是 d×d,与 L 无关,这在 80K trace 下应该是巨大的内存优势,但论文没强调。
5. SWE-bench 的 sandbox RL pipeline 实现细节论文偏少,但这部分是真正难复现的。开源时这部分代码会一起放吗?
6. $534K 的 RL 成本是否包括 base 的 continual pretraining (7.5T tokens)? 如果不算,总成本可能数倍于此,真实 ROI 需重新算。

记忆点

精读笔记 · 配套论文 PDF: /data/szhang967/papers/paper-notes/MiniMaxM1_2506.13585.pdf
See also: 02_MiniMax01_2501.08313.html (base 架构 / lightning attention 推导)