MiniMax M2.7：Gonka 网络的第三个模型

MiniMax M2.7 是来上海的 MiniMax 公司开发的一个 LLM 大语言模型 (LLM)。MiniMax 由闫俊杰（曾任职于 SenseTime）领导的研究团队于 2021 年创立，并迅速成为中国领先的 AI 实验室之一。该公司获得了阿里巴巴、腾讯和弘杉投资的资金——这些战略投资者与包括开发 Kimi K2.6 的 Moonshot AI 在内的其他“中国 AI 巨头”背后是同一批投资者。

除了纯语言模型之外，MiniMax 还以其消费级产品而闻名：聊天助手 Talkie 和 Hailuo，以及行业内最引人注目的视频生成器之一。但对于 Gonka 网络而言，M 系列的文本模型——早期 abab 模型的继承者——尤为重要。

M 系列的主要架构特点是其高效的注意力机制。如果早期大型模型使用经典的二次注意力（计算成本与上下文长度的平方成正比），那么 MiniMax 是最早公开混合线性注意力机制的公司之一。这使得在不显著增加计算成本的情况下处理非常长的序列成为可能——这是该系列的历史名片。与 Qwen3-235B 和 Kimi K2.6 一样，该模型建立在 MoE (Mixture of Experts) 架构之上：名义上有数百亿参数，但每个查询只激活其中一小部分，这大大降低了推理的成本。

在 Gonka 网络中，该模型被识别为 MiniMaxAI/MiniMax-M2.7——正是这个字符串需要作为 API 请求中 model 字段的值。M2.7 版本是本文发布时 M 系列的最新迭代。

区分模型“开箱即用”的特性与它在特定网络中部署时的特性至关重要。当模型在去中心化的 Gonka 网络中运行时，其操作参数由 GPU 主机端的 vLLM 推理配置设定，而不仅仅是模型架构。以下是我们网关提供的实际值：

• 上下文窗口： 131,072 个 token（约 10 万字）。这是 Gonka 网络中的子网配置。MiniMax 架构本身支持更长的上下文，但在任何给定时刻，实际的上限由主机上的推理设置决定。
• 最大输出： 单次响应 4,096 个 token。这个数字是经过经验测量得出的——通过强制进行长生成并达到上限（finish_reason: length）的请求。相比之下，Qwen3-235B 的上限是 8,192，Kimi K2.6 是 3,072 个 token。这并非模型本身的限制，而是 vLLM 子网的配置。
• 主机 VRAM 要求： 每个节点约 320 GB VRAM。这是大型 MoE 模型在 FP8 量化中的典型要求——Qwen3-235B 和 Kimi K2.6 也需要同样的 320 GB。实际上，这意味着多个 H100/H200 级别的 GPU 组合成一个节点。

Gonka 网络中的推理成本不取决于模型的选择，而是由网络参数决定：通过 JoinGonka Gateway，MiniMax M2.7 以与 Qwen 和 Kimi 相同的费率提供。价格统一是因为网络的底层是基于计算工作成本的统一计算，而不是特定供应商的价格。

Gonka 网络的用户首次可以在三个旗舰模型中进行选择，所有这三个模型都可以通过统一的、兼容 OpenAI 的接口 JoinGonka Gateway 访问。下面的比较有助于理解“哪个更好”并非关键，而是每个模型针对哪类任务进行了优化。

关于 2026 年基准测试的一个重要说明：顶级开源模型在公开测试中的差距已缩小到个位数百分比，而且这种差异通常在基准测试本身的统计误差范围内。对于实际工作而言，重要的不是 MMLU 排名中的绝对位置，而是任务的性质：上下文长度、逻辑链的复杂性、所需的语言、工具调用的可用性。

实际指导：对于涉及超长文档和流式处理大量文本的任务，测试 MiniMax M2.7 是有意义的——其高效的注意力机制在历史上就是为这种场景优化的，能够在不急剧增加成本的情况下保持长上下文。对于通用的多语言工作和稳定的生产工具调用，Qwen3-235B 是一个经过验证的选择。对于涉及复杂多步推理的任务，可以与 Kimi K2.6 的答案进行比较。最佳的生产策略是，在代码中保留所有三个模型，并根据任务类型通过一个 model 参数在它们之间切换，而无需更改应用程序的架构。

MiniMax M2.7 的添加不是“将文件上传到服务器”，而是通过链上投票进行的网络升级的结果。模型支持包含在协议 v0.2.13 版本中，该版本由提案 #54 批准：该提案于 2026 年 5 月 21 日获得通过（约 63% 的赞成票），并在设定的区块高度激活。这是网络接受任何重大更改（从费率到新模型）的相同治理机制。

