Guides & Insights

MiniMax-M3.1-Flash 现已接管你的 M2.7 调用：10 月 19 日有哪些变化

作者

Gideon Frost

发布日期

Oct 19, 2026

最新模型 · 20查看全部模型 →

基准测试：Artificial Analysis · 每日更新

返回全部文章

如果你正在将 MiniMax-M2.7 于今天发送到 MiniMax M Plan 或 Token Plan 密钥，那么这个名字背后的模型已经改变。MiniMax 自己的模型停用通知将 2026 年 10 月 19 日定为日期：发往这些计划上的 MiniMax-M2.7 和 MiniMax-M2.5 的请求会在该日自动路由到 MiniMax-M3.1-Flash——代码中是同一个模型 ID，另一端却是不同的模型，其思考预算默认拉满，而且完全无法关闭思考。这个模型本身并不新：自 2026 年 9 月 27 日起，MiniMax-M3.1-Flash 就一直出现在厂商的文档中，当时我们首次确认它以 MiniMax-M3.1-Flash-Preview 这一名称出现在那里。新之处、也是今天所标注日期的内容，是这次替换——以及两个更早的模型系列会在同一时间表下被并入其中这一事实。像此次发布这类发布背后有文档记录的 AI 故障和智能体事件，都收录在 OrcaRouter AI Incident Archive 其中每条条目都带有各自的来源、严重程度、置信度等级和争议标记。

该通知实际上承诺了什么

MiniMax 在其自己的模型列表文档中公布了时间表，而且对于一次弃用而言，它具体得非同寻常。三个日期就说明了一切。

• 2026 年 10 月 19 日 — M2.5 和 M2.7 系列将停止向新用户提供。• 2026 年 10 月 19 日 — 在 M Plan 和 Token Plan 下，对 M2.5 或 M2.7 的每个请求都会自动路由到 M3.1 Flash。现有模型名称继续可用，厂商表示套餐用量额度保持不变。• 2026 年 11 月 18 日 — 两个系列均将退役。对它们的 API 请求将完全停止工作。

Screenshot of MiniMax's Model List documentation page showing the collapsed heading 'MiniMax M2.5 and M2.7 Model Retirement Notice', the Available Models table with the MiniMax-M3 row described as a frontier multimodal coding model with a 1M context window and tunable thinking depth, and a Retired Models table listing MiniMax-M2.7, MiniMax-M2.7-highspeed, MiniMax-M2.5, MiniMax-M2.5-highspeed, MiniMax-M2.1, MiniMax-M2.1-highspeed, MiniMax-M2, MiniMax-M2-her and MiniMax-Music-3.0, each marked Retired.

按量付费被单独处理：MiniMax 表示，现有的按量付费用户在停用日期之前仍可继续访问，而新用户从今天起就被切断。公司给出的建议正是你意料之中的那套——检查你的应用是否依赖这些模型，并开始规划迁移——但对于今早生产流量还指向 M2.7 的任何人来说，这已经有点晚了。

通知中最重要的词是自动。这不是那种会返回错误、迫使你修改代码的弃用。这是一种静默替换：你的请求依然成功，你的用量依然从同一额度中扣除，而生成 token 的东西已经换了。如果你记录的是请求的模型，而不是响应的模型，那么你的监控就会显示一项运行着你并未选择的模型的健康服务。

响应内部会发生三处变化

供应商的 API 参考文档在同一页面上记录了这两个模型，因此很容易精确说明二者之间的差异。MiniMax-M3.1-Flash 是一款前沿的多模态编码模型，具有 1,000,000 token 的上下文窗口和可调节的思考深度；MiniMax-M2.7 是一款旧版的文本与工具模型，具有 204,800 token 的窗口。

