Run Xiaomi MiMo on cloud GPUs

The Xiaomi MiMo models to host today are MiMo-V2.6-Flash and MiMo-V2.6-Pro. Flash has 309 billion parameters with 15 billion active and a 177.74 GB checkpoint, which a 2x H200 VM holds with about 82 GB left (calculated). Pro has 1.02 trillion parameters with 42 billion active and a 573.46 GB checkpoint that needs 8x H200. Each size comes as an RL checkpoint and a MOPD upgrade of it, and a 9B distill built on Qwen3.5-9B fits one 48 GB card. Every card lists the MIT license.

Which Xiaomi MiMo checkpoint is which

Xiaomi's Hugging Face organization, XiaomiMiMo, created the V2.6 repositories on 21 September 2026 for the RL checkpoints and the 9B distill, and on 27 September 2026 for the MOPD checkpoints. The cards call Flash the efficiency-balanced checkpoint of the series and Pro the flagship. Both are sparse mixture-of-experts models with a 1M-token context that take text, image, video and audio input. Sizes are the summed safetensors files, and every card, recipe and cookbook linked on this page was checked on 12 November 2026.

RL is the checkpoint that came out of the series' reinforcement learning, which the card describes as one mixed run across coding, general agents, visual and cybersecurity tasks. MOPD is the upgrade of that checkpoint. The MOPD cards say it fuses several domain-specialized teachers into one model, and that it mitigates tool-call repetition, a failure in which "the model keeps issuing the same or highly similar tool calls". vLLM's recipe calls MOPD the recommended starting point for new deployments and says the original RL checkpoint can get stuck re-issuing the same tool calls, so I start from MOPD. The two checkpoints of each size have the same size, so the table holds for both.

The left-over figures are 92% of the VM's memory minus the checkpoint, so they leave out activations and CUDA graphs, and the engine's startup log has the real cache size. The V2.6 checkpoints are mixed precision. Their config.json lists quant_method fp8 with a store_dtype of mxfp4, and vLLM's recipe says the weights are stored as mxfp4 and computed as FP8, which is how 309 billion parameters come to 177.74 GB. Each repository also holds an audio tokenizer and a draft model for speculative decoding, so the main weights are 172.93 GB for Flash and 566.05 GB for Pro, and the recipes quote 173 GB and 566 GB.

The context is cheap to hold. Flash has 9 global-attention layers with 4 KV heads and 39 sliding-window layers with a 128-token window, which costs 22.5 KiB of BF16 cache per token, or 22.5 GiB for a full 1,048,576-token sequence. Pro costs 50 KiB per token. Both are calculated from config.json, and the KV cache explainer shows the method.

Serve MiMo-V2.6-Flash with vLLM on 4 H200s

vLLM's recipe serves both Flash checkpoints with one command and lists 4x H200, or an aggregate of at least 208 GB of GPU memory, as the hardware. It needs vLLM 0.31.0, the first stable release that can load the mxfp4-stored weights. The model cards still point at the older vllm/vllm-openai:mimov25-cu129 image, which the recipe says predates that support, so use the 0.31.0 image. It is built for CUDA 13.0, and vLLM's Docker page says that needs an R580 or newer driver, so run nvidia-smi first. This is the recipe's command for the MOPD checkpoint, wrapped in Docker with the port published on the VM's loopback address:

sudo docker run -d --name vllm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:v0.31.0 XiaomiMiMo/MiMo-V2.6-Flash-MOPD \
  --tensor-parallel-size 4 \
  --trust-remote-code \
  --gpu-memory-utilization 0.95 \
  --max-model-len auto \
  --reasoning-parser mimo \
  --tool-call-parser mimo \
  --enable-auto-tool-choice \
  --generation-config vllm

Reach it through an SSH tunnel, as in the vLLM guide. The recipe recommends temperature=1.0 and top_p=0.95. Its example request turns thinking on with chat_template_kwargs and enable_thinking, and it says to set that to false or leave it out to switch thinking off. A 2x H200 VM holds the checkpoint by the memory rule, but the recipe's verified shape is four GPUs, so that is where I start. A DFlash speculative decoding variant also exists, and it points --speculative-config at the dflash folder inside the downloaded snapshot because vLLM does not resolve that Hub subfolder itself.

MiMo-V2.6-Pro takes 8 GPUs

The recipe for Pro runs the same command with XiaomiMiMo/MiMo-V2.6-Pro-MOPD and --tensor-parallel-size 8. It lists 8x H200 or an aggregate of at least 680 GB, so eight H100s at 640 GB fall short even though the memory rule leaves them about 15 GB. 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.

SGLang's MiMo-V2.6 cookbook covers Flash on 4 GPUs and Pro on 8, on H200 or B300, builds its commands in a configurator and names the lmsysorg/sglang:dev image. Its own data marks the B300 recipes as verified and the H200 recipes as not verified, which is why I would start with vLLM on H200. The commands printed on the model cards are larger. The Flash card runs --tp 8 --dp 2 and the Pro card runs --tp 16 with --nnodes 2, which is two nodes and a cluster rather than one DeployGPU VM. The SGLang guide covers the engine.

