MiniMax M3 只有 428B 参数，凭什么拿来和 DeepSeek、Kimi、Qwen 比？

MiniMax M3 开源后，我第一眼注意到的是它其实没那么大。

428B 总参数，23B 激活参数。这个数字单独看当然不小，但放到现在国产开源旗舰模型里，就有点微妙了。

DeepSeek-V4 Pro 是 1.6T 参数，Kimi K2.7 Code 也到了约 1T。相比之下，MiniMax M3 只有 428B。

所以问题来了：

一个参数规模明显小一截的模型，为什么还值得拿来和 DeepSeek、Kimi、Qwen 放在一起比？

答案在于，它在 428B 这个规模下，塞进了几件现在很要命的东西：1M 上下文、23B 激活参数、原生多模态、MiniMax Sparse Attention，还有面向编程和 Agent 的定位。

这篇文章就从这个反差讲起。MiniMax M3 到底小在哪里，又为什么还能被放到这张桌子上。

一、MiniMax M3 到底开源了什么？

MiniMax M3 已经在 Hugging Face 上开放权重。

模型卡里能确认的信息大概是这些：

这里最值得看的，不是 428B，而是 23B 激活参数。

M3 是 MoE 架构。总参数放在那里，但每次推理只激活约 23B 参数。也就是说，它不是每次都把全部参数跑一遍，而是靠稀疏激活，在能力和成本之间找一个平衡点。

428B 这个数字的微妙就在这里。

它不是小模型。没人会说 428B 小。但它也没有大到 DeepSeek-V4 Pro、Kimi K2.7 Code 那个级别。真正让它值得讨论的，是它在这个体量里，把 1M 上下文、多模态、编程和 Agent 都放进来了。

二、428B 为什么还能拿来比较？

如果只看总参数，MiniMax M3 确实不是最大的。

放在几个国产开源旗舰旁边看，差距很直观：

这张表里，MiniMax M3 的位置很清楚。

它没有 DeepSeek-V4 Pro 那么大的总参数，也没有 Kimi K2.7 Code 那种接近万亿级的规模。但它的上下文长度直接到了 1M，激活参数控制在 23B，同时还做了原生多模态。

M3 走的是另一条路：把复杂任务需要的几块能力拼在一起，推理时只激活 23B。

这就是”只有 428B 参数”值得讨论的地方。428B 真不小，但它在旗舰模型对比里没有靠体量压人，仍然有资格被拿出来讨论。

三、MiniMax M3 的关键，不是大，而是长上下文效率

MiniMax M3 最值得单独讲的技术点，是 MiniMax Sparse Attention，也就是 MSA。

长上下文现在很多模型都会讲。问题是，支持 1M 上下文，不等于 1M 上下文真的好用。

你可以把很多内容塞进去，但模型要付出计算成本。你可以让模型读很长的材料，但它不一定能抓住重点。你也可以让模型执行长任务，但它可能跑到一半就忘了最初要干什么。

所以长上下文真正难的地方，其实有两个：

一个是成本能不能压下来。

另一个是任务能不能持续推进。

M3 的 MSA 主要是在解决前一个问题。

官方模型卡写到，在 1M 上下文下，M3 相比 M2：

MSA 论文页里还提到，在一个 109B 参数的原生多模态模型上，MSA 在 1M context 下把 per-token attention compute 降低 28.4 倍，并在 H800 上实现 14.2 倍 prefill 和 7.6 倍 decoding wall-clock speedup。

这些数字说明，M3 不是简单把上下文窗口拉长。它想解决的是百万级上下文怎么更便宜、更快地跑起来。

当然，话也不能说满。

快不等于准。长上下文模型最难的不是“能塞进去”，而是塞进去以后能不能找对信息、记住任务目标、不要中途跑偏。M3 在效率上给出了很强的信号，但真实任务表现还要看更多第三方评测。

四、编程能力：别急着说它第一

原文里有一些具体分数，比如 SWE-Bench Pro 59.0%、Terminal Bench 2.1 66.0%、KernelBench Hard 28.8%。

这些数字我没有在 MiniMax M3 的 Hugging Face 模型卡里核到，所以不建议写成确定事实。

模型卡能确认的是：MiniMax 官方称 M3 在 long-horizon agentic benchmarks 上达到 frontier-level performance，并且在 coding 和 cowork 方面表现突出。

这句话可以写，但要写得克制一点。

M3 的编程能力，不应该被理解成“它会不会写一个函数”。

