MiniMax M3：百万 Token 上下文之后，Agent 才是主线

M3 这篇发布最值得读的地方，不是又多了一个「会写代码」的模型，而是 MiniMax 把三个方向绑在了一起：前沿编码与 Agent 任务、最高 100 万 token 上下文、原生多模态输入。官方博客称，M3 使用 MiniMax Sparse Attention，也就是 MSA，让长上下文成为可以继续扩展的维度；同一篇发布还把 MiniMax Code、Token Plan 和 API 一起推出来，明显是要把模型能力直接放进开发者的日常工作流里。1

这意味着，M3 的核心问题不是「会不会补全一段代码」，而是模型能否在很长的上下文里持续读文档、看日志、跑工具、改方案，并在几十次甚至上百次反馈后继续推进任务。官方给出的 CUDA 优化案例里，M3 连续执行约 24 小时，完成 147 次 benchmark 提交和 1,959 次工具调用，把 Hopper FP8 GEMM 的硬件峰值利用率从 7.6% 推到 71.3%。1 这类数字很吸引人，但也提醒我们：M3 押注的是长程执行，不只是单轮答案质量。

长上下文模型真正难的地方不在「把窗口标到 1M」，而在每增加一段上下文，注意力计算和显存访问会不会把推理成本拖垮。MiniMax 在原文里把矛头指向 full attention 的二次复杂度，并提出 MSA 这种稀疏注意力架构：先把 KV 切成更精确的块，再让查询只命中相关块，避免每个 token 都和全部历史做全量交互。1

原文还提到一个工程细节：M3 在算子层采用「KV outer gather Q」的方式，用 KV block 做外层循环，把命中同一 KV block 的 query 聚合起来。这样每个 block 只读一次，内存访问也更连续；在 M3 的 head 配置下，官方称该实现比 Flash-Sparse-Attention 和 flash-moba 快 4 倍以上。1

如果只看宣传语，1M 上下文容易被理解成「能塞更多文档」。更准确的读法是：MiniMax 想让模型在一条长任务里保留论文、代码、实验日志、工具返回和用户反馈，减少频繁压缩历史造成的信息损失。官方称，在 100 万上下文长度下，M3 的单 token 计算量只有上一代模型的 1/20，prefill 阶段加速超过 9 倍，decode 阶段加速超过 15 倍；多组 ablation 中，MSA 在多数能力上接近 full attention。1

这里仍要留一个问号：博客讲清了架构思路和官方速度收益，但外部读者还需要技术报告、权重和可复现实验来判断 MSA 在不同任务、不同硬件、不同 batch 设置下的实际边界。原文结尾也写到，MiniMax 会在发布后 10 天内释放技术报告和对应模型权重。1

M3 的公开定位里，编码和 Agent 是最重的部分。官方给出的几项基准包括：SWE-Bench Pro 59.0%、Terminal-Bench 2.1 66.0%、SWE-fficiency 34.8%、KernelBench Hard 28.8%、MCP Atlas 74.2%。1 这些指标覆盖软件工程、终端任务、代码效率、算子优化和工具协议任务，说明 MiniMax 不想只拿代码补全做卖点。

更有信息量的是它对「真实编码协作」的判断。原文说，现有代码 Agent 的训练和评测常把任务假设成单轮：用户给需求，模型给答案。但真实开发常是连续协作，需求会变，方案要讨论，中间结果会引出新问题，模型还要在同一个会话里切换任务。为缩小基准与真实体验的差距，MiniMax 构建了交互式用户模拟框架，模拟需求细化、方案讨论、反馈修正、连续任务切换和复杂项目迭代。1

这个方向比单纯刷榜更接近代码 Agent 的痛点。开发者真正关心的是：模型看完一个仓库后，能不能记住约束；修了一个 bug 后，能不能理解测试失败的含义；跑到第 80 次工具调用时，能不能不把早期目标忘掉。M3 把长上下文、工具调用和编码能力放在一起讲，逻辑上是自洽的。

MiniMax 称 M3 从 Step 0 就做混合模态训练，并重构文本预训练数据管线，引入大量 interleaved data，也就是文本、图像、视频等信息交错出现的数据。1 这种说法的重点不在「支持图片输入」本身，而在它试图让视觉信息进入模型的基础语义空间，而不是后期外挂一个视觉模块。

这对 Agent 任务很重要。官方论文复现案例里，M3 需要理解论文中的曲线、数据和公式；MiniMax Code 也因为 M3 的多模态能力，支持 computer use。原文举的例子是，用户可以让它在电脑上打开本地 ERP 客户端，并根据 Excel 表批量录入发票信息。1 如果这个能力稳定，它指向的是跨应用、跨文件、跨系统的桌面自动化，而不是聊天框里的一次性问答。

但多模态部分的公开细节还偏少。官方博客没有展开视频理解的帧率、输入长度、视觉 tokenizer、训练数据构成，也没有给出足够细的错误类型分析。对开发者来说，下一步更该看模型卡、API 文档和真实桌面任务测试，而不是只看「原生多模态」这个标签。

这次发布同时更新了 MiniMax Code。官方把它描述成面向 M3 训练的 Agent 产品，可以利用 M3 的长上下文、编码 / Agent 任务和多模态能力；它还包含 Agent Team，将大任务拆成多阶段、并发、动态调整的工作流，并通过 Producer + Verifier 的对抗式循环持续产出、反思和修正。1

这解释了为什么 M3 的发布文大量讲长期执行案例。MiniMax 不是只想卖一个 API 模型，而是把模型、桌面 Agent、Token Plan 和开发者工具接在一起。官方模型页也写到，M3 API 支持最高 1M token 上下文，并保证最低 512K token；它把 1M 上下文称为长程 Agent、长程 Coding 和长视频理解的基础设施。2

商业层面也很直接。Token Plan 分为 Plus、Max、Ultra 三档：20 美元 / 月约 17 亿 M3 token，50 美元 / 月约 51 亿 token，120 美元 / 月约 98 亿 token；文本、图像、语音和音乐共享同一使用池。1 API 计费按输入长度分层，≤512K 输入 token 走标准价格，超过 512K 进入更高的长上下文价格；thinking 可以按请求开关，standard 和 priority 两种服务层级也可组合使用。1

这套定价思路和模型能力是一体的：如果长上下文、工具调用和多模态要进入日常工作，用户不会只按「每百万 token 单价」算账，而会看一个月能跑多少次大仓库任务、多少次长实验、多少次桌面自动化。Token Plan 给了很高的名义额度，但真实成本还取决于上下文复用、缓存命中、工具调用次数和失败重试率。

第一，M3 不是单点能力发布。MiniMax 把稀疏注意力、编码 Agent、多模态和产品入口放在同一篇博客里，说明它的目标是长程任务执行，而不是只在聊天或补全场景里提高分数。

第二，MSA 是这篇文章的技术核心。百万上下文如果没有更低的注意力成本，很容易变成昂贵的展示参数；MiniMax 给出的 1/20 单 token 计算量、9 倍以上 prefill 加速和 15 倍以上 decode 加速，正是在回答这个成本问题。1

第三，所有结论都要带着「官方自测」这个前提。博客末尾列了大量评测方法，其中不少使用内部基础设施、内部 benchmark、Claude Code 或自家 scaffolding，部分外部模型成绩也来自不同 leaderboard 或模型卡。1 这不等于数据无效，但读者在决策时应优先看三个后续信号：技术报告是否给出足够复现细节，开源权重是否按承诺释放，第三方能否在真实仓库、真实桌面和真实长任务里复现类似收益。