MiniMax M3.1 Flash 上线：单价腰斩，但 thinking 关不掉了

先把口径分清：哪些是官方确认，哪些是转述#

这三种来源在后面的结论里权重完全不同，先列清楚：

平面定价的真正含义是「长上下文不加价」#

M3 是分档的：512K 输入以内 0.30 / 1.20，超过 512K 输入单价翻倍到 0.60 / 2.40，缓存 0.12。M3.1 Flash 把分档整个取消：0.15 / 0.60 / 0.015，1M 上下文一个价。

我在写这篇前直接拉了 OpenRouter 的模型清单（468 个模型）做交叉核对：

三行合起来说明两件事。第一，M3 的短档单价与第三方转述的官方价格页一致（0.30 / 1.20），所以「M3.1 Flash 单价是 M3 的一半」这个说法有价格依据，不是媒体口径。第二，付费档今天还没上架——minimax/minimax-m3.1-flash:free 的单价读出来是 0，免费窗口还开着；按第三方记的 10 月 19 日 11:56 UTC 上线时间起算，72 小时窗口会在 10 月 22 日 11:56 UTC 前后到期。

顺手记一个模态细节：这条免费档的输入模态是 text / image / video，输出只有 text，单次最大输出 524,288。也就是说它是「能看图看视频、只吐文字」的形态，官方那句「前沿多模态编码模型」里的「多模态」指的是输入端。

但免费档不能拿来做容量规划。 它的作用是给你一个零成本试错的入口，不是一条可以写进 SLO 的线路——原因见下面「速度」那一节。

单价腰斩 vs 总成本降 70%：中间那 40% 在哪#

这是本文最值得自己动手算的一段。

单价确实是 M3 短档的 50%：0.15 对 0.30、0.60 对 1.20，都是整整齐齐的一半。但官方同时说了「用量成本降 70%」。总花费 = token 量 × 单价，于是：

• 单价降到 50%，若 token 量不变，总花费只能降 50%；
• 要降到 30%（即降 70%），token 量必须变成 0.30 / 0.50 = 60%，也就是完成同一个任务要少花约 40% 的 token。

这 40% 从哪来？官方只给了「更激进的稀疏」和「快 3 倍」两句话，没给 token 账。而价格表里有一条很容易被忽略的线索：缓存价 0.015。

M3 短档缓存是 0.06，长档是 0.12。M3.1 Flash 的缓存价分别是它们的 1/4 和 1/8。也就是说，如果一个 Agent 负载每轮都在重读同一段前缀（仓库上下文、系统提示、工具定义），那么降价的主战场根本不在输入和输出行，而在缓存行。

代码：把一次 Agent 任务的花费算到三行上#

下面这个脚本把「输入 / 缓存命中 / 输出」分开计价，模拟一个典型的读仓库 Agent：12 轮，每轮重读整个仓库（命中缓存）、新增 4K 工具输出、产生 2.5K 输出（含 thinking）。它跑出来的数字就是本文后半段的依据。

PRICES = {
    "M3 (<=512K)": {"in": 0.30, "out": 1.20, "cache": 0.06},
    "M3 (>512K)":  {"in": 0.60, "out": 2.40, "cache": 0.12},
    "M3.1 Flash":  {"in": 0.15, "out": 0.60, "cache": 0.015},
}

def turn_cost(p, fresh_in, cached_in, out):
    """一次调用：新输入走 input 价、命中前缀走 cache 价、输出（含 thinking）走 output 价。"""
    return fresh_in / 1e6 * p["in"] + cached_in / 1e6 * p["cache"] + out / 1e6 * p["out"]

def agent_task(p, turns=12, repo_tokens=60_000, per_turn_new=4_000, out_per_turn=2_500):
    total, context = 0.0, repo_tokens
    for _ in range(turns):
        total += turn_cost(p, per_turn_new, context, out_per_turn)
        context += per_turn_new + out_per_turn
    return total, context

实跑输出：

== 单次调用：8K 输入 / 3K 输出 ==
M3 (<=512K)    $0.006000   相对 M3 短档 100.0%
M3 (>512K)     $0.012000   相对 M3 短档 200.0%
M3.1 Flash     $0.003000   相对 M3 短档  50.0%

== Agent 任务：12 轮 / 每轮重读 60K 仓库 + 4K 新工具输出 + 2.5K 输出 ==
M3 (<=512K)    $0.1193   结束上下文 138K
M3 (>512K)     $0.2387   结束上下文 138K
M3.1 Flash     $0.0424   结束上下文 138K

