MiniMax opened the M3.1 Flash weights on October 23: about 428B total parameters, 23B activated per token, native 1M-token context. Reading "23B active," many assume one consumer card might get close. The opposite is true: the smallest tier across all officially verified recipes is four data-center cards, and on Hopper it takes a full node of eight H100s. This SOP answers one question — how to actually run it — with three official verified recipes, a VRAM ledger, and a troubleshooting list. Every command is copied verbatim from the official vLLM recipe and SGLang cookbook with its source; estimates and unpublished numbers are labeled as such.
Scope first: launch story, anonymous testing, and benchmarks belong to the October 21 unmasking piece, which has no deployment content; acquisition overview, license deep-read, and ecosystem coverage belong to the open-weights piece. This article covers commands, the memory ledger, troubleshooting.
One: the deployment floor — no single-card recipe exists
MiniMax has published no unified minimum-hardware spec; what exists are verified recipes per framework. Per the official vLLM recipe and SGLang cookbook, the minimum viable tiers are: four Blackwell cards (B200/B300/GB200/GB300, TP4), four AMD MI355X (TP4), or a full Hopper node of 8x H100/H200 (TP8, FP8 path). No official recipe supports single-card or consumer hardware — that is model structure, not laziness, and Section Five does the math. Do not attempt a 4090.
Two: weights and download — three calibers for size
Two official addresses, verified on release day: Hugging Face at MiniMaxAI/MiniMax-M3.1-Flash (public, not gated; Hub metadata shows 2026-10-23 02:26 UTC per timesof.ai, another outlet says files updated 03:37 UTC — note the caliber when citing "release time"), and ModelScope at MiniMax/MiniMax-M3.1-Flash (repo address: modelscope.cn/models/MiniMax/MiniMax-M3.1-Flash; via ITHome). There is no official GitHub repo named after the model — github.com/MiniMax-AI/MiniMax-M3.1-Flash returns 404; the relevant org repo is the kernel library MiniMax-AI/MSA (needed for SGLang on Blackwell). Any "official GitHub model repo" link is fabricated.
Download command (model card, local-deployment section):
hf download MiniMaxAI/MiniMax-M3.1-Flash --local-dir MiniMax-M3.1-FlashMirror variant for mainland China (cnblogs):
export HF_ENDPOINT=https://hf-mirror.com
huggingface-cli download MiniMaxAI/MiniMax-M3.1-Flash --local-dir ./MiniMax-M3.1-FlashSize exists only in multiple calibers:
- Community tally: 252.4 GB, 48 safetensors shards plus a 2.3 GB DSpark draft head (orcarouter, second-hand);
- Official vLLM recipe: runtime weights 285 GB (NVFP4), 293 GB (MXFP4 Quark), 533 GB (FP8);
- Contradiction: the model card says "about 428B" while HF safetensors metadata says "220B params" — unreconciled by the vendor (timesof.ai); this article follows the model card.
The 252.4 GB versus 285 GB difference is plausibly download-versus-runtime footprint; shard totals are unconfirmed. Precision: the official checkpoint is one QAT-native format — routed experts NVFP4, shared experts MXFP8, query path FP8 (vLLM recipe caliber). No standalone FP8/BF16/INT4 official quantized repos were published on release day (unpublished). Known variants: AMD's Quark-MXFP4 (293 GB), FlagRelease W8A8 builds for nine platforms, and a third-party unsloth GGUF whose tiers and accuracy loss are unverified — the model card warns "Results are for the official weights; third-party quantizations may differ."
Three: vLLM — fix the version before copying commands
The critical precondition: vLLM 0.33.0+ is required, but that version was not on PyPI on release day — merging into upstream wheels takes about a week (official vLLM blog). Until then there are two legitimate paths: the official prebuilt Docker images, or a nightly wheel. If a pip-installed stable release reports "unknown speculative method / parser / architecture," this is why.
Official images (vLLM blog):
vllm/vllm-openai:minimax-m31-flash # NVIDIA
vllm/vllm-openai-rocm:minimax-m31-flash # AMDRecipe one, full-node H100/H200 TP8 (Hopper runs FP8 KV with Marlin kernels; DSpark is not enabled here officially; verbatim from the vLLM recipe):
vllm serve MiniMaxAI/MiniMax-M3.1-Flash \
--tensor-parallel-size 8 \
--reasoning-parser minimax_m3 \
--block-size 128 \
--kv-cache-dtype fp8 \
--attention-config '{"indexer_kv_dtype": "fp8"}' \
--compilation-config '{"cudagraph_mode": "FULL_AND_PIECEWISE"}' \
--max-model-len 262144 \
--max-num-seqs 80 \
--limit-mm-per-prompt '{"video": 0}' \
--gpu-memory-utilization 0.9 \
--no-enable-log-requests \
--disable-hybrid-kv-cache-manager \
--moe-backend marlin \
--enable-auto-tool-choice \
--tool-call-parser minimax_m3Recipe two, GB200 TP4 (Blackwell, native NVFP4, with DSpark):
VLLM_FLOAT32_MATMUL_PRECISION=high \
vllm serve MiniMaxAI/MiniMax-M3.1-Flash \
-tp 4 \
--reasoning-parser minimax_m3 \
--block-size 128 \
--kv-cache-dtype nvfp4 \
--attention-config '{"indexer_kv_dtype": "nvfp4", "use_prefill_query_quantization": true}' \
--compilation-config '{"cudagraph_mode": "FULL_AND_PIECEWISE"}' \
--speculative-config '{"method":"dspark","num_speculative_tokens":3,"attention_backend":"FLASH_ATTN","kv_cache_dtype":"fp8","draft_sample_method":"probabilistic","rejection_sample_method":"block"}' \
--max-num-seqs 256 \
--disable-hybrid-kv-cache-managerRecipe three, MI355X TP4 (AMD; NVFP4 experts requantized to MXFP8):
VLLM_ROCM_USE_AITER=1 VLLM_ROCM_USE_AITER_FUSION_SHARED_EXPERTS=1 \
vllm serve MiniMaxAI/MiniMax-M3.1-Flash \
-tp 4 \
--reasoning-parser minimax_m3 \
--block-size 128 \
--kv-cache-dtype nvfp4 \
--attention-config '{"indexer_kv_dtype": "nvfp4", "indexer_decode_cp": true}' \
--quantization-config.moe mxfp8 \
--speculative-config '{"method":"dspark","num_speculative_tokens":3,"attention_backend":"TRITON_ATTN","kv_cache_dtype":"fp8","draft_sample_method":"probabilistic"}' \
--disable-hybrid-kv-cache-managerTwo mandatory flags. --block-size 128 is hard-required by MSA sparse attention (sparse block 128); drop it and vLLM fails with No common block size for 16 (vLLM recipe) — the first item in the official error catalog. Every official command also carries --disable-hybrid-kv-cache-manager; the recipe does not explain it separately, but do not remove it — the error from dropping it is undocumented; restore the original command if startup misbehaves.
On 1M context: the model natively supports 1,048,576 tokens; vLLM controls it via --max-model-len, defaulting to auto, which adapts to KV capacity; the official Hopper example caps at 262144 (256K) explicitly due to memory. The DSpark draft head ships in the checkpoint's dspark/ directory. The recipe also documents a 1P1D prefill/decode disaggregated setup; on AMD each prefill-node rank needs 560 GiB of host huge pages (Section Seven, item nine).
Four: SGLang — not merged to main, special install path
SGLang's support code was not merged into main as of writing. The official cookbook gives a PR-based install flow (the PR number is marked TBD in the docs; substitute the real value; source: SGLang cookbook):
PR_NUMBER=<the PR number of the model support PR>
git clone https://github.com/sgl-project/sglang.git
cd sglang
git fetch origin "pull/${PR_NUMBER}/head"
git checkout FETCH_HEAD
uv pip install --prerelease=allow -e pythonBlackwell additionally needs MiniMax's official MSA kernel (not needed on Hopper or AMD), pinned to the officially specified commit:
git clone https://github.com/MiniMax-AI/MSA.git
cd MSA
git checkout c8e1013a16a708d2a7656805d5fc26f2b87715d1
uv pip install --no-deps -e .Docker images: lmsysorg/sglang:dev-minimax-m31-flash (NVIDIA) and lmsysorg/sglang:dev-minimax-m31-flash-mi35x (AMD MI350X/MI355X, ROCm 7.2).
Recipe four, 4x B300 Balanced (official verbatim):
FMHA_SM100_ALLOW_JIT=1 \
sglang serve \
--trust-remote-code \
--model-path MiniMaxAI/MiniMax-M3.1-Flash \
--reasoning-parser minimax-m3 \
--tool-call-parser minimax-m3 \
--tp 4 \
--moe-runner-backend flashinfer_trtllm_routed \
--speculative-algorithm DSPARK \
--speculative-use-block-verification \
--cuda-graph-backend-prefill breakable \
--chunked-prefill-size 32768 \
--max-running-requests 128 \
--cuda-graph-max-bs-decode 128 \
--mem-fraction-static 0.8 \
--tokenizer-worker-num 8 \
--host 0.0.0.0 \
--port 30000Recipe five, 8x H200 Balanced (official verbatim):
sglang serve \
--trust-remote-code \
--model-path MiniMaxAI/MiniMax-M3.1-Flash \
--reasoning-parser minimax-m3 \
--tool-call-parser minimax-m3 \
--tp 8 \
--context-length 140000 \
--cuda-graph-backend-prefill breakable \
--mem-fraction-static 0.85 \
--cuda-graph-max-bs-decode 64 \
--tokenizer-worker-num 8 \
--host 0.0.0.0 \
--port 30000Three details trip people up. The parser naming differs: SGLang uses hyphenated minimax-m3, vLLM underscored minimax_m3 — swapping them breaks both. DSpark on SGLang needs only --speculative-algorithm DSPARK, loading from the repo's dspark/ directory automatically; PD-disaggregated deployments must enable DSpark on both ends. There is no dedicated 1M-context switch; the official 1M caliber is the 4x B300 MonoKernel recipe at 723 tok/s decode, batch 1, 1M context (919 at 256K, 1028 at 1K), with --max-running-requests capped at 8.
Five: the VRAM ledger — 428B fully resident, 23B only bounds compute
| Item | Figure | Caliber |
|---|---|---|
| Download size | 252.4 GB (48 shards + 2.3 GB draft head) | Community tally (orcarouter) |
| Runtime weights (NVFP4) | 285 GB | Official vLLM recipe |
| Runtime weights (MXFP4 Quark) | 293 GB | Official vLLM recipe |
| Runtime weights (FP8) | 533 GB | Official vLLM recipe |
| BF16 full weights | ~856 GB | Estimated at 428B x 2 bytes, not official; no official BF16 repo |
| SGLang MonoKernel per-rank routed-expert copy | 54.1 GiB/rank | SGLang cookbook |
| SGLang KV pool (B300, mem-fraction 0.8) | ~6.5M tokens (MonoKernel) / 10.4M (standard) | SGLang cookbook |
| 1M-context KV cache total | Unpublished | No official or community figure |
| Minimum viable hardware | 4x B200/B300, 4x MI355X, 8x H100/H200 | Official verified recipes |
The table kills a widespread misreading: "23B active, so I need only a 23B model's memory." No. Each token activates about 23B parameters, which bounds per-step compute and energy — not storage. All 428B expert weights must stay fully resident in memory; the router merely picks among them each step. AI Portal (caip.org.cn) makes the same point. This is the root cause of consumer infeasibility: the memory ledger scales with 428B total parameters, not 23B activated.
The GB cost of a 1M-context KV cache is unpublished by vendor and community alike. Confirmed: MSA makes KV cheap per token (sparse block 128, top-16 blocks, up to 2048 keys per query), and SGLang calibers a B300 node's KV pool at roughly 6.5M-10.4M tokens — but the authoritative total for 1M contexts is, honestly, unpublished.
Consumer status (low evidence): the smallest official recipe is four data-center cards. Transformers, KTransformers, unsloth, and ATOM are all marked "in progress" on the model card; no low-barrier official path has shipped. A third-party GGUF exists, but its tiers and accuracy loss are unverified.
Six: domestic silicon — FlagOS Day-0 across nine chips
FlagOS (BAAI) completed Day-0 adaptation for nine chip families — T-Head, NVIDIA, Huawei Ascend, Hygon, Kunlunxin, MetaX, Moore Threads, TsingMicro, Iluvatar CoreX — shipping unified W8A8 builds via vLLM-plugin-FL or SGLang-plugin-FL, named like FlagRelease/MiniMax-M3.1-Flash-W8A8-<chip>-FlagOS-Express. T-Head, NVIDIA, Hygon, Kunlunxin, MetaX, and Iluvatar run the vLLM path; Moore Threads and Ascend run the SGLang path. Performance figures are all FlagOS-official (32K in / 1K out / 64 concurrency, baseline 8x H100 on SGLang 0.5.19): normalized throughput at 165.0% for T-Head, 99.5% for Ascend, 85.9% for Kunlunxin. Caveat: the test is labeled "BF16," which is questionable — 428B BF16 needs ~856 GB and cannot fit 8x H100's 640 GB — so cite relative percentages only. On Ascend, "Day-0 access" is MiniMax's caliber; no independent Huawei-side deployment doc has been found.
Seven: troubleshooting — no community record yet, so lean on official presets
As of the verification date (the day after release), no high-frequency M3.1-Flash-specific GitHub issues were found — no substantial community troubleshooting record exists yet. The reliable reference today is the official docs' preset error catalog: 13 calibers across the vLLM recipe and SGLang cookbook. The key ones:
- vLLM:
No common block size for 16— missing--block-size 128(MSA forces block 128). Source: vLLM recipe. - vLLM doesn't recognize the speculative method, parser, or architecture — 0.33.0 was not on PyPI on release day; use a nightly wheel or the official images. Source: vLLM blog and recipe.
- SGLang on Blackwell dies at import — MSA kernel missing; install MiniMax-AI/MSA at the pinned commit. Source: SGLang cookbook.
- SGLang on Blackwell:
JIT compilation is disabled and AOT kernel ... was not found— setFMHA_SM100_ALLOW_JIT=1; the check tests existence only, so=0does not disable it. Source: SGLang cookbook. - SGLang on Blackwell is slow, no
nvfp4_to_fp8 backend=qmul4in logs — silent slow-path fallback; need nvcc 13.4+ (the PyTorch wheel's cu130 does not count). Source: SGLang cookbook. - SGLang on 8x B200: CUDA graph capture OOM — you copied the B300 recipe; officially use
--mem-fraction-static 0.75plus--cuda-graph-max-bs-prefill 16384. Source: SGLang cookbook. - SGLang on AMD rejects
--tp 8— ROCm supports TP4 and below; split into two TP4 services behind a router. Source: SGLang cookbook. - SGLang MonoKernel refuses to start — needs the trio of
--page-size 128, the 8-token DSpark chain (--speculative-num-steps 1 --speculative-eagle-topk 1 --speculative-num-draft-tokens 8 --speculative-dspark-block-size 7), and--disable-attn-tp-gather. Source: SGLang cookbook. - vLLM PD prefill node:
Cannot map 560.00 GiB of 1024 MiB HugeTLB pages— pre-allocate huge pages:
echo 2240 | sudo tee /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepagesand the container's hugetlb limit. Source: vLLM recipe.
10. Reasoning text leaks into answers — parser off or misnamed: vLLM underscored minimax_m3, SGLang hyphenated minimax-m3. Source: both official docs.
11. from_pretrained does not work — Transformers is still officially "in progress"; use vLLM, SGLang, or TokenSpeed. Source: model card and cnblogs testing.
12. Downloads fail from mainland China — switch to HF_ENDPOINT=https://hf-mirror.com; check disk headroom for 252 GB first. Source: cnblogs testing.
13. High time-to-first-token on long prompts — tokenization is the bottleneck; every official recipe carries --tokenizer-worker-num 8, and --max-running-requests should equal --cuda-graph-max-bs-decode so decode always hits a CUDA graph. Source: SGLang cookbook.
Eight: contradictions and unknowns — keep them in mind
Beyond the three contradictions already covered (428B vs 220B parameters; 252.4 GB vs 285 GB size; "routed experts NVFP4 + shared experts MXFP8 + query FP8" versus media paraphrases "routed experts W4A4, indexer and main branch Q8KV4"), several questions remain officially unanswered: a unified minimum-hardware table, the GB cost of the 1M-context KV cache, standalone official FP8/BF16/INT4 repos, Ascend-side deployment docs, and third-party GGUF tier sizes with accuracy losses. None are estimated here. Last reminder: the weights ship under the MiniMax Community License — free for non-commercial use; commercial use requires the attribution "Built with MiniMax M3.1-Flash"; organizations above 20 million USD annual revenue need prior written authorization. Open weights, not open source.
FAQ
Q1: I only have a 4090 or a Mac — is it truly hopeless? A: On official paths, yes. The smallest official recipe is four data-center cards, because all 428B expert weights must stay resident; 23B activation lowers the compute floor, not the memory floor. Transformers, KTransformers, unsloth, and ATOM are all marked "in progress," and the third-party GGUF is unverified — with an explicit official warning that third-party quantizations may differ.
Q2: vLLM fails with "No common block size for 16" — what now?
A: The command is missing --block-size 128, hard-required by MSA sparse attention; all three official vLLM recipes carry it. Add it back, and keep --disable-hybrid-kv-cache-manager — every official recipe includes it.
Q3: How do I enable 1M context, and why do official examples stop at 256K?
A: On vLLM set --max-model-len; the default auto adapts to KV capacity, and the official Hopper example caps at 262144 (256K) explicitly due to memory. SGLang has no dedicated switch; its 8x H200 recipe runs 140000. The VRAM cost of a 1M-context KV cache is unpublished, so check your KV pool first (SGLang: ~6.5M-10.4M tokens on a B300 node).
Q4: SGLang on Blackwell won't start or runs slowly — what do I check first?
A: Three steps. Confirm the MSA kernel at the pinned commit (without it the server dies at import); confirm FMHA_SM100_ALLOW_JIT=1 is set; confirm nvcc 13.4+ (the PyTorch wheel's cu130 does not count), or you land on a silent slow path — the tell is no nvfp4_to_fp8 backend=qmul4 in logs. All three come from the SGLang cookbook.
Q5: My company wants to deploy commercially — what does the license require? A: The MiniMax Community License is free for non-commercial use. Commercial use requires displaying "Built with MiniMax M3.1-Flash" and notifying the vendor; organizations above 20 million USD annual revenue need prior written authorization. The official checkpoint is a single QAT-native format and third-party quantizations may differ — standardize on official weights in production.
Related reading
- MiniMax M3.1 Flash Unmasked: Space Bunny Ran 200T Tokens: the launch story and official benchmark table
- Nemotron 3.5 Bolt Local Deployment: 74B on a 24GB Card: the other extreme — a deploy SOP on one 24GB card
- Open Weight, But How Open? Five Model Licenses Compared: where the MiniMax Community License sits among five licenses