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 aShow HNlaunch for Lume, our macOS virtualization stack.
Today, we’re sharing the first result from a broader effort to connect thatVirtualization.frameworkfoundation to the local computer-use environments behindCua Driverand the infrastructure behindCua Cloud and Fleets: a small, process-scoped compatibility layer that unlocks newer Metal fast paths inside a macOS guest.
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.
Apple Vz users have been running into these limitations elsewhere too. Tart, another notable CLI built on Apple’sVirtualization.framework, has an open“No GPU passthrough in macOS guest?”issue asking whether the framework can provide usable graphics and decent LLM performance in a macOS VM guest. The VM continues to use the virtual GPU that Apple provides. Our work exposes newer Metal paths on that device and closes part of the practical gap.
On an M1 Ultra, TinyLlama 1.1B running through llama.cpp processed prompts11.08× fasterand generated tokens16.36× fasterthan 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’sGemma 4 12B QAT Q4_0, a 6.98 GB model released this year. The same layer improved prompt processing7.20×and token generation14.54×. The unlocked VM reached 99.59% of bare-metal prompt speed and 94.82% of bare-metal generation speed.
Apple’sVirtualization.frameworkpresents a macOS guest with avirtual graphics device. The guest submits Metal work through a purpose-built GPU driver, and Apple’s host stack executes it on the physical GPU. This arrangement is paravirtualization, where the host keeps control of the hardware and the guest uses a virtualization-aware device.
This differs from other virtualization stacks built on QEMU and KVM, which can use a different architecture. On x86 Linux hosts,VFIOcan assign a compatible physical PCI device or hardware function to a VM through an IOMMU, giving the guest direct access to that device. This is the model usually meant by GPU passthrough.
In our stock Tahoe VM, the paravirtualized device reported roughly an Apple 5-era family, 32 KB of maximum threadgroup memory, and SIMD-group matrix support as unavailable. Modern Metal software uses those answers to select kernels, so llama.cpp took a slower path even though the device could execute newer kernels.
Apple documents GPU capability throughGPU families and feature tablesand recommendsquerying the device at runtime. That makes the reported capability boundary consequential: applications are doing exactly what the platform tells them to do.
We built a small Metal capability shim (a compatibility layer inserted between an application and an API) that runs inside one guest process. It intercepts selected Metal capability queries and changes the answers returned to that process. Metal applications use those answers to select kernels, so returning the tested Apple-family and threadgroup-memory values lets llama.cpp choose its newer GPU paths. For our tested profile, the shim: