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

Paper: arXiv:2506.13585 Code: MiniMax-AI/MiniMax-M1 Code reference: main @ 2abb4f45 (2025-07-07)

1. Motivation (研究动机)

MiniMax-M1 要解决的是大推理模型在 test-time compute 继续放大时的两个耦合瓶颈：一是传统 softmax attention 的二次复杂度让长 CoT 输出变得昂贵，二是大规模 RL 训练在长输出、off-policy 多轮更新和混合注意力架构下容易失稳。OpenAI o1、DeepSeek-R1 等 Large Reasoning Models 证明了“生成时多想一会儿”可以提高复杂数学、代码和真实任务能力，但如果模型架构仍然主要依赖标准 Transformer attention，那么把输出从 32K 推到 80K、100K 甚至更长时，rollout 成本、延迟和显存压力会迅速成为 RL 与推理的主瓶颈。论文把这个问题定位为一个系统级 scaling 问题，而不是单独的算法改进：如果 attention 架构不支持低成本长序列，RL 算法再稳定也很难真正放大 test-time compute；如果 RL 算法会丢弃关键 token 或 reward 体系被长度偏置污染，低成本长序列也不会自然转化为更强推理。

论文的背景判断是：已有 sparse attention、linear attention、state-space model、linear RNN 等方向都声称能降低长上下文成本，但在“开源大规模 reasoning model + 大规模 RL + 真实复杂任务”的组合上还没有充分验证。Hunyuan-T1 被提到是少数非标准 attention 的 reasoning model 例外，但它没有开源且细节有限。因此 MiniMax-M1 的目标不是只报告一个高分模型，而是证明 hybrid-attention MoE 架构可以支撑 1M 输入上下文和 80K thinking budget，并且能在 512 H800、三周量级内完成完整 RL 训练。这一点很重要，因为大模型 agent 的真实工作负载往往同时需要长输入和长输出：软件工程任务需要读大量仓库上下文、定位 bug、尝试修复并解释；工具使用任务需要在多轮状态与 API 约束之间反复推理；长上下文问答需要在相似证据之间做检索和消歧。单纯在短题目上扩大 CoT 长度不足以覆盖这些场景。

MiniMax-M1 的研究动机还来自 RL 训练中的一个更细粒度问题：PPO/GRPO 里的 token-level clipping 在长 CoT 中会误伤“低概率但高价值”的反思 token。论文列举的 However、Recheck、Wait、Aha 这类 token 往往是推理路径分叉点，base model 初始概率低，RL 更新时 importance sampling ratio 容易很大。传统 clipped objective 会在第一次 on-policy 更新之后把这些 token 的梯度贡献裁掉，导致后续 off-policy minibatch 更新不能继续强化这些反思行为。对于长 CoT，这不是局部小问题：越长的回答越依赖中途重检、改写假设和回退错误路径，丢掉这些 token 会让模型更难自发形成长程 reasoning pattern。

另一个动机是 reward 与 data 的现实性。只用数学和竞赛编程做 rule-based RL 可以形成可验证奖励，但不足以覆盖 agentic tool use、software engineering、long-context understanding、一般 QA/写作等更开放场景；而用 generative reward model 做开放任务又会带来 length bias，容易把“更长”误判成“更好”。MiniMax-M1 因此把模型、算法、数据、reward monitor、训练 curriculum、长输出扩展策略放到同一个框架下讨论。它的核心问题可以概括为：如何在不让计算成本和训练不稳定性爆炸的前提下，把 test-time compute 从单纯的短题 CoT 扩展到 1M 输入、80K 输出和真实 agent 任务。

Figure 1 解读：左侧汇总了 MiniMax-M1-80k 与闭源、开权重模型在数学、编码、软件工程、工具使用、长上下文等任务上的总体对比；右侧给出生成长度增加时的理论 inference FLOPs scaling。论文想表达的重点不是 MiniMax-M1 在所有竞赛任务都第一，而是它在长上下文和真实 agent 场景上更能体现 hybrid attention 的边际价值：当 generation length 接近 64K 或 100K 时，M1 相对 DeepSeek-R1 的计算消耗显著下降，使“更长 thinking budget”不再只是昂贵宣传点。

2. Idea (核心思想)

