Cua 的团队此前以 macOS 虚拟化栈 Lume 起步。苹果自家的 Virtualization.framework 让 macOS 客户机通过虚拟 GPU 使用宿主的 Apple GPU，但在默认配置下，这个虚拟设备上报了一套非常保守的 Metal 能力档。应用程序正是根据这些应答来选择计算内核和渲染路径，于是 llama.cpp 在虚拟机里走了更慢的 GPU 代码路径。

虚拟机里的 GPU 被「降级」了

问题出在能力查询的应答上。在 Cua 基于 macOS Tahoe 的标准虚拟机里，这块虚拟显卡上报的近似能力是「Apple 5 时代家族」、最大线程组内存仅 32 KB，并且不支持 SIMD 组矩阵运算。现代 Metal 软件会依据这些应答挑选内核，即便设备其实能跑更新的内核，llama.cpp 也只会选择更慢的实现。

苹果官方文档通过「GPU 家族与特性表」来描述 GPU 能力，并建议应用在运行时查询设备。换言之，应用程序只是照着平台告诉它的边界来工作。这与常见的 GPU 直通不同：在 x86 Linux 上可以通过 VFIO 把物理 PCI 设备直接分配给虚拟机，而苹果这套是半虚拟化架构，宿主机仍掌控硬件，客户机使用的是虚拟化感知的设备。

进程级补丁做了什么

Cua 团队写了一个很小的 Metal 能力补丁，作为兼容层插在某个客户机进程与 Metal API 之间。它只拦截并改写该进程读到的少数几项能力应答：把支持的家族档提升到 Apple family 9（编号 1009），并把最大线程组内存从 32 KB 提到 64 KB。就这两项改动，足以让被测的 llama.cpp 版本改用更新的 SIMD 组归约、SIMD 组矩阵与 bfloat16 路径。

关键在于，这个补丁只作用于被注入的那个工作进程及其子进程，工作负载仍然跑在苹果现有的虚拟 GPU 通道上，由宿主的 Apple GPU 执行；它不涉及物理 GPU 直连、原始 PCI 或 VFIO 直通，也不改动内核。其余能力档保持默认不变，配置缺失或格式错误时会自动回落到标准路径。

实测：提速 7 到 16 倍

测试在一台 Apple M1 Ultra（48 核 GPU）、宿主 macOS 26.6.1 上进行，客户机为当前公开的 Tahoe Cua 镜像（macOS 26.5.2、8 个虚拟 CPU、16 GiB 内存），运行 Lume 0.5.1，统一使用官方 llama.cpp b10167 版本。

使用 TinyLlama 1.1B 对话模型（Q4_K_M）时，提示处理从标准虚拟机的每秒 431.86 个词元提升到解锁后的 4786.70 个词元，达到裸机的 98.25%；生成速度从每秒 12.63 个词元提升到 206.60 个词元，相当于裸机的 72.06%。两项提升分别为 11.08 倍与 16.36 倍。

换成 Google 今年发布的 Gemma 4 12B（QAT Q4_0，约 6.98 GB）后，提示处理从每秒 71.66 个词元提升到 515.76 个词元，达到裸机的 99.59%；生成从每秒 3.41 个词元提升到 49.67 个词元，相当于裸机的 94.82%，提升分别为 7.20 倍与 14.54 倍。

再用 Meta 官方的 Muse Glimmer 30B（Q4_K-M，约 16.76 GB，客户机内存提到 64 GiB）测试，提示处理从每秒 25.83 个词元提升到 194.97 个词元，生成从每秒 2.38 个词元提升到 21.08 个词元，提升分别为 7.55 倍与 8.87 倍。作为对照，MLX-LM 0.31.3 在标准中就已经很快，补丁前后几乎持平（提示 1.005 倍、生成 0.993 倍），这也帮助团队定义了发布时所覆盖的能力档范围。

局限与适用边界

这项技术仍是实验性的，且对版本敏感：它依赖客户机 Metal 实现中私有的、随 macOS 版本可能变化的行为，因此每一个宿主与客户机组合都需要单独验证。补丁只影响被注入的工作负载，加固或受平台保护的程序可能拒绝库注入；它覆盖的能力档也仅限于已测试的范围，物理 GPU 能力发现不在其内。

Cua 已将相关源码以与 Lume、Cua 相同的宽松许可证开放，并附带构建脚本、能力探测与原始基准日志，供他人复现。对于需要在苹果芯片虚拟机里跑本地推理的开发者，这层补丁提供了一个值得关注的起点——前提是接受它的实验属性，并为每个系统组合自行核验。

来源：Cua 官方博客（GitHub 项目 trycua/cua），作者 Francesco Bonacci 与 Johnny Franks

为什么要在 Mac 上重造一个引擎

MiniMax 在 8 月 3 日把 H3 正式开源，这是一个能同时吃进文本、图像、音频、视频、再一次性吐出最长 15 秒带原生立体声视频的通用生成模型。官方提供了 Hugging Face 权重和基于 SGLang、MLX 等的参考实现，社区也很快出现了 PipeNetwork 的 MLX 移植版。

但 antirez 选择了一条更硬核的路：不依赖现成框架，自己用 C 实现推理内核，再用 Metal 把矩阵运算落到苹果芯片的 GPU 上。这样做的好处是能精细控制统一内存的占用与复用——视频模型权重动辄上百 GB，能否塞进 Mac 的有限内存，取决于推理引擎怎么分批搬运张量。h3.c 目前仍在开发中，仓库显示它已能跑通提示词到视频、首尾帧约束，以及参考图、视频、音频的 Ref2VA 条件控制。

速度能快多少

项目 README 里给出了一组在 M5 Max 上的实测。以一段 512 像素见方、22 帧的红狐踏雪短片为基准：用默认 20 步去噪需要约 26.4 秒；而采用 4 步的激进调度，耗时压缩到约 3.5 秒，画面对照 29 步参考稿的全片结构相似度（SSIM）仍有 0.556，独立的冲浪者测试为 0.547。换句话说，用不到七分之一的时间，就能拿到一个可用、但细节更糙的预览。

模型核心是一个 33B 的稠密 Transformer（H3-Omni-Transformer），文本编码器复用 Qwen 系模型，权重以 BF16 精度常驻。在开启预览的激进配置下，峰值显存占用约 25.9 GiB（int8 估算）。仓库还提供多档预设：默认 20 步、最慢 50 步参考、最快 4 至 7 步，开发者可以一次只调一个旋钮来权衡速度与画质。

能拿来做什么

h3.c 内置了一个类似 Iris 的交互会话：启动时加载模型与分词器，之后输入提示词即可连续生成，重复提示词换随机种子时不必重新加载。它支持首帧与末帧锚定，让镜头从 A 画面运动到 B 画面，也支持按顺序追加多张参考图，标记为图片 1、图片 2，让模型据此生成「让图片 1 里的人挥手」这类指令。

分辨率方面，512×512 是被反复验证的开发尺寸，768p 级别的横竖构图也已验证，画布上限受机械限制约 768×1344。更短的 256 见方预览会自动降低空间位置编码频率，消除长镜头里出现的网格伪影。

对普通用户而言，h3.c 的意义在于把在云端排队、按秒计费的视频生成，变成在自己电脑上离线跑的一件事。代价是需要一台内存充足的 Apple Silicon Mac，以及等待项目继续打磨工程完整度。antirez 本人以把复杂系统写到极简著称，h3.c 最终能否成为 Mac 上跑 H3 的默认选择，还要看后续的内存优化与稳定性。

来源：Hacker News | antirez | https://github.com/antirez/h3.c