Xiaomi MiMo-V2.6 on a Mac: the 9B Distill Fits in 16GB, Flash and Pro Do Not

Xiaomi MiMo published the MiMo-V2.6 family on 21 September 2026 under the MIT license, and exactly one of its three checkpoints is a Mac model. MiMo-V2.6-Distill-Qwen-9B is a supervised fine-tune of Qwen3.5-9B that lands on the Hub as 18.85 GB of BF16 weights, and the community conversions run from 3.54 GB at IQ2_M to 9.53 GB for the official ggml-org Q8_0. We downloaded that official file, checked its SHA-256 against the Hub, and loaded it on a 16GB M4. The other two checkpoints are not a Mac story at all: Pro-RL is 573.49 GB of weights and Xiaomi's own serve command asks for two nodes and 32 GPUs.

Does MiMo-V2.6 run on your Mac?

Yes for the Distill, no for the flagship. Every size below was read from the Hugging Face API on 24 September 2026, and every Mac verdict follows the same usable-memory rule our recommender applies across the catalog.

The Distill is the only member with an official ggml-org conversion, the only one with vision support published as a separate projector, and the only one we could actually run. Everything else in this article is about getting that 9B onto the machine you already own.

The 9B "Distill" is a Qwen3.5-9B fine-tune, and the file says so

Xiaomi is explicit in the model card: the checkpoint is Qwen3.5-9B trained on MiMo-generated data, covering coding, general agent tasks, visual coding and cybersecurity, released "as a starting point for open research in agentic reinforcement learning." The GGUF metadata agrees. The official Q8_0 carries general.architecture = qwen35, qwen35.block_count = 32, qwen35.attention.head_count_kv = 4, and general.base_model.0.name = Qwen3.5 9B (model card, 2026).

That matters for two practical reasons. First, llama.cpp did not need a new architecture to run it: the runtime reads it as its existing qwen35 path. Second, quantization recipes transfer, which is why mlx-community's OptiQ build states it reused the layer allocation from its Qwen3.5-9B pack, tensor for tensor, all 250 matched.

The architecture is the current hybrid: 32 blocks, 8 of them full attention (every fourth block) and 24 linear attention, 16 query heads against 4 KV heads at a key and value length of 256. Context is 262144 tokens, so 256K, not the 1M the flagship cards advertise; the 1M figure belongs to Pro and Flash, whose cards list it under Model Summary. Modalities are text, image and video: the config carries image and video token ids and a 27-layer vision tower, but no audio encoder, so the 9B drops the audio input the bigger two keep.

The honest framing on quality: this is an SFT checkpoint whose evaluation table is Xiaomi's, reported from the MiMo-V2.6 technical report, and we found no third-party reproduction of those numbers. On SWE Verified (avg@3) the card puts the Distill at 61.1 against 60.0 for Qwen3.5-9B, on SWE Pro at 44.6 against 32.0, on Terminal Bench 2.1 at 37.1 against 27.0 and on OfficeQA at 19.5 against 9.0. Those are modest-to-real gains on an agentic benchmark suite, all vendor-reported. If you want the local coding picture with third-party rankings, our Qwen3.6 and Gemma 4 coder roundup is the place to start.

Which Mac runs which MiMo-V2.6 build

The budget column is our own arithmetic, not a vendor number. We ramp the usable share of unified memory from 70 percent at 32GB and below to 85 percent at 128GB and above, which leaves room for macOS, the KV cache and your apps. The reasoning behind the rule is in how much VRAM an LLM needs.

The 64GB row is the interesting one for this family, and it is the tier we call the 64GB dead zone: 48 GiB of budget is enormous for a 9B model and simultaneously not enough for the next MiMo up. If you are buying memory for this family specifically, everything above 32GB buys you context and quant headroom for the Distill, not access to Flash.

Every published quantization of the Distill, by the byte

We recomputed the sizes below from the Hub blob API on 24 September 2026, so the byte counts are exact rather than rounded by anyone's model card. Binary figures are what macOS and Activity Monitor will show you.

MLX users have one first-party-ish option: mlx-community's OptiQ-4bit pack, whose two weight shards total 7.10 GB (6.61 GiB) and whose full repository, tokenizer included, is 7.12 GB. Its card states "6.77 GB on disk," which our own sum of the shards does not reproduce. Note also what that card does not claim: the Capability Score was not run for this model, and the published Qwen3.5-9B scores belong to the parent, not to this quant.

For a 16GB Mac, the meaningful band is 5.83 to 8.11 GB: IQ4_NL or Q4_K_M if you want context, Q6_K_L if you want the largest quant that still leaves a real working set. Our 16GB Mac guide covers the rest of that tier.

We loaded the official Q8_0 on a 16GB M4

Claims about "it works with llama.cpp" are cheap, so we ran it. The numbers below are from one machine, and we are stating the setup because it constrains what the numbers mean.