• 上下文 — 在 MiniMax-M3.1-Flash 上为 1,000,000 个 token，而在 MiniMax-M2.7 上为 204,800 个，约增长五倍。• 输入 — MiniMax-M3.1-Flash 支持文本、图像和视频，而 M2.x 系列仅支持文本和工具调用；厂商的旧版说明明确指出其不接受图像或视频输入。• 思考 — 在 MiniMax-M3.1-Flash 上始终开启且无法禁用；发送 thinking: {"type": "disabled"} 会返回 HTTP 400，错误码为 2013。• 思考深度 — effort 接受 low、medium、high、xhigh 和 max，省略时默认为 max。M2.7 没有等效控制。• 推理输出 — 返回于 reasoning_content，在 OpenAI 兼容协议中；在 Anthropic 兼容协议中则位于 thinking 块中。reasoning_split: false 不被接受，因此思考内容无法作为 content 中的 <think> 标签推回。• 输出上限 — 在 MiniMax-M3.1-Flash 上，推荐生成 131,072 个 token，硬性上限为 524,288 个；而 M2.7 的总上下文为 204,800 个。• 准入层级 — service_tier: "priority"（提速 1.5 倍的快速准入层级）在 MiniMax-M3.1-Flash 上不受支持。依赖优先准入的工作负载将失去该能力。• 采样 — top_p 在 MiniMax-M3.1-Flash 上默认为 0.95，而 M2.x 模型上为 0.9。

其中两项只是表面性的。思考默认值则不是。为 M2.7 构建的工作负载从来不必考虑推理强度，因为没有什么可设置的。同样的工作负载未经改动，现在每个请求都以最大强度运行——而 MiniMax 会将思考令牌计入生成长度限制，这就是为什么供应商自己的文档警告说，过小的 max_tokens会导致 max_tokens 停止原因，且完全没有文本输出。

A generated two-column scoreboard titled 'MiniMax-M2.7 vs MiniMax-M3.1-Flash — the scoreboard'. MiniMax-M2.7 lists 204,800-token context, text and tools, thinking off allowed, no thinking-depth control, open weights since April 2026, and $0.30 / $1.20 pricing; MiniMax-M3.1-Flash lists 1,000,000-token context, text, image and video, thinking off returning an HTTP 400 error, thinking depth low to max defaulting to max, no published open weights, and price not published. The footer reads 'Vendor documentation figures; MiniMax-M3.1-Flash has no independent benchmarks. Routing date 19 Oct 2026.'

默认情况下使用的是昂贵的那个设置。

陷阱可以用一句话概括：迁移通知说你的用量额度保持不变，这没错，但每次请求所消耗的 token 数并非如此。

MiniMax 的 M Plan 常见问题解答明确指出，消耗取决于思考深度，而且 M3.1 Flash 的思考深度越高，生成的思考内容越多，消耗也越多。在effort默认为max的情况下，一个迁移后的 M2.7 工作负载现在正以该模型提供的费用最高的设置运行，却无人选择这一设置。

一个粗略的示例，使用整数，并明确标明这是算术推演而非实际测量：假设每天 40,000 次请求、6,000 token 的提示词，以及 3,000 个思考 token 处于 max 档，而约为 600 个处于 low 档。这相当于每天多出 9,600 万个思考 token，每月约 29 亿个。按 MiniMax-M3 公布的每百万 token 1.20 美元的输出费率计算——这是现有最接近的已公布费率，因为 MiniMax 未公布 M3.1 Flash 的按 token 费率——这一差额每月略高于 3,400 美元。只要改变其中两个假设，这个数字就会大幅变动；关键在于，正负号不会变。

修复方法只需改一个字段，而且因协议而异：output_config.effort用于兼容 Anthropic 的端点，reasoning_effort用于兼容 OpenAI 的端点，reasoning.effort用于 Responses 端点。MiniMax 自家的编码工具指南推荐的正是这一点——对简单任务降低 effort，而不是试图禁用思考，因为禁用思考并不是可选项。

