Mac Studio M5 Ultra with 512 GB: which frontier open-weight MoE models actually fit (and how fast)

A single 512 GB Mac Studio M5 Ultra holds GLM-5.3 at 3-bit or IQ4_XS (343–365 GB files, tight), GLM-5.3-Flash at 6-bit, Meta's Muse Spark Open at 2-bit and DeepSeek V4.1-Flash in a 2-bit MLX build, even at macOS's default GPU limit. Out of the box the GPU may use only about 75% of memory (about 384 GB). Muse at 3-bit (401 GB), MiMo-V2.6-Pro at Q2_K and DeepSeek V4.1-Flash at 4-bit load only after you raise that limit. Kimi K3, DeepSeek V4-Pro and Qwen3.8-2.4T do not fit at a usable quant. They need two Macs or rented GPUs. Reflection Beam is not in the analyzer yet; its NVFP4 weights are 293.63 GB. By my arithmetic, 400 GB-class MoEs should decode at roughly 15–30 tokens/s. Long prompts are still slow to process.

Check your own model, quant and context in the analyzer. The fit verdicts on this page come from the analyzer, not from me.

This page contains affiliate links.

What Apple actually ships: M5 Ultra and M5 Max specs

The Mac Studio with the M5 Max or M5 Ultra was announced on 25 August 2026, and it shipped from 22 September. The two sources disagree on the 512 GB configuration. Apple's newsroom post still says "Mac Studio with 512GB of unified memory is coming in late October", and Apple's spec page lists 512 GB as an M5 Ultra option. MacStories wrote on 15 October that the 512 GB model "is slated for release at the end of the year". Check that it is orderable before you plan around it.

Sources: Apple's spec page, Apple Newsroom, Macworld and BGR. Apple claims "up to 4x faster" LLM prompt processing than the M3 Ultra in LM Studio (vendor-reported, July 2026 tests).

The 512 GB configuration has no product card here yet. The card below is the 256 GB M5 Ultra, with its current price.

How much of 512 GB can the GPU really use?

On Apple Silicon, the GPU can wire about 75% of unified memory by default. On a 512 GB Mac that is about 384 GB, which is not enough for any of the 400 GB quants below. You raise the cap with one command:

sysctl iogpu.wired_limit_mb                  # 0 = default (~75%)
sudo sysctl iogpu.wired_limit_mb=483328      # ~472 GB on a 512 GB Mac

The mlx-lm docs give the same rule: set the limit above the model size but below total memory. Three warnings:

• It resets on reboot. You can make it permanent through /etc/sysctl.conf, but that may require disabling SIP.
• Apple does not support it. Leave headroom for macOS: 8–16 GB at minimum on smaller Macs. Pinggy suggests 32–64 GB on a 512 GB box.
• Watch Memory Pressure. If it goes yellow or red, or the Mac starts swapping, lower the cap.

My working limits (my arithmetic, the analyzer is the authority):

There are step-by-step screenshots in my Metal VRAM limit guide.

Which open-weight MoE models exist right now (Oct 2026)

I only counted a model if its weights are downloadable from Hugging Face today. Parameters and licences come from the model cards.

Beam was announced on 5 October and its weights went public on 16 October. Why active parameters matter more than total: see my MoE models guide.

The fit table: model × memory tier

Each cell gives a quant, its file size, and the analyzer's verdict. The analyzer adds the KV cache at the stated context (32k unless marked) and framework overhead to the file.

• Fits / tight / does not fit … unified: against macOS's default GPU limit (75% of memory).
• Fits / tight / does not fit 472, 232 or 116 GB: against a raised limit, the middle of the ranges in the table above.
• Raised limit only: it fails at the default limit and loads only after you raise it.

File sizes are decimal GB (bytes ÷ 10⁹), summed from each Hugging Face repo's file list on 20 October 2026. They are Unsloth dynamic GGUFs unless marked MLX, ggml-org or native. Muse's vision projector adds another 4.10 GB if you use images.

No 750B+ model fits on one 512 GB Mac at classic 4-bit, so you choose between 3-bit and dynamic quants such as IQ4_XS. Beam is the exception to check yourself: the analyzer has no record for it yet, so compare its file size plus KV cache with your GPU limit. The 256 GB Mac is for the "Flash" class: GLM-5.3-Flash, gpt-oss-120b and Kolibri-1. On 128 GB, GLM-5.3-Flash loads only at 1–2-bit with the limit raised, so gpt-oss-120b and Kolibri-1 are the comfortable picks.

Context and KV cache: small for these models, but check

These MoEs use compressed or sparse attention, so the KV cache matters far less than it did with Llama-style models.

• DeepSeek V4.1-Flash. The model card gives 890 bytes of global KV per token. That is about 0.11 GB at 128k and under 1 GB at 1M (my arithmetic).
• GLM-5.3. The config shows 78 layers and a compressed latent of 512 + 64 values per layer. At BF16 that is about 88 KiB per token: roughly 2.9 GB at 32k and 11.8 GB at 128k (my arithmetic from the config). This assumes the runtime caches the latent and does not expand it to full heads.
• MiMo-V2.6-Pro. 60 of its 70 layers use a 128-token sliding window, so only 10 layers grow with context.
• Beam and Muse. Beam uses gated GQA with sliding windows. Meta has not published Muse's attention layout. Use the KV cache calculator for these rather than guessing.

KV quantisation buys more headroom:

