MiniMax M3 发布解析：1M Token 上下文、稀疏注意力架构与港股 A 股两线并进（2026）

2026 年 6 月 1 日，MiniMax 发布了 M3 模型。如果只看发布稿，你会看到"1M 上下文"、"原生多模态"、"前沿 Coding 能力"这几个关键词——这些都是实际特性，但没有一个能单独解释 M3 为什么值得关注。

值得关注的理由在于一个不太常被单独提及的细节：在 100 万 token 的上下文规模下，M3 的单 token 计算量约为上代模型的 1/20。这不是数字游戏，而是一个工程决策的结果，它决定了 M3 是否能在商业上做到"1M 上下文"，而不只是在技术上宣称它。

为什么 1M 上下文本身不算创新，但 M3 的实现方式是

长上下文模型不是新鲜事。Google Gemini 1.5 在 2024 年就支持了 1M token 输入。但"支持"和"可用于生产"之间的差距，大多数团队都踩过：当上下文接近上限时，每次推理的成本和延迟会以非线性方式膨胀，API 账单从"可控"变成"无法预算"。

传统全注意力机制的问题在于计算复杂度是 O(n²)——上下文长度翻倍，计算量变四倍。这个基本限制使得大多数模型的"1M 上下文支持"在实际使用中更接近一个技术极限展示，而不是稳定可用的功能。

MiniMax M3 选择了自研 MSA（Multi-head Sparse Attention，多头稀疏注意力） 架构来绕开这个问题。

MSA 稀疏注意力：技术决策的逻辑

标准 Transformer 的注意力机制让序列中的每个 token 都对其他所有 token 计算相关性权重——这保证了全局感受野，但代价是平方级别的计算复杂度。稀疏注意力的思路是：大多数 token 之间实际上的相关性接近于零，计算这些近乎无效的权重是算力浪费。

MSA 的具体实现方式 MiniMax 没有公开全部细节，但从已知信息可以推断几个关键设计选择：

局部窗口 + 全局 token 混合：序列被分割成固定大小的局部窗口，每个 token 只与同一窗口内的 token 和少量"全局 token"进行全注意力计算。全局 token 负责跨窗口信息聚合，局部窗口保证近邻信息不丢失。

动态稀疏性：不同于固定稀疏模式（如 BigBird、Longformer），MSA 的稀疏模式会根据输入内容动态调整，相关性高的 token 对仍然做密集计算，而不是用统一的稀疏规则"一刀切"。

推理算子优化：MiniMax 公布了一个令人印象深刻的数字——M3 的底层推理算子性能较主流开源方案（推测是 FlashAttention 系列）提升了 4 倍以上。这个提升意味着在同等 GPU 资源下，每秒能处理的 token 吞吐量显著增加。

最终的工程结果：在 1M token 上下文规模下，单 token 算力约为上代的 1/20。换算成业务语言：处理一份 100 万 token 的长文档（约相当于 5 本中等长度的技术书籍），计算成本是上代模型的 5%。

M3 的三个核心能力场景

1. 超长上下文文档分析

1M token 的实用性不在于"我能往进塞多少字"，而在于几个具体场景：

• 法律合同审查：大型并购案的合同文档总量常常超过 50 万字，传统做法是人工分段阅读或使用 RAG 切分索引。M3 可以整体输入，保留跨段落的上下文一致性
• 代码库分析：将一个中型项目（约 10-30 万行代码）整体输入，做全局架构分析或 Bug 定位，而不需要预先向量化和检索
• 长视频理解：原生多模态支持意味着可以把几小时的视频帧序列整体提交，而不需要外部时序分割处理

2. 代码能力与 Agent 训练

M3 在训练过程中引入了交互式用户模拟器框架——这是一个不太常见但很关键的训练创新。

通常的代码训练范式是：让模型看大量代码 → 在已有代码题上做微调。这种方式的问题是，模型学到的是"如何让静态代码题看起来对"，而不是"如何在真实开发流程中迭代"。

MiniMax 的方式是：构建一个虚拟的开发者用户，这个用户会对模型生成的代码给出"模拟真实开发者"的反馈——报告运行时错误、提出边界条件、要求修改接口设计。模型在与这个虚拟用户的多轮交互中学习，接触的是"接近生产环境的交互场景"而不是理想化的代码题。

效果：M3 在编程任务上的表现明显好于仅凭静态代码数据训练的模型，特别是在需要根据运行反馈迭代修改代码的任务上。

