428B参数开源、速度直接翻倍：MiniMax M3这次不只是堆参数

MiniMax M3 开源：原生多模态旗舰模型亮相

  6 月 16 日，稀宇科技 MiniMax 宣布其原生多模态旗舰模型 MiniMax M3 正式开源。

  从参数规模看，MiniMax M3 拥有约 428B 总参数，单次推理激活约 23B 参数。

  它不是简单堆参数的密集模型，而是采用 MoE 架构，让模型在保持大容量的同时，尽量控制实际推理成本。

  更关键的是，M3 从训练初期就进行多模态混合训练，能够处理文本、图像、视频等输入，而不是在纯文本模型基础上后接一个视觉模块。

这意味着，它的多模态能力不是"外挂式补丁"，而是从底层训练阶段就被纳入统一语义空间。这也是 MiniMax M3 最值得关注的地方。

  过去很多多模态模型看起来能识图、能看视频，但在复杂任务里很容易出现割裂：图片理解是一套逻辑，文本推理是另一套逻辑，代码生成又是第三套逻辑。M3 想解决的问题，是让模型在长上下文、多模态信息和复杂任务执行之间形成更统一的能力。

  比如开发者给它一篇论文、相关代码、实验日志和图表，它不只是总结内容，而是有机会把这些材料同时放进上下文里，进行理解、复现、调试和迭代。

  这类场景过去对模型的上下文长度、代码能力和多模态理解要求都非常高，任何一环短板都会让任务中断。

引入稀疏注意力机制应对长上下文挑战

  为了解决长上下文带来的计算成本，MiniMax M3 引入了 MiniMax Sparse Attention，也就是 MSA 稀疏注意力机制。

  传统全注意力机制在上下文变长时，计算量会快速膨胀。

  上下文从几万 token 拉到几十万、上百万 token 后，成本和延迟都会成为实际部署中的大问题。MSA 的思路，是让模型在处理长上下文时，不再对所有历史信息进行同等计算，而是通过块级筛选，优先关注真正相关的内容，从而降低无效计算。

换成更直白的话说：不是把整本书每一页都重新读一遍，而是先判断哪些章节最相关，再集中处理这些部分。

代码与 Agent 能力显著提升

  MiniMax 官方披露，M3 在代码和 Agent 能力上相比上一代有明显提升，在 SWE-Bench Pro、Terminal-Bench、KernelBench、MCP Atlas 等评测中表现突出。

  更值得注意的是，MiniMax 没有只强调单轮代码生成，而是提到通过模拟真实开发者协作过程，训练模型在多轮需求变更、反馈修正、任务切换和复杂项目迭代中工作。

速度优化：从“能演示”走向“能使用”

  M3 的另一个变化，是速度。

  M3 发布早期由于访问量快速增长，体验上出现过延迟问题。

  官方已经将模型输出速度从最初的 30 TPS 优化到 80 TPS，后续还会继续提速。

  对于普通用户来说，TPS 只是一个技术指标；但对开发者和企业来说，它决定了模型能不能进入实际生产环境。

  一个模型即使能力很强，如果响应太慢，也很难承载高频调用。

  尤其是代码助手、智能客服、文档分析、企业知识库、办公 Agent 这些场景，用户对等待时间非常敏感。速度提升不是锦上添花，而是模型从"能演示"走向"能使用"的关键门槛。

开源背后的现实考量

  当然，MiniMax M3 的开源也不能只看热闹。

  首先，428B 级别模型并不意味着普通电脑可以轻松跑起来。

  即便它是 MoE 架构，实际部署仍然需要较高的算力、显存和推理框架支持。

  对个人开发者来说，更现实的路径可能是通过 API、云服务、量化版本或第三方推理平台使用，而不是直接在消费级设备上完整部署。

  其次，"开源"在大模型领域需要看清楚具体含义。很多模型更准确地说是"开放权重"，是否允许商用、是否允许二次分发、是否有使用限制，都要以官方许可证为准。

  对企业开发者来说，模型能力只是第一步，合规和成本同样重要。