The 9B distill on one 48 GB card

MiMo-V2.6-Distill-Qwen-9B is Qwen3.5-9B fine-tuned on MiMo-generated data. Its card calls it a 9B agentic model covering coding, general-purpose agent tasks, visual coding and cybersecurity, released as "a starting point for open research in agentic reinforcement learning". The checkpoint is 18.82 GB in BF16, so one 48 GB card holds it with about 25 GB left. At 32 KiB of cache per token, a full 262,144-token session costs 8 GiB (calculated from its config). The card reports SWE Verified at 61.1 against 60.0 for Qwen3.5-9B, averaged over 3 runs, and those are Xiaomi's own numbers.

The card documents SGLang only. It names no image, so this is its command in Docker with the latest tag that the V2.6 cards name:

sudo docker run -d --name sglang --gpus all --shm-size 32g --ipc=host \
  -p 127.0.0.1:30000:30000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  lmsysorg/sglang:latest \
  sglang serve \
  --model-path XiaomiMiMo/MiMo-V2.6-Distill-Qwen-9B \
  --reasoning-parser mimo \
  --host 0.0.0.0 \
  --port 30000

SGLang's installation page asks for a CUDA 13-compatible driver for its current images, so run the same nvidia-smi check before you pull lmsysorg/sglang:latest.

The --host 0.0.0.0 stays inside the container, where only the loopback-published port reaches it. The command sets a reasoning parser and no tool-call parser, and the card names none for this model. vLLM's Qwen3.5-9B recipe asks for vLLM 0.17.0 or newer and the distill declares the same architecture, but the MiMo card itself documents SGLang. Ollama lists the model as mimo-v2.6, with 9B tags from 6.6 GB (9b-q4_K_M) to 19 GB (9b-gguf-bf16) and a 256K context window, so it also runs through Open WebUI:

Ollama, GGUF and hosted MiMo

Ollama's mimo-v2.6-flash and mimo-v2.6-pro pages list one tag each, :cloud, so they run on Ollama's servers and download no weights, and I found no Ollama page for MiMo-V2.5, MiMo-V2.5-Pro or MiMo-V2-Flash on 12 November 2026. llama.cpp merged V2.6 conversion on 22 September 2026 in pull request 29257, and the ggml-org organization on Hugging Face publishes GGUF files for the Flash and Pro checkpoints and for the 9B distill. For Flash, ggml-org/MiMo-V2.6-Flash-MOPD-GGUF holds MXFP4 at 167.37 GB, Q2_K at 126.37 GB and Q2_K_S at 105.86 GB, summed per quantization, and its card says to run llama serve -hf ggml-org/MiMo-V2.6-Flash-MOPD-GGUF. By the memory rule the Q2_K_S build leaves about 24 GB on one H200 and the MXFP4 build about 92 GB on 2x H200 (calculated). The llama.cpp server guide covers the engine and the GGUF guide the format.

The cards also list hosted routes: "Also available in AI Studio, MiMo Code, Xiaomi MiMo Desktop, Xiaomi MiMo Open Platform API, and OpenRouter." MiMo Code is Xiaomi's terminal coding assistant, MIT licensed on GitHub, and its README lists a custom provider that can "add any OpenAI-compatible API in the TUI", so it can reach the vLLM server above through a tunnel. A few prompts do not need 573 GB of weights on a rented disk. The open coding models page sets MiMo beside the other models for coding agents, and the frontier models page covers the other 8-GPU VM models. For a general model that fits one card, the Qwen page is the smaller start.

The MiMo license

All eight repositories I read list license: mit in their card metadata, and none contains a LICENSE file. SGLang's V2.6 cookbook says "License: MIT, continuing the MiMo-V2.5 licensing as confirmed by the model team", while its older V2.5 page says Apache 2.0, so read the license field of the repository you download. The GitHub repository for MiMo-V2-Flash carries the Apache License 2.0 for its code.

Every card ends with a Use Restrictions section that lists uses Xiaomi asks you not to make, including "For any military purpose or application" and "To engage in or facilitate malicious cyber activities". The section closes with this sentence: "This notice is an informational reminder only and does not amend the applicable model licence or impose additional licence conditions." Read the whole section before you ship a product on these weights.

Disk space and download time

Stopping a DeployGPU instance deletes its disk, so every session downloads the weights again, and a full hf download of Flash is 177.74 GB while Pro is 573.46 GB. At an assumed 10 Gbit/s that takes about 2.4 minutes for Flash and 7.6 minutes for Pro, and at 1 Gbit/s about 24 minutes and 1.3 hours (calculated, because provider network speeds are not published). 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 column with 573 GB before you launch for Pro. The download guide covers faster ways to pull large checkpoints and the stop guide shows what to copy off first.