MiniMax-M3.1-Flash: 428B of weights that want to be served like 23B

MiniMax put the weights of M3.1-Flash on Hugging Face in late October, and the first row of the benchmark table is a provocation. On Automation-Bench v1.0.6 the open model scores 62.8, ahead of DeepSeek V4.1 Flash-1017 at 60.5, Opus 5 at 50.3 and GPT-5.6 Sol at 45.8. The card describes a natively multimodal mixture of experts with roughly 428B total parameters and about 23B active per token, taking text, image and video in, producing text, with a context window of up to 1M tokens. What caught my attention is the three efficiency mechanisms stacked on top of each other, and how little the release says about what they buy on your hardware.

What actually shipped

The model card describes three changes that land on whoever serves it. No full-attention layers are left: M3 kept its first three, and M3.1-Flash swaps them for MiniMax Sparse Attention (MSA), so every layer attends only to the blocks it selects. Quantization-aware training (QAT) covered the routed experts and the attention paths, so the low-precision weights you download are the ones the model learned with, not a compression bolted on afterwards. And a new speculative decoding head called DSpark replaces the earlier EAGLE-like multi-token prediction and ships as a draft head, which only helps if your runtime loads it. SGLang, vLLM and TokenSpeed have launch recipes; Transformers and KTransformers support is still in progress.

The license is the custom MiniMax Community License, not Apache or MIT. AiCybr's summary of it says commercial use needs a visible "Built with MiniMax M3.1-Flash" notice and that products above 20 million dollars in annual revenue need written authorization. Read the license text yourself before this goes behind a customer-facing feature.

The parameter count does not add up

The card text says approximately 428B total, the Hugging Face metadata counts 220B parameters, and the repository download is roughly 252 GB. Those three numbers cannot all describe the same thing in a naive way: 428B parameters at one byte each would be well over 400 GB. The tensor types listed are F32, BF16, F8_E4M3 and U8, plus an mxfp8 tag. My reading is that a large share of the expert weights is stored packed in U8 containers, which the Hub counter treats as one element even when each byte holds more than one value. That would explain both the low parameter count and the 252 GB. I have not confirmed this against the config, and MiniMax does not state the QAT bit widths anywhere on the card, so treat it as a hypothesis to check before you size a machine.

The practical consequence is simple. "23B active" sets your per-token compute and your decode bandwidth. The 252 GB sets how much accelerator memory you need before the first token of KV cache. A 256 GB configuration leaves no room for any context worth having, and the 1M window is a ceiling, not something you get for free.

What sparse attention actually buys

The MSA paper from June is the most concrete part of the story. MSA is blockwise sparse attention built on grouped query attention (GQA). A lightweight index branch scores key-value blocks and picks a top-k subset separately for each GQA group, and the main branch computes exact attention only over the selected blocks. On a 109B natively multimodal model the authors report quality matching GQA, a 28.4x cut in per-token attention compute at 1M context, and 14.2x prefill and 7.6x decode wall-clock speedups on H800 GPUs with their co-designed kernel.

Every efficiency number in this release was measured on something other than the checkpoint you would actually download.

Now try to turn those numbers into a GPU order. They were measured on a 109B model in June, not on M3.1-Flash. For this checkpoint the card gives no sparsity ratio, no block size and no long-context throughput. DSpark comes with no acceptance rate and no speedup, and QAT is said to reduce memory and improve serving efficiency without a single figure. The architecture is plausibly fast at long context, but if someone asks how many tokens per second one node serves at 512K, nothing in this release answers. As I wrote in the break-even piece, speculative decoding can turn into a net loss at high batch sizes, and without an acceptance rate you cannot tell which side of that line DSpark lands on.

Reading the benchmark table honestly

The highlights are real but selective. M3.1-Flash ties Opus 5 on BankerToolBench at 76.2 and leads LOCA-Bench 256K at 60.3. It loses clearly elsewhere: Terminal Bench 4.0 at 38.1 against 51.8 for Opus 5, NL2Repo-Bench at 61.2 against 75.3, OSWorld 2.0 at 61.7 against 70.6. On DeepSWE v1.1 it scores 73.7, below DeepSeek V4.1 Flash-1017 at 77.0. Several rows depend on harness and judge choices. BankerToolBench ran through OpenCode with MiniMax-M2.7 as the judge, CharXiv RQ used GPT-5.5 as judge, and context settings range from 200K to 1M depending on the benchmark. A vendor's older model grading the vendor's new model is not a neutral measurement.

The card also warns that third-party quantizations may score differently from the official weights. The official weights are already QAT-trained at low precision, so I would not trust a community re-quant for agent work without side-by-side numbers.

What I would test this week

If you run agent workloads on your own GPUs, run this test before ordering anything. Replay your longest real agent trace, the kind where prefill dominates the bill, through vLLM or SGLang at 128K and then 512K context, with the DSpark head on and off. Record prefill time, decode tokens per second and peak memory per GPU, and put them next to what you serve today in the local cost calculator. If prefill at 512K is not several times faster than your current full-attention model, stop there: the 1M context is marketing for your workload, and the hosted API is the cheaper way to buy those benchmark scores.