1. 混合架构概述
各位同学，咱们今天聊聊混合架构。说白了，就是让手机、平板、甚至IoT设备里的几个“大脑”一起干活。
我刚开始做端侧推理那会儿，大家还习惯把模型一股脑扔给CPU。结果呢？发热、卡顿、掉电快。后来发现，这就像让一个数学家去搬砖——不是不能干，但效率太低了。真正的解法，是让不同硬件干自己最擅长的事。
端侧四大计算单元：谁擅长什么？
先看看我们手头有哪些“兵”。端侧设备里，常见的计算单元就这四位：
- CPU（中央处理器）：通用性最强，什么活都能接。但单论并行计算，它其实是个“单核战神”。
- GPU（图形处理器）：天生为并行计算设计。上千个小核心一起上，矩阵乘法这种活它最拿手。
- NPU（神经网络处理器）：专门为AI推理设计的“特种兵”。卷积、激活函数这些操作，它硬件层面就优化好了。
- DSP（数字信号处理器）：低功耗、低延迟。处理音频、传感器数据这类流式任务，它是专家。
核心观点：没有哪个单元是万能的。混合架构的精髓，就是“让专业的人干专业的事”。
分工逻辑：谁该做什么？
我在项目中遇到过不少同学，上来就问：“NPU这么强，是不是所有模型都跑NPU？” 嗯，这是个好问题，但答案没那么简单。
我一般这样分：
| 任务类型 | 推荐单元 | 原因 |
|---|---|---|
| 控制逻辑、分支判断、小模型 | CPU | 灵活，延迟可控。适合处理稀疏、不规则的计算。 |
| 大矩阵运算、卷积层 | GPU / NPU | 并行度高。GPU通用性强，NPU能效比更高。 |
| 定点量化模型、连续推理 | NPU | 硬件加速单元，功耗低。适合长时间运行的视觉模型。 |
| 音频处理、传感器融合 | DSP | 超低功耗，实时性好。唤醒词检测这类任务首选。 |
个人经验：我曾经把一个语音唤醒模型硬塞给NPU跑，结果功耗反而比DSP高了3倍。后来才意识到，DSP的流水线架构对短序列处理有天然优势。选硬件，不能只看算力，还得看任务特征。
协同模式：它们怎么配合？
分工明确了，接下来就是协同。你想想看，一个典型的端侧推理流程，其实是个“接力赛”。
我习惯把协同模式分成三种：
- 串行流水线：一个单元干完，交给下一个。比如CPU先做预处理，然后NPU跑模型，最后CPU做后处理。简单、稳定，但会有等待开销。
- 并行计算：多个单元同时干活。比如GPU和NPU各跑模型的一部分，最后合并结果。效率高，但同步是个坑。
- 异构调度：系统根据负载动态切换。比如低负载时用DSP省电，高负载时唤醒NPU。这是最智能的模式，也是实现难度最大的。
为什么会这样？因为端侧资源太有限了。你不能像服务器那样堆硬件，只能靠调度来“挤”性能。
一张图看懂混合架构
下面这张图，是我自己总结的端侧混合架构分工与协同逻辑。你看一眼，基本就明白整体脉络了。
实际落地中的坑与经验
理论说完了，咱们聊聊实战。我踩过的坑，你们就别再踩了。
我曾经犯过的错：在某个智能摄像头项目里，我天真地以为NPU能搞定一切。结果发现，NPU对非4的倍数的输入尺寸支持很差，而且不支持某些自定义算子。最后不得不把一部分层切回CPU跑。嗯，这里要注意——NPU不是万能的，它有自己的“脾气”。
所以，我建议你在做架构设计时，先问自己三个问题：
- 模型里有没有NPU不支持的算子？如果有，备选方案是什么？
- 数据流是连续的还是突发的？连续流更适合DSP或NPU，突发任务CPU更灵活。
- 功耗预算有多少？每瓦性能，才是端侧的核心指标。
一个小技巧：我习惯在项目初期，先用CPU跑一遍完整模型，做profiling。看看哪些层最耗时，哪些层计算模式最规则。然后根据这些数据，决定把哪些层卸载到GPU或NPU。这叫“先摸底，再分工”。
好了，这一章的内容就到这里。混合架构不是简单的“把模型扔给NPU”，而是一场精密的调度艺术。理解了分工与协同，你才算真正入了端侧推理的门。