MiniMax M3.1：泄露的预览文件说了什么——以及无人证实的内容

Hugging Face 上有一个名为 MiniMax-M3.1-preview-private 的 250 GB 检查点，除了少数几家推理合作伙伴之外，任何人都无法打开。还有一份日期为 9 月 22 日的文档，读起来完全像是该厂商的架构说明，它流传于一个公开的合作伙伴工程仓库中，而不是出现在厂商自己的网站上。而在 9 月 26 日，一位被广泛关注的模型观察者发帖称，MiniMax M3.1 是“下周即将推出的下一款模型”，并且他们已经在测试其预览版。把这三件事放在一起，你就得到了 MiniMax M3.1 的全部公开记录——一款其名称、架构变动、权重数量和发布周都已在外流传的模型，而厂商对其中任何一项都未在公开场合透露过只言片语。它所承接的前代模型 MiniMax M3 则是另一回事：那款已经发布了，而正是它让人们如此关注这一款。

一个未发布模型从外部看就是这样，而精确说明证据的形态是值得的，因为这三条线索的强度并不相同。检查点的存在得到了印证：多条独立线索都指向同一个私有仓库名称和同一个文件数量。架构文档则没有以那种方式得到印证——它是第三方的转录，可能真实，可能过时，也可能部分系编造。“未来一周”的说法是某个人的预期，而不是一份时间表。本文中的所有内容都按其实际具备的强度加以标注，这里没有任何内容应被解读为发布公告。

让 MiniMax M3.1 尚未问世就值得写一篇文章的，是它的前代。按多数评价，MiniMax M3 是 MiniMax 迄今发布过的最强开放权重模型——一个 100 万 token、文本-图像-视频模型，在 Artificial Analysis Intelligence Index 上达到 29.2，并且仍是少数能够真正维持长上下文连贯性的开放模型之一。如果 M3.1 在九月最后一周落地，对开发者而言真正重要的数字不是这则泄密的可信度，而是各层中发生了什么变化，以及提供服务需要多少成本——而在这两点上，泄露的文件都异常具体。

哪些是已确认的，哪些只是流传中的

诚实的拆分，截至2026年9月27日：

• 已确认：MiniMax M3.1 不存在公开版本。Hugging Face 上的 MiniMaxAI 组织对 MiniMaxAI/MiniMax-M3.1、MiniMaxAI/MiniMax-M3.1-preview 以及 MiniMaxAI/MiniMax-M3.1-preview-private 一视同仁地返回 401——也就是该平台表示“未找到或对你不可见”的响应。其最新的公开上传仍为 MiniMax-Music3（2026 年 8 月 7 日）和 MiniMax-H3（2026 年 7 月 28 日）。

• 已确认：MiniMax M3.1 在我们能核查的任何地方都无法路由。它不在 OrcaRouter 的模型目录中，也不在我们监控的公开列表里；目前你真正可以调用的 MiniMax 模型是 MiniMax M3，位于 minimax/minimax-m3。

• 已确认：MiniMax 没有发布任何内容。没有模型卡，没有博客文章，没有定价页面，没有权重，没有 API 模型 ID。没有任何关于发布的媒体报道，因为根本没有发布。

• {{1}}正在流传{{/1}}：{{2}}该架构文档{{/2}}。它被逐字收录在一个公开代码仓库中——{{3}}longsco/innoferra-eval{{/3}}，一个面向托管模型端点的合作伙伴接入套件，创建于{{4}}2026年9月23日{{/4}}——文件名为 {{5}}PREVIEW-20260922.md{{/5}}，其文件头将其描述为一份{{6}}于9月25日分享的供应商文档{{/6}}，并附有一条说明：“{{7}}模型名称、供应商发布日期和公开发布时间仍以实际发布为准。{{/7}}”这是该文档自身的保留说明，不是我们的，而且这一保留是恰当的：第三方持有的供应商备忘副本并不等同于{{8}}MiniMax{{/8}}的声明。

• 流传中：那个 250 GB 检查点及其第二次发布。该仓库的入门规范记录了一个位于 MiniMaxAI/MiniMax-M3.1-preview-private 的私有多模态检查点——62 个文件、48 个 safetensors 文件、约 250 GB，架构字符串为 MiniMaxM3SparseForConditionalGeneration——随后是更大的第二次发布 MiniMax-M3.1-preview2-dspark-private，共 101 个文件、约 236 GB，其中新增了一个 2.3 GB 的 fp8 推测性草稿。两者都是私有的。我们无法打开其中任何一个，你也不能。

• 流传中的：时间线。9月26日的帖子是唯一有人公开给出的时间点，而“下周”只是一种预期。请把9月28日那一周视为值得关注的窗口，而不是一个确定日期。

承载工程细节的那一份文档