MiniMax-M1 的核心新意是把 test-time scaling 拆成三层协同：第一层是 hybrid MoE + Lightning Attention 架构，用线性注意力为主、周期性 softmax attention 校正的方式降低长序列成本；第二层是 CISPO，把 PPO/GRPO 的 token update clipping 改成 importance sampling weight clipping，从而保留所有 token 的梯度路径；第三层是面向 40K 到 80K 输出的 RL 工程 recipe，包括 FP32 LM head、AdamW 超参、重复检测早停、data curriculum 和 GenRM length-bias 在线监控。论文真正想证明的是：长推理能力不是“给模型更大 max tokens”就会出现，而是需要架构效率、RL objective 和训练数据/奖励系统共同支持。

在模型架构上，MiniMax-M1 基于 MiniMax-Text-01，论文报告总参数 456B、每 token 激活 45.9B、32 experts。注意力设计是“每 7 个 transnormer blocks with Lightning Attention 后接 1 个 softmax attention Transformer block”。released code 的 config.json 对应 80 层、hidden size 6144、64 attention heads、8 KV heads、32 local experts、top-2 experts；attn_type_list 中每 8 层的第 8 层为 full attention，其余为 linear/lightning attention，这与论文“七个 lightning 后一个 softmax”的描述一致。这个设计的直觉是：大部分层用 near-linear 的 Lightning Attention 承担长序列状态传播，降低 rollout 与 inference 的边际成本；少量 full attention 层保留全局交互能力，避免纯线性注意力在复杂推理中表达不足。

在 RL 算法上，CISPO 的关键不是简单调大 clipping range，而是重新选择“裁哪里”。PPO/GRPO 的 clipped surrogate 会根据 advantage 符号和 ratio 大小把某些 token 的更新直接 mask 掉；CISPO 则把 ratio 先裁成 $\overset{r}{^}_{i, t}$ ，再把它作为 stop-gradient 权重乘在 token log-prob 上。这样大 ratio token 的梯度幅度被限制，但 token 本身不会从 loss 中消失。对长 CoT 来说，这意味着罕见但关键的反思 token 仍可在多轮 off-policy 更新里持续贡献梯度。论文将这个策略解释为牺牲一点 bias 来换取更低 variance 和更稳定的长回答训练。

第三层 idea 是把“可扩展 RL”看成数据与 reward 的 curriculum。MiniMax-M1 先用 rule-verifiable tasks 稳住数学、逻辑、代码和软件工程能力，再逐步混入需要 reward model 的一般任务。对于无法规则验证的开放任务，论文不把 GenRM 当作静态打分器，而是在线监控 length bias：如果策略开始通过拉长输出骗取高分，就触发 reward model recalibration，并配合 reward shaping、value clipping、normalization 降低长度表面特征的影响。对于 80K thinking budget，论文也没有一步到位，而是从 40K 分阶段扩展到 48K、56K、64K、72K、80K，用生成序列 perplexity 收敛和输出长度 99 分位接近窗口上限作为切换信号。

因此这篇论文的 insight 可以浓缩为三句话：长推理 scaling 的瓶颈主要在 rollout 成本与训练稳定性，而不是只在模型分数；hybrid Lightning Attention 让长序列 RL 在算力上可行，CISPO 让长 CoT token 在优化上不被过早裁掉；真正可用的 80K reasoning model 还需要围绕 precision、optimizer、repetition、reward bias 和 curriculum 做系统工程。

3. Method (方法)

3.1 架构：Hybrid MoE + Lightning Attention

MiniMax-M1 继承 MiniMax-Text-01 的 MoE 基础，并把长上下文能力作为 RL scaling 的前置条件。论文报告模型总参数为 456B，每 token 激活 45.9B，包含 32 experts；released config.json 展示了 80 层、32 local experts、num_experts_per_tok=2 的 top-2 routing。modeling_minimax_m1.py 中 MiniMaxM1Model.__init__ 会读取 attn_type_list，当该层标记为 0 时使用 linear_attention 并设置 attention_type=0，否则使用 full attention；默认配置的列表模式是 7 个 0 后跟 1 个 1，重复 10 次。这个实现层面证实了论文中的 hybrid attention pattern：大多数层采用 Lightning Attention，周期性插入 full attention。