M3.1 Flash / M3 花费比 = 35.6%  → 降幅 64.4%
若单价腰斩(50%)而总成本要降 70%，则 token 量必须降到 60%（少花 40%）

== 只换缓存价这一项（输出/输入价都不变）的敏感度 ==
M3 原价                      $0.1193
只把 cache 价压到 0.015         $0.0676

三行结论值得单独划出来：

1. 一次性调用只降 50%。8K 输入 3K 输出这种没有前缀复用的场景，你拿到的就是单价那一半，跟「70%」无关。
2. 缓存重的 Agent 负载能降到 35.6%（降 64.4%）——已经接近官方口径的 70%，说明那 70% 是特定负载形态下的数字，不是「所有场景统一降 70%」。
3. 最后一行是敏感度对照：光把缓存价从 0.06 压到 0.015，就能把同一任务从 0.1193 砍到 0.0676（降 43%）。如果你的系统没有做前缀缓存（比如每轮把上下文重新拼一遍、或者带时间戳/随机 ID 导致前缀永不稳定），你花的钱会更接近 M3 的那一列。迁移之前先把缓存命中率量出来，这比选模型重要。

迁移坑一：thinking 关不掉，关掉直接 400#

官方文档写死了：M3.1 Flash 的思考不能禁用。传 {"thinking": {"type": "disabled"}} 或 effort="none"，服务端返回 400，错误信息是「model … requires adaptive thinking」。

这不是「静默忽略参数」，是直接报错。以前靠关思考压成本的批处理任务（分类、字段抽取、格式改写）从 M3 迁过来，会第一时间挂掉。

更隐蔽的是默认值：effort 允许 low / medium / high / xhigh / max，默认 max。你什么都不写，就是最高档，输出 token（含思考）按最高档烧。而输出单价是输入单价的 4 倍（0.60 对 0.15），这一项对账单的影响比输入侧的降价大得多。迁移时省钱的第一个动作，是显式把 effort 降到你实际需要的档位。

那关不掉的思考，到底多花多少钱#

思考不可关闭这件事，账要按「多出来的输出 token」算，因为输出单价是输入的 4 倍。假设一个本该零思考的分类任务：8K 输入，真正需要的答案只要 200 个输出 token，但每轮会附带若干思考 token。按官方单价跑一遍：

思考 token     0 -> M3.1 Flash 每次 $0.001320（比零思考多   0.0%）
思考 token   200 -> M3.1 Flash 每次 $0.001440（比零思考多   9.1%）
思考 token   500 -> M3.1 Flash 每次 $0.001620（比零思考多  22.7%）
思考 token   800 -> M3.1 Flash 每次 $0.001800（比零思考多  36.4%）
思考 token  1500 -> M3.1 Flash 每次 $0.002220（比零思考多  68.2%）

也就是说，800 个思考 token 就把单次成本顶高 36%。输入侧那 50% 的降价，很容易被输出侧的思考吃回去一大半。

effort 是唯一能压这一项的旋钮（思考不能关、但档位能降）。把 12 轮 Agent 任务里每轮的输出 token 当成 effort 的代理量，同一份单价下：

effort=max（默认）     每轮输出  2500 tok -> $0.0424（相对默认 100.0%）
effort=high           每轮输出  1500 tok -> $0.0342（相对默认  80.7%）
effort=medium         每轮输出   800 tok -> $0.0285（相对默认  67.2%）
effort=low            每轮输出   400 tok -> $0.0252（相对默认  59.5%）

从默认的 max 换到 low，账单能再降约 40%——这个幅度和「单价腰斩」是一个量级的。所以迁移 M3.1 Flash 的正确顺序是：先显式设 effort，再谈缓存优化。注意这里每轮输出 token 是我按档位给的假设值，不是官方公布的换算比（官方没有公布 effort 与 token 数的对应关系），你要拿自己的 usage 字段回测：同一个任务在 low 和 max 下各跑一次，看 completion_tokens 差多少，那个比例才是你的真实系数。

迁移坑二：effort 的字段名三种协议各不相同#

MiniMax 同时提供两条兼容线路，字段名不一样：

读思考内容的位置也不同：OpenAI 协议放在 reasoning_content 里，Anthropic 协议是一个 thinking block。如果日志或统计脚本只抓 content，thinking 会被静默丢掉——它不显示，但按输出 token 计费。

OpenAI 兼容线路的最小请求：

curl https://api.minimax.io/v1/chat/completions \
  -H "Authorization: Bearer $MINIMAX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMax-M3.1-Flash",
    "reasoning_effort": "low",
    "messages": [{"role": "user", "content": "把这个函数改成尾递归"}]
  }'

