Read time: ~12 minutes.

Key facts:

• MiniMax published the MiniMax-M3.1-Flash weights on October 23, 2026: about 428B total parameters, 23B active per token, text, image and video input, up to a 1M-token context (MiniMax on X, model card).
• The checkpoint is quantization-aware trained: MXFP8 dense layers and NVFP4 experts, plus a built-in DSpark speculative-decoding draft in a dspark/ folder (vLLM recipe). The safetensors add up to roughly 252 GB (about 250 GB main model, 2.3 GB draft), per the Hugging Face file listing.
• Officially recommended servers: vLLM, SGLang and TokenSpeed. Verified layouts are TP4 on NVIDIA GB200 / B300 / GB300 or AMD MI355X, and TP8 on 8x H200 at a 140K context in SGLang.
• It is not an Apache or MIT release. The MiniMax Community License allows free non-commercial use; commercial use needs a “Built with MiniMax M3.1-Flash” notice and either a one-time email notice or, above $20M yearly revenue, prior written authorization (LICENSE).

What we checked: we read the model card, the license, the bundled FlagOS deployment notes, config.json, the official vLLM recipe (vLLM commit d05b1c8, added October 23), the SGLang cookbook page and its verified command matrix, vLLM’s model registry, parser list and install docs, and PyPI. We did not run the model ourselves: we don’t have a 4x Blackwell node, so every speed and memory number here comes from MiniMax, vLLM or SGLang.

If you were waiting for MiniMax M3.1 Flash to become self-hostable, it is now: the weights are on Hugging Face and ModelScope, and vLLM and SGLang both ship tested launch commands for it. The catch is the size. This is a 428B mixture-of-experts model that needs a four-GPU Blackwell node (or eight H200s) to serve, the vLLM recipe asks for a version that isn’t on PyPI yet, SGLang support still lives outside its main branch, and the license is non-commercial unless you notify MiniMax. This guide walks through the download, hardware choice, both launch paths, the request-level controls and the errors the official docs warn about.

If you only want to call the model, the hosted API is far simpler and costs $0.15 / $0.60 per million input/output tokens. Our MiniMax M3.1 Flash API guide covers that route, including the free OpenRouter tier. The rest of this page is for people who need the weights on their own hardware.

What changed on October 23

When MiniMax launched M3.1 Flash on October 19, its launch post said “Model weights will be released later,” and its launch tweet said they “will arrive on Oct 23.” They did. MiniMax’s announcement reads: “MiniMax M3.1 Flash weights are now public. 428B parameters total, 23B activated per token,” with links to Hugging Face and ModelScope.

According to the model card, M3.1 Flash keeps the MoE design of MiniMax M3 with three changes:

• Sparse attention throughout. The first three full-attention layers of M3 are replaced with MiniMax Sparse Attention (MSA), so every layer is sparse.
• Quantization-aware training. The routed experts and attention paths were quantized during training. That’s why the release is already NVFP4/MXFP8 rather than BF16.
• DSpark speculative decoding. A draft head ships inside the checkpoint and replaces M3’s earlier MTP approach.

The published config.json matches that: 60 layers, 128 routed experts with 4 active per token plus 1 shared expert, a 200,064-token vocabulary and max_position_embeddings of 1,048,576.

MiniMax’s headline scores for the official weights include 73.7% on DeepSWE v1.1, 61.7 on OSWorld 2.0, 82.2 on CyberGym and 76.2 on BankerToolBench. The card notes that “Results are for the official weights; third-party quantizations may differ.” Those are vendor numbers measured with specific harnesses (Claude Code, mini-SWE-agent, Codex), so treat them as a starting point and run your own evals.

Step 1: Check you have the hardware

This is the step most people should stop at. The weights alone are about 250 GB, before any KV cache.

The official recipes cover these layouts:

Hardware	Server	Layout	Source
NVIDIA GB200	vLLM	TP4 (half a node), single node or prefill/decode split	vLLM recipe
AMD MI355X (ROCm 7.2+)	vLLM	TP4, single node or prefill/decode split	vLLM recipe
NVIDIA B300 / GB300	SGLang	TP4 (Low-Latency, Balanced, High-Throughput)	SGLang cookbook
NVIDIA H200	SGLang	TP8, context capped at 140,000 tokens	SGLang cookbook
AMD MI350X / MI355X	SGLang	TP4 per server (Low-Latency, High-Throughput)	SGLang cookbook