这类架构为什么有助于 test-time scaling？在传统 softmax attention 中，生成第 $t$ 个 token 时需要与过去 token 的 KV cache 交互，训练/推理成本随长度明显增长；Lightning Attention 属于 linear attention 变体，目标是在长序列上让状态更新更接近线性。论文给出的经验数字是：相对 DeepSeek R1，M1 在 64K generation length 时 FLOPs 少于 50%，在 100K 时约为 25%。这使得 40K、80K 输出不只是 API limit，而是在 RL rollout 中也更可承受。released code 还在 MiniMaxM1ForCausalLM.forward 中对 lm_head(hidden_states) 的输出执行 logits.float()，与论文在 RL 训练中强调 LM output head 使用 FP32 解决 precision mismatch 的工程经验一致，但 released repo 没有训练 kernel 与 rollout 代码，不能进一步验证完整训练路径。

3.2 预训练与 SFT：先让 base model 适合 RL

论文没有直接从 MiniMax-Text-01 进入 RL，而是先做 continual pretraining 和 cold-start SFT。continual pretraining 使用额外 7.5T tokens，目标是增强 reasoning 和 long-context 能力，同时保持数据多样性。数据侧改进包括 Web/PDF parsing、启发式清洗、从网页/论坛/教材抽取自然 QA 对、避免 synthetic data、对 QA 数据做 semantic dedup，并把 STEM、code、book、reasoning 相关数据比例提高到 70%。训练 recipe 方面，论文降低 MoE auxiliary loss 系数，调整并行训练策略以支持更大 micro batch size；学习率先以 $8 \times 1 0^{- 5}$ 常数训练 2.5T tokens，再在 5T tokens 上 decay 到 $8 \times 1 0^{- 6}$ 。

长上下文扩展也在预训练阶段处理。论文指出 hybrid-lightning 架构的收敛更复杂，过激地增加训练长度会导致 sudden gradient explosion。作者把原因归因于早期层和后期层的参数优化节奏不同：Lightning Attention 中早晚层 decay rates 不同，早期层更偏向 local information，当上下文长度扩展太快时，早层无法跟上后层变化。解决方式是更平滑地分四阶段扩展 context window，从 32K 逐步到 1M tokens。SFT 阶段则用高质量 long CoT 样本注入 reflection-style reasoning，覆盖 math、coding、STEM、writing、QA、multi-turn chat，其中 math 和 coding 约占 60%。这一阶段的功能不是追求最终分数，而是为 RL 提供更稳定的初始策略和 CoT 行为先验。

3.3 CISPO：从裁 token update 改为裁 IS weight

论文先回顾 PPO/GRPO 的基本形式。对问题 $q \sim D$ 、旧策略采样回答 $o_{i} \sim π_{θ_{old}} (\cdot ∣ q)$ ，token-level ratio 为： $r_{i, t} (θ) = \frac{π _{θ} ( o _{i, t} ∣ q , o _{i, < t} )}{π _{θ_{old}} ( o _{i, t} ∣ q , o _{i, < t} )} .$ GRPO 不用 value model，而用同一问题下 $G$ 个回答的相对 reward 标准化 advantage： $\hat{A}_{i, t} = \frac{R _{i} - mean ({ R _{j} } _{j = 1}^{G} )}{std ({ R _{j} } _{j = 1}^{G} )} .$ PPO/GRPO 的问题在于 clipped surrogate 会把 ratio 超出 trust region 的 token update 置为无效，特别是正 advantage 且 $r_{i, t} > 1 + ϵ_{high}$ 的罕见反思 token。CISPO 先写出带 corrected distribution 的 REINFORCE 形式： $J_{REINFORCE} (θ) = E [\frac{1}{∣ o _{i} ∣} \sum_{t = 1}^{∣ o_{i} ∣} sg (r_{i, t} (θ)) \hat{A}_{i, t} lo g π_{θ} (o_{i, t} ∣ q, o_{i, < t})] .$ 然后 CISPO 只裁剪 IS weight： $\overset{r}{^}_{i, t} (θ) = clip (r_{i, t} (θ), 1 - ϵ_{l o w}^{I S}, 1 + ϵ_{hi g h}^{I S}),$ 并优化： $J_{CISPO} (θ) = E [\frac{1}{\sum _{i = 1}^{G} ∣ o _{i} ∣} \sum_{i = 1}^{G} \sum_{t = 1}^{∣ o_{i} ∣} sg (\overset{r}{^}_{i, t} (θ)) \hat{A}_{i, t} lo g π_{θ} (o_{i, t} ∣ q, o_{i, < t})] .$ 论文实验中没有对 IS weight 施加下界，而是把 $ϵ_{l o w}^{I S}$ 设得很大，只调 $ϵ_{hi g h}^{I S}$ ；同时沿用 DAPO 的 dynamic sampling 和 length penalty，不加 KL penalty。CISPO 梯度因为 weight clipping 会有轻微 bias，但所有 token 都保留在梯度计算中，尤其适合长回答。论文还给出一个 unified objective，通过 $M_{i, t}$ mask 统一表示不同 clipping 策略；CISPO 可理解为 $M_{i, t} = 1$ 的特例，而 PPO/GRPO 的 trust region clipping 则隐式定义了会丢 token 的 mask。