3. 原生多模态与桌面操作

M3 支持图像、视频理解以及桌面操作能力（GUI Interaction）。"桌面操作"在这里的含义是：模型能理解屏幕截图中的 UI 元素，并生成对应的操作指令（点击、输入、滚动等）。

这与近期多家公司发布的"计算机使用（Computer Use）"能力属于同一技术方向，但 MiniMax 将其集成到了 M3 的基础能力中，而不是作为单独的 API 插件提供。

从 M2.7 到 M3：开发者需要关注的差异

如果你已经在测试或使用 MiniMax M2.7（2026 年 4 月 13 日发布），M3 有哪些实质性的变化值得重新评估？

如何决定是否迁移：如果你的工作流不需要处理超过 200K tokens 的长文档，也不需要多模态输入，M2.7 在纯文本 Agent 任务上的性能（SWE-Pro 56.22%，Terminal Bench 82.4%）仍然具有竞争力，且 API 定价便宜（输出 $1.10/M tokens）。

如果你有长文档分析、多模态 Agent 或桌面自动化需求，M3 是实质性的升级而不是边际改进。

MiniMax 的商业路径：港股上市 + A 股 IPO 辅导

技术之外，MiniMax 在 2026 年同步推进了两件大事，在判断"要不要深度绑定这家公司的 API"时值得放在一起考虑：

2026 年 1 月：港交所上市，首日股价翻倍至 1330 港元/股。这是 MiniMax 的第一个公开市场背书，意味着财务信息公开透明，有监管约束。

2026 年 5 月 29 日：与中信证券签署 A 股 IPO 辅导协议，正在评估在上交所科创板上市的可能性。A 股上市的技术企业通常需要满足较高的营收规模和研发投入要求，这意味着 MiniMax 的商业化路径已经具备相应的规模。

对 API 用户的实际意义： 1. 上市公司的财务状况受审计约束，相比私有公司，API 服务的持续性风险更低 2. 两地上市（或 A 股注册）意味着需要在国内监管框架下运营，这对数据合规有明确的约束和保障 3. 融资能力的增强意味着基础设施投入可能持续，GPU 资源稳定性提升

当然，上市不等于永久可靠——需要关注的是财报中 API 业务的具体营收占比和增速，而不只是股价。MiniMax 官方披露的 ARR（年化收益）超过 3 亿美元且在短期内翻倍，说明商业化已经不是"早期探索"阶段。

技术验证路径

目前 M3 的可公开验证信息：

• 发布公告：MiniMax 官方（minimaxi.com / hailuo.ai）
• 技术报告：MiniMax 通常在发布后数周内公开技术报告，建议关注其官方 GitHub（github.com/MiniMax-AI）
• API 访问：国内版本通过 MiniMax 平台（api.minimax.chat），国际开发者可通过部分聚合平台访问
• 基准验证：SWE-Pro 和 Terminal Bench 的验证可通过 GitHub 对应评测框架复现

总结：M3 适合进测试队列的四个信号

把 MiniMax M3 列入下一轮测试的判断标准：

1. 你有超过 200K tokens 的长文档处理需求——这是 M3 相对 M2.7 最明确的差异化场景
2. 你需要多模态 Agent（图像 + 文本，或屏幕截图理解）——M3 原生支持，M2.7 不支持
3. 你在做代码迭代场景（不只是单次生成，而是修改-反馈-再修改循环）——交互式训练方法的效果主要体现在这里
4. 你需要一个有清晰商业路径的供应商——港股+科创板双线推进，财务透明度高

如果以上条件都不满足，M2.7 在成本和纯文本 Agent 性能上仍然是很好的选择，不需要着急迁移。

延伸阅读

• Qwen3.7-Max 深度解析：Arena 盲测中国第一、Agent 能力跃升背后的技术逻辑（2026）
• MiniMax M2.7 选型指南：比 Claude Opus 4.6 便宜 40 倍，SWE-Pro 56.22%，什么时候用它（2026）
• How to Track Open-Source Model Licenses: Commercial Use Boundaries and Model Card Change Audits
• How to Verify AI Data Retention and Training Usage Policies: A Practical Privacy Guide for OpenAI, Anthropic, and Gemini

RadarAI 聚合 AI 优质更新与开源信息，帮助开发者高效追踪 AI 行业动态，快速判断哪些方向具备了落地条件。