现在真正有价值的编程模型，考验的是一整条链路：读项目、理解需求、定位问题、改代码、跑测试、看到报错、继续修，最后交付。

这类任务很吃上下文，也很吃工具调用和自我纠错能力。

所以 M3 的编程看点在于，它不是单纯的代码补全模型，而是想进入长程编程协作场景。

如果把它和 Kimi、DeepSeek、Qwen 放一起看，几家的路线大概是这样：

所以，如果问“M3 编程是不是最强”，现在还不能这么下结论。

更稳的说法是：M3 靠长上下文、多模态、稀疏注意力和 Agent 定位，去抢复杂编程任务里的持续协作能力。参数规模只是背景。

五、Agent 能力：M3 想打的是“持续干活”

Agent 能力决定了一个模型能不能真正”干活”。它考验的是模型能不能像一个初级同事一样，自己拆步骤、调用工具、跟踪上下文、遇到问题换个办法，最后交付一个结果。

在这个方向上，MiniMax M3 的卖点挺明确。

它有 1M 上下文，有 MSA 来降低长上下文成本，有原生多模态，也有 coding 和 agent 标签。这些东西放在一起，指向的就是长程任务。

但这里还是要刹一下车。

原文里说“M3 在 Claw-Eval 端到端评测中拿到最高分”，这条我没有在 MiniMax M3 模型卡里核到。Kimi K2.7 Code 模型卡里有 Kimi Claw 24/7 Bench，但那是 Kimi 自家的长程 Agentic 评测，不能直接拿来证明 M3。

M3 的 Agent 想象空间来自这些能力的叠加，某一个榜单分数说明不了全部。

它能看更长的任务历史，长上下文成本又被 MSA 往下压了一截；它还能处理图像和视频，不是只看文本；再加上 coding/cowork 的定位，它确实比普通聊天模型更接近“工作模型”。

如果说过去的大模型竞争像是在比“谁回答得更聪明”，那 M3 这个方向更像是在比“谁能把事情做下去”。

这就是它虽然只有 428B 参数，却仍然能进入国产开源旗舰讨论的原因。

六、开源协议：M3 不是最省心的那个

如果只是个人体验，协议可能不是第一优先级。

但如果公司想把模型放进产品，协议就很关键。

这一点必须讲清楚。

MiniMax M3 是开放权重，但不是“随便商用不用管”。

它的 minimax-community 许可证明确写了商业使用条件。对大公司来说，这意味着法务流程不可省。对小团队来说，门槛不算特别高，但也不是 Apache 2.0 或标准 MIT 那种简单模式。

Kimi K2.7 Code 也不能简单写成 MIT。它是 Modified MIT，模型卡和 LICENSE 都写了额外条件：如果商业产品或服务超过 1 亿月活，或月收入超过 2000 万美元，需要在用户界面显著展示 “Kimi K2.7 Code”。

所以，如果你的第一目标是商业授权最省心，Qwen 的 Apache 2.0 和 DeepSeek 的 MIT 更占优势。

如果只是技术尝试、私有化验证、研究和原型开发，M3 的协议问题没那么吓人，但 LICENSE 还是要提前读。

结尾：MiniMax M3 的惊讶点，恰恰是它没有那么大

把 MiniMax M3 放到国产开源旗舰里看，最有意思的地方不是它参数最大。

恰恰相反，它没有那么大。

DeepSeek-V4 Pro 是 1.6T，Kimi K2.7 Code 约 1T，Qwen3.5-397B-A17B 是 397B 但只激活 17B。MiniMax M3 卡在一个很微妙的位置：428B 总参数，23B 激活参数，数字不夸张，但该有的东西不少。

它有 1M 上下文，有原生多模态，有 MSA，有 coding 和 agent 定位，还有开放权重。

所以 M3 的故事不是“参数碾压”。

它更像是在回答另一个问题：

以前大家看模型，最关心它会不会聊天、会不会写代码。现在问题变了：能不能读很长的上下文、处理图像和视频、调用工具、在一个任务里持续推进，像一个初级同事一样把事情做完？

从这个角度看，MiniMax M3 的位置就清楚了。它不是参数最大的那个，但它指向了一个方向：开源模型正在从”会回答”走向”能工作”。

最后问你一个问题：

如果一个开源模型参数不是最大，但它有更长上下文、更强 Agent 能力和多模态能力，你会优先考虑它吗？

我想看看大家现在选模型，到底更看重参数规模，还是更看重真实任务能力。