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-inferencing 配置决定，而不仅仅取决于模型架构。以下是我们 Gateway 返回的实际数值：

• 上下文窗口： 200,000 tokens（约 150,000 字）。这是 Gonka 网络中子网的配置。MiniMax 架构本身支持更长的上下文，但实际运行时的上限由主机端的推理设置决定。
• 最大输出： 单次响应 8,192 tokens。该数字是通过强制长文本生成的请求测试得出的，已触及上限（finish_reason: length）。目前，网络中所有模型的上限均为 8,192 tokens。这不是模型本身的限制，而是 vLLM 子网的配置。
• 主机 VRAM 要求： 每节点约 320 GB VRAM。这是大型 MoE 模型在 FP8 量化下的典型要求 — Kimi K2.6 同样需要这 320 GB 显存。在实践中，这意味着需要多张 H100/H200 级 GPU 合并为一个节点。

Gonka 网络中的推理价格不取决于模型选择，而是由网络参数决定：通过 JoinGonka Gateway，MiniMax M2.7 的费率与 Kimi K2.6 相同。这种统一价格是由于网络基础是基于计算成本的统一结算，而非特定厂商的定价。

Gonka 网络用户有两种旗舰模型可供选择，两者均可通过统一的、兼容 OpenAI 的 JoinGonka Gateway 接口访问。以下对比旨在帮助理解每种模型针对的任务配置文件，而不是评判“哪个更好”。

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

实践准则：对于涉及超长文档和大规模文本流式处理的任务，建议测试 MiniMax M2.7 — 该系列高效的 attention 机制历来针对此类场景进行了优化。对于具有复杂逻辑和长上下文的推理任务，建议与 Kimi K2.6 的回答进行比较。生产环境中的最佳策略是在代码中同时保留两种模型，并通过更改 model 参数轻松切换，而无需修改应用程序架构。

添加 MiniMax M2.7 并不是指简单的“文件上传到服务器”，而是通过 on-chain 投票进行的网络升级结果。该模型的支持已包含在 v0.2.13 协议版本中，该版本由提案 proposal #54 批准：该提案于 2026 年 5 月 21 日通过（约 63% 的赞成票），并在预定的区块高度激活。这就是网络采用任何重大变更所使用的 governance 机制，从资费定价到新模型上线均通过此方式进行。

对于去中心化网络而言，多模型架构是至关重要的一步。如果网络仅锁定单一是模型，在基础架构上是脆弱的：模型更新会导致迁移危机，而单一模型的任何故障都会使整个服务瘫痪。一个能够同时支持多个模型的网络可以平稳演进：新模型作为额外的“通道”添加，旧模型继续运行，而 GPU-хосты 可以选择为哪种模型提供算力。在技术上，每个模型运行在自己的网络分片中——相同的机制（DevShards）此前曾用于运行 Kimi K2.6。

早期阶段的一个细微差别是：“模型出现在网络列表中”到“模型对所有客户开放”之间可能会有一段时间差。起初，MiniMax M2.7 在 broker模式下的推理仅对特权密钥开放，普通请求会返回错误——这是正常的试运行阶段。到 2026 年 5 月底，公共访问权限开启，模型随之对所有 Gateway 客户开放。关于网络架构如何设计以及为何模型以此方式运行，请参阅关于 Gonka 网络架构的文章。

相同的 MiniMax M2.7 通过 OpenRouter 需要 $0.279/$1.20 每 1M token，而 JoinGonka 仅需 $0.003/$0.009。

最直接的方式是通过 JoinGonka API Gateway。由于 Gateway 提供与 OpenAI 兼容的 API，在更改 model 字段的值后，与 GPT、Claude 或 Kimi 一起使用的代码即可直接用于 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": "简要解释什么是线性注意力 (linear attention)"}
    ]
  }'

通过 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 注册，您将获得 1,000 万免费 Token 用于测试网络中的任何模型 — 这足以在您自己的任务上比较两种网络模型。

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

• Cursor：在 Custom Model 设置中指定 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 系列的高效注意力 (attention) 原本就是为了在不大幅增加成本的情况下保持长上下文而设计的。一次性发送整个文档，并让模型处理全部内容，而不是分块处理。

RAG 与知识库交互。 在检索增强 (retrieval-augmented) 的场景中，当数十个来自向量数据库的片段被混入上下文中时，模型处理多个异构文本片段的能力直接影响响应质量。这是长上下文模型的天然优势领域。

转录稿与日志处理。 通话转录稿、长对话支持、流式日志 —— 这些任务通常输入量大，但输出简短。在这里，8,192 个 Token 的输出限制不是问题：输入量很大，而输出则是摘要或提取出的关键事实。

何时选择其他模型。 目前，网络中的所有模型单次响应最高可提供 8,192 个 Token，因此如果您的应用程序需要单次请求超长回复（例如生成大型文档、大段代码），请在架构中考虑这一总量限制，并将生成过程拆分为多个部分。对于涉及复杂多步推理的任务，建议与 Kimi K2.6 的回答进行对比。通用建议：将您的真实请求集通过两个模型分别运行并对比结果 —— 注册时附赠的 1,000 万 Token 足以进行充分的比较测试。

从技术上讲，在模型之间切换只需更改 model 字段中的一行字符串。因此，基于 Gonka 网络构建的良好应用架构不会“永久锁定”某个模型，而是允许根据任务类型在 Kimi K2.6 和 MiniMax M2.7 之间路由请求 —— 低廉的推理成本 (inference) 使得这种路由在经济上非常划算。