MiniMax M3.1 Flash Requirements

MiniMax M3.1 Flash is a multimodal MoE model from MiniMax with 428B total and about 23B active parameters. At 4-bit (NVFP4) the weights are about 250GB, and you should plan for roughly 260-300GB of memory including the KV cache. It will not run on a single 24GB or 32GB GPU or on a 64GB Mac. The realistic floor is a Mac Studio (M3 Ultra) with 512GB of unified memory or a server with four 96GB-class GPUs. If you do not need to run it locally, the official API is cheap at $0.15 per 1M input tokens and $0.60 per 1M output tokens, which is enough for personal trials.

MiniMax M3.1 Flash launched as a hosted service on October 19, 2026, and its weights were published on October 23 on Hugging Face (MiniMaxAI/MiniMax-M3.1-Flash) and ModelScope, with day-0 vLLM support. It had been teased under the codename "Space Bunny". This article works out the requirements from the published file sizes and official figures, and labels anything MiniMax has not stated as our own estimate. Most benchmark numbers are vendor-reported (as of October 24, 2026).

If you want to check quickly whether your GPU or Mac can run it, our VRAM calculator (free, no sign-up) estimates the required VRAM from the model, quantization and context length you pick. MiniMax M3.1 Flash is available in its model list.

In the table, 252.4GB (repo) and 250.1GB (the NVFP4 checkpoint for vLLM) are official figures. BF16, FP8, 3-bit and 2-bit are our estimates derived from 428B parameters (BF16 = 2 bytes, FP8 = 1 byte, ~3.5 bits for 3-bit class, ~2.7 bits for 2-bit class). "Memory needed" adds KV cache and runtime headroom on top and is not an official number. MiniMax has not published requirements for consumer hardware.

With about 23B active parameters, per-token compute is closer to a 20B-class model. But the experts selected change with every token, so all 428B of weights must sit in memory. "23B active" describes speed, not memory: required memory stays at the 428B level.

The safetensors metadata on Hugging Face shows roughly 220B parameters, about half of the official 428B. This is most likely because the 4-bit (NVFP4) weights are stored packed two per 8-bit integer (U8), and the viewer counts the packed elements as parameters. The file size (about 252GB) is consistent with 428B parameters stored at around 4 bits (about 214GB, plus scales and layers kept at higher precision). Use 428B, not 220B, for memory estimates.

The same kind of mismatch shows up elsewhere; our DeepSeek V4.1 Flash requirements article covers a similar disagreement in total parameter counts. Always check the actual file sizes in the repository rather than trusting the model page's headline number.

M3.1 Flash was not squeezed to 4-bit after the fact. It was trained with quantization-aware training (QAT), so the model learns to work at low precision. According to the published details, the routed experts and the sparse-attention KV path were trained for NVFP4, shared experts for MXFP8, and the query path in FP8. Only the parts that tolerate low precision are 4-bit; the sensitive parts stay at 8-bit.

As a result, the NVFP4 checkpoint for vLLM is 250.1GB versus 451.5GB for the previous MiniMax M3 (MXFP8), a 44.6% reduction. Because the official release is already 4-bit, going smaller means relying on community GGUF builds. About 25 community quantizations are listed on Hugging Face, but their quality has not been well verified yet.

The KV cache matters most for long contexts. Officially, M3.1 Flash uses 34,560 bytes per token, 43.75% less than the 61,440 bytes of M3. Our calculation from those figures:

These figures are for a single request and scale with concurrency. The reported result of 76 concurrent 256K-token sequences on 4x B300 (versus 28 for M3) comes from both the compressed weights and the smaller KV cache. For a single user, 256K adds only about 9GB on top of the 250GB of weights, and even 1M adds about 35GB. Be aware that image and video inputs can inflate the token count quickly.

Unified-memory Macs can hold huge MoE models without a GPU memory wall. The 4-bit M3.1 Flash is about 250GB, so a 512GB Mac Studio (M3 Ultra) fits the weights, KV cache and OS with room to spare. A 256GB Mac is almost full with the 4-bit weights alone, leaving little for macOS and the KV cache, so a ~3-bit build (about 170-190GB) with a short context is the realistic choice. Macs with 128GB or less struggle even at 2-bit.

Note that the Mac tooling is not ready right after release. The officially recommended engines are SGLang, vLLM and TokenSpeed, mostly aimed at NVIDIA and AMD servers. Transformers, KTransformers and unsloth support is listed as in progress, and llama.cpp is not officially recommended. Running on Mac via MLX or GGUF means validating community quantizations yourself.

- 4x B300 (the configuration in the official report): 76 concurrent 256K sequences. Server-class, not something individuals buy
- 4x RTX PRO 6000 (96GB) = 384GB: fits 4-bit (about 250GB) with roughly 130GB left for KV cache. Workstation-class, and one of the few NVIDIA setups here within reach of individuals or small teams
- 8x H100 80GB = 640GB: a conventional server that can even hold FP8 (430GB+)
- 8x H200 = 1,128GB: for running BF16 (about 856GB)
- A single RTX 5090 (32GB) or 4090 (24GB): far too small. Even 8x 24GB = 192GB cannot hold the 4-bit weights

When combining multiple GPUs over PCIe, inter-GPU traffic is slow and MoE expert distribution can hurt throughput. Server GPUs with NVLink have an advantage at the same memory capacity. The fact that MiniMax also reports GB300, Rubin and AMD MI355X support reflects that data-center hardware is the main target.

When GPU memory is short, you can keep expert weights in system RAM and compute only the active ones on the GPU. This is what KTransformers-style engines do, and a workstation with 256-512GB of DDR5 plus one 24-48GB GPU is the imagined setup. However, KTransformers support for M3.1 Flash is still in progress, so it is not usable yet. Even once it works, speed is bound by RAM bandwidth and will be much slower than on server GPUs.

The official API costs $0.15 per 1M input tokens, $0.60 per 1M output tokens and $0.015 per 1M cached input tokens, with no long-context surcharge. Prices vary by provider: OpenRouter reportedly lists $0.10 and $0.50, and Together AI offers a serverless endpoint. For example, 100M input and 20M output tokens a month comes to $0.15 x 100 + $0.60 x 20 = $27.

One catch: M3.1 Flash cannot turn reasoning off. The chat template lets you choose an effort level of low, medium, high, xhigh or max, but if you leave it unset it defaults to max. Reasoning tokens are billed as output on the API, so even short questions can produce far more output than expected. Try low first and check the cost.

Once you account for hardware, power and operations, self-hosting will realistically never break even against API usage on the order of $27 a month. Running locally makes sense only when sensitive data cannot leave your network, when you process large volumes of tokens continuously, or when you want to inspect or modify the model.

M3.1 Flash is released under the MiniMax Community License. Commercial use is allowed, but you must show the attribution "Built with MiniMax M3". If annual revenue is US$20M or less, a one-time email notice is required; above US$20M, prior written authorization is required. It is not an OSI-approved open-source license, and differs sharply from DeepSeek V4.1 Flash, released around the same time under the MIT license. Read the full LICENSE on the distribution page before embedding it in a commercial product.

- vLLM: vllm serve MiniMaxAI/MiniMax-M3.1-Flash starts an OpenAI-compatible server; supported since day 0
- SGLang: use the Docker image lmsysorg/sglang:latest and start it with --shm-size 32g
- TokenSpeed: one of the officially recommended engines
- Docker Model Runner: docker model run hf.co/MiniMaxAI/MiniMax-M3.1-Flash
- Transformers, KTransformers, unsloth: integrations in progress
- llama.cpp: not officially recommended; community GGUFs are at your own risk

Recommended sampling is temperature 1.0 and top_p 0.95. The reasoning effort is set through the chat template. The 2.3GB DSpark draft head ships in the repository and can speed up decoding on engines that support it. For multi-GPU runs, match the engine's tensor-parallel setting to your GPU count.

The vendor-reported scores are self-reported and have seen little independent reproduction. Artificial Analysis reports a 93% hallucination rate on AA-Omniscience, a metric for how often a model answers incorrectly instead of admitting it does not know. A high number suggests it tends not to say "I don't know". For fact-sensitive uses, pair it with search or internal documents and verify the output.

Among large open-weight MoE models, M3.1 Flash has about half the weights of DeepSeek V4.1 Flash and a fraction of Kimi K3, putting it near the upper edge of what an individual can reach. See also our articles on DeepSeek V4.1 Flash requirements, self-hosting Kimi K3 open weights, and the older MiniMax M2.5. If you want something that runs on a single GPU, a small model like the one in Recursive Flint requirements is the practical alternative.

- Out of memory (OOM): lower the context length and concurrent requests, reduce --max-model-len, then add GPUs. The KV cache reaches about 35GB at 1M tokens
- Model fails to load: your vLLM or SGLang version may be too old; day-0 support is in the latest releases, so update first
- Shared memory errors in Docker: SGLang needs --shm-size 32g
- Slow or very long outputs: reasoning effort defaulted to max because it was unset; lower it to low or medium
- Quality drop: community 2-3 bit quantizations are poorly verified; compare against the official NVFP4
- Memory spikes with images or video: more input tokens mean a larger KV cache; reduce resolution or frame count