MiniMax M2.7 API 接入指南

先说结论:两个值,一个大小写陷阱

base_url 填 https://api.kkaiapi.com/v1,model 填 MiniMax-M2.7,请求是标准的 /v1/chat/completions 格式。这里唯一的坑是大小写:这个 ID 是 MiniMax-M2.7,大写开头,和目录里大多数全小写的 ID 不一样,写成 minimax-m2.7 会直接返回模型不存在。接入前对照 /v1/models 的返回列表核实一次拼写,比凭记忆手打更保险。

curl https://api.kkaiapi.com/v1/chat/completions \
  -H "Authorization: Bearer sk-你的kkaiapi密钥" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMax-M2.7",
    "messages": [{"role": "user", "content": "规划给一个 REST 接口加分页的步骤,再写出改动"}]
  }'

MiniMax M2.7 到底是什么

MiniMax 在 2026 年 3 月 18 日发布了 M2.7,定位是 Agent 工作流、软件工程和办公任务。架构上是稀疏 MoE,报道给出的规模大约是 2300 亿总参数、每个 token 激活约 100 亿,这个小激活参数的设计正是它推理成本低的原因,官方定价也体现了这一点。 发布时最引人注意的说法是"自我进化":MiniMax 宣称 M2.7 是第一个参与了自己开发过程的模型,内部版本在训练它的强化学习流程里自主跑了上百轮优化。这是一个很吸睛的说法,同时也是厂商自己的说法,当成定位宣传看待,不是可验证的规格参数。 权重是公开的:今年 4 月的报道显示模型以 Modified-MIT 协议开源在 Hugging Face 上,但有一条协议细节值得注意——协议里的商用条款要求获得 MiniMax 的书面授权,个人和研究用途宽松,商用自部署是需要单独走授权流程的事,不是下载了就能直接商用。

Python 与 JavaScript 快速接入

两个官方 OpenAI SDK 都支持自定义 base_url,model 字段原样传字符串。不需要 MiniMax 专属的客户端,聊天补全、流式返回、标准的 tools 数组都能直接用。 把 Key 放进环境变量,model ID(连大小写)固定在一个配置常量里,这个字符串只在一个地方出现,以后改起来不容易漏改。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["KKAIAPI_KEY"],
    base_url="https://api.kkaiapi.com/v1",
)

resp = client.chat.completions.create(
    model="MiniMax-M2.7",
    messages=[
        {"role": "system", "content": "你是一个谨慎的软件工程师。"},
        {"role": "user", "content": "审查这段函数的边界情况并给出修复方案:..."},
    ],
    max_tokens=4000,
)
print(resp.choices[0].message.content)
print(resp.usage)

Agent 与编程能力,附来源说明

实操上的判断是:M2.7 的核心卖点是效率——用 100 亿激活参数的小架构,在多步 Agent 任务上做出有竞争力的表现,价格是同代里较低的一档。跑成百上千步的循环特别在意这个比值,自己的用量日志一个下午就能把这个比值在自己的任务上验证清楚。

• Agent 编程:官方发布报告了 SWE-bench Pro 56.2 分、Terminal-Bench 2.0 57.0 分、SWE-bench Multilingual 76.5 分,这几个基准 M2 系列一直是开源模型里比较靠前的选手
• Agent 浏览与工具调用:官方报告 BrowseComp 77.8 分,发布材料强调的是多步循环——查日志、分析代码、改文件、调工具、迭代
• 办公与文档类工作:发布定位把文档和办公任务生成放在和编程同等重要的位置,如果你的流水线产出的是报告而不是代码,这一点值得留意
• 以上都是厂商自己在发布时给出的成绩,独立榜单上 M2.7 在开源 Agent 阵营里属于有竞争力但不是断层领先,具体到自己的任务上还是要自己跑一遍

上下文口径:目录数字和厂商文档不一致

这里要说清一个不一致的地方,因为直接关系到怎么做预算。kkaiapi 目录里 MiniMax-M2.7 的上下文标注是 100 万 token。但 MiniMax 自己的模型文档描述的上下文规模在 20 万 token 量级(具体数字 196608)。这两个数字对不上,本文不打算假装它们一致。 稳妥的工程做法是先按厂商给出的 20 万这个数字做预算,等哪天真的需要更长上下文时,自己发一条明显超长的请求,看截断或拒绝到底发生在哪里,用一次实测代替两个不一致的数字之间的猜测。如果场景本来就用不到 20 万 token,这个分歧对你没有任何影响;如果会逼近这个量级,五分钟的测试比往任何一个方向假设都划算。

价格对照

按量计费,充多少花多少。

验证接入与排查首次调用

先查一次模型列表,直接复制返回结果里的精确拼写——对这个模型来说,大小写是最容易出错的地方。 其余排查思路和其他模型一致:401 多半是 Key 没导出到当前 shell;404 常见于 base_url 漏了 /v1;多步任务里 finish_reason 是 length,说明 max_tokens 对一个会先规划再输出的模型设小了,先调大留足余量,再评判输出质量。

curl -s https://api.kkaiapi.com/v1/models \
  -H "Authorization: Bearer sk-你的kkaiapi密钥" | grep -i minimax

常见问题