macOS VMs were capping local AI inference. A small Metal shim gets to 98% of native Mac speed.

Apple's Virtualization.framework hands macOS guests a paravirtual Metal driver, and that driver has been reporting an older GPU family than the host chip actually has. Cua, the open-source project behind the Lume macOS-VM frontend, has now released a process-scoped Metal capability shim that rewrites those answers inside one guest process. On an M1 Ultra, it lifts llama.cpp to 11.08× the stock VM's prompt-processing speed and 16.36× the token-generation speed, reaching 98% of bare-metal prompt performance.

The shim is small in lines of code and large in what it changes. A stock Tahoe-era guest reports roughly an Apple 5-era GPU family, 32 KB of maximum threadgroup memory, and no SIMD-group matrix support. The shim instead reports family 1009 and 64 KB of threadgroup memory, and it enables the SIMD-group matrix, SIMD-group reduction, and bfloat16 paths in llama.cpp's Metal backend. None of those kernels are new. They have been sitting dormant in the code because the capability query said they were not safe to use. Changing the answer changes which kernel llama.cpp picks, and the new kernels are the ones written for modern Apple Silicon.

The numbers come from a specific configuration the team picked to make the ceiling visible. TinyLlama 1.1B on the M1 Ultra jumped from a stock guest to 11.08× faster prompt processing and 16.36× faster token generation, with prompt processing at 98% of bare-metal. Gemma 4 12B QAT Q4_0 (6.98 GB on disk) ran 7.20× faster on prompt and 14.54× faster on generation, hitting 99.59% of bare-metal prompt speed and 94.82% of bare-metal generation. Meta's Muse Glimmer 30B Q4_K-M GGUF in a 64 GiB guest on llama.cpp b10359 went 7.55× faster on a 512-token prompt and 8.87× faster on 128-token generation, with the team explicitly running text-only llama.cpp, no Ollama, no multimodal projector, and no drafter.

Gemma 4 12B Q4_0 with the shim reaches 94.82% of bare-metal generation, not 100%. The remaining gap is the paravirtual GPU contract itself: a guest sees a virtualized Metal driver, not the host's full Apple GPU, and the shim only changes what the guest process is told. Apple Virtualization.framework is unchanged. In a companion Hacker News thread, the authors clarify the result applies to llama.cpp inside the tested macOS guest configuration, not to bare-metal Mac performance. For the 30B model, the team only reported a shim-vs-stock comparison (7.55× prompt, 8.87× generation), not a shim-vs-bare-metal number, so how close a 30B-class model gets to native performance remains an open measurement.

The same capability gap has surfaced in other Virtualization.framework frontends. Release notes point to a Tart issue describing the same kind of mismatch. The shim, build scripts, a capability probe, and raw benchmark logs were released under the same permissive license as Lume, and Metal workloads benefit.

Two questions are open. First, whether the speedup transfers to M2, M3, and M4 families, where the baseline capability profile and the headroom may both be different. Second, whether other Metal workloads, including the drafter path, the multimodal projector, and inference engines beyond llama.cpp, see the same kernels light up once the shim unlocks the capability gates. The framing is that this is the first result in a broader effort to characterize the paravirtual contract, not a settled answer.