Figure 3 解读：该消融在 Qwen2.5-32B-base 上比较 GRPO、DAPO 和 CISPO，评估 AIME 2024。论文强调 CISPO 在相同训练步数下优于 GRPO/DAPO，并且用约 50% 的训练步数达到 DAPO 类似效果。这个结果是方法动机的直接证据：不是简单“调 clipping bound”，而是避免 clipping 掉长 CoT 中稀有但有用的 token。

3.4 Hybrid attention RL 的工程 recipe

论文最有价值的部分之一是承认 hybrid architecture 在大规模 RL 中有额外坑。第一是 generation 和 training 的 computational precision mismatch。作者在 rollout token 的训练模式概率与推理模式概率之间观察到明显差异，导致 reward 不能增长；layer-by-layer 分析定位到 LM head 输出层的 high-magnitude activations。解决方式是把 LM output head 提升到 FP32，使训练/推理 token probability 的相关性从约 0.9x 提高到 0.99x，并且该 correlation 在训练中保持稳定。

Figure 4 解读：左右两图分别展示修复前后 training-mode 与 inference-mode token probability 的散点相关性。理论上二者应该落在对角线附近；修复前偏离说明 rollout 中看到的概率与训练 loss 中使用的概率不一致，RL 更新会朝错误方向优化。FP32 LM head 修复后相关性接近 0.99x，说明这个问题不是 reward 本身错，而是数值路径不一致。

第二是 optimizer hyperparameter sensitivity。论文使用 AdamW，并指出 VeRL 默认的 betas=(0.9, 0.999)、eps=1e-8 在 M1 训练中可能 non-convergence。MiniMax-M1 的梯度幅度跨度从 1e-18 到 1e-5，多数小于 1e-14，且相邻 iteration 梯度 correlation 弱。因此作者设置 $β_{1} = 0.9$ 、 $β_{2} = 0.95$ 、eps=1e-15。第三是复杂 prompt 会诱发 pathologically long and repetitive responses，长重复回答的大梯度会威胁稳定性。作者没有等生成完再惩罚重复，而是实现 early truncation：如果连续 3000 个 token 的概率都高于 0.99，就停止生成，以避免重复循环消耗窗口并提升 throughput。

3.5 RL data、reward 与 80K thinking 扩展

RL 数据分为 rule-verifiable 和 model-feedback 两大类。rule-based 部分对所有任务使用 final correctness reward 加 format reward。数学数据来自公开和官方竞赛题，经过不完整样本/格式错误过滤、embedding-based dedup、与 SFT 数据严格隔离、benchmark contamination 去除、去掉多子题/证明题/二元猜测题，并把选择题改为开放题；最后用强 reasoning model 计算 pass@10，只保留 pass rate 在 0 到 0.9 之间的样本，形成 nearly 50K 数学 RL 样本。

逻辑推理部分选择 41 个非平凡任务，用 SynLogic 生成数据和 verifier，难度上界要求强模型 pass@10 大于 0，下界要求 MiniMax-Text-01 pass rate 在 0 到 0.5 之间，得到约 53K 样本。竞赛编程收集 online judge 和 coding websites，对缺测试的问题用 MiniMax-Text-01 生成测试套件，最后得到 30K 样本。软件工程数据来自公开 GitHub issues/PRs，构造 containerized sandbox，以测试通过/失败、编译错误、runtime failure、regression 作为 reward，样本量为 several thousand。

