MiniMax M3 GPU requirements: memory, configurations and serving

MiniMax M3 needs one 8-GPU server. Its MXFP8 weights are 443.75 GB and its BF16 weights 854.18 GB, and no single GPU or 4-GPU VM that QuantaCloud rents by the hour holds either. vLLM's recipe has verified it on 8-GPU H200, B200 and B300 servers, and the H200 server takes the MXFP8 build with the full context window. The weights are open on Hugging Face under MiniMax's own licence, which puts conditions on commercial use.

What MiniMax released#

MiniMax published M3 on Hugging Face in June 2026, in two precisions, and followed it with M3.1-Flash in October. These are MiniMax's figures and the sizes of the files:

Hugging Face counts 427,040,140,160 parameters in the M3 files. The config describes 60 layers, 57 of them with 128 experts each, of which a token uses 4 plus one shared expert. M3 takes text, images and video, and it has three thinking modes: enabled, adaptive and disabled.

M3 is a mixture-of-experts model, so size it on the 428B total. The 23B active parameters set how much work each token takes. They do not reduce memory, because every expert has to be loaded.

One detail is not settled across sources. MiniMax's card says 1M context, and the config allows 1,048,576 positions. vLLM's recipe notes a native context of 512K, with RoPE scaling to go past it, and Ollama's hosted tag lists 512K. I would plan for 512K and treat the second half as something to test.

The licence#

M3 is not under MIT or Apache. The grant in the MiniMax Community License covers the usual rights only "for non-commercial purposes". Commercial use appears only in a condition attached to that grant, which applies "If the Software (or any derivative works thereof) is used for any Commercial Use" and sets two requirements. So the text never grants commercial use in so many words: it assumes it and attaches requirements. The first is attribution: "you shall prominently display "Built with MiniMax M3" on a related website, user interface, blogpost, about page or product documentation." The second depends on revenue. If the products and services "generate more than 20 million US dollars" in yearly revenue, you need "a separate, prior written authorization from MiniMax". Below that, the licence asks only for a one-time notice by email to api@minimax.io.

The licence defines commercial use broadly. It includes offering products or services to third parties for a fee, commercial use of APIs built on the model, and deploying a fine-tuned or modified version for any commercial purpose. An appendix lists prohibited uses, among them supporting any military purpose. I found no territorial restriction in the text. M3.1-Flash carries the same licence with its own name in the attribution line. Given how the grant is worded, I would have MiniMax's answer in writing before a commercial launch. This is a summary and not legal advice, so read the file before you build a product on it.

Memory at each precision#

The file sizes match the parameter count. 427.04B parameters at 2 bytes are 854.1 GB, which is the BF16 repository, and at 1 byte they are 427.0 GB. The MXFP8 repository is 16.7 GB larger because the embeddings, the output layer and the vision encoder stay in BF16 and MXFP8 stores one scale for every 32 weights (our calculation). In GiB, the unit GPUs report, that is 795.51 GiB for BF16 and 413.27 GiB for MXFP8.

MiniMax ships no 4-bit build of M3. For 4 bits there are the community GGUF files below and the NVFP4 build that NVIDIA published for Blackwell GPUs. M3.1-Flash, MiniMax's newer model, ships with 4-bit experts and is 250.12 GB.

The cache is the part to watch at long context. By the formula in the KV cache guide, M3 stores 2 x 60 layers x 4 KV heads x 128 x 2 bytes = 122,880 bytes per token, which is 15 GiB at 131,072 tokens and 120 GiB at the full 1,048,576 (our calculation, 16-bit cache). Treat that as a floor. vLLM's recipe reports about 3.5 GiB per GPU left on an 8-GPU H200 server with the BF16 weights and estimates about 83,000 tokens in it, roughly three times the formula per token (our calculation). The recipe's advice is --kv-cache-dtype fp8, which it says gives about 1.5 times the cache pool.

Which configurations hold MiniMax M3#

The table sets the weights against the budget of each configuration, 92% of the memory the GPUs report in nvidia-smi, which is vLLM's default (our calculation):

On demand, nothing that the recipe supports holds M3. The 8x A100 SXM4 VM has the memory for the MXFP8 weights on size alone, but the recipe recommends Hopper or newer GPUs and does not list the A100, so I would not plan a deployment on it. The 4x RTX PRO 6000 and 2x H200 NVL configurations are too small.

The BF16 row shows why arithmetic on file sizes is only an upper bound. On paper the BF16 weights leave 237.8 GiB on an 8-GPU H200 server. vLLM's recipe calls that fit tight, reports about 3.5 GiB per GPU left and caps the context at 65,536 tokens. Use MXFP8 on H200, and keep BF16 for B200 and B300 servers.

