MiniMax M3 API：价格、在线体验与示例

项目编程：围绕现有代码推进修复与功能迭代

我们会优先把 MiniMax M3 用于目标明确的任务迭代，例如修复已有问题、根据接口约定补充功能，或根据测试结果调整实现。Thinkwright 的公开工程实验显示，M3 与 GLM-5.2 在已有代码的修复和功能补充任务上表现接近，较明显的差距集中在从零构建项目。

我们据此建议，如果你是原有项目的持续改进和新功能迭代，那么可以尝试使用M3。

长文分析：联合阅读代码库、文档与运行日志

MiniMax M3 使用 MSA 稀疏注意力处理长上下文。其技术论文介绍了先筛选相关信息块、再执行注意力计算的方法，以降低超长输入的计算开销。

我们更关注它在跨资料分析中的价值，例如检查代码实现是否符合需求、比较多个版本的接口约定，或结合日志还原问题发生过程。我们建议为资料保留文件名、版本和时间信息，并要求结论对应具体位置。对于超长任务，也可以先让模型列出找到的关键证据，再继续给出判断。

图片与视频理解：将界面和视觉资料纳入分析

我们会把 MiniMax M3 的视觉能力用于需要结合画面理解的工作，例如检查网页截图与实现是否一致、分析图表内容，或根据操作视频整理流程。API Hop和MiniMax 官方 API 一样提供图片与视频输入，其中图片使用 image_url 内容块，视频使用 video_url 内容块。

我们建议在输入时明确你的要求：检查界面就指出需要关注的区域，分析图表就说明要核对的指标，处理视频就限定时间段和需要识别的事件。这样更方便把模型输出与原始材料对应起来，继续修改代码或补充说明。

工具协作：根据中间结果继续完成多步骤任务

MiniMax M3 支持工具调用，并能在多轮工具交互之间继续推理。应用提供检索、代码执行或文件处理工具后，模型可以根据返回结果决定下一步操作。官方工具教程还要求在后续轮次保留完整的模型响应，以维持任务信息的连续性。

在客户的反馈中，对 M3 的 Agent 使用体验存在分歧：有用户认可其执行能力，也有人报告复杂流程中出现混乱。我们因此建议从边界清楚的短流程开始，写明每一步的输入、预期结果和失败处理，再逐步增加任务长度。

长时间优化：围绕可验证目标持续改进

MiniMax 官方展示过一个 FP8 矩阵乘法内核优化案例：M3 在约 24 小时内进行了 147 次基准提交和 1,959 次工具调用，通过反馈持续修改实现。

我们认为，这类能力值得用于具有明确目标的工作，例如代码性能优化、测试修复和实验复现。我们的建议是提前确定正确性检查、性能目标和停止条件；当结果长时间没有改善时，再检查任务描述、工具反馈或实现方向，避免只增加调用次数。

软件工程：SWE-bench Pro 59.0%，SWE-fficiency 得分 34.8

官方发布结果中，MiniMax M3 的 SWE-bench Pro 成绩为 59.0%，SWE-fficiency 得分为 34.8。我们把它们分别作为项目问题修复与代码性能优化的参考。

SWE-fficiency 关注保持功能正确前提下的加速效果，其指标涉及模型优化与专家优化的相对表现。我们会将 34.8 保留为该评测得分，避免将其误读为实际项目提速 34.8%。对于性能优化任务，我们建议同时检查运行时间、资源占用和测试结果。

终端执行：Terminal-Bench 2.1 达到 66.0%

MiniMax 官方公布的 M3 成绩为 66.0%。该测试使用 Terminus 2，单任务超时为 2 小时，最大输出预算为 128K Token。这些是评测设置，可以帮助我们理解分数对应的执行条件。

我们更关注模型能否在命令执行后读懂反馈，并继续修正。实际评估时，我们建议选取需要安装依赖、运行测试和处理报错的任务，同时保留失败步骤的日志，检查任务最终是否完成。

工具与检索：MCP Atlas 74.2%，BrowseComp 约 83.5%

官方报告中，MiniMax M3 的 MCP Atlas 成绩为 74.2%，BrowseComp 约为 83.5%。我们将这两项结果作为工具协作与复杂检索能力的参考。

对于需要搜索多份资料、核对条件再输出结论的流程，我们建议把“找到相关内容”和“正确回答问题”分别检查。例如，要求模型保留来源链接、说明证据对应的条件，并标记仍未解决的问题。我们会优先观察工具返回的信息是否真正支撑了最终答案。

多模态理解：OmniDocBench 91.6，MMMU-Pro 78.1%