对于去中心化网络而言，多模型是具有里程碑意义的一步。绑定到单一模型的网络本质上是脆弱的：新模型版本的发布会演变为迁移危机，而单一模型的任何故障都会导致整个服务崩溃。能够同时容纳多个模型的网络可以平稳发展：新模型作为额外的“通道”添加，旧模型继续运行，GPU 主机可以选择提供哪种服务。从技术上讲，每个模型都存在于其自己的网络分片中——此机制（DevShards）以前用于启动 Kimi K2.6。

早期阶段的一个特殊细微差别是：“模型出现在网络列表中”与“模型对所有客户开放”之间可能存在滞后。MiniMax M2.7 在 broker 模式下，推断最初只对特权密钥可用，对于常规请求会返回错误——这是磨合的正常阶段。到 2026 年 5 月底，公共访问开放，模型对所有 Gateway 客户可用。有关网络如何工作以及模型为何以这种方式启动的更多信息，请参阅有关 Gonka 网络架构的文章。

通过 OpenRouter 使用同一 MiniMax M2.7 的价格是每 1M $0.279/$1.20，而 JoinGonka 的价格是 $0.001。

最直接的方式是通过 JoinGonka API Gateway。由于 Gateway 提供了兼容 OpenAI 的 API，所以与 GPT、Claude、Qwen 或 Kimi 配合使用的代码，在更改 model 字段的值后，即可与 MiniMax 配合使用。

通过 curl 的最小示例：

curl https://gate.joingonka.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMaxAI/MiniMax-M2.7",
    "messages": [
      {"role": "user", "content": "简要解释什么是线性注意力"}
    ]
  }'

使用 openai 库的 Python 请求相同：

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://gate.joingonka.ai/v1",
)

response = client.chat.completions.create(
    model="MiniMaxAI/MiniMax-M2.7",
    messages=[{"role": "user", "content": "你好，MiniMax"}],
)
print(response.choices[0].message.content)

流式传输（Server-Sent Events）——用于交互式界面，响应在生成时显示：

stream = client.chat.completions.create(
    model="MiniMaxAI/MiniMax-M2.7",
    messages=[{"role": "user", "content": "写一篇关于长上下文的短文"}],
    stream=True,
)
for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

注册 JoinGonka Gateway 后，您将获得 1000 万免费 token 来测试任何网络模型——这足以在您的任务上比较所有三个模型。

与开发工具的兼容性：所有与 OpenAI API 配合使用的工具，均可通过 Gateway 与 MiniMax 配合使用。只需更改 model 参数：

• Cursor：在自定义模型设置中，指定 MiniMaxAI/MiniMax-M2.7
• Claude Code、Cline、Continue.dev：配置中的模型名称
• LangChain、n8n：初始化客户端时的 model 参数

模型最新列表始终可在 GET /v1/models 终结点获取——从那里动态获取非常方便，这样您的应用程序 UI 就能自动显示最新的模型集。如果收到 429 too many concurrent requests，这对于网络早期增长阶段的新模型来说是正常现象：请在几秒后重试请求。

在一个网络中拥有三个模型非常有价值，因为可以针对不同的任务选择不同的工具，而无需更改提供商或集成代码。以下是一些适合开始测试 MiniMax M2.7 的场景。

长文档分析。 如果任务是总结合同、解析技术文档、处理大型法律或金融文本，M 系列的高效注意力机制在历史上就针对在不急剧增加成本的情况下保留长上下文进行了优化。在一次请求中传递整个文档，并要求模型一次性处理所有内容，而不是分块处理。

RAG 和知识库协作。 在检索增强型场景中，当数十个来自向量数据库的片段被纳入上下文时，模型保留许多不同文本片段的能力直接影响响应的质量。这是长上下文模型的自然优势领域。

处理文字记录和日志。 通话记录、长时间的支持对话、流式日志——这些任务的输入量很大，但响应通常很短。在这里，4,096 token 的输出上限并不会造成困扰：输入很多，输出则是摘要或提取的事实。

何时选择其他模型。 如果您的应用程序需要在一次请求中获得非常长的响应（大型生成的文档、大段代码），请记住 4,096 token 的输出上限——Qwen3-235B 的上限是其两倍（8,192）。如果生产环境中稳定的原生工具调用是关键，Qwen3-235B 已有更长的验证时间。对于涉及复杂多步推理的任务，可以与 Kimi K2.6 的答案进行比较。普遍的建议是：将您的真实查询集通过所有三个模型运行一遍并比较结果——注册时提供的 1000 万免费 token 足以进行全面的比较测试。

从技术上讲，在模型之间切换就是更改 model 字段中的一行代码。因此，Gonka 网络上设计良好的应用程序架构不会“永久选择一个模型”，而是允许根据任务类型在 Qwen、Kimi 和 MiniMax 之间路由请求——廉价的推理使得这种路由在经济上具有优势。