MiniMax M3: an open frontier model you can run yourself?

Clients with sensitive data keep asking me whether open models are finally good enough to run on their own hardware. MiniMax M3 is one of the most capable open-weight models of 2026: about 428 billion parameters, a context of one million tokens, and text, image and video as input. It's also big enough that 'run it yourself' needs a real plan. Here is what M3 is, what the numbers really say, what hosting it takes, and when I would use it.

Dominik Heinrich

November 7, 202611 min read

1. What M3 is

MiniMax released M3 on 1 June 2026, and the weights followed on Hugging Face right after. It's a native multimodal mixture-of-experts model: about 428 billion parameters in total, of which about 23 billion are active for each token, with text, image and video as input and text as output. MiniMax trained it on mixed modalities from the first step rather than bolting vision on later.

The headline feature is the context window of one million tokens. It rests on MiniMax Sparse Attention, which, according to MiniMax's technical report, cuts per-token compute at a one-million-token context to about one twentieth of its predecessor M2. M3 also supports three reasoning modes per request: always on, adaptive and off. That last one matters in practice, because you can trade depth for latency per call instead of per deployment.

2. Why mixture-of-experts changes the maths

In a dense model every parameter works on every token. In a mixture-of-experts model a router sends each token to a few specialised experts, so only about 23 of the 428 billion parameters do the work for any one token. That makes answers much faster and cheaper to compute than the total size suggests, which is why MoE has become the default design for large open models.

The catch is memory. All experts still have to sit in GPU memory, because the router can pick any of them for the next token. So you pay for memory like a 428-billion-parameter model and for compute like a much smaller one. For hosting that's the single most important fact: the GPU count is set by total parameters plus context, while the throughput you get from those GPUs is set by the active parameters.

Tip from practice

When you compare hosting options, size the GPUs for total parameters and estimate throughput from active parameters. Mixing the two up is the most common sizing mistake with MoE models.

What is Mixture of Experts?, IBM Technology (YouTube). Loads from YouTube only after you click.

3. Read the numbers carefully

MiniMax and the vLLM recipe list 59.0% on SWE-Bench Pro, 66.0% on Terminal-Bench 2.1 and 74.2% on MCP Atlas, all strong results for agentic coding and tool use. They are the vendor's own numbers, measured under the vendor's own setup. Artificial Analysis, which runs its own independent tests, gives M3 a score of 19 on its Intelligence Index, below average among open-weight models of its size class, while also noting that it's reasonably priced and quicker than average per task.

Both can be true at once. A model can be very good at agentic coding and tool calls and weaker at broad reasoning or knowledge questions. The only number that matters for your decision is the one from your own test set: 30 to 50 real tasks with expected results, run against M3 and against the hosted model you use today, measured on quality, latency and cost per task.

4. Open weights is not open source

The weights ship under the MiniMax Community License, not under MIT or Apache 2.0. Commercial use is possible, but it comes with conditions, so read the licence with your legal team before you build a product on it, and again before each major version, because licences change between releases.

Treat the licence as part of the artifact. Store the licence text next to the model files in your own registry, record which version you run and where, and make that information easy to find for audits. Also keep the model families apart: MiniMax publishes several models under the same brand, such as its separate H3 video model, and each comes with its own terms. 'We use MiniMax' is not specific enough for a compliance review; 'we run MiniMax-M3, this revision, under this licence, for these use cases' is.

5. What it takes to host it

At BF16 the weights alone are roughly 860 GB; at 8-bit, roughly 430 GB. The KV cache for long contexts comes on top, and at hundreds of thousands of tokens it isn't small, even with sparse attention. The vLLM recipe's default configuration is a single node with 8× H200 GPUs, tensor parallelism and BF16. On AMD, BF16 also needs eight GPUs, while the MXFP8 variant runs from four. MiniMax publishes an MXFP8 build, and the recipe lists NVFP4 and MXFP4 variants for newer hardware.

Realistically, that's a dedicated GPU node in your cloud region or data center, not a workstation and not a shared cluster that also runs your web apps. Use the calculator below to see how precision changes the memory bill, and price a reserved GPU node against what you spend on hosted API calls today. For many teams, the break-even only arrives at high, steady volume or when the data simply can't leave.

bash

# vLLM recipe default: one node, 8x H200, tensor parallel, BF16
vllm serve MiniMaxAI/MiniMax-M3 \
  --block-size 128 \
  --max-model-len 65536 \
  --tensor-parallel-size 8 \
  --tool-call-parser minimax_m3 \
  --enable-auto-tool-choice \
  --reasoning-parser minimax_m3

Tip from practice

M3 support wasn't in a stable vLLM release at launch; the recipe pins a dedicated container image. Check the recipe before you pin versions in production.

