用 CANN 做推理时图像预处理通常在 CPU 上完成——读图、Resize、Normalize、格式转换然后把处理好的 Tensor 拷到 NPU。AIPPAI Preprocessing改变了这个模式——它让预处理成为推理管线的一部分跟模型推理在同一硬件链路上执行。AIPP 在昇腾 NPU 上是一组可配置的预处理参数。模型加载时AIPP 配置随 OM 模型一起加载到硬件中。推理时输入数据直接喂给 AIPP 硬件模块预处理后的结果直接流入模型推理——中间不需要软件层面的干预。AIPP 为什么存在推理的预处理通常分三步从存储读文件CPU 负责、做图像处理CPU 或 DVPP、把结果拷到 NPU。第三步的 CPU→NPU 搬运是隐藏的性能损耗——数据类型和内存布局在搬运过程中可能需要二次转换。AIPP 的定位是融合这三步中的可配置部分传统流程 CPU 读图 → CPU Normalize → CPU HWC→CHW → CPU→NPU 拷贝 → NPU 推理 AIPP 流程 CPU 读图 → NPU AIPP 硬件做 Normalize格式转换 → NPU 推理CPU 只做最基本的图像读取从磁盘到内存。归一化参数、颜色空间转换、布局变换全部由 AIPP 在 NPU 上完成。AIPP 配置项AIPP 通过静态配置文件定义预处理流程。配置项在 ATC 模型转换时嵌入 OM 模型{aipp_config:{input_format:YUV420SP_U8,// 输入格式src_image_size_w:640,src_image_size_h:640,csc_params:{// 颜色空间转换matrix_r0c0:256,matrix_r0c1:0,matrix_r0c2:359,// ... YUV→RGB 矩阵参数},mean_chn_0:128,// 各通道均值mean_chn_1:128,mean_chn_2:128,min_chn_0:0.0,// 归一化范围max_chn_0:255.0}}可配置的操作颜色空间转换CSCYUV→RGB/BGR使用配置的 3×3 矩阵归一化(pixel - mean) * var各通道独立配置裁剪从原图裁剪区域后再 ResizePaddingResize 后的图像如果尺寸不对齐填充到对齐尺寸推理链路中的 AIPPAIPP 在推理链路中的位置原始图像YUV/NV12→ NPU 输入 Buffer ↓ AIPP 硬件模块 ┌─────────────────────────────┐ │ CSC: YUV → RGB │ │ Crop: 裁剪兴趣区域 │ │ Resize: 缩放到模型输入尺寸 │ │ Normalize: (pixel-mean)*var │ │ Layout: HWC → CHW │ └─────────────────────────────┘ ↓ 模型推理AI CoreAIPP 的输出直接是模型输入的 float32 Tensor——布局、数值范围、通道顺序全部已对齐。AIPP 执行的整个过程不受 CPU 干预它是模型加载时被编译进 OM 的一个硬件配置。AIPP 与 DVPP 的对比AIPP 和 DVPP 都做预处理但定位不同特性AIPPDVPP处理内容Normalize、CSC、CropJPEG 解码、Resize、CSC配置方式静态配置编译时确定运行时 API 调用位置推理管线内部紧耦合推理管线外部松耦合数据源直接从输入 Buffer 读取从 CPU 内存或文件读取灵活性低参数编译时固定高运行时可选AIPP 适合生产环境——预处理参数固定不折腾配置。DVPP 适合开发阶段——想换预处理参数时不用重新编译模型。两者也可以串联使用DVPP 做解码和 Resize输出喂给 AIPP 做 Normalize 和 CSC。DVPP 输出的是 YUV 数据AIPP 的 CSC 正好处理 YUV→RGB 的转换。图像推理中的典型场景ResNet-50 图像分类部署时使用 AIPPatc--modelresnet50.onnx\--framework5\--outputresnet50\--soc_versionAscend910\--insert_op_confaipp_resnet50.cfg插入 AIPP 配置后推理时输入只需是原始的 YUV 或 JPEG 数据由 DVPP 解码后的格式。Normalize 参数和均值由 AIPP 在 NPU 上处理。如果多个模型需要不同的预处理参数——模型 A 用mean[0.485,0.456,0.406]模型 B 用mean[0.5,0.5,0.5]——每个 OM 模型携带独立的 AIPP 配置。推理时根据 modelId 自动选择对应的预处理参数。AIPP 与 DVPP 的配合使用AIPP 和 DVPP 可以协作完成预处理管线。一个典型场景DVPP 解码JPEG → YUV硬件解码DVPP ResizeYUV 缩放到模型输入尺寸AIPPYUV→RGB Normalize → 输出 float32 TensorDVPP 处理完的 YUV 数据直接通过片上 DMA 传给 AIPP——不需要经过 DDR。AIPP 的 Normalize 参数在模型加载时已配置好不需要每次推理传参。协作流程完全在 NPU 内部完成CPU 只负责提供原始图像数据。AIPP 的局限性AIPP 的主要局限在于参数必须在编译时确定。如果需要为不同输入使用不同的 Normalize 参数比如多模型服务中各模型的预处理参数不同需要多个 OM 模型各带独立的 AIPP 配置。AIPP 也无法处理动态形状的预处理——如果你的模型输入形状在推理时变化AIPP 的 Resize 目标尺寸无法在模型加载后修改。动态 Shape 场景建议用 DVPP ops-cv 的运行时 API。参考仓库ops-cv 图像处理算子库DVPP 视觉预处理文档
AIPP：将预处理融进推理管线的硬件加速
用 CANN 做推理时图像预处理通常在 CPU 上完成——读图、Resize、Normalize、格式转换然后把处理好的 Tensor 拷到 NPU。AIPPAI Preprocessing改变了这个模式——它让预处理成为推理管线的一部分跟模型推理在同一硬件链路上执行。AIPP 在昇腾 NPU 上是一组可配置的预处理参数。模型加载时AIPP 配置随 OM 模型一起加载到硬件中。推理时输入数据直接喂给 AIPP 硬件模块预处理后的结果直接流入模型推理——中间不需要软件层面的干预。AIPP 为什么存在推理的预处理通常分三步从存储读文件CPU 负责、做图像处理CPU 或 DVPP、把结果拷到 NPU。第三步的 CPU→NPU 搬运是隐藏的性能损耗——数据类型和内存布局在搬运过程中可能需要二次转换。AIPP 的定位是融合这三步中的可配置部分传统流程 CPU 读图 → CPU Normalize → CPU HWC→CHW → CPU→NPU 拷贝 → NPU 推理 AIPP 流程 CPU 读图 → NPU AIPP 硬件做 Normalize格式转换 → NPU 推理CPU 只做最基本的图像读取从磁盘到内存。归一化参数、颜色空间转换、布局变换全部由 AIPP 在 NPU 上完成。AIPP 配置项AIPP 通过静态配置文件定义预处理流程。配置项在 ATC 模型转换时嵌入 OM 模型{aipp_config:{input_format:YUV420SP_U8,// 输入格式src_image_size_w:640,src_image_size_h:640,csc_params:{// 颜色空间转换matrix_r0c0:256,matrix_r0c1:0,matrix_r0c2:359,// ... YUV→RGB 矩阵参数},mean_chn_0:128,// 各通道均值mean_chn_1:128,mean_chn_2:128,min_chn_0:0.0,// 归一化范围max_chn_0:255.0}}可配置的操作颜色空间转换CSCYUV→RGB/BGR使用配置的 3×3 矩阵归一化(pixel - mean) * var各通道独立配置裁剪从原图裁剪区域后再 ResizePaddingResize 后的图像如果尺寸不对齐填充到对齐尺寸推理链路中的 AIPPAIPP 在推理链路中的位置原始图像YUV/NV12→ NPU 输入 Buffer ↓ AIPP 硬件模块 ┌─────────────────────────────┐ │ CSC: YUV → RGB │ │ Crop: 裁剪兴趣区域 │ │ Resize: 缩放到模型输入尺寸 │ │ Normalize: (pixel-mean)*var │ │ Layout: HWC → CHW │ └─────────────────────────────┘ ↓ 模型推理AI CoreAIPP 的输出直接是模型输入的 float32 Tensor——布局、数值范围、通道顺序全部已对齐。AIPP 执行的整个过程不受 CPU 干预它是模型加载时被编译进 OM 的一个硬件配置。AIPP 与 DVPP 的对比AIPP 和 DVPP 都做预处理但定位不同特性AIPPDVPP处理内容Normalize、CSC、CropJPEG 解码、Resize、CSC配置方式静态配置编译时确定运行时 API 调用位置推理管线内部紧耦合推理管线外部松耦合数据源直接从输入 Buffer 读取从 CPU 内存或文件读取灵活性低参数编译时固定高运行时可选AIPP 适合生产环境——预处理参数固定不折腾配置。DVPP 适合开发阶段——想换预处理参数时不用重新编译模型。两者也可以串联使用DVPP 做解码和 Resize输出喂给 AIPP 做 Normalize 和 CSC。DVPP 输出的是 YUV 数据AIPP 的 CSC 正好处理 YUV→RGB 的转换。图像推理中的典型场景ResNet-50 图像分类部署时使用 AIPPatc--modelresnet50.onnx\--framework5\--outputresnet50\--soc_versionAscend910\--insert_op_confaipp_resnet50.cfg插入 AIPP 配置后推理时输入只需是原始的 YUV 或 JPEG 数据由 DVPP 解码后的格式。Normalize 参数和均值由 AIPP 在 NPU 上处理。如果多个模型需要不同的预处理参数——模型 A 用mean[0.485,0.456,0.406]模型 B 用mean[0.5,0.5,0.5]——每个 OM 模型携带独立的 AIPP 配置。推理时根据 modelId 自动选择对应的预处理参数。AIPP 与 DVPP 的配合使用AIPP 和 DVPP 可以协作完成预处理管线。一个典型场景DVPP 解码JPEG → YUV硬件解码DVPP ResizeYUV 缩放到模型输入尺寸AIPPYUV→RGB Normalize → 输出 float32 TensorDVPP 处理完的 YUV 数据直接通过片上 DMA 传给 AIPP——不需要经过 DDR。AIPP 的 Normalize 参数在模型加载时已配置好不需要每次推理传参。协作流程完全在 NPU 内部完成CPU 只负责提供原始图像数据。AIPP 的局限性AIPP 的主要局限在于参数必须在编译时确定。如果需要为不同输入使用不同的 Normalize 参数比如多模型服务中各模型的预处理参数不同需要多个 OM 模型各带独立的 AIPP 配置。AIPP 也无法处理动态形状的预处理——如果你的模型输入形状在推理时变化AIPP 的 Resize 目标尺寸无法在模型加载后修改。动态 Shape 场景建议用 DVPP ops-cv 的运行时 API。参考仓库ops-cv 图像处理算子库DVPP 视觉预处理文档