A few things in that table matter more than they look:

• Blackwell runs the experts natively. The vLLM recipe says NVFP4 MoE “runs natively on the FP4 tensor cores” on GB200, so no MoE quantization override is needed. On MI355X, vLLM re-quantizes the NVFP4 experts to MXFP8 at load (--quantization-config.moe mxfp8), and SGLang re-quantizes them to MXFP4.
• H200 works, with a shorter context. SGLang’s verified H200 recipe uses --tp 8 and --context-length 140000, and it doesn’t enable DSpark. If you only have Hopper, plan on 140K context, not 1M.
• AMD tops out at TP4 per server in SGLang. The cookbook says the server “refuses a larger TP.” On an 8-GPU MI350X/MI355X node, run two servers on GPUs 0-3 and 4-7 and put the SGLang router in front.
• Consumer GPUs and Macs are not covered. None of the official recipes target a single workstation GPU or Apple Silicon. The model card lists Transformers, KTransformers, unsloth and ATOM integrations as “in progress.” Wait for those, or use the API.

There is also a ninth-vendor route. The model card links FlagOS (from the Beijing Academy of Artificial Intelligence and partners), which publishes W8A8 conversions for T-Head, NVIDIA, MetaX, Hygon, Huawei Ascend, Moore Threads, Iluvatar, Kunlunxin and Tsingmicro chips under the FlagRelease/ org. Its example runs on T-Head with tensor_parallel_size=8. If you’re on one of those domestic accelerators, start from the matching FlagRelease model card rather than this guide.

Step 2: Read the license before you deploy

The weights ship under the MiniMax Community License, not a standard open-source license. In short, from the LICENSE file:

• Non-commercial use, copying, modification and redistribution are allowed free of charge, keeping the copyright notice.
• For any commercial use, you must “prominently display ‘Built with MiniMax M3.1-Flash’” on a related website, UI, blog post, about page or product docs.
• If the product or service makes more than $20 million a year, you need “separate, prior written authorization” by emailing api@minimax.io with the subject “M3.1-Flash licensing - authorization request”. Below that, a one-time notice email with the subject “M3.1-Flash licensing — notice” is enough.
• “Commercial use” explicitly includes paid services built on it, commercial use of APIs serving it, and commercially deploying fine-tuned or otherwise post-trained versions.
• An appendix lists prohibited uses, including any military purpose.

If you’re putting this behind an internal tool at a company, read the definition with your legal team. Running it to power a paid product without the notice is a license breach.

Step 3: Download the weights

The model card’s download command uses the Hugging Face CLI (hf, from huggingface_hub):

pip install -U huggingface_hub
hf download MiniMaxAI/MiniMax-M3.1-Flash --local-dir MiniMax-M3.1-Flash

Things to know before you start a 250 GB download:

• Budget about 235 GiB of disk for the weights, plus room for tokenizer files and caches. The repo has 48 main safetensors shards and a separate dspark/ folder for the draft.
• Download the whole repo, including dspark/. Both vLLM and SGLang find the draft in that subfolder automatically. vLLM’s recipe says --speculative-config “needs no draft model path,” and SGLang’s cookbook says that with --speculative-algorithm DSPARK and no draft path, “the server finds that subfolder and loads the draft from it.” If you skip that folder, speculative decoding has nothing to load.
• The model uses custom code. The repo includes configuration_minimax_m3_vl.py plus image and video processors, so SGLang’s commands pass --trust-remote-code. Review those files if your security policy requires it.
• In mainland China, the same weights are on ModelScope.

You can also point the servers at the Hub ID MiniMaxAI/MiniMax-M3.1-Flash directly and let them download on first launch. That’s convenient on a fresh node, but a pre-downloaded local directory makes restarts much faster.

Step 4 (vLLM): Install a new enough vLLM

The vLLM recipe lists vLLM 0.33.0+. As of October 23, the newest vLLM on PyPI is 0.32.0 (released October 18), so pip install vllm gives you an older build than the recipe was written for. vLLM’s install docs offer nightly wheels built from the main branch:

