Xiaomi MiMo-V2.6 on a Mac: 9B Fits 16GB, Flash Needs 256GB

Xiaomi MiMo published the MiMo-V2.6 family on 21 September 2026 under the MIT license, and exactly one of its three checkpoints is an everyday Mac model. MiMo-V2.6-Distill-Qwen-9B is a supervised fine-tune of Qwen3.5-9B, and its official ggml-org Q8_0 conversion is listed at 9,527,498,048 bytes by the raw Hugging Face model API. We downloaded that official file, checked its SHA-256 against the Hub, and loaded it on a 16GB M4. The other two checkpoints are a different story: Flash-RL needs a 256GB Mac Studio in practice, and Xiaomi's own serve command for Pro-RL asks for two nodes and 32 GPUs.

Updated 1 October 2026. What changed since launch week:

• Still no Ollama tag. ollama.com/library/mimo returns 404 on 1 October 2026, so the 9B still runs through llama.cpp, LM Studio or MLX, not ollama run.
• Xiaomi shipped MOPD upgrades of Flash and Pro on 27 September. MiMo-V2.6-Flash-MOPD and Pro-MOPD keep the same size and architecture and target a tool-call repetition problem in agent runs. There is no MOPD version of the 9B Distill.
• The first published Flash-RL run on a Mac. A community MLX 4-bit build runs on a 256GB M3 Ultra Mac Studio at 59.4 tok/s of sustained generation, with 164.3 GB of peak unified memory, per Vontra's model card.
• Pro now fits a 512GB Mac Studio, on paper only. Community GGUF builds of Pro-MOPD start at 255,788,448,096 bytes, under the 512GB tier's budget. The smallest one costs a lot of quality, as we detail below.

Does MiMo-V2.6 run on your Mac?

Yes for the Distill on any 16GB Mac, yes for Flash on a 256GB Mac Studio, and only on paper for Pro. Every size below was read from the Hugging Face API, first on 24 September 2026 and again on 1 October 2026, and every Mac verdict follows the same usable-memory rule our recommender applies across the catalog.

The Distill is the only member that runs on the Mac you probably own, and the only one we ran ourselves. Most of this article is about getting that 9B onto your machine; the Flash and Pro sections cover what a Mac Studio can and cannot do.

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 from 32GB to 64GB buys you context and quant headroom for the Distill, not access to Flash. Flash starts to make sense at 128GB, and runs well only at 256GB.

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

Since launch week, one community repository has filled that gap. VitreousCut's MTP GGUF trains its own draft head and merges it into Q4_K_M and Q5_K_M files of 6,099,608,064 and 6,726,525,504 bytes, both comfortable on a 16GB Mac. Two caveats before you chase the speedup. The --spec-type draft-mtp flag needs the prism fork of llama.cpp, not a stock build. And the repository's own numbers come from an RTX 4090, not a Mac: 85.1 percent draft acceptance on repetitive greedy output, but 38.0 percent on sampled text, where the gain shrinks to a small fraction. Nobody has published a Mac measurement yet.

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. Its MOPD upgrade, published on 27 September, has the same architecture and the same file layout.

The smallest GGUF we can verify today is not from ggml-org: AesSedai's BPW2.0 build of Flash-MOPD totals 77,395,741,280 bytes across three shards, according to its raw Hugging Face model API. The launch-week Flash-RL build from the same author is no longer publicly reachable. The smallest ggml-org build is Q2_K, a two-shard checkpoint totalling 126,214,593,856 bytes, and their MXFP4 build is larger still.

The Mac that actually runs Flash is a 256GB Mac Studio. Vontra's MLX conversion keeps the model's native MXFP4 experts, averages 4.257 bits per weight, and on a 256GB M3 Ultra sustains 59.4 tok/s of decode with 164.3 GB of peak unified memory, per the repository's own measurements. That card is explicit about the limits: current MLX tooling runs the text model only, not MiMo's MTP, DFlash, vision or audio paths. For multimodal and drafting, Xiaomi's own instructions still 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. Xiaomi serves it with --tp 16 --dp 2 across two nodes. At launch, the smallest build anyone had published was mlx-community's mxfp4-q8 pack at 553.89 GB (515.85 GiB), too large for any Mac.

That changed on 30 September. AesSedai's BPW2.0 build of Pro-MOPD is 255,788,448,096 bytes, about 238 GiB, which fits under the 512GB Mac Studio's budget of about 435 GiB. The catch is in the quantizer's own table: at 2 bits per weight, perplexity rises by about 44 percent over the full-quality build. The BPW3.5 build keeps that loss to about 3 percent, but at about 417 GiB it leaves under 20 GiB of the same budget for context. Treat Pro on a Mac as an experiment for a 512GB owner, not a recommendation; nobody has published a Mac run of any of these builds.

Both models also take image, video and audio input at 1M tokens of context, which is exactly the workload a cluster is for. On the Mac most people own, the realistic 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 1 October 2026, ollama.com/library/mimo and ollama.com/library/mimo-v2.6 both still return 404, as they did at launch. Until a library tag appears, use llama.cpp directly or a GGUF loader built on it. The model alert form on this page emails you when a better model than your current pick fits your exact Mac.

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

Flash, yes, on a 256GB Mac Studio: a community MLX 4-bit build has a published run on a 256GB M3 Ultra at 59.4 tok/s, text only. On 96GB and 128GB it fits on paper as a 2-bit GGUF, with no published run. Pro only fits a 512GB Mac Studio, as a 2-bit to 3.5-bit community GGUF, and nobody has published a Mac run of it.

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?

Several 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 and Pro BPW GGUFs, the Flash MLX 4-bit build and the 9B MTP GGUF are community work. On licensing, the 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 1 October 2026. The base checkpoint is MIT, so downstream quants inherit that, but a quant is not a Xiaomi release and its quality and speed figures are its author's claims.

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-MOPD GGUF, the AesSedai Pro-MOPD GGUF, the VitreousCut MTP GGUF and the mlx-community OptiQ pack: every byte count in this article, read 24 September 2026 and rechecked 1 October 2026.
• XiaomiMiMo/MiMo-V2.6-Flash-MOPD and MiMo-V2.6-Pro-MOPD model cards: the MOPD upgrade of both checkpoints, same architecture, tool-call repetition fix, published 27 September 2026.
• AesSedai MiMo-V2.6-Pro-MOPD-GGUF card and Flash-MOPD-GGUF card: BPW build sizes and the perplexity change of each build against the full-quality one.
• Vontra MiMo-V2.6-Flash-RL MLX 4-bit MTP card: 4.257 bits per weight, 256GB M3 Ultra run, 59.4 tok/s sustained generation, 164.3 GB peak unified memory, text path only.
• VitreousCut MiMo-V2.6-Distill-Qwen-9B-MTP-GGUF card: trained MTP draft head, prism fork requirement, RTX 4090 acceptance figures.
• 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.