从 Anthropic 协议改过来的话，把 reasoning_effort 换成 output_config.effort 即可，max_tokens 这类字段不变。

代码：迁移前自检，把 400 和默认 max 提前抓出来#

改一个模型名就上线，是这次迁移最容易踩的坑。下面这个 linter 拿请求模板当输入，把「会 400 的字段」「未显式设 effort」「跨协议抄错字段名」三类问题一次扫出来：

ALLOWED_EFFORT = {"low", "medium", "high", "xhigh", "max"}
EFFORT_KEY_BY_PROTOCOL = {
    "anthropic":        ("output_config", "effort"),
    "openai-chat":      ("reasoning_effort", None),
    "openai-responses": ("reasoning", "effort"),
}

def lint(payload, protocol="openai-chat"):
    problems = []
    t = payload.get("thinking")
    if isinstance(t, dict) and t.get("type") == "disabled":
        problems.append('thinking={"type":"disabled"} → 400：M3.1 Flash 只支持自适应思考')
    if payload.get("enable_thinking") is False:
        problems.append("enable_thinking=false → 400（同上）")

    outer, inner = EFFORT_KEY_BY_PROTOCOL[protocol]
    raw = payload.get(outer)
    effort = raw.get(inner) if (inner and isinstance(raw, dict)) else (raw if not inner else None)
    if effort == "none":
        problems.append('effort="none" → 400（同上）')
    elif effort is None:
        problems.append("未显式设置 effort：默认 max，输出 token 按最高档走")
    elif effort not in ALLOWED_EFFORT:
        problems.append(f'effort="{effort}" 不在允许值内')

    if "service_tier" in payload:
        problems.append("service_tier 不被 M3.1 Flash 接受，M3 的优先档没有跟过来")
    if protocol != "anthropic" and "output_config" in payload:
        problems.append("把 Anthropic 的 output_config 发到了 OpenAI 兼容端点")
    if protocol == "anthropic" and "reasoning_effort" in payload:
        problems.append("把 reasoning_effort 发到了 Anthropic 端点")
    return problems

跑真实用例的输出：

[旧批处理模板（M3 时代，显式关思考）]  (openai-chat)
  ✗ thinking={"type":"disabled"} → 400：M3.1 Flash 只支持自适应思考，不能关
  ✗ 未显式设置 effort：默认 max，输出 token 会按最高档走（省钱请显式降档）

[旧优先档模板]  (openai-chat)
  ✗ 未显式设置 effort：默认 max，输出 token 会按最高档走（省钱请显式降档）
  ✗ service_tier 不被 M3.1 Flash 接受：M3 的 1.5× 优先档没有跟过来，请删掉

[跨协议抄字段]  (openai-chat)
  ✗ 未显式设置 effort：默认 max，输出 token 会按最高档走（省钱请显式降档）
  ✗ 把 Anthropic 的 output_config 发到了 OpenAI 兼容端点：应改用 reasoning_effort

[只补了 model 名，没补 effort]  (anthropic)
  ✗ 未显式设置 effort：默认 max，输出 token 会按最高档走（省钱请显式降档）

[改对了的样子]  (anthropic)
  ✓ 没发现问题

五个用例里四个有问题，其中**「只改了 model 名」就是最常见的那个动作**。你如果只从 M3 复制了一份配置、把模型名换成 M3.1 Flash，那么在关思考这件事上会直接 400，在 effort 这件事上会悄悄按 max 计费。

顺带一个第三方提到、官方页面没写到的差异：service_tier 参数不被 M3.1 Flash 接受。M3 的 1.5× 优先档没有跟过来，写进请求里不会生效。

官方自己的文档和博客在打架#

这类矛盾在迁移期最费时间，值得单独拎出来：

• 发布博客写的是：「M3.1 Flash is now available through the MiniMax API, M Plan, and MiniMax Code」。
• 我们抓到的 API 文档页（platform.minimax.io/docs/guides/text-generation）顶部横幅写的是：「MiniMax-M3.1-Flash-Preview is available only through M Plan and MiniMax Code for now」，模型名还多一个 -Preview 后缀。

两处不能同时为真：一个说 API 已经能用、模型名不带后缀；另一个说 API 还不能用、名字是预览版。不要把搜索来的模型名直接写死进生产配置。 迁移时的做法是打一次 GET /v1/models（或者看控制台模型列表），拿到真实可用的模型 ID 再写进配置；服务端返回的 404 和「仅预览可用」是两种完全不同的失败，混淆了会白排查半天。

