在一台M1 Ultra上，跑在macOS虚拟机里的TinyLlama 1.1B，prompt处理速度从每秒431.86 token跳到4786.70 token，提速11.08倍；token生成从12.63跳到206.60，提速16.36倍，逼近裸机的98%。换成更贴近实际使用的Gemma 4 12B QAT模型，生成速度提速14.54倍，达到裸机的94.82%。这是trycua（旗下有macOS虚拟化工具Lume）本周发布的一份研究性博客里给出的数字。

数字很扎眼，但标题里的说法值得较真：trycua管这个叫"GPU passthrough"，可这跟大多数人理解的GPU直通不是一回事。

发生了什么：一个进程级垫片，把虚拟机的GPU"能力"改高了

Apple的Virtualization.framework给macOS虚拟机提供的从来不是物理GPU的直接控制权，而是一块半虚拟化虚拟图形设备：guest提交Metal指令，host的物理GPU代为执行，硬件控制权始终在host手里。这跟x86/Linux上VFIO配合IOMMU、把整块物理GPU分配给虚拟机的做法，是两种完全不同的架构。

trycua做的事情，是写了一个只作用于单个guest进程的Metal能力垫片，拦截supportsFamily、最大threadgroup内存等能力查询，把虚拟机里原本汇报的"Apple 5代、32KB threadgroup内存"改成"Apple 9代、64KB"。llama.cpp看到这个更高的汇报值，就会自己切换到SIMD-group matrix、bfloat16等更快的计算路径——物理GPU其实一直具备执行这些路径的能力，只是虚拟机的驱动一直没告诉它可以用。

这解释了为什么prompt处理能跑到裸机98%以上：workload没变，只是选择了原本就存在、只是被guest"以为自己不支持"而没选的路径。

术语的差一个字，决定了读者该怎么理解这件事

Apple的官方文档从未承诺guest的Metal能力会和host保持一致，反而明确要求应用在运行时查询supportsFamily、maxThreadgroupMemoryLength之类的接口，自己判断能用哪条路径。这个设计的前提，是应用如实提问、平台如实回答。

trycua的垫片做的，正是打破这个"如实回答"的契约——不是打开了一条Apple没开放的物理通道，而是让guest进程在查询时得到一个被篡改的答案。类似的悬而未决的诉求此前已经在同类工具Tart的issue里出现过，说明这不是trycua一家的困惑，而是所有基于Virtualization.framework做macOS虚拟机的项目都撞过的墙。

提速的不是硬件，是虚拟机对自己说的谎。

严格意义上的passthrough，指的是VFIO/IOMMU式的物理设备独占分配，trycua自己在文档里也承认"物理GPU分配、原始PCI或VFIO直通、内核改动都在这个机制之外"。用这个词做标题，容易让读者以为Apple开放了新的硬件通道，实际发生的是应用层的能力查询被动了手脚。

  • 风险.新路径依赖guest对自己"谎报"的能力汇报，host物理GPU执行这些原本不该被guest看到的路径时，是否会产生数值偏差或不稳定，trycua的博客完全没有讨论，目前也没有看到独立于trycua的第三方复现数据。

谁会用上它，接下来该看什么

这套机制最直接的受益者，是在Apple Silicon macOS虚拟机里跑本地大模型推理的开发者，以及trycua自己的Cua Driver、Cua Cloud等依赖虚拟化基础设施的产品——如果结果站得住，云端跑agent的Mac主机成本能明显往下压。同类工具Tart、UTM大概率会关注这个方案能不能复现到自己的栈里。

真正的变量在Apple这一侧。这个垫片吃的是私有、版本敏感的Metal实现细节，trycua自己也承认每个macOS版本都需要单独测试，随时可能被下一次系统更新改掉行为。它依赖的是一个平台原本设计给"诚实问答"用的接口，一旦Apple把这类能力欺骗当成需要修补的兼容性问题，这条路径随时可能失效。

在看到更多独立硬件、独立llama.cpp版本上的复现数据之前，这份提速数字更适合当作一个值得关注的信号，而不是可以直接搬进生产环境的结论。