MiniMax (文本模型)

MiniMax 是一家成立于 2022 年初、总部位于上海的 AI 研究公司，其运营的大语言模型系列可与全球最强大的开源权重系统直接竞争。该实验室的文本模型系列涵盖了 MiniMax-Text-01、M1、M2 以及当前的旗舰版 M2.7，支持长上下文推理、软件工程和多步智能体任务执行。本页面仅介绍文本模型 API，不包含 MiniMax 的 Hailuo 视频平台及其音频和音乐生成产品，后者服务于完全不同的应用场景。

MiniMax 文本 API 可通过 platform.minimax.io、兼容 Anthropic 的端点或 OpenRouter 进行访问。该产品线包括基于 Apache 2.0 协议的开源权重模型（M1、M2）以及专有变体。上下文窗口从 M2-Her 角色扮演变体的 66K Token 到 M1 和 MiniMax-01 的 100 万 Token 不等，据报道在推理时具有 400 万 Token 的外推能力。定价从每百万输入 Token $0.15（M2.5）到每百万 $0.40（M1）不等，使 MiniMax 成为用于代码和长文档处理的最具性价比的前沿级 API 之一。主要应用场景：智能体软件流水线、大型代码库分析、多轮指令遵循以及对单 Token 成本敏感的批量内容处理。

MiniMax 概览（2026 年 5 月）

当前 MiniMax 文本模型产品线（按发布时间从早到晚）：

• MiniMax-Text-01 / MiniMax-01（2025 年 1 月）：总参数量 4560 亿，通过混合专家（MoE）架构，每个 Token 激活 459 亿参数。引入了“闪电注意力（lightning attention）”机制，支持 100 万 Token 原生上下文和 400 万 Token 推理外推。发布时的基准测试成绩与 GPT-4o 和 Claude 3.5 Sonnet 相当，同时提供长达 20-32 倍的上下文窗口。在 HuggingFace 上基于 Apache 2.0 协议开源。

• MiniMax-M1（2025 年 6 月 16 日）：总参数量 4560 亿，混合注意力推理模型，100 万上下文，最高支持 80K 输出 Token。提供 M1-40k 和 M1-80k 变体。完整的强化学习（RL）训练在 512 张 H800 GPU 上耗时三周，花费 $534,700，使用了 MiniMax 专有的 CISPO 强化学习算法。SWE-bench 得分：55.6%（40k）和 56.0%（80k）。

• MiniMax-M2（2025 年 10 月 23 日）：总参数量 2300 亿，通过 MoE 每次推理激活 100 亿参数。发布时在 Artificial Analysis Intelligence Index 的所有开源权重系统中排名第一。LiveCodeBench 得分约 83%，SWE-bench verified 得分 69.4%。197K 上下文。输出速度 114.5 Token/秒。

• MiniMax-M2.1：专注于多语言和多任务编程。100 万上下文窗口。针对多步编程任务和企业级语言覆盖。

• MiniMax-M2.5：SWE-bench 得分 70.40%，AIME 得分 88.75%。产品线中价格最低，为 $0.15/1M 输入 Token。在同等任务下，输入费率比 Claude Opus 4.6 便宜约 16 倍。

• MiniMax-M2.7（2026 年 3 月 18 日）：当前旗舰版。SWE-Pro 得分 56.22%，VIBE-Pro 得分 55.6%，Terminal Bench 2 得分 57.0%。GDPval-AA ELO 达到 1495，在该评估的开源模型中得分最高。205K 上下文。

• MiniMax-M2-Her：专为角色扮演和多角色沉浸式交互设计的变体。66K 上下文。

访问选项包括直接 HTTP 调用、OpenAI SDK 或 MiniMax 兼容 Anthropic 的端点（https://api.minimax.io/anthropic），使其能够无缝接入已基于 Anthropic 工具构建的代码库中。

MiniMax 的真正优势

M 系列在软件工程基准测试中始终在开源权重模型中保持领先或并列第一。在 2025 年 6 月 M1 发布时，它在 TAU-bench（智能体工具使用）上领先所有开源模型，在长上下文任务上超越了 Gemini 2.5 Pro 和 OpenAI o3。M2 和 M2.5 延续了这一轨迹，M2.5 在 SWE-bench verified 上达到了 70.40%，与单 Token 成本高出数倍的模型得分相当。

真正的差异化优势在于长上下文与低激活参数量的结合。根据 MiniMax 自己的测量，拥有 100 万 Token 窗口的 MiniMax M1 处理时消耗的计算资源比 100K Token 下的 DeepSeek R1 少约 70%。对于进行大型代码库分析、文档审查或长周期智能体循环的团队来说，这种成本效益至关重要。

