14、AI/ML在Camera中的应用：NPU/DSP/GPU推理选择、模型量化与剪枝、TFLite/ONNX Runtime部署优化、AI场景识别的功耗控制
各位好，今天我们来聊聊AI/ML在Camera中的应用。这个话题，说白了就是怎么让手机摄像头变得更“聪明”，同时还不怎么费电。我做了这么多年Camera HAL，见过太多项目在AI落地上栽跟头——要么模型跑不动，要么跑起来手机烫得能煎鸡蛋。嗯，今天就把我踩过的坑和积累的经验，一次性讲清楚。
14.1 推理硬件选型：NPU、DSP、GPU，到底该用谁？
先问个问题：你手头有个AI模型要做场景识别，该把它扔到哪个处理器上跑？
我个人习惯，先看三个维度：延迟要求、功耗预算、模型复杂度。这三者决定了你的硬件选型方向。
| 硬件单元 | 典型延迟 | 典型功耗 | 适合场景 |
|---|---|---|---|
| NPU | 5-15ms | 50-200mW | 实时场景识别、人脸检测 |
| DSP | 15-50ms | 30-100mW | 低功耗后处理、图像增强 |
| GPU | 10-30ms | 500-2000mW | 复杂模型、高精度需求 |
我在项目中遇到过最典型的案例：某旗舰机要做实时夜景模式，模型有8层卷积。一开始团队想用GPU跑，结果预览帧率直接掉到15fps，手机背面温度飙到42度。后来切到NPU，延迟降到8ms，功耗只有120mW。你想想看，这差距有多大。
核心原则：能用NPU就别用GPU，能用DSP就别用CPU。但要注意，NPU对模型结构有要求——某些算子（比如动态shape、循环）NPU不支持，得提前做算子兼容性检查。
14.2 模型量化与剪枝：把模型“瘦身”到极致
模型太大，跑不动怎么办？两个办法：量化、剪枝。我一般先做量化，再做剪枝，顺序不能反。
14.2.1 量化：从FP32到INT8
量化说白了就是把模型参数从32位浮点数变成8位整数。精度会掉一点，但模型体积直接缩到1/4，推理速度能快3-5倍。
我曾经在一个人脸检测模型上做过实验：
- FP32模型：12MB，推理延迟22ms
- INT8量化后：3MB，推理延迟6ms
- 精度损失：mAP从0.92降到0.89
嗯，0.03的精度损失换4倍速度提升，这笔账怎么算都划算。但要注意，量化后一定要做校准数据集的验证，我见过有人跳过这步，结果模型在暗光场景下直接崩了。
我的建议：量化时用200-500张代表性图片做校准，覆盖白天、夜晚、室内、室外各种场景。别偷懒，这一步省不了。
14.2.2 剪枝：砍掉不重要的连接
剪枝就是去掉模型中那些权重接近0的连接。我习惯用结构化剪枝，按通道或卷积核来剪，这样对硬件更友好。
举个例子，一个MobileNetV2模型，我剪掉30%的通道后：
- 模型大小从14MB降到9MB
- 推理速度提升约25%
- 精度只掉了0.5%
为什么会这样？因为很多通道其实学到的特征高度冗余，砍掉它们对最终结果影响很小。
避坑指南：我曾经在剪枝后忘了做微调（fine-tune），结果模型精度直接掉了5个点。记住，剪枝完一定要用原始数据集再训练几个epoch，让模型重新适应。
14.3 TFLite / ONNX Runtime 部署优化
模型训练好了，怎么部署到手机上？目前主流方案就两个：TFLite和ONNX Runtime。我两个都用过，说说我的感受。
14.3.1 TFLite：Google的亲儿子
如果你用TensorFlow训练模型，TFLite是最自然的选择。它有几个关键优化点：
- Delegate机制：通过GPU Delegate或NNAPI Delegate把计算卸载到硬件加速器
- 模型转换：用TFLite Converter做量化、优化
- 运行时内存管理：用Arena分配器减少内存碎片
// TFLite GPU Delegate 示例
TfLiteGpuDelegateOptionsV2 options;
options.inference_preference = TFLITE_GPU_INFERENCE_PREFERENCE_SUSTAINED_SPEED;
options.inference_priority1 = TFLITE_GPU_INFERENCE_PRIORITY_MIN_LATENCY;
auto* delegate = TfLiteGpuDelegateV2Create(&options);
interpreter->ModifyGraphWithDelegate(delegate);
这段代码我用了很多次。注意那个SUSTAINED_SPEED选项，它会让GPU在性能和功耗之间做平衡，而不是一味追求最快。
14.3.2 ONNX Runtime：跨平台利器
如果你的模型来自PyTorch或其他框架，ONNX Runtime是更好的选择。它支持Execution Provider机制，可以灵活切换后端：
- CPUExecutionProvider：兜底方案
- CUDAExecutionProvider：NVIDIA GPU专用
- NNAPIExecutionProvider：Android NPU/DSP加速
我个人习惯，在Android上优先用NNAPI Execution Provider。它会把算子自动映射到NPU或DSP上，省去手动调度的麻烦。
性能对比（以MobileNetV2为例）：
| 方案 | 延迟 | 功耗 |
|---|---|---|
| TFLite CPU | 35ms | 800mW |
| TFLite GPU Delegate | 12ms | 600mW |
| ONNX Runtime NNAPI | 8ms | 150mW |
14.4 AI场景识别的功耗控制
最后聊聊功耗。AI场景识别是个典型的“一直开着”的功能——手机要持续分析画面内容，判断是风景、人像还是食物。如果处理不好，电池半天就没了。
我总结了一套三级功耗控制策略：
- 帧率分级：
- 静止场景：1fps推理（功耗最低）
- 轻微运动：5fps推理
- 剧烈运动：15fps推理
- 模型分级：
- 低功耗模式：轻量模型（MobileNetV3-Small）
- 高精度模式：标准模型（MobileNetV3-Large）
- 硬件动态切换：
- 低负载：DSP处理
- 中负载：NPU处理
- 高负载：GPU处理（极少触发）
我在一个项目中实现了这套策略，结果AI场景识别的平均功耗从450mW降到了120mW。怎么做到的？核心就是不要一直用最高精度跑。你想想看，手机放在桌上不动，你非要每秒30帧跑大模型，那不是浪费电吗？
一个小技巧：用运动传感器（加速度计+陀螺仪）做触发信号。检测到手机静止时，直接降低推理频率。这个方案几乎不增加额外功耗，效果却很明显。
14.5 知识体系总览
下面这张图是我自己整理的AI Camera优化知识体系，涵盖了从硬件选型到部署优化的完整链路。你可以把它当作一个检查清单，做项目时对照着看，基本不会漏掉关键环节。
好了，这一章的内容就到这里。AI在Camera中的应用，说到底就是在功耗、延迟、精度之间找平衡。没有银弹，只有根据具体场景做取舍。希望我分享的这些经验，能帮你少走一些弯路。