16 Jun 2026
GLM-5.2
A million-token setting backed by index sharing
743B reported total · text
MiniMax M3 / MoE
MiniMax-M3
Sparse reads do not automatically mean a small cache
AnnouncementSources checked 2026-09-13
New to model sizes or GPU memory? Start with weights, parameters and quantization →
M3 is a useful candidate for long multimodal agent tasks and a particularly good model for learning the difference between storing context and reading it. Its sparse attention selects relevant blocks instead of reading the entire history on every step.
428Breported total parameters
23Bactive parameters per token
1,048,576configured token positions
Publisher-reported, rounded model count; not an exact tensor census. Multimodal components and packaging can change the artifact size.
Evaluate it for
Long-context coding and multimodal agent evaluation with supported MSA kernels.
Choose another path when
Treating a sparse-read speedup as proof that all KV storage is reduced by the same factor.
Release context
Why this release matters
The June model combines 428B total parameters, roughly 23B active and native multimodal training. MiniMax Sparse Attention adds a lightweight indexer to select blocks; the full retained state still needs its own capacity budget.
The announcement promised weights within ten days. We verified the current open checkpoint, not a precise first-publication day.
Release evidence · Announced 2026-06-01 · Follow the MiniMax M3 timeline →
Deployment starting points
Which hardware, how many, at what precision?
Start with an exact artifact and an engine that supports it. A configuration below is evidence of a documented path; its device count does not promise a particular throughput or concurrency.
No certified hardware configuration in this edition
Treating a sparse-read speedup as proof that all KV storage is reduced by the same factor.
The pinned model card establishes the architecture. It does not, by itself, prove that a particular GPU count runs this checkpoint at your target context. The capacity screen below helps rule out undersized allocations; a successful load and workload test are still required.
869.16 GB of tensor data in the pinned index
This is the index’s reported tensor payload, in decimal GB. It excludes file headers and runtime memory. Mixed precision, conversion and host/device placement determine how much GPU memory the loaded model needs.
Inspect the exact index metadata →Capacity screen: would the weights fit?
This estimates inference memory for a hypothetical uniform precision. It is useful for rejecting an allocation that is too small. It does not establish a working deployment or estimate training memory.
| Representation | Approximate weight floor | What remains to budget |
|---|---|---|
| 16-bit uniform | 856 GB | Cache, modality state, workspace, quantization metadata and uneven sharding |
| 8-bit uniform | 428 GB | Cache, modality state, workspace, quantization metadata and uneven sharding |
| 4-bit uniform | 214 GB | Cache, modality state, workspace, quantization metadata and uneven sharding |
Enter the total across the whole model replica, not per GPU: KV or recurrent cache for all concurrent requests, image/audio state and execution workspace. There is no universal default. We additionally leave 15% of each GPU unused.
856 GB for hypothetical weights
Enter a request-and-buffer budget to calculate the aggregate capacity requirement.
A count of one does not prove the engine supports this GPU. A count above one does not prove the model shards evenly or communicates efficiently. Publisher-reported, rounded model count; not an exact tensor census. Multimodal components and packaging can change the artifact size.
Architecture in practice
What the serving engine has to do
Store the history. Read the selected parts.
Fewer bytes read can reduce bandwidth pressure.
That does not prove an equal reduction in stored bytes.
Mechanism schematic based on the pinned model card and configuration. It explains a design principle; it is not a full implementation graph.
Inspect the full checkpoint specifications
| Exact checkpoint | MiniMaxAI/MiniMax-M3 |
|---|---|
| Text model type | minimax_m3_vl |
| Layers | 60 |
| Hidden width | 6,144 |
| Attention / KV heads | 64 / 4 |
| Head dimension | 128 |
| Routed / selected experts | 128 / 4 |
| Configured positions | 1,048,576 |
| Documented extension | Not recorded for this checkpoint |
| Inputs → output | text, image, video → text |
| License metadata | minimax-community · custom terms |
Open weights do not imply unrestricted use. Read the applicable license terms linked from the pinned card.
A useful comparison
What else belongs on the shortlist?
GLM5.2 compares index-sharing attention; K2.6 provides a contemporaneous multimodal MoE baseline.
20 Apr 2026
Kimi-K2.6
Keep the hardware fixed; compare the completed work
1,000B reported total · text + image + video
These are editorial comparison candidates. We have not run a matched quality or serving benchmark, so this is not a ranking.
Prepare to explain it
The interview lesson
Draw retained KV blocks, the indexer and selected reads. Explain how bandwidth savings can coexist with substantial resident cache.
Attention layouts · Quantization · Courses and worked examples
For a deployment evaluation, record exact weights, precision, engine, device count, interconnect, prompt/output lengths and concurrency. Report task success, errors, TTFT, TPOT and useful throughput together.
Sources and citation
Our assessment is editorial judgment based on the linked architecture and deployment evidence. Model facts are publisher-reported or attributed to runtime maintainers; no independent GPU benchmark was run.
AI Infra Interviews, “MiniMax-M3: release, architecture and deployment”, checked 2026-09-13. Preserve this date and the exact checkpoint when citing.