官方完整评测表中，MiniMax M3 的 OmniDocBench 得分为 91.6，采用 v1.5 数据集；MMMU-Pro 成绩为 78.1%。我们认为，这两项结果适合分别观察文档解析和多学科视觉理解能力。

OmniDocBench 的评估包含文字、表格和公式等文档元素。我们会优先用带复杂排版、嵌套表格或公式的资料测试 M3，同时检查提取内容与页面位置是否对应。对于需要进一步推理的问题，我们建议继续核对推理所使用的数据，而不仅检查文字是否识别完整。

独立评测与响应速度：综合指数 29，输出约 100 Token/秒

Artificial Analysis 的 MiniMax M3 思考版本在 Intelligence Index v4.3.2 中得到 29 分；基于 MiniMax API 的输出速度约为每秒 100.4 Token，首个 Token 时间约为 2.65 秒。

对比 MiniMax M2.7：终端与工具任务的提升更明显

官方发布表中，MiniMax M2.7 与 M3 的 Terminal-Bench 2.1 成绩分别为 51.1% 和 66.0%，MCP Atlas 分别为 49.4% 和 74.2%。

对于已经使用 M2.7 准备升级到M3的团队，我们建议优先拿多轮工具调用、代码修复和长会话任务做替换评估。对于现有流程已经能够稳定完成的短任务，我们会继续比较回复质量、耗时和调用成本，判断升级带来的实际收益。

对比 Claude Opus 4.7：检索成绩较高，软件工程仍有差距

同一发布表中，M3 与 Claude Opus 4.7 的 BrowseComp 成绩约为 83.5% 和 79.3%；SWE-bench Pro 则为 59.0% 和 64.3%。我们据此认为，M3 的检索表现值得关注，但软件工程能力仍需要按具体任务比较。

我们建议将资料查找、跨来源核对和项目修复分别测试。若工作主要依赖检索，可以重点评估 M3；若需要在复杂代码库中一次完成较完整的修改，我们会把 Opus 4.7 保留为对照，并观察通过率与后续返工量。

对比 GPT-5.5：代码修复成绩接近，终端执行差距更大

在 MiniMax 的发布表中，M3 与 GPT-5.5 的 SWE-bench Pro 成绩分别为 59.0% 和 58.6%；Terminal-Bench 2.1 则为 66.0% 和 78.2%。其中 GPT-5.5 的终端成绩引用自该基准官方榜单，测试环境未与 M3 完全统一。 MiniMax M3 官方发布与评测说明

我们会将前一组结果理解为该评测中的接近表现，0.4 个百分点不足以单独支持明显领先的判断。对于需要连续执行命令、调试环境和完成交付的任务，我们建议进一步比较最终完成率，避免只根据代码修复分数选择模型。

对比 GLM-5.2：公开工程实验呈现速度与完整交付的取舍

Brandon Huey 在 2026 年 6 月 19 日发表的 Thinkwright 实验中，使用 60 个计分任务，每个模型运行三次。实验采用 Fireworks priority 服务，并在客户端将思考设置为关闭。结果如下。 Thinkwright 一手工程实验

我们将这项结果理解为该实验中的完成率与等待时间取舍：M3 更快，GLM-5.2 的完整通过率更高。作者记录的较大差距集中在从零构建任务，包括包结构和接口行为。我们据此建议优先让 M3 承担边界明确的修改任务，并对新项目交付补充运行入口、目录结构和边界条件检查。

按需计费与模型成本优化

按当前 API Hop 单价和实际用量计费，按需充值。

统一 AI模型 与数据 API，一站式多模型接入

一个密钥多个AI模型和数据模型，节省对接成本，一键切换，业务需要的场景必然是AI+数据

调用记录与应用权限控制，每一次调用明明白白

每一笔调用记录都可以在后台查到，可以设置多个密钥对应不同的应用

按任务验收模型输出

通过 API Hop 使用文档列出的模型 ID 与支持参数。按自己的验收标准评估输出，投入生产前核对用量记录与响应元数据；模型名称或演示样例不保证每次结果。

准备账户并进行在线测试

登录并确认余额，创建一个 API 密钥。

在 Playground 中体验

可以在 Playground 中体验模型的能力，确定最佳的模型使用方案。

将 MiniMax M3 集成到你的业务中

根据我们提供的开发文档，将 MiniMax M3 集成到业务中。

后续的模型升级

升级前先确认 API Key 的模型列表已返回新型号的准确 ID。仅在新旧模型支持相同接口和请求字段时更换 model，并验证返回格式、流式行为、输出上限与费用后再切换生产流量。涉及异步图片或视频任务时，还应验证任务提交、状态查询与结果获取流程。