📚 课程目录第3章 i.MX 95异构计算资源解析

3. i.MX 95异构计算资源解析

i.MX 95 的视觉与 AI 能力并非来自单一处理器，而是由四类异构单元协同完成：负责神经网络推理的 eIQ Neutron NPU、承担通用并行计算的 Mali GPU、处理视频编解码的 VPU，以及把 RAW 传感器数据变成可用图像的 ISP。理解这套资源的关键，不是记住各自峰值指标，而是弄清"什么任务该交给谁、数据在它们之间怎么流动、带宽和内存如何分配"。本节围绕这四点展开，并给出可落地的资源分配思路。

eIQ Neutron NPU：算力与算子支持

eIQ Neutron NPU 是 i.MX 95 上专为边缘推理设计的加速器，典型配置提供约 2 TOPS（INT8）量级的算力，支持 INT8、INT16 等量化精度，并针对卷积、深度卷积、全连接、池化、激活等常见算子做了硬件映射。它的价值在于把推理从 CPU 上卸载下来，使 CPU 能专注调度与后处理。

但"支持算子"不等于"支持任意模型"。实际部署时，模型需要先经过 eIQ 工具链（基于 TensorFlow Lite / ONNX 流程）转换与量化，再由 Neutron 编译器判断哪些层能落到 NPU、哪些层必须回退到 CPU。常见回退原因包括：使用了 NPU 未覆盖的算子（如某些自定义激活、动态 shape 操作）、量化不兼容、或张量维度超出硬件约束。因此评估一个模型能否高效运行，第一步是看"NPU 覆盖率"——覆盖率越高，CPU 回退越少，端到端延迟越稳定。

量化是 NPU 发挥算力的前提。以 INT8 为例，需用代表性校准集统计激活分布，确定每层的 scale 与 zero-point；若校准集与实际场景偏差过大，精度会明显下降，此时可对敏感层保留 INT16 或 FP16。

Mali GPU：通用计算与图形

Mali GPU 在 i.MX 95 上承担两类任务：图形渲染（OpenGL ES / Vulkan）与通用计算（OpenCL）。在视觉系统里，GPU 常被用于图像预处理（缩放、色彩空间转换、归一化）、后处理（NMS、绘制检测框）以及部分可并行的算子。它的优势是灵活、可编程，适合处理 NPU 不支持的算子或需要频繁变化的逻辑。

但 GPU 的能效比通常低于专用 NPU，且与 CPU、NPU 共享内存带宽。因此资源分配上的一般原则是：能放 NPU 的推理尽量放 NPU，GPU 用于预处理/后处理和图形叠加，避免让 GPU 承担大规模卷积推理。若把整个网络都跑在 GPU 上，功耗和延迟往往都不理想。

VPU：编解码能力

VPU 负责视频的硬件编解码，典型支持 H.264、H.265 的 4K 编解码，部分配置还支持 AV1 解码。它把压缩码流解成 YUV 帧，或把 YUV 帧编成码流，整个过程不占用 CPU 与 NPU。在视觉系统里，VPU 是"视频入口"和"视频出口"：摄像头或网络流先经 VPU 解码，得到可供 ISP/GPU/NPU 处理的图像；处理结果再经 VPU 编码后推流或存储。

需要区分的是：VPU 只做编解码，不做图像质量处理。解码输出的 YUV 若来自压缩流，通常已由编码端做过处理；而来自 RAW 传感器的数据则必须先经 ISP。二者路径不同，不能混用。

ISP：图像处理管线

ISP 把传感器输出的 RAW 数据转换为可用的 RGB/YUV 图像，典型环节包括黑电平校正、去马赛克、白平衡、色彩校正、伽马、降噪与锐化。i.MX 95 的 ISP 支持多路摄像头输入，可同时处理不同分辨率的流。ISP 的输出质量直接决定后续 NPU 推理的输入质量——如果白平衡或曝光不准，模型精度会显著下降。

ISP 与 NPU 的关系是"上游决定下游"：ISP 输出的分辨率、色彩格式、帧率，都会影响 NPU 的输入张量尺寸与带宽占用。因此调优时不能只盯 NPU，还要回看 ISP 的输出配置。

资源分配策略

四类单元共享 DDR 带宽，这是最容易成为瓶颈的地方。一个 4K 30fps 的 YUV420 帧约 12MB，若 ISP、NPU、GPU、VPU 同时读写，带宽压力会迅速上升。因此分配策略的核心是"减少不必要的搬运"：

分辨率匹配：NPU 输入通常只需 640×640 或 416×416，不必把 4K 帧直接送进 NPU。可在 ISP 或 GPU 阶段先缩放，降低张量尺寸与带宽。
格式统一：尽量让 ISP 输出、NPU 输入、GPU 处理使用一致的色彩格式（如 NV12），避免反复转换。
流水线并行：VPU 解码、ISP 处理、NPU 推理、GPU 后处理可分布在不同帧上并行，用多缓冲（如 3~4 个 buffer）掩盖各阶段延迟。
算子回退控制：若某模型 NPU 覆盖率低，可考虑用 GPU 承接回退层，或调整模型结构（如替换不支持的激活函数）以提高覆盖率。

不要默认"NPU 一定最快"。若模型很小、或大量算子在 CPU 回退，端到端延迟可能反而不如直接在 CPU/GPU 上跑。部署前应实测各单元的实际耗时，而不是只看峰值算力。

一个可参考的配置示例

假设一路 1080p 摄像头做目标检测，可参考如下分配：ISP 输出 1080p NV12，GPU 缩放到 640×640 并归一化，NPU 跑 INT8 检测模型，CPU 做 NMS，GPU 绘制检测框，VPU 将带框画面编码为 H.264 推流。此时 NPU 输入张量约 640×640×3，INT8 下约 1.2MB，远小于原始帧，带宽压力可控。若实测 NPU 推理耗时 8ms、GPU 预处理 3ms、CPU 后处理 2ms，则单帧处理约 13ms，理论上可支撑 30fps 以上，但需预留 ISP 与 VPU 的带宽余量。

实际调优时，建议先用 perf 或厂商提供的 profiling 工具分别测量各单元占用，再决定是否调整分辨率、量化精度或流水线深度。资源分配不是一次设定，而是随模型、分辨率、帧率共同迭代的过程。