MiniMax M3.1 Flash发布，速度与价格成关键

MiniMax M3.1 Flash在同一款轻量模型中结合了200+ TPS的日常输出速度、170+ TPS的P50输出速度、较低的API单价与Coding、Agent能力。它是否适合作为默认模型，仍需根据真实任务成功率和端到端成本判断。2026年10月19日，MiniMax正式发布M3.1 Flash，将其定位为Coding/Agent优化轻量模型，支持100万Token上下文；此前以Space Bunny之名运行的模型是它的早期版本，匿名阶段已处理超过200万亿Token[2]。在定价方面，M3.1 Flash每百万Token的普通输入为1元、输出为4元、缓存读取为0.1元。

200+ TPS要放回真实请求链路

评估模型输出速度，需要先明确统计口径。M3.1 Flash采用更激进的稀疏注意力架构，官方给出的日常输出速度为200+ TPS，P50输出速度稳定在170+ TPS，线上推理速度较前代提升近3倍。TPS表示每秒生成的Token数量，P50则是速度分布的中位数。200+ TPS是特定日常场景下的可达速度，不应直接理解为每个请求都不低于200 TPS的服务下限。对交互式代码生成，可按170至200 TPS作纯算术估算：生成2000个输出Token约需10至12秒；但这仅是模型持续输出阶段的时间，尚未计算请求排队、网络传输、首Token等待、工具执行与结果校验等环节的开销。由于现有发布资料并未给出统一的首Token延迟，因此无法仅凭200+ TPS判断代码补全的实际响应速度。此外，在工具调用和多轮Agent中，模型输出通常只是任务链路的一部分。函数参数、调用计划和中间推理文本均需要由模型生成，高TPS确实能够缩短这些部分的生成时间；然而终端命令执行、浏览器操作、外部API响应以及失败重试不由该速度指标直接反映。对于短输出的工具调用，首Token延迟和外部工具耗时往往更加关键；而对于长规划文本和多轮代码修改，输出速度的影响才会更为明显。

在批量长文本与长输出场景中，TPS的优势更容易被直接观察到。按照P50的170 TPS计算，生成1万个输出Token的纯生成时间约为59秒；处理更大规模的批量任务时，模型吞吐量会直接影响任务完成时间。但100万Token上下文也不意味着满上下文请求仍能保持200+ TPS，长输入还会显著增加输入费用。在真实测试中，必须将输出TPS与首Token延迟、端到端耗时、失败率和并发环境下的整体吞吐量区分开来。现有资料未完整披露测试硬件、输入长度、输出长度、并发规模以及统计周期，稀疏注意力架构本身也不足以推导出固定速度。因而，200+ TPS适合用来描述提速方向和典型场景表现，但不足以作为延迟保障或容量规划的唯一依据。

Coding、Agent与Computer Use要分开评估

在DeepSWE v1.1中，M3.1 Flash得分为73.7，低于DeepSeek V4.1 Flash-1017的77.0，差距为3.3分，因此不能据此宣称它在软件工程任务上领先。在另一项代码修复测试SWE Rfore Bench中，M3.1 Flash得到23.0分，报道称这一成绩超过DeepSeek对应成绩的两倍。由于两项测试针对的编程任务与评分口径不同，这些分数不能合并成一个统一排名；73.7分的软件工程成绩反映了其综合编码表现，而23.0分的代码修复成绩则更多反映了局部修复能力。在Agent和自动化能力评估中，M3.1 Flash在Agents’ Last Exam中取得了29.6%的通过率，报道同时给出了739元的任务成本。在Automation-Bench v1.0.6测试中，其得分为62.2，高于DeepSeek V4.1 Flash-1017的60.5分。此外，该模型在OSWorld V2中的得分为61.7，相关报道将其与Agents’ Last Exam成绩一并列为国产模型第一。这里的739元需要放回Agents’ Last Exam基准的题量、回合数和Token统计口径理解，不应被视为一次API调用的费用；由于现有资料未给出完整的费用拆分方式，它更适合用于同一评测内的模型成本对照。