这条也顺带解释了一个现象：为什么同一个模型，不同人报出来的「能不能用」说法不同——免费档、M Plan、MiniMax Code、按量 API 是四条不同的交付路径，权限和名称可能不一致。

权重还没放，别按「可自托管」做规划#

官方博客写的是权重稍后放出。第三方记的时间是 10 月 23 日（转述 X 上的公告，不属于官方页面）。

我自己的复核是：hf-mirror 上 MiniMaxAI 名下，今天还没有 M3.1 的权重仓库。所以如果你的方案里写着「先用 API 试，下周本地部署」，这一条得先打个问号。第三方还提到架构是 428B 总参数 / 约 23B 激活的 MoE、稀疏注意力、外加原生视觉编码器——这个量级本来也不是单机能跑的形态，四张卡以下的本地部署计划可以直接划掉。

速度：200 TPS 和 103 tok/s 不是一个东西#

官方口径是输出 200+ TPS、P50 170+。第三方在 OpenRouter 免费档上量了三天，中位数是 103 tok/s、首 token 1.15 秒。

两个数字都不算错，但量的不是同一条线路：免费档必然限流，厂商口径大概率是自有 API 的稳态表现。要写进容量规划的，只能是你实际会付钱的那条线路的测速。 拿免费档的数字做容量表，或者拿厂商数字去做 SLA 承诺，两头都会失准。

同一条材料里还有个值得记一笔的细节：第三方引用 OpenRouter 的说法，匿名期里 MiniMax 修过首 token 延迟（1.95 秒 → 1.22 秒）、吞吐（70 → 100 tok/s）和错误率（1.4% → 0.7%）。**「匿名上架 → 收集真实流量 → 上线前修一轮」**这套流程，比任何发布文案都更能说明现在模型上线的真实工序。

榜单怎么读：同一批材料里 AutomationBench 有三个数字#

官方表里给的：BankerToolBench 76.2、DeepSWE v1.1 73.7%、OSWorld V2 61.7、Agents’ Last Exam 29.6、CyberGym 82%，AutomationBench-AA 标为顶级。

但同一批材料里 AutomationBench 出现了三个不同的数字：表格里 62.2、成本图里 effort=max 时的 62.8%、OpenRouter 口径的 72.5%（AA 变体）。harness 不同、effort 档位不同，这三个数就不能直接比较。

第三方还有一张横向对比表，把 DeepSWE v1.1 摆在一起：DeepSeek V4.1 Flash 1017 是 77.0、Opus 5 是 74.0、GPT-5.6 Sol 是 73.0、M3.1 Flash 73.7、Kimi K3 67.5、GLM-5.3 66.9。也就是说，M3.1 Flash 落在第一梯队靠后的位置，不是榜首——它的卖点在价格，不在绝对能力。AA 的独立指数给的是 42，比 M3 高 13 个点，这个进步幅度是真的。

结论很简单：这些数字都是厂商自报加第三方转述，选型时拿自己的任务集跑一遍，别按榜单下单。

总结#

• M3.1 Flash 的前身是匿名跑了一个月、处理 200+ 万亿 token 的 Space Bunny，这是官方博客确认的。
• 定价是平面 0.15 / 0.60 / 0.015（每百万 token），1M 上下文不加价；单价恰好是 M3 短档的一半，缓存价是 M3 的 1/4 到 1/8。
• 「成本降 70%」不是统一降幅：一次性调用只降 50%，只有在缓存命中很重的 Agent 负载上才可能接近 70%。自己算一遍只要十几行代码，我这份模拟跑出 64.4%。
• thinking 关不掉，关掉直接 400；effort 默认 max，且三种协议的字段名不同。迁移时第一个动作是显式降 effort、并把 linter 挂到 CI 上。
• 官方文档和发布博客在「模型名」和「API 是否可用」上互相打架，以 GET /v1/models 的实测结果为准。
• 权重还没放，OpenRouter 上只有免费档（72 小时窗口），今天正好在到期日；要付费容量规划，用你自己那条线路的测速，别用免费档数字。
• 能力上它是第一梯队靠后，不是榜首；这次值得迁移的理由是成本和缓存计价结构，不是分数。

参考与致谢：MiniMax 官方博客《MiniMax M3.1 Flash》（10 月 19 日）、MiniMax 平台文档 text-generation 页、OpenRouter 模型清单 API（本机 10 月 22 日实测）、第三方报道（digitalapplied、cellcog 的发布时间线与定价摘录）。所有「第三方」标注的数字均未获官方页面逐条确认，请以你自己的实测账单为准。