MiniMax M3的发布不仅刷新了国产开源模型的性能上限，更关键的是它首次将长上下文、Agentic Coding和原生多模态三大核心能力整合在单一模型中，彻底改变了AI工作流的拼接架构。本文从实际应用场景出发，深入剖析M3如何通过1/20的计算成本突破，让曾经因成本过高而搁置的产品方案重获商业可行性，同时揭示开源生态可能面临的重新洗牌。

5 月 31 日下午，MiniMax 把 M3 发了出来。

那天我正在帮一个客户跑一份 80 多页的 PRD 评审，Opus 4.7 那边账单跳得心疼，Sonnet 4.6 又总在长上下文的中段开始胡说。看到 M3 的发布消息，我第一反应跟很多人一样——又一个国产模型跑分超过了 Anthropic，标题党。

技术报告甩出 SWE-Bench Pro 59.0%、BrowseComp 83.5，我扫了一眼默默关掉。心想跑分这种东西，过两个月就被新模型刷下去了，不值得当天追。

但接下来一周，我用 API 和 MiniMax Code 把它接进了团队几条线上跑的流程，跑了几天之后，我承认我的判断慢了。

M3 不是又一个跑分超 Opus 的模型，它是国产开源里第一个把“长上下文”“Agentic Coding”“原生多模态”这三件事，同时焊在一颗模型里的。

这件事比跑分本身重要得多。

一、所谓”三件套合一”，到底解决了什么

做 AI 产品这几年，我见过最痛苦的一类架构图，是这样的。

代码相关任务走 Claude Opus 4.7，长上下文任务走 Gemini 3.1 Pro，涉及图像/视频的多模态任务再切一刀去 GPT-5.5。三家 API、三套 token 单价、三套 rate limit、三套 prompt 风格。每次工作流跨节点，就要把状态序列化一次、反序列化一次，信息损耗在 20-30% 这个量级，有时候更高。

这种架构说白了，就是你的 AI 工作台，是租了三家不同的工位拼起来的。

M3 第一次让这件事在开源模型里变成了”一张桌子”。SWE-Bench Pro 59.0% 这个数，意味着它的 Coding 不是”能写小函数”的水平，是能接住 Agent 框架里实际任务调度的水平;BrowseComp 83.5 超过 Opus 4.7 的 79.3，意味着它能撑起多步骤工具调用而不在中间断链;1M 上下文加上原生多模态，意味着你可以把”读一份带图的长报告”这件事真的塞进一次推理里。

不是性能维度的赢，是工作流维度的赢。

我那天把客户那份 80 多页 PRD 加上里面 14 张产品截图，一次性丢给 M3，让它直接出”前后矛盾的需求点 + 视觉规范不一致的截图编号”。这件事在过去要跨两个模型——文本走一个、图走一个，然后我自己手工 merge。现在是一个 API 调用。

二、跑分不是重点，重点是它怎么贵

跑分这件事，我看了七八年大模型，已经学会不当回事。任何一家公司发新模型的当天，跑分都好看。

真正决定一个模型能不能进生产的，是它的钱包效率，不是它的智商。

M3 把跑分拉到了 Opus 4.7 附近，这件事在大模型评测圈被讨论得最多。但更值得讨论的是另一组数字:1M 上下文下，每 token 的计算量是上一代的 1/20。

这个 1/20 不是”省了 5% 的成本”。它是把”1M 上下文这件事能不能落地”从一个学术问题变成一个商业问题。

过去半年里，我至少劝退过三家客户的”超长上下文”需求——不是技术不行，是 API 账单上算下来，他们这套流程每个月要烧掉的钱，远高于他们能从这套流程里赚到的。

1M 不是一个跑分指标，是一个账单指标。

如果 MSA(MiniMax Sparse Attention)真的能把单 token 的计算量压到 1/20，那很多过去因为成本算不过来而砍掉的产品方案，值得重新算一遍账。

我已经把上周二砍掉的一个”全文档智能问答”方案，重新拉回了我的待跟进列表。

三、MSA 让”长上下文”第一次和钱包对齐

稀疏注意力这件事不是 MiniMax 第一个做的，Anthropic、Mistral、Kyutai 都各有方案。但开源模型里把稀疏注意力做到 1/20 计算量、还同时维持 SWE-Bench Pro 59.0% 这种水平的，M3 是头一个。

更关键的是它开源了。

不开源意味着所有的”我们模型很省”都只是发布会上的演示。开源意味着你可以自己跑、自己测、自己把它部署到自己的 GPU 上算成本。

这是国产模型这几年第一次，把“省”这件事做成了一件可验证的事，而不是 PPT 上的事。

我自己手头还没来得及做完整的横评，这块我必须诚实地承认:1M 上下文塞到 80 万 token 之后，中段记忆衰减到底有多严重，我手上的样本量太小，只能说”目前我跑过的几个场景没出现明显遗忘”。这块欢迎做长上下文压力测试的同行在评论区拍砖。

但即便打个对折，如果它的实际效率只有宣称的一半，这件事对开源生态也仍然是一次重置。

四、为什么我还没立刻把 Opus 那条线砍掉

写到这里有人可能会觉得我在吹。不是。

虽然 M3 让我对国产开源的判断变了，但我没有立刻把团队 Opus 4.7 那条线砍掉，有四个我自己不放心的点。

第一，Computer Use 我只跑了两个 case，样本太少。M3 号称能操作桌面，这件事在 Anthropic 这边走了大半年才相对稳定。开源模型在 Agent 工作流里的稳定性，需要更多线上时间来验证，跑两个 case 看着好不代表跑两万次还好。

第二，中文场景的细分能力，我没看到充分的对比数据。M3 的跑分集中在英文 benchmark，但我们国内的客户场景——特别是金融、法律这种带强中文术语的——和英文 benchmark 的分布差异很大。这一块需要等更多国内团队的实测出来。

第三，Tool Use 的”长链条稳定性”还没充分压测。BrowseComp 83.5 是好，但 BrowseComp 的链条长度有限，真实业务里 Agent 一跑跑七八个工具调用，中间任何一步格式跑偏全盘崩。这块 Opus 4.7 是行业里目前最稳的，M3 还没经过同等量级的线上压测。

第四，生态周边没跟上。Anthropic 这边有 MCP、有 Computer Use SDK、有相对成熟的 prompt 缓存，M3 这边的工具链、文档、社区案例都还在早期。

模型本身只是产品决策的一部分，生态成熟度往往才是真正的换型阻力。

所以我现在的实际操作，是把团队三条主线里那条”长上下文+多模态+成本敏感”的线先迁过去，Coding/Agent 那条线在 M3 上观察一个月，Computer Use 那条还在 Opus 这边。

写在最后

M3 这件事，我自己的判断分成两层。

技术上，它确实是国产开源模型这几年最有分量的一次发布——把过去要拼三家模型才能做完的事，焊成了一条产线。

但选型上，它对大多数还在用 Opus 4.7 / Gemini 3.1 Pro 的团队来说，不是”立刻换”，而是”立刻评估”。这两件事中间隔着一个月的真实业务数据。

如果你也在做 AI 产品，我比较好奇的是——

你手上有哪条线，是过去因为“成本算不过来”被砍掉的?如果 MSA 那个 1/20 是真的，这条线值不值得重新算一遍?