MiniMax 上线 M3.1 Flash：428B MoE、1M 上下文，推理强制开启改变接入方式
据 MarkTechPost 2026 年 10 月 19 日报道，MiniMax 在 API 上线 M3.1 Flash，428B 总参数、约 23B 激活、1M token 上下文，输入 0.15 美元、输出 0.60 美元每百万 token；官方称权重预计 10 月 23 日发布，许可证尚未披露。
发生了什么
据 MarkTechPost 2026 年 10 月 19 日报道，MiniMax 已在其 API 上线 MiniMax M3.1 Flash（平台模型名 MiniMax-M3.1-Flash），定位编程、智能体办公任务与视觉推理的多模态 MoE 模型。来源列出 428B 总参数、约 23B 激活参数、100 万 token 上下文，并提到稀疏注意力与原生视觉编码器，输入支持文本、图像、视频，输出为文本。这些参数总量与 MiniMax M3 一致，来源指出 MiniMax 未发布技术报告说明 Flash 变体的具体改动。报道称报道时该模型已在 MiniMax API、M Plan 和 MiniMax Code 桌面端可用，支持 Anthropic 兼容与 OpenAI 兼容访问（含 Chat Completions 和 Responses）。报道给出统一价格：每百万输入 token 0.15 美元、输出 0.60 美元，缓存读取 0.015 美元，无长上下文附加费；来源称这约为 M3 标准费率的每 token 一半。推理始终开启且无法关闭，提供 Low、Medium、High、Xhigh、Max 五档努力等级，MiniMax 建议默认 Max；发送 thinking.type=disabled 或 effort=none 会报错，推理内容放在可能缺失的 reasoning_content 字段。来源称权重预计 2026 年 10 月 23 日发布，许可证未披露，自托管硬件未披露；并称 Space Bunny 是 M3.1 Flash 的早期构建。所有基准分数均由 MiniMax 报告，尚无独立复现。
对开发者的影响
对开发者而言，最直接的后果不是参数规模，而是接入契约的变化：推理不可关闭意味着每次请求都存在推理 token 与延迟下限，简单分类、抽取、短问答这类负载的成本结构会被改变。第二处变化是解析路径，来源明确指出依赖从 M3 内联 think 标签提取推理的集成需要改为读取独立的 reasoning_content 字段，且该字段可能缺失，因此解析代码必须容忍它不出现，否则会把正常响应当成异常。第三处是努力等级，五档设置把「质量/成本」从模型选择问题变成参数选择问题，同一模型在同一工作负载上通过 effort 就能得到差异明显的分数与花费，来源以 Automation-Bench 图表说明各档均低于每项任务 0.05 美元。第四处是兼容层，OpenAI 兼容与 Anthropic 兼容同时提供，意味着现有 SDK 迁移路径较宽，但 effort 与 reasoning 字段属于厂商扩展，跨供应商切换时难以原样搬运。需要强调的是，上述基准、成本与速度（报道提到产品页约 150 token/秒、公告称是 M3 的 3 倍）均为 MiniMax 报告口径，没有独立验证；来源自身也记录了图表与表格之间的不一致（最大努力档 62.8 与 62.2），并指出 Automation-Bench 数字不能跨来源直接比较，例如 Kimi K3 模型卡在 600 项任务公开子集上报告 30.8，而 MiniMax 表格列出 46.7。编程能力是这套叙事里最弱的一环，来源称 Terminal Bench 4.0 为 38.1，落后 Opus 5 的 51.8 约 13.7 分，NL2Repo-Bench 也落后约 14.1 分。自托管方面，在权重与许可证实际公布之前，部署方无法判断商用与再分发权利，来源只说明 M3 的 MXFP8 构建约 440 GB，可作为硬件量级的粗略参考，而不是 M3.1 Flash 的实际体积。
接入与评估建议
建议一：先验证推理字段的解析改造，再谈迁移。触发这项决策的已报告变化是推理常开、禁用会报错、内容移入 reasoning_content。实际要做的选择是把内部推理抽取层从「匹配内联标签」改为「读取结构化字段并允许缺失」。前置条件是代码库里存在依赖内联标签的解析或后处理逻辑；若已按结构化字段解析，此项工作可跳过。可测量的验证标准是在固定的一批样本上统计 reasoning_content 缺失时的响应成功率与解析失败率，确认缺失不会导致内容丢失或异常抛出。建议二：把努力等级当作可调参数做一次成本-质量曲线，而不是照搬官方推荐的 Max。已报告的变化是五档 effort 且默认建议 Max。实际选择是针对每类负载固定一个档位并写进配置，而不是全局统一。前置条件是任务有可自动判定的成功标准；对没有判定标准的开放式任务，应先用小样本人工标注再比较。可测量的验证标准是同一样本集在 Low 与 Max 之间的通过率差距，以及对应的 token 消耗与端到端延迟变化，若差距小于噪声水平则选低档位。建议三：权重发布后再决定自托管，不要提前按 440 GB 做容量规划。已报告的变化是权重与许可证均未披露。实际选择是继续走 API，还是等许可证明确后评估本地部署。前置条件是许可证是否允许目标用途、硬件是否满足实际权重体积；在这两项明确前，自托管评估缺乏依据。可测量的验证标准是许可证中关于商用与再分发的条款是否覆盖你的使用场景，以及可获取的量化版本在目标卡型上的实测吞吐。
限制与待确认事项
关键不确定性有三点。第一，所有基准、成本与速度数据均为 MiniMax 报告，没有独立复现，来源自己也记录了同一次公告中 62.8 与 62.2 的不一致，以及 Automation-Bench 跨来源不可比的问题。第二，权重计划于 2026 年 10 月 23 日发布，但截至报道时许可证与自托管硬件均未披露，权重可用不等于许可证授予了商用或再分发权利，两者需要分开判断。第三，MiniMax M3.1 Flash 这一版本目前未出现在 KimiSeek 的实时模型目录中，来源所述 API 可用性与价格指的是 MiniMax 官方渠道；若后续考虑通过 KimiSeek 调用，应以站内定价页与模型列表的实际条目为准，价格可能变化。此外，来源未给出 Flash 相对 M3 的技术报告，稀疏注意力的具体实现与视觉编码器的细节无法核实。文中的接入建议与验证方法属于基于已报告变化的分析，不是对模型实际表现的验证结论。