2、边缘硬件架构：MCU、MPU、NPU、TPU的区别与选型
聊边缘AI，第一个绕不开的话题就是硬件选型。我见过不少团队，算法跑得挺溜，一上板子就卡死，或者功耗爆炸。说白了，就是没搞清楚手里的芯片到底擅长什么。
今天咱们就把MCU、MPU、NPU、TPU这四兄弟掰扯清楚。顺便看看三款典型芯片——STM32、RK3588、Jetson Orin——它们的内存层次到底长啥样。
2.1 四类处理器的核心区别
先给个直观的对比。你想想看，这四类芯片就像四种工具：
- MCU（微控制器）：瑞士军刀。啥都能干一点，但别指望它干重活。特点是集成度高、功耗极低、实时性好。
- MPU（微处理器）：台式电脑的CPU。性能强，能跑Linux，但外围电路复杂，功耗也上去了。
- NPU（神经网络处理器）：专门为AI推理设计的加速器。说白了就是矩阵乘法怪兽。
- TPU（张量处理器）：Google家的专用芯片。跟NPU类似，但架构更偏向TensorFlow生态。
关键认知：MCU和MPU是通用处理器，NPU和TPU是专用加速器。边缘AI的常见组合是「MPU + NPU」或者「MCU + 轻量级NPU」。
2.2 典型芯片的内存层次分析
内存层次这东西，我刚开始做嵌入式AI时吃过亏。有一次在STM32上部署一个轻量级模型，明明Flash和RAM都够，但推理速度就是上不去。后来一查，原来是频繁的DMA传输把总线带宽吃满了。嗯，这里要注意——内存层次不只是看容量，更要看带宽和访问延迟。
2.2.1 STM32（以STM32H7系列为例）
STM32是MCU的典型代表。它的内存层次比较简单：
| 层级 | 容量 | 带宽 | 用途 |
|---|---|---|---|
| Flash | 1MB ~ 2MB | ~200 MB/s | 存储代码和常量数据 |
| SRAM（DTCM） | 128KB ~ 512KB | ~400 MB/s | 核心数据、堆栈、中间结果 |
| SRAM（AXI-SRAM） | 512KB ~ 1MB | ~320 MB/s | 大块数据缓冲区 |
| 外部SDRAM | 8MB ~ 64MB | ~100 MB/s | 扩展内存，但延迟高 |
我的经验：在STM32上跑AI，尽量把模型权重放在Flash里，推理时的中间激活值放在DTCM。我曾经试过把权重放外部SDRAM，推理速度直接掉了3倍——总线竞争太严重了。
2.2.2 RK3588（瑞芯微旗舰MPU）
RK3588是典型的「MPU + NPU」异构架构。它的内存层次复杂得多：
| 层级 | 容量 | 带宽 | 说明 |
|---|---|---|---|
| L1 Cache（每核） | 32KB I-cache + 32KB D-cache | ~64 GB/s | CPU核心私有 |
| L2 Cache（每簇） | 512KB | ~32 GB/s | 四个A76核心共享 |
| L3 Cache | 3MB | ~16 GB/s | 所有CPU核心共享 |
| NPU内部SRAM | 512KB | ~128 GB/s | NPU专用，存放权重和激活值 |
| 系统DDR | 8GB ~ 32GB（LPDDR4/5） | ~51.2 GB/s | CPU和NPU共享主存 |
为什么会这样设计？说白了，NPU的SRAM带宽极高但容量小，适合放当前层的权重和激活值。而整个模型的大头权重，还是得放在DDR里，通过DMA搬运到NPU SRAM。
避坑指南：我曾经在RK3588上部署一个YOLOv5s模型，发现NPU利用率只有40%。排查了半天，原来是DDR带宽被CPU的4K视频解码占用了。解决方案是把NPU的DMA通道优先级调高，同时把视频解码绑到小核上。
2.2.3 Jetson Orin（NVIDIA边缘AI平台）
Jetson Orin是真正的「性能怪兽」。它的内存层次体现了GPU架构的特点：
| 层级 | 容量 | 带宽 | 说明 |
|---|---|---|---|
| L1 Cache（每SM） | 128KB | ~2 TB/s | GPU SM私有 |
| L2 Cache | 4MB | ~1 TB/s | 所有SM共享 |
| 统一内存（UM） | 8GB ~ 64GB（LPDDR5） | ~204.8 GB/s | CPU和GPU共享，硬件自动迁移 |
| 显存（VRAM） | 与UM共享 | ~204.8 GB/s | GPU专用，但物理上同一片内存 |
关键点：Jetson Orin的「统一内存」是个好东西。你不需要手动管理CPU和GPU之间的数据拷贝，硬件会自动做page migration。但代价是——如果访问模式不好，频繁的缺页中断会严重拖慢性能。
我记得有一次在Orin上跑一个多模态模型，CPU侧预处理图片，GPU侧跑推理。按理说统一内存会自动处理，但实际帧率只有15fps。后来用cudaMemAdvise手动指定了内存访问偏好，帧率直接翻倍到30fps。嗯，自动化的东西，有时候还是得人工干预一下。
2.3 选型建议
说了这么多，到底怎么选？我个人的习惯是看三个维度：
- 模型大小：小于1MB的轻量模型（如MobileNetV1），STM32就能搞定。1MB~10MB的中等模型，RK3588比较合适。超过10MB的大模型，得上Jetson Orin。
- 实时性要求：如果要求毫秒级响应，MCU的确定性延迟是优势。如果允许几十毫秒的抖动，MPU+NPU更灵活。
- 功耗预算：电池供电的设备，STM32（几十mW）是首选。有电源插座的，RK3588（几W到十几W）和Jetson Orin（15W~60W）都可以考虑。
一个小技巧：如果你不确定选哪款，可以先在RK3588上做原型验证。它的生态最成熟，踩坑成本低。等算法稳定了，再根据实际资源消耗决定是降级到STM32还是升级到Jetson Orin。
最后说一句，内存层次的理解，直接决定了你的推理性能。别光看芯片的TOPS算力，内存带宽和延迟才是真正的瓶颈。我见过太多项目，算力标称4TOPS，实际跑起来连1TOPS都用不满——都是被内存卡死的。