在你进行任何调优之前，有一个二阶效应值得检查。如果你的客户端发送的 max_tokens 是按 M2.7 回答所需大小设置的，那么一个采用最大努力的模型可能会把全部预算花在推理上，并返回一条空消息。MiniMax 的 Anthropic 兼容参考文档要求你将 output_config.effort设为max，并且要显式设置；同一页面的参数表警告说，思考 token 会计入 max_tokens。这两句话相隔几行，而正是这种组合会让你得到一个内容为空的 200 响应。

目前仍然没有按 token 计价的价格

这部分让迁移难以核算成本，而不是难以编写代码。MiniMax 的按需付费价格表只列出了一个语言模型：MiniMax-M3，对于最多 512,000 个输入 token 的提示，每百万输入 token 收费 0.30 美元，每百万输出 token 收费 1.20 美元；超过该上限后翻倍至 0.60 美元和 2.40 美元，并且划掉的标价已永久应用 50% 折扣。提示缓存读取分别为每百万 0.06 美元和 0.12 美元。MiniMax-M3.1-Flash 根本没有出现在该表中。

已公布的是订阅定价。M Plan 的 Go 套餐为每月 22 美元，Explore 为每月 55 美元，Build 为每月 132 美元；这三个套餐都包含 M3.1 Flash Preview 文本模型，其中 Explore 的使用额度是 Go 的三倍，Build 则是七倍半。Token Plan 仍面向现有订阅者提供，但不再向新订阅者出售；厂商的升级说明称，无论哪种情况，各套餐都保持当前价格和文本限制不变。

所以，对于“M3.1 Flash 每 token 成本是多少”这个问题，诚实的答案是：MiniMax 之外的人目前还无法告诉你，因为这个数字并没有写在页面上。如果你这周就需要一个每 token 的数字来构建商业论证，唯一站得住脚的方法就是实测：在每个 effort 级别运行固定的评估集，记录用量（来自响应），然后按你的套餐所隐含的费率进行换算。一个只发布模型卡却不发布费率卡的供应商，是在告诉你：它想谈的是订阅，而不是按量计费。

你实际发送的是哪个模型 ID？

MiniMax 的文档自相矛盾，而且偏偏在最糟糕的时刻造成麻烦。API 参考文档、模型调用指南和模型列表都将该模型称为 MiniMax-M3.1-Flash。M Plan 页面、Claude Code 设置指南和 Codex 设置指南则都称其为 MiniMax-M3.1-Flash-Preview，其中还包括一份 Claude Code 配置，将四个独立的环境变量全部设为 MiniMax-M3.1-Flash-Preview[1m]。

两种命名都没有被标注为已弃用，文档中也没有任何页面宣布正式可用日期或更名。这一点值得明确说明，而不是靠猜测：截至今天，供应商仍在使用这两个字符串，而我们无法从公开文档中确认按量付费密钥会接受哪一个。唯一能得出定论的测试大约只需十秒钟，而且不产生任何费用：

curl https://api.minimax.io/v1/models -H "Authorization: Bearer $YOUR_KEY"

读取返回的 ID，并原样使用其中任意一个。如果你要将该模型接入 Claude Code、Cursor、Codex 或 OpenCode，厂商指南要求使用 -Preview 形式，并且 Claude Code 指南还指出，当配置正确时，该工具应报告 MiniMax-M3.1-Flash-Preview 为当前活动模型。

如果你自行托管，这些都不会波及到你。

MiniMax-M2.7 是一个开放权重模型。它的检查点自 2026 年 4 月起就一直在 MiniMaxAI 组织下的 Hugging Face 上，而停用 API 端点的通知不会影响在你自己的硬件上运行的副本。M2.5 也是如此。如果你的 M2.7 流量由你自己的集群或私有部署提供服务，那么今天的路由变更就是别人的问题。

MiniMax-M3.1-Flash 并不在那个位置上。MiniMaxAI 组织最近的两个公开仓库是创建于 2026 年 8 月 7 日的 MiniMax-Music3，以及创建于 2026 年 7 月 28 日的 MiniMax-H3；而在 Hugging Face 上搜索 M3.1 则没有任何结果。对于你目前正被路由到的这个模型，既没有检查点，也没有许可证文件，更没有可自托管的退路。如果你选择 M2.7 的原因是开放权重，那么这次迁移在自主性上确实是降级，即使在能力上是升级。