“将 MiniMax M2 系列集成到我们的平台对我们的用户来说是一个巨大的胜利。我们发现 M2.1 在处理复杂、多步编程任务的细微差别时，表现出了该领域罕见的一致性。”——开发者平台团队，引自 2026 年 1 月 MiniMax M2.1 发布报道

对于需要自托管或微调的团队来说，开源权重是一个真正的优势。M1 和 M2 均采用 Apache 2.0 协议，允许商业使用和修改。MiniMax-01 论文（arXiv:2501.08313）提供了完整的架构细节，使其成为全球所有实验室中透明度最高的前沿级模型发布之一。

“我们对像 M2.1 这样强大的开源模型感到兴奋，它为各种软件开发任务带来了前沿性能，在某些情况下甚至超越了前沿水平。开发者理应拥有选择权，而 M2.1 提供了这种急需的选择。”——开发者，引自 2026 年 1 月 MiniMax M2.1 发布新闻稿

MiniMax 的局限性：用户经常遇到的问题

速率限制系统是最常被提及的摩擦点。MiniMax 使用固定的 5 小时窗口，而不是滚动速率限制。如果你在上午 9:45 用尽了额度，你需要等到上午 10:00 下一个固定窗口开启。习惯了 OpenAI 或 Anthropic 滚动窗口的开发者会对此感到不适应，而且固定窗口与突发性的智能体工作负载兼容性较差。在 2026 年 3 月 23 日之后注册账户的用户还面临早期用户所没有的每周配额上限，这在同一产品内造成了不平等的访问层级。

模型输出较为冗长。Artificial Analysis 测量到 M2 在评估期间“生成了 7000 万个输出 Token，略高于平均水平”，这直接转化为生产环境中更高的输出成本。对于预期输出较短的摘要或分类任务，这种冗长性会显著增加账单费用。

对于大多数团队来说，本地推理是不切实际的。拥有 4560 亿参数的 MiniMax-M1 需要大多数开发者无法获取的硬件。2025 年底 HuggingFace 上的社区讨论引发了对 llama.cpp 兼容性的不确定性。2300 亿参数的 M2 相对可行，但如果没有集群仍然遥不可及。

存在内容限制。中国监管要求（2023 年的一项法律禁止“破坏国家统一和社会和谐”的内容）意味着模型会过滤政治话题，特别是涉及中国治理和领土问题的话题。对于一般的编码和写作任务，这很少出现，但对于新闻、政策研究或地缘政治分析团队来说，这是一个已被记录的限制。

在纯数学推理方面，MiniMax M2 落后于更专注的推理模型。AIME-25：MiniMax M2 为 78%，而 Kimi K2 Thinking 为 94-99%。如果逐步数学推导或形式化证明生成是主要应用场景，Kimi 或 Qwen3.5 是更好的选择。

MiniMax vs. Qwen vs. DeepSeek

这三家都是中国主要的开源权重实验室，在 2025-2026 年间快速连续发布模型。它们之间的差异在于架构和运营层面，而不仅仅是营销手段。

MiniMax vs. Qwen（阿里巴巴）：两者都使用稀疏激活的混合专家（MoE）架构。Qwen3.5 每次前向传递激活约 370 亿参数；MiniMax M2.7 从 2300 亿总参数中激活 100 亿，使得 MiniMax 的单 Token 计算成本更低。Qwen3.5 的上下文窗口达到约 991K Token，与 MiniMax M1 的 100 万相当。在竞技编程方面，Qwen3.5 领先（LiveCodeBench 85.33% vs. MiniMax M2 的约 83%）。在知识密集型任务上，Qwen3.5 在 GPQA Diamond 上得分为 87.37%。两者的旗舰版输入定价相当，均为 $0.30/1M，不过 MiniMax M2.5 以 $0.15 的价格低于 Qwen 的旧变体。对于大多数编码和分析任务，两者之间的选择确实难分伯仲；Qwen 在知识检索和竞技数学方面略占优势，而 MiniMax 在上下文长度和原生智能体工具使用方面略胜一筹。

MiniMax vs. DeepSeek V3.2：机制上的差距在于吞吐量与上下文深度。DeepSeek V3.2 每秒生成约 230 个 Token；MiniMax M2 生成 114.5 个。如果速度是主要限制因素，DeepSeek 大约快两倍。当 MiniMax M1 在 2025 年 6 月发布时，其 100 万 Token 的上下文比 DeepSeek R1 的 128K 窗口大 8 倍，这是一个具体的架构差距。DeepSeek V3.2 此后扩展了上下文，但 MiniMax M1 和 MiniMax-01 仍然是超长输入处理的标杆。速率限制设计也有所不同：DeepSeek 使用滚动窗口，MiniMax 使用固定的 5 小时窗口。具有突发使用模式的团队通常报告 DeepSeek 的系统更容易配合工作。

