Mercury 3 vs MiniMax M3：一个数字对阵一整份记录

Inception 于 2026 年 10 月 19 日发布 Mercury 3，只给出了一项性能数据——每秒 1,068 个 token——没有任何形式的基准测试分数。MiniMax 于 2026 年 6 月 1 日发布 MiniMax M3，附带了厂商基准测试表、可下载的检查点，并在四个月后公布了独立评估者的评分。把两者并排对比，有趣的问题并不是哪个模型更快或更便宜，而是如今其中一个模型可以由作者以外的人核查，另一个却不能。这种不对称正是整个对比的核心，而且无论哪家实验室宣布何种降价，这一点都不会改变。 像这次发布背后那些有记录的 AI 故障和智能体事件，都收录在 OrcaRouter AI Incident Archive 中，每条记录都附有自己的来源、严重程度、置信度等级和争议标记。

这两个模型在纸面上也恰好足够接近，因此选择是真实存在的。两者都支持一百万 token 的窗口。两者都处于低价档位。两者都构建在对各自类别而言并不寻常的架构之上——Mercury 3 采用扩散架构，MiniMax M3 则在专家混合架构上采用稀疏注意力——并且两者都声称，正是这种架构为它们带来了经济性。

两篇发布帖，两种不同类型的证据

将 Inception 的公告作为文档来阅读。它提出了一个规模论证：Mercury 3 的总参数量比 Mercury 1 大 40 倍以上，从 Mercury 1（mini）到 Mercury 3，测得的智能水平大约提升至三倍，而且该模型“和它最小的前代一样快”。它提出了一个比较性质量主张：Mercury 3 “与 GPT-6 Luna 和 Claude Haiku 5.5 等前沿速度优化模型相当或更好”。并且它只报告了恰好一项任务结果，来自 Inception 自有的 web-agent 测试框架，在 50 个实时 Mind2Web 导航任务上，模型完成了 50%。其中每一项都由厂商报告，且没有一项指明基准测试套件、领先幅度或硬件配置。

把 MiniMax 的材料当作一份文档来读，它的形态恰恰相反。里面有一张基准测试表，列出各项测试套件的名称与百分比——SWE-Bench Pro 59.0、Terminal-Bench 2.1 66.0、BrowseComp 83.5、OSWorld-Verified 68.70——此外还有模型卡，还有发布在 Hugging Face 上的权重，还有 Artificial Analysis 的一份独立榜单，给该模型在其智能指数上打了 29 分。厂商的数字终究还是厂商的数字，我们尚未看到这些数字被复现。但这个模型任何人都可以下载、运行和测量，这正是那个独立数字之所以存在的原因。

已发布内容中的这一差异并非营销细节。它决定了任何人就这两个模型能给你提供什么样的建议。对于 MiniMax M3，有实测的吞吐量数据、实测的每索引任务成本、实测的排名。而对于 Mercury 3，只有一个宣称。

规格说明，并附上各方的来源

• 每百万 token 价格——Mercury 3 标价为输入 $0.20、输出 $0.70，在发布折扣期间减半至 $0.10 和 $0.35；相比之下，MiniMax M3 在输入 token 不超过 512K 的请求上为 $0.30 和 $1.20

• 缓存输入 — Mercury 3 每百万 $0.02，发布窗口期内 $0.01，而 MiniMax M3 每百万 $0.06

• 上下文窗口 — Mercury 3 为 1,000,000 个 token，MiniMax M3 为 1,048,576 个

• 最大输出 — 在我们的产品目录页上，Mercury 3 为 131,072 个 token，而 MiniMax M3 为 512,000 个 token；MiniMax 未公布最大输出数值，因此该数值来自我们，而非厂商

• 输入模态——Mercury 3 仅支持文本，对比 MiniMax M3 支持文本、图像和视频

• 架构 — Mercury 3 是一种扩散语言模型，可并行细化 token 块；而 MiniMax M3 是混合专家模型，总参数量约 428B，每个 token 激活约 23B，并采用 MiniMax Sparse Attention

• 权重 — Mercury 3 为闭源、仅提供 API，而 MiniMax M3 可根据 M​iniMax 社区许可证下载

• 吞吐量 — Mercury 3 为每秒 1,068 个 token（厂商报告，基于未具名的 NVIDIA 硬件，批大小和 effort 设置均未指定），对比 MiniMax M3 为 Artificial Analysis 测得的每秒 106.4 个 token

• Independent Intelligence Index — 截至 2026 年 10 月 20 日，Mercury 3 尚未收录；相比之下，MiniMax M3 为 29，在当日现行修订版中于 121 个模型里排名第 23。

• 推理控制 — Mercury 3 有四档 effort 设置，从 instant 到 high，省略参数时默认为 low；而 MiniMax M3 则有一个 thinking 参数，支持 enabled、adaptive 和 disabled 三种模式

• 工具调用与结构化输出——两者均可在兼容 OpenAI 的聊天补全端点上得到支持