So the practical answer is one 8-GPU server built to order: H200 for MXFP8, B200 or B300 for BF16 or for long contexts with many users. Send a capacity brief with the precision, the context length and the traffic you expect, and the configuration, lead time and terms come back in writing. Dedicated GPU servers describes the offer, and the H200, B200 and B300 pages describe the GPUs.

Serving MiniMax M3#

MiniMax's card lists six frameworks it recommends: SGLang, vLLM, Transformers, KTransformers, Unsloth and ATOM. vLLM's recipe gives 0.24.0 as the minimum version and points to a dedicated image, vllm/vllm-openai:minimax-m3. The M3 architecture is also registered in the stable 0.30.0 and 0.33.0 releases. This is the recipe's command for the MXFP8 build on eight GPUs:

vllm serve MiniMaxAI/MiniMax-M3-MXFP8 \
  --tensor-parallel-size 8 \
  --block-size 128 \
  --tool-call-parser minimax_m3 \
  --reasoning-parser minimax_m3 \
  --enable-auto-tool-choice

--block-size 128 is mandatory on every platform, because the sparse attention works in blocks of 128 tokens. On H200 the recipe adds its own flags and a pinned image for the MXFP8 kernels, so generate the command for your GPU from the recipe. Set --max-model-len to the longest request you really serve: a shorter window leaves more cache for concurrent users. The vLLM multi-GPU guide explains tensor parallelism, and SGLang is the first engine on MiniMax's list.

GGUF files exist, from the community and not from MiniMax. Unsloth and bartowski publish quantizations for llama.cpp, which merged M3 support, sparse attention included, on 2026-07-26. Unsloth's 4-bit file is 264.93 GB and its 8-bit file 453.61 GB. On size, the 4-bit file fits a 4x RTX PRO 6000 VM, whose budget of 351.8 GiB is well above the file's 246.73 GiB (our calculation). I have not run it, and llama-server runs 4 request slots by default, which suits a few users rather than a busy API. The llama.cpp guide covers splitting a GGUF across GPUs.

Ollama has no M3 download. Its minimax-m3 page lists a single cloud tag, which runs on Ollama's servers.

MiniMax M3.1-Flash#

M3.1-Flash is the newer model, on Hugging Face since October 2026. MiniMax describes the same scale, about 428B parameters with 23B active, with sparse attention in every layer, quantization-aware training and a DSpark draft head for speculative decoding. Because the routed experts are trained at 4 bits, the files are 250.12 GB plus a 2.30 GB draft head, 235.08 GiB in all.

That is small enough for a 4x RTX PRO 6000 VM on size, with 116.7 GiB left (our calculation), though vLLM's recipe does not list that card. It lists Blackwell data center GPUs with four-way tensor parallelism and a full 8-GPU H100 or H200 server, and it needs vLLM 0.33.0 or newer. If you are choosing between the two for a new deployment, M3.1-Flash asks for less memory than M3 at MXFP8, and the licence terms are the same.

To test it on a 4x RTX PRO 6000 VM, these are the RTX PRO 6000 configurations the catalog lists right now:

MiniMax M3 FAQ#

How many parameters does MiniMax M3 have?

About 428B in total and about 23B active per token, by MiniMax's model card. Hugging Face counts 427,040,140,160 in the weight files.

Is MiniMax M3 open source?

The weights are open to download, with no gate. The licence is the MiniMax Community License, not an open-source licence such as MIT. Its grant names only non-commercial purposes, and its conditions for commercial use are attribution and either a notice or, above 20 million US dollars of yearly revenue, written authorization.

Where is MiniMax M3 on Hugging Face?

In MiniMaxAI/MiniMax-M3 for BF16 and MiniMaxAI/MiniMax-M3-MXFP8 for the 8-bit build. M3.1-Flash is in MiniMaxAI/MiniMax-M3.1-Flash.

Is there a MiniMax M3 GGUF?

Yes, from Unsloth and bartowski, between about 90 GB and 853 GB depending on the quantization. MiniMax itself publishes safetensors only.

Can I run MiniMax M3 locally?

Only with server hardware. The MXFP8 weights need 413.27 GiB of GPU memory before any cache, which is an 8-GPU H100 or H200 server. A 4-bit GGUF brings that to about 247 GiB, which still takes more than two 96 GB GPUs, so a 4x RTX PRO 6000 VM.

The rule I follow for MiniMax M3 is to pick the precision first and the server second: MXFP8 on an 8-GPU H200 server, BF16 only on B200 or B300. Check the licence against your revenue before either. For a model of this class that fits fewer GPUs, compare DeepSeek V4-Flash, and see the best open-source LLMs for the wider field.