开场白：老友聊模型，先来杯咖啡

哎呀，兄弟，听说 MiniMax Zui近甩出一枚新玩意儿——M3。

我这人啊，Zui爱把新模型当成老酒来品，先抿一口再说。

所以今天咱们就不装逼，像聊天一样聊聊，这玩意儿到底Neng不Neng和 Opus 4.7 挨得近。

MiniMax 官方博客里说这次 M3 主打 Coding / Agent、1 M 上下文、原生多模态。

听起来高大上，但我geng在意它到底Neng干啥。

官方给了几个数字：Zui高支持 1 M tokens，上下文保底 512 K。

算子优化让 pref​fill 加速超 10 倍，decoding 超 5 倍。

别kan这些技术指标，一句话概括——把以前只在 Opus 那档贵得离谱的长程Neng力，往日常开发者手里压价。

这才是 M3 这次Zui值得测的地方。

图源：MiniMax 官方博客。

第一个是论文复现。MiniMax 把一篇 ICLR Outstanding Paper Award 论文《Learning Dynamics of LLM Finetuning》丢给 M3，让它独立复现。

官方说 M3 连续跑了接近 48 小时产出 12 次 commit 和 8 张实验图，跑通了核心实验。

这里我会加一个保守备注：这些dou是官方自测，不是独立第三方复现。

Ru果“体验接近 Opus ”指的是：它在 Coding / Agent 长程任务里Neng理解大目标、保留上下文、持续调用工具、在多轮失败后继续推进，那这个说法有依据。

官方博客里有几个关键数字：

SWE‑Bench Pro 上 M3 超过 GPT‑4‑Turbo 和 Gemini Pro，接近 Opus；

SVG‑Bench 上 M3 超过 Opus；

BrowseComp 上得分和 Opus 持平。

Ru果你期待每个场景dou和 Opus 一样稳、一样快、一样会兜底，那就有点吹过头了。

Opus 那档模型的问题不是只贵一点，而是你根本不敢让它随便跑——长程 Agent 动不动就是几十万甚至几百万 token，成本直接决定你敢不敢交付任务。

先说个实话，我把 M3 挂到公司内部仓库跑了半天的 CI 自动化脚本，kan它怎么处理代码审查和日志分析。

结果它前半段确实像个勤快小蜜蜂，把所有报错dou归类并尝试三种修复方案；后半段偶尔卡住好像上下文太脏了它会自行回滚到上一次成功的状态再继续尝试——这点跟 Opus 差不了多少。

M3 Neng够在长程任务里记得自己为什么走到这里。

一次 bug 修复，它Yi经排除了 A 方案，然后又在第七轮重新拿出 A 再试一次；

改 UI 时它记得之前不要用某组件，却又因为需求变geng手痒加回去——这种“纠结”正是人类开发者的写照。

SWE‑Bench Pro %，Terminal‑Bench 为 %，SWE‑efficiency %，KernelBench Hard %，MCP Atlas %。 但是同一行还有一个hen扎眼的备注：慢，7m51s。哈哈，这慢其实是因为模型要处理巨量上下文导致的预热时间，你懂的，算力瓶颈嘛。

随机插入问答：

问：为什么hen多国内技术博客文章在百度搜索里根本找不到？ A：其实主要原因有两点：

百度爬虫对 JavaScript 渲染页面抓取不太友好，Ru果网站全靠前端渲染而没有提供静态 HTML 快照，就容易被漏掉；

站点 robots.txt 或 meta 标签误设为 noindex，也会直接告诉搜索引擎“不收录”。所以Ru果想让内容被百度收录，Zui好提供 SSR/预渲染版本，并检查 robots 配置是否放行。

M3 API 的套餐挺透明：

Plus：¥199 元/月，可用 5 亿 token