Mac Studio M3 Ultra 512 GB
— measured local LLM benchmarks

Results

All MLX rows use the same ~8,000-byte prompt (2,700–3,100 tokens after tokenization) and generate 300 tokens at temperature 0. Prompt processing (PP) and generation are separate measurements — on Apple Silicon they behave very differently and quoting only one of them is how benchmarks lie.

Power column: p90 during generation / maximum over the whole run (load + PP + generation), in watts. † Kimi K2.7 Code ran on llama.cpp (llama-bench, 2,048-token prompt), so its PP figure is not tokenizer-identical to the MLX rows, its load time is a cold-start wall clock including one token, and generation-window power could not be isolated (whole-run p90 was 103.6 W). Rows marked experimental required unmerged draft mlx-lm pull requests pinned to specific commits — not yet in any official release. ‡ Qwen3.5’s load time was measured with a warm page cache, so treat it as a floor, not a cold start. Qwen3.5, gpt-oss-120B, and both Gemma 4 rows were measured 2026-07-22 on the same machine; the rest 2026-07-19/20.

What the numbers mean in practice

The practical split is simple. gpt-oss-120B, Qwen3.6 35B-A3B, Gemma 4 26B-A4B IT, Qwen3-Coder-Next are interactive — 77–105 tok/s feels immediate for chat and coding. The 3 giant models (316–390 GiB on disk) run at 18–25 tok/s: readable-speed generation that no other single consumer machine can attempt at all, because the weights simply do not fit anywhere else. In between, Qwen3.5 397B-A17B (208.5 GiB) holds 38.1 tok/s — a 397B-parameter model at conversational speed. Devstral 2 at 8.9 tok/s is a batch worker — queue it, do not chat with it.

Prompt processing is the number most benchmarks hide. Small MoE models ingested our ~2,800-token prompt at 2,000–2,900 tok/s, while the 400 GiB-class models sit at 145–207 tok/s — so a long repository context takes real seconds before the first output token. If your workload is long-context-heavy, weight PP as heavily as generation speed.

32K-class long context — measured, three runs per model

The same 96,638-byte text (32,006–36,777 tokens depending on tokenizer) was ingested and 128 tokens generated, three times per model. Prompt processing is shown as the median of three runs with the p10–p90 spread — all 12 runs finished with no OOM and no swap.

Generation slowed 13–36% and prompt processing 23–34% vs the short-prompt runs, with peak memory up 1–8 GB — no cliff, just a gradual tax. Only Qwen3.5 showed meaningful PP variance across runs (359–428 tok/s). The 300 GiB-plus models (DeepSeek R1, GLM-5.2, Kimi K2.7) have not been measured at 32K yet.

Local Codex agent soak — 29/29 over 32 minutes

We pointed Codex CLI at Qwen3-Coder-Next (4bit MLX) served locally on the same machine and ran one fixed implementation task (29 iterations, 1,909 s total): implement a Python module against an existing test suite and generate a Markdown report. Every iteration finished in a single agent turn with 6/6 tests passing — median 56 s, p90 102 s per iteration. Median machine power during the soak was 31.1 W.

This is a stability check on one constrained, small-repo task — it shows the local-agent loop is solid, not that a local model matches a frontier API model on arbitrary large repositories.

Read this before quoting the table

These are single-run snapshots

Speed varies with quantization, runtime version, prompt, temperature, and OS state. Treat every number as "what one real run produced on this machine", not a guaranteed or average figure.

Speed is not model quality

This page measures throughput only. A faster model is not a better model — pick by output quality first, then check here whether the wait is acceptable.

GLM-5.2 and DeepSeek V4 Flash needed draft mlx-lm PRs