• Machine: MacBook Pro, Mac16,1, Apple M4, 16GB unified memory.
• Runtime: llama.cpp b11149 macOS arm64 binaries, reported as 0.5.0-dev (build 11149, commit d2e54583c).
• Files: MiMo-V2.6-Distill-Qwen-9B-Q8_0.gguf (9,527,498,048 bytes) and mmproj-MiMo-V2.6-Distill-Qwen-9B-Q8_0.gguf (624,229,728 bytes), both verified against the Hub SHA-256 values (de6dae10... and 4b77e812...).
• Backend: Metal, confirmed by the runtime log (GPU name: MTL0 (Apple M4), libraries compiled and loaded from embedded data, backend reported as MTL,BLAS).

Results with the language model alone, full offload (-ngl 99), 4096-token context:

Then the same prompt with the vision projector attached. The runtime reported modalities: text, vision, video and the projector loaded, but throughput collapsed to 0.1 t/s generation and 0.2 t/s prompt, in two separate runs, against 6.0 to 6.3 t/s for the identical prompt without it. The likely cause is the memory ceiling rather than the vision code path: the same log reports recommendedMaxWorkingSetSize = 12713.12 MB, about 12.4 GiB of GPU-wired memory on a 16GB machine, and 8.87 GiB of weights plus 0.58 GiB of projector plus the compute buffers leaves very little before macOS starts paging. One caveat we owe you: this test machine was already under memory pressure before the run (about 19 GB of a 20 GB swap file in use), so treat the 0.1 t/s figure as a symptom of a 16GB Mac at its limit, not as a fixed performance number. The direction is not in doubt, the magnitude may be.

The practical reading for a 16GB machine: run the Q8_0 text-only, or step down to a 5.83 to 6.88 GB quant if you want the vision projector. If your work is long agentic runs on 16GB, a smaller quant with context headroom beats the largest quant that technically loads, the same trade-off we described for Qwen3.8-27B on a Mac.

For MTP supporters, one correction to the launch chatter: the Distill has a single MTP layer in its config (mtp_num_hidden_layers: 1) and no MTP tensors in the converted GGUF at all (we parsed the file: 427 tensors, 424 of them blk.*, none matching MTP). ggml-org published no MTP drafter for the 9B, so there is nothing to point a speculative-decoding flag at. The MTP files ggml-org did convert, mtp-MiMo-V2.6-Flash-RL-Q8_0.gguf at 2.38 GB among them, belong to the Flash repository. We did not verify MTP drafting on the 9B, and we found no primary source claiming it works.

Why Flash and Pro are cluster territory

MiMo-V2.6-Flash-RL is 309B total parameters with 15B activated, 48 layers, 256 routed experts of which 8 fire per token, FP8 weights in per-expert shards. It ships as 90 files totalling 177.77 GB, plus a 2.94 GB DFlash drafter and a 1.19 GB MTP model. The smallest GGUF we can measure for it is not from ggml-org: AesSedai's BPW2.0 build is 71.94 GB across three shards, and their IQ2_S is 114.15 GB. The smallest ggml-org build is Q2_K, which is a two-shard checkpoint, 5,948,608 bytes of shard metadata plus a 125,711,620,192-byte second shard, for 125.72 GB (117.08 GiB) in total; their MXFP4 build is 167.37 GB. A 96GB Mac Studio has 76.8 GiB of budget, so the 67.00 GiB BPW2.0 build is the only one that fits any Mac at all, and it is a third-party quant with no published Metal verification. Xiaomi's own instructions for this model start at --tp 8 --dp 2 on SGLang, which is 16 GPUs, or 4-way tensor parallelism on vLLM.

MiMo-V2.6-Pro-RL is 1.02T total parameters with 42B activated, 70 layers, 384 routed experts, and its repository is 573.49 GB (534.11 GiB) in 155 files. Add the 5.54 GB DFlash drafter and the 2.46 GB MTP model if you want the full recipe. The smallest build anyone has published is mlx-community's mxfp4-q8 pack at 553.89 GB (515.85 GiB), and the 512GB Mac Studio, the largest configuration in the announced lineup, has about 435.2 GiB of usable budget. Xiaomi serves it with --tp 16 --dp 2 across two nodes. There is no configuration of a Mac that runs Pro-RL, and there is no fork, quant or trick that changes that arithmetic.

Both models also take image, video and audio input at 1M tokens of context, which is exactly the workload a cluster is for. On a Mac, the realistic sub-1M-parameter option in this release is the Distill, and the interesting comparison is not against Flash but against the other 9B models your machine can hold.

What you actually need to install

