MiniMax：Text-01 / M1 → M2.7 → M3，注意力选择如何与 Agent RL、KV 和内核一起演进

1. 先画出架构与 post-training 的分界

Text-01/M1、M2 系列和 M3 的注意力与系统设计确实不同；M2.1、2.5、2.7 则主要沿用 M2 backbone，更新 agent 数据、RL 和任务系统。不能把每个 API 名称都画成一套新骨架。

2. Text-01 / M1 到 M2：为什么会从 hybrid 回到全 attention

M1 以 Text-01 的 hybrid MoE + Lightning Attention 为基础，使用周期性 full/softmax attention 与更多 lightweight long-context block。它有利于长序列推理的计算预算，但公开 M2 技术报告指出，在真实长上下文、多跳和 agent 工作负载中，hybrid 质量下降以及 prefix cache / speculative decoding 的集成仍不够成熟。因此 M2 选择更规则的 62-layer decoder-only：full attention + GQA，外加 256 个细粒度 experts、top-8 路由、sigmoid gate 和 learnable expert bias。

纸面 FLOPs 较低，不代表 agent 服务的端到端表现一定更好。cache reuse、prefix semantics、推测验证、kernel 规则性和质量退化都要计入测试。

3. M2 的预训练和 Agent RL：架构之外的另一半模型

M2 技术报告披露 29.2T token 的预训练，并分为 constant 阶段和 8K→32K→192K 的长上下文阶段。长文档 packing、native PDF 等数据形态决定模型能否学习跨页、跨文件的结构；随机截取的 token 窗口覆盖不了这类依赖。

后训练则围绕 GitHub PR、多语言 Docker、可执行测试、应用开发、Terminal-Gym、搜索与办公环境建立可验证奖励。对 agent 系统来说，奖励不应只看文本是否像答案：代码任务需要编译/测试，UI 任务需要交互状态，搜索任务需要证据，长任务还需要对失败轨迹做局部归因。

Forge 将训练、推理和 agent 环境拆开，并使用 windowed FIFO、prefix-tree merging 与 rollout 调度。训练 GPU 只是 RL 样本吞吐的一环，生成服务、缓存复用、sandbox 和奖励器的稳定性同样会卡住管线。

4. M2.1、M2.5、M2.7：用同一骨架迭代可执行工作流

M2.1 更新了 interleaved thinking、代码和上下文管理；M2.5 增加数十万现实环境上的 RL、process reward、CISPO 与并行工具调用；M2.7 又加入 memory、skills、动态工具搜索，以及“失败轨迹→计划→修改→评估→保留/回退”的循环。这些改动属于训练目标、agent harness 和工具策略，不能用来补写新的 attention stack。

更短的 reasoning 或更好的规划可能减少调用轮数，也可能增加单轮工具并行、缓存状态和回退分支。评测时应分列模型 decode 时间、工具 wall-clock、上下文增长、cache hit、重试和最终成功率。

5. M3：MSA 如何把长上下文 attention 变成选择 + 执行问题

M3 的 MiniMax Sparse Attention（MSA）建立在 GQA 上。轻量 Index Branch 为每个 GQA group 评估 KV blocks 并选择 Top-k，Main Branch 只在选中的 block 上计算精确 sparse attention。论文同时给出 exp-free Top-k、KV-outer sparse attention 等 kernel 设计，用来处理 block-level 不规则访问；“稀疏”在这里有对应的执行实现。

这和 DeepSeek DSA / V4 CSA 的共同主题是：1M context 不再能只问‘有没有 attention’，而要问谁索引、谁压缩、谁选择块、KV 如何存、kernel 是否能把算法稀疏性兑现为时间。

6. 部署：开权重路径与托管路径需要分开测

MiniMax 为 M2/M2.5/M2.7 提供 Hugging Face、vLLM/SGLang、Transformers、API 和本地 OpenAI-compatible 示例。对于 self-host，首先用官方 checkpoint 的精度、模板和 engine 复现短请求；随后再测试 MoE 并行、MTP、长 context 和多工具 workload。对于托管 API，用户只能测可观察的 cache、限流、工具与 context 语义，不能把产品页面的‘private cluster’当物理架构公开。

1. 记录权重 total size 和 KV head/config，不从 active 参数推测设备需求。
2. 在 M2/M2.5 上测 MTP acceptance、验证成本和 prefix hit。
3. 在 M3 上单独测 index branch、selected blocks、quality recall 和 sparse kernel 时间。
4. Agent benchmark 把模型与工具/沙箱 latency 分列，避免把外部等待隐藏在 tokens/s 后。

7. M1 与 M2 的对照实验该怎样读

要比较 hybrid Lightning 与 M2 full attention，不应只横向比较两个发布宣称的 context 上限。固定模型精度、上下文分布、输出预算、cache policy、MTP、工具环境和 quality target，再记录 prefill、decode、KV、cross-token recall 与任务成功率。M1 的长思考 RL 和 M2 的 agent data / MTP 同时变化，因此任何端到端差异都不是纯 attention 因果效应。

8. Forge 把 RL 系统拉回模型家族页的原因

Forge 把 rollout inference、agent environment、reward 和 trainer 分开，同时保留 prefix-tree merging、窗口化队列与 kernel 协同。这样一来，“扩大 M2.5 的 RL”就会落到具体系统约束上：环境吞吐、长尾轨迹、缓存命中、异构 worker 和失败恢复都会影响样本产出。Agent 科研与Systems for ML 论文目录收录了相关 RL systems 材料。

9. 一手来源