Both failed on the released mlx-lm 0.31.3 and only ran with pinned, unmerged pull requests (#1410 and #1189). They work, but we do not call them officially supported.

The Kimi row is a reference, not an apples-to-apples comparison

Kimi K2.7 Code ran on llama.cpp with a 2,048-token prompt, a different tokenizer and a different load-time definition (cold-start wall clock). Its generation-window power could not be isolated, so it stays blank rather than estimated.

Power numbers are per-window, not "constant draw"

Load and prompt processing spike much higher than steady generation. We publish the p90 during generation and the maximum over the whole run as separate columns — neither is an idle or average figure.

Common questions, answered from the measurements

Can one Mac Studio 512 GB really run DeepSeek R1, GLM-5.2, or Kimi K2.7 Code?

Yes — we measured all three on this machine: DeepSeek R1-0528 at 20.3 tok/s (4-bit MLX), GLM-5.2 at 17.9 tok/s, and Kimi K2.7 Code at 24.6 tok/s (2-bit GGUF on llama.cpp), each with the weights fully in memory and no swap. Caveat: GLM-5.2 only ran on a pinned draft mlx-lm pull request, so it is not officially supported yet.

Which model felt usable for coding agents on this machine?

Qwen3-Coder-Next generated at 77.2 tok/s and completed a 29/29 local Codex agent soak on the same machine; Devstral 2 123B ran at 8.9 tok/s, which suits batch work rather than interactive coding. That is a speed observation, not a model-quality ranking.

Do the 300–400 GiB models need special setup?

Some do. DeepSeek R1-0528 ran on released mlx-lm as-is. GLM-5.2 and DeepSeek V4 Flash each required a pinned, unmerged draft mlx-lm pull request, and Kimi K2.7 Code ran via llama.cpp. Before any of the giant models, raise the GPU wired-memory limit (sudo sysctl iogpu.wired_limit_mb=480000 — it resets to zero on reboot).

How much power does it draw while generating?

Measured p90 during generation ranged from 37.9 W (Qwen3-Coder-Next) to 75.9 W (Devstral 2), with whole-run spikes up to 172.7 W during load and prompt processing. These are per-window measurements, not constant draw.

What about long contexts — 32K tokens and beyond?

Measured for four models (2026-07-22, 32K-class input, 3 runs each, all 12 clean): Qwen3.5 397B-A17B held 33.0 tok/s generation at a 34,448-token prompt, gpt-oss-120B 62.6 tok/s at 32,006 tokens, Gemma 4 26B-A4B 67.6 tok/s and Gemma 4 31B 21.4 tok/s at 36,777 tokens. Generation dropped 13–36% vs short prompts and no run hit OOM or swap. The 300 GiB-plus trio (R1, GLM-5.2, Kimi) has not been measured at 32K yet.

Method & reproducibility

Machine

Mac Studio / Apple M3 Ultra / 32-core CPU / 80-core GPU / 512 GB unified memory / 4 TB SSD

Software

macOS 26.5.1 · MLX 0.32.0 · mlx-lm 0.31.3 · mlx-vlm c9e27b0 · llama.cpp 571d0d5

Protocol

MLX rows: the same 8,000-byte text as prompt, temperature 0, seed 42, 300 generated tokens. Kimi: llama-bench -p 2048 -n 300. 32K long-context rows: the same 96,638-byte text, 128 generated tokens, 3 runs per model (Qwen3.5 and Gemma 4 served via mlx-vlm). Power: powermetrics CPU+GPU+ANE at 1 s intervals.

Pinning

Every measured artifact is a specific Hugging Face quantization repo pinned to a specific revision, recorded in the run manifest — so “DeepSeek R1” here means one exact set of weights, not whatever the repo serves today.

Raw data

The exact numbers on this page are published as JSON at /benchmarks/512gb/results.json — cite or diff them freely.

Hygiene

One run that overlapped with background disk I/O was discarded as contaminated and re-measured idle. Failed runs (released mlx-lm rejecting GLM-5.2 and DeepSeek V4) were kept in the logs, not replaced with zeros.

Run your own numbers on this exact machine

These benchmarks were measured through the same checkout, access page, and Tailscale connection you get. 7 days from $499 — bring your own models and workload.