WWDC 2026结束后，Vision Pro开发者社区又活跃起来。苹果在visionOS 3.0里终于允许部分应用调用Neural Engine跑本地AI推理，这让在头显上直接运行大模型做AR问答，从理论变成了可以动手试一试的事。
我们决定实际测一下：用一台M2芯片、16GB统一内存的Vision Pro，部署了Qwen3-Lite-3B和Llama 4 Scout（8B参数，4-bit量化版）这两个轻量模型，看看它们在AR场景里做“看到什么就问什么”的实时问答，表现到底如何。
实测数据：发热快，续航短
测试环境是visionOS 3.0 beta 2。我们模拟了一个常见场景：用户看向桌上的咖啡杯、Switch和一本书，通过语音或手势触发，模型识别物体并生成介绍。
结果挺直接。Qwen3-Lite-3B勉强能用。首次响应大约2.8秒，生成速度在15-18 tokens/s之间。但发热明显：室温25°C左右，持续用5分钟，额头接触区温度就升到39°C；10分钟后接近42°C，已经能感到温热。功耗比正常AR浏览高了约40%，续航从官方的2小时缩水到不足1.5小时。
Llama 4 Scout (4-bit) 的情况更糟。首次响应超过5秒，生成速度只有6-9 tokens/s，推理时AR画面帧率肉眼可见地掉。发热更快，5分钟就到43°C。而且它几乎吃光了全部16GB内存，切换应用或加载稍大的模型就可能崩溃。
作为对比，我们看了Meta Quest 3（骁龙XR2 Gen 2，12GB内存）。虽然原始算力不如M2，但安卓生态对端侧AI更友好，社区优化方案多。实测一个同规模3B量化模型，响应时间3-4秒，速度12-15 tokens/s，温度稳定在36°C左右。这说明，散热设计和系统调度，可能比芯片算力更影响体验。
比算力更麻烦的事：交互和系统限制
模型跑起来只是第一步，想做成能用的功能，开发者还得面对苹果设计哲学带来的一连串关卡。
输入交互是头号难题。Vision Pro没有手柄，全靠眼动、手势和语音。在AR场景里，用户“看着”一个物体，怎么精确触发对它的查询，而不是对准背景里的另一个？现在visionOS API只给粗略的注视点坐标，物体识别还得靠模型自己从摄像头画面里做，这又增加了计算和延迟。语音输入在吵闹环境里识别率也不稳。相比之下，Quest的手柄指向性输入更直接。
系统API限制了模型的“眼睛”。为保护隐私，visionOS对摄像头原始数据的访问限制很严。应用很难拿到未处理的高清实时视频流给大模型分析。你拿到的可能是系统处理过、模糊或裁剪过的画面，这对模型识别精度打击很大。苹果更希望模型处理系统抽象出的“物体”信息，而不是原始图像数据。这基本堵死了让大模型做精细视觉问答的路。
功耗和散热是硬约束。我们测的是间歇性问答。如果要模型持续监听环境并即时反馈，发热和耗电会飙升。苹果对设备表面温度有安全限制，系统可能在过热前主动降频或终止AI进程，导致服务中断。开发者必须在功能完整和设备可用之间做艰难取舍。
开发者怎么选：等苹果，还是绕道走？
目前来看，在Vision Pro上做流畅的本地大模型AR问答助手，用户体验还远没到“好用”的程度。发热、延迟、交互精度，问题一堆。
但这不代表空间计算加端侧AI没戏。一些更垂直的场景可能先行。比如，把模型量化到极小（1.5B甚至更小），只专注一个很窄的领域（比如只识别特定品牌电子产品并显示官网信息），或许能跑通。或者，采用混合架构：简单识别在本地做，复杂推理和知识查询通过加密链路交给云端，平衡体验和隐私。
这让人想起AI在其他领域落地的教训。无论是AI自动回复邮件导致项目延期，还是AI质检误判浪费人力，都说明同一件事：技术上能跑通，和产品上能用，中间隔着交互、成本和工程细节砌成的高墙。Vision Pro的本地大模型之路，现在还卡在砌墙的早期阶段。
开发者生态在升温，但期待即插即用的AI AR体验还为时过早。对多数团队来说，更现实的路径或许是：吃透visionOS 3.0最新API，关注苹果对Neural Engine和模型部署的后续优化，并优先在PC或云端验证想法和场景，而不是过早陷在Vision Pro的工程优化泥潭里。毕竟，先让想法在数字世界跑通，再决定要不要塞进一个会发热的头显，是更稳妥的节奏。
