MiniMax M3 API：定价、百万上下文与生产环境应用

MiniMax M3 API 于6月1日正式上线。那周我就开始测试了。两周后才动笔记录——在此之前，你还沉浸在演示的震撼中。

这是一篇工作笔记，不是模型评测。基准测试到处都是。我关心的更具体：minimax m3 模型在生产环境中究竟适合什么场景，100万上下文在实际使用中意味着什么成本，以及直连API还是聚合器——选哪个、什么时候选。

先说几点。

大多数头条数字（59.0% SWE-Bench Pro、>9×/15× 的速度提升、83.5 BrowseComp）都是厂商自报的。我把它们视为有利条件下的上限，而不是你的代码库上的下限。

100万上下文是真实的。定价分两档。这比很多人意识到的更重要。

开放权重在第十天左右登陆 Hugging Face。如果你读到某篇发布文章还说”权重即将公布”，那已经是过时信息了。

MiniMax M3 是什么（面向开发者）

API 可用性与接入方式

三种接入方式。通过 MiniMax 开放平台直连。通过聚合器——OpenRouter、Fireworks 等。或者从 Hugging Face 自托管。

我测试了前两种。自托管留给有 GPU 资源的人——minimax m3 参数总量约 428B，每个 token 激活约 23B（MoE 架构），不是单张消费级 GPU 能跑的。

我测试的两条路径，实际体验上的差异在文档里看不出来。直连的每 token 成本更低。聚合器给你提供跨多个模型的统一计费界面。哪个更重要，取决于一个大多数团队还没想清楚的问题——我后面会回来谈，因为这是我看到团队卡住的地方。

100万上下文，512K 保底

这行字值得仔细读。MiniMax M3 API 支持最多 100万 token 的上下文。规划时要对标的数字是 512K——有保证的最低值。100万的上限是有条件的。

我在约 48 万 token（拼接的代码仓库 + 设计文档 + 一段长对话）下做了测试。三次运行结果一致，延迟在预期范围内。

推到约 70 万 token（加入了项目完整的 issue 历史）。延迟波动明显变大。计费档位也变了。

所以实际上：512K 是你可靠的工作数字。上半段窗口存在，但那是预算项，不是免费容量。

底层架构是 MSA——MiniMax 稀疏注意力机制——在发布文章中有记录。对成本规划来说，关键细节是：在 100万 token 上下文下，每 token 计算量降至 M2 的约 1/20。没有这个比例，长上下文档位根本不可能在经济上成立。

M3 为什么而生

编程与智能体工作负载

minimax m3 模型定位于长周期编程和智能体工作。两周的摸索下来，这个定位是诚实的。

单轮问答没问题。不令人惊艳，但没问题。真正体现差异的是长会话——读取代码仓库、制定计划、执行、迭代、从中途出错中恢复。MiniMax 自己的演示让 M3 运行 12 小时、提交 18 次，复现一篇 ICLR 论文。这才是这个架构看起来为之设计的工作负载。

相关的 minimax m3 基准数字——均为厂商自报——是 59.0% SWE-Bench Pro、66.0% Terminal Bench 2.1、74.2% MCP Atlas。VentureBeat 的报道将其与 GPT-5.5 和 Gemini 3.1 Pro 对比。那个”碾压”的说法，我会降温 30%。数字是真实的。条件是 MiniMax 自己的实验室和自己的脚手架。

对开发者的意义：如果你在构建编程助手、桌面智能体，或者任何维护多步骤计划的系统，M3 进入候选名单。如果你的工作负载是高并发的短提示，你在为用不上的上下文付费。

原生多模态（图像、视频）输入

多模态是原生的，不是后加上去的。文本、图像和视频进入同一个上下文。输出是文本。

我把一张 UI 截图 + 一段 30 秒的屏幕录制 + 一段相关后端代码丢给它，让它推断用户真正想做什么。它做到了。不是一次就成——我在第二轮引导了一下（第一次猜测合理但错了）。按我的标准，这算是可用的。

有个细节我想特别指出，因为在另一个测试中坑了我：图像和视频 token 与文本共用同一个池。一段短视频在任何提示文本之前就能吃掉你 512K 窗口的相当一部分。我查了一段 15 秒 720p 视频的 token 数——比我脑子里的估算高得多。在做推断之前，值得实际测量一下。

生产成本与限制

我不在这里列具体的每百万 token 费率。供应商价格会变动，关于 minimax m3 价格机制另有一篇文章专门处理这些数字。规划阶段你需要的是结构。

标准档 vs 长上下文档（>512K）费率

MiniMax M3 API 分两档：

≤512K 输入 token — 标准费率。覆盖大多数对话、编程和智能体循环。
>512K 输入 token — 更高的长上下文费率。面向全仓库推理、超长文档、数小时的智能体会话。

