MiniMax M3.1 Flash实测：推理强度如何决定修Bug成本

结果先行： MiniMax M3.1 Flash 现已在 AIHubMix 上以 minimax-m3.1-flash 的模型 ID 按 token 计费开放调用，输入 $0.165 / 输出 $0.66 每百万 token。在一个包含两个 bug 的 Python 函数修复任务上，它在两种推理强度设置下均通过了全部 215 个隐藏测试。默认强度下平均每次修复消耗 6,673 个输出 token、耗时 56 秒；切换到 reasoning_effort="low" 后降至 889 个 token、9.5 秒。成本从每次 $0.0045 降到 $0.0006。

如果你正从 M2.7 迁移，或是在 M3 与 Flash 之间做选型，每 token 单价只是故事的一半。另一半由推理强度设置决定。

从匿名模型到正式发布

M3.1 Flash 最初以匿名形式出现。9 月 23 日，它以 Space Bunny Alpha 的名字登陆 OpenRouter 和 OpenCode，免费、100 万上下文、多模态、思考常开。据 CellCog 的时间线记录，它登顶 OpenRouter 日榜，压过 DeepSeek^广告 V4.1 Flash，并连续五天成为 OpenCode 使用量最高的模型。社区在 MiniMax 官方表态之前就通过 tokenizer 把它匹配到了 MiniMax 身上——X 用户 cheaty 的对比发现其文本 tokenizer “与 MiniMax M3 完全一致”，其他测试者也用 36/36 和 50/50 的探针字符串交叉验证了这一结论。

正式时间线如下：

日期	事件
9 月 23 日	Space Bunny Alpha 上线 OpenRouter 与 OpenCode
9 月 27 日	MiniMax 命名为 M3.1-Flash-Preview，成为 MiniMax Code 默认模型
9 月 30 日	Token Plan广告 改为 M Plan，纳入 M3.1 Flash
10 月 19 日	M2.5/M2.7 对新用户关闭，套餐请求路由至 M3.1 Flash
10 月 19 日	minimax-m3.1-flash 在 AIHubMix 上线，按 token 付费

MiniMax 的模型列表现已去掉 “Preview” 标签，正式名称 MiniMax-M3.1-Flash，定位为“具备 100 万上下文窗口和可调思考深度的前沿多模态编程模型”。AIHubMix 的每次响应都会报告这个上游名称。

tokenizer 指纹识别是一种在不依赖官方声明的情况下判断模型身份的技术手段。由于不同模型在训练时使用的分词器（tokenizer）在词表规模、子词切分规则和特殊 token 编号上存在差异，给定同一段文本，不同 tokenizer 会产生不同的 token 数量和 ID 序列。研究人员将探针字符串（如特定长度的单词、标点组合）输入匿名模型，统计其 token 数或比对返回的 token ID，与已知模型的 tokenizer 特征进行匹配，即可高置信度地推断匿名模型的身份。cheaty 的观察——Space Bunny Alpha 的文本 tokenizer 与 MiniMax M3 完全一致——正是基于这一原理，其他测试者用 36/36 和 50/50 的探针字符串交叉验证，进一步排除了巧合。

与 M2.7 的规格差异

项目	MiniMax M2.7	MiniMax M3.1 Flash
上下文窗口	204,800	1,000,000
max_tokens（推荐/最大）	65,536 / 204,800	131,072 / 524,288
输入类型	文本	文本、图像、视频
思考模式	常开，无级别	常开，五档
默认思考深度	—	max
显式 cache_control	支持，写入计费	不支持
默认 top_p	0.9	0.95
状态	2026 年 11 月 18 日退役	当前主力

保持不变的部分：两者每次请求都会思考，都支持 MiniMax 的 Anthropic 兼容和 OpenAI 兼容 API，也都只接受 tool_choice: auto。