uv pip install -U vllm \
    --torch-backend=auto \
    --extra-index-url https://wheels.vllm.ai/nightly

vLLM’s docs warn that plain pip is “not supported” for nightly indices because it may pick the latest released version instead. Use uv. The default nightly variant is built for CUDA 12.9; add a variant subdirectory such as /cu130 if you need another one.

On AMD, use vLLM’s ROCm build; the MI355X recipe requires ROCm 7.2 or later.

Step 5 (vLLM): Launch the server

The GB200 single-node command from the recipe, verbatim:

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-manager

And the AMD MI355X single-node version:

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-manager

What the important flags do, according to the recipe:

• --block-size 128 is mandatory. MSA’s sparse block size is 128 (sparse_block_size: 128 in config.json), and the KV cache block size has to match.
• --kv-cache-dtype nvfp4 with indexer_kv_dtype: nvfp4 stores both the KV cache and the sparse-attention indexer’s K cache in NVFP4, which is how 1M-token contexts fit.
• --speculative-config turns on the bundled DSpark draft with 3 speculative tokens. No draft path is needed.
• indexer_decode_cp (AMD command) splits the indexer’s decode scoring across TP ranks by context instead of by index head.
• --reasoning-parser minimax_m3 separates the thinking trace from the answer.

Want tool calls? The recipe’s troubleshooting section says --tool-call-parser and --reasoning-parser “both use minimax_m3,” and vLLM’s tool-calling docs call --enable-auto-tool-choice mandatory for automatic tool calls. Add both to the command above:

  --tool-call-parser minimax_m3 \
  --enable-auto-tool-choice \

Both minimax_m3 parsers are present in vLLM’s main branch.

For a larger deployment, the recipe also has prefill/decode disaggregated (1P1D) commands for both GB200 and MI355X over NIXL. The AMD prefill node offloads KV to host memory: 560 GiB per rank in 1 GiB HugeTLB pages, or 2,240 pages for four ranks, which you must reserve before starting (echo 2240 | sudo tee /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages).

Step 4 (SGLang): Install from the dev image or the support branch

The SGLang cookbook is blunt: “MiniMax-M3.1 support has not yet been merged into SGLang main.” You have two options.

Option A, Docker (easiest):

docker pull lmsysorg/sglang:dev-minimax-m31-flash
# AMD MI350X / MI355X (ROCm 7.2):
docker pull lmsysorg/sglang:dev-minimax-m31-flash-mi35x

Option B, from source. The cookbook tells you to check out the model-support pull request, whose number it had not filled in when we read it (“The PR number is TBD”). The open PR titled “[Feat] minimax: Support MiniMax-M3.1-Flash” is sgl-project/sglang#45925; confirm it is still the right one before building, then:

pip install --upgrade pip
pip install uv
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 python
cd ..

On Blackwell (B300 / GB300 / B200), also install the MSA kernels. SGLang imports them at startup and “the server fails without them.” Hopper and AMD don’t use them:

git clone https://github.com/MiniMax-AI/MSA.git
cd MSA
git checkout c8e1013a16a708d2a7656805d5fc26f2b87715d1
uv pip install --no-deps -e .
cd ..

Some of these kernels compile at runtime and need a CUDA toolkit (nvcc) 13.4 or newer on the machine. The cookbook stresses that the CUDA version of your PyTorch wheel (cu130) “does not count.”

Step 5 (SGLang): Launch with a verified recipe

SGLang’s page generates commands from a matrix of hardware and strategy. These two come straight from its verified cells.

4x B300, Balanced (good speed for several users at once):

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 30000

8x H200, Balanced:

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 30000

Note the parser name: SGLang spells it minimax-m3 with a hyphen, vLLM uses minimax_m3 with an underscore. Copying one server’s flags into the other is an easy way to lose an afternoon.

Tuning notes from the cookbook worth knowing:

