How to Run MiniMax M3 Locally: Hardware, Quants & Setup (2026)

Quick answer. MiniMax M3 is a 428B-parameter Mixture-of-Experts model with roughly 23B active per token, so the full weights do not fit in any single 24GB or 48GB GPU. Run it as a heavily quantized GGUF with the experts offloaded to system RAM, or serve the MXFP8/NVFP4 weights across a multi-GPU rig with vLLM.

MiniMax M3 is a frontier-scale open-weight model: 428B total parameters, about 23B active per token, native multimodality (text, image, video), and a context window up to 1M tokens built on MiniMax Sparse Attention (MSA). Those numbers make it powerful and awkward to self-host at the same time. This guide is the honest version: what actually fits on the hardware you own, which quant to pick, and which runtime (Ollama, vLLM, or LM Studio) matches your setup.

What are MiniMax M3's specs, and why do they matter for local hosting?

Two facts drive every hosting decision:

• 428B total parameters. Even at 4-bit that is roughly 214GB of weights, and at the official 8-bit MXFP8 quant it is well over 400GB. No consumer GPU holds that in VRAM.
• ~23B active per token (MoE). Only a small slice of the 256-expert network fires for any given token. That is the escape hatch: you can keep the dense/attention layers on the GPU and push the rarely-touched expert weights into ordinary system RAM.

The attention layers use MiniMax Sparse Attention rather than dense attention, which is what gives M3 its cheap long-context inference in the vendor's own serving stack. That detail matters later: most GGUF runtimes do not implement MSA yet and fall back to dense attention, so the 1M-context speed advantage largely belongs to vLLM/SGLang today.

For a full capability rundown, MiniMax's pricing, and the multimodal story, see the MiniMax M3 developer guide. If you are weighing it against the other big June-2026 open-weight release, the GLM-5.2 vs MiniMax M3 coding comparison covers benchmarks and cost head-to-head.

How much VRAM and RAM do you actually need?

Because M3 is a MoE, the number that matters is combined RAM + VRAM, not VRAM alone. The table below uses the sizes from the community dynamic GGUF builds (Unsloth). Treat them as approximate — quant sizes shift slightly between builds.

★ Community builders recommend the ~3-bit dynamic quant as the best size/quality balance for M3. The takeaway: the smallest genuinely usable copy of M3 needs on the order of 130–160GB of memory across your GPU(s) and system RAM. That is the floor you are designing around.

Which quant fits your rig?

Here is the honest mapping from hardware to what you can realistically load. "CPU offload" means the MoE expert tensors sit in system RAM while attention and the router run on the GPU.

Two practical notes on quant format once you move off pure GGUF: MXFP8 is MiniMax's official quant and the safe default for GPU serving. NVFP4 is the 4-bit format to reach for on Blackwell hardware (RTX 50-series, RTX 6000 Pro, B200) because those chips accelerate it natively. AWQ INT4 community builds exist too and behave like other AWQ models under vLLM. If you have the VRAM to hold the weights outright, prefer these formats over GGUF so you keep MSA and the sparse-attention long-context speedup.

Ollama vs vLLM vs LM Studio: which runtime should you use?

Short version: use llama.cpp or LM Studio if you are offloading experts to RAM on a workstation or a big-memory Mac. Use vLLM or SGLang if you have enough VRAM to hold the weights and you care about throughput and long context. Ollama is the fastest way to try M3, but for a model this size you will want the finer control llama.cpp gives you.

Step-by-step: run MiniMax M3 with llama.cpp and CPU offload

This is the path most people with one workstation GPU and plenty of RAM will take. First, pull one quant of the GGUF:

pip install -U huggingface_hub

huggingface-cli download unsloth/MiniMax-M3-GGUF \
  --include "UD-IQ3_XXS/*" \
  --local-dir MiniMax-M3-GGUF

Then serve it with the experts pinned to system RAM. The key flags are --n-gpu-layers (push as much as possible onto the GPU) and --n-cpu-moe (keep the MoE expert tensors on the CPU so a small GPU is not the bottleneck):

llama-server \
  -m MiniMax-M3-GGUF/UD-IQ3_XXS/*.gguf \
  --n-gpu-layers 99 \
  --n-cpu-moe 999 \
  --ctx-size 32768 \
  --threads 32 \
  --host 0.0.0.0 --port 8080

Tune --n-cpu-moe downward if you have spare VRAM (fewer experts on CPU = faster), and raise --threads to match your physical cores. Recommended sampling for M3 is temperature 1.0, top-p 0.95, top-k 40. Once it is up, it speaks the OpenAI-compatible API at http://localhost:8080/v1.

For Ollama, download a GGUF the same way, point a Modelfile at it, then:

ollama create minimax-m3 -f Modelfile
ollama run minimax-m3

For a multi-GPU rig with enough VRAM, skip GGUF entirely and serve the native weights with vLLM:

pip install -U vllm

vllm serve MiniMaxAI/MiniMax-M3 \
  --tensor-parallel-size 4 \
  --enable-expert-parallel \
  --max-model-len 262144 \
  --trust-remote-code

Match --tensor-parallel-size to your GPU count, and use the NVFP4 community repo instead of the base repo if you are on Blackwell and want 4-bit throughput.

When is running MiniMax M3 locally actually worth it?

Be clear-eyed about the trade. M3's API is inexpensive (MiniMax's published rate is around $0.30 per million input tokens and $1.20 per million output at promo pricing), so local hosting rarely wins on raw cost until you are pushing very high volume. Local makes sense when you need data to stay on your own hardware, want deterministic latency without a network hop, or are experimenting with fine-tunes and custom serving. If you mostly want the model's output and not the operational burden, the hosted API is the pragmatic default.

If you are standing up self-hosted inference as part of a real product and want engineers who have shipped this kind of GPU-serving work before, Codersera can help you hire vetted remote developers to build it out. For the wider context on where M3 sits among open-weight models, the open-source LLMs landscape guide is the pillar to start from, and the MiniMax M2.7 local setup guide covers the smaller sibling if M3 is more than your hardware can carry.

FAQ

Can I run MiniMax M3 on a single 24GB GPU?

Not in VRAM alone. Because M3 is a MoE with ~23B active parameters, you can run a 1–2-bit GGUF on a 24GB GPU only if you also have roughly 128GB or more of system RAM and offload the expert layers to the CPU. It works, but expect modest tokens per second.

What is the smallest quant that keeps M3 usable?

Community builders point to the ~3-bit dynamic GGUF (around 159GB) as the best balance of size and quality. The 1-bit and 2-bit versions load in less memory (~130–150GB) but give up more accuracy, which shows up most on coding and long-reasoning tasks.

Does GGUF give me the full 1M-token context speed?

Not yet. MiniMax Sparse Attention is what makes M3's long context cheap, and most GGUF runtimes fall back to dense attention because MSA support is still landing. For genuine fast 1M-context inference, serve the native MXFP8 or NVFP4 weights with vLLM or SGLang.

MXFP8, NVFP4, or AWQ — which quant format should I pick?

Use MXFP8 (the official quant) as the default for GPU serving. Choose NVFP4 on Blackwell GPUs for native-accelerated 4-bit throughput. AWQ INT4 is a fine community option under vLLM. Reach for GGUF only when you are offloading experts to system RAM on a workstation or Mac.

How much RAM do I need if I do not have a big GPU?

Aim for at least 133GB of combined RAM to load the smallest quant, and 192–256GB if you want headroom for a longer context window and a comfortable 3-bit build. On Apple silicon, a 256GB or 512GB unified-memory Mac Studio runs the 3–4-bit GGUF through LM Studio or MLX in a single quiet box.