MiniMax-M3.1-Flash on a Mac Studio: 256 GB, and MLX First

What MiniMax shipped

The model card describes a native multimodal mixture of experts: about 428B parameters in total, 23B active per token, text, image and video input, text output, and a context window of up to 1M tokens. Its config has 60 layers, 128 routed experts (4 per token) plus a shared expert, and MiniMax Sparse Attention in all 60 layers; M3 still used full attention in its first three. The routed experts were trained in NVFP4 and the attention and dense layers in MXFP8, which is why the official weights are 250.1 GB, plus a 2.3 GB DSpark draft head for speculative decoding. The repo was created privately on 17 October and its single commit went public on 23 October.

MiniMax’s benchmark table is agentic and vendor-run, each score on the scaffold the card names. It reports no SWE-bench Verified or SWE-bench Pro score and notes that third-party quantizations may differ:

On its own card, then, M3.1-Flash trails DeepSeek’s newest Flash on the coding rows and leads on automation. The index scores its capability 48 of 50, the same as MiniMax-M3.

The licence: non-commercial by default

The MiniMax Community License is the same text as MiniMax-M3’s apart from the model name. It grants use “for non-commercial purposes”. Commercial use is allowed on conditions:

• display “Built with MiniMax M3.1-Flash” on a related website, interface or documentation;
• below US$20 million in yearly revenue, send MiniMax a one-time notice at api@minimax.io;
• above US$20 million, get MiniMax’s prior written authorization.

Its prohibited uses include military purposes. Running it on your own Mac for personal or research work needs nothing. The index scores the licence 4 of 10.

Which builds fit which Mac

Sizes from the Hugging Face API, checked on 24 October 2026 (decimal GB):

The index lists a 189 GB minimum, set by the 3-bit MLX build. On paper that clears a 192 GB M2 Ultra, but a 187 GB file leaves no room for macOS and the context cache on that Mac. Plan on a 256 GB Mac Studio; both fully specified runs peaked at 182.1 GB in oMLX’s accounting at a 1K context, rising to 187.5 GB at 32K on the M5 Ultra. 4-bit builds and the original checkpoint need 512 GB, an option Apple’s store still lists as “coming late October” for the M5 Ultra and had not opened for orders on 24 October.

Runtimes: MLX works, llama.cpp just got its fix

Status checked on 24 October 2026:

