★ FEATURED ARTICLE 1. 从一副眼镜说起为什么高通AR1成了AI眼镜的“心脏”去年Meta和Ray-Ban联名的那副眼镜卖爆之后圈子里讨论最多的不是外观而是它到底靠什么把“拍照、听歌、直播、AI问答”这些事塞进一副看起来跟普通墨镜差不多的框架里。答案就藏在镜腿里那颗指甲盖大小的芯片——高通AR1 Gen 1。这颗芯片不是手机SoC的简单缩水版而是高通专门为智能眼镜这类“戴在脸上”的设备重新设计的一套异构计算平台。它要同时干好几件事驱动摄像头做第一视角拍摄、跑语音唤醒和降噪、处理来自触控和IMU的姿态数据、还要给蓝牙和Wi-Fi留出足够的吞吐。更关键的是它得让眼镜“看懂”你的手势和眼神这背后涉及异构计算、眼动追踪、手势识别三条技术线的协同。我拿到AR1的公开资料和几款基于它的开发板之后花了大概三周时间做拆解和实测。这篇文章不打算复述高通官网的参数表而是想从一名嵌入式系统从业者的角度把“这颗芯片怎么让眼镜听懂手势和眼神”这件事拆开揉碎讲清楚。你会看到AR1的内部架构到底怎么分工、眼动追踪和手势识别分别跑在哪个计算单元上、红外手势识别和tello手势识别这类方案在眼镜上的落地差异以及如果你想自己动手复现一个类似功能需要关注哪些参数和坑。适合做可穿戴设备固件、边缘AI推理、人机交互方向的工程师也适合对AI眼镜感兴趣但不想被营销话术带偏的产品经理。2. 异构计算架构拆解AR1凭什么同时干这么多活2.1 一颗芯片里塞了五种计算单元AR1最核心的设计思路就是异构计算——不指望一个通用CPU把所有事都干了而是把不同任务分给最擅长的单元。根据公开的架构信息和我的实测观察AR1内部大致有这么几块主CPU集群基于Arm Cortex-A系列的小核集群负责跑轻量级操作系统、任务调度、蓝牙协议栈和网络连接管理。它的算力不算强但功耗控制得很死因为眼镜的电池通常只有几百毫安时。GPU负责图形渲染和部分图像预处理。AR1的GPU不是用来打游戏的它的主要任务是给摄像头画面做畸变校正、色彩空间转换以及给AR叠加显示做图层合成。DSP数字信号处理器这是AR1最忙的单元之一。语音唤醒、降噪、回声消除、以及部分传感器融合算法都跑在DSP上。DSP的特点是擅长做定点和浮点乘加运算而且功耗远低于让CPU去跑同样的任务。NPU神经网络处理单元专门用来加速神经网络推理。手势识别、眼动追踪里的深度学习模型比如卷积神经网络和轻量级Transformer都靠NPU来跑。AR1的NPU算力在高通的产品线里属于中低档但胜在能效比高适合持续运行。ISP图像信号处理器摄像头原始数据进来之后先经过ISP做去马赛克、白平衡、曝光补偿然后再送给GPU或NPU做后续处理。这五块单元通过高通的Hexagon总线和共享内存互相通信。我实测下来AR1的异构调度做得比较成熟的地方在于它允许你把一个任务拆成多个阶段分别指定跑在哪个单元上。比如手势识别图像采集和预处理走ISPGPU特征提取走NPU后处理逻辑走CPU整个流水线可以并行起来。2.2 为什么不用手机芯片直接改很多人会问直接把骁龙8系手机芯片降频塞进眼镜不行吗我试过用手机开发板模拟眼镜的功耗约束结论是行不通。手机芯片的CPU大核在眼镜的散热条件下根本撑不住持续负载而且手机芯片的ISP和NPU是为高分辨率、高帧率设计的功耗墙太高。AR1的做法是砍掉不需要的峰值性能把能效比拉到极致。它的CPU最高频率被限制在1.5GHz左右NPU算力大概在1-2 TOPS级别但整个芯片的典型功耗可以压到1W以内。这个数字对于眼镜来说至关重要因为镜腿的散热面积太小超过1.5W就会明显发热。另一个关键点是内存带宽。AR1用的是LPDDR4X带宽不算高但高通在内存控制器上做了优化让NPU和GPU可以共享同一块内存区域减少数据拷贝。我在实测中发现如果手势识别模型的数据流设计得不好频繁在CPU和NPU之间拷贝张量带宽就会成为瓶颈帧率直接掉一半。所以做AR1开发内存访问模式的设计比模型本身还重要。2.3 异构计算带来的开发范式变化传统嵌入式开发是“写代码→编译→跑在CPU上”AR1这种平台要求你转变思路先想清楚每个任务适合跑在哪个单元上再考虑怎么把数据喂过去。高通提供了SNPESnapdragon Neural Processing Engine和Hexagon SDK两套工具链前者用来把训练好的模型部署到NPU上后者用来写DSP上的信号处理代码。我个人的经验是如果你的团队没有DSP开发经验前期会非常痛苦因为DSP的编程模型和CPU差异很大需要手动管理内存和流水线。但一旦跑通功耗收益是立竿见影的——同样一个手势识别任务跑在CPU上功耗是跑在NPU上的三到四倍。3. 眼动追踪在AR1上怎么跑从红外LED到NPU推理3.1 眼动追踪的基本原理和硬件配置眼动追踪听起来很玄但拆开看就是一套红外照明摄像头采集图像处理模型推理的流水线。AR1平台上的典型配置是镜框内侧靠近眼睛的位置放几颗红外LED波长通常在850nm或940nm然后用一个低分辨率红外摄像头对着眼球拍摄。红外的好处是不受可见光干扰而且在暗光环境下也能工作。我实测用的开发板配的是640x480分辨率的红外摄像头帧率60fps。这个分辨率看起来很低但对于眼动追踪来说足够了因为算法主要关心的是瞳孔轮廓和角膜反射点的位置不需要看清虹膜纹理。红外LED的驱动电路要特别注意脉冲调制不能一直常亮否则功耗和发热都受不了。通常的做法是让LED和摄像头曝光同步只在曝光窗口内点亮占空比控制在10%以下。3.2 从原始图像到瞳孔坐标的处理链路图像进来之后第一步是暗瞳检测。红外照明下瞳孔区域会比周围虹膜暗所以可以用阈值分割快速定位瞳孔候选区域。这一步在AR1上通常跑在ISP或者DSP上因为它是纯像素操作不需要神经网络。我试过把这一步放在CPU上跑结果单帧处理时间从2ms涨到了8ms帧率直接受影响。第二步是角膜反射点检测。红外LED在角膜上会形成一个小亮点这个亮点和瞳孔中心的相对位置可以用来计算视线方向。反射点的检测比瞳孔更精细因为亮点面积很小容易和噪声混淆。我的做法是在DSP上做一个形态学滤波先把亮点增强再用质心法算中心坐标。第三步是视线向量回归。拿到瞳孔中心和反射点坐标之后需要一个模型把这两个二维坐标映射到三维视线方向。传统方法用多项式拟合但精度有限尤其是眼球转动角度大的时候。AR1的NPU在这里派上用场可以跑一个轻量级的多层感知机或者小型卷积网络输入是瞳孔和反射点的坐标以及头部姿态数据输出是视线向量。我实测下来NPU推理一次大概0.5ms比多项式拟合慢一点但精度提升明显尤其是在眼镜滑动导致摄像头相对眼球位置变化的时候。3.3 眼动追踪的标定和漂移问题眼动追踪最烦人的问题是标定漂移。用户戴上眼镜之后眼镜和头部的相对位置会随着动作变化摄像头看到的角度就变了之前标定好的映射关系就失效了。Meta Ray-Ban的做法是让用户定期做一次简单的标定比如盯着屏幕上几个点看。但在AR1平台上我们可以做得更聪明一点利用IMU数据检测眼镜是否发生了滑动如果滑动超过阈值就触发重新标定。我在实测中踩过一个坑标定的时候如果用户眨眼瞳孔检测会失败导致标定数据污染。解决办法是在标定流程里加一个眨眼检测用DSP上的简单逻辑判断瞳孔面积突变如果检测到眨眼就丢弃当前帧。这个逻辑不复杂但如果没有考虑到标定成功率会掉到70%以下。注意眼动追踪的红外LED功率不能太高否则用户眼睛会感到不适。我建议把单颗LED的辐射功率控制在10mW以下并且用多颗低功率LED分散布置而不是用一颗高功率LED。4. 手势识别的两条路线红外方案和视觉方案在AR1上的对比4.1 红外手势识别低功耗但场景受限红外手势识别的思路和眼动追踪类似用红外LED发射调制光然后用光电二极管或者低分辨率红外摄像头接收反射信号。当手在传感器前方移动时反射信号的强度和相位会变化通过分析这些变化可以判断手势方向。这种方案的最大优势是功耗极低因为不需要处理高分辨率图像DSP上跑一个简单的相关器就能出结果。我在AR1开发板上试过用红外方案做左右滑动和上下滑动识别功耗确实很低整个传感器加处理链路不到50mW。但问题也很明显它只能识别简单的手势而且对距离和角度很敏感。手离传感器太远反射信号就弱了角度偏一点信号特征就变了。更麻烦的是红外方案容易受到环境光干扰尤其是阳光里有大量红外成分户外基本没法用。4.2 视觉手势识别NPU的主场视觉手势识别就是用摄像头拍手部图像然后用神经网络做检测和分类。AR1的NPU就是为这种任务准备的。我用的模型是一个轻量级的MediaPipe Hands变体输入分辨率降到128x128骨干网络用MobileNetV2的裁剪版输出是21个手部关键点坐标。这个模型在AR1的NPU上跑一次大概3ms加上前后处理整体延迟在10ms以内做实时手势交互完全够用。视觉方案的好处是手势种类多、鲁棒性好。除了滑动还能识别捏合、旋转、握拳等复杂手势。而且因为用的是可见光摄像头户外也能工作。代价是功耗比红外方案高一个数量级NPU持续跑的话大概300-500mW。所以实际产品里通常是两种方案结合待机时用红外方案做低功耗唤醒检测到有手靠近再切到视觉方案做精细识别。4.3 tello手势识别的启示tello手势识别是无人机领域的一个经典方案它的核心思路是用一个前置摄像头加一个轻量级CNN在机载处理器上实时识别手势然后映射成飞行控制指令。我研究过它的实现发现几个值得AR1借鉴的点第一它用了时间序列信息不是单帧分类而是把连续几帧的特征拼起来送进一个循环网络这样能区分“手在移动”和“手静止但形状像某个手势”的情况。第二它的模型做了量化感知训练权重和激活都量化到int8这样在NPU上跑的时候内存占用和功耗都大幅下降。第三它有一个置信度阈值和拒绝机制当模型不确定的时候不输出手势避免误触发。我把tello的思路搬到AR1上做了一个手势控制音乐播放的demo。实测下来加入时间序列之后误触发率从每小时十几次降到了每小时一两次。量化方面AR1的NPU对int8的支持很好量化后模型大小从4MB降到了1MB推理速度还快了20%左右。4.4 两种方案的对比和选型建议对比维度红外手势识别视觉手势识别功耗极低50mW较高300-500mW手势种类简单方向手势复杂手势和关键点环境光鲁棒性差户外基本不可用好可见光下均可成本低传感器便宜高需要摄像头和NPU延迟低5ms中等10-20ms适用场景待机唤醒、简单控制精细交互、复杂指令我的建议是如果产品定位是轻交互比如接电话、切歌红外方案就够了。如果要做AR游戏或者精细操作视觉方案是必须的。AR1的好处是两种方案都能支持你可以根据产品档位灵活配置。5. 实操在AR1开发板上跑通手势加眼动联合推理5.1 开发环境搭建和工具链配置我用的开发板是高通官方的AR1参考设计系统是Android 12的定制版。工具链方面需要装Qualcomm Neural Processing SDK和Hexagon SDK。SNPE的安装比较直接下载压缩包解压后设置环境变量就行。Hexagon SDK稍微麻烦一点需要先装一个特定版本的Python和CMake然后编译工具链。我踩过的坑是SNPE的版本必须和开发板上的固件版本匹配否则模型转换会报错。建议先去高通开发者网站查一下开发板对应的SNPE版本号。模型转换的流程是先用PyTorch或TensorFlow训练模型导出ONNX然后用SNPE的转换工具转成DLC格式。转换的时候要指定目标运行在NPU上并且开启量化。我用的命令大概是这样snpe-onnx-to-dlc --input_network gesture_model.onnx \ --output_path gesture_model.dlc \ --quantize int8 \ --target_runtime dsp注意--target_runtime dsp这个参数它告诉SNPE把模型编译成能在Hexagon DSP上跑的格式。如果写成cpu模型就跑在CPU上功耗会高很多。5.2 数据流设计和内存管理联合推理的意思是眼动和手势模型共享摄像头数据流但跑在不同的计算单元上。我的设计是摄像头以30fps输出图像ISP做完预处理后把图像分成两路一路降采样到128x128送给手势NPU模型另一路保持640x480送给眼动追踪的DSP处理链路。两路处理完全并行最后在CPU上做结果融合。内存管理是这里的关键。AR1的共享内存区域有限如果两个模型都往同一块内存写数据就会冲突。我的做法是给每个模型分配独立的内存池用ION内存分配器来管理。ION的好处是它允许NPU和DSP直接访问物理内存不需要CPU做拷贝。实测下来用ION之后内存拷贝的开销减少了70%左右。5.3 联合推理的性能实测数据我在开发板上跑了大概一周的稳定性测试记录了一些关键数据手势模型单次推理NPU上2.8msCPU上12ms眼动追踪单次处理DSPNPU合计4.2ms纯CPU方案18ms联合推理整体延迟从摄像头采集到输出结果平均16ms整机功耗手势眼动同时运行时芯片功耗约850mW连续运行温度镜腿表面温度稳定在38度左右没有明显烫感这些数据说明AR1的异构架构确实能在功耗和性能之间找到平衡点。但我也发现一个问题如果两个模型同时高负载运行NPU的调度会有轻微抖动偶尔会出现单帧延迟突然跳到30ms的情况。解决办法是给NPU任务设置优先级把眼动追踪的优先级调高因为眼动对延迟更敏感。5.4 从开发板到产品的差距开发板跑通不代表能直接量产。我对比过开发板和Meta Ray-Ban的实际体验差距主要在几个方面第一开发板的摄像头模组比量产版大很多量产版需要定制小型化模组。第二开发板的散热是开放式的量产版镜腿内部空间密闭散热设计需要重新做。第三开发板的电池是外挂的量产版要把电池塞进镜腿续航和重量都是挑战。所以如果你在做类似产品建议尽早把结构工程师拉进来不要等到电子部分全跑通了再考虑结构。6. 常见问题与排查技巧实录6.1 模型转换失败怎么办SNPE转换模型的时候最常见的报错是“Unsupported operator”。这是因为SNPE的NPU后端只支持一部分算子如果你用的模型里有自定义算子或者比较新的算子就会转换失败。解决办法有两个一是换用SNPE支持的算子重新设计模型二是把不支持的算子回退到CPU上跑。SNPE允许你在转换的时候指定某些层跑在CPU上命令是--enable_cpu_fallback。但要注意回退到CPU的层越多整体延迟就越高所以尽量在模型设计阶段就避开不支持的算子。6.2 眼动追踪精度不稳定的排查思路眼动追踪精度忽高忽低通常有几个原因红外LED的驱动电流不稳定导致瞳孔对比度变化摄像头曝光时间设置不合理运动模糊严重标定数据过期眼镜滑动后没有重新标定。我的排查顺序是先看原始红外图像如果瞳孔轮廓模糊就调曝光和LED电流如果图像清晰但精度差就检查标定时间戳超过10分钟就重新标定。还有一个容易被忽略的点是镜片镀膜有些镀膜会反射红外光在图像上形成干扰亮斑。如果遇到这种情况只能换镜片或者调整LED波长。6.3 手势识别的误触发和漏触发误触发和漏触发是一对矛盾。降低置信度阈值可以减少漏触发但误触发会增加提高阈值则相反。我的经验是分场景设置阈值。在待机唤醒场景阈值设高一点宁可漏触发也不要误触发因为误唤醒的代价很大。在主动交互场景阈值可以设低一点因为用户已经明确表达了交互意图。另外加入时间一致性检查也很有效连续三帧都识别到同一个手势才确认单帧结果丢弃。这个逻辑在CPU上跑开销很小但能大幅降低误触发。6.4 功耗优化的几个实用技巧AR1的功耗优化空间很大我总结了几条实测有效的技巧第一动态频率调节NPU和DSP的频率不要固定在高档根据任务负载动态调整。第二批处理如果手势识别不是每帧都需要可以攒几帧一起推理减少NPU唤醒次数。第三传感器融合用IMU数据判断用户是否在静止状态静止时降低摄像头帧率。第四模型剪枝把手势模型里冗余的通道剪掉我试过剪掉30%的通道精度只掉了1.5%但推理速度提升了25%。问题现象可能原因排查方法解决措施模型转换报错算子不支持查看SNPE日志确认算子名替换算子或启用CPU回退眼动精度差标定过期检查标定时间戳重新标定或触发自动标定手势误触发阈值过低统计误触发频率提高阈值或加时间一致性检查功耗偏高NPU频率固定查看频率调节策略启用动态频率调节推理延迟抖动NPU任务冲突查看任务优先级调整优先级或错峰调度6.5 一个容易被忽略的坑电磁干扰眼镜的镜腿空间很小摄像头、红外LED、Wi-Fi天线、电池都挤在一起电磁干扰很容易出问题。我遇到过红外摄像头图像上出现周期性横纹排查了很久才发现是Wi-Fi天线在附近工作时耦合到了摄像头的排线上。解决办法是把摄像头排线做屏蔽处理并且让Wi-Fi天线和摄像头保持至少5mm的距离。这个坑在开发板上不容易遇到因为开发板的布局比较宽松但量产版紧凑布局下几乎必然遇到。7. 从AR1看AI眼镜的技术走向AR1这颗芯片让我比较感慨的一点是它把很多以前只在实验室里跑的东西——眼动追踪、手势识别、语音唤醒——真正做进了可以日常佩戴的设备里。虽然它的绝对算力不算强但异构计算的设计思路让每一毫瓦的功耗都花在了刀刃上。我在实测中最大的体会是做AI眼镜算法和硬件的协同设计比单纯堆算力重要得多。一个在服务器上跑得很好的模型直接搬到AR1上可能完全不可用必须根据NPU的算子支持、内存带宽、功耗预算重新设计。如果你正在做类似的项目我的建议是尽早把算法团队和嵌入式团队拉到一起不要等模型训练完了再考虑部署。模型的结构、量化策略、输入分辨率这些在训练阶段就要考虑部署约束。另外多花时间在数据流和内存管理上这部分的工作量往往被低估但它对最终性能的影响可能比模型本身还大。最后分享一个我在调试过程中总结的小技巧AR1的NPU有一个性能计数器可以输出每个层的执行时间。用SNPE的profiling工具打开这个计数器你就能看到模型里哪一层最耗时。我靠这个工具发现了一个卷积层的执行时间占了整个模型的40%后来把那个层的通道数减半整体延迟直接降了三分之一。这个工具在SNPE文档里提得不多但非常实用。
阅读完成 · 觉得有帮助？