一般任务使用 25K complex samples。带 ground truth 但难以规则验证的 STEM/factual problems 使用 GenRM 作为 verifier，并用 human-annotated reward benchmark、Best-of-N 与 pass@N gap 来调数据分布和 prompt。无 ground truth 的 instruction-following、creative writing 等任务用 pairwise comparison，分数为 -1、0、1；训练前通过多盲一致性、position-switched 一致性等方式减少 preference bias，再用 Swiss Round scoring 选参考答案。由于 GenRM 容易偏好更长 CoT，论文在线监控 length bias，一旦发现策略通过拉长输出来最大化 GenRM reward 且 task success/reasoning depth 没有提升，就触发 reward recalibration，并配合 reward shaping、value clipping、normalization。

80K thinking 扩展从已训练的 40K 模型出发。作者先评估 curated dataset 的 pass rates，移除容易样本，增加困难 math/code 样本，并下采样 synthetic reasoning data，因为这类数据在长上下文 RL 中会产生重复和同质化输出。长度扩展采用 staged window expansion：40K $\to$ 48K $\to$ 56K $\to$ 64K $\to$ 72K $\to$ 80K；切换依据包括生成序列 perplexity 是否收敛，以及输出长度 99th percentile 是否接近当前窗口上限。后期每个 window 还会出现 pattern collapse：负样本长度比正样本增长更快，更早触及窗口上限，导致后段 token 累积过大的 negative gradients。对应解法是重复高概率 token 早停、组合 sample-level loss 与 token-level normalization、降低 gradient clipping threshold 和 $ϵ_{hi g h}^{I S}$ 。

3.6 Released code 对应关系与缺口

Code reference: main @ 2abb4f45 (2025-07-07) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
MiniMax-M1 Hugging Face config	`config.json`, `configuration_minimax_m1.py`	`MiniMaxM1Config`; release config: 80 layers, 6144 hidden size, 32 experts, top-2 routing
Hybrid attention pattern	`modeling_minimax_m1.py`	`MiniMaxM1Model.__init__`; reads `attn_type_list`, uses `linear_attention` for 0 and full attention for 1
Lightning attention module	`modeling_minimax_m1.py`	`MiniMaxM1LightningAttention.forward`, `MiniMaxM1LightningAttention.inference`
Sparse MoE routing	`modeling_minimax_m1.py`	`MiniMaxM1SparseMoeBlock.forward`; gate logits, softmax routing weights, selected experts
FP32 logits / LM head output	`modeling_minimax_m1.py`	`MiniMaxM1ForCausalLM.forward`; `logits = self.lm_head(hidden_states)` then `logits.float()`
Inference demo / deployment	`main.py`, `docs/vllm_deployment_guide.md`, `docs/transformers_deployment_guide.md`	sample loading, device map, vLLM/Transformers serving instructions
Model release and recommended decoding	`README.md`	MiniMax-M1-40k/80k Hugging Face links; temperature 1.0, top_p 0.95

Released GitHub repo 包含模型定义、tokenizer/config、模型索引、README、deployment docs 和 function-calling docs，但没有公开 CISPO 训练实现、RL rollout pipeline、reward model、data construction scripts、训练 launch scripts 或 optimizer config 文件。因此训练数据规模、学习率、AdamW betas/eps、窗口扩展策略、512 H800 三周训练成本等数字来自论文正文，而不是 released training config。论文公式与 released code 实现差异：CISPO、GenRM bias monitor、sandbox RL 和 80K window expansion 在当前 release 中没有对应训练代码可核验；released code 只能验证 inference/modeling 层的 hybrid attention、MoE routing 和 logits FP32 cast。

Released inference forward 的结构可以抽象为：

