Mistral Large 4 on a Mac: 233GB Smallest, 512GB Studio Only

Mistral published the weights of Le Chonk, its 1-trillion-parameter mixture-of-experts, on 29 October 2026, and the Mac answer is a hard yes or no. The smallest build anyone has published is 233.010GB, the smallest official ggml-org build is 297.676GB, and no Mac with 16GB to 192GB of unified memory holds either one. Only the 512GB Mac Studio M5 Ultra gets in, and that is before a single token of context.

TL;DR: Mistral Large 4 is a 1T-parameter MoE that activates 49B parameters per token. The Mac floor is a 512GB Mac Studio M5 Ultra: the official IQ2_XXS GGUF is 297.676GB and the smallest third-party build is 233.010GB. Every Mac from 16GB to 192GB is out, a 256GB Mac Studio is out once the draft head, the projector and the cache are counted, and the only builds that fit a Mac at all are 1-bit and 2-bit, the class we never rank. llama.cpp support landed on 29 October and is not in the latest tagged release yet.

Will Mistral Large 4 run on your Mac? The short answer

No Mac below 512GB of unified memory can load it, and the gap is not close. Unified memory is the single pool an Apple Silicon Mac shares between the CPU and the GPU, so a Mac either holds the whole model or it does not run it. A 128GB MacBook Pro is 105GB short of the smallest file that exists. No offload trick closes a gap that size: the weights have to be resident, and quantization below 1 bit is not a thing you can download.

The 256GB tier is the one that deserves an argument rather than a subtraction, because Unsloth's own run guide says the 233GB 1-bit quant "should fit on 256GB RAM including a Mac Studio" (Unsloth). We still do not count it, and the arithmetic is why. Our convention for a 256GB Mac Studio M5 Ultra is roughly 218GB usable for models (Mac Studio M5 Ultra 256GB), so the 233.010GB file alone is about 15GB over before a single token of context. Add the 2.246GB Q8_0 DSpark draft head and the 3.409GB F16 vision projector from the same repository and the working set is 238.665GB, inside a 256GB pool that macOS, the KV cache and the runtime buffers also need. Unsloth's own guidance is that unified memory "should exceed the quant's file size with room for the operating system, KV cache and runtime buffers". On a 256GB Mac there is no such room.

The second reason is quality. The only builds that fit any Mac are 1-bit and 2-bit conversions, which is exactly the class we list but never rank: why we never recommend 2-bit quants is our long version of that call. If your plan was a frontier 1T model on a laptop, the honest answer is that this is a 512GB Mac Studio model, and it is a 1-bit or 2-bit Mac Studio model.

What Mistral actually released on 29 October

Mistral Large 4 is the model Mistral announced in public preview earlier in October, and the weights landed at the end of the month. The blog post that accompanies the release carries a publication timestamp of 29 October 2026, 12:00 UTC (Mistral), and the Hugging Face repository's own history dates its "Initial release" commit to 2026-10-29T14:11:16Z (Hugging Face commits API). The official ggml-org GGUF conversion was already in place the day before, created 2026-10-28T12:07:36Z (ggml-org).

What is in the checkpoint, from the model card and the published config (mistralai):

• Mixture-of-experts: 1 trillion total parameters, 49B active per token, 52B including the embeddings and the output layers.
• 72 hidden layers, 128 routed experts with 4 active per token, plus 1 shared expert.
• Context window: 1,048,576 tokens, with a vocabulary of 204,800.
• Multimodal input: a Pixtral-style vision encoder takes text and images, text out.
• DSpark draft head: 3 MLA layers that propose 3 tokens at a time from the target model's hidden states, over a 2,048-token sliding window (ggml-org NVFP4 card).
• FP8 source: the released checkpoint is block-scaled FP8 with 128x128 blocks, 1,060.555GB across 54 safetensors shards (Hugging Face blobs API).

