cua Lume Metal Capability Shim进程级 DYLD 注入修正 macOS 虚拟机 GPU 能力报告的原理、构建与验证【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cua本文围绕 libs/lume/metal-capability-shim/README.md 展开讲清这个实验性“Metal 能力 shim”在 Apple Silicon 上的 macOS 虚拟机Lume guest里解决了什么问题、如何通过DYLD_INSERT_LIBRARIES与 Objective-C 运行时方法替换改写 GPU 能力查询结果、如何用仓库自带的构建/校验/打包脚本复现可追溯的二进制产物以及 M1 Ultra 上 TinyLlama 与 Gemma 4 的实测证据。读完后你可以理解“只抬高能力上报、不碰设备本身”这一设计的边界并能在受控环境中安全地启用、探测与移除该 shim。问题背景虚拟机里的 Metal 设备“自报能力”偏低Lume 是 cua 仓库中运行 macOS 虚拟机guest的工具链guest 内的 GPU 走的是 Apple 的半虚拟化paravirtualized图形路径而不是直通物理显卡。在这种路径下guest 内MTLDevice的能力上报可能不足以让 llama.cpp、MLX-LM 这类运行时选择到高性能 fast path例如supportsFamily:对 Apple GPU family 的查询返回falsemaxThreadgroupMemoryLength报告的 threadgroup memory 偏小。这个 shim 的定位被刻意收窄见 README它只改动 macOS guest 内选定 Metal 能力查询的回答把 Apple GPU family 的“支持”上报抬到一个可配置的天花板ceiling并抬高 threadgroup memory 上限GPU 命令仍然走 Apple 半虚拟化图形路径——不把物理设备直通给 guest不 patch 宿主不修改 guest 内核它不改动Common、Mac、Metal 这几个 family 区间的原始回答它不包含任何私有 feature-profile 钩子、时钟拦截clock interposition、mesh-draw 替换、ray-tracing 覆写或 pipeline 编译回退。也就是说这是一个“只改口供、不升级硬件”的能力上报 shim且作用域限定在单个进程。实现原理constructor 注入 对_MTLDevice的方法替换shim 的全部实现只有一个 Objective-C 文件 Sources/LumeMetalCapabilities.m约 200 行依赖Foundation、Metal和objc/runtime。结合源码可以完整还原它的工作链条进程启动时注入。dylib 通过DYLD_INSERT_LIBRARIES加载后__attribute__((constructor))标记的initializeLumeMetalCapabilitiesL187-L206自动执行先做环境配置校验再NSClassFromString(_MTLDevice)找到 Metal 私有设备类最后替换其initGPUFamilySupport方法的实现。设备初始化能力时才挂钩。当_MTLDevice走initGPUFamilySupport时hookInitGPUFamilySupportL182-L185先调用installDeviceHooks安装真正的能力钩子再调用原始实现。installDeviceHooks用synchronized([device class])加gDeviceHooksInstalled标志保证只安装一次L119-L180。替换三个能力查询方法。replaceMethodL105-L117通过method_setImplementation替换并保存原 IMPsupportsFamily:original || (1001 family appleFamilyMax)即只在 Apple family 区间1001 起内把“不支持”抬为“支持”区间外一律保留设备原始回答L96-L103maxThreadgroupMemoryLength返回max(原始值, 配置值)只升不降L78-L85recommendedMaxWorkingSetSize同样max(原始值, 配置值)且仅当显式设置了环境变量时才安装这个钩子L87-L94。值得注意的是“fail-closed失败即关闭”设计贯穿两处配置校验失败则完全不注入。loadConfigurationL43-L76要求LUME_METAL_APPLE_FAMILY_MAX必须存在且落在1001含到1999之间——缺省、为零、越界或非数字都会直接放弃启用进程保持原始能力私有类/方法缺失则保持原样。installDeviceHooks若发现maxThreadgroupMemoryLength、supportsFamily:等所需方法不存在只会NSLog记录 “leaving stock capabilities unchanged” 并退出不做任何部分替换L139-L143。README 的兼容性章节也明确要求“把私有类或方法缺失当作不受支持unsupported处理”。配置参数与环境变量README 中给出的控制项及行为如下默认值与源码 loadConfiguration 一一对应变量默认值行为LUME_METAL_APPLE_FAMILY_MAX必填Apple family 上报天花板。缺省、为 0、越界源码校验为1001或2000或格式错误时库完全不修改进程LUME_METAL_MAX_THREADGROUP_MEMORY65536把上报的最大 threadgroup memory 抬到至少该字节数max语义只升不降LUME_METAL_RECOMMENDED_WORKING_SET_SIZE不变仅当显式设置时把 recommended working-set size 抬到至少该值README 特别强调这些控制项只应配合已测试过的工作负载与宿主/guest 组合使用“上报了某能力”并不证明使用该能力的所有 Metal API 都能正确工作。构建双架构 dylib、校验脚本与发布打包构建要求 Apple Silicon Xcode Command Line Tools。README 给出的最小流程./Scripts/build.sh ./Scripts/verify.shScripts/build.sh 的实际动作L12-L58用xcrun clang分别以-arch arm64与-arch arm64e编译唯一源文件参数包括-O3 -Wall -Wextra -Werror -fobjc-arc -fvisibilityhidden -dynamiclib、-install_name rpath/LumeMetalCapabilities.dylib、-mmacosx-version-min13.0链接Foundation与Metal框架产出LumeMetalCapabilities-arm64.dylib和LumeMetalCapabilities-arm64e.dylib并做 ad-hoc 签名以-O2编译探针 Tests/metal-capabilities.m 为metal-capabilities可执行文件在输出目录默认dist/生成SHA256SUMS。Scripts/verify.sh 的校验比常规更强L19-L52lipo -verify_arch确认 arm64/arm64e 架构、codesign --verify --strict验签、shasum -a 256 -c SHA256SUMS核对哈希用strings做负向断言两个 dylib 中不得出现研究版行为残留GPU_HOOK_TIME_SCALE、mach_absolute_time、clock_gettime、gettimeofday、MESH_FALLBACK、IGNORE_ARGTYPE、SYNC_COMPUTE也不得出现宽能力行为LUME_METAL_FEATURE_PROFILE、featureProfile、LUME_METAL_FAMILY_MAX否则直接判定 “unexpected research-only behavior” 失败退出。这与 README 的声明相互印证发布产物“刻意窄”不含研究阶段的钩子。verify.sh支持--no-build只校验已有产物。工具链固定与发布打包README 指出与证据匹配的 M1 Ultra/Tahoe 发布二进制使用Command Line Tools 26.4干净的源码修订与二进制溯源记录在 Release/PROVENANCE.md。若安装了匹配工具链可用DEVELOPER_DIR/Library/Developer/CommandLineTools ./Scripts/build.sh ./Scripts/verify.sh --no-buildRelease/PROVENANCE.md 进一步固定了复现细节冻结源码修订d95545418f4789b5fc9ae13b8614c920071f11b5、Apple clang 21.0.0、macOS SDK 26.4、最低部署目标 13.0、dylib 为 69,456 字节的 thin arm64/arm64e 且仅 ad-hoc 签名明确非Developer ID 签名、未公证install name 为rpath/LumeMetalCapabilities.dylib链接 Foundation、Metal、Objective-C runtime、CoreFoundation 与 libSystem。同时提醒工具链与构建环境细节会改变二进制字节因此要记录 Xcode、SDK、源码修订、checkout 路径与输出哈希。Scripts/package-release.sh 以ARTIFACT_DIR RELEASE_DIR两个参数调用它检查三个产物齐全后把已验证的二进制组、通过git archive从冻结修订生成的源码归档前缀cua-d9554541/、以及已提交的 SHA256SUMS 与 PROVENANCE 复制到发布目录拒绝覆盖任何已存在的发布输出最后再跑一次verify.sh --no-build。README 也说明发布资产刻意不提交进dist/。运行单进程启用与能力探针README 给出的标准用法测试画像为 Apple family 天花板1009即 Apple 9并上报 64 KB threadgroup memoryDYLD_INSERT_LIBRARIES/path/to/LumeMetalCapabilities-arm64.dylib \ LUME_METAL_APPLE_FAMILY_MAX1009 \ ./metal-capabilities 1009注意选择与目标进程架构匹配的 dylibarm64 或 arm64e。探针metal-capabilities的源码Tests/metal-capabilities.m很简单解析命令行 family 参数默认 1009调用MTLCreateSystemDefaultDevice()然后打印设备名、查询的 family、supportsFamily:结果与maxThreadgroupMemoryLength便于在注入前后直接对比能力变化。仓库证据目录记录了注入前后的实际变化M1 Ultra/Tahoe见 2026-08-09 证据 README能力Stock未注入注入 safe shimsupportsFamily:1009falsetrue最大 threadgroup memory32,768 字节65,536 字节同一份证据还验证了 fail-closed 行为配置错误的LUME_METAL_APPLE_FAMILY_MAX会产生与 stock 一致的结果确认了“配置不合法即不生效”的声明。移除无持久化状态移除方式就是 README 的 “Remove” 一节从工作负载环境中移除DYLD_INSERT_LIBRARIES与所有LUME_METAL_*变量然后重启该工作负载。shim 不产生任何持久化系统变更——所有修改都发生在被注入进程的运行时内存里method_setImplementation改的是该进程内的方法表。兼容性边界为什么刻意不声明MTLGPUFamilyMetal3README 的兼容性章节是本 shim 最重要的安全约束要点代码依赖 macOS guest 内私有且版本敏感的 Metal 实现细节Apple 可能在任何 macOS 版本中改变它们。应把启用范围限定在单个进程、对每个宿主/guest 版本组合独立测试不要把画像扩大为声明MTLGPUFamilyMetal3。证据 2026-08-09 README 给出了具体原因MLX-LM 会依据MTLGPUFamilyMetal3的回答来选择 residency set而测试中的半虚拟化设备无法创建该路径要求的 residency set——一个声明了MTLGPUFamilyMetal3的宽研究画像在 MLX 设备初始化阶段直接失败。这正是发布版 shim “只改 Apple family 回答”的原因。能力上报不等于功能可用README 明确“被上报的能力并不能证明使用该能力的每个 Metal API 都正确工作”。验证证据M1 Ultra 上的 llama.cpp 与 MLX-LM 结果仓库在 evidence/lume-metal-capability-shim/ 下保留了完整的原始数据JSON、stderr、results.csv、SHA256SUMS。两组代表性结果均为llama-bench十次采样samples_ts的中位数TinyLlama 1.1B Q4_K_M2026-08-09工作负载裸机宿主Stock guestSafe-shim guestGuest 加速Shim/宿主pp5124,871.99 tok/s431.86 tok/s4,786.70 tok/s11.08×98.25%tg128286.71 tok/s12.63 tok/s206.60 tok/s16.36×72.06%Gemma 4 12B QAT Q4_02026-08-10工作负载裸机宿主Stock guestSafe-shim guestGuest 加速Shim/宿主pp512517.88 tok/s71.66 tok/s515.76 tok/s7.20×99.59%tg12852.38 tok/s3.41 tok/s49.67 tok/s14.54×94.82%这两组结果的含义在 macOS Tahoe guest 中注入 Apple-family-only shim 后llama.cpp 的 prompt processing 恢复到接近裸机宿主的水平98%–99.6%token generation 恢复 72%–94.8%。Gemma 4 证据的 stderr 对比也说明机制路径safe-shim 侧记录 Apple family 9、SIMD-group matrix 与 reduction 支持、bfloat16而 stock 侧记录 Apple family 5 且这些 fast path 被禁用。该证据还记录了测量卫生一次与宿主计算负载重叠的 stock 预跑被整体拒绝最终数据全部来自无竞争的窗口。MLX-LM 一侧MLX-LM 0.31.3 MLX 0.32.0Llama-3.2-3B-Instruct-4bit512 token prompt / 128 token generation十次重复工作负载Stock guestSafe-shim guest比值Prompt processing1,656.55 tok/s1,665.47 tok/s1.005×Token generation172.09 tok/s170.86 tok/s0.993×即 safe 画像对 MLX-LM 无实质速度影响但确认了其在 shim 下仍可正常运行。证据 README 同时划定了范围这些运行证明了缩减版 shim 能激活 llama.cpp 的 fast path不依赖私有 feature-profile 钩子或研究钩子的 timing/mesh/ray-tracing/argument-layout/pipeline fallback但并不验证所有 Metal 特性与工作负载llama.cpp 官方b10167发布二进制的 SHA-256 与历史交接二进制不同该证据系列应与历史 M5 数据分开看待。另有第三组 2026-08-11 Muse/Glimmer 64G 数据clean stock/unlocked 对照同目录保留。小结一个“窄而可审计”的能力修正层这个 shim 的价值在于把“虚拟机内 GPU 能力上报不足”这一具体问题约束在最小可审计的面里单文件 ObjC 实现、单一必填环境变量、max语义只升不降、双重 fail-closed配置校验 私有方法缺失检测、负向 strings 断言的构建校验、冻结修订加哈希清单的发布溯源PROVENANCE.md、SHA256SUMS以及明确拒绝扩大画像不声明MTLGPUFamilyMetal3的兼容性边界。它依赖私有、版本敏感的 Metal 内部实现因此使用时必须遵循 README 的告诫限定单进程、按宿主/guest 版本组合独立验证并始终牢记“上报能力不等于能力可用”。代码以 MIT 协议发布LICENSE。【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cua创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 cua Lume Metal Capability Shim：进程级 DYLD 注入修正 macOS 虚拟机 GPU 能力报告的原理、构建与验证
cua Lume Metal Capability Shim进程级 DYLD 注入修正 macOS 虚拟机 GPU 能力报告的原理、构建与验证【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cua本文围绕 libs/lume/metal-capability-shim/README.md 展开讲清这个实验性“Metal 能力 shim”在 Apple Silicon 上的 macOS 虚拟机Lume guest里解决了什么问题、如何通过DYLD_INSERT_LIBRARIES与 Objective-C 运行时方法替换改写 GPU 能力查询结果、如何用仓库自带的构建/校验/打包脚本复现可追溯的二进制产物以及 M1 Ultra 上 TinyLlama 与 Gemma 4 的实测证据。读完后你可以理解“只抬高能力上报、不碰设备本身”这一设计的边界并能在受控环境中安全地启用、探测与移除该 shim。问题背景虚拟机里的 Metal 设备“自报能力”偏低Lume 是 cua 仓库中运行 macOS 虚拟机guest的工具链guest 内的 GPU 走的是 Apple 的半虚拟化paravirtualized图形路径而不是直通物理显卡。在这种路径下guest 内MTLDevice的能力上报可能不足以让 llama.cpp、MLX-LM 这类运行时选择到高性能 fast path例如supportsFamily:对 Apple GPU family 的查询返回falsemaxThreadgroupMemoryLength报告的 threadgroup memory 偏小。这个 shim 的定位被刻意收窄见 README它只改动 macOS guest 内选定 Metal 能力查询的回答把 Apple GPU family 的“支持”上报抬到一个可配置的天花板ceiling并抬高 threadgroup memory 上限GPU 命令仍然走 Apple 半虚拟化图形路径——不把物理设备直通给 guest不 patch 宿主不修改 guest 内核它不改动Common、Mac、Metal 这几个 family 区间的原始回答它不包含任何私有 feature-profile 钩子、时钟拦截clock interposition、mesh-draw 替换、ray-tracing 覆写或 pipeline 编译回退。也就是说这是一个“只改口供、不升级硬件”的能力上报 shim且作用域限定在单个进程。实现原理constructor 注入 对_MTLDevice的方法替换shim 的全部实现只有一个 Objective-C 文件 Sources/LumeMetalCapabilities.m约 200 行依赖Foundation、Metal和objc/runtime。结合源码可以完整还原它的工作链条进程启动时注入。dylib 通过DYLD_INSERT_LIBRARIES加载后__attribute__((constructor))标记的initializeLumeMetalCapabilitiesL187-L206自动执行先做环境配置校验再NSClassFromString(_MTLDevice)找到 Metal 私有设备类最后替换其initGPUFamilySupport方法的实现。设备初始化能力时才挂钩。当_MTLDevice走initGPUFamilySupport时hookInitGPUFamilySupportL182-L185先调用installDeviceHooks安装真正的能力钩子再调用原始实现。installDeviceHooks用synchronized([device class])加gDeviceHooksInstalled标志保证只安装一次L119-L180。替换三个能力查询方法。replaceMethodL105-L117通过method_setImplementation替换并保存原 IMPsupportsFamily:original || (1001 family appleFamilyMax)即只在 Apple family 区间1001 起内把“不支持”抬为“支持”区间外一律保留设备原始回答L96-L103maxThreadgroupMemoryLength返回max(原始值, 配置值)只升不降L78-L85recommendedMaxWorkingSetSize同样max(原始值, 配置值)且仅当显式设置了环境变量时才安装这个钩子L87-L94。值得注意的是“fail-closed失败即关闭”设计贯穿两处配置校验失败则完全不注入。loadConfigurationL43-L76要求LUME_METAL_APPLE_FAMILY_MAX必须存在且落在1001含到1999之间——缺省、为零、越界或非数字都会直接放弃启用进程保持原始能力私有类/方法缺失则保持原样。installDeviceHooks若发现maxThreadgroupMemoryLength、supportsFamily:等所需方法不存在只会NSLog记录 “leaving stock capabilities unchanged” 并退出不做任何部分替换L139-L143。README 的兼容性章节也明确要求“把私有类或方法缺失当作不受支持unsupported处理”。配置参数与环境变量README 中给出的控制项及行为如下默认值与源码 loadConfiguration 一一对应变量默认值行为LUME_METAL_APPLE_FAMILY_MAX必填Apple family 上报天花板。缺省、为 0、越界源码校验为1001或2000或格式错误时库完全不修改进程LUME_METAL_MAX_THREADGROUP_MEMORY65536把上报的最大 threadgroup memory 抬到至少该字节数max语义只升不降LUME_METAL_RECOMMENDED_WORKING_SET_SIZE不变仅当显式设置时把 recommended working-set size 抬到至少该值README 特别强调这些控制项只应配合已测试过的工作负载与宿主/guest 组合使用“上报了某能力”并不证明使用该能力的所有 Metal API 都能正确工作。构建双架构 dylib、校验脚本与发布打包构建要求 Apple Silicon Xcode Command Line Tools。README 给出的最小流程./Scripts/build.sh ./Scripts/verify.shScripts/build.sh 的实际动作L12-L58用xcrun clang分别以-arch arm64与-arch arm64e编译唯一源文件参数包括-O3 -Wall -Wextra -Werror -fobjc-arc -fvisibilityhidden -dynamiclib、-install_name rpath/LumeMetalCapabilities.dylib、-mmacosx-version-min13.0链接Foundation与Metal框架产出LumeMetalCapabilities-arm64.dylib和LumeMetalCapabilities-arm64e.dylib并做 ad-hoc 签名以-O2编译探针 Tests/metal-capabilities.m 为metal-capabilities可执行文件在输出目录默认dist/生成SHA256SUMS。Scripts/verify.sh 的校验比常规更强L19-L52lipo -verify_arch确认 arm64/arm64e 架构、codesign --verify --strict验签、shasum -a 256 -c SHA256SUMS核对哈希用strings做负向断言两个 dylib 中不得出现研究版行为残留GPU_HOOK_TIME_SCALE、mach_absolute_time、clock_gettime、gettimeofday、MESH_FALLBACK、IGNORE_ARGTYPE、SYNC_COMPUTE也不得出现宽能力行为LUME_METAL_FEATURE_PROFILE、featureProfile、LUME_METAL_FAMILY_MAX否则直接判定 “unexpected research-only behavior” 失败退出。这与 README 的声明相互印证发布产物“刻意窄”不含研究阶段的钩子。verify.sh支持--no-build只校验已有产物。工具链固定与发布打包README 指出与证据匹配的 M1 Ultra/Tahoe 发布二进制使用Command Line Tools 26.4干净的源码修订与二进制溯源记录在 Release/PROVENANCE.md。若安装了匹配工具链可用DEVELOPER_DIR/Library/Developer/CommandLineTools ./Scripts/build.sh ./Scripts/verify.sh --no-buildRelease/PROVENANCE.md 进一步固定了复现细节冻结源码修订d95545418f4789b5fc9ae13b8614c920071f11b5、Apple clang 21.0.0、macOS SDK 26.4、最低部署目标 13.0、dylib 为 69,456 字节的 thin arm64/arm64e 且仅 ad-hoc 签名明确非Developer ID 签名、未公证install name 为rpath/LumeMetalCapabilities.dylib链接 Foundation、Metal、Objective-C runtime、CoreFoundation 与 libSystem。同时提醒工具链与构建环境细节会改变二进制字节因此要记录 Xcode、SDK、源码修订、checkout 路径与输出哈希。Scripts/package-release.sh 以ARTIFACT_DIR RELEASE_DIR两个参数调用它检查三个产物齐全后把已验证的二进制组、通过git archive从冻结修订生成的源码归档前缀cua-d9554541/、以及已提交的 SHA256SUMS 与 PROVENANCE 复制到发布目录拒绝覆盖任何已存在的发布输出最后再跑一次verify.sh --no-build。README 也说明发布资产刻意不提交进dist/。运行单进程启用与能力探针README 给出的标准用法测试画像为 Apple family 天花板1009即 Apple 9并上报 64 KB threadgroup memoryDYLD_INSERT_LIBRARIES/path/to/LumeMetalCapabilities-arm64.dylib \ LUME_METAL_APPLE_FAMILY_MAX1009 \ ./metal-capabilities 1009注意选择与目标进程架构匹配的 dylibarm64 或 arm64e。探针metal-capabilities的源码Tests/metal-capabilities.m很简单解析命令行 family 参数默认 1009调用MTLCreateSystemDefaultDevice()然后打印设备名、查询的 family、supportsFamily:结果与maxThreadgroupMemoryLength便于在注入前后直接对比能力变化。仓库证据目录记录了注入前后的实际变化M1 Ultra/Tahoe见 2026-08-09 证据 README能力Stock未注入注入 safe shimsupportsFamily:1009falsetrue最大 threadgroup memory32,768 字节65,536 字节同一份证据还验证了 fail-closed 行为配置错误的LUME_METAL_APPLE_FAMILY_MAX会产生与 stock 一致的结果确认了“配置不合法即不生效”的声明。移除无持久化状态移除方式就是 README 的 “Remove” 一节从工作负载环境中移除DYLD_INSERT_LIBRARIES与所有LUME_METAL_*变量然后重启该工作负载。shim 不产生任何持久化系统变更——所有修改都发生在被注入进程的运行时内存里method_setImplementation改的是该进程内的方法表。兼容性边界为什么刻意不声明MTLGPUFamilyMetal3README 的兼容性章节是本 shim 最重要的安全约束要点代码依赖 macOS guest 内私有且版本敏感的 Metal 实现细节Apple 可能在任何 macOS 版本中改变它们。应把启用范围限定在单个进程、对每个宿主/guest 版本组合独立测试不要把画像扩大为声明MTLGPUFamilyMetal3。证据 2026-08-09 README 给出了具体原因MLX-LM 会依据MTLGPUFamilyMetal3的回答来选择 residency set而测试中的半虚拟化设备无法创建该路径要求的 residency set——一个声明了MTLGPUFamilyMetal3的宽研究画像在 MLX 设备初始化阶段直接失败。这正是发布版 shim “只改 Apple family 回答”的原因。能力上报不等于功能可用README 明确“被上报的能力并不能证明使用该能力的每个 Metal API 都正确工作”。验证证据M1 Ultra 上的 llama.cpp 与 MLX-LM 结果仓库在 evidence/lume-metal-capability-shim/ 下保留了完整的原始数据JSON、stderr、results.csv、SHA256SUMS。两组代表性结果均为llama-bench十次采样samples_ts的中位数TinyLlama 1.1B Q4_K_M2026-08-09工作负载裸机宿主Stock guestSafe-shim guestGuest 加速Shim/宿主pp5124,871.99 tok/s431.86 tok/s4,786.70 tok/s11.08×98.25%tg128286.71 tok/s12.63 tok/s206.60 tok/s16.36×72.06%Gemma 4 12B QAT Q4_02026-08-10工作负载裸机宿主Stock guestSafe-shim guestGuest 加速Shim/宿主pp512517.88 tok/s71.66 tok/s515.76 tok/s7.20×99.59%tg12852.38 tok/s3.41 tok/s49.67 tok/s14.54×94.82%这两组结果的含义在 macOS Tahoe guest 中注入 Apple-family-only shim 后llama.cpp 的 prompt processing 恢复到接近裸机宿主的水平98%–99.6%token generation 恢复 72%–94.8%。Gemma 4 证据的 stderr 对比也说明机制路径safe-shim 侧记录 Apple family 9、SIMD-group matrix 与 reduction 支持、bfloat16而 stock 侧记录 Apple family 5 且这些 fast path 被禁用。该证据还记录了测量卫生一次与宿主计算负载重叠的 stock 预跑被整体拒绝最终数据全部来自无竞争的窗口。MLX-LM 一侧MLX-LM 0.31.3 MLX 0.32.0Llama-3.2-3B-Instruct-4bit512 token prompt / 128 token generation十次重复工作负载Stock guestSafe-shim guest比值Prompt processing1,656.55 tok/s1,665.47 tok/s1.005×Token generation172.09 tok/s170.86 tok/s0.993×即 safe 画像对 MLX-LM 无实质速度影响但确认了其在 shim 下仍可正常运行。证据 README 同时划定了范围这些运行证明了缩减版 shim 能激活 llama.cpp 的 fast path不依赖私有 feature-profile 钩子或研究钩子的 timing/mesh/ray-tracing/argument-layout/pipeline fallback但并不验证所有 Metal 特性与工作负载llama.cpp 官方b10167发布二进制的 SHA-256 与历史交接二进制不同该证据系列应与历史 M5 数据分开看待。另有第三组 2026-08-11 Muse/Glimmer 64G 数据clean stock/unlocked 对照同目录保留。小结一个“窄而可审计”的能力修正层这个 shim 的价值在于把“虚拟机内 GPU 能力上报不足”这一具体问题约束在最小可审计的面里单文件 ObjC 实现、单一必填环境变量、max语义只升不降、双重 fail-closed配置校验 私有方法缺失检测、负向 strings 断言的构建校验、冻结修订加哈希清单的发布溯源PROVENANCE.md、SHA256SUMS以及明确拒绝扩大画像不声明MTLGPUFamilyMetal3的兼容性边界。它依赖私有、版本敏感的 Metal 内部实现因此使用时必须遵循 README 的告诫限定单进程、按宿主/guest 版本组合独立验证并始终牢记“上报能力不等于能力可用”。代码以 MIT 协议发布LICENSE。【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cua创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考