🧩 MiniMax M3 Locally: The 428B Model's Real Hardware Cost

MiniMax shipped M3 on June 1, 2026, and it's the kind of release that reads great in a benchmark table and terrible in a hardware budget: a 428-billion-parameter open-weight model with frontier coding scores and a genuine 1-million-token context window — attached to a parameter count that puts real self-hosting out of reach for almost everyone reading this. We've been through this exact gap with every giant MoE release this year. Here's the honest math on M3.

By the numbers

• 428 billion total parameters, with roughly 23 billion active per token (Mixture-of-Experts architecture)
• Released June 1, 2026; weights live on the official MiniMaxAI Hugging Face organization by June 7
• 1,000,000-token context window on the hosted API
• Accepts text, image and video input natively — not text-only
• Licensing: a commercially-restricted custom license, not a standard permissive open-source license

The hardware reality

The 428B/23B split is the headline, and it's easy to misread. Mixture-of-Experts architectures only activate a fraction of their parameters for any single token — that's what makes M3 fast to run once loaded, and it's why its per-token compute cost resembles a much smaller dense model. But "active parameters" describes compute, not memory: unless a serving stack specifically supports expert offloading, you generally still need the entire 428B parameter set resident in VRAM or fast system RAM to serve the model at all. Compute-cheap and memory-cheap are not the same thing, and M3 is the first without being the second.

The most realistic path for anyone without a server-grade rack is community quantization. Unsloth's dynamic GGUF builds bring the smallest usable configuration — UD-IQ3_XXS — down to roughly 159GB, which is a workable target for a well-specced multi-GPU workstation or a Mac Studio-class unified-memory machine, but it's nowhere near a single consumer GPU's reach. A back-of-envelope BF16 size (428B params × 2 bytes) lands around 856GB before any optimization — the chart above shows the gap between "quantized and just barely local-capable" and "the full-precision file you'll never load on a desktop."

Rent vs. own, again

We say this on every frontier-scale local guide because it keeps being true: for a model this size, the local-vs-cloud decision stops being a philosophical privacy debate and becomes arithmetic. Renting a multi-GPU instance by the hour on a cloud GPU marketplace to run the Unsloth quant costs a few dollars for an afternoon of testing — enough to know whether M3 actually earns a place in your workflow before you spend four figures on hardware that might sit mostly idle. If you're pushing enough daily volume that the API's per-token cost starts to hurt, that's the point where owning the hardware starts to make sense; almost nobody is at that point on day one.

Where M3 actually earns its size

The 1M-token context and native multimodal input are the real differentiators, not raw parameter count. Long-document analysis, large codebase review in a single pass, and workflows that mix text, image and video context in one request are the use cases M3's architecture is actually built for — and those are exactly the workloads where the hosted API's context-window pricing matters more than whether you own the GPU underneath it.

How this compares to the other giant open models we've covered

Model	Total / active params	Context	Realistic local path
MiniMax M3	428B / ~23B	1M	Multi-GPU quant (~159GB) or API
Kimi K3	2.8T / MoE	1M (hosted); ~128-256K local	Multi-H100 cluster or API — see our Kimi K3 guide
GLM-5.2	744B MoE	1M	The most self-hostable of the three — see our GLM-5.2 guide
DeepSeek V4 Pro	Dense/MoE, code+math focus	Varies	Covered in our DeepSeek V4 guide

API access while you decide

MiniMax serves M3 through its own hosted API, and that's the realistic on-ramp for almost everyone: no quantization decisions, no VRAM math, and a bill that scales with actual usage instead of an idle rig depreciating in a closet. Day-one serving support from major inference stacks (vLLM, SGLang) is the signal to watch if you're planning to self-host eventually — a model's local ecosystem tends to stabilize in the weeks after those integrations land, not at launch. Until then, hosted access is also the only way to sanity-check M3's 1M-token context and multimodal input against your actual documents and codebases before committing hardware budget to anything.

Who should actually consider self-hosting

Self-hosting M3 only pencils out in a narrow band: teams already running enough daily token volume that API costs exceed rental-hardware costs, workloads with a hard data-residency requirement that rules out any external API, or research use where inspecting and modifying the model itself is the point. Outside that band — including almost every solo creator or small team reading a "local AI" guide — renting a multi-GPU instance for a focused test session, or simply using the API, gets you the model's actual capabilities without the six-figure-adjacent hardware conversation a 428B model implies at full precision.

How we picked what to trust

Every figure above traces to MiniMax's own model card and blog post, the Hugging Face release listing, or Unsloth's published quantization sizes — we skipped the "runs great on a gaming laptop" claims some smaller blogs are already publishing, because a 428B model simply doesn't fit that framing however it's quantized. We'll revisit this page as more independent benchmarks and serving-stack support (vLLM, SGLang) mature.

Verdict

MiniMax M3 is a genuinely strong open-weight release — the 1M context and native multimodal input are real capabilities, not marketing filler — but "open-weight" and "runs on your desktop" are further apart here than for almost any model we've covered. Budget for a rented multi-GPU box if you want to touch the weights yourself, lean on the API for daily work, and if your hardware tops out around 24GB, our quantization guide will help you pick a model class that actually fits what you own.