def minimax_m1_forward(input_ids, attention_mask, output_router_logits=False):
    hidden_states = embed_tokens(input_ids)
    router_logits_all = []
    for i, layer in enumerate(layers):
        if attn_type_list[i] == 0:
            attn = MiniMaxM1LightningAttention
        else:
            attn = full_attention_impl
        hidden_states = attn_norm_and_residual(hidden_states, attention_mask)
        moe_hidden, router_logits = sparse_top2_moe(hidden_states)
        hidden_states = mlp_norm_and_residual(moe_hidden)
        if output_router_logits:
            router_logits_all.append(router_logits)
    hidden_states = final_rms_norm(hidden_states)
    logits = lm_head(hidden_states).float()
    return logits, router_logits_all

Paper-derived CISPO training loop 则可写为：

for batch in prompts:
    responses = old_policy.sample_group(batch, G, max_tokens=current_window)
    rewards = verifier_or_genrm(responses)
    advantages = group_relative_normalize(rewards)
    for minibatch in off_policy_updates(responses):
        ratio = policy.prob(minibatch.tokens) / old_policy.prob(minibatch.tokens)
        clipped_is = clip(ratio, 1 - eps_low_is, 1 + eps_high_is)
        loss = -mean(stop_gradient(clipped_is) * advantages * logprob(policy, minibatch.tokens))
        update(policy, loss)

这个伪代码只描述论文目标函数，不代表 GitHub release 中存在训练实现。

4. Experimental Setup (实验设置)

模型与训练流程分为四个主要阶段。第一阶段是基于 MiniMax-Text-01 的 continual pretraining：额外 7.5T tokens，数据质量和 mixture 专门向 reasoning/long-context 倾斜，STEM、code、book、reasoning 相关数据占比提高到 70%；学习率以 $8 \times 1 0^{- 5}$ 常数训练 2.5T tokens，再在 5T tokens 上 decay 到 $8 \times 1 0^{- 6}$ ；上下文训练长度从 32K 平滑扩展到 1M。第二阶段是 cold-start SFT：long CoT 样本覆盖 math、coding、STEM、writing、QA、multi-turn chat，math/coding 约 60%。第三阶段是 40K RL：使用 CISPO，在 reasoning-intensive tasks 与 general-domain tasks 上按 curriculum 训练。第四阶段是 80K RL：从 40K 模型出发，过滤过易样本，增加困难数学/代码，减少 synthetic reasoning data，并按 40K、48K、56K、64K、72K、80K 扩展输出窗口。

RL 数据集包含明确的 scale 信息。数学 RL 样本 nearly 50K，逻辑推理样本约 53K，竞赛编程样本 30K，软件工程样本 several thousand，一般 GenRM 任务 25K。rule-verifiable tasks 使用 final correctness reward 和 format reward；数学与逻辑任务依赖 answer checker/verifier；编程任务依赖测试用例；软件工程任务在 containerized sandbox 中执行代码，以 tests pass/fail 和编译/运行错误作为 reward。model-feedback tasks 使用 GenRM 或 pairwise comparison，其中 instruction-following 还结合 rule-based constraint reward 与 model-based quality reward。

优化和稳定性设置中，论文明确报告了若干不是默认值的关键 recipe。AdamW 使用 $β_{1} = 0.9$ 、 $β_{2} = 0.95$ 、eps=1e-15，而不是 VeRL 默认 betas=(0.9, 0.999)、eps=1e-8；LM output head 使用 FP32 以修复训练/推理概率 mismatch；early truncation 规则是在 3000 个连续 token 的 probability 都超过 0.99 时停止生成；80K 扩展后期降低 gradient clipping threshold 和 $ϵ_{hi g h}^{I S}$ 。完整 RL training 使用 512 H800 GPUs，三周完成，论文给出的 rental cost 是 $534,700。

评估覆盖数学、一般代码、软件工程、reasoning & knowledge、long context、agentic tool use、factuality、general assistant 八类。所有任务使用 temperature 1.0、top-p 0.95 sampling。AIME 2024/2025 采样 32 次并报告平均 passrate；LiveCodeBench 和 FullStackBench 报告 16 samples 平均 passrate；GPQA-Diamond 采样 32 次；HLE 不使用 external tools；SWE-bench Verified 使用 Agentless scaffold，并改为两阶段 localization：先粗粒度文件定位，再细粒度定位到具体文件和代码元素，不使用 embedding-based retrieval；OpenAI-MRCR 测试长上下文中多个相似 item 的检索和消歧，LongBench-v2 包含 503 个多选问题且上下文从 8K 到 2M words；TAU-bench 使用 GPT-4.1 作为 user model、通用 system prompt、无 custom tools，最大交互步数 40。

