MiniMax-M1: Scaling Test-Time Compute Efficiently with Lightning Attention

Long-context reasoning models chain many thousands of intermediate reasoning tokens, and paying full KV-cache attention cost for every one of those tokens does not scale, so test-time compute scaling was blocked by decode cost rather than by context length.

Hybrid MoE plus lightning attention, with the architecture inherited from MiniMax-Text-01: 456B total parameters, 45.9B activated per token, native 1M-token context, which the paper states is 8x the context size of DeepSeek R1. The novel claim in THIS paper is not the architecture but the serving-side consequence: because lightning attention carries a constant-size state, the mechanism enables efficient scaling of test-time compute, i.e. the per-token cost of emitting long chains of reasoning does not grow with how much context has already accumulated. That is the cleanest statement in this slice of why constant-state attention changes an economics problem (reasoning-token volume) rather than only a memory problem.

SLUG RENAMED 2026-10-04 (parent agent): was 'minimax-m1', colliding with the models record of the same id, which made every bare-slug cross-reference ambiguous. Inbound refs (['family']) all mean the models record, so none needed repointing; papers are cited via `sources`, never by bare slug. arXiv preprint; no journal-ref. Described by the authors as the first open-weight large-scale hybrid-attention reasoning model. speedup_reported is null: the paper's quantitative claims are the 1M native context, the 8x context multiple over DeepSeek R1, and the 45.9B-active-of-456B ratio, none of which is a throughput speedup with baseline and settings. llama.cpp support verified via the MINIMAX arch family; the general lesson (constant-state attention makes long reasoning chains affordable) is the reusable finding. VENUE_TRACK BACKFILL 2026-10-04 (paper-fields pass, agent w3p): venue_track 'unknown'. `venue` is 'arxiv-preprint', which means no peer-reviewed venue has been established for this work as of the verification date, so the track genuinely is not known. 'unknown' is used here rather than leaving the field null or guessing 'main': the schema separates 'unknown' from 'main' precisely so that an unprereviewed preprint is not silently counted as main-track work. This annotation is what lets a downstream filter distinguish 'peer reviewed, main track' from 'not peer reviewed' without inferring it from the venue string.