MiniMax M3.1 Flash on a Mac: 186GB at 3-Bit, 4-Bit Needs 512GB

MiniMax published the M3.1 Flash weights on 23 October 2026, and the Mac verdict takes about ten seconds of arithmetic. Unified memory is the single pool Apple Silicon shares between its CPU and its GPU, and the entire weight file has to fit inside it. The smallest MLX conversion of this 428B mixture-of-experts is 186.505 GB, the 4-bit conversion is 248.385 GB, and the cheapest file in unsloth's GGUF ladder is 129.361 GB. No Mac with 16GB to 128GB of unified memory can load any of those, and the 4-bit build needs a 512GB Mac Studio. The one thing a 128GB Mac can load is a 2-bit community GGUF, which is exactly the class we never rank.

TL;DR: The Mac floor for MiniMax M3.1 Flash is the mlx-community 3-bit text build at 186.505 GB, which fits a 256GB Mac Studio M5 Ultra and nothing smaller unless you drop to a 2-bit community GGUF. The 4-bit build at 248.385 GB needs the 512GB M5 Ultra, and Ollama still serves the model as a cloud tag only, so a Mac reader gets the files from Hugging Face or not at all.

Does MiniMax M3.1 Flash run on your Mac?

No Mac laptop and no Mac Studio below 256GB of unified memory can hold the model, and that includes the 128GB tier with the GPU-wired ceiling raised. The budget column follows the same rule our recommender applies to every model: the usable share of unified memory ramps from 70 percent at 32GB to 85 percent at 128GB and above. That leaves room for macOS, the KV cache and your apps. Our VRAM guide covers why that share is lower than the number on the box. For example, a 64GB Mac has about 48 GB of model budget, which is a quarter of the smallest MLX build.

Two of those rows are worth reading twice. A 128GB Mac has roughly 109 GB of model budget under the default rule, and community reports put the raised wired ceiling near 92 percent, or about 118 GB. The only file that clears either number is AtomicChat's AD-IQ2_XXS at 112.158 GB, a 2-bit build whose card claims a 128GB Mac with the GPU limit raised and a context up to about 32k tokens. Every 3-bit build and up, the MLX conversions included, starts above 129 GB, so the 128GB machine misses everything we would rank.

What MiniMax actually shipped

MiniMax-M3.1-Flash is a native multimodal mixture-of-experts model from MiniMax, built for coding, agentic workflows, computer use and cybersecurity, and it takes text, image and video input with text output. The model card lists approximately 428B total parameters with 23B activated per token and a context window of up to 1,000,000 tokens. The published config.json fills in the sizing-relevant detail: 60 hidden layers, 64 attention heads, 4 key-value heads at a head dimension of 128, and a 200,064-token vocabulary. Each layer routes tokens through 128 experts, 4 of them per token, plus one shared expert.

The timeline matters more than the architecture. The repository was created on 2026-10-17, and the Hugging Face API reports that every file in it carries a commit timestamp of 2026-10-23T03:37:20Z, which is when the local path became real. That is three days before this check, not a launch-day story.

Sizes below are sums of the blob sizes the Hugging Face API reported on 26 October 2026, in decimal units. The official repository totals 252,446,157,295 bytes, or 252.446 GB, of which the weight shards are 250,116,419,880 bytes (250.116 GB) and the bundled DSpark draft head is 2,301,867,426 bytes (2.302 GB).

Licence terms come from the repository metadata and the LICENSE file it ships, not from a launch post. The checkpoint is minimax-community, which grants free use for non-commercial purposes. Commercial use carries two conditions: display "Built with MiniMax M3.1-Flash" prominently, and either send a one-time notice to MiniMax or obtain prior written authorization if the product generates more than 20 million US dollars in yearly revenue. Open weights, then, in the downloadable sense rather than the permissive-licence sense.

The MLX ladder: 186.505 GB is the floor

MLX is Apple's own array framework for Apple Silicon, and its builds ship as safetensors rather than GGUF. Every MLX build of M3.1 Flash on the Hub is community work, and none of them is small. Sizes below are sums of the blob sizes the Hugging Face API reported on 26 October 2026, with the first rung to load a 256GB Mac at the top.