关于 MiniMax M3.1 设计的全部具体已知信息，都可以追溯到那一个 Markdown 文件，外加同一仓库中的两个配套文件：一份说明该检查点应如何提供服务的 SGLang 演示文档，以及一份合作伙伴端点应当满足的 spec.yaml。把整个仓库通读下来，它看起来就像一家推理服务提供商在做推理服务提供商该做的事——从 MiniMax 那里收到一个早期版本，记录下变更内容，并为其构建一套验证套件。这个仓库不是新闻资料包，也不是为了说服任何人而写的。

这算是它的一个优点，同时也是其所证明之事的极限。其中没有任何内容由 MiniMax 签署。这三份文档彼此吻合的方式，正是真实文档彼此吻合的方式——相同的量化常数、相同的环境变量名、相同的启动标志——而它们彼此不一致的方式，也正是真实发布彼此不一致的方式：9月22日的预览版称，新的推测解码方法没有置信度头，而第二次检查点发布则附带了一份将 enable_confidence_head 设为 true 的草稿配置。一份伪造品通常不会包含一条纠正轨迹。但“异常连贯”并不等于“已确认”，而读者的失败模式，就是把下面的常数当作 MiniMax 公开的设计来吸收，而它们至多只是被他人解读出的 MiniMax 私有设计。

根据那份文件，五项工程变更

以下是文档所描述的 MiniMax M3 与 MiniMax M3.1 之间的差异。每一行均源自厂商，且未经审计——没有任何独立第三方对 MiniMax M3.1 任何形式的输出进行过实测。

• 注意力覆盖范围。前三层中的全注意力被替换为稀疏注意力，因此所有层都是稀疏的。在 MiniMax M3 上，前三层曾是稀疏堆叠的全注意力锚点。

注意力精度——"Q8KV4"。查询（包括索引器的查询）从投影中以 BF16 输出，并被转换为 FP8 E4M3。键和值——同样包括索引器的——被量化为 E2M1、四位、以 16 个为一组，并使用每块 E4M3 缩放，缩放值为 amax/6，钳制到 [1/512, 448]。文档强调，阶梯采用就近取偶舍入且阈值不对称，外部张量缩放恰好为 1，并且零幅值必须编码为正零。M3 使用了同一系列的八位 KV 路径，因此这再次将 KV 字节数减半。

• 专家精度。MoE 路由专家从 MXFP8 转为 W4A4 NVFP4，而共享专家被有意排除在外。两个专家投影采用不同的激活方案：FC1 使用动态的逐行缩放，即 2688 除以该行的绝对最大值，行缩放应用在 GEMM 之后、激活函数之前；FC2 使用固定的外层缩放 16。合作伙伴 README 中明确写出的实际后果很直白：“如果提供商在没有这些设置的情况下，用通用 NVFP4 路径运行检查点，就会静默地产生不同的数值结果。”

• 投机解码。EAGLE 风格的多 token 预测头已被移除，取而代之的是 MiniMax 称为 DSpark 的方法——一个普通的马尔可夫头，并且在 9 月 22 日的文档中，没有置信度头。这是对已服务端点体验影响最大的变更，因为它是设计中唯一的每流速度杠杆。MiniMax 随检查点一同发布的演示引擎不包含 DSpark，而提供商测量了这一差距：在相同的 80,000 token 帧且无投机的情况下，并发为 1 时每流吞吐量为每秒 63.9 token，到并发 4 时降至 60 以下，因此文档自身的结论是，没有 DSpark，该技术栈无法在负载下保持其延迟目标。

• 新增了一个请求字段。MiniMax M3.1 增加了顶层 reasoning_effort 字段，可取值为 max、xhigh、high、medium 或 low，由聊天模板作为 effort 标签注入系统提示词。M3 此前只有一个 thinking 开关，取值为 adaptive 和 disabled。文档特别而古怪地指出，该字段不带任何校验，也没有必需的默认值——服务商将此解读为可以接受或拒绝未列出的取值，这也意味着两个合规的 endpoint 对同一请求可能表现出不同的行为。

检查点中有两个细节值得单独指出，因为它们是那种发布公告会省略的东西。首先，该检查点同时附带了图像预处理器配置和视频预处理器配置——MiniMax M3.1 从构造上就是多模态模型，而不是后来才加上视觉能力的文本模型，并且提供商自身的指导意见是不要在新栈上拒绝图像输入。其次，第二次检查点发布完全移除了 MTP 和 NEXTN 键，也没有添加任何替代它们的内容，这就是为什么 DSpark 草稿必须作为单独的 2.3 GB 产物出现。主权重中没有可启用的草稿头。

为什么没有 M3.1 的基准测试数据，以及这为何并非疏漏

每一篇爆料文章最终都会写到那一步：要么编造一张基准测试表，要么承认自己根本没有。MiniMax M3.1 就没有。合作方规格说明明确指出了这一点，就在一个纯粹为了防止有人犯这个错误而存在的字段里：