对比基线包括闭源 OpenAI-o3、Gemini 2.5 Pro (06-05)、Claude 4 Opus、Seed-Thinking-v1.5，以及开权重 DeepSeek-R1、DeepSeek-R1-0528、Qwen3-235B-A22B。表 1 还比较了最大输入/输出长度：OpenAI-o3 为 200K input / 100K output，Gemini 2.5 Pro 为 1M / 64K，Claude 4 Opus 为 200K / 32K，DeepSeek-R1-0528 为 128K / 64K，Qwen3-235B 为 128K / 32K，MiniMax-M1-80k 为 1M / 80K。这个设置突出了 MiniMax-M1 的主要评估变量：它不只是比 benchmark accuracy，也比长输入和长输出同时可用时的任务能力。

5. Experimental Results (实验结果)

核心结果显示 MiniMax-M1-80k 在开权重模型中整体强，但不是所有学科竞赛任务第一。数学上，MiniMax-M1-80k 在 AIME 2024 为 86.0，AIME 2025 为 76.9，MATH-500 为 96.8；对应 MiniMax-M1-40k 分别是 83.3、74.6、96.0。它在 AIME 2024 高于 Qwen3-235B 的 85.7、原始 DeepSeek-R1 的 79.8，但低于 DeepSeek-R1-0528 的 91.4、OpenAI-o3 的 91.6 和 Gemini 2.5 Pro 的 92.0。AIME 2025 上 M1-80k 仍低于 Qwen3-235B 的 81.5 和 DeepSeek-R1-0528 的 87.5。这个结果说明 80K thinking budget 带来增益，但在纯竞赛数学上不是压倒性领先。

代码与软件工程任务更能体现论文方法。LiveCodeBench (24/8–25/5) 中 M1-80k 得到 65.0，M1-40k 为 62.3，接近 Qwen3-235B 的 65.9，但低于 DeepSeek-R1-0528 的 73.1 和 closed models。FullStackBench 中 M1-80k 为 68.3，M1-40k 为 67.6，高于 Qwen3-235B 的 62.9，接近 DeepSeek-R1-0528 的 69.4。SWE-bench Verified 中 M1-80k 为 56.0，M1-40k 为 55.6，略低于 DeepSeek-R1-0528 的 57.6，但明显高于原始 DeepSeek-R1 的 49.2 和 Qwen3-235B 的 34.4。论文把这一点归因于 execution-based software engineering RL environment：模型在真实 GitHub issue/PR、容器测试和 bug localization/code repair/test synthesis 场景中获得直接 reward，而不是只在短代码题上训练。

长上下文结果是 MiniMax-M1 最突出的部分。OpenAI-MRCR 128K 上，M1-80k 为 73.4，M1-40k 为 76.1，高于 OpenAI-o3 的 56.5、Claude 4 Opus 的 48.9、DeepSeek-R1-0528 的 51.5、Qwen3-235B 的 27.7，仅低于 Gemini 2.5 Pro 的 76.8。OpenAI-MRCR 1M 上，M1-80k 为 56.2，M1-40k 为 58.6，与 Gemini 2.5 Pro 的 58.8 接近，而多数对比模型没有 1M 结果。LongBench-v2 上，M1-80k 为 61.5，M1-40k 为 61.0，高于 OpenAI-o3 的 58.8、Claude 4 Opus 的 55.6、DeepSeek-R1-0528 的 52.1、Qwen3-235B 的 50.1，仅低于 Gemini 2.5 Pro 的 65.0。这个结果与架构动机一致：1M input context 不是摆设，在检索和消歧型 benchmark 上直接变成优势。

Agentic tool use 上，TAU-bench airline 中 M1-80k 为 62.0，M1-40k 为 60.0，高于 Gemini 2.5 Pro 的 50.0、OpenAI-o3 的 52.0、Claude 4 Opus 的 59.6、DeepSeek-R1-0528 的 53.5 和 Qwen3-235B 的 34.7。TAU-bench retail 中 M1-80k 为 63.5，低于 M1-40k 的 67.8、OpenAI-o3 的 73.9、Gemini 的 67.0、Claude 的 81.4，也略低于 DeepSeek-R1-0528 的 63.9，但高于 Qwen3-235B 的 58.6。论文正文更强调 airline 和整体 agentic tool-use 场景中 M1-40k/M1-80k 对开权重模型及 Gemini 的优势。这个现象说明更长 thinking budget 不总是单调提升所有工具任务，可能受任务 domain、交互策略和 reward curriculum 影响。

