MiniMax-M3.1-Flash VRAM requirements at Q4 and 1M context

MiniMax-M3.1-Flash needs about 423 GB in this Q4_K_M, 1,048,576 token, batch one scenario. The cache is 145 GB of that, so context length matters here.

Context length decides this one. MiniMax-M3.1-Flash has 428B total and 23B active parameters, with 128 experts per layer, 4 picked per token and the first 3 layers dense. At Q4_K_M, which the calculator prices at 0.56 bytes per parameter, the weights come to 240 GB. The cache at the full 1,048,576 tokens adds 145 GB, and a 38 GB runtime allowance brings the total to 423 GB. That makes the cache 34 percent of the total, a big slice at this context length. Models that keep fixed state in most layers can look very different. This one doesn't.

By TechCompare · Updated

Total VRAM required
423 GB
MiniMax-M3.1-Flash 428B (MoE) at Q4_K_M
Weights
240 GB
428B params
KV cache
145 GB
1024K tokens, FP16 KV

Calculator

Estimated VRAM required

423 GB

428B params at Q4_K_M, 1,048,576 token context, batch 1, inference.

Weights
240 GB
KV cache
145 GB
Overhead
38.5 GB

Estimate accuracy: Planning estimate. Rounded model counts, tensor formats, cache packing, and workspace can change actual allocation. Confirm the exact checkpoint and serving engine with a load test.

MiniMax-M3.1-Flash uses sparse attention in all 60 layers. Each stores full-resolution KV for 4 heads at head dim 128, plus a 128-value index key. The published checkpoint is mostly MXFP4 and is about 224 GB on disk. Vision processing and speculative decoding need extra memory.

Hardware that fits

Apple entries show installed unified memory separately from a model budget based on an 8 GB reserve. That budget is a planning heuristic, not a fixed hardware limit.

No single GPU in our catalog has enough memory. Multi-GPU or CPU offload required.

How this is calculated

MiniMax uses sparse attention in all 60 layers. Each query reads only the top 16 blocks of 128 tokens, which cuts compute. It doesn't cut memory, because a later query can pick any earlier block, so the keys and values of every token have to stay stored at full resolution. Each layer keeps 4 KV heads at head dimension 128, plus a 128 value index key per token that scores the blocks. In FP16 that's 138,240 bytes for every token in the context, or 145 GB at 1M tokens. The weights side is easier to check. The published checkpoint is mostly MXFP4 and takes about 224 GB on disk, and this page's Q4_K_M weight budget is 240 GB, so the Q4 factor lands close to the real files. Hugging Face's parameter counter shows about 220.5B instead of 428B because packed 4 bit weights store two values per byte. The model card's 428B is the real count, and it's the one used here. Lowering the context to 256K cuts the cache to 36 GB and the total to 304 GB. At 128K the total is 284 GB, and at 32K it's 269 GB.

Verdict

Plan the weights and the context together. By capacity alone the full 1M scenario needs 6 cards of 80 GB, while 256K needs 4 and 32K needs 4. Four 80 GB cards give 320 GB, which covers the 256K total on paper but not the 1M one. A Q8 cache, if your engine supports it for this layout, would bring the 1M total to 343 GB. Splitting a model across cards is an engine decision, so confirm which layouts your server supports. This estimate leaves out vision processing, speculative decoding, prefill workspace and uneven shards. Measure peak memory with your real prompts before you commit to hardware.

More MiniMax scenarios

Kimi K3.1 Pro at Q4_K_M
A 2.78T expert pool with 24 latent attention layers and fixed state in the other 69.
View details ➜
Mistral Large 4 at Q4_K_M
A 1T expert pool with 63 latent cache owners and 44 layers that also store an index key.
View details ➜
Muse Spark Open at Q4_K_M
Only 16 of its 62 layers grow with context, and the other 46 hold a 2,048 token window.
View details ➜

Frequently asked questions

How much VRAM does MiniMax-M3.1-Flash need at Q4?
This page estimates about 423 GB for one sequence at 1,048,576 tokens with an FP16 cache. That's 240 GB of weights, 145 GB of cache and 38 GB of runtime allowance. At 256K the same setup needs about 304 GB. Q4_K_M is a planning factor, so compare it with the size of the checkpoint you actually download.
Doesn't sparse attention shrink the KV cache?
It shrinks the work, not the storage. Each query reads only the top 16 blocks of 128 tokens, but which blocks matter depends on the query, so any past token might be needed later. The keys and values stay at full resolution for all 60 layers, and each layer also stores a 128 value index key per token. That's why the cache is 145 GB at 1M. Check whether your engine offers a smaller cache type for this model before relying on one.
Why does Hugging Face show 220.5B parameters when the card says 428B?
The published checkpoint is mostly MXFP4, and packed 4 bit weights store two values per byte. The parameter counter reads the stored U8 values, so it reports about half the real count. The model card's 428B is the true number of parameters, and the files take about 224 GB on disk. This page uses 428B, which gives a Q4 weight budget of 240 GB.
How does this estimate compare with the MiniMax-M3 page?
The older MiniMax-M3 estimate at 1M is 405 GB. This budget also counts the 128 value index key in every layer, and the older preset doesn't, so a small part of the difference comes from that. The calculator lists both at 428B with 23B active, so the weights don't explain it. See the MiniMax-M3 page for its own numbers.
How much memory do I save by cutting the context?
A lot, compared with hybrid models. The cache scales with context, so 128K gives a total of 284 GB and 32K gives 269 GB. The 240 GB of weights stays put, which sets the floor. If you only need short prompts, limit the server's context length so it doesn't reserve cache for 1M tokens.
Does running more than one request at a time change the total?
Yes, because every sequence has its own cache and the weights are shared. At batch 2 and the full context the estimate is 583 GB. Since the cache is so large here, concurrency and context length matter much more than they do on models with a small cache. Size for the number of long requests you expect to be open at the same moment.
What does this estimate leave out, and what about the license?
It leaves out vision processing, speculative decoding, prefill workspace, communication buffers and uneven splits across GPUs. The 38 GB allowance is a planning heuristic, not a cap. The weights ship under the minimax-community license, so read it before commercial use. MiniMax's model card is the place to check serving recommendations.