Minimax 相关整理(2025-2026)
Minimax-01
25 年 1 月开始开源的模型，
模型对标，对标 DeepSeek V3，GPT-4o 等模型
模型架构采用 MoE，优化最大的是 attention 部分，
MoE 训练过程中，除了使用 GShard 类的 Auxiliary Loss 平衡专家外，也采用了全局路由来控制 expert token 的分配（猜测就是简单的同步每个 expert 全局被选次数？）。
- Scaling
文中对不同 attention 进行了 scaling laws 拟合，结论表明 lightning attention 更好。同时 scaling laws 也被用于选取模型大小，以及确定训练时候的 batch size。
MiniMax M1
25 年 6 月左右发布 arxiv, huggingface
- MOE 架构，456B-A46B，32 个 expert，部分 attention 采用 lightning attention 来节省长文本推理时候的开销。
- 对 MiniMax-Text-01 继续预训练 7.5T token
- SFT 中加入 CoT 模型。数学和编程样本约占全部数据的 60%。
- RL 用了 CISPO，用 512 张 H800， 花了 3 周完成 RL 的训练，成本大约 53 万美元。
- 做长度扩充训练
RL
RL 中基于规则奖励（答案正确+format reward）的训练：
- 数学推理： 50K，用强推理模型筛选保留合适难度的数学题。
- 逻辑推理： 包含 41 种任务，53K 样本；同样对难度上限和下限进行了控制。用 SynLogic 实现数据合成流程。
- 竞赛编程： 30K 竞赛编程数据样本，同样保留难度适中且质量较高的算法题。
- 软件工程： 包含 bug 定位，代码修复，测试用例生产；团队开发了一个复杂的、基于容器的 sandbox 环境，用来模拟真实的软件开发流程。这个环境下能够提供倾析的反馈信号（正奖励或失败奖励）
RL 中基于 reward model 的训练（约 25K 个样本）：
有标准答案、但难以通过规则验证的任务
- 通过比较 GenRM 选出的 Best-of-N（BoN）回答和多个 benchmark 上的 pass@N 指标，评估 GenRM 的有效性。
没有标准答案的任务
- 首先使用多个内部和外部模型生成回答，然后这些参考答案会经过内部质量评估。
- 采用 成对比较框架 ，与参考答案对比来评估模型回答。
最优的 GenRM 后，他们会在整个训练数据集上执行 Swiss Round 评分系统 ，从而为 RL 训练确定最合适的参考答案
还在 RL 侧系统性地采用了 reward shapin 个，value clipping，normalization 降低奖励信号对一些表面特征（例如长度）极端值的敏感性。
在 RL 事后，采用了一个经过精细管理的 curriculum 和动态加权策略，用于在 CISPO 框架下进行 RL 训练：
- 一开始只训练那些带有基于规则奖励的高推理强度任务
- 然后逐步混入一般领域任务
长度扩展策略
高效训练一个支持 80K 输出长度 的 RL 模型。
采用了一种 分阶段窗口扩展的 RL 策略 。按 48K → 56K → 64K → 72K → 80K 逐级上升。
这种分阶段推进的方法可以确保每一步都维持训练稳定性。是否进入下一阶段长度窗口，则由一组经验指标来决定。这些指标包括：
- 生成序列上的 perplexity 是否已经收敛
- 输出长度的 99 分位数 是否接近当前上下文窗口上限
这些信号可以帮助判断模型是否已经准备好继续扩展长度，从而使整个扩展过程中的训练保持稳健。为了支持更长 thinking，他们不仅扩展长度窗口，还重新调整了训练数据：
- 去掉太容易的样本
- 提高难题比例
- 减少会诱发重复和同质化的 synthetic reasoning data
关键的长输出 RL 问题：pattern collapse
随着长度变长，负样本更容易撑满窗口，后半段积累大量负梯度，最终导致后文生成崩坏、乱码化。
这种不平衡来自两个因素：
- GRPO 中 advantage normalization 本身具有不对称性
- 他们采用的是 token-level loss
为了解决这个问题，他们提出了三项关键措施：
（1）检测重复模式并提前停止
他们会检测重复模式，例如连续出现高概率 token 的情况，并采用 early stopping，防止重复性回答过度消耗上下文窗口。
（2）结合 sample-level loss 与 token-level normalization
他们引入了 sample-level loss + token-level normalization 的组合，用来缓解正负样本之间的不平衡，降低这种不利影响。
（3）进一步降低 gradient clipping threshold 和 ε_IS^high
他们还降低了梯度裁剪阈值以及 ε_IS^high，以进一步稳定生成过程。
MiniMax M2
似乎是 25 年 10 月发布的模型：有 huggingface，和三个官方博客：
- What makes good reasoning data
- Aligning to What? Rethinking Agent Generalization in MiniMax M2
- Why Did MiniMax M2 End Up as a Full Attention Model?
架构 230B-A10B MOE，主要与 GPT-5，Claude Sonnet 4.5 等对标。
M2 对比 M1，主要用了 Full Attn
核心原因有三层：
- 第一，efficient attention 的目的主要是省 compute。 ：MiniMax 说，在 compute 有限的情况下，我们需要用同样预算获得更高性能；efficient attention 的核心价值是让训练和推理更便宜。
- 第二，benchmark 容易误导架构选择。 ：小规模实验和已有 benchmark 上，hybrid attention 可能看起来很接近 full attention；但更大规模和更复杂任务下，可能暴露 multi-hop reasoning 缺陷。
- 第三，真实瓶颈不是设计一个 attention，而是评测它是否真的可靠。 ：MiniMax 说，越强的模型越难评估。很多架构问题只有 scale up 后才暴露，而发现问题本身比解决问题还难。
- 第四，linear/sparse attention 的基础设施还不够成熟。 ：低精度 state storage、prefix caching、speculative decoding 都是必须解决的问题。尤其在真实对话和 agent 服务中，prefix cache 命中率很高，新架构必须很好支持。
- 第五，SWA / hybrid 尝试失败的原因是长上下文退化。 ：MiniMax 说它们尝试过 Hybrid SWA，但随着上下文增长，性能明显下降；并且 retrieval head、induction head 等全局注意力模式在 pretraining 早期已经形成，后续 CPT 很难完全调整。
M2 主打 agent/coding model
为 coding and agentic workflows 设计的模型，擅长 multi-file edits、coding-run-fix loops、test-validated repairs，以及 shell、browser、retrieval、code runner 等复杂 toolchain。
M2 的重点不是单次长 CoT，而是 agent loop：
plan → act → observe → think → revise → act → verify
什么才是好的 Reasoning 数据？
- CoT 的质量体现为逻辑完整而不过度冗余。他们做了多样性的格式混淆，同时，对于 CoT 和 Response 中可能存在的 Badcase，如幻觉、指令遵循、逻辑错误等，我们进行了规则+LLM-as-a-judge 的清洗。
- 实验中也发现了 math 和 code 数据是 Reasoning 能力提升的关键。
- 需要足够多样的数据覆盖更多的 domain，比如逻辑推理、科学类、指令遵循、以及开放创意类任务。不同领域的任务有相异的思考范式, Reasoning 的多样性是能力泛化的基础。
- 更加难、复杂的 query 对模型的训练更有效，所以要根据 passrate (for verifiable) 或复杂度评分 (non-verifiable) 进行数据分布的调整
- 当数据质量和多样性都过关时，数据规模的提升总能带来显著收益。不论是增加 query 数量、做“1Q 多 A”、多 epoch 训练，甚至是混合不同方向的数据带来更多的训练步数，模型都会稳步变好。
- 根据任务特点对所有的数据做了归并，分为 Verifiable 和 Non-Verifiable 两条数据管线进行自动化数据合成与处理。
Agent 泛化
- Interleaved Thinking
MiniMax 认为 agent 需要 Interleaved Thinking 。也就是说，模型不是只在开头想一次，然后一直执行；而是在任务过程中可以反复 thinking。
原因是 agent 任务里上下文很长，而且工具返回会不断改变环境。模型需要根据新的 tool outputs 重新判断、诊断错误、提取信息、调整计划。
这也解释了为什么该模型 HF 模型卡要求保留 <think>...</think> 历史。MiniMax 明确说，M2 是 interleaved thinking model，使用时必须把 assistant 历史消息里的 thinking content 原样传回(这一点和推理模型不同, 推理模型使用中通常会把前文的 thinking 内容删掉)，删除 <think>...</think> 会伤害模型表现。
- Generalization is about perturbation
Agent 泛化不仅仅是适应新工具, 它是关于在模型一切可能的操作空间上的扰动适应这件事。 真正的 agent generalization 是对整个 operational space 的 perturbation 稳定，包括：
- tool info 和 toolset 变化
- system prompt 变化
- user prompt 变化
- environment 变化，比如文件、代码库、API
- tool responses 变化
它们认为旧的 tool scaling 只覆盖了 tool info，而没有覆盖 agent 运行过程中的其他扰动。于是它们建立了 full-trajectory generalization 的数据管线，通过这样链路产生的数据, 可以保证在绝大多数的扰动下, 让模型在每一步都对 perturbations 更稳定。
Minimax-M2.1
26 年 1 月左右发布的，huggingface，和 2 个博客：
- M2.1: Multilingual and Multi-Task Coding with Strong Generalization
- Why We Built VIBE Bench: Rethinking Evaluation for Real Workloads
架构与 M2 大致相同，该模型主要针对 agent 能力进行了提升。
M2.1 的提升不是靠单纯刷 SWE-Bench，而是把 coding agent 的训练目标从“修 Python bug”扩展到“真实软件工程”
| 他们遇到的问题 | 他们进行的操作 |
|---|---|
| SWE-Bench 不能完全代表真实 coding 场景 ：它主要是 Python bug fixing，覆盖面太窄。 | 不只围绕 SWE-Bench 训练，而是扩展到真实软件工程任务，包括多语言开发、测试生成、性能优化、code review 等。 |
| 语言覆盖不足 ：真实项目不只是 Python，还包括 Java、Go、TypeScript、Rust、C++ 等。 | 从 GitHub 收集大量 issues、PRs 和测试用例，构建覆盖 10+ 主流语言的数据管线。 |
| 多语言环境很难搭建 ：编译型语言有复杂工具链、版本兼容、依赖管理和测试框架。 | 建立大规模多语言训练环境，并针对不同语言设计测试执行、依赖处理和错误解析逻辑。 |
| 真实环境训练成本很高 ：大量代码任务需要真实运行、测试和验证。 | 搭建高并发 sandbox 基础设施，可快速启动数千个隔离执行环境，支持大规模 RL 训练。 |
| 真实开发不只是修 bug ：还包括写测试、性能优化、code review 等。 | 为不同任务设计专门训练数据和 reward signals，让模型学习多任务 coding 能力。 |
| 模型写的测试可能太简单 ，导致错误代码也能被选中。 | 基于 GitHub PR 和自生成 code patches 合成训练样本，强化高质量 test generation。 |
| 代码不仅要正确，还要高效 。 | 训练模型关注算法复杂度、内存使用、并发处理和 API 最佳实践，提升 performance optimization 能力。 |
| Code review 容易 hallucinate ：模型可能指出不存在的问题。 | 构建 SWE-Review benchmark，同时考察缺陷召回率和误报率，要求找对问题且不能乱报。 |
| 模型容易绑定某一个 scaffold ：在 Claude Code 里强，不代表在 Cursor、自研框架、Droid、mini-swe-agent 里也强。 | 做 OOD scaffold generalization 训练，并在多个 scaffold 上评估 SWE-Bench 表现。 |
| 不同 scaffold 的 context management 不一样 ，有些会丢弃历史 thinking content，影响 interleaved thinking。 | 一方面继续推荐使用 interleaved thinking，另一方面训练模型适应不同上下文管理策略。 |
| 复杂开发任务有很多约束 ：system prompt、user query、memory、tool schema、Agents.md、Skill.md 等都要遵守。 | 强化 long-range instruction following，让模型在长程任务中持续遵守复合指令约束。 |
| M2.1 仍有 over-exploration ：会重复读文件、重复跑测试。 | 计划通过更好的 planning、code localization、memory mechanism 和 adaptive thinking depth 提升效率。 |
| 只看任务是否完成不够 ，开发者体验也重要。 | 计划定义 developer experience reward，包括代码质量、响应延迟、信息透明度、commit message、PR 描述等。 |
| 真实环境执行太贵 。 | 计划构建 Coding World Model，预测测试是否通过、错误信息和程序行为，减少真实执行成本。 |
| 用户需求常常模糊、会中途变化 。 | 计划构建 User Simulator，模拟真实开发者和 agent 的交互模式。 |
| 高质量数据是瓶颈 。 | 建立自动化 data flywheel：发现 GitHub 任务、评估难度、增强任务、分析失败案例、生成新训练数据。 |
后训练技术与实践经验
链接：MiniMax M2.1：在 Agent 场景下的后训练技术与实践经验
- SWE Scaling：从 GitHub 构建可验证软件工程任务
这是 M2.1 coding agent 训练最核心的数据来源。
MiniMax 的做法是利用 GitHub 中大量结构化数据，比如 PR 和 Commit，构建各种 verifiable software engineering tasks 。这些任务可以用于 SFT、拒绝采样，也可以用于 RL。
流程大致是：
第一步，筛选 GitHub PR / Commit。 例如筛选最终被 merge 的 PR，或者带有相关测试用例的 PR。
第二步，为 PR 构建可运行 Docker 环境。 这一步很难。MiniMax 会让 agent 在代码沙盒里反复 build，根据 build 结果自我迭代，尝试把环境搭起来。某些语言或库版本较复杂时，还需要专家经验来优化 agent 的执行流程，相当于给 agent 注入 skill。
第三步，对 PR 做 tagging 和分流。 PR 类型很多，包括 bugfix、新 feature、性能优化、测试构建、重构等。不同类型的 PR 后续处理方式不同。
比如 bugfix 任务可以抽取 F2P 和 P2P 测试：
- F2P ：修复前 fail，修复后 pass，用来验证 bug 是否被修好。
- P2P ：修复前 pass，修复后仍 pass，用来防止修 bug 时引入新 bug。
而 feature 任务、性能优化任务、测试生成任务的 reward 构造方式又不同。
第四步，用模型校验任务一致性。 因为原始 GitHub PR 不一定规范，issue 描述和测试用例也可能不完全一致，所以 MiniMax 会用模型检查问题描述、测试用例和代码修改是否匹配。如果缺少关键信息，还会补充问题描述，让任务变成自包含任务。
这一节最关键的思想是：
把 GitHub PR / Commit 转化成多种可验证任务，而不是只做 SWE-Bench 风格的 bug fixing。
AppDev
AppDev 属于从零到一完成全栈软件开发任务。
- Expert in the Loop ：在 AppDev 场景中，MiniMax 使用 Expert in the Loop 。也就是说，由相关领域的数据专家参与数据生成和迭代。
- Meta Query 与 Rubric-based Reward ：专家写 Prompt 或 Meta Query；Meta Query 结合特定场景的 Random Seed，能合成多样化的用户 Query；采样前构建 Rubric-based Reward
- 专家经验注入与 Prompt Distillation ：专家采样时候把一些开发经验放到 system prompt 中，但训练时去掉，这样专家的 Best Practice 就会变成模型的默认行为，
- Agent as a Verifier ：前端、App 这类任务只看静态代码很难判断质量。MiniMax 会让模型在沙盒环境中完整部署项目，再通过 Playwright 等工具与界面交互，根据交互后的状态变化，对照 Rubric 打分。
WebExplorer
- 提高 query 难度 ：先探索真实信息链，再通过 query evolution 去掉明显入口，让任务变得更长、更难、更像真实搜索。去掉入口如“：移除容易搜索到的信息，模糊化具体线索，替换显著信息
- 用平均解决轮次衡量难度 ：初始问题平均约 7.9 轮 解决，query evolution 进化后达到 9.9 轮 。
Agent 评测
- VIBE ：评估模型从零到一构建应用的能力。reward 包括真实运行环境检查应用是否能编译、交互逻辑是否正确、视觉效果是否符合要求。
- SWE-Review ：测试模型能不能像 code reviewer 一样发现代码缺陷。
- OctoBench ：评估 Agent 的复杂指令遵循能力
Minimax M2.5
似乎是 26 年 2 月左右出的模型。huggingface，还有博客：
Coding：从“修代码”到“像架构师一样规划系统”
M2.5 更强调复杂项目中的 0-to-1 system design 和 完整开发生命周期 。MiniMax 说，M2.5 在训练中形成了类似软件架构师的行为：在写代码之前，会主动从功能、结构、UI 设计等角度拆解和规划项目。
Search and Tool Calling： M2.5 相比 M2.1 使用约 20% 更少的轮次，但取得更好结果。
Office Work： 和金融、法律、社会科学等领域的资深专业人士合作，让这些专家设计需求、提供反馈、参与标准定义，并直接参与数据构建，把行业 tacit knowledge 纳入训练管线。
效率和成本 ：M2.5 原生服务速度达到 100 tokens/s ，接近其他 frontier models 的两倍；M2.5 平均每个任务消耗 3.52M tokens ，M2.1 是 3.72M tokens 。
Minimax M2.7
26 年 4 月左右的模型。huggingface
架构与前几代相似。主打 self-improvement、自主构建 agent harness、复杂工程交付、专业办公交付，以及多 agent 协作。