2、端侧推理硬件基础：NPU架构简介、DSP与GPU的协同、内存带宽与计算瓶颈分析
做端侧AI ISP优化，说白了就是跟硬件打交道。你得知道手里的芯片到底能干什么，不能干什么。我见过不少算法工程师，模型精度调得挺好，一上板子就卡成PPT，最后发现是硬件资源没用好。这一章，我们就聊聊端侧推理的三驾马车：NPU、DSP、GPU，以及那个永远不够用的内存带宽。
2.1 NPU架构：专为矩阵而生
NPU，神经网络处理器。名字听着高大上，本质上就是个“矩阵计算加速器”。它跟CPU最大的区别是什么？CPU什么活都能干，但干得不够快；NPU只会干一件事——矩阵乘加，但干得极快。
核心认知：NPU的算力密度（TOPS/mm²）通常是GPU的3-5倍，但灵活性远低于GPU。这意味着，如果你的模型结构规整（Conv + ReLU + Pooling），NPU是首选；如果模型里有大量自定义算子或动态分支，NPU可能直接罢工。
我拆解过几款主流端侧NPU，它们的架构大同小异，基本包含这几个模块：
| 模块 | 功能 | 我的经验 |
|---|---|---|
| MAC阵列 | 乘加运算单元，通常排成16x16或32x32的脉动阵列 | 阵列利用率是关键，我见过利用率不到30%的项目 |
| 激活/池化单元 | ReLU、Sigmoid、MaxPool等非线性操作 | 这部分通常不是瓶颈，但要注意精度对齐 |
| 本地SRAM | 存放权重和中间特征图，通常几百KB到几MB | SRAM大小直接决定你能否做算子融合 |
| DMA引擎 | 负责数据在DDR和SRAM之间搬运 | DMA带宽经常被忽略，其实是隐藏的瓶颈 |
| 指令调度器 | 解析并分发NPU指令 | 指令流水线停顿会吃掉大量性能 |
举个例子，假设你的NPU有256个MAC，每个MAC每周期能做一次乘加。如果主频1GHz，理论算力就是256 GOPS。但实际能跑到多少？我测过很多芯片，实际利用率通常在40%-70%之间。为什么？因为数据喂不饱MAC阵列。
小技巧：在模型部署时，尽量让特征图的通道数是MAC阵列行数的整数倍。比如阵列是16x16，通道数最好选16、32、64这种。我曾经把一个32通道的卷积改成33通道，性能直接掉了40%。
2.2 DSP与GPU：各司其职的搭档
NPU不是万能的。端侧AI ISP里，很多预处理和后处理任务，NPU做不了或者做不好。这时候就需要DSP和GPU来补位。
DSP（数字信号处理器），擅长流式数据处理。比如图像缩放、色彩空间转换、直方图统计这些操作，DSP做起来比NPU快得多。为什么？因为DSP有专门的SIMD指令和硬件循环，处理像素流就像流水线一样顺畅。
GPU（图形处理器），擅长并行渲染和通用计算。在端侧，GPU通常用来做图像增强、滤波、以及一些NPU不支持的自定义算子。但GPU的功耗比较高，用的时候得悠着点。
我个人的习惯是这么分工的：
- 预处理（RAW域处理、去马赛克、白平衡） → DSP，延迟低，功耗小
- 核心推理（去噪、超分、HDR融合） → NPU，算力密度高
- 后处理（色调映射、锐化、显示格式转换） → GPU，灵活且效果好
避坑指南：我曾经在一个项目里，把后处理也扔给NPU做。结果NPU不支持某些非线性操作，只能用CPU模拟，性能直接崩了。后来改成GPU做后处理，帧率从15fps提到了45fps。记住：不要试图让NPU做它不擅长的事。
这里有个协同工作的典型流程：
// 伪代码：端侧AI ISP推理流水线
// 阶段1：DSP预处理
dsp_process(raw_image, &preprocessed_image); // 去马赛克、降噪
// 阶段2：NPU推理
npu_run(model_handle, preprocessed_image, &feature_map); // 核心AI处理
// 阶段3：GPU后处理
gpu_process(feature_map, &output_image); // 色调映射、锐化
// 阶段4：显示
display(output_image);你看，每个硬件干自己最擅长的活，整体效率才能上去。
2.3 内存带宽：看不见的瓶颈
聊完计算单元，咱们聊聊内存。这是端侧AI ISP优化里最容易被忽视，但影响最大的因素。
为什么？因为计算单元越来越快，但内存带宽的增长速度远远跟不上。你想想看，NPU算力每年翻倍，DDR带宽每年只涨20%-30%。结果就是：计算单元经常闲着，等数据从DDR搬过来。
我做过一个测算：
| 操作 | 计算量（MACs） | 数据量（Bytes） | 计算时间（@1TOPS） | 搬运时间（@25GB/s） | 瓶颈 |
|---|---|---|---|---|---|
| 3x3 Conv, 3x224x224→64x224x224 | 86M | 12.5M | 0.086ms | 0.5ms | 带宽 |
| 1x1 Conv, 64x112x112→128x112x112 | 102M | 6.4M | 0.102ms | 0.256ms | 带宽 |
| FC, 2048→1000 | 2M | 8.2M | 0.002ms | 0.328ms | 带宽 |
看到没？几乎所有操作，数据搬运时间都远大于计算时间。这就是所谓的“内存墙”。
核心结论：端侧AI ISP优化的第一要务，不是提升算力利用率，而是减少数据搬运。算力再高，数据喂不进去也是白搭。
怎么减少数据搬运？我常用的几个方法：
- 算子融合：把Conv + BN + ReLU合并成一个算子，中间结果留在SRAM里，不用写回DDR
- 量化：从FP32降到INT8，数据量直接减少4倍，带宽压力骤降
- 数据复用：尽量让权重和特征图在本地SRAM里多待几个周期
- Winograd/FFT：减少乘法次数，但会增加数据量，需要权衡
经验之谈：我优化过一个4K视频实时去噪模型。原始模型用FP32推理，带宽需求高达40GB/s，芯片根本扛不住。后来做了三件事：INT8量化、Conv+ReLU融合、权重重排。最终带宽降到8GB/s，帧率从12fps提到了55fps。你看，优化带宽比优化算力有效得多。
2.4 计算瓶颈分析：找到那个最慢的环节
最后，咱们聊聊怎么分析瓶颈。做性能优化，最忌讳的就是“盲人摸象”——凭感觉猜哪里慢。一定要用数据说话。
我一般用这套流程：
- Profiling：用芯片厂商提供的profiler工具，跑一遍完整推理，看每个算子的耗时
- 拆解：把耗时最高的几个算子拎出来，分析是计算瓶颈还是带宽瓶颈
- 定位：如果是计算瓶颈，看MAC利用率；如果是带宽瓶颈，看DDR读写量
- 优化：针对瓶颈类型，选择对应的优化策略
这里有个简单的判断方法：
- 如果MAC利用率 < 50%，大概率是带宽瓶颈
- 如果MAC利用率 > 80%，但整体帧率还是不达标，那就是算力不够，得换模型
- 如果DDR读写量 > 模型理论最小值的2倍，说明数据复用做得不好
注意：不要只看平均利用率。有些算子（比如Depthwise Conv）的MAC利用率天然就低，因为它的计算密度小。这时候要结合具体算子来分析，不能一刀切。
嗯，这一章的内容差不多就这些。总结一下：NPU负责矩阵计算，DSP负责流式处理，GPU负责灵活渲染。三者协同，才能发挥端侧芯片的最大潜力。而内存带宽，是那个永远绕不开的瓶颈——优化它，比优化算力更有效。