Two terms explain the shape of everything below. Mixture-of-experts (MoE) is an architecture that routes each token to a few experts out of many, so the memory bill follows the 1 trillion total parameters while the compute bill follows the 49B active ones. Quantization is the act of storing those weights at fewer bits per value, and every build under the FP8 source is a different point on that trade.

Mistral reports frontier-class coding and security numbers for it: 48% on the Artificial Analysis Coding Agent Index, effectively tied with GLM-5.3 while using 47% fewer tokens per task, and 26 on the Artificial Analysis Intelligence Index v5 (model card). None of that changes the memory picture, which is the part that decides whether you can run it at all.

Every build, and the real file size

Every size below is the sum of that build's own weight shards in decimal GB, read from the Hugging Face blobs API on 30 October 2026. Quant cards round these numbers, so both are shown where they differ.

Sizes come from the repository file listings: mistralai, ggml-org GGUF, ggml-org NVFP4, unsloth and mlx-community 2-bit. The two smallest builds are worth separating, because they are constantly confused: 233.010GB is Unsloth's UD-IQ1_S, a third-party 1-bit conversion, while the smallest official ggml-org build is IQ2_XXS at 297.676GB.

What actually fits the 512GB Mac Studio

The 512GB Mac Studio M5 Ultra does not hand you 512GB for a model. macOS and the system take their share, and the number we use for that machine is roughly 435GB usable for weights (Mac Studio M5 Ultra 512GB), which is the same convention the rest of our Mac guides use.

Against 435GB, the Mac verdict per build is straightforward:

• IQ2_XXS at 297.676GB: fits, and with the F16 vision projector added (3.409GB) it still leaves a wide margin.
• Q2_K at 380.706GB: fits, which is exactly what the ggml-org card claims when it annotates that build "Fits in 512 GB of unified memory".
• MLX 2-bit at 338.132GB: fits, and it is the one MLX build that does.
• MLX 3-bit at 459.251GB and MLX 4-bit at 590.408GB: do not fit. The 4-bit card says so in as many words, and recommends pipeline parallelism across two Macs instead.
• Q4_K_M at 634.802GB, Q8_0 at 1,115.150GB, BF16 at 2,098.861GB: do not fit any single Mac that exists.

For example, the 3-bit MLX conversion at 459.251GB sits about 24GB over the roughly 435GB usable figure, and the 4-bit at 590.408GB sits 155GB over it. Neither fits one Mac on that arithmetic.

One caveat that matters more than it looks: the MLX conversions are text-only. The vision encoder and the DSpark draft head are not in them, so if you want image input or the speculative decoding speedup on a Mac Studio, the ggml-org GGUF route is the one that carries both. For the general memory maths behind these tiers, the how much VRAM for LLMs guide covers the same ground for GPUs and unified memory.

What the 1M context costs on a Mac

The card markets a 1M-token context, and the number to plan with is smaller than that, because the cache has to live in the same pool as the weights. KV cache is the per-token state attention keeps for the text you have already sent. This model is the cheapest case in the 1T class to reason about, because it does not keep a dense one: llama.cpp stores one MLA-style key per position per cache-owning layer, plus a single indexer key head per layer (llama.cpp).

Read the published config and the cache is small by 1T standards. Of the 72 layers, 63 keep their own MLA entry (512 latent values plus 64 RoPE values per position), and 44 keep their own indexer key (128 values per position). That is 41,920 values per token, or about 82 KB per token at fp16, our calculation from the published config. Rounded, that is roughly 11GB of cache for 128K tokens, 44GB for 512K, and 88GB for the full 1M window.

So the context window is a budget decision rather than a wall, and only on the 512GB machine. With IQ2_XXS (297.676GB) plus the F16 projector (3.409GB) inside 435GB, you have room for a long context and the runtime buffers, and you can raise the macOS wired-memory limit to claim it. On any Mac below 512GB the weights alone consume the pool, and the context discussion never starts.

Which build of llama.cpp loads it

