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

MiniMax M2.7 是一款大型语言模型（LLM），由总部位于上海的 MiniMax 公司开发。MiniMax 由 Yan Junjie（曾就职于商汤科技）领导的研究团队于 2021 年创立，并迅速成为中国领先的 AI 实验室之一。该公司获得了阿里巴巴、腾讯和红杉资本的投资——这与支持包括月之暗面（Kimi K2.6 的开发者）在内的其他“中国 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 推理配置决定，而不仅仅是模型的架构。以下是我们的 Gateway 返回的实际值：

• 上下文窗口： 131,072 个 token（大约 100,000 个单词）。这是 Gonka 网络中子网的配置。MiniMax 架构本身支持更长的上下文，但任何时候的实际上限都由主机上的推理设置决定。
• 最大输出： 单次响应 4,096 个 token。这个数字是通过强制长生成达到上限的请求经验性测量的（finish_reason: length）。相比之下，Qwen3-235B 的上限是 8,192，Kimi K2.6 是 3,072 个 token。这并非模型本身的限制，而是 vLLM 子网的配置。
• 主机显存要求： 每个节点约 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% 的赞成票）并在指定区块高度激活。这与网络采纳任何重大变更（从费率到新模型）的治理机制相同。

多模型对于去中心化网络是根本性的一步。绑定单一模型的网络 inherently 脆弱：新模型版本的发布会演变为迁移危机，而单一模型的任何故障都会导致整个服务崩溃。能够同时承载多个模型的网络可以平稳演进：新模型作为额外的“车道”被添加，旧模型继续运行，而 GPU 主机可以选择服务什么。从技术上讲，每个模型都驻留在其自己的网络分片中——此机制（DevShards）此前曾用于启动 Kimi K2.6。

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

最直接的方式是通过 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 之间路由请求——廉价的推理使这种路由在经济上具有优势。