2. AI ISP系统架构
好，咱们进入第二章。上一章聊了 AI ISP 为什么能取代传统 ISP，这一章咱们看看它到底长什么样。说白了，就是拆开来看：硬件怎么摆、软件怎么跑、数据怎么流。
我刚开始接触 AI ISP 时，也以为就是把传统 ISP 里的模块换成神经网络完事。后来发现完全不是那么回事。AI ISP 的架构设计，其实是在「算力、带宽、延迟」这三个夹缝中找平衡。你想想看，一个 4K@60fps 的传感器，每秒要处理的数据量接近 12G 像素，光靠 AI 硬算，功耗直接起飞。
2.1 硬件架构：三大核心域
我个人习惯把 AI ISP 的硬件分成三个域：Sensor 域、AI 处理域、显示/编码域。它们之间通过高速总线（比如 AXI4）连接。
核心原则：数据尽量在片上处理，减少 DDR 访问。一次 DDR 读写的功耗，比一次 MAC 运算高两个数量级。
下面这张图是我自己画的一个典型 AI ISP 硬件架构，你可以看到数据是怎么从 Sensor 一路走到显示器的。
2.2 软件架构：分层解耦
硬件定下来后，软件怎么管？我见过不少团队，硬件流片回来了，软件还在调驱动，结果项目延期。所以软件架构一定要和硬件架构同步设计。
我一般把 AI ISP 的软件分成四层：
| 层级 | 组件 | 职责 | 运行位置 |
|---|---|---|---|
| 应用层 | Camera HAL / API | 曝光控制、3A 策略、场景识别 | CPU (A核) |
| 推理引擎层 | TensorRT / ONNX Runtime / 自研 Runtime | 模型加载、张量分配、算子调度 | CPU + NPU |
| 驱动层 | NPU Driver / ISP Driver | 硬件寄存器配置、DMA 传输、中断处理 | CPU (R核 / M核) |
| 固件层 | Microcode / RTL 状态机 | 像素级流水线控制、Line Buffer 管理 | NPU 内部微控制器 |
避坑指南：我曾经在一个项目里，把 3A 算法也塞进了 NPU。结果发现曝光统计需要逐帧反馈，NPU 的推理延迟根本跟不上。后来老老实实把 3A 放回 CPU，用传统算法做粗调，AI 做细调，才把问题解决。
2.3 数据流与处理管线
数据流是 AI ISP 的灵魂。我习惯把它画成一条流水线，每个阶段都有明确的输入输出格式。
典型的 AI ISP 处理管线如下：
- RAW 图输入（Bayer 格式，12/14-bit）
- 预处理（黑电平校正、坏点校正、LSC）
- AI 去马赛克 + 降噪（单模型或多模型级联）
- AI 色调映射（HDR 重建 + Tone Mapping）
- 传统 ISP 后处理（Gamma、CCM、Sharpen）
- YUV 输出（送显示或编码）
这里有个关键点：AI 模型的位置。放在预处理之后、后处理之前，是最常见的做法。为什么？
- 放在预处理前：RAW 图噪声太大，模型学起来吃力。
- 放在后处理之后：颜色空间已经变了，模型要同时学颜色校正和降噪，任务太复杂。
注意：AI 模型输出的数据格式一定要和后处理模块对齐。我见过一个案例，模型输出是 RGB，但后处理模块只认 YUV，结果中间加了一个颜色空间转换模块，白白增加了 3 行延迟。
2.4 管线中的关键指标
设计管线时，有几个指标你必须盯死：
| 指标 | 典型值 | 瓶颈影响 |
|---|---|---|
| 端到端延迟 | < 1 帧 (16.7ms @60fps) | 取景器体验、拍照响应 |
| AI 模型推理延迟 | < 8ms (单帧) | 决定管线能否实时 |
| DDR 带宽占用 | < 12 GB/s (4K@60) | 系统功耗、多路并发 |
| Line Buffer 大小 | 取决于卷积核尺寸 | 芯片面积、功耗 |
我个人习惯在架构设计阶段，先用 Excel 搭一个延迟模型。把每个模块的延迟、带宽、buffer 大小填进去，跑一遍仿真。这样能提前发现瓶颈，不用等到 RTL 写完了再回头改架构。
一句话总结：AI ISP 的架构设计，本质上是「算力换画质，带宽换延迟」的权衡。硬件定边界，软件定策略，数据流定效率。