其中两行在任何地方被引用之前，都需要附上一则说明。1,068 这个数字是供应商的测量结果，且未说明测试框架，因此无法与独立评估者在固定方法下得出的数字相提并论。另外，Artificial Analysis 会定期重新评分其指数；上面的 29 是 2026 年 10 月 20 日的读数，而 MiniMax M3 在更早的修订版本中读数有所不同。该指数上的数字会变动；但 M3 有这样一个数字、而 Mercury 3 没有，这一事实不会变。

在请求层面，每秒 1,068 个 token 意味着什么

每秒 token 数是个糟糕的决策单位，因为没人购买 token。他们购买的是已完成的请求。把这两个数字都转换成用户实际体验到的东西——生成一个千 token 回答需要多长时间。

在 Inception 声称的每秒 1,068 个 token 下，一个 1,000 个 token 的回答大约需要 0.94 秒的生成时间。而在 MiniMax M3 实测的 106.4 个 token/秒下，同样的回答大约需要 9.4 秒。再把 M3 实测的 1.13 秒首 token 时间算进去，两种体验之间的差距大约就是十倍——这还没有计入网络延迟、排队或提供商自身的开销。

Mercury 3 的情况正是如此，而且这是一个真实的案例。生成时间相差十倍，就是"感觉瞬间即得"的搜索答案与"感觉像在加载页面"的搜索答案之间的差别。Inception 的整条产品线正是围绕这一点构建的：公司销售 Mercury Voice 主打首答案 token 的延迟，销售 Mercury Decide 主打分类，并将旗舰产品定位在客服、辅导、搜索和网页智能体等场景——在这些工作负载中，答案慢就意味着产品已经坏掉，而不只是稍差一些。

十倍这个数字并不能告诉你 Mercury 3 到底好不好。Mind2Web 的结果——在 50 个实时任务上完成率为 50%，"显著高于 GPT-6.1-Sol"——是 Inception 发布的唯一结构化质量信号，而 50 个任务这个样本小到只要有一个难处理的网站，就能让百分比变动两个点。评测框架是 Inception 自己的。对比模型只给出了名字，没有给出分数。这确实是一个信号，说明该模型能够驱动浏览器，但它不是一个你可以放进采购决策里的测量结果。

MiniMax M3 的纪录究竟说明了什么

M3 的独立表现并不光鲜，但很实用。其智能指数为 29，而同对比类别模型的中位数为 19；输出速度为每秒 106.4 个 token，而中位数为 77.4；首 token 时间为 1.13 秒，而中位数为 1.70 秒；每个模型运行该指数的成本为 0.51 美元。这是一款在其类别中质量远高于平均水平、就其规模而言速度明显高于平均水平且运行成本低的模型。

同一指数家族经第三方转载后流传开来的各项子分数，则讲述了一个更具体的故事：在文档理解和指令遵循方面表现强劲，在自主多步骤智能体工作方面则较弱。其编程与智能体子分数之间的差距，是该记录中最大的内部分差。如果你的工作负载是“读完这份长文档并精确作答”，M3 有充分证据支撑。如果是“连续运行二十分钟并交付成果”，证据则更薄弱，且指向相反的方向。

对于 Mercury 3，没有可供撰写的对应段落，因为相关数据并不存在。Artificial Analysis 没有 Mercury 3 页面——其索引仍列出 Mercury 2.5 和 Mercury 2——因此在该模型发布一天后，它没有独立评分、独立速度数据，也没有每任务成本数字。Inception 的对比集合（GPT-6 Luna、Claude Haiku 5.5）属于快速层级而非前沿层级；对于一款延迟敏感型产品而言，这是正确的对比对象，但该说法没有给出领先幅度，也没有测试名称。

价格差距比价签所显示的要小

人们的本能反应是把 Mercury 3 称为经济之选，把 M3 称为昂贵之选。按 token 计算，这个方向大体没错，但远没有看上去那么夸张：Mercury 3 的输入价格便宜 1.5 倍，输出价格便宜 1.7 倍。这算不上不同级别，只是不同货架而已。

运行一个具体的工作负载。以每天处理 10,000 条回复的客服或搜索助手为例，每条回复包含 1,500 个输入 token 的检索上下文和提示脚手架，以及 300 个输出 token。也就是每天 1,500 万个输入 token 和 300 万个输出 token。

• Mercury 3 按标价 — 15 × $0.20 加 3 × $0.70，即每天 $5.10

• Mercury 3 按上线费率——15 × $0.10 加 3 × $0.35，即每天 $2.55

• MiniMax M3 按其小请求费率计算——15 × 0.30 美元 + 3 × 1.20 美元，即每天 8.10 美元

因此，在 1 万次对话中，这两个标价之间的每日差价约为 3 美元。如果 Mercury 3 在其默认低投入设置下的 token 效率比 M3 更差——而 Inception 之外没人知道，因为 Mercury 3 没有实测的输出 token 数——那么这 3 美元的差距在真实流量下可能缩小甚至反转。这正是未评分模型难以做预算的具体原因：没有实测的完成率和实测的冗长程度，就无法计算每个已完成任务的成本。