The 3-bit card is explicit about what it is: a text-only conversion that drops the vision tower. It states 3-bit affine weights at group size 64, which it calls 3.5 bits per weight, with the router kept at 8 bits. The card reports about 187 GB of peak memory in a short generation test and says the build was tested with mlx-lm 0.32.2. The 4-bit card keeps the source precision instead of requantizing: routed experts in NVFP4, attention and shared expert layers in MXFP8, router in float32, greedy output matching the original checkpoint token for token, and about 249 GB of peak memory. Those two peak figures are the clearest numbers in the release, and they are why the 4-bit build is a 512GB machine.

The GGUF ladder: the floor is a sub-2-bit quant

The GGUF side comes from unsloth's conversion, not from MiniMax. Its README is still headed "Work in progress", and the repository was rewritten as recently as 2026-10-25T05:13:48Z, so the largest single file a reader downloads can change between visits. The figures below are folder sums from the same API call on 26 October 2026, not single-shard quotes.

Read the first row as the floor of unsloth's ladder rather than as an answer. UD-IQ1_M is a sub-2-bit quantisation, which is below the line we take in why we never recommend 2-bit quants. It is listed so you know the smallest file that uploader published, not so you load it on a 256GB machine and call it a day. The first rung that looks like a working build on that machine is UD-Q3_K_XL at 193.951 GB, which leaves about 24 GB for everything else.

Other uploaders go lower, and the difference matters on a 128GB Mac. AtomicChat publishes a four-rung ladder of its own, requantized from a BF16 unpack with an importance matrix: AD-IQ2_XXS at 112.158 GB, AD-Q2_K at 161.582 GB, AD-IQ3_S at 208.938 GB and AD-Q4_K at 257.180 GB. Those are 2-bit and 3-bit class files, and the card states which machine each one targets. We list them and do not rank them.

Two caveats come with the GGUF route, and both are recent. The first is a llama.cpp bug: GGUFs converted from the official checkpoint produced garbled output because the minimax-m3 graph never applied the per-expert NVFP4 scales, which is issue #31063, opened on 2026-10-23 and closed on 2026-10-24. The fix, PR #31097, first shipped in release b11861 on 2026-10-24, so a Homebrew llama.cpp from before that date will not run these files correctly. The second is attention: llama.cpp runs MiniMax Sparse Attention only with flash attention on and without --kv-unified. Its MiniMax-M3 code also runs the first three blocks with dense attention, so those blocks read the whole context instead of the usual selection. The DSpark draft head is not in these builds either, which the AtomicChat card states outright.

One GGUF detail does beat MLX: the repositories ship vision projectors, unsloth's mmproj-BF16.gguf at 1.735 GB and mmproj-F32.gguf at 3.462 GB, plus AtomicChat's mmproj-MiniMax-M3.1-Flash-F16.gguf at 1.732 GB. The mlx-community text builds carry no vision tower at all.

What the 1M context adds on top

KV cache is the per-token state a model keeps so it does not re-read the whole prompt at every step, and here it is large. The config gives 60 layers with 4 key-value heads at a head dimension of 128. At 16 bits, one token costs 2 (key and value) x 4 x 128 x 2 bytes = 2048 bytes per layer, so 122,880 bytes across 60 layers, or 120 KiB per token.

MiniMax Sparse Attention does not make that smaller. MiniMax Sparse Attention (MSA) picks a top-k set of position blocks per query instead of attending to everything, which cuts the compute and the attention traffic, but the keys and values for every token are still stored. In llama.cpp the sparse path gets its own memory implementation, llama-kv-cache-msa.h, whose header comment says it runs two cache instances, one for the K/V tensors and one for the MSA indexer tensors. Sparsity changes which blocks are read, not how much is kept.