在BankerToolBench金融工具调用测试中，该模型取得76.2分，与Opus 5并列第一；在CyberGym网络安全测试中，其得分为82.2，与GLM-5.3处于第一梯队。在无工具学术推理测试HLE w/o tools中，其得分为43.4，报道称这一成绩略高于DeepSeek V4.1 Flash-1017[6]。这些结果分别反映了M3.1 Flash在代码生成、工具选择、跨应用操作和专业任务上的表现，但各项结果分别对应金融、网络安全和无工具推理，不能直接据此推导通用能力排名。媒体关于该模型“与DeepSeek基本追平”的说法，是对多项评测结果的综合概括。具体而言，M3.1 Flash在Automation-Bench上取得了更高的分数，但在DeepSWE v1.1上仍低于DeepSeek，同时在代码修复、Computer Use和专业工具测试中展现了各自的优势。将M3.1 Flash接入开发工作流前，应使用真实仓库、真实工具链和明确的成功标准进行测量；单凭基准榜单难以提供充分依据。

API单价之外还要算任务总成本

评估实际使用成本时，需要结合具体计费条件理解相关标题中的“价格砍到1/2”。相较M3，M3.1 Flash的输入和输出单价均降低50%以上，缓存读取单价降低超过70%；官方同时表示，Agentic类任务的综合使用成本降低了70%。这些数字的含义和适用范围不同：输入、输出和缓存读取反映的是API单价，Agentic类任务的综合使用成本则针对特定任务，不能直接套用到每一个应用。按照三类Token分别计费的方式，可以将API基础费用写成明确的计算公式：

任务费用（元）=普通输入Token÷1,000,000×1
             +输出Token÷1,000,000×4
             +缓存读取Token÷1,000,000×0.1

缓存命中的Token应计入缓存读取项，不能在计算费用时与普通输入项重复累加。按每百万Token单价计算，100万普通输入Token与100万输出Token的基础费用为1加4元，合计5元。如果这100万输入全部按缓存读取计费，同时仍产生100万输出Token，费用则为0.1加4元，合计4.1元，此情形与上一项并非同一计费状态的重复计算。以20次调用为例，若累计产生400万普通输入Token和40万输出Token，费用为4加1.6元，合计5.6元；若400万输入全部来自缓存读取，费用则降至0.4加1.6元，合计2元。这组纯算术示例说明了缓存对长上下文任务的影响，并不代表官方基准或实际账单。当输入和输出Token数量相同时，输出费用占总费用的80%，因此代码生成、Agent规划等输出比例较高的任务会主要受到4元输出单价的影响；相反，读取长文档或重复携带工具定义的任务，输入费用与缓存命中率更加关键。与DeepSeek V4.1 Flash-1017的比较同样需要区分闲时、高峰和缓存状态，相关资料列出的每百万Token价格如下：

M3.1 Flash并非在每一种计费状态下都比DeepSeek便宜。在闲时且没有缓存命中的情况下，两者处理100万输入Token与100万输出Token的基础费用均为5元；若转入DeepSeek高峰时段，其相同任务费用将升至2加8元，合计10元，而M3.1 Flash仍维持5元。在假设任务包含1000万缓存读取Token与100万输出Token的条件下，DeepSeek闲时费用为0.2加4元，合计4.2元，高峰费用为0.4加8元，合计8.4元；M3.1 Flash对应的费用则为1加4元，合计5元。这表明，闲时且缓存读取占比很高时，DeepSeek的单价更具优势；高峰时段，M3.1 Flash在未缓存输入和输出上的价格更有优势，开发者不能仅根据单一标价做出判断。

实时Coding场景主要关注首Token延迟、P50输出速度和代码任务成功率，单纯的最低Token单价不足以作为唯一衡量标准。批量Agent则应优先评估成功任务的总费用，将失败重试和额外回合消耗计入考量。100万Token长上下文任务需要关注前缀稳定性和缓存读取比例，预算评估不能忽略满上下文输入下的输出生成占比。工具调用密集型任务需要同时记录模型生成耗时与外部工具执行耗时。对API成本敏感的应用，应把模型单价、Token用量、缓存命中率和任务成功率放进同一个计算公式中整体衡量。选型时，应使用同一批真实任务进行A/B测试，固定代码仓库版本、提示词、工具定义、上下文长度和重试策略，同时记录首Token延迟、P50或P95输出速度、任务总耗时、成功率、输入、输出和缓存Token用量、缓存命中率以及总费用。目前，M3.1 Flash已上线MiniMax API、MPlan和MiniMax Code，MiniMax透露Pro版本将在后续推出。