• “尚未发布 3.1 基线；不要复用 M3 的数值作为验收门槛。”

那条指令是整个语料库中最有用的一句话，因为这篇文章的偷懒版本会把 MiniMax M3 的 Artificial Analysis 分数写在 MiniMax M3.1 的标题下。它不该这么做。同一个仓库针对 MiniMax 自己的 M3.1 端点运行 AIME-25 和 GPQA-Diamond 探测，并将它们记录为队友与厂商之间的对比，且分数尚未确定：在 GPQA-Diamond 上，团队运行结果为 0.904，厂商的为 0.813；在 600 题的 MMLU-Pro 子集上，则为 0.898 对 0.821。这些是同一次评估的两次运行结果不一致，而不是模型结果，而且它们被标记为预览，并计入了重复次数。今天任何引用单个 MiniMax M3.1 基准数字的人，引用的都是尚不存在的东西。

MiniMax M3 是什么，以便确定续作的规模

MiniMax M3 于 2026 年 5 月底发布，并于 6 月 2 日上线 Hugging Face——总计 4280 亿参数，其中 230 亿为活跃参数，60 层，128 个路由专家并采用 top-4 路由，4 个 KV 头对 64 个注意力头，上下文窗口为 1,048,576 个 token，最大输出为 512,000。在独立评测方面，Artificial Analysis 在 Intelligence Index 上给它打出 29.2 分，在 145 个抽样模型中位列第 60，编码指数为 58.6，而在我们自己的路由遥测中，首个 token 的 p50 为 3,348 毫秒。MiniMax 自己为其公布的核心数字是 BrowseComp 上的 83.5，这是厂商数据，且因此未经审计。

在泄露周期里，定价是最经得起时间考验的部分。MiniMax M3 的输入价格为每百万 token 0.30 美元，输出价格为每百万 token 1.20 美元，缓存读取为 0.06 美元——而且它已在 OrcaRouter 上线，模型为 minimax/minimax-m3，按供应商标价、0% 加价，因此如果 MiniMax 对 M3.1 采用同样的定价方式，新费率会在其问世当天就在我们这边生效，而不是晚一个计费周期。

重述这一切的重点并非怀旧。而在于，本周任何人刷新 Hugging Face 组织页面的全部原因，就是 MiniMax M3 已经足够出色，以至于其继任者成了一个生产问题，而不是一场看热闹——并且，一个拥有 4280 亿参数、100 万上下文、定价为 $0.30/$1.20 的模型，树立了 M3.1 必须跨越的性价比门槛，而不只是能力门槛。

匿名上市这一角度，以及为什么它可能已经得到了解答

九月早些时候的一条线索值得在此收尾。一个匿名隐身条目出现在第三方编程平台上，具有 1,000,000 token 上下文、$0 定价和强制推理等级，我们以 Space Bunny Alpha 之名进行了报道，并指出这类匿名条目的基准概率：它们最终都会被某家厂商认领——Pony Alpha 成了 Zhipu 的模型，Hunter Alpha 成了 Xiaomi 的，Ox Alpha 成了 MiniMax 以另一个名称发布的版本。该条目中的分词器与异常指纹指向一个 MiniMax 预览检查点。如果 MiniMax M3.1 本周真的到来，最可能的解读是：那个匿名条目就是它的实地测试，而谜团将通过官方公告、而非进一步取证工作来解开。那是推断，不是证据，也是本文中的最后一个推断。

本周值得关注的事项及行动指南

能把它从一次泄露变成一次正式发布的信号是具体且可核查的，而且并非大多数评论所追踪的那些。MiniMaxAI 组织下带有模型卡片的公开 Hugging Face 仓库——而非私有仓库——是最强的单一指标；该组织的上传历史是公开的，能把每一次发布精确到日。第二个是 MiniMax 的模型页面或 API 模型 ID。公布的价格是第三个，也是与预算息息相关的那一个。第四个是 Artificial Analysis 上发布日期晚于模型发布的基准测试表，也是唯一独立的一项。

在那之前，对任何正在构建的人来说，实际处境与任何其他发布前的周次并无不同：你今天能路由到的模型是 MiniMax M3，一个 API 密钥就能连同它一起访问 200 多个其他模型，自动故障转移意味着某个端点抖动不会变成你的故障，而通过路由 DSL 固定的路由或混合路由，或者让一组模型通过模型融合共同作答，正是为尚未投入生产的模型降低风险的方式。如果 M3.1 到来，那只是换一个模型 ID，而不是一次迁移——这正是不要针对一份泄露信息构建定制集成的全部理由。

这篇文章不会做的一件事，就是假装知道那是在什么时候。检查点是真实存在的，文件是具体的，而最近一次的公开说法，是某个人说了句“下周”。这三者之中，只有前两者是你可以自行核实的。