你用手机里的 AI 擦掉照片路人，或者让它离线处理一段文字，速度不仅取决于模型有多聪明，也取决于应用能不能把手机芯片真正用起来。模型像一台发动机，部署工具链则负责把动力传到车轮。中间层一旦效率低，再强的芯片也可能只是在等待。
React Native ExecuTorch v0.10 想解决的正是这段“传动系统”。它面向 React Native 开发者。React Native 是用 JavaScript 或 TypeScript 构建原生移动应用的框架；ExecuTorch 则是 PyTorch 面向手机和嵌入式设备的模型运行方案，负责把训练好的模型送到不同芯片后端执行。
这次最醒目的数字是“最高加速 92 倍”。但这个结果以及本文涉及的主要性能数据，目前都只来自作者 d_arthez 发布的一篇 Reddit 帖子，尚无正式基准报告或原始测试数据可供交叉验证。
92倍，到底快在哪里？
据该 Reddit 帖子，v0.10 相比 v0.9 在若干特定模型组上取得显著加速。其中，FastSAM 的实例分割推理最高达到 92 倍。
这里有两个限定词不能省。第一是“最高”，它代表测得的峰值，不是稳定适用于所有任务的平均结果。第二是“实例分割”——它不仅判断照片里有什么，还要给每个独立物体画出像素级轮廓。例如，照片中有三个人，它需要分别勾出三个人的边界。这个任务与语言模型生成文字并不是一回事，两者的加速倍数不能直接横向比较。
所以，更准确的说法不是“手机 AI 全面快了 92 倍”，而是“在特定测试条件下，FastSAM 相比上一版最高快了 92 倍”。
语言模型也有提升，只是数字温和得多。帖子称，在 LLM——也就是大语言模型——当中，Qwen3 0.6B 的增益最大：处理长提示词时，速度超过 v0.9 的 3 倍。长提示词意味着模型开始回答前，需要先读入较多文字。端侧设备的算力、内存、电量和散热都很有限，因此三倍以上的提升依然可能直接改变交互体验。
真正的变化，是把黑箱拆开
速度数字背后是一场结构重写。据 React Native ExecuTorch 官方文档，团队放弃了 v0.9 将任务封装在不透明 C++ 原生模块里的做法，转而使用可以检查和替换的 TypeScript pipelines——也就是把模型运行过程拆成开发者能读、能改的处理流水线。
可以把旧结构想成一台封死外壳的机器：它能工作，但开发者很难看清某一步为何变慢，也不容易换掉其中一个零件。新结构把处理步骤摆到台面上。帖子还称，它覆盖主要的芯片后端，并让自定义模型更容易接入；官方文档列出的后端包括 Core ML、MLX 和 Vulkan。
代价是新 API 不向后兼容。官方文档显示，团队把旧实现保留在单独的 legacy 入口中，让应用可以逐页迁移，新旧代码也能暂时共存。这不像一次普通的局部优化，更像更换发动机，同时为现有应用留下回退通道。
为什么值得关注？
端侧推理——直接在手机等用户设备上运行模型——可以减少对云端服务的依赖，降低网络等待，并让数据留在本机。但它一直受制于手机有限的资源。部署层每省下一份重复工作，都可能让原本只能放在服务器上的体验更接近可用。
这条路线也来自具体需求。据 Software Mansion 介绍，React Native ExecuTorch 源于团队开发照片橡皮擦应用时积累的端侧模型封装工作，并在 2024 年 11 月发布首版。当时公共 API 只有一个运行语言模型的 hook——可理解为供应用调用的一处接口——团队已经预告会加入照片橡皮擦所用的 SAM。到了 v0.10，发布演示中最抢眼的 FastSAM 同样属于图像分割领域，虽然它不是原版 SAM。
因此，v0.10 更值得看的不只是一个峰值数字，而是端侧工具链开始同时处理两件难事：把特定模型跑得更快，也让应用开发者更容易检查、替换和迁移整个推理流程。
局限与未知
- 帖子没有披露测试设备、芯片后端、量化方式、输入长度、线程配置、预热策略和原始数据，92 倍与 3 倍以上的结果暂时无法复现或交叉核验。
- “支持所有主要芯片后端”“更容易接入自定义模型”等表述范围含糊，现有材料不足以判断具体覆盖边界和接入成本。
- 92 倍只对应 FastSAM 的特定实例分割测试；Qwen3 0.6B 的结果则限定在长提示词场景。两者都不能外推为所有模型、所有手机或所有端侧任务的普遍提升。