• The first launch is slow while the MSA and FlashInfer kernels compile. They’re cached under ~/.cache/minfer/msa_v1 and reused.
• --mem-fraction-static 0.8 is the validated value at TP4 on B300 and B200. B200 has 192 GB per GPU versus B300’s 288 GB, so B200’s high-throughput recipe drops to 0.75; with B300’s settings, 8x B200 runs out of memory capturing the 32K-token prefill CUDA graphs.
• --tokenizer-worker-num 8 is in every recipe because with 100K-token prompts a single tokenizer process becomes the bottleneck and time-to-first-token climbs.
• Keep --max-running-requests equal to --cuda-graph-max-bs-decode so every decode batch replays a captured CUDA graph.
• For multi-turn agent traffic, --enable-hierarchical-cache --hicache-size <GB per rank> keeps evicted prefixes in host memory so returning sessions don’t recompute them.

The Low-Latency recipe on B300 uses MiniMax’s MSA-V1 MonoKernel for one request at a time. SGLang measured decode at 1,028 tokens/s at 1K context, 919 at 256K and 723 at 1M on 4x B300 (with acceptance length fixed at 5), against 479, 465 and 408 on the standard path. It’s batch-size-1 only and caps --max-running-requests at 8, so it’s for a single fast agent, not a shared endpoint.

Step 6: Send your first request

Both servers expose an OpenAI-compatible Chat Completions API. vLLM listens on port 8000 by default; the SGLang commands above use 30000. MiniMax’s recommended sampling settings are temperature=1.0 and top_p=0.95.

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMaxAI/MiniMax-M3.1-Flash",
    "temperature": 1.0,
    "top_p": 0.95,
    "messages": [
      {"role": "user", "content": "Explain MSA sparse attention in 3 bullets."}
    ]
  }'

With the reasoning parser on, the thinking trace comes back in message.reasoning_content and the answer in message.content. When streaming, they arrive on delta.reasoning_content and delta.content, so you can render them separately.

Thinking mode and reasoning effort

This is one place where self-hosting differs from MiniMax’s hosted API. On the hosted API, thinking is always on and trying to disable it returns HTTP 400 (see our API guide). The SGLang cookbook documents two request-level fields for the open weights, passed as top-level body fields (extra_body in the OpenAI SDK):

• thinking: {"type": "enabled" | "disabled" | "adaptive"}. Omitting it means adaptive, where the model decides per turn. Any other type returns HTTP 400.
• reasoning_effort: low, medium, high, xhigh or max, passed to the chat template. none and minimal turn thinking off. Effort is ignored when thinking is disabled.

from openai import OpenAI

client = OpenAI(base_url="http://localhost:30000/v1", api_key="EMPTY")

response = client.chat.completions.create(
    model="MiniMaxAI/MiniMax-M3.1-Flash",
    messages=[{"role": "user", "content": "How many prime numbers are there below 50?"}],
    max_tokens=8192,
    extra_body={"thinking": {"type": "adaptive"}, "reasoning_effort": "low"},
)
print(response.choices[0].message.content)

On vLLM, the recipe documents effort through the chat template: chat_template_kwargs: {"reasoning_effort": "<level>"}. It doesn’t document a thinking field, so test before relying on disabled there.

Tool calls and images

With the minimax-m3 / minimax_m3 tool parser on, structured calls come back in message.tool_calls using the standard OpenAI tools format. To return a result, append the assistant turn with its tool_calls and one tool message per call with the matching tool_call_id, then call the model again.

Images use the standard image_url content type. If you run SGLang’s prefill/decode router, the cookbook warns that per-request media options such as max_long_side_pixel and video fps don’t reach the servers (observed with sglang-router 0.3.2).

Benchmark it on your traffic

The vLLM recipe includes a load test you can run as-is:

vllm bench serve \
  --backend vllm \
  --model MiniMaxAI/MiniMax-M3.1-Flash \
  --endpoint /v1/completions \
  --dataset-name random \
  --random-input 8192 \
  --random-output 1024 \
  --max-concurrency 32 \
  --num-prompts 320

Step 7: Don’t expose the endpoint

Neither command above sets an API key, and the SGLang examples bind to 0.0.0.0. A 4-GPU Blackwell box answering anyone on the internet is exactly what attackers scan for. Keep the server on a private network or behind an authenticating proxy. Our guide to locking down self-hosted LLM endpoints has the checklist.

Troubleshooting

