Core ML 为什么跑不起来？react-native-executorch-fsmn-vad 的 ANE/GPU 执行失败踩坑实录

• 人工智能
• 语音
• 音频

react-native-executorch-fsmn-vad 为 React Native 应用提供可直接在设备端运行的fsmn-vad 语音活动检测（Voice Activity Detection）模型，导出为 ExecuTorch.pte格式程序。不少新手在尝试用 Core ML 后端跑它时，会遇到 ANE/GPU 执行失败的怪象。本文用官方踩坑记录还原完整排查过程，帮你快速避开这些坑，选对后端。

先搞清楚：这个仓库里到底有什么

这个仓库只发布了一个可用的后端构建：

仓库约定：目录里只有NOTES.md而没有.pte，说明该后端被导出过但因执行失败被拒发，笔记里记录的就是失败原因。

Core ML 执行失败：CPU_AND_NE 下的 error0x1

Core ML 后端对这个模型的表现非常"拧巴"（详见 coreml/NOTES.md）：

• 在CPU_AND_NE计算单元下，fp16 和 fp32 都报执行错误0x1，即 ANE 参与调度时直接失败；
• 反复修改compute_unit参数也无法修复，说明不是简单的配置问题；
• 换成CPU_ONLY之后倒是能跑通了——但纯 CPU 的 Core ML 构建相比已发布的 XNNPACK 构建没有任何加速优势，发出来毫无意义。

结论：不是导出错了，而是这个模型本身在 Core ML 的 ANE/GPU 路径上就会执行失败。

⚠️ 最容易忽略的坑：编译模型缓存

排查时有一个关键细节值得所有新手记住：官方在清掉 Core ML 编译模型缓存（~/Library/Caches/executorchcoreml）后重新测试，才得出上面这个结论。

原因在于：过期的编译缓存会静默返回旧的编译产物，制造出"假通过"的假象。如果你改完compute_unit发现"好像好了"，先清缓存再验证，否则很可能只是跑到了旧缓存。

别和 "Invalid blob shape" 搞混了

这个仓库的其他文本 embedding 模型在 Core ML 下也出过故障：对动态序列维度做 masked mean-pool 时，Core ML 会推断出依赖数据的输出形状，被 ANE 和 GPU 后端直接拒绝，报Espresso exception: "Invalid blob shape"。

注意：fsmn_vad 的这次失败是另一种故障、另一种特征，和该问题无关，排查时不要照着那个 issue 对号入座。

对照组：MLX 后端同样翻车

为了确认"是不是模型本身的问题"，团队用 MLX 后端做了对照实验（见 mlx/NOTES.md）。结果很有意思：

• 导出本身很干净，只拆出 3 个子图，比卷积视觉模型（碎成 28~50 片）健康得多；
• 但在真机执行时直接失败，报Method 'forward' failed；
• 同样的输入、同样的测试框架（iPhone 16，ExecuTorch 1.4.1）下，XNNPACK 构建 1.5 ms 出有限输出，MLX 构建直接挂掉——失败是 MLX 产物特有的；
• 即使它能跑也不该发：MLX 版本 2.87 MB，比 XNNPACK 的 1.83 MB大 57%，且模型太小太卷积，权重量化救不回来。

另外有两个算子没有成功 lower：aten.as_strided_copy（MLX 后端无处理器）和aten.clamp_（处理器存在但对Slot类型参数调float()抛TypeError）。

那到底该用哪个？直接用 XNNPACK 构建

答案明确：用 xnnpack/fsmn_vad_xnnpack_fp32.pte，它在 iPhone 16 上跑这个模型只需约1.5 ms。

在 React Native 里接入时，把 react-native-executorch 库模型注册表里的模型常量传给对应的任务管线即可，具体见库文档 README.md 中的说明。模型输入输出契约可在 xnnpack/config.json 查看：输入[1000, 512]的 float32 音频特征，输出[1, 1000, 248]的 float32 结果。

如何获取这些模型文件

如果需要本地查看完整仓库，执行：

git clone https://gitcode.com/hf_mirrors/software-mansion/react-native-executorch-fsmn-vad

⚠️ 版本兼容性提醒

这些文件面向ExecuTorch v1.4.1运行时发布，官方不提供向前兼容保证——旧版运行时可能无法加载。在自己的运行时里加载前，先读一下 ExecuTorch 官方的兼容性说明。

踩坑自查清单 📋

遇到 Core ML / 其他后端执行失败，按顺序自查：

1. 清缓存再验证：删掉 Core ML 编译模型缓存后重测，排除"假通过"；
2. 换 compute_unit 对比：分别在CPU_AND_NE、CPU_ONLY下各测一次，定位是加速路径问题还是通用问题；
3. 找对照组：同一模型换后端（如 XNNPACK）跑同样输入，确认失败是否属于特定后端的产物问题；
4. 看失败特征：记录具体报错（0x1、Method 'forward' failed、Invalid blob shape），不同特征对应不同根因，别混为一谈；
5. 算体积账：就算某后端能跑，体积明显更大且无量化收益，也不值得发布。

小结

Core ML 跑不起来，本质是这个 fsmn-vad 模型在 ANE/GPU 路径上执行失败（error0x1），而CPU_ONLY又无加速价值，所以仓库选择了已验证可用的XNNPACK fp32 构建作为唯一发布后端。新手记住两点即可：执行前先清编译缓存，有疑问就用同模型的另一个后端做对照——这两步能帮你排除大半"玄学"故障。

• 人工智能
• 语音
• 音频