MiniMax M2.7: Gonka Network Model

MiniMax M2.7 is a large language model (LLM) from MiniMax, a company based in Shanghai. MiniMax was founded in 2021 by a team of researchers led by Yan Junjie (formerly of SenseTime) and quickly became one of China's leading AI laboratories. The company has attracted funding from Alibaba, Tencent, and HongShan — the same circle of strategic investors behind other "Chinese AI tigers," including Moonshot AI, the developer of Kimi K2.6.

Beyond pure language models, MiniMax is known for consumer products: chat assistants Talkie and Hailuo, as well as one of the most prominent video generators in the industry. But for the Gonka network, the M-series of text models — successors to earlier abab models — is particularly important.

The main architectural feature of the M-series is its focus on an efficient attention mechanism. While early large models used classic quadratic attention (computational cost grows proportionally to the square of context length), MiniMax was one of the first to release a hybrid linear attention mechanism. This allows for processing very long sequences without an explosive increase in computational cost — a historical hallmark of the lineup. Like Qwen3-235B and Kimi K2.6, the model is built on the MoE (Mixture of Experts) architecture: hundreds of billions of parameters "on paper," but only a small fraction of them are activated for each query, drastically reducing the cost of inference.

In the Gonka network, the model is identified as MiniMaxAI/MiniMax-M2.7 — this is the string you need to pass in the model field of your API request. Version M2.7 is the latest iteration of the M-series at the time of publication.

It is important to distinguish between the characteristics of the model "out-of-the-box" and the characteristics with which it is deployed in a specific network. When a model operates in the decentralized Gonka network, its operational parameters are defined by the vLLM-inference configuration on the GPU-host side, not just the model architecture. Here are the actual values returned by our Gateway:

• Context window: 200,000 tokens (about 150,000 words). This is the subnet configuration in the Gonka network. The MiniMax architecture itself supports a significantly longer context, but the practical ceiling at any given moment is determined by the inference settings on the hosts.
• Maximum output: 8,192 tokens per response. This figure was measured empirically — by a request with forced long generation that hit the ceiling (finish_reason: length). Currently, this ceiling is the same for all models in the network — up to 8,192 tokens. This is not a limit of the model itself, but the configuration of the vLLM-subnet.
• Host VRAM requirement: about 320 GB VRAM per node. This is a typical requirement for a large MoE model in FP8 quantization — the same 320 GB are needed for Kimi K2.6. In practice, this means several H100/H200 class GPUs combined into one node.

The price of inference in the Gonka network does not depend on the model choice and is determined by network parameters: via JoinGonka Gateway, MiniMax M2.7 is available at the same rate as Kimi K2.6. The unified price is a consequence of the fact that the network is based on a single calculation of costs for computing power, not a specific vendor's price list.

Gonka network users have a choice of two flagship models, both accessible via a unified OpenAI-compatible JoinGonka Gateway interface. The comparison below helps to understand not "which one is better," but for which task profile each is optimized.

An important caveat regarding benchmarks in 2026: the gap between top open-weights models in public tests has shrunk to single percentage points, and this difference is often within the statistical margin of error of the benchmarks themselves. For practical work, it is not the absolute place in the MMLU rating that matters, but the nature of the task: context length, complexity of logic chains, required language, and tool calling availability.

Practical guideline: for tasks with very long documents and streaming processing of large volumes of text, it makes sense to test MiniMax M2.7 — the efficient attention of its series is historically tailored to such scenarios. For reasoning tasks with complex logic and long context, you should compare responses with Kimi K2.6. The best strategy in production is to keep both models in the code and switch between them by a single model parameter without changing the application architecture.

Adding MiniMax M2.7 is not a "file upload to a server," but the result of a network upgrade conducted through on-chain voting. Support for the model was included in protocol release v0.2.13, approved by proposal #54: it was passed on May 21, 2026 (approximately 63% of votes in favor) and activated at a specified block height. This is the same governance mechanism through which the network adopts all significant changes — from pricing to new models.

Multimodality for a decentralized network is a fundamental step. A network tied to a single model is fundamentally fragile: the release of a new model version turns into a migration crisis, and any failure of the sole model crashes the entire service. A network capable of supporting multiple models simultaneously evolves smoothly: new models are added as additional "tracks," older ones continue to operate, and GPU hosts get a choice of what to serve. Technically, each model lives in its own network shard — the same mechanism (DevShards) was previously used to launch Kimi K2.6.

A separate nuance of the early stages: there may be a lag between "the model appeared in the network list" and "the model is open to all clients." Initially, MiniMax M2.7 inference in broker mode was available only to privileged keys and returned an error for regular requests — a normal shakedown phase. By the end of May 2026, public access opened, and the model became available to all Gateway clients. More details on how the network is structured and why models are launched this way can be found in the article about Gonka network architecture.

The same MiniMax M2.7 via OpenRouter is $0.279/$1.20 per 1M, versus $0.0047/$0.014 at JoinGonka.

The most direct path is via the JoinGonka API Gateway. Since the Gateway provides an OpenAI-compatible API, the same code that works with GPT, Claude, or Kimi will start working with MiniMax after changing the model field value.

A minimal example using 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": "Briefly explain what linear attention is"}
    ]
  }'

The same request in Python using the openai library:

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": "Hello, MiniMax"}],
)
print(response.choices[0].message.content)

Streaming (Server-Sent Events) for interactive interfaces where the response is displayed as it is generated:

stream = client.chat.completions.create(
    model="MiniMaxAI/MiniMax-M2.7",
    messages=[{"role": "user", "content": "Write a short essay about long context"}],
    stream=True,
)
for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

Upon registering with JoinGonka Gateway, you receive 1.5M free tokens to test any network models — this is enough to compare all three network models on your own tasks.

Compatibility with development tools: everything that works with the OpenAI API also works with MiniMax through the Gateway. Simply change the model parameter:

• Cursor: in the Custom Model settings, specify MiniMaxAI/MiniMax-M2.7
• Claude Code, Cline, Continue.dev: model name in the config
• LangChain, n8n: model parameter during client initialization

The up-to-date list of models is always available via the GET /v1/models endpoint — it is convenient to pull it dynamically so that your application's UI automatically displays the current set. If you receive 429 too many concurrent requests — this is a normal phase for a fresh model in the early growth stage of the network: retry the request after a few seconds.

Having three models in one network is valuable because you can select different tools for different tasks without changing providers or integration code. Here are scenarios where it makes sense to start testing with MiniMax M2.7.

Analysis of long documents. If the task is contract summarization, technical documentation analysis, or processing large legal or financial texts, the efficient M-series attention is historically optimized for maintaining long context without a sharp increase in cost. Pass the entire document in a single request and ask the model to work with the full volume at once, rather than in pieces.

RAG and working with knowledge bases. In retrieval-augmented scenarios where dozens of fragments from a vector database are mixed into the context, the model's ability to hold many heterogeneous pieces of text directly affects the quality of the answer. This is a natural niche for long-context models.

Processing transcripts and logs. Call transcriptions, long support dialogues, streaming logs — tasks where the input volume is large but the output is usually short. Here, an 8,192-token output limit is not a hindrance: you input a lot, and output a summary or extracted facts.

When to choose another model. Currently, all network models provide up to 8,192 tokens in a single response, so if your application requires a very long response in one request (a large generated document, a bulky piece of code) — factor this common limit into your architecture and break the generation into parts. For tasks with complex multi-step reasoning, compare the answers with Kimi K2.6. Universal advice: run the same set of your real requests through both models and compare the results — the 1.5M free tokens received upon registration are enough for the first comparative run.

Technically, switching between models is a change of one string in the model field. Therefore, a well-architected application on the Gonka network does not "choose a model once and for all," but allows routing requests between Kimi K2.6 and MiniMax M2.7 depending on the task type — cheap inference makes such routing economically profitable.