Run MiniMax-M3 on cloud GPUs

The MiniMax-M3 checkpoint is 854.18 GB in BF16, so it runs on an 8x H200 VM with about 184 GB left for the cache and runtime (calculated). MiniMax also publishes an MXFP8 build at 443.75 GB and MiniMax-M3.1-Flash, released on 19 October 2026, at 252.42 GB including its draft head. The license is free for non-commercial use and asks commercial users to show "Built with MiniMax M3" and to contact MiniMax, and Ollama lists only hosted cloud tags.

Five MiniMax checkpoints from 230 to 854 GB

The cards for MiniMax-M3 and MiniMax-M3.1-Flash list about 428 billion parameters, about 23 billion active and a 1M-token context, and vLLM's recipes list M2.7 and M2.5 at 230 billion with 10 billion active. M3 is natively multimodal, with text, image and video input. Sizes are summed safetensors files, and every card, recipe, cookbook and license linked on this page was checked on 12 November 2026.

The left-over figures are 92% of the VM's memory minus the checkpoint. They leave out activations, CUDA graphs and the vision encoder, so the engine's startup log has the real cache size. NVIDIA also publishes an NVFP4 build of M3 at 250.10 GB, which vLLM's recipe lists for Blackwell. Kimi K3 is a different class at 1,561 GB, and the Kimi K3 page has its math. The frontier models page sets M3 beside the other models that need all 8 GPUs.

MiniMax-M3 in BF16 on 8x H200

My starting point for MiniMax-M3 is the BF16 build on 8x H200, because both engines document that setup for Hopper. vLLM's recipe renders it at tensor parallel 8 and calls it a tight single-node fit. Its command caps the context at 65,536 tokens, and the recipe says a smaller --max-model-len frees memory for the cache. Two flags matter. --block-size 128 is mandatory on every platform because of the sparse attention cache, and the tool call and reasoning parsers are both minimax_m3, not the minimax_m2 of earlier releases. The recipe also points to a dedicated vllm/vllm-openai:minimax-m3 image. This is its Docker command with sudo, a container name and the port published on the VM's loopback address:

sudo docker run -d --name vllm --gpus all --privileged --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:minimax-m3 MiniMaxAI/MiniMax-M3 \
  --block-size 128 \
  --max-model-len 65536 \
  --tensor-parallel-size 8 \
  --tool-call-parser minimax_m3 \
  --enable-auto-tool-choice \
  --reasoning-parser minimax_m3

Reach it through an SSH tunnel, as in the vLLM guide. SGLang's cookbook runs the same BF16 build on H200 at --tp 8, says the MXFP8 kernels are Blackwell-only, asks for SGLang 0.5.22 or newer and requires --trust-remote-code. It says to launch with --reasoning-parser auto and --tool-call-parser auto. The card lists three reasoning modes, enabled, adaptive and disabled, and recommends a temperature of 1.0 and a top_p of 0.95. Pick an 8x H200 offer whose Interconnect column says NVLink (SXM), as the H200 page explains, and see the multi-GPU page for how the GPUs in one VM share a model.

MiniMax-M3.1-Flash

MiniMax released M3.1-Flash on 19 October 2026, according to its release notes. Its card calls it a native multimodal mixture-of-experts model for coding, agentic workflows, computer use and cybersecurity, with text, image and video input and up to 1M tokens of context. It builds on M3 with three changes. Sparse attention now replaces the first three full-attention layers, the routed experts and the attention paths are quantized during training, and DSpark speculative decoding replaces the earlier EAGLE-like approach, with a draft head in the release. The 48 weight files sum to 250.12 GB, and the draft in its dspark folder adds 2.30 GB. vLLM's recipe describes the format as MXFP8 dense layers with NVFP4 experts.

Engine support is recent. vLLM's recipe asks for vLLM 0.33.0 or newer and the vllm/vllm-openai:minimax-m31-flash image. It lists tensor parallel 4 on Blackwell, where NVFP4 uses the FP4 tensor cores, and tensor parallel 8 on a full H100 or H200 node with the FP8 variant. SGLang's cookbook says M3.1 support was not yet merged into SGLang main and names an lmsysorg/sglang:dev-minimax-m31-flash image. The recipe's own command has many Blackwell-specific flags, so copy it from the recipe page for your hardware.