Reasoning & knowledge 类指标中，M1-80k 在 GPQA Diamond 为 70.0，HLE text-only 为 8.4，ZebraLogic 为 86.8，MMLU-Pro 为 81.1。ZebraLogic 明显高于 M1-40k 的 80.1、Qwen3-235B 的 80.3 和原始 DeepSeek-R1 的 78.7，但低于 DeepSeek-R1-0528/Claude 4 Opus 的 95.1。SimpleQA 上 M1-80k 只有 18.5，虽然高于 Qwen3-235B 的 11.0 和 Seed-Thinking-v1.5 的 12.9，但低于 DeepSeek-R1 的 30.1、DeepSeek-R1-0528 的 27.8、OpenAI-o3 的 49.4 和 Gemini 的 54.0。MultiChallenge 上两个 M1 模型都是 44.7，与 DeepSeek-R1-0528 的 45.0 接近，但低于 OpenAI-o3/Gemini。结论是：M1 的优势集中在长上下文、软件工程和部分工具任务；factuality 和一部分知识/竞赛任务仍有明显提升空间。

Figure 5 解读：AIME 2024、AIME 2025 和 LiveCodeBench v5 的训练曲线同时画出 accuracy 与 generation length。论文观察到训练过程中 performance 和 response length 一起上升，AIME 与 LiveCodeBench 平均响应长度超过 20,000 tokens，AIME 2024 accuracy 从约 68% 提升到 80%。这支持“test-time compute scaling 有效”的主张，但也提醒读者：性能提升和长度提升相关，不代表盲目拉长输出总是好；前文的 length-bias monitor、重复早停和窗口 staged expansion 都是为了避免长度成为 reward hacking 的工具。

论文的主要局限也很清楚。第一，released GitHub repo 公开了 open-weight model、Hugging Face/Transformers/vLLM 支持和模型定义，但没有公开完整 RL 训练代码、数据生成、reward model、CISPO 实现和 launch configs，因此复现性主要停留在 inference/modeling 层；训练 recipe 只能按论文描述理解，不能从代码逐行核验。第二，CISPO 的 evidence 包括 Qwen2.5-32B-base 控制实验和 M1 训练结果，但没有系统展示不同 $ϵ_{hi g h}^{I S}$ 、off-policy update rounds、length penalty、dynamic sampling 的大规模消融。第三，GenRM length bias 被论文识别并处理，但在线 recalibration 的具体指标阈值和 reward model 训练细节不足。第四，M1-80k 并非所有任务都优于 M1-40k，TAU-bench retail 和 MRCR 128K/1M 上 40k 反而更高，说明“更长 budget”与具体任务/解码策略之间仍需更细粒度适配。

整体来看，MiniMax-M1 的贡献不只是发布一个 1M context、80K output 的开权重模型，而是给出了一套围绕长推理 scaling 的系统配方：用 hybrid Lightning Attention 降低长序列成本，用 CISPO 避免关键反思 token 被 clipping 丢弃，用 FP32 head、AdamW 超参、重复早停和 curriculum 处理大规模 RL 的工程不稳定，再用软件工程、工具使用、长上下文 benchmark 证明这种设计在真实 agent 场景中有收益。对于后续工作，最值得复用的不是单个 benchmark 分数，而是“架构效率 + token-level RL objective + reward/data curriculum + 长输出稳定性监控”这条组合路线。

Paper Notes

探索

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

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

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 架构：Hybrid MoE + Lightning Attention

3.2 预训练与 SFT：先让 base model 适合 RL

3.3 CISPO：从裁 token update 改为裁 IS weight

3.4 Hybrid attention RL 的工程 recipe

3.5 RL data、reward 与 80K thinking 扩展

3.6 Released code 对应关系与缺口

4. Experimental Setup (实验设置)

5. Experimental Results (实验结果)

目录