• oMLX. The measured run below used oMLX 0.7.2 with the oQ3e-mtp build and multi-token prediction off. oMLX 0.7.3.dev1, a development release from 24 October, adds official support: it serves the original NVFP4 checkpoint or the oQ builds and runs the bundled DSpark draft as speculative decoding.
• mlx-lm. mlx-community’s Text-3bit and Text-4bit conversions are “Tested with mlx-lm 0.32.2”. Both drop the vision tower, so they are text only. Loading MiniMax’s original checkpoint directly needs mlx-lm from GitHub: PR #2003 merged on 23 October, and the latest release is still 0.32.2. mlx-vlm added the model, vision included, on its main branch on 24 October (PR #2580); the latest release, 0.7.10, predates it.
• llama.cpp. GGUFs converted from the official checkpoint produced “token soup”: the minimax-m3 graph never applied the per-expert NVFP4 scales (issue #31063). The fix, PR #31097, merged on 24 October and first shipped in release b11861 the same day. Its author could not test it end to end, Unsloth’s GGUF card still says “work in progress”, and two GGUF uploaders report that upstream still runs the first three layers with dense rather than sparse attention. Homebrew’s llama.cpp predates the fix. AtomicChat’s files sidestep the scale bug because they were dequantized to BF16 before conversion. No llama.cpp speed on a Mac has been published yet.
• Ollama lists only minimax-m3.1-flash:cloud, a hosted model with nothing to download.

# 256 GB Mac, text only, stock mlx-lm
pip install -U mlx-lm
mlx_lm.chat --model mlx-community/MiniMax-M3.1-Flash-Text-3bit

Measured speeds

All Mac runs so far are community submissions to oMLX’s public benchmark board, decode only, with speculative decoding off:

The first two rows are in the index. The third was posted on 24 October, after this release’s data was frozen, and its quantization is not stated, so the index could at most list it without using it as a reference.

oMLX’s own release notes add a runtime developer’s figure: 22.5 tok/s for the 4-bit oQ4e build on an M3 Ultra with one request and speculative decoding off, measured before a decode speed-up that the same release says adds 14% at short context. With the draft head on, the notes report 42.0 tok/s. That is speculative decoding, a different workload, so the index records none of these.

The index’s figures: community25 tok/s on the M3 Ultra, and community35 tok/s on the M5 Ultra, the leaderboard’s reference chip for models that need more than 128 GB. That M5 Ultra figure is the measured 34.5 tok/s run, 1.36 times the M3 Ultra run on the same build. The model enters the leaderboard on this run at Score 64 (#53); the bandwidth estimate alone would have given about 28 tok/s (Score 62). The gain is larger than the 1.04–1.12 times seen in MiMo-V2.6-Flash’s M5 Ultra runs, and short of the 1.5 times bandwidth ratio between the chips.

Two practical notes. Speed falls with context: the M3 Ultra drops by about a third between 1K and 8K tokens. And prefill is slow on the older chip: oMLX measured 270–290 tok/s on the M3 Ultra against 850–1,090 on the M5 Ultra, so at those rates a 32K-token agent prompt takes about two minutes to start answering on the M3 Ultra and under 40 seconds on the M5 Ultra.

What a 128 GB Mac can’t do

The smallest MLX build is 186.5 GB, so nothing loads normally on 128 GB. One community member tried streaming experts from an NVMe drive on a 128 GB M4 Max (oQ3e build, mlx-vlm’s expert-offload path inside oMLX 0.7.2’s Python), and posted the results in oMLX issue #4786:

• community2.93 tok/s with a 24 GB expert cache and community4.53 tok/s with a 71 GB cache, greedy, 1,558-token prompt;
• prefill of 34–40 tok/s: a 10,818-token prompt prefilled at 40.2 tok/s and took 269 seconds to the first token;
• by the reporter’s arithmetic, 15 tok/s would need about 159 GiB of experts resident, which cannot fit in 128 GB.

AtomicChat’s 112.2 GB 2-bit GGUF is listed as fitting a 128 GB Mac with macOS’s GPU limit raised and about 32K of context, but no Mac run has been published, and its card reports unusually high divergence from the original even for its 4-bit file. At 128 GB the index’s pick is Qwen3.8-Flash-Next, at community46 tok/s on an M5 Max.

Against the other big models

As of 24 October 2026, with the index’s figure for each chip (these cells update with every build):

Why does M3.1-Flash rank a point below M3 with the same capability and licence scores? Speed alone. The index’s M5 Ultra figure for M3 is a 4-bit estimate, while M3.1-Flash’s is its own measured 3-bit run, and estimates for giant mixture-of-experts models have erred in both directions, so treat that one point as unsettled until M3 has a measured M5 Ultra run. The bigger point stands either way: MiMo-V2.6-Flash, the index’s pick for 192–512 GB Macs, is about twice as fast on the same Mac, needs less memory and is MIT-licensed. DeepSeek V4.1 Flash scores higher on MiniMax’s own card but needs 512 GB at the index’s 3-bit floor and runs only in oMLX and Rapid-MLX.

Should you run it?

• You own a 256 GB Mac Studio. Worth a try if your work is agentic (tool use, computer use, security tasks) and either non-commercial or fine with the credit and notice terms. Use oMLX with the oQ3e-mtp build, or mlx-lm 0.32.2 with Text-3bit for text only. Keep prompts short on an M3 Ultra.
• You want the best model a 256 GB Mac runs. The index says MiMo-V2.6-Flash. MiniMax-M3.1-Flash is the specialist alternative, not the default.
• You use llama.cpp or LM Studio. Wait for builds and GGUFs that include the 24 October fix and for a first Mac report; until then, MLX is the dependable path.
• You have 128 GB. Don’t. SSD streaming tops out around 4–5 tok/s with minute-long prefills.

Frequently Asked Questions