Apple Silicon and macOS VMs: 11–16× Faster LLM Inference with llama.cpp
Published on August 11, 2026 by Francesco Bonacci and Johnny Franks
If you've been following Cua from the start, you may remember that it began with a Show HN launch for Lume, our macOS virtualization stack.
A macOS guest running through Apple's Virtualization.framework uses a virtual GPU backed by the host's Apple GPU. In our stock Tahoe VM, that device reported a conservative Metal capability profile. Applications use those answers to select kernels and rendering paths, which left llama.cpp running much slower GPU code.
We built a small, process-scoped compatibility layer that changes selected capability answers for one guest process, allowing llama.cpp to select newer Metal kernels. This is the first result from our broader effort to connect Lume's virtualization foundation to the local computer-use environments behind Cua Driver and the infrastructure behind Cua Cloud and Fleets.
We're releasing this work today as a research release under the same permissive license as Lume and Cua, so others can reproduce the results and help map which Apple Silicon chips, macOS releases, and Metal workloads benefit.
On an M1 Ultra, TinyLlama 1.1B running through llama.cpp processed prompts 11.08× faster and generated tokens 16.36× faster than the same workload in the same stock VM. Prompt processing reached 98% of our bare-metal result. The source, build scripts, capability probe, and raw benchmark logs are included so you can inspect and reproduce the result.
We repeated the experiment with Google's Gemma 4 12B QAT Q4_0, a 6.98 GB model released this year. The same layer improved prompt processing 7.20× and token generation 14.54×. The unlocked VM reached 99.59% of bare-metal prompt speed and 94.82% of bare-metal generation speed.
We then tested Meta's official Muse Glimmer 30B Q4_K-M GGUF in a 64 GiB guest. Through llama.cpp b10359, the unlocked VM processed a 512-token prompt 7.55× faster and generated 128 tokens 8.87× faster than the stock guest. This was a text-only llama.cpp test; it did not use Ollama, a multimodal projector, or a drafter.
The same capability gap has surfaced in other Virtualization.framework frontends. Tart, another macOS virtualization CLI, has an open “No GPU passthrough in macOS guest?” issue covering graphics and LLM performance inside macOS guests.
... continue reading