llama.cpp added MiMo-V2.6 conversion support in the v0.5.0 release on 23 September 2026 (#29257, listed as "Add MiMo-V2.6 conversion support"), which is what produced the official ggml-org GGUF. Any build from that release or later loads the file, and we confirmed it on b11149 with the Metal backend.

# What we ran: the verified 9.53 GB official file, text only
llama-cli -m MiMo-V2.6-Distill-Qwen-9B-Q8_0.gguf -ngl 99 -c 32768

# The same file plus the vision projector, which is what pushes a 16GB Mac over
llama-cli -m MiMo-V2.6-Distill-Qwen-9B-Q8_0.gguf --mmproj mmproj-MiMo-V2.6-Distill-Qwen-9B-Q8_0.gguf -ngl 99 -c 32768

# Or let llama.cpp fetch everything from the Hub, the way the ggml-org README shows it
llama serve -hf ggml-org/MiMo-V2.6-Distill-Qwen-9B-GGUF

One practical warning from the official repository: its README notes that the conversion applies an interim chat template patch and that the patch should be removed once the upstream template is fixed. The patched template worked in our test, but if you see empty or malformed chat output after a future runtime update, that note is the first thing to read.

FAQ

Does MiMo-V2.6-Distill-Qwen-9B run on a 16GB Mac?

Yes, at 5.83 to 8.11 GB for the quants we would recommend (IQ4_NL through Q6_K_L), or at the official 9.53 GB Q8_0 if you accept a tight working set. We loaded the official Q8_0 on a 16GB M4 with the Metal backend and measured 66.78 t/s prompt and 6.04 t/s generation at a 4096-token context. Adding the 0.62 GB vision projector on the same machine dropped generation to 0.1 t/s, so on 16GB either skip the projector or step down a quant.

Is MiMo-V2.6 in Ollama yet?

No. On 24 September 2026, ollama.com/library/mimo and ollama.com/library/mimo-v2.6 both return 404 and a site search for "mimo" returns no model entry. Until a library tag appears, use llama.cpp directly or a GGUF loader built on it.

Can a Mac Studio run MiMo-V2.6-Flash-RL or Pro-RL?

Pro-RL, no: its weights are 534.11 GiB and the 512GB Mac Studio has about 435.2 GiB of usable budget. Flash-RL is a maybe on paper: the smallest published quant is 67.00 GiB, which fits a 96GB Mac Studio's 76.8 GiB, but no one has published a verified Metal run of it, and Xiaomi's reference deployment is 8-way tensor parallel across 2 data-parallel replicas.

Does the 9B have the 1M-token context the family advertises?

No. The 1M-token figure belongs to the Pro and Flash model cards. The Distill's config and its GGUF metadata both state max_position_embeddings and context_length of 262144, so 256K. That is still far more than a 16GB machine can pair with a large quant.

Is anything in the family not really from Xiaomi?

Two of the files we cite are third-party. The ggml-org conversion is an automated ggml-org build of the Xiaomi checkpoint, the mlx-community OptiQ pack is an mlx-optiq output, and the Flash BPW2.0 and IQ2_S GGUFs are a community quantization. On licensing, the three Xiaomi repositories declare MIT, the ggml-org GGUF is tagged MIT, and bartowski's repository carries no license field in its Hub metadata as of 24 September 2026. The base checkpoint is MIT, so downstream quants inherit that, but a quant is not a Xiaomi release and its quality is its author's claim.

Every figure here comes from a primary source we opened ourselves, and the memory table is our arithmetic, labelled as such. Found an error? Contact us: our editorial standards are on the about page.

• XiaomiMiMo/MiMo-V2.6-Distill-Qwen-9B and its config.json: base model, MIT license, 32 blocks, 8 full-attention blocks, context length 262144, vision and video token ids, single MTP layer, no audio encoder.
• XiaomiMiMo/MiMo-V2.6-Pro-RL and MiMo-V2.6-Flash-RL model cards: 1.02T total and 42B activated for Pro, 309B and 15B for Flash, 1M context, MTP drafter, and the SGLang and vLLM serve commands quoted above.
• Hugging Face API with ?blobs=true for Pro-RL, Flash-RL, the Distill, the ggml-org GGUF, the ggml-org Flash GGUF, the bartowski GGUF, the AesSedai Flash GGUF and the mlx-community OptiQ pack: every byte count in this article, read 24 September 2026.
• ggml-org/llama.cpp v0.5.0 release notes: MiMo-V2.6 conversion support, published 23 September 2026.
• ggml-org llama.cpp release b11149: the macOS arm64 binaries used for our run, reporting version 0.5.0-dev, build 11149.
• ggml-org/MiMo-V2.6-Distill-Qwen-9B-GGUF README: the Q8_0 mmproj note and the interim chat template patch warning.
• bartowski OptiQ card: the transferred layer allocation, the 250 matched tensors, the "not run" Capability Score and the 6.77 GB on-disk claim.