• llama.cpp: --cache-type-k q8_0 --cache-type-v q8_0, paired with flash attention. The llama.cpp authors found q8_0 has "no significant quality loss". K is more sensitive than V.
• MLX: mlx_lm.generate takes --kv-bits 8 and --quantized-kv-start (community-reported, Pinggy), and mlx_lm.server has --quantize-kv-cache (community-reported, Techplained). --max-kv-size gives a rotating cache.

llama.cpp v0.4.0 (4 Sep 2026) added sparse flash attention for DeepSeek-V4 and GLM on Metal. It also turned on the Metal 4 tensor API on M5 chips. Use a current build.

How fast? Every figure, labelled

No one has published a single-Mac test of a 400 GB-class MoE on the M5 Ultra yet, because the 512 GB model is only just arriving. Here is what exists.

Measured on M5 Ultra Measured on M3 Ultra 512 GB (the baseline) My estimate for one 512 GB M5 Ultra. Apple's own M5-over-M3 Ultra decode ratios are 1.56 and 1.58. BGR saw 1.33. The bandwidth ratio is 1.47. Applying 1.3–1.6× to the M3 Ultra numbers gives about 23–28 tok/s for GLM-5.3 at 4-bit-class quants. Kimi-style 1T models would land at about 14–18 tok/s at short context (my arithmetic).

As a sanity check, here is the bandwidth ceiling: bandwidth ÷ bytes read per token. For Muse Q3_K_XL that is 1,200 GB/s ÷ (42.7B active × ~0.49 bytes) ≈ 57 tok/s. GLM-5.3 Q3_K_XL gives about 66 tok/s, and Beam NVFP4 about 88 tok/s. On the M3 Ultra, real decode landed at 25–55% of this ceiling. Treat the ceilings as upper bounds, not forecasts (my arithmetic).

The big caveat is prefill. Macs read weights fast but have less compute for processing the prompt.

• On an M3 Ultra, a 15,777-token prompt to DeepSeek V3 took 227 seconds (community-reported, Hardware Corner).
• A dense Llama 405B took 10.3 minutes to first token at 16K (community-reported, mlx #3209).
• Apple says the M5 Ultra cuts time-to-first-token by up to 4.6× (vendor-reported). Its own Mistral Medium 3.5 test fell from 95.9 s to 24.6 s.

That helps, but agents that resend 50–100k tokens of context will still wait. Prompt caching (mlx_lm.cache_prompt, or llama.cpp slot reuse) is not optional.

Clustering two Macs for the models that don't fit

Clustering uses RDMA over Thunderbolt 5, which arrived in macOS 26.2. Three tools support it today:

The data favours tensor parallelism over RDMA:

• Apple. Two M5 Ultras ran Muse at 24.99 tok/s with tensor parallelism and 15.74 with pipeline (vendor-reported). Pipeline mode keeps decode about the same as one machine. It mainly helps prefill.
• Jeff Geerling. On 4 × M3 Ultra, exo over RDMA took Qwen3 235B from 19.5 tok/s on one node to 31.9 on four. llama.cpp over TCP fell from 20.4 to 15.2 (community-reported, December 2025). That llama.cpp result predates the RDMA transport, so retest before writing llama.cpp off.

Apple's setup uses two Thunderbolt 5 cables per link and the experimental MLX_METAL_FAST_SYNCH=1 flag. Two 512 GB machines give about 940 GB of usable memory. That is enough for Muse NVFP4, MiMo-V2.6-Pro native, and 1-bit Kimi K3. DeepSeek V4-Pro's 850 GB file would be tight. More detail is in my multi-GPU inference guide.

When renting an H200 or B200 is the better choice

Rent instead of buying when any of these is true:

• You need 4-bit or better on a 1T+ model. Kimi K3, DeepSeek V4-Pro and Qwen3.8-2.4T are rack-scale models. Unsloth recommends at least 610 GB of memory even for its 1-bit Kimi K3 UD-IQ1_S.
• Your work is long-context and prefill-heavy. Repo-wide agents and batch document jobs fall into this group. A single B200 runs GLM-5.3-Flash 1-bit at 1,122 tok/s prefill (Unsloth-reported).
• You run it a few hours a month. On-demand H200s at RunPod were listed at $3.59–5.29 per GPU-hour, B200s at $5.98–7.99, and Vast.ai H200s at $3.69–5.05 (single source: computeprices.com, checked 20 Oct 2026). An 8 × H200 node (1,128 GB) at the low RunPod rate is about $29 per hour (my arithmetic).

You can try it on RunPod or Vast.ai:

Rent GPUs on RunPod → Rent GPUs on Vast.ai →

My local vs cloud cost guide does the break-even maths.

My take

The 512 GB M5 Ultra is the first desktop where a GLM-5.3 or Muse Spark Open class model is a normal daily tool. But "fits" means 3-bit or dynamic 4-bit, not classic 4-bit, and often a raised GPU memory limit. For most people the better buy is a 256 GB M5 Ultra running GLM-5.3-Flash at Q4 with the GPU memory limit raised (see the table): MIT-licensed, about 200 GB of weights, 18B active. Buy 512 GB if you want GLM-5.3, Muse or Beam daily and privately. Add a second Mac only if Apple's two-Mac numbers hold up in independent tests. If your work is mostly long prompts, rent. Prefill is still the Mac's bottleneck.

Get started

• Check your exact model, quant and context in the analyzer
• Which Mac to buy for local AI
• How MoE models work and why active parameters set the speed
• KV cache calculator for long contexts
• Renting cloud GPUs step by step

Frequently asked questions