新增的关键旋钮是推理强度。MiniMax 的文本生成指南列出 low、medium、high、xhigh 和 max 五档，字段缺省时使用 max。M2.7 的代码不会发送这个字段，所以模型切换后，每个请求都会以 max 强度运行——这是迁移中最容易被忽视的成本陷阱。

reasoning_effort 是 OpenAI 兼容 API 中用于控制模型思考深度（思维链长度）的字段，通常接受 low、medium、high 等枚举值，部分厂商会扩展更多档位。它不改变模型权重，而是通过系统提示或解码策略，引导模型在生成最终答案前投入多少内部推理 token。对按输出 token 计费的模型而言，该字段直接决定成本：档位越高，模型生成的隐藏思考 token 越多，账单和延迟也随之上升。M3.1 Flash 将该字段扩展为五档并默认取 max，意味着不显式传参的请求会以最深思考运行，这是迁移代码中容易被忽视的成本放大器。

价格对比：Flash 便宜在哪里

每百万 token 价格，核对于 10 月 19 日。官方价格来自 MiniMax 按量付费页面；M3 的价格包含其“永久五折”标签。

模型	官方输入/输出	AIHubMix 输入/输出	AIHubMix 缓存读取
MiniMax M2.7	$0.30 / $1.20	$0.2958 / $1.1832	$0.05916
MiniMax M3.1 Flash	未公布	$0.165 / $0.66	$0.0165
MiniMax M3	$0.30 / $1.20	$0.288 / $1.152	—

在 AIHubMix 上，Flash 比 M2.7 低约 44%（$0.165 ÷ $0.2958 ≈ 0.56），比 M3 低约 43%（$0.165 ÷ $0.288 ≈ 0.57），输出侧比例相同。M3 的官方价格在输入超过 512K token 后翻倍，而 AIHubMix 对 Flash 只列一个统一价格。

显式 cache_control 指 Anthropic 兼容 API 中允许调用方通过 cache_control 标记，将特定提示段落写入服务端缓存，后续请求命中缓存时按折扣价读取。它适合长系统提示、固定文档等重复前缀，能显著降低输入成本。MiniMax M3.1 Flash 不支持该字段，但 API 仍会自动报告 prompt_tokens_details.cached_tokens，说明服务端存在自动前缀缓存；区别在于调用方无法手动控制哪些内容被缓存，也无法保证命中。对依赖显式缓存来压缩长上下文成本的团队，这一差异需要在选型时计入。

实测：一次真实的两 Bug 修复任务

准备条件： 环境变量 AIHUBMIX_API_KEY 中配置 AIHubMix 密钥，安装 openai Python SDK。AIHubMix 的快速开始文档覆盖了这两步。

任务设计： 一个计费函数 billable_days(start, end, pauses)，含两个 bug——暂停区间越过计费期末尾时会多算一天，重叠暂停会被重复扣减。提示词描述症状并要求只返回修正后的函数。本地测试框架随后运行 215 个隐藏用例。每种设置在 10 月 19 日通过 Chat Completions 各跑三次。以下数据来自 AIHubMix 自身测量，尚未被第三方复现。

请求代码如下，成本从 usage 字段计算：

import os
from openai import OpenAI

client = OpenAI(base_url="https://aihubmix.com/v1", api_key=os.environ["AIHUBMIX_API_KEY"])
PRICE_IN, PRICE_OUT, PRICE_CACHE = 0.165, 0.66, 0.0165  # AIHubMix, per 1M tokens

def run(prompt, effort=None):
    extra = {"reasoning_effort": effort} if effort else {}
    r = client.chat.completions.create(
        model="minimax-m3.1-flash",
        max_tokens=32768,
        messages=[{"role": "user", "content": prompt}],
        **extra,
    )
    u = r.usage
    cached = (u.prompt_tokens_details.cached_tokens or 0) if u.prompt_tokens_details else 0
    cost = ((u.prompt_tokens - cached) * PRICE_IN + cached * PRICE_CACHE
            + u.completion_tokens * PRICE_OUT) / 1e6
    return r.choices[0].message.content, u.completion_tokens, cost

