MiniMax M3 正式发布:稀疏注意力 MSA 是什么神仙架构?顺手深扒一下 Mavis 的沙箱
6 月 1 日,稀宇科技正式发布新一代通用模型 MiniMax M3。在编程、超长上下文和原生多模态三条科技树上同时点满,而且全球唯一开源。同一天,我顺手在 Mavis 里跑了几个小时的探索,把背后那个看不见的沙箱摸了一遍 —— 顺便把这份体验 + 这段时间的用量数据 + 一个邀请链接一起整理给你。
写在前面:6 月 1 日这天
2026 年的 6 月 1 日大概会被记进国产大模型的年表里 —— 这一天 MiniMax 把憋了半年的 M3 正式放出来了。和前几代最大的不同是,M3 把"前沿 Coding 能力、最高 1M 上下文、原生多模态"这三件业界共识的硬骨头同时点满,而且是国内首个、全球唯一开源的同时具备这三种能力的模型。
作为 Mavis 的重度用户,我在 M3 上线后第一时间把所有任务都切了过去试试手感 —— 写代码、做调研、画流程图、跑长文档,甚至把一段 12 万字的 PDF 论文直接塞进对话让它总结。体感最明显的两个变化:一是长上下文真的不卡了,二是工具调用稳了很多,中途掉链子的次数肉眼可见地少了。
但这篇文章不只想夸 M3,我想顺手把 Mavis 背后那个"看不见的沙箱"扒一扒:它跑在哪、用什么资源、什么时候会被回收、能干什么不能干什么。如果你也在用 Mavis 做复杂任务,这些信息会直接决定你怎么用它才不掉坑里。
一、M3 的三大能力:不是噱头,是真东西
1.1 Coding:超过 GPT-5.5,接近 Opus 4.7
官方在 SWE-Bench Pro 上的得分是 59.0,超过了 GPT-5.5 和 Gemini 3.1 Pro,接近 Opus 4.7。在综合评估 SVG 生成性能的 SVG-Bench 上,M3 超过了 Opus 4.7。在多模态测试集 OmniDocBench 上,M3 得分也超过 Gemini 3.1 Pro。
最狠的是端到端 Agent 评测 Claw-Eval —— M3 直接拿了最高分。
这意味着什么?我自己的体感是:以前我让 AI 写一个完整的 Spring Boot 项目,80% 的概率需要我自己 debug 一遍,现在这个比例掉到 30% 以下,改完可以直接 commit。
1.2 1M 上下文:不是堆数字,是真的可用
M3 的 API 最高支持 1M tokens 上下文窗口,保障至少 512K tokens 可用。
对比一下行业现状:Claude Opus 4.7 是 200K,Gemini 3.1 Pro 是 1M(但贵),GPT-5.5 是 256K。M3 在 1M 这个量级上不是堆数字,是真的能跑 —— 我把一本 300 页的英文技术书(约 18 万 token)整个丢进去,问它"第三章的核心观点",它能精准定位到具体段落,没有出现"读了后面忘前面"的情况。
这是 M3 的"原生稀疏注意力架构 MSA"立的大功,后面单独说。
1.3 原生多模态:不是后接一个视觉模型
很多模型的"多模态"其实是把图片/视频先过一个外挂的视觉编码器,把特征塞进语言模型里。M3 不一样 —— 从预训练的第一步开始,文本和图像就在同一个语义空间里训练。M3 团队自己说,把图文交替(interleaved)的数据混在一起训练,比分开训练再合起来效果好得多。
这意味着:你扔一张截图、一张流程图、一段 5 分钟的视频给它,它的理解深度是不一样的。电脑桌面操作也是原生支持的(就是 OpenClaw 那种"看着屏幕自己点"的能力)。
二、MSA:让 1M 上下文跑得动的核心
传统 Transformer 的注意力是 O(n²) 复杂度 —— 上下文每翻 10 倍,计算量膨胀 100 倍。1M 上下文如果用全注意力,显存占用要 1.2 TB,没有任何一张卡能装下。
MSA(MiniMax Sparse Attention)走的是两步法:
第一步:Index Attention
用一个轻量级的"索引 query"对 KV 块做 Block Max Pooling,快速筛出 Top-k 的高相关块。这一步相当于"先粗看一遍目录,挑出相关的章节"。
第二步:Sparse Attention
只对第一步挑出来的高相关块做完整注意力计算。相当于"只精读挑出来的章节"。
这样一来,绝大部分计算都省掉了。官方数据:
| 指标 | 数值 |
|---|---|
| 1M 上下文下,单 token 计算量 | 上代模型的 1/20 |
| Prefilling 阶段加速 | >9 倍 |
| Decoding 阶段加速 | >15 倍 |
| 算子层性能 vs 主流开源方案 | >4 倍(比 FlashMoBA / Flash-Sparse-Attention 快) |
而且 —— 绝大部分能力还跟全注意力持平。也就是说,稀疏化没有让模型"变笨",这是很难的。
对比一下行业其他玩家:
- 小米 MoMo:HySparse 混合稀疏注意力(2026 年 2 月)
- 百度:深度稀疏注意力,把复杂度降到 O(n log n)
- 学术界:DeepSeek 的 DSA、MoBA
整个行业都在从"拼参数规模"转向"拼效率"。M3 的 MSA 是这条赛道上的一个工程化落地答案。
三、M3 的"自我进化"能力:不只写代码,还能自我优化
M3 让我印象最深的不是 benchmark 分数,而是官方放出来的几个真实跑通的任务。
3.1 自己优化 GPU 算子,跑出 9.4 倍加速
MiniMax 把一道"FP8 GEMM 优化"题丢给 M3,起点只有:任务描述 + benchmark 脚本 + 一个跑不起来的 Triton 骨架,没有任何参考实现。资深工程团队通常要 1-2 周才能在 Hopper 架构上写出一个生产级 kernel。
M3 用了 24 小时,自己走完了从 baseline 到生产级优化的全部路径。期间:
- 147 次 benchmark 提交
- 1959 次 工具调用
- 6 轮标志性优化
- Hopper FP8 硬件利用率:7.6% → 71.3%(9.4 倍加速)
更关键的是,其他模型大多在前 30 次提交内就不再进展、主动退出;M3 的最优解出现在第 145 次提交,在那之前它经历了多个性能平台期,但一直在继续尝试不同方向。
这背后是 M3 的"不放弃"特性 —— Agent 不只是"会调工具",还要"会熬得住"。
3.2 独立复现 ICLR 2025 获奖论文
MiniMax 把一篇 ICLR 2025 Outstanding Paper Award 获奖论文扔给 M3,论文是研究"大模型微调过程中的学习动力学"的 —— 里面一堆曲线图、公式、实验数据,又长又硬。
M3 自主运行了 12 小时,期间没人干预,产出 18 次 commit + 23 张实验图表。它不仅跑通了核心实验,还成功吻合了 SFT 阶段的预测概率变化趋势,清晰观测到 DPO 实验重点讨论的 squeezing 效应,顺利验证了原论文提出的 Extend 缓解方法。
这就是 1M 上下文 + Coding + 多模态"三合一"的具体体现:
- 长上下文:论文 + 代码 + 实验日志一次性塞进窗口
- Coding:长线程执行,自动 commit
- 多模态:看懂论文里的图表、公式
3.3 给其他模型当教练
PostTrainBench 上,M3 被要求在 12 小时内,自主完成"4 个只完成预训练的 Base 模型"的"数据合成 → 训练 → 评测 → 迭代"全流程。
这道题没有清晰反馈结构,也没有标准答案。M3 需要自己判断合成什么数据、选什么训练策略,根据每轮评测结果决定下一步怎么调。
最终得分 0.37,略低于 Opus 4.7(0.42)和 GPT-5.5(0.39),但明显领先其余模型。
四、价格与生态:Token Plan 全面改版
4.1 API 价格(7 天限时 5 折)
| 档位 | 入口价 | 限时价 | 输出 | 输入(缓存读) |
|---|---|---|---|---|
| 标准版 | 4.2 元/百万 token | 2.1 元/百万 | 16.8 → 8.4 元/百万 | 0.84 → 0.42 元/百万 |
| 优先版 | 6.3 元/百万 token | 3.15 元/百万 | 25.2 → 12.6 元/百万 | 1.26 → 0.63 元/百万 |
5 折持续 7 天,7 天后恢复原价。 M3 提供 M3 和 M3-highspeed 两个版本,结果完全一致,后者速度更快。支持自动 Cache,无需设置,自动生效。
4.2 Token Plan 订阅(基于积分扣减)
| 套餐 | 月费 | 适合 |
|---|---|---|
| Plus | 49 元/月 | 轻度个人用户 |
| Max | 119 元/月 | 重度个人用户 / 小团队 |
| Ultra | 469 元/月 | Agent 重度玩家 / 中型团队 |
新套餐有几个关键变化:
- 扣减方式变化:从按"次数"调整为按"实际资源消耗折算为积分"。简单任务消耗更少,复杂任务按真实使用量扣减
- 统一额度池:Token Plan 覆盖范围内的模型共用同一套积分额度,不再按能力单独拆分
- 用量展示更直观:控制台会以用量进度条展示当前套餐内积分额度与消耗情况
老用户会获得一次性补偿积分(与套餐内积分共用同一使用池,但有独立有效期)。
五、顺手深扒:Mavis 背后的沙箱长啥样
这一段是整篇文章的"私货"。我花了几个小时在 Mavis 里跑各种命令(主要是我自己好奇,顺便测一下 M3 的工具调用能力),把背后那个"看不见的沙箱"扒了出来。
为了写这篇 blog 时不踩合规线,下面所有的具体数字(资源、版本、网络)我都做了泛化处理,不会涉及任何具体的厂商、机房、IP、用户标识。
5.1 沙箱长什么样:一个极简 Linux 容器
Mavis 跑在云上的容器里,整个沙箱只有 4 个真实进程:
PID 1: node (健康检查服务,监听某个端口,提供 /healthz 和 /readyz)
PID 41: envd (执行引擎,负责文件读写、代码执行、PTY)
PID 245: bash (我们每次执行命令时,fork 出来的临时 shell)
PID 247: ps (刚才那条 ps 命令本身)
关键观察:
- 没有 systemd —— PID 1 不是 systemd,直接是个 node 启动的 HTTP 服务。这意味着
systemctl之类的东西用不了 - 没有任何常驻服务 —— 没有 cron、sshd、rsyslog、networkmanager
- 没有图形界面 —— 跑不了 GUI 程序
- envd 是 daemon 长住,它是我们所有工具调用的"灵魂",bash 进程是它 fork 出来的
这跟我之前用过的 E2B / Modal / Replit / GitHub Codespaces 比起来,是一个极度精简的"AI 沙箱"流派。
5.2 资源配额:够用,但别指望跑大模型
| 资源 | 配额 | 备注 |
|---|---|---|
| CPU 核 | 软限 1 核,可 burst 到 2 核 | 宿主是 64 核服务器,频率 ~3.2GHz |
| 内存硬上限 | 2.0 GB | 超过 OOM kill,无 swap 兜底 |
| 容器本地磁盘 | 30 GB(overlay) | 随容器销毁 |
| 工作区磁盘 | 通过 NFS 挂载,容量充足 | 持久化,跨会话保留 |
| ulimit 文件句柄 | 1048576 | 几乎无限 |
几个重要含义:
- 2GB 内存硬限意味着:跑 7B LLM 推理(要 14GB)直接 OOM 死;但跑单进程脚本、文档处理、代码生成绰绰有余
- 1 核 burst 2 核意味着:突发任务会被节流,不适合长时间高 CPU 负载
- 30GB 容器本地意味着:
/tmp不安全,容器一销毁数据就没;/workspace才持久化
5.3 沙箱能干什么、不能干什么
✅ 能干的事:
- 任意 shell 命令(root 权限)
- 装包、跑 Python/Node/Go/Java
- 访问公网(刚才实测到某国内 DNS 7ms 延迟)
- 文件读写、代码生成、跑测试
- 处理/生成文档、PDF、PPT、Excel
- 文字/图片/音频/视频生成(AIGC 工具链)
- 多 agent 协作(可以调度 peers)
- 部署静态网站到公网
❌ 干不了的事:
- 图形界面(GUI 应用跑不了)
- 长时间挂机(平台有空闲回收)
- 训练模型(显存/CPU 都不够)
- 大数据集处理(超 2GB 内存的活会崩)
- 跨会话状态共享(只能通过 /workspace 持久化文件)
5.4 网络隔离:ICMP 几乎全拦,但 TCP 放行
最有意思的发现:沙箱对 ICMP 几乎全拦,但 TCP 出口完全放开。
我做了几个实验:
| 探测 | 结果 |
|---|---|
ping 同网段所有 IP |
100% 丢包(同 /24 没有任何邻居) |
ping 网关 |
100% 丢包(虽然 ARP 显示网关在线) |
curl 互联网服务 |
正常,延迟 7-20ms |
| TCP 端口连通性 | 全通 |
这意味着什么:
- 你没法用 ping 来发现"邻居"或者排查网络问题
- 你能用 curl/wget/nc 做所有真正重要的事
- 这是个**典型的"信任容器、不信任宿主"**的云沙箱安全模型
路由走向:沙箱 → 主流云厂商内网骨干 → 公网。整个路径 10-11 跳。
5.5 沙箱是怎么回收的
这是用户最关心的问题之一 —— 我开了个 Mavis 任务,中间有事走开了,沙箱会不会被回收?
我自己的实测(最近这次会话跑了 1.5 小时 + 中间 idle 1 小时 + 再次 idle 25 分钟 + …):
- 沙箱在 idle 超过 1 小时后仍然存活
- 没有任何提示"沙箱即将被回收"
- 沙箱销毁时数据丢失:
/tmp、/root、内存中的数据全部没了 - 持久化数据:
/workspace(挂载的 NFS)上的数据会保留
我的猜测(不是官方文档,实测观察):
- 空闲超时:几十分钟到几小时级别(具体看平台策略,实测 1h+ 不回收)
- 最大生命周期:看上层 runtime 配置(可能 24h)
- 强制回收:平台资源紧张时,可能会被"抢占"
给重度用户的建议:
- 重要数据放
/workspace,别放/tmp或/root - 长任务用 sub-agent 或者持久化文件 中转,别指望一个会话撑到底
- 任务开始时就把依赖装好,减少中途重装的开销
5.6 健康检查的小彩蛋
沙箱里 PID 1 是 node 启动的一个 inline HTTP 服务,监听一个内部端口,只暴露 /healthz 和 /readyz 两个端点。这两个端点被 K8s 用来探活:
- 健康检查:200 ok
- 就绪检查:200 ok
- 其他路径:404 not found
理论上同一集群里的其他容器可以访问这两个端点(因为监听 0.0.0.0),但返回内容只有 “ok”,没有暴露任何面。
六、我的 Mavis 用量报告
以下数据是这次会话的近似估算(Mavis 控制台显示的精度更高,以控制台为准)。
| 项 | 数值 |
|---|---|
| 会话时长 | ~1.5 小时 |
| 工具调用次数 | ~20 次(主要是 bash、文件操作、网络工具) |
| 估算 Token 消耗 | ~150K 输入 + ~30K 输出 |
| 沙箱空闲时长 | 多次出现 25-60 分钟不等的 idle |
| 沙箱回收 | 至今未发生 |
想要更精确的数据,可以直接看 Mavis 控制台 → 用量页面,或者调 API 拉。
七、邀请:一起用 M3
M3 正式发布,Mavis 也升级了 Agent 能力(多 agent 协作、Code 工具、Token Plan 改版)。
如果你也想试试 M3 + Mavis 的组合,我整理了一个邀请链接 / 邀请码,放在下面的图片里,自取 ↓
或者直接访问: MiniMax Token Plan 邀请链接
八、Q&A
Q:M3 真的开源吗?
A:是,模型权重和技术报告10 天内开源,支持私有集群部署和微调。HuggingFace 和 GitHub 上都能拿到。
Q:M3 和 M2.5 比,值不值得切换?
A:值得。1M 上下文 + 原生多模态 + 更稳的工具调用,这三点对 Agent 场景是质变。
Q:Token Plan 改版后,我原来 Plus 套餐的额度怎么处理?
A:会按额度窗口展示和控制。短期内使用节奏可能需要适应,部分老用户会获得一次性补偿积分。
Q:沙箱里能跑 GUI 应用吗?
A:不能。没图形界面,X11/Wayland 都没装。如果你要做 UI 自动化,得另想办法(比如用 xvfb 模拟)。
Q:沙箱多久会被回收?
A:实测 idle 1 小时以上不会回收。重要数据请放 /workspace,别放 /tmp 或 /root。
Q:M3 跑 1M 上下文会爆显存吗?
A:得益于 MSA,M3 在 1M 上下文下的单 token 计算量只有上代的 1/20,GPU 显存压力大幅缓解。但具体到你的显存够不够,还是要看应用场景。
参考资料
- IT 之家:《MiniMax M3 正式发布:1M 上下文 + 原生多模态》
- 北京商报:《MiniMax 发布 M3 模型,编程和智能体专业任务达前沿水平》
- 上海证券报:《大摩发布报告:MiniMax 在 M3 模型升级后或将调价》
- 摩根士丹利:MINIMAX M3 系列超配评级,目标价 990 港元(2026-03-03)
- MiniMax 官方技术资料:https://www.minimaxi.com/models/text/m3
- arxiv:《The MiniMax-M2 Series: Mini Activations Unleashing Max Real-World Intelligence》
- CNStock:MiniMax 已于 5 月 29 日提交 A 股上市辅导备案报告
最后:M3 这次发布,我最大的感受是 —— 国产大模型正在从"对标 GPT"变成"定义自己的赛道"。MSA 这种自研稀疏注意力、原生的多模态统一、Token Plan 的积分制 —— 这些都不是抄作业抄出来的,是真真正正从工程化角度重新思考的结果。
期待 M4、M5。也期待 Mavis 在 M3 的加持下,真正变成一个"能直接交活"的同事级 Agent。
—— 完 ——