# Cua ships a Metal shim that accelerates LLMs inside macOS VMs > Source: > Published: 2026-08-11 23:28:05+00:00 [Cua](https://cua.ai) founder [Francesco Bonacci (@francedot)](https://x.com/francedot) released an open-source Metal capability layer on August 11th that Cua says sharply accelerates llama.cpp inference inside Apple Silicon macOS virtual machines. The release addresses a narrow bottleneck in Apple's virtualization stack. Apple's Virtualization.framework already lets a macOS guest send Metal work to the host GPU through a paravirtualized graphics device. Cua found that its stock macOS Tahoe guest reported a conservative capability profile, leading llama.cpp to disable faster kernels that the virtual GPU could execute. Cua's layer changes those capability answers for a single process. In [a thread on X](https://x.com/trycua/status/2087224365284733400), Cua reported prompt-processing gains ranging from 7.20x to 11.08x and token-generation gains ranging from 8.87x to 16.36x across three models on an M1 Ultra. Bonacci started Cua in San Francisco in March 2025 after leaving Microsoft, where he and co-founder [Dillon DuPont (@ddupont808)](https://x.com/ddupont808) worked on Windows Agent Arena, a benchmark and testing platform for desktop agents. Bonacci began Cua with [Lume](https://github.com/trycua/cua), its open-source manager for native macOS and Linux VMs on Apple Silicon. Cua joined Y Combinator's X25 batch and has since expanded into cross-platform sandboxes, computer-control drivers and agent benchmarks. ### The virtual GPU was taking the slow path A stock Tahoe guest in Cua's tests reported Apple GPU family 5 and 32 KB of maximum threadgroup memory. llama.cpp reads those values before selecting Metal kernels. Based on the reported profile, it disabled SIMD-group reduction, SIMD-group matrix operations and bfloat16 support. Cua's [process-scoped compatibility layer](https://github.com/trycua/cua/blob/main/libs/lume/metal-capability-shim/README.md) intercepts selected Metal queries and reports support through Apple family 9, while raising the threadgroup-memory answer to 64 KB. The host bridge, virtual GPU and guest kernel remain unchanged. That distinction matters because Cua has also described the work under the more familiar label of GPU passthrough. The release does not assign the M1 Ultra's physical GPU directly to the guest. It keeps Apple's paravirtualized GPU path in place and changes what one injected process believes that device supports. Apple's [Metal feature tables](https://developer.apple.com/metal/capabilities/) classify M1-series GPUs under Apple family 7. Cua's family 9 answer is a tested compatibility profile rather than physical hardware detection. Cua says each additional Metal workload, host chip and macOS combination requires separate validation. ### Cua's benchmarks approach bare-metal speed For TinyLlama 1.1B Q4_K_M, Cua measured prompt processing rising from 431.86 to 4,786.70 tokens per second, an 11.08x increase. Token generation rose from 12.63 to 206.60 tokens per second, or 16.36x. The unlocked prompt-processing result reached 98.25% of Cua's 4,871.99-token-per-second bare-metal measurement. The generation result retained a larger virtualization gap. Bare-metal generation reached 286.71 tokens per second, putting the unlocked VM at 72.06% of host performance. Cua calculated the TinyLlama figures from the medians of ten llama-bench samples for each workload. Cua repeated the test with Google's Gemma 4 12B instruction-tuned QAT Q4_0 model. Prompt processing increased from 71.66 to 515.76 tokens per second, while generation increased from 3.41 to 49.67 tokens per second. Those unlocked results reached 99.59% and 94.82% of Cua's corresponding bare-metal measurements. The [published Gemma evidence](https://github.com/trycua/cua/tree/main/evidence/lume-metal-capability-shim/2026-08-10-m1-ultra-gemma4) contains ten-sample medians, model hashes and benchmark logs. For Meta's Muse Glimmer 30B Q4_K-M, running in a 64 GiB Tahoe guest, Cua reported prompt processing increasing from 25.83 to 194.97 tokens per second and generation increasing from 2.38 to 21.08. The [Muse Glimmer evidence set](https://github.com/trycua/cua/tree/main/evidence/lume-metal-capability-shim/2026-08-11-m1-ultra-muse-glimmer-64g) uses the median of three runs and covers text-only llama.cpp inference. It excludes Ollama, the model's multimodal projector and speculative decoding. The results remain Cua-run benchmarks on one M1 Ultra. Cua published the source, build scripts, checksums, raw output and environment records under the repository's MIT license, giving other developers enough material to reproduce or challenge the measurements. ### MLX exposed the boundary Cua did not find a general performance gain across Metal software. MLX-LM stayed effectively flat in its tests, moving from 1,656.55 to 1,665.47 tokens per second for prompt processing and from 172.09 to 170.86 for generation. An earlier, broader capability profile also caused MLX device initialization to fail when it advertised Metal 3 support. According to Cua's [technical write-up](https://github.com/trycua/cua/blob/main/blog/gpu-passthrough-macos-vms.md), MLX then requested a residency set that the paravirtualized device could not create. Cua narrowed the release to Apple-family and threadgroup-memory answers after that failure. The current implementation requires enabling an unrestricted device feature level on the host and injecting a dynamic library into the selected guest process through `DYLD_INSERT_LIBRARIES` . Hardened or platform-protected executables may reject that injection. Removing the environment variables returns the workload to its stock capability path. Cua also describes the method as experimental and version-sensitive because it relies on private behavior in the guest Metal implementation. A future macOS release could change that behavior. For Bonacci, the immediate bet is that Apple Silicon VMs contain enough usable GPU capability to run local inference close to host speed, provided developers can identify which conservative capability checks are blocking the faster kernels.