三次运行结果：

设置	平均输出 token	平均耗时	平均每次修复成本	测试通过
省略 effort（= max）	6,673	56 秒	$0.0045	每次 215/215
effort=low	889	9.5 秒	$0.0006	每次 215/215

默认行的算术如下：464 个提示 token（约 192 个被缓存），加上 6,673 个输出 token。(272 × $0.165 + 192 × $0.0165 + 6,673 × $0.66) ÷ 1,000,000 ≈ $0.0045。按 1,000 次此类修复计算，默认设置约 $4.45，low 档约 $0.64。

方差相当大：默认档的输出 token 在 4,589 到 9,680 之间波动，耗时在 39 到 82 秒之间。这一系列的另一篇文章测量了全部五档强度。

迁移时的五个失败模式

不设 effort 就是 max。 如果你的客户端从不发送强度字段，就要做好长回合和高额思考账单的准备。修复方法：在每个请求中发送 reasoning_effort，从 low 开始试。

无法跳过思考。 M3 可以关闭思考运行，Flash 不行。在实测中，短分类提示几乎不消耗思考 token（0 到 6 个），但零消耗没有保证。如果某条代码路径必须保证非思考调用，保留在 M3 上。

没有 Priority 档。 Flash 会拒绝 service_tier 字段。如果你依赖 M3 的 Priority 档（1.5 倍价格）来保证延迟，这里没有对等方案。

AIHubMix 尚未列出视频输入。 MiniMax 文档写明支持视频，但 AIHubMix 当前只列出文本和图像。Base64 图像与图像 URL 在测试中均正常工作。

提示词必须具体。 一位早期 Space Bunny 用户评价它“快得离谱，但需要清晰具体的指令，否则就太懒了”。要把预期输出和模型应运行的检查明确写出来。

尚无法验证的部分

与 M3 的质量对比。 MiniMax 没有为 M3.1 Flash 发布任何基准，Artificial Analysis 也没有收录它。M3 有 MiniMax 自报的 SWE-Bench Pro 59.0% 和 Artificial Analysis 智能指数 29.2。你看到的任何 Flash 基准表要么是 M3 的数据，要么没有来源。

MiniMax 自己的每 token 价格。 截至 10 月 19 日未公布。

更难的任务。 本次任务是有边界的，low 档就够用。每种设置三次运行无法告诉你更高强度从何处开始产生回报。

开放权重。 MiniMax 表示计划发布，但没有日期。M3 的权重已在 Hugging Face 上。

SWE-Bench Pro 是 SWE-Bench 系列的扩展版本，用于评估模型解决真实软件仓库 issue 的能力。与原始 SWE-Bench 相比，它扩大了任务来源与难度覆盖，要求模型在给定仓库中定位缺陷、修改代码并使隐藏测试通过，评分以通过率为准。该基准被广泛用于编程模型的横向对比，但成绩通常由厂商自行运行并公布，复现条件（如是否允许重试、测试框架版本）会影响可比性。文中提到 M3 的 SWE-Bench Pro 59.0% 为 MiniMax 自报，而 Flash 没有对应数据，因此无法据此判断两者在真实修复任务上的质量差距。

是否应该切换

M Plan / Token Plan 的 M2.5 或 M2.7 用户： 你已经身处其中——MiniMax 从今天起重路由了模型名。重新跑评估，加上强度设置。

按量付费的 M2.5 或 M2.7 用户： 你有到 11 月 18 日的时间。在 AIHubMix 上，改模型 ID 并加上 reasoning_effort。

使用 M3 构建编程 Agent 的团队： 在一小部分流量上试试 Flash 的 low/medium 档。AIHubMix 的对比页展示了两张价格卡，模型页有 ID 和端点。

留在 M3 的情况： 你需要开放权重、可关闭思考、独立基准数据，或者 Priority 档。