vLLM: No common block size for 16. You left out --block-size 128. MSA’s sparse block size is 128 and the KV cache block size must match.

vLLM: unknown speculative method, unknown parser, or the architecture isn’t recognized. You are probably on an older vLLM. The recipe targets 0.33.0+, which wasn’t on PyPI as of October 23. Install the nightly wheel with uv as shown in Step 4.

SGLang on Blackwell: JIT compilation is disabled and AOT kernel ... was not found. Set FMHA_SM100_ALLOW_JIT=1 so the MSA kernels can compile on first launch. The cookbook notes that only the variable’s presence is checked, so =0 does not turn JIT off.

SGLang on Blackwell: the server fails at import. The MSA kernels aren’t installed. Install the MiniMax-AI/MSA repo at the pinned commit shown in Step 4.

SGLang on Blackwell is slower than expected. Check the startup log for nvfp4_to_fp8 backend=qmul4. If it’s missing, your CUDA toolkit is older than 13.4 and the server has silently fallen back to a slower path. Point CUDA_HOME at a 13.4 toolkit, for example /usr/local/cuda-13.4.

SGLang on 8x B200: out of memory during CUDA graph capture. You copied B300 settings. Use the B200 recipe’s --mem-fraction-static 0.75 and --cuda-graph-max-bs-prefill 16384.

SGLang on AMD: the server refuses --tp 8. M3.1 NVFP4 on ROCm runs at TP4 or less. Start two servers with HIP_VISIBLE_DEVICES=0,1,2,3 and HIP_VISIBLE_DEVICES=4,5,6,7 on different ports and put the router in front with --policy cache_aware.

SGLang Low-Latency (MonoKernel) refuses to start. It needs --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. The cookbook says that without the last flag “the server refuses to start.”

vLLM prefill node: Cannot map 560.00 GiB of 1024 MiB HugeTLB pages. Reserve the 1 GiB huge pages on the host (and allow them in your container’s hugetlb limit) before launching the disaggregated AMD prefill node.

Reasoning text is mixed into the answer. You didn’t enable the reasoning parser, or you used the other server’s spelling. vLLM wants minimax_m3; SGLang wants minimax-m3.

FAQ

Can I run MiniMax M3.1 Flash on a single GPU or a Mac? Not with any official recipe today. The smallest documented layouts are four Blackwell or MI355X GPUs, or eight H200s. MiniMax lists Transformers, KTransformers, unsloth and ATOM support as in progress, so smaller-footprint options may come later.

Is there a GGUF or smaller quantization? The official checkpoint is already NVFP4/MXFP8. AMD publishes a Quark MXFP4 build, amd/MiniMax-M3.1-Flash-Quark-MXFP4, which SGLang has run only with its Low-Latency recipe on MI350X/MI355X. FlagOS publishes W8A8 builds for nine chip vendors. MiniMax warns that third-party quantizations may score differently.

Can I use 1M tokens of context? The model supports it, but the model card says usable context “depend[s] on GPU memory and the serving configuration.” The Blackwell recipes use an NVFP4 KV cache to get there; the H200 recipe caps context at 140,000 tokens.

Do I need a separate draft model for speculative decoding? No. DSpark ships in the checkpoint’s dspark/ folder and both servers load it automatically. SGLang also supports RadixArk’s separately trained DFlash2 draft (RadixArk/Minimax-M3.1-Flash-Dflash2), on Blackwell only and only in colocated serving.

Self-host or API? At $0.15 / $0.60 per million input/output tokens on MiniMax’s API, self-hosting only makes sense if you already have the GPUs, need data to stay on your hardware, or run enough volume to keep a 4-GPU node busy. Start with the API, and compare with other large open-weight models we’ve covered, such as Kimi K3.

Sources

• MiniMax: weights announcement on X (October 23, 2026)
• MiniMax-M3.1-Flash model card, files and LICENSE on Hugging Face
• MiniMax M3.1 Flash launch post
• vLLM recipe: MiniMaxAI/MiniMax-M3.1-Flash
• vLLM GPU installation docs (nightly wheels)
• vLLM tool calling docs
• SGLang cookbook: MiniMax-M3.1
• ModelScope mirror