minimax m3 开源了吗

团队要选模型时最怕两件事：以为它开源，结果只能调 API；或者以为能随便商用，翻完许可条款才发现有坑。这篇不讲结论，只给一套可复用的核实顺序——先确认权重有没有公开放出，再确认许可属于哪一类，最后对照自己的用法（自建、微调、转售、进产品）逐条比对。看完你能自己判断「到底算不算开源」，也能把结论落到选型文档里。

团队选模型的时候最怕两件事：以为某个模型是开源的，结果发现只能调 API；或者以为权重能随便商用，翻完许可条款才发现有一堆附加条件。这两件事的共同点是——听传言拍板，最后返工。这篇不讲结论，只给一套可以反复用的核实顺序。

思路很简单：先确认权重有没有公开放出，再确认许可属于哪一类，最后对照自己团队的用法逐条比对。看完你能自己判断「到底算不算开源」，也能把结论落到选型文档里，下次有人再问，直接翻记录就行。

为什么这个问题没有一句话答案

「开源」这个词在模型圈至少有两层含义：一是权重文件能不能下载，二是许可允许你拿它做什么。很多团队只看到第一层就下结论，结果在第二层上翻车。更麻烦的是，放权重的方式本身也分好几种，可用度差别很大。

还要注意一点：版本和快照会变。今天能下的权重，不代表下个月还是同样的条款。所以别背结论，背核实路径——路径不会过期，结论会。

四步核实清单：从「有没有」到「能不能」

1. 查官方去厂商官网和官方文档找模型页，看有没有明确的下载入口或权重仓库地址。只有 API 文档、没有权重链接，先按闭源对待，别急着写进选型结论。
2. 查模型库到 /models 搜相关条目，看标注的开放方式是权重开放、仅 API 还是仅研究用途。模型库的字段通常比新闻稿可靠，因为它要长期维护。
3. 查许可原文找到条款文件后只盯四件事：商用是否允许、是否要署名、再分发和托管给第三方是否允许、有没有日活或营收门槛类的附加条件。
4. 内测验证真能下到权重，就拉一个最小实例跑通推理，确认权重完整、能正常加载。许可能用但权重跑不起来，等于没用。

顺序别乱：先确认存在，再确认权限，最后确认可用。三步缺一步，都别写进选型结论。踩过坑的团队多半是跳过了第一步，直接拿新闻标题当依据。

许可条款逐项对照：你的用法踩哪条

光知道「有许可」不够，关键是你打算怎么用。下面这张表把常见用法和要盯的条款对上，团队可以逐行打勾。

• 自建内网：很多条款对内部使用宽松，对外提供服务要单独授权，别两头混着算
• 微调蒸馏：团队内部用和对外发版是两笔账，允许你用不等于允许你发
• 嵌入产品：出现用户数或营收门槛时，让法务拍板而不是工程同学拍板
• 改名发布：几乎都会要求保留署名，改个名当自研发布风险最大
• 遇到模糊表述：按最保守的理解执行，并把疑问写成书面问题留痕

把结论写进选型文档，别只留在聊天记录里

很多团队的核实结论只活在群聊里，换了个人接手就得重来一遍。正确的做法是把结论写进选型文档，并且带上三样东西：核实时间、核实的页面位置、以及你读到的条款版本或快照标识。下次有人问，直接指过去。

还要写明适用边界：我们团队属于哪种用法、对应条款里的哪一条、谁负责复核。没有边界的结论等于没结论。另外准备一条退路，如果许可后续收紧，你切到哪个替代方案、迁移代价多大，可以先参照 /models/deploy 把显存与并发底线算出来。

什么时候可以停止纠结这个问题

核实是有成本的，不是所有团队都值得一直追。三种情况可以停下来：调用量小且全部走官方 API；团队已有通用许可判断流程，把它当一个待填条目；以及短周期试跑、不对外发布的场景。

真正需要反复确认的是三类：长期自建、微调后对外发布、把模型嵌进商业产品。这三类才值得投入核实成本，其他场景按流程走一遍就行，别为单个模型重开一轮讨论。