Not the one you probably have installed. Support for the architecture arrived in llama.cpp on 29 October 2026 in commit 78feec062d, "model: mistral le chonk" (llama.cpp), which adds the mistral-large4 architecture and the DSpark draft head. As of 30 October that support is in master and in none of the tagged builds. The conversion/mistral4.py module and the MISTRAL_LARGE4 architecture constant are absent from the v0.8.0 tree (28 October 2026) and from the b11988 build (29 October 2026, 20:53 UTC) that the release feed lists. A stock download from those tags gives you a binary that does not know the architecture.

The command itself is the one on the official card:

llama serve -hf ggml-org/Mistral-Large-4-1T-A52B-GGUF:IQ2_XXS

If you run Unsloth's build instead, their card documents the extra flags: -md dspark-Mistral-Large-4-1T-A52B-Q8_0.gguf --spec-type draft-dspark --spec-draft-n-max 3 for speculative decoding, and --mmproj mmproj-BF16.gguf for vision (Unsloth).

Ollama is not an option for local inference today. Its library page lists a single tag, mistral-large-4:cloud, priced at $0.70 input, $0.07 cached input and $2.10 output per million tokens, with no local pull available (Ollama). If a local tag appears, the install advice changes; the size table above does not.

The license, in one paragraph

The weights ship under the Mistral Ecosystem Open-Weight License, which the LICENSE file describes as "a modified version of the MIT license" and the blog calls a modified MIT license. For a Mac owner it reads as MIT with one clause that matters. Use, modification, distribution, sublicensing and sale are permitted, but "if the Licensee or any of its affiliates operates a Model as a Service business, the Licensee must enter into a separate commercial license with Mistral" before commercial use. The license defines Model as a Service as giving a third party access to the model for inference or post-training in a way that lets them control inputs, parameters or training data. It carves out end-user products where the model is embedded in a feature, plus pure relaying of requests to someone else's hosted model. Internal use and use through Mistral's own products are exempt (LICENSE). Running it at home or inside your own company changes nothing; reselling the endpoint is the case that needs a signature.

What to run on your Mac instead

If the answer above is no, the useful move is to match a model to the memory you already have. The 512GB Mac Studio is covered build by build in Mac Studio M5 Ultra 512GB local LLM. The two closest large-model cases are GLM-5.3 VRAM requirements, where a 753B MoE starts at 217GB, and Mistral Small VRAM requirements, where the same family's 22B model loads at about 17GB and fits a 24GB machine. Between those two extremes there is a wide middle, and the how much VRAM for LLMs guide maps it by memory tier.

FAQ

Does Mistral Large 4 fit in 128GB of unified memory?

No. The smallest published build is Unsloth's UD-IQ1_S at 233.010GB, and the smallest official ggml-org build is IQ2_XXS at 297.676GB. A 128GB Mac is short by 105GB against the smaller of the two, and there is no quantized build below 1 bit to reach for. This is a 512GB Mac Studio model, not a MacBook Pro model.

Is the 233GB build an official Mistral or ggml-org release?

No, and the distinction matters when you compare guides. 233.010GB is Unsloth's UD-IQ1_S, a third-party dynamic 1-bit conversion. The official ggml-org repository's smallest build is IQ2_XXS at 297.676GB, which its card annotates "Fits in 512 GB of unified memory". Any claim that Mistral's own 2-bit is 233GB is reading the third-party table.

Can a 256GB Mac Studio run it?

Only the 1-bit build fits the pool on paper, and we do not count it as a working setup. Unsloth's guide says the 233GB quant should fit a 256GB machine, but our convention for that Mac is roughly 218GB usable for models, so the file alone is over it. With the Q8_0 DSpark draft head (2.246GB) and the F16 vision projector (3.409GB) the working set is 238.665GB before macOS, the KV cache and the runtime buffers. 512GB is the first Mac class where the model, the context and the buffers coexist.

Will it run in Ollama?

Not locally. Ollama's library page lists one tag, mistral-large-4:cloud, which runs on Mistral's servers rather than yours. Local inference means llama.cpp or MLX, and for llama.cpp it means a build newer than the latest tagged release, because the mistral-large4 architecture landed in commit 78feec062d on 29 October 2026.