为了完整起见，来自 Moonshot AI 的 Kimi K2 是该层级的第三个主要竞争对手。Kimi 使用 1 万亿总参数（320 亿激活），在 BrowseComp 上优于 MiniMax M2（60.2% vs. 44.0%），并在 AIME 数学上与 Claude Opus 4.6 相当。MiniMax 在价格上低于 Kimi（旗舰版输入为 $0.30 vs. $0.60/1M）。同样值得比较的还有：Zhipu GLM 和 Llama，它们是不同能力和成本点上的开源权重替代方案。

付费 API 层级值得吗？

根据独立分析，在 $0.15/1M 输入 Token（M2.5）的价格下，MiniMax 的输入成本比 Claude Opus 4.6 便宜约 16 倍，单 Token 的总 API 成本约为其 8%。对于批量处理、代码审查流水线或大规模文档分析，其经济性极具吸引力。

关键的注意事项：MiniMax 并不像某些开源托管服务那样提供真正的免费推理层级。Token Plan 是预付费的批量套餐；Unlimited Monthly Plan 专为重度企业使用而设。对于评估和原型设计，OpenRouter 托管了大多数 MiniMax 模型，提供按量付费访问，起步价即为上述单 Token 费率，这是在承诺使用直接平台账户之前阻力最小的测试方式。

MiniMax M2.7-highspeed 变体的价格为 $0.60/1M 输入，是标准 M2.7 费率的两倍。开发者在使用第三方集成时应确认默认调用的是哪个变体，因为在 API 包装器文档中命名可能会有歧义。

对于拥有足够基础设施的团队，可以自托管基于 Apache 2.0 协议的开源权重模型（M1、M2），部署后完全消除单 Token 成本。这是大规模用户最具成本效益的路径，但需要具备 2300 亿至 4560 亿参数的部署能力。

最佳应用场景（以及何时应避免使用）

非常适合：

• 智能体软件工程流水线、CI/CD 自动化和多步代码生成。TAU-bench 的性能通过可验证的数据支持了这一应用场景。

• 长文档分析，200K-1M Token 的上下文窗口消除了分块的需要。适用于整个代码库、法律文档、研究语料库。

• 对成本敏感的生产工作负载，在这些场景中 Claude 或 GPT-4 的定价不可持续，且代码任务的响应质量需要保持在接近前沿的水平。

• 需要 Apache 2.0 许可的自托管或微调应用场景。

• 已经基于 Anthropic SDK 构建的团队，希望在端点级别无缝替换为更便宜的模型而无需更改代码。

在以下情况避免使用 MiniMax：

• 输出吞吐量高于 150 Token/秒是硬性要求。DeepSeek V3.2 能更好地处理突发的高速推理。

• 应用场景涉及政治、地缘政治或中国司法管辖区敏感话题，内容过滤可能会产生干扰。

• 主要任务是数学证明生成或竞技数学。Kimi K2 Thinking 和 Qwen3.5 在 AIME 和形式推理基准测试中得分明显更高。

• 需要可预测的滚动速率限制。固定的 5 小时窗口设计需要为智能体工作流重新架构重试逻辑。

• 需要在消费级硬件上进行本地推理。参数量太大，除了企业级 GPU 集群外无法运行。

开始使用 MiniMax

最快的路径：在 platform.minimax.io 创建账户，购买 Token Plan 套餐，并使用现有的 Anthropic SDK 代码通过兼容 Anthropic 的端点（https://api.minimax.io/anthropic）调用 API。设置基础 URL 和 API 密钥；模型字符串变为 "MiniMax-M2.7" 或 "MiniMax-M2.5"，具体取决于你的性价比目标。

如果不想创建账户进行评估，OpenRouter 将 MiniMax M2 和 M2.7 列为按量付费模型，可通过 OpenRouter 密钥访问。这是在承诺使用 MiniMax 平台账户和 Token Plan 之前推荐的第一步。

开源权重的 M1 和 M2 模型位于 HuggingFace 的 MiniMaxAI 组织下。对于自托管，建议从 M2 变体（总参数 2300 亿，激活 100 亿）开始，作为比 M1 的 4560 亿更易于处理的部署目标。社区已成功使用 vLLM 和 SGLang 进行推理服务。

速率限制规划：假设为固定的 5 小时窗口，并相应地构建指数退避（exponential backoff）策略。Coding Plan（基于提示词配额）和直接 API 额度计费对于不同的工作负载形态具有不同的经济性；运行持续智能体循环的团队通常更喜欢额度计费，以避免套餐窗口阻塞。