MiniMax M3：首个开权重前沿编程模型——双层计费 API 对路由策略意味着什么

今天，MiniMax 发布了 M3 模型，打破了前沿 AI 领域两年来的一个惯例：开权重与前沿编程能力无法并存。M3 在 SWE-Bench Pro 上取得 59.0% 的成绩——根据 MiniMax 自有 benchmark 表，高于 GPT-5.5 和 Gemini 3.1 Pro——同时具备基于全新稀疏注意力架构 MSA 的百万 token 上下文，以及原生多模态能力（支持图像、视频输入与 computer-use）。权重将在发布后 10 天内开放。

对于正在做路由决策的工程团队，这最后一点至关重要：M3 现已在 MiniMax API 和 OpenRouter 上线，但开权重版本（以及随之而来的自托管路由选项）还需要数天时间。请据此规划。

发生了什么

MiniMax M3 于 2026 年 6 月 1 日正式发布，集成了此前只在闭源前沿模型中才能见到的三项能力：

• 前沿编程： SWE-Bench Pro 59.0%、Terminal-Bench 2.1 66.0%、MCP Atlas 74.2%。MiniMax 内部的 24 小时 CUDA 内核优化测试（147 次提交、1959 次工具调用、全程无人工干预）表明，M3 的设计目标是长周期自主迭代，而非单次代码生成。
• 通过 MSA 实现百万 token 上下文： MiniMax Sparse Attention 将 KV 缓存分块，每块只读一次，相比 M2 在百万 token 长度下实现了 prefill 加速 9 倍、decoding 加速 15 倍。百万 token 下的单 token 计算量仅为上一代的 1/20。
• 从第 0 步训练的原生多模态： 图像与视频输入从训练起就与文本交错融合，而非后期附加。包含 computer-use（桌面导航）能力。

模型已在 MiniMax API 和 OpenRouter 上线。定价：输入 $0.30/M tokens，输出 $1.20/M tokens（发布期 50% 折扣；基础价格约为此两倍）。

为何对 AI 工程团队重要

开权重改变了自托管路由的经济性。 权重一旦发布，团队即可在本地运行 M3 推理——在不将敏感代码发送至外部服务器的前提下满足数据合规要求。这与 DeepSeek V4 开权重对有数据驻留约束的企业产生战略意义的逻辑相同。对于目前将所有编程流量路由到 Claude Opus 或 GPT-5.5 的团队，M3 开权重提供了一个新的成本层级值得评估。

SWE-Bench Pro 59% 是路由信号，不只是 benchmark 炫耀。 当一个模型能在测试套件验证下自主修复真实 bug，它就适合用于无人值守的 coding-agent 工作负载。M3 的声称性能将其定位在与 Opus 4.7 同一梯队——这意味着它成为目前只路由到 Anthropic 顶层的编程 agent 流量的可信 fallback 候选。

长上下文改变了你的上下文预算假设。 百万 token 下单 token 计算量仅为前一代 1/20，意味着多仓库代码分析的成本曲线与其他仅支持缓慢、高价注意力机制的百万 token 模型截然不同。此前因延迟或成本而回避百万 token 上下文的运营商，可能会发现 M3 的 MSA 数据值得重新评估。

Router/Operator 视角

MiniMax M3 的 API 引入了两个路由代理必须显式处理的维度：

1. 基于上下文长度的计费分层

MiniMax API 定价按上下文长度分为两个层级：标准层（不超过 512,000 tokens）和长上下文层（超过 512K）。这不只是标签差异——费率本身不同。只记录模型名称而不追踪 token 数量的 router，会将意外的高成本归结到一个"便宜"的模型上。运营商需要对每个请求的上下文窗口使用量进行监控，以便理解每次调用落入哪个计费层，并正确做账。

2. Thinking 模式与普通模式切换

M3 支持两种模式：用于复杂任务的推理（thinking）模式和用于快速响应的标准模式。这与 Qwen3.7-Max、DeepSeek V4、Kimi K2.6 上出现的切换维度相同——路由策略越来越需要不只选择 provider/model，还要选择推理模式。需要深度推理的 coding-agent 工作负载应路由到 thinking 模式；高并发自动补全工作负载应路由到标准模式以控制延迟和成本。

3. Priority 与标准服务等级

MiniMax 为延迟敏感的工业工作负载提供了 priority 服务层，与标准吞吐层并行。通过 OpenRouter 等第三方聚合器路由 SLA 关键编程 agent 任务时，运营商应确认请求实际命中的服务层，以及聚合器是否暴露了选择机制。

4. 聚合器覆盖并不统一

M3 已在 OpenRouter 上线，但并非所有聚合器都已接入。使用 provider 无关 fallback 的多 provider 路由设置不会自动落到 MiniMax——在将 M3 作为 fallback 选项使用前，请确认你的聚合器 model catalog 中已有该模型。

TheRouter 用户应关注或尝试的事项

• 监控上下文窗口遥测数据。 MiniMax M3 的双层计费意味着需要追踪每个请求的 token 数量，而不只是请求计数。如果你的编程 agent 任务通常使用较长 prompt（仓库上下文、大型 diff），请确认典型请求落入哪个计费层。
• 评估 M3 作为 coding-agent fallback 路由。 一旦开权重发布（根据 MiniMax 公告，10 天内），路由决策将发生变化：团队可在本地运行 M3，仅在溢出时使用托管 API。请关注权重发布和技术报告。
• 检查聚合器 model catalog。 如果你依赖 OpenRouter 或其他聚合器进行多 provider 路由，请确认 M3 在你的可达模型集中，并且你的 fallback 链可以纳入它。
• 关注 benchmark 独立验证波。 MiniMax 的 SWE-Bench Pro 数据为厂商自报。社区独立复现结果将在未来数天内陆续出现。建议在对自身任务分布验证数据成立之后，再将生产编程流量路由到 M3。

M3 是自 DeepSeek V4 以来 coding-agent 基础设施领域最重要的开权重发布——不是因为 benchmark 已无争议，而是因为它迫使每个路由到闭源前沿编程模型的团队重新思考：他们是否还需要那个闭源包装。