How much context can a 512GB Mac Studio actually use?

More than a dense 1T model would allow. The MLA and single-head indexer cache keeps the per-token cost near 82 KB at fp16 by our calculation from the published config: roughly 11GB of cache at 128K tokens, 44GB at 512K and 88GB at the full 1M window. With IQ2_XXS at 297.676GB inside the roughly 435GB usable on that machine, a long context fits alongside the weights. On anything smaller, the weights decide the answer first.

Every size in this article is the sum of a build's own weight shards, read from the Hugging Face blobs API on 30 October 2026, and the context budget is our arithmetic on the published config, labelled as such. Found an error? Contact us: our editorial standards are on the about page.

Sources

• Mistral Large 4 release post, dated 29 October 2026: https://mistral.ai/news/mistral-large-4-oss/
• Mistral Large 4 model card, specifications, benchmarks and sampling settings: https://huggingface.co/mistralai/Mistral-Large-4-1T-A52B
• Mistral Large 4 repository file listing with per-shard sizes (1,060.555GB across 54 shards): https://huggingface.co/api/models/mistralai/Mistral-Large-4-1T-A52B?blobs=true
• Mistral Large 4 commit history, Initial release at 2026-10-29T14:11:16Z: https://huggingface.co/api/models/mistralai/Mistral-Large-4-1T-A52B/commits/main
• Published config, cache-owning layers and indexer parameters: https://huggingface.co/mistralai/Mistral-Large-4-1T-A52B/raw/main/config.json
• Mistral Ecosystem Open-Weight License text: https://huggingface.co/mistralai/Mistral-Large-4-1T-A52B/blob/main/LICENSE
• ggml-org GGUF repository, quant table and the 512GB annotations: https://huggingface.co/ggml-org/Mistral-Large-4-1T-A52B-GGUF
• ggml-org GGUF file listing with per-shard sizes: https://huggingface.co/api/models/ggml-org/Mistral-Large-4-1T-A52B-GGUF?blobs=true
• ggml-org NVFP4 GGUF, DSpark draft head description: https://huggingface.co/ggml-org/Mistral-Large-4-1T-A52B-NVFP4-GGUF
• ggml-org NVFP4 file listing: https://huggingface.co/api/models/ggml-org/Mistral-Large-4-1T-A52B-NVFP4-GGUF?blobs=true
• Unsloth GGUF repository, speculative decoding and vision flags: https://huggingface.co/unsloth/Mistral-Large-4-1T-A52B-GGUF
• Unsloth GGUF file listing, UD-IQ1_S at 233.010GB: https://huggingface.co/api/models/unsloth/Mistral-Large-4-1T-A52B-GGUF?blobs=true
• Unsloth run guide, memory bands and the 256GB note: https://unsloth.ai/docs/models/mistral-large-4
• mlx-community 2-bit conversion, about 338GB peak memory: https://huggingface.co/mlx-community/Mistral-Large-4-1T-A52B-Text-2bit
• mlx-community 3-bit conversion, about 459GB peak memory: https://huggingface.co/mlx-community/Mistral-Large-4-1T-A52B-Text-3bit
• mlx-community 4-bit conversion, does not fit one 512GB Mac: https://huggingface.co/mlx-community/Mistral-Large-4-1T-A52B-Text-4bit
• llama.cpp commit 78feec062d, "model: mistral le chonk": https://github.com/ggml-org/llama.cpp/commit/78feec062d
• llama.cpp DSA cache implementation, MLA key plus single indexer head: https://github.com/ggml-org/llama.cpp/blob/master/src/llama-kv-cache-dsa.cpp
• llama.cpp v0.8.0 release, 28 October 2026: https://github.com/ggml-org/llama.cpp/releases/tag/v0.8.0
• Ollama library entry, cloud tag only: https://ollama.com/library/mistral-large-4