3. 功耗模型分析：CPU/GPU/DSP/NPU在SLAM中的功耗占比与热分布

做AR眼镜的SLAM，最头疼的问题是什么？

不是精度不够，不是鲁棒性差。是烫。

我当年做第一代AR原型机的时候，跑ORB-SLAM2，CPU直接飙到85度。用户戴了五分钟就摘下来，说「这眼镜能煎鸡蛋」。嗯，从那以后，功耗和热分布就成了我设计架构时的第一优先级。

今天咱们就来拆解一下，SLAM算法在不同计算单元上的功耗到底怎么分布的。说白了，就是搞清楚「电都去哪儿了」。

3.1 各计算单元的基础功耗画像

先给个直观的数据。我整理了一个典型移动SoC在运行SLAM时的功耗对比表。注意，这是「运行SLAM」时的数据，不是跑分软件的数据。

计算单元	典型功耗(W)	SLAM负载占比	峰值温度(°C)	能效比(帧/瓦)
CPU (A78大核)	2.5 - 4.0	35% - 45%	75 - 85	3 - 5
GPU (Adreno 650)	3.0 - 5.5	25% - 35%	70 - 80	8 - 12
DSP (Hexagon)	0.8 - 1.5	10% - 15%	55 - 65	15 - 20
NPU (AI引擎)	1.0 - 2.0	5% - 10%	50 - 60	25 - 35

看到没？CPU虽然灵活，但能效比最低。NPU能效比是CPU的5到7倍。你想想看，如果能把SLAM里那些重复性的计算挪到NPU上，省下来的电量够眼镜多跑两个小时。

3.2 热分布：为什么眼镜腿比镜框烫？

我遇到过最尴尬的事，是给客户演示时，眼镜腿烫得他耳朵发红。后来我们专门做了热成像分析，才发现问题出在热传导路径上。

AR眼镜的热分布有几个特点：

• 热源集中：SoC芯片通常放在镜腿前端，离耳朵很近
• 散热面积小：眼镜总共就那么点表面积，还没手机十分之一大
• 用户接触敏感：皮肤对42度以上就开始不适了

我画了一张典型的热分布图，你看看就明白了。

你看，SoC那个位置是深红色的。我们实测下来，如果CPU持续满载，镜腿表面温度能在5分钟内从35度升到48度。而镜片区域因为远离热源，温度基本没变化。

3.3 不同SLAM阶段的功耗分解

咱们把SLAM拆开来看。一个典型的视觉SLAM流程，功耗分布是这样的：

1. 图像采集（5%）：摄像头和ISP，功耗很低，但必须一直开着
2. 特征提取（35%）：ORB、FAST、SIFT这些，CPU算起来很费电
3. 特征匹配（25%）：暴力匹配或者FLANN，内存访问频繁
4. 位姿估计（15%）：PnP、BA优化，计算密集但频率低
5. 地图维护（10%）：关键帧插入、回环检测，偶尔触发
6. 渲染输出（10%）：GPU绘制，AR叠加显示

我做过一个实验：把特征提取从CPU挪到NPU上跑，整机功耗从4.2W降到了2.8W。降了33%！代价是什么？特征点的重复率从95%降到了92%。嗯，对于AR应用来说，这个精度损失完全可以接受。

3.4 动态功耗管理策略

光知道功耗分布还不够，你得会「管」它。我总结了几条实战经验：

• 按需降频：当IMU数据表明眼镜静止时，把特征提取频率从30fps降到5fps。功耗直接砍半。
• 异构调度：把重复性高的任务（如描述子计算）固定到NPU，把控制逻辑留在CPU。
• 温度感知：当镜腿温度超过43度时，自动降低GPU频率，优先保证用户舒适度。

我曾经在一个项目里，就因为没做温度感知，导致用户投诉「眼镜烫耳朵」。后来加了热敏电阻和动态调频策略，投诉率直接降为零。

嗯，这里要注意一点：动态调频不能太激进。我见过有人把CPU频率从2.0GHz降到0.5GHz，结果SLAM直接跟丢了。你得留出足够的算力余量，保证在快速运动时也能跟上。

3.5 实测数据与优化建议

最后，给出一组我们实测的优化前后对比数据：

指标	优化前（纯CPU）	优化后（CPU+NPU+DSP）	提升幅度
整机功耗	4.5W	2.1W	↓53%
镜腿温度	48°C	39°C	↓9°C
SLAM帧率	30fps	28fps	↓7%
定位精度	±2cm	±3cm	可接受

你看，功耗降了一半多，温度降了9度，但SLAM性能只损失了一点点。这就是异构计算的价值。

说白了，做AR眼镜的SLAM，你不能只盯着算法精度。你得把功耗和热分布当成第一性原理来考虑。用户不会因为你SLAM精度高1毫米就多戴半小时，但一定会因为烫耳朵而立刻摘下来。

嗯，今天就聊到这儿。记住一句话：在AR眼镜上，功耗就是用户体验，温度就是产品生命线。

---