迁移清单，按重要程度排序

• 今天 — 确认你使用的是订阅密钥还是按量付费密钥。自动路由适用于 M Plan 和 Token Plan；按量付费会继续为现有用户提供 M2.5 和 M2.7，直至 11 月 18 日。 • 今天 — 记录 API 返回的模型 ID，而不只是你发送的模型 ID，这样静默替换就会在你的数据中显现出来。 • 本周 — 在每次调用时显式设置 effort。应按任务类别选择级别，而不是继承 max。 • 本周 — 在提高 effort 之前，先调高 max_tokens 或 max_completion_tokens，并检查是否出现以 max_tokens 为停止原因的空补全。 • 11 月 18 日之前 — 如果你仍然需要 M2.7 的行为，请将其移植到自托管检查点，或接受新模型的行为。该日期之后，端点将不复存在。 • 11 月 18 日之前 — 重新测试任何使用过 service_tier: "priority" 的内容。它在 M3.1 Flash 上不可用，因此即使模型未变，延迟特征也会改变。

路由层在哪里物有所值

本周的教训不在于 MiniMax 发布了更好的模型，而在于：你代码中的模型 ID 是供应商可以改写的一项承诺，而这种改写不会在你的部署历史中附带任何变更日志条目。

正因如此，才应该把模型选择放在路由器之后统一处理，而不是在十二个服务里硬编码厂商字符串。在 OrcaRouter 上，MiniMax-M3 以及 M2.5 和 M2.7 端点与 200 多个其他模型一起，全部通过同一个密钥调用，加价 0%——直接按供应商标价原样透传，因此 MiniMax-M3 的定价与厂商收费完全一致，仍是每百万 token 0.30 美元和 1.20 美元；也正因如此，厂商调价当天就会生效，而不必等到下一个计费周期。

有两件事在这里确实很有用。首先，路由 DSL 允许你为某一类任务固定指定一个模型，并在第一个不可用时切换到第二个，这样对尚未验证的模型所做的评估会与现有模型并行运行，而不是取代它。其次，跨提供商的自动故障转移意味着上游出状况的半天只会导致路由降级，而不是服务中断。

Screenshot of the OrcaRouter model page for MiniMax M3 showing the model path minimax/minimax-m3, 512K maximum output, text, image and video input, vision, tools, JSON and reasoning output badges, the Minimax vendor attribution, a model description and a code-sample panel.

需要说明的是：截至今天，MiniMax-M3.1-Flash 并不在我们的目录中。我们提供的是按 token 计费的 MiniMax 系列，包括 M3、M2.7、M2.5 和 H3。因此，如果你想把你刚迁移到的模型与刚迁离的模型作比较，原模型那边只需一个 key 就能访问。新模型本身则需要通过 MiniMax 自己的套餐来使用。

什么会改变这个读数

三份公开材料会把这件事从一则迁移故事变成一则发布故事，而它们目前都还不存在。为 MiniMax-M3.1-Flash 提供按 token 计价的价格，才能让任何人真正核算切换成本。在 Hugging Face 上提供一个 checkpoint，将恢复 M2.7 用户正在失去的自托管选项。在 Artificial Analysis 上收录该模型，将赋予它首个独立智能评分——MiniMax-M3 在该指数上为 29.2，而 MiniMax 自己的文档声称 M3.1 Flash 在 SWE、BrowseComp 和 xBench 上取得了最先进的结果，却没有随这些声明公布哪怕一个数字。

在那之前，就把它当作它本来的样子来对待：可调用、有文档、未经基准测试、也没有按 token 定价，如今还在接收那些并非冲着它名字而来的流量。能从中全身而退的团队，是那些在第一天就注意到自己的模型 ID 已经变成了一个别名的人。