缓存输入这一项对智能体工作负载来说比主打数字更重要，因为智能体在每一步都会重新发送相同的系统提示和工具定义。Mercury 3 每百万缓存 token 收费 $0.02，使得 20,000 token 的前置内容每次调用成本为 0.0004 美元。M3 的 $0.06 是它的三倍，这仍然很小——但在五十步的运行中，差距是几美分，而不是不到一美分的零头，而智能体流量正是几美分会成倍放大的地方。

许可证、退出以及你无法下载的东西

MiniMax M3 以 MiniMax 社区许可证发布。非商业用途免费；商业用途则需展示“Built with MiniMax M3”，年收入低于 2000 万美元时需作一次性告知，超过该门槛则需事先获得书面授权，并遵守禁止用途附录。这更像是一次法律审查，而非走个形式，但它是你在开始构建之前就能读完的许可证。

Mercury 3 没有可供阅读的许可证，因为没有什么可授权的。它是闭源的。这并不自动构成否决理由——大多数通过 API 调用模型的团队从不接触权重——但它会改变一旦 Inception 更改其价格、条款或可用性时会发生什么。退出是一次迁移，而不是重新部署。

还有一个值得指出的不对称之处：M3 已有四个月的运行记录。它出现在我们的产品目录中已经足够久，积累了流量和延迟百分位数据，而且其价目表一直保持稳定。Mercury 3 才上线一天，其发布价格没有公布结束日期，而它的前代模型已经不再向新用户开放——Inception 自己的迁移说明称，Mercury 2 和 Mercury 2.5 将停止接受新注册，现有客户将于 2026 年 11 月 15 日失去访问权限。一个如此迅速地淘汰一条模型产品线的厂商，其实是在向你传递一个信号：它期望你如何消费其产品。

路由器改变算术的地方

这组对比很好地说明了第一周为什么根本不该做选择。MiniMax M3 已在 OrcaRouter 上线，输入每百万 token 0.30 美元、输出每百万 token 1.20 美元，这是该服务商的标价，没有任何加价，并与另外 200 多个模型一起，通过一个 OpenAI 兼容端点提供。Mercury 3 不在我们的目录中——检查我们的模型 API 时，任何 Inception 模型都查不到——所以任何想调用它的人只能去 Inception 自己的平台，或去 Inception 列出的某个第三方托管商。我们宁愿把这一点说清楚，也不愿暗示一条我们并不拥有的调用路径。

适合尚未经过实测、发布速度异常快的场景的模式是双路径设计。把对延迟至关重要的层级通过供应商放在 Mercury 3 上，并把经过实测的备用方案保留在 M3 或我们提供的其他模型上，同时接好自动故障转移，确保 429 或端点降级不会让该功能不可用。路由 DSL 的存在正是为了让这种拆分成为一条规则，而不是代码库中的分叉；而且因为 供应商的目录价会原样传递，Inception 的降价或 MiniMax 的层级变更会在宣布当天就反映到你的账单上，而不是等到下一份合同。

这个设计并不能为你带来 Mercury 3 方面的质量保证。目前还没有任何东西能做到这一点。

本周要应用的规则

• 如果答案必须在大约一秒内返回，而且错误答案可以挽回——搜索建议、支持分诊、辅导提示、带有升级路径的智能体步骤——那么仅凭其延迟方面的宣称，Mercury 3 就值得花一周进行评估。预算要按标价来算，而不是按 50% 的发布优惠价，因为该折扣没有公布结束日期。

• 如果你需要在做出决定之前了解这款模型到底有多好，那么在这两者之中，只有 MiniMax M3 能让你做到这一点。它也是这两者中唯一一个你可以下载、量化、微调，或运行在自己硬件上的模型。

• 如果你的工作负载需要读取视频或图像，那么比较就到此为止了。M3 能处理它们；Mercury 3 不能。

• 如果你优化的是每个已完成任务的成本，而不是每个 token 的成本，那么这两个模型目前都还无法给出你需要的数字——M3 是因为其代理能力上的弱点已经过实测且确实存在，而 Mercury 3 则是因为其任务完成行为完全未经测量。

真正需要关注的不是 Mercury 3 的价格，而是 Mercury 3 的首次独立评估——无论它何时出炉。如果其吞吐量宣称能在中立测试框架下复现出接近每秒 1,068 个 token 的成绩，并且质量达到 Inception 所宣称的 Haiku 级别，那么这就不再是一场对比，而会成为 Web 上每一个受延迟约束的产品都要面对的迁移问题。如果它落在厂商宣称与独立评测之间常见的折扣水平，且质量只是有竞争力，那么诚实的总结就是上面那句：一个快速、便宜但未经证实的模型，对阵一个更慢、便宜但已被证实的模型——而对大多数团队来说，在另一方拿出实测数字之前，得到生产路径的是已被证实的那一方。