MiniMax M3 API：百万上下文与编码指南

MiniMax M3 API 为代码代理、长流程工具工作流和多模态分析而生。它接受文本、图片和视频输入，支持多达百万级 token 的上下文窗口，并暴露思维控制来在延迟与推理深度之间权衡。开源权重也已发布，但对于不想运维 800GB 级检查点的团队来说，托管 API 是实用之选。

本指南分离 MiniMax 原生 API 行为与当前 reAPI 路由。两者的区别很关键，因为模型 ID、计价档位和请求接口并不一致。

TL;DR

MiniMax 于 2026 年 6 月 1 日发布 M3，随后在 MiniMax 社区许可证下公开权重。^[1]
托管模型支持高达 百万 token 上下文，原生支持文本、图片和视频输入。^[2]
MiniMax 在 512K token 的输入阈值上下采用不同的定价。
reAPI 当前使用统一费率：$0.60 输入、$2.40 输出、$0.12 缓存读每百万 token。
使用 M3 来分析代码库、构建编码代理、处理文档密集型工作和多模态任务。不要假设有了百万 token 窗口就无需信息检索、信息压缩或 prompt 组织。

MiniMax M3 API 规格

规格	MiniMax M3
发布日期	2026 年 6 月 1 日
上下文窗口	高达百万 token
保证托管上下文	至少 512K token
输入模态	文本、图片、视频
输出	文本
推理模式	启用、自适应、禁用
推荐采样	`temperature: 1.0`、`top_p: 0.95`
reAPI 模型 ID	`minimax/minimax-m3`
reAPI 端点	`/v1/chat/completions`
权重	发布于 Hugging Face 和 GitHub

MiniMax 把 M3 描述为由 MiniMax 稀疏注意力驱动的编码和代理模型。该架构旨在降低百万级 token 注意力的计算和内存成本。这是厂商对其架构的声明，而非保证每一个百万 token 请求都快速或在整个序列上精度一致。

发布的检查点约 427 亿参数，主要 Hugging Face 仓库未计本地部署开销约 854GB。通过 SGLang、vLLM、Transformers 和 KTransformers 等框架可以本地部署，但这不是一个随意的单 GPU 模型。^[1]

MiniMax M3 API 定价解析

MiniMax 的原生 API 将普通和长上下文调用分开定价。其当前促销价表列出以下标准服务价格：

路由	输入 / 百万	输出 / 百万	缓存读 / 百万
MiniMax 原生，输入 ≤512K	$0.30	$1.20	$0.06
MiniMax 原生，输入 512K–1M	$0.60	$2.40	$0.12
reAPI 当前费率	$0.60	$2.40	$0.12

上述原生价格是 MiniMax 在 2026 年 8 月 1 日展示的折扣率。该页面还显示更高的划掉原价，所以生产预算应该存储检索日期而非把折扣当作模型的永久属性。^[3]

reAPI 使用单一 token 费率而不在 512K 边界改价。这使估算更容易，尽管短上下文调用可能通过 MiniMax 原生促销档获得更便宜的价格。

MiniMax M3 上下文与定价地图，显示 512K 边界、百万 token 窗口和当前 reAPI 统一费率

现实成本示例

假设一个代码库分析任务通过 reAPI 发送 180,000 个未缓存输入 token 并返回 12,000 个输出 token：

input  = 180,000 / 1,000,000 × $0.60 = $0.1080
output =  12,000 / 1,000,000 × $2.40 = $0.0288
total  = $0.1368

当重复 prefix 命中缓存时，同一工作流变得更便宜。把稳定的工具定义、代码库指令和系统上下文放在前面；把变动的任务细节放在末尾。MiniMax 说自动 prompt 缓存使用 prefix 匹配，适用于至少 512 token 的输入。^[4]

如何通过 reAPI 调用 MiniMax M3

reAPI 路由使用熟悉的 OpenAI Chat Completions 形态。重要细节是命名空间模型 ID。

curl https://api.reapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $REAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "minimax/minimax-m3",
    "messages": [
      {
        "role": "system",
        "content": "Review code conservatively. State assumptions before editing."
      },
      {
        "role": "user",
        "content": "Find the race condition in this queue worker and propose a minimal patch."
      }
    ],
    "temperature": 1,
    "top_p": 0.95,
    "max_tokens": 8192
  }'

使用模型发现返回的精确 ID 集成到生产密钥。MiniMax M3 模型页面和 API 文档展示当前 reAPI 接口。

MiniMax 原生端点使用 MiniMax-M3 而非 reAPI 命名空间 ID。不要把一个厂商的模型字符串复制到另一个厂商的请求中，并假设网关会标准化它。

思维模式与代理行为

开源模型卡记录三种推理模式：

enabled：总是使用显式推理。
adaptive：让 M3 决定何时额外推理有帮助。
disabled：最小化延迟并最大化吞吐量。

对代码审查、调试、多步规划和工具密集型代理，从自适应或启用推理开始。对自动完成、分类和简短变换，禁用推理可以减少延迟。MiniMax 说启用和禁用思维在原生 API 上共享相同的 token 费率；成本差异来自请求最终消耗多少 token，不是单独的推理费用。^[2]

推理控制可能跨托管路由不同。如果应用依赖特定的 thinking 字段，在发布前测试接受的请求 schema 而非假设所有 OpenAI 兼容端点都转发它。

百万 token 窗口的用处

长上下文窗口在模型需要同时处理多个相关工件时最有用：

一个代码库加上 issue 历史和构建日志；
一套长合同集合带交叉文档引用；
一段视频转录配合选定的帧；
多步代理轨迹应该保留用于后续决策。

当 prompt 是未过滤的转储时就没那么有用。大输入增加延迟并可能淹没相关证据。生产代理应该仍然去重文件、优先检索可能的片段、总结已完成的工具轨迹并保留精确源位置用于验证。

如果你的决策主要关于开源权重和管理可靠性，对比 Kimi K3 和 Claude Opus 5。关于另一个低成本百万 token 编码模型，见 GLM-5.2 API 指南。

MiniMax M3 限制

主要约束是运营规模。发布权重让团队获得部署控制，但这不会使一个 427B 参数的多模态模型易于部署。量化减少内存，而长上下文把 KV 缓存和吞吐量压力加回系统。

基准声明也需要背景。MiniMax 报告在 SWE-Bench Pro 上 59.0% 以及在 Terminal-Bench 2.1 上 66.0%，但发布说明解释了不同模型有时使用不同的脚手架且多个结果来自内部基础设施。^[2]把那些分数看作预期能力的证据，不是你自己代理中成功的预测。

最后，百万 token 可用性可能取决于服务容量。MiniMax 把 512K 描述为保证，上界为高达 1M。测试你计划使用的精确地域、账户、并发和请求大小。

MiniMax AI. MiniMax M3 官方模型仓库和本地部署指南。 huggingface.co/MiniMaxAI/MiniMax-M3
MiniMax. MiniMax M3：前沿编码、百万上下文、原生多模态。 minimax.io/blog/minimax-m3
MiniMax API Platform. MiniMax M3 按用量付费定价。 platform.minimax.io
MiniMax API Docs. 自动 prompt 缓存。 platform.minimax.io/docs/api-reference/text-prompt-caching