这个分档是我会围绕它设计系统的核心。一个日常在 10 万~30 万 token 区间运行的系统，和一个经常触及 70 万 token 的系统，单位经济学完全不同。发现方式和我猜大多数团队发现的一样：看账单。

对我有效的做法：默认路由上限设为 512K，超过需要显式标记。这样成本在调用点就能看到，而不是月底才冒出来。

跨模态的共享 token 池

前面提到过，但值得单独说一遍。没有单独的多模态配额。图像是 token。帧是 token。它们和文本吃同一个窗口，也以同样的方式跨越 512K。

对于每轮都截图输入的智能体循环，这个消耗速度比粗算的要快得多。审计一次真实会话的 token 数。不要相信合成基准。

直连 API vs 聚合层

这是我看到团队卡住的决策。大多数人卡的时间比应该的要长。

各自适合什么场景

选直连，如果：

M3 已确定为主力模型，不打算切换。
每 token 成本比集成界面更重要。
你需要完整的 100 万（部分聚合器上限更低——Fireworks 上线时有 50 万的上限，正在分阶段提升）。
维护一个模型专属集成对你来说不是负担。

选聚合器，如果：

你已经在生产中运行多个模型，或者将来需要。
你想在不重建请求路径的情况下，对比测试 M3 和 Claude Opus 或 DeepSeek V4。
统一计费、重试、故障转移路由和可观测性很重要。
你还不知道工作负载最终会稳定在哪个模型上。

选聚合的真实理由不是更低的每 token 成本——通常略高。真实理由是模型切换自由度有经济价值，而且你的产品跨供应商触及的生成越多，这个价值复利越大。WaveSpeedAI 处于这一层，OpenRouter 和 Fireworks 也是——各自在路由、延迟和覆盖面上做了不同的取舍。

我的粗略原则，仅供参考：单模型编程智能体 → 直连。跨供应商混合文本 + 图像 + 视频 → 聚合器。不是硬规则，是出发点。

限制与权衡

开放权重、技术报告，以及仍缺失的东西

权重在 Hugging Face 上。社区 GGUF 量化版本已上线。两点值得了解：

许可条款尚未完全确定。不要假设是 Apache 2.0 或 MIT——在本地部署路径上构建商业产品前，请先核查。

并非所有推理引擎都支持 MSA。不支持的会回退到密集注意力，这会损失一部分速度优势。如果你自托管，在基准测试之前先验证引擎支持——否则你的数字会比实际更差看。

ARC-AGI 的差距

发布报道往往跳过的一点。M3 在编程和智能体上的优秀数字，不能直接平移到 ARC-AGI 等通用抽象推理基准上。这个模型为它所宣传的而塑造——编程、工具使用、长周期智能体、多模态接地——不是抽象谜题。

这不是批评，而是模型的形状。了解这一点，能避免押错宝。

常见问题

MiniMax M3 API 已经上线并可稳定用于生产了吗？

是的。2026年6月1日起上线。稳定到多个聚合器已在路由真实流量的程度。和任何上线不足三个月的模型一样，随着供应商调优，预期会有偶发的行为变化——固定你的提示，保持一套评估套件。

MiniMax M3 真正有保证的上下文长度是多少（512K 还是 100万）？

512K 有保证，100万是上限。512K 以下行为一致。超过之后，你进入更高定价和更大延迟方差的区间。部分聚合器在上线时上限低于 100万。围绕 512K 来规划。

MiniMax M3 对图像和视频输入是原生多模态支持吗？

是的。原生，不是适配器。文本、图像和视频共用同一个 token 池和上下文窗口。输出仅为文本。

MiniMax M3 的开放权重现在可以用了吗？

是的。上线后约第十天登陆 Hugging Face。总参数约 428B，每 token 激活约 23B（MoE）。单张消费级 GPU 无法运行——预计需要多 GPU 或量化推理。许可条款——商业使用前请核查。

我应该直接访问 MiniMax M3 还是通过聚合器？

如果你已确定单一模型并想要最低每 token 成本，选直连。如果你在运行多个模型或预计切换，选聚合器。答案取决于你的工作负载，而不是哪个”更好”。

结语

MiniMax M3 API 之所以有趣，不是因为它在某个单一维度上领先，而是因为组合——前沿级编程能力、原生多模态、真实（但分档）的 100万上下文、开放权重，全在一个模型里。这种组合折叠了过去需要拼接多个供应商才能实现的集成界面。

在投入生产前我会做的事：

跑你的真实工作负载，不是基准测试。 测量提示相对于 512K 落在哪里。在上线前确定路由策略。根据你要运行多少个模型来选直连还是聚合器，而不是只看标价。如果自托管，在你的推理引擎里验证 MSA 支持。

两周不算长。模型会持续演进，定价也会。这篇文章的保质期就在这里。

一切以你实际构建那天的文档为准。

往期文章：