M2.7 and M2.5 for a 4-GPU VM

If 8 GPUs is more than you want, M2.7 and M2.5 are the smaller choice. Both are FP8 checkpoints of 230.13 GB, so 4x H100 leaves about 64 GB and 2x H200 about 29 GB (calculated). vLLM's M2.7 recipe runs tensor parallel 4 on H200, H100 or A100 and says pure tensor parallel 8 is not supported. MiniMax's own vLLM deployment guide gives a 4-GPU command too and lists 220 GB for the weights plus 240 GB per 1M tokens of context. This is the recipe's command, which asks for vLLM 0.20.0 or newer:

sudo docker run -d --name vllm --gpus all --privileged --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e VLLM_USE_RUST_FRONTEND=1 \
  vllm/vllm-openai:latest MiniMaxAI/MiniMax-M2.7 \
  --trust-remote-code \
  --tensor-parallel-size 4 \
  --tool-call-parser minimax_m2 \
  --enable-auto-tool-choice \
  --reasoning-parser minimax_m2

The latest image is built for CUDA 13.0, and vLLM's Docker page says that needs an R580 or newer driver, so run nvidia-smi first. On an older driver, use v0.32.0-cu129, the last release with a CUDA 12.9 image (checked 12 November 2026).

Read the M2.7 license before you pick it. Its LICENSE is a non-commercial license that requires prior written authorization from MiniMax for commercial use and expressly allows personal use, including self-hosted deployment. The M2.5 repository carries a different file, LICENSE-MODEL.

Claude Code and the MiniMax API

MiniMax runs an API at platform.minimax.io, which the cards link, and its Claude Code page points Claude Code at https://api.minimax.io/anthropic with the model name MiniMax-M3.1-Flash[1m]. The page says thinking is always on for that model. That is MiniMax's hosted service, not your GPU. Ollama's library page shows ollama launch claude --model minimax-m3:cloud, which also runs on Ollama's servers. For a MiniMax model you serve yourself, the Claude Code guide has the setup, and the open coding models page compares what else is worth hosting.

The MiniMax M3 license in plain terms

The MiniMax Community License grants the rights to use, copy, modify, merge, publish, distribute and sublicense the weights for non-commercial purposes. For any Commercial Use you must display "Built with MiniMax M3" on a related website, interface, blog post, about page or product documentation. If the products or services that use it earn more than 20 million US dollars in yearly revenue, you need MiniMax's prior written authorization from api@minimax.io. Otherwise you send a one-time notice to the same address.

The license defines Commercial Use to include offering products or services for a fee that rely on the model, the commercial use of APIs for it, and deploying a fine-tuned version for any commercial purpose. An appendix bans uses such as any military purpose. The MXFP8 repository carries the same text, and the M3.1-Flash license is the same text with "Built with MiniMax M3.1-Flash" as the line to display. This is a summary, so read the file before you ship.

Ollama, Hugging Face and the download

Ollama lists minimax-m3:cloud and minimax-m3.1-flash:cloud, both hosted, and marks its minimax-m2.5 and minimax-m2.7 pages as retired with no models pushed, on 31 July and 9 November 2026. So on a rented GPU the engines are vLLM and SGLang. The M3 card's download command is hf download MiniMaxAI/MiniMax-M3 --local-dir MiniMax-M3, and the Docker commands above pull the same files into the mounted cache on first start.

Disks are fixed per offer on QuantaCloud, Massed Compute and Hyperstack and adjustable on Verda up to the offer's limit, so compare the disk size in the vCPU / RAM / Disk column with 854 GB. At an assumed 10 Gbit/s, 854.18 GB takes about 11 minutes, and at 1 Gbit/s about 1.9 hours (calculated, because provider network speeds are not published). Stopping a DeployGPU instance deletes its disk, so every session downloads the weights again. The download guide covers faster ways to pull them.