Interactive

What does a mixture-of-experts model cost to host?

All experts must sit in GPU memory, but each token only runs through the active ones. Memory scales with total parameters, speed with active parameters.

Total parameters (B)428B

Active per token (B)23B

Precision

≈ 428 GB

weights in GPU memory

80 GB GPUs, minimum

23B

compute per token, like a dense model this size

Planning estimate: weights plus about 15% for KV cache and runtime. Real throughput depends on batch size, interconnect and the serving engine.

All calculators and checklists

6. Run it on Kubernetes like a service

Put the model on a dedicated GPU node pool with a taint, so only inference pods land there, and use the NVIDIA GPU Operator or your cloud's GPU node images to keep drivers consistent. On AKS, a GPU node pool with the right VM size gives you the same building block. Cache the weights in object storage or a pre-filled persistent volume close to the cluster, because pulling hundreds of gigabytes from the internet on every restart turns scaling and recovery into an outage.

Expose vLLM's OpenAI-compatible API only inside your network, behind your gateway and single sign-on, never directly on the internet. Scale on queue length and time to first token rather than CPU, and alert on GPU memory, error rates and token throughput. Long-context requests deserve their own limits, so one user pasting a whole codebase can't starve everyone else.

yaml

# Inference pod on a tainted 8-GPU node, weights from a pre-filled volume
spec:
  tolerations:
    - key: nvidia.com/gpu
      operator: Exists
      effect: NoSchedule
  containers:
    - name: vllm
      image: vllm/vllm-openai:minimax-m3
      args: ["--model", "/models/MiniMax-M3", "--tensor-parallel-size", "8",
             "--block-size", "128", "--max-model-len", "65536"]
      resources:
        limits:
          nvidia.com/gpu: 8
      volumeMounts:
        - { name: weights, mountPath: /models }
        - { name: shm, mountPath: /dev/shm }
  volumes:
    - name: weights
      persistentVolumeClaim: { claimName: minimax-m3-weights }
    - name: shm
      emptyDir: { medium: Memory, sizeLimit: 64Gi }

Tip from practice

Pre-pull the image and pre-fill the weights volume before you need them. A cold start that downloads 800 GB is not autoscaling, it's an outage.

Architecture for self-hosting an open mixture-of-experts model on Kubernetes: a dedicated GPU node pool runs vLLM with tensor and expert parallelism, weights are cached from object storage, an internal OpenAI-compatible API sits behind a gateway with single sign-on, the deployment autoscales on queue length, and monitoring tracks GPU memory, latency and errors. (AWS) — Self-hosting an open MoE model: dedicated GPU nodes, cached weights, an internal API behind your gateway, scaling on queue length.

7. Operate it like a product, not an experiment

A self-hosted model is a service with users, so it needs what every service needs: an owner, a version plan, monitoring and a way back. Put a model gateway in front of it that also knows your hosted models, so applications call one endpoint and the gateway routes by data class, cost and quality. Then a model upgrade becomes a routing change you can roll back in seconds.

The Azure Well-Architected guidance for AI workloads and the AWS Generative AI Lens both stress the same operating basics: evaluate continuously, monitor quality and not just uptime, and plan capacity for the peaks. In practice that means your test set runs on every model or configuration change, a dashboard shows quality, latency and cost per task side by side for each model, and someone looks at it every week.

8. Where it fits

M3 shines where data must not leave your network, where long documents or whole codebases need to fit into a single context, and where agents work through your own tools and MCP servers. Run it next to a hosted frontier model behind your gateway, route by data class, and compare quality and cost on real work for a few weeks before you decide how much traffic it gets.

Keep an eye on the release pace. In October 2026 MiniMax followed up with M3.1-Flash: the same size class, sparse attention throughout the model, quantization-aware training and speculative decoding, aimed at better task performance and inference efficiency. Check the newest variant before you buy hardware. And for the hardest reasoning tasks on data that may leave your network, I would still start with a hosted frontier model and let the test set tell me when an open one has caught up.

Takeaway
M3 makes self-hosting a serious option for sensitive work, if you budget for the GPUs. Treat benchmarks as a starting point, check the licence and let your own test set decide.

Real projects behind this

Offline AI robot on an ESP32

Try it yourself

Want this in your company? Let's talk mail@dominikheinrich.ch

Sources and official guides

MiniMax M3: an open frontier model you can run yourself?

1. What M3 is

2. Why mixture-of-experts changes the maths

3. Read the numbers carefully

4. Open weights is not open source

5. What it takes to host it

What does a mixture-of-experts model cost to host?

6. Run it on Kubernetes like a service

7. Operate it like a product, not an experiment

8. Where it fits

Get in touch