MiniMax shipped M3.1 Flash as a genuinely different kind of checkpoint from its predecessor. MiniMax M3 released as BF16 weights that teams quantized to FP8 or INT4 on their own after the fact. M3.1 Flash is quantization-aware trained from the start: MiniMax trained the model to run natively in NVFP4 and MXFP8, so the 252.4GB checkpoint on Hugging Face is the reference precision, not a shrunk-down copy of something bigger. That one decision is why this deployment guide looks different from every other MoE sizing post: the usual "divide total params by bytes-per-param" shortcut doesn't hold here, and the official vLLM recipe splits into two genuinely different serve commands depending on whether you're running Blackwell or Hopper.
TL;DR: What It Takes to Deploy MiniMax M3.1 Flash
MiniMax M3.1 Flash (428B total, 23B active) ships as a 252.4GB natively quantized checkpoint, not a BF16 release you quantize yourself. It runs natively at TP4 with full 1M context on Blackwell, or at TP8 with context capped at 262K on Hopper.
- Checkpoint: 252.4GB across 48 safetensors shards plus a 2.3GB DSpark drafter, as listed on MiniMax's Hugging Face repository.
- Hardware split: Blackwell (B200/B300/GB200/GB300) runs native NVFP4 at TP4 with the full 1,048,576-token context; Hopper (H100/H200) needs TP8, caps context at 262,144 tokens, and disables video input, per vLLM's official recipe.
- License: commercial use is free with attribution under $20M in trailing revenue; above that, MiniMax requires prior written authorization.
- Spheron: 4x B200 runs $21.00/hr spot as of 30 Oct 2026. Check B200 availability.
MiniMax M3.1 Flash Deployment: Architecture at 428B Total, 23B Active
MiniMax M3.1 Flash is a Mixture-of-Experts model with 428 billion total parameters and roughly 23 billion active per token, published on MiniMax's Hugging Face model card. The MoE layers hold 128 routed experts plus 1 shared expert, and the router selects 4 routed experts per token through sigmoid scoring with a routed scaling factor of 2.0. That is the same total-parameter count as M3, which is useful context for teams comparing the two: the architecture change is in precision and attention, not in raw scale. Readers coming from the earlier MiniMax M2.7 deployment guide should note that M2.7 is a much smaller 229B-parameter model, so the jump to M3.1 Flash's footprint is closer to the M3 generation than to M2.7.
The network has 60 total transformer layers: 3 dense feed-forward layers followed by 57 MoE layers. Attention uses grouped-query attention with 64 query heads, 4 KV heads, a head dimension of 128, and a hidden size of 6,144. All 60 layers run MiniMax Sparse Attention (MSA), which restricts each query to the top 16 blocks of 128 tokens rather than attending over the full sequence, the mechanism that keeps the model's 1M-token context window computationally viable.
The deployment-relevant change from M3 is speculative decoding. M3's draft mechanism was an EAGLE-like multi-token-prediction head; M3.1 Flash replaces it with a dedicated DSpark drafter, shipped as a separate 2.3GB checkpoint in the same release rather than bolted on by the community afterward. On Artificial Analysis's own benchmark, measured on 26 Oct 2026, M3.1 Flash scored an Intelligence Index of 43 with a $0.22 cost per task and roughly 119 tokens per second measured throughput, a 14-point jump over M3 and roughly in line with GLM-5.3 Flash (42) and DeepSeek V4.1 Flash (45).
VRAM Math: the 252GB NVFP4 Checkpoint vs FP8 and BF16
The quick way to size a 428B-parameter MoE model is to multiply by bytes-per-parameter: 2 bytes for BF16, 1 byte for FP8, 0.5 bytes for a 4-bit format. That shortcut gives you three numbers, none of which match what MiniMax actually ships, because the checkpoint mixes four different precisions across different parts of the network rather than running one uniform dtype everywhere.
| Precision path | Estimate method | Size |
|---|---|---|
| BF16 (hypothetical) | 428B params x 2 bytes | ~856GB |
| FP8 uniform (hypothetical) | 428B params x 1 byte | ~428GB |
| Native QAT checkpoint (shipped) | NVFP4 routed experts + sparse-attention KV, MXFP8 shared/dense, FP8 query path | 252.4GB across 48 shards |
| DSpark drafter (shipped, separate) | Speculative-decoding head | 2.3GB |
Neither hypothetical row is what you download. The 252.4GB figure sits well below a uniform-FP8 estimate because the bulk of the parameter count lives in the 128 routed experts, which run at 4-bit NVFP4, while the smaller dense and shared paths run at the heavier MXFP8 and FP8 precisions to preserve accuracy where sparsity would hurt most. This is also why a naive "it's 4-bit, so halve the FP8 number" guess (which would land near 214GB) overshoots how small the file actually is: the non-expert paths cost more bytes per parameter than a flat 4-bit assumption accounts for.
The practical consequence is that VRAM planning for M3.1 Flash has to start from the 252.4GB figure MiniMax actually published, not from a precision-times-parameters formula. DeepSeek V4-Pro's deployment guide walks through the same category of problem for a different model: a checkpoint that ships FP4 experts and FP8 elsewhere natively, where the published file size is the number that matters and the formula is only useful for sanity-checking it.
GPU Configurations That Fit: 4x B200/B300 (Native NVFP4) vs 8x H200 (Hopper Upcast)
MiniMax's official vLLM recipe doesn't treat all GPUs the same way, because Blackwell has hardware FP4 tensor cores and Hopper doesn't. On Blackwell (B200, B300, GB200, GB300), vLLM runs the NVFP4 weights as published, at tensor-parallel size 4, with the full 1,048,576-token context window available. On Hopper (H100, H200), vLLM has to upcast the experts to a precision the hardware can execute, which is why the same recipe calls for a full 8-GPU node at tensor-parallel size 8, caps context at 262,144 tokens, and disables video input for that path entirely.
| Configuration | Total VRAM | Parallelism | Max context | Video input |
|---|---|---|---|---|
| 4x B200 (192GB) | 768GB | TP4, native NVFP4 | 1,048,576 | Enabled |
| 4x B300 (288GB) | 1,152GB | TP4, native NVFP4 | 1,048,576 | Enabled |
| 8x H200 (141GB) | 1,128GB | TP8, upcast | 262,144 | Disabled |
The real-world payoff of the Blackwell path shows up at scale.
vLLM's own Blackwell command for this model is vllm serve MiniMaxAI/MiniMax-M3.1-Flash --tensor-parallel-size 4 --max-model-len 1048576. The Hopper equivalent is vllm serve MiniMaxAI/MiniMax-M3.1-Flash --tensor-parallel-size 8 --max-model-len 262144, with video input turned off for that configuration. Running MiniMax's official recipe as published, rather than guessing at flags, is worth the extra five minutes of reading before your first launch.
On pricing, Spheron sells H200 and B200 on-demand and spot by the minute, which covers both hardware paths the vLLM recipe actually targets. B300 currently shows only a published spot rate on Spheron's pricing page, with no on-demand tier listed, so teams that specifically need guaranteed on-demand B300 capacity should check live availability before planning around it. GB200 NVL72 and GB300 NVL72, the full-rack 72-GPU systems the recipe also lists under the Blackwell TP4 path, are reservation products on Spheron rather than instant self-serve, so a reader who wants one of those racks needs the reservation flow, not the on-demand dashboard. An 8x H200 node on Spheron runs $31.36/hr spot ($38.40/hr on-demand) as of 30 Oct 2026, against the hosted MiniMax API's flat $0.15 per million input tokens, $0.60 per million output tokens, and $0.015 per million cached input tokens regardless of context length used. Whether self-hosting beats the API comes down entirely to your sustained request volume and how much of that volume hits cache.
Pricing fluctuates based on GPU availability. Spheron rates above are live as of 30 Oct 2026; other providers reflect their most recent published rates and may have changed. Check current GPU pricing → for live rates.
One operational note from running inference on spot capacity in general: every 8-GPU spot type we used was reclaimed at least once on 14 Oct 2026, and on 16 Oct one B200 region stopped five of our spot VMs in a single day. If you're serving M3.1 Flash on spot rather than on-demand, keep at least two copies of the deployment on separate nodes or regions with automatic recovery configured, rather than treating a single spot node as production capacity.
Licensing: What MiniMax's Community License Requires at Scale
MiniMax M3.1 Flash ships under the MiniMax Community License, which is free for commercial use but carries a revenue-gated authorization requirement. Every deployment needs attribution. Below $20 million in trailing annual revenue, a one-time notice email to MiniMax is sufficient to stay compliant. Above that threshold, the license requires prior written authorization from MiniMax before you deploy.
That $20 million line is worth checking against your organization's actual numbers before a production launch rather than after, since it determines whether legal needs to open a conversation with MiniMax or just send a notice. If you also need video generation rather than M3.1 Flash's text-and-reasoning focus, MiniMax H3's deployment guide covers a sibling release with its own, more restrictive territory-based license, so don't assume M3.1 Flash's terms carry over.
Teams sizing a 428B MoE deployment against this quantization math are usually also comparing node options across H200 and B200. Spheron bills both on-demand and spot by the minute, with no long-term contract, and multi-node clusters up to 512+ GPUs with InfiniBand available on request if concurrency outgrows a single node.
Quick Setup Guide
Decide upfront whether you're deploying on Blackwell (B200/B300/GB200/GB300) or Hopper (H100/H200), since the vLLM recipe branches hard on this. Also confirm your organization's trailing annual revenue against the MiniMax Community License's $20 million threshold before provisioning anything.
The checkpoint is 252.4GB across 48 safetensors shards plus a 2.3GB DSpark drafter. 4x B200 (768GB) or 4x B300 (1,152GB) fit it natively at TP4 with room for the full 1M-token context. 8x H200 (1,128GB) fits it at TP8 with context capped at 262144.
Select your GPU configuration in app.spheron.ai: 4x B200 or B300 for the Blackwell path, 8x H200 for the Hopper path. SSH into the instance using the connection guide at https://docs.spheron.ai/connecting/ssh-connection.
Install the vLLM version named in MiniMax's official recipe at recipes.vllm.ai. Download MiniMaxAI/MiniMax-M3.1-Flash from Hugging Face with huggingface-cli and HF_TOKEN set, including the DSpark drafter shards if you plan to enable speculative decoding.
On Blackwell: vllm serve MiniMaxAI/MiniMax-M3.1-Flash --tensor-parallel-size 4 --max-model-len 1048576. On Hopper: vllm serve MiniMaxAI/MiniMax-M3.1-Flash --tensor-parallel-size 8 --max-model-len 262144, with video input disabled per the recipe. Validate with a test completion before routing production traffic.
Frequently Asked Questions
The official checkpoint is 252.4GB across 48 safetensors shards, plus a separate 2.3GB DSpark speculative-decoding drafter, as published on MiniMax's Hugging Face repository. That is lower than a naive FP8 estimate (428B params x 1 byte = ~428GB) because the checkpoint is natively mixed-precision: NVFP4 for the 128 routed experts and the sparse-attention KV paths, MXFP8 for the shared and dense layers, and FP8 for the query path. A hypothetical BF16 release would run roughly 856GB (428B x 2 bytes).
The vLLM recipe splits by hardware generation. Blackwell GPUs (B200, B300, GB200, GB300) run the checkpoint natively at tensor-parallel size 4 with the full 1,048,576-token context, because they have hardware FP4 tensor cores. Hopper GPUs (H100, H200) lack native FP4 support, so the recipe upcasts the experts and requires a full 8-GPU node (tensor-parallel size 8), with context capped at 262,144 tokens and video input disabled.
It's open-weight under the MiniMax Community License, which permits commercial use with attribution. Organizations with trailing annual revenue above $20 million need prior written authorization from MiniMax before deploying it; organizations below that threshold only need to send MiniMax a one-time notice email. Read the license text yourself before a production launch, since the threshold and notice mechanics are the kind of detail legal teams want to verify directly.
Yes, that's the Hopper path in MiniMax's own vLLM recipe: tensor-parallel size 8 across all eight GPUs, with --max-model-len capped at 262144 and video input disabled for that configuration. An 8x H200 SXM5 node has 1,128GB of VRAM against a 252.4GB checkpoint, which leaves most of the headroom for KV cache rather than weights.
M3 shipped as a BF16 checkpoint that teams quantized to FP8 or INT4 themselves after the fact. M3.1 Flash ships as a quantization-aware-trained checkpoint: MiniMax trained the model to run natively in NVFP4 and MXFP8, so the released weights are the reference precision rather than a BF16 original with a community-applied quant layer bolted on. It also replaces M3's EAGLE-like speculative decoding with a dedicated DSpark drafter head shipped in the same release.
