MiniMax M3’s 1M-token context window is the headline, and it has produced a lot of guidance about KV cache budgets on consumer cards. That guidance skips a step: before the cache is a problem, the weights are. M3 is a 427-billion-parameter model, and its Q4 weights are larger than the KV cache at full 1M context.
Quick answer: No consumer GPU runs MiniMax M3. Its weights are 427B — the community Q4_K_M GGUF is a 264GB download, eight times an RTX 5090’s 32GB. Even the most aggressive 1-bit quantization is 128GB. This is a four-to-eight card data-centre deployment, or an API call. If you want long-context work on hardware you own, buy a 24GB card and run a 32B-class model.
NVIDIA GeForce RTX 3090
24GB GDDR6X24GB used at ~$820 runs Qwen 3 32B at Q4 with real context headroom. That is the local long-context tier — M3 is eleven times past it.
Affiliate links — we may earn a commission at no extra cost to you. Amazon ships globally; Shopee SG covers Singapore & ASEAN.
Who this is for
You are building 1M-context RAG or an agentic loop that has to hold a whole codebase, a case file, or a long transcript, and you were trying to work out which GPU to buy for it. This page is the sizing check that comes before that decision. If your context needs are smaller, the Llama 70B guide covers the models that do fit on one card.
MiniMax M3 VRAM math — the weights come first
MiniMax M3’s own weight index on Hugging Face reports 427,040,140,160 parameters in BF16, so the unquantized weights are roughly 854GB. It is a sparse MoE, and the active-expert budget per token is a fraction of that — which is why it is fast for its size, and why it gets described as a model that “only” needs the routed experts in memory.
That description is wrong in the same way it is wrong for every MoE. Routing is decided per token at inference time, so the model cannot know in advance which experts it needs and all of them stay resident. Sparsity buys speed, not capacity.
These are the sizes the community GGUF builds actually ship at (unsloth/MiniMax-M3-GGUF), which is the number that has to fit before you think about context at all:
| Quantization | Weights | Smallest setup that holds it |
|---|---|---|
| Q8_0 | ~453GB | 6x 80GB |
| Q4_K_M | ~264GB | 4x 80GB |
| Q3_K_M | ~195GB | 3x 80GB |
| Q2_K_XL | ~143GB | 2x 80GB |
| IQ1_M | ~128GB | 2x 80GB, at severe quality cost |
VRAM capacity memory bandwidth Specs are manufacturer figures. Bar lengths are scaled independently per metric.
For reference, four RTX 5090s pool to 128GB — which does not hold the Q4 weights, and holds the 1-bit build with nothing left for context. There is no consumer configuration that runs this model usefully.
Then the KV cache, which is the second problem
The 1M context window does carry a real cost, and it is the part most long-context guidance gets right: KV cache scales linearly with context and gets no benefit from MoE sparsity. At Q4 KV quantization it runs roughly 128GB at a full 1M tokens.
Stacked on the weights, the total looks like this:
| Context | KV cache (Q4 KV) | Weights (Q4_K_M) | Total VRAM |
|---|---|---|---|
| 8K | ~1 GB | ~264 GB | ~265 GB |
| 32K | ~4 GB | ~264 GB | ~268 GB |
| 128K | ~16 GB | ~264 GB | ~280 GB |
| 512K | ~64 GB | ~264 GB | ~328 GB |
| 1M | ~128 GB | ~264 GB | ~392 GB |
Read the first row rather than the last one. At 8K context — no long-context ambition at all — M3 already needs 265GB. The cache never becomes the dominant term; even at the full million tokens it is half the size of the weights. Any sizing guide that starts from the cache has skipped the expensive part. For the general method, see the VRAM sizing guide.
Setups that actually run MiniMax M3
| Setup | VRAM | Q4_K_M weights fit? | Context ceiling |
|---|---|---|---|
| RTX 5090 | 32 GB | No — 8x short | — |
| Dual RTX 5090 | 64 GB | No | — |
| Dual RTX 3090 | 48 GB | No | — |
| 4x RTX 5090 | 128 GB | No — 1-bit only, no cache room | — |
| Cloud 2x H100 80GB | 160 GB | Only at Q2 | ~128K at Q2 |
| Cloud 4x H100 80GB | 320 GB | Yes | ~256K |
| Cloud 2x MI300X 192GB | 384 GB | Yes | ~900K — 8GB short of the full window |
| Cloud 5x H100 80GB | 400 GB | Yes | ~1M |
The single MI300X that gets recommended for this model is worth calling out: at 192GB it holds Q2 or Q3, not Q4. Full-quality M3 at a real context length is a two-card MI300X or four-card H100 job.
Try RunPod Cloud GPU→Which GPU should YOU buy?
- You want MiniMax M3 specifically: none. Use the hosted API, or rent multi-GPU capacity if you need custody of the weights. Ollama distributes M3 as
minimax-m3:cloudwith no local build, which is a reasonable signal about the intended deployment. - You want long context on hardware you own: a used RTX 3090 24GB at ~$820 runs Qwen 3 32B at Q4 (~20GB) — modest context on one card, and the honest local ceiling. Two of them pool to 48GB and give that model a genuinely long window.
- You want the most context a single card can hold: RTX 5090 32GB. The extra 8GB over a 3090 goes almost entirely to KV cache, which is what runs out first in RAG and agent loops.
- You need 1M context in production: rent. The break-even against buying is measured in years, and the hardware you would buy is not consumer hardware.
The contrarian take: 1M context is usually the wrong requirement
Nobody wants to hear this after budgeting for a big card: most workloads described as “1M context” are retrieval problems wearing a costume. A well-tuned 32B with good chunking and reranking answers full-codebase questions more accurately than a frontier model fed a million undifferentiated tokens, because attention over a million tokens is not the same as attention over the right ten thousand.
Rule of thumb: if better retrieval could get your working set under 128K without hurting accuracy, solve it there. The RAG GPU guide covers the retrieval-side sizing that makes this work.
Common MiniMax M3 mistakes
- Reading the active-expert budget as the VRAM requirement. Sparsity governs speed, not memory. All 427B parameters are resident, which is the difference between 32GB and 264GB. The same trap catches people with LongCat 2, where no consumer card runs full BF16 either.
- Sizing from the KV cache. The cache is real and it does scale linearly, but on this model it is the smaller of the two terms at every context length including 1M.
- Assuming a single MI300X 192GB covers it. That holds Q2 or Q3, not Q4_K_M at 264GB.
- Skipping KV quantization on the setups that do fit. M3 supports Q4/Q8 KV cache. FP16 KV doubles the cache footprint and halves usable context, which matters once you are paying by the hour.
Final verdict
| Need | Best pick | Price |
|---|---|---|
| MiniMax M3 for real work | Hosted API | per token |
| M3 with custody of weights | Rented 4x H100 or 2x MI300X | hourly |
| Long context you own, best value | RTX 3090 24GB (used) | ~$820 |
| Long context you own, most headroom | RTX 5090 32GB | ~$4,900 |
NVIDIA GeForce RTX 4090
24GB GDDR6X24GB new, for a 32B-class model at Q4 with room for a working context. The tier that exists — M3 is eleven times past it.
Affiliate links — we may earn a commission at no extra cost to you. Amazon ships globally; Shopee SG covers Singapore & ASEAN.
Frequently asked questions
How much VRAM does MiniMax M3 need?
Roughly 264GB for the Q4_K_M weights alone, before any context — MiniMax M3 is a 427-billion-parameter MoE, and although only a fraction of the experts activate per token, all of them stay resident because routing happens at inference time. KV cache adds on top of that: about 16GB at 128K context and about 128GB at the full 1M window. So a realistic full-quality deployment is around 280GB for 128K and around 392GB for 1M, which is four to six data-centre cards.
Can I run MiniMax M3 on an RTX 4090?
No, and not on an RTX 5090 either. The Q4_K_M weights are about 264GB against the 4090’s 24GB, so the gap is a factor of eleven rather than something offloading or a smaller quantization can close — even the most aggressive 1-bit community build is 128GB. A 4090 is a good card for a 32B-class model like Qwen 3 32B at roughly 20GB, which leaves real room for context.
What GPU do I need for MiniMax M3 at full 1M context?
About 392GB of VRAM at Q4_K_M — roughly 264GB of weights plus 128GB of KV cache — which means five or six 80GB cards. A pair of AMD MI300X 192GB comes to 384GB, so it lands just short of the full window at around 900K context. A single MI300X is not enough at full quality; it holds a Q2 or Q3 build instead. For almost every team the honest answer is to rent this by the hour, since the hardware only breaks even at very high sustained utilization.
Is MiniMax M3 worth running locally?
Local is not really on the table: the smallest usable build is well past any consumer or workstation configuration, and Ollama distributes the model as a cloud entry with no local weights. The realistic choice is between the hosted API and renting multi-GPU capacity when you need custody of the weights. If what you actually want is long context on your own hardware, a 32B-class model on a 24GB card is the tier that exists.
Should I quantize the KV cache for MiniMax M3?
Yes — past about 32K context, Q4 or Q8 KV cache quantization is essentially mandatory. FP16 KV cache doubles cache memory and roughly halves your usable context. vLLM and llama.cpp both support KV quantization with minimal quality loss on MoE architectures like M3. On rented hardware this translates directly into cost, since it decides how many cards a given context length needs.
The 1M context window is not what makes MiniMax M3 expensive to run. 427 billion resident parameters are, and they cost more than the cache at every context length including the full million.