MiniMax-M2.5 is labeled by its publisher as a 230B-total, 10B-active mixture-of-experts model. The official Hugging Face repository currently lists 125 mapped safetensors files totaling exactly 230,134,264,560 bytes, or 230.134GB in decimal units. That makes 240GB an extremely tight file-only boundary, 256GB a 25.866GB file-only margin and 288GB a 57.866GB margin—before KV cache, runtime workspaces, allocator behavior or other live state.
Short answer
- 192GB: 38.134GB short. The official files do not fit wholly.
- 240GB: 9.866GB file-only margin. Treat this as an unsafe resident-fit target.
- 256GB: 25.866GB file-only margin. The files fit, but runtime viability is unproven.
- 288GB: 57.866GB file-only margin. More practical capacity, still not a performance or compatibility guarantee.
For distributed deployments, read the multi-GPU placement guide. To compare candidate capacity tiers, use the NVIDIA data-center hub or AMD Instinct hub.
Official repository facts
| Repository observation | Current official value | What it means |
|---|---|---|
| Mapped safetensors files | 125 | The index maps files numbered 00000 through 00124 |
| Summed blob bytes | 230,134,264,560 | 230.134GB decimal download-size boundary |
| Shard filename suffix | of-00126 | The label does not match the 125 mapped/listed files; do not infer a missing shard without repository evidence |
Index metadata total_size | 466,083,044,352 bytes | Logical tensor-size metadata differs from stored FP8 blob bytes; it is not the repository download total |
| Quantization config | FP8 E4M3, dynamic activations, 128×128 weight blocks | Some modules are excluded from conversion; “FP8” is not exactly one byte for every stored value |
| Architecture | 62 layers, 256 local experts, 8 experts per token | Active routing does not remove the stored expert weights |
| Maximum positions | 196,608 | Architecture ceiling, not a promise that maximum context fits on minimum hardware |
MiniMax-M2.5 file-only memory boundaries
| Nominal accelerator memory | Difference from 230.134GB | File-only interpretation |
|---|---|---|
| 192GB | 38.134GB short | Does not fit wholly |
| 230GB | 0.134GB short | Does not fit wholly |
| 240GB | 9.866GB margin | Files fit; unsafe boundary before runtime memory |
| 256GB | 25.866GB margin | Files fit; constrained depending on workload and placement |
| 270GB documented usable | 39.866GB margin | Files fit; exact platform exposure and runtime support still required |
| 288GB | 57.866GB margin | Files fit with more room for live state |
| 320GB | 89.866GB margin | Files fit in aggregate; multi-device placement still must be proven |
| 384GB | 153.866GB margin | Files fit in aggregate with larger capacity headroom |
Why 230B total and 10B active do not answer the VRAM question
Mixture-of-experts routing activates only part of the model for a token, but the deployment still needs access to stored expert weights. The 10B-active label may help explain compute behavior; it does not reduce the official checkpoint to a 10B-model download. Use the exact artifact, not active-parameter shorthand, for capacity planning.
The 240GB trap
A 240GB aggregate pool leaves 9.866GB after the stored files. Model loaders, non-FP8 tensors, KV cache, attention state, graph capture, communication buffers and allocator reservations still need memory. With multiple devices, the remainder is not one freely shared pool; a shard or duplicated allocation can exhaust one accelerator first. Do not market 240GB as a comfortable resident configuration without a measured, fully disclosed run.
256GB and 288GB hardware paths
A 256GB device such as MI325X clears the stored files by 25.866GB, while a 288GB MI350X or MI355X clears them by 57.866GB. Those are OAM-class server accelerators requiring qualified platforms, ROCm target and kernel support, Infinity Fabric topology, host resources, cooling and power. Capacity alone does not establish successful MiniMax execution or performance.
Multiple NVIDIA devices can also clear the boundary in aggregate—for example, three 80GB devices total 240GB, four 80GB devices total 320GB, and two H200 141GB devices total 282GB. The official MiniMax deployment guidance recommends vLLM and must be reconciled with the current engine version, tensor/expert parallel strategy and exact hardware. Device-count arithmetic is not a validated launch recipe.
Long context is a separate allocation
The config declares 196,608 maximum positions. Actual KV-cache and attention memory depend on input/output length, cache precision, batch, concurrency and implementation. A platform that barely clears the checkpoint files may have little or no room for the context that motivated the model choice.
Reproducible deployment checklist
- Pin
MiniMaxAI/MiniMax-M2.5and the exact revision. - Record the downloaded files and reconcile them with the official index.
- Name every accelerator, exposed memory, host, topology and placement strategy.
- Pin vLLM or another runtime, build, driver, kernels and launch flags.
- Disclose CPU, host-memory or storage offload.
- Fix input/output tokens, context setting, cache precision, batch and concurrency.
- Measure per-device peak memory, host-memory peak, correctness, prompt processing, decode and time to first token.
Check source-specific measurements, build a reproducible MiniMax record, or save private hardware criteria.
Primary sources
- Official MiniMax-M2.5 model card
- Official repository API with blob sizes
- Official configuration
- Official safetensors index
- Official vLLM deployment guide
- Official MiniMax-M2.5 GitHub repository
Reviewed October 25, 2026. File-size arithmetic is not an independent performance benchmark. Model capability claims remain publisher claims unless separately reproduced.