Put that against the 256GB machine. The 3-bit build leaves roughly 31 GB after the weights, which is about 250,000 tokens of context at f16 before you quantize the cache. The full 1M window needs about 129 GB of cache on its own, so it is a 512GB conversation, and a quantized cache is the only lever that moves it. This is arithmetic from the published config rather than a measurement, and it assumes a single sequence with no cache quantization. The AtomicChat card reaches the same order of magnitude from the other direction, putting the attention cache at about 0.14 MB per token, which it reports as 1.1 GB at 8k context and 4.5 GB at 32k.

Which runtime loads it on a Mac

The architecture is in mainline llama.cpp, which is the strongest signal available before anyone publishes a Mac benchmark. src/models/minimax-m3.cpp carries the header comment describing MiniMax Sparse Attention, states that MTP is not in released model weights, and declares LLM_TYPE_428B_A23B for the 60-layer case. Support for the family landed on 2026-07-26, before this checkpoint, and the file was still being fixed on 2026-10-24 with the commit that forwards quant scales to the graph. Conversion lives in conversion/minimax.py, and tools/mtmd/models/minimax-m3.cpp covers the vision tower, so the GGUF route to image input is upstream work on the same architecture rather than a MiniMax promise. That route runs on community conversions of the same weights, and the smallest of them is a 2-bit build. The GGUF path exists upstream, then, but the builds that fit a small Mac sit below our quality line.

The MLX route is proven upstream as well. ml-explore/mlx-lm#2003, merged 2026-10-23, is titled "Support loading the original MiniMax M3.1 checkpoint", and it is the conversion path both mlx-community cards name. The maintainers kept the router in float32 so that expert selection matches the original.

The Mac runtime that has published numbers is oMLX. oMLX 0.7.3.dev2 serves M3.1 Flash from the original NVFP4 checkpoint or from oQ builds. Its notes report oQ4e on an M3 Ultra with 1024-token code continuations and real-use sampling: 22.5 tok/s with Lightning MTP off and 42.0 tok/s with it on, one request at a time. Those are the oMLX contributors' measurements on their own machine, not ModelFit's, and the release is a development build.

Ollama is the one route that asks nothing of your Mac. The library page lists a single tag, minimax-m3.1-flash:cloud, with a 976K context window and text and image input. There is no local tag, so ollama run minimax-m3.1-flash streams from Ollama's servers rather than downloading 186 GB of weights. Our own catalog still lists the model as a cloud entry for the same reason.

The DSpark draft head is published, and one Mac runtime uses it

The repository ships the draft head as a real file, dspark/model-dspark-00001.safetensors at 2,301,867,426 bytes (2.302 GB), and the model card describes DSpark as the speculative decoding path that replaced an earlier MTP approach. The oQ3e-mtp card breaks the checkpoint down the same way, listing the language model at 192.497 GB, vision at 1.354 GB and the DSpark draft at 2.302 GB.

What that buys you depends entirely on the runtime. oMLX runs the bundled draft as Lightning MTP, which is where the 22.5 to 42.0 tok/s jump above comes from. The GGUF conversions leave it out, which the AtomicChat card states outright, and llama.cpp's architecture file states that MTP is not in released model weights. That is consistent with a conversion of the language model rather than of the full package. The safe reading: the draft head is worth 2.302 GB only if you are on a runtime that consumes it.

Bottom line

MiniMax M3.1 Flash is a two-machine model on Apple Silicon. The 256GB Mac Studio M5 Ultra takes the 3-bit text build at 186.505 GB with roughly 31 GB to spare, and the 512GB machine takes the 4-bit build at 248.385 GB with about 187 GB left over for context. Below 256GB, the only option is a 2-bit GGUF, which is a listing rather than a recommendation, and Ollama will not put the weights on your disk at all.

If you are sizing other large MoE releases against the same hardware, our DeepSeek V4 memory guide covers a generation with no local path at all, and the M5 Ultra 256GB picker shows what that machine does when the model is 120B rather than 428B.

FAQ

Can a 128GB Mac run MiniMax M3.1 Flash?

Only a 2-bit build, and that is a class we do not rank. The smallest file on the Hub is AtomicChat's AD-IQ2_XXS at 112.158 GB, whose card claims a 128GB Mac with the GPU limit raised and a context up to about 32k tokens. Every 3-bit build and up starts above 129 GB, which is past both the default budget of a 128GB machine (~109 GB) and the raised wired ceiling of roughly 118 GB.

Which Mac do I need for the 3-bit build?

A 256GB Mac Studio M5 Ultra, and only just. The MLX 3-bit conversion is 186.505 GB against roughly 218 GB of usable model budget, and its card reports about 187 GB of peak memory in a short generation test. Expect a text-only path and a context in the low hundreds of thousands of tokens rather than the advertised 1M.

Why does the 4-bit build need 512GB?

Because it is 248.385 GB on disk and its card reports about 249 GB of peak memory, which is above the ~218 GB usable on a 256GB machine. On a 512GB M5 Ultra, with roughly 435 GB usable, the same build leaves about 187 GB for the KV cache and everything else.

Is there a cheaper official quantisation?

No. MiniMax ships the unquantized checkpoint and recommends SGLang, vLLM and TokenSpeed for serving, with unsloth listed as an integration in progress. Every MLX and GGUF build on the Hub is community work, and the smallest of them is a 2-bit GGUF at 112.158 GB.

Can I run it from Ollama?

Only from Ollama's cloud. The library page lists one tag, minimax-m3.1-flash:cloud, with a 976K context window, and no local tag exists. A Mac reader who wants the weights gets them from the Hugging Face repositories linked here.

Sources

• MiniMaxAI/MiniMax-M3.1-Flash model card: architecture, 428B total and 23B active parameters, 1M-token context, MSA, DSpark draft head, MiniMax Community licence name.
• Hugging Face API, MiniMaxAI/MiniMax-M3.1-Flash with blob sizes: 252,446,157,295 bytes total, 250,116,419,880 bytes of weight shards, 2,301,867,426-byte DSpark draft, and the 2026-10-23T03:37:20Z commit timestamps.
• MiniMax M3.1 Flash config.json: 60 layers, 64 attention heads, 4 key-value heads at head dimension 128, 128 experts with 4 activated, 200,064-token vocabulary, 1,048,576 max positions, sparse attention settings.
• MINIMAX COMMUNITY LICENSE: non-commercial grant, "Built with MiniMax M3.1-Flash" display clause, prior written authorization above 20 million US dollars of yearly revenue.
• mlx-community/MiniMax-M3.1-Flash-Text-3bit and its blob sizes: 186.505 GB, text-only conversion, 3.5 bits per weight, router at 8 bits, about 187 GB peak memory.
• mlx-community/MiniMax-M3.1-Flash-Text-4bit and its blob sizes: 248.385 GB, NVFP4 experts with MXFP8 attention, about 249 GB peak memory.
• unsloth/MiniMax-M3.1-Flash-GGUF and its blob sizes: the UD quantisation ladder summed per folder, the mmproj files, the 2026-10-25 rewrite.
• AtomicChat/MiniMax-M3.1-Flash-GGUF and its blob sizes: the AD ladder from 112.158 GB, the 128GB target for AD-IQ2_XXS, the attention cache at about 0.14 MB per token, the flash-attention requirement and the missing DSpark draft.
• llama.cpp src/models/minimax-m3.cpp and llama-kv-cache-msa.h: MiniMax Sparse Attention, LLM_TYPE_428B_A23B, the two-instance MSA cache, the MTP comment.
• llama.cpp issue #31063, PR #31097 and release b11861: the dropped per-expert NVFP4 scales, the garbled output, and the fix that shipped on 2026-10-24.
• mlx-lm commit 59995f13: support for loading the original MiniMax M3.1 checkpoint, merged 2026-10-23.
• oMLX 0.7.3.dev2 release notes: MiniMax M3.1 Flash with Lightning MTP and the M3 Ultra oQ4e decode figures.
• Ollama library page: the single cloud tag with a 976K context window.
• MiniMax M3.1 Flash launch post: API pricing and the vendor framing of the release.