4、模型格式与转换：理解ONNX、Caffe、TFLite等模型格式，以及如何转换为BPU支持的格式（如.bin）

旭日BPU（Brain Processing Unit）作为地平线面向AIoT场景推出的嵌入式神经网络处理器，其推理引擎并不直接读取PyTorch或TensorFlow的训练权重，而是要求模型经过一系列标准化、量化与编译流程，最终生成BPU专用的二进制指令文件（.bin）。理解ONNX、Caffe、TFLite等中间表示格式的差异，掌握从训练框架到BPU格式的转换链路，是确保模型在旭日X3/X5等芯片上高效、稳定运行的前提。本章将系统拆解模型格式的本质、转换流程中的关键操作，以及常见陷阱的规避方法。

上图展示了从训练框架到BPU部署的完整转换链路。核心思想是：训练框架负责精度，中间表示负责通用性，转换工具链负责硬件适配。实际工程中，ONNX是最推荐的中间格式，因为它具备良好的算子覆盖度和跨框架兼容性；Caffe模型在早期项目中仍有存量，但新项目建议优先迁移至ONNX；TFLite由于量化信息与算子集限制，通常需要额外处理才能被BPU工具链接受。

4.1 核心原理：为什么需要中间表示与格式转换

BPU本质上是一个专用的SIMD向量处理器，其指令集针对卷积、池化、全连接等算子深度定制。训练框架（如PyTorch）的动态图机制、自动微分功能以及丰富的Python生态，在推理阶段不仅冗余，而且无法直接映射到BPU硬件。因此，模型格式转换的本质是将“训练语义”翻译为“硬件指令”，这一过程分为两个阶段：

• 图结构标准化：将训练框架的计算图（可能包含控制流、动态shape）转换为静态、无分支的中间表示图。ONNX的GraphProto就是这种标准化产物，它定义了节点（Node）、张量（Tensor）和属性（Attribute）的统一规范。
• 算子映射与优化：将中间表示的算子逐一映射到BPU支持的算子库。例如，Conv+BN+ReLU这种融合结构在BPU上可以合并为一个高效指令，而ONNX中的BatchNormalization算子需要被“折叠”进卷积的权重和偏置中。

理解这一原理对后续排障至关重要。例如，当转换报错“Unsupported Op”时，本质是ONNX中的某个算子（如GridSample）在BPU算子库中无对应实现，此时需要手动替换或分解该算子。

4.2 判断方法与操作流程：从PyTorch到.bin的标准路径

以最常见的PyTorch模型为例，标准转换流程包含五个步骤。以下操作基于地平线提供的hbdk工具链（版本≥3.5.0）和horizon_model_convert脚本。

步骤1：PyTorch模型导出为ONNX

import torch
import torchvision.models as models

model = models.resnet18(pretrained=True)
model.eval()

# 构造一个符合模型输入的示例张量
dummy_input = torch.randn(1, 3, 224, 224)

# 导出ONNX，opset_version建议使用11或更高
torch.onnx.export(
    model,
    dummy_input,
    "resnet18.onnx",
    export_params=True,
    opset_version=11,
    do_constant_folding=True,
    input_names=["input"],
    output_names=["output"],
    dynamic_axes={"input": {0: "batch_size"}, "output": {0: "batch_size"}}
)
print("ONNX导出完成")

关键参数说明：opset_version决定了ONNX算子集的版本，BPU工具链通常支持opset 9~13，建议使用11以获得最佳兼容性；dynamic_axes允许动态batch，但BPU推理时通常固定为1，因此也可以不设置。

步骤2：ONNX模型校验与算子检查

使用地平线提供的hb_onnx_checker工具检查模型是否包含BPU不支持的算子：

hb_onnx_checker --model resnet18.onnx --input-shape 1,3,224,224

该命令会输出算子列表，并标注每个算子是否被BPU支持。若出现Unsupported标记，则需要查看具体算子名称，并考虑替换方案。例如，Resize算子（用于上采样）在BPU上支持有限，建议改用ConvTranspose2d或Upsample的特定模式。

步骤3：模型量化校准

BPU推理以INT8为主，因此需要准备校准数据集（通常为500~1000张验证集图片），统计每层激活值的动态范围。地平线工具链使用hb_quantize命令：

hb_quantize --model resnet18.onnx --calibration-data ./calib_images/ --batch-size 32 --quant-scheme int8

量化过程会生成一个resnet18_quantized.onnx，其中包含了每层的量化参数（scale和zero_point）。校准数据集的选择直接影响量化精度，应尽量覆盖部署场景的真实数据分布，避免使用训练集（容易过拟合到训练分布）。

步骤4：编译生成.bin文件

hb_compile --model resnet18_quantized.onnx --input-shape 1,3,224,224 --output resnet18.bin

编译过程会将量化后的计算图映射为BPU指令序列，并生成二进制文件。编译日志中会显示每层的调度信息、内存占用和预估延迟。若编译失败，常见原因是输入shape与模型不匹配或量化参数异常。

步骤5：运行时验证

使用地平线提供的Python运行时库hb_runtime加载.bin文件进行推理验证：

from hb_runtime import Runtime
import numpy as np

runtime = Runtime("resnet18.bin")
input_data = np.random.rand(1, 3, 224, 224).astype(np.float32)
output = runtime.run(input_data)
print("输出shape:", output.shape)

此步骤用于确认.bin文件可正常加载并产生合理输出，同时可对比原始PyTorch模型的输出差异，评估量化损失。

4.3 案例拆解：Caffe模型迁移与TFLite模型适配

某安防项目需要将已有的Caffe人脸检测模型（基于SSD架构）迁移至旭日X3开发板。该模型包含DetectionOutput后处理层，而BPU不支持该算子。以下是完整的处理过程：

该案例的核心经验是：BPU不是万能的，后处理算子（如NMS、Anchor生成）应尽量放在CPU端。这不仅简化了模型转换，还能利用CPU的灵活性处理动态逻辑，而BPU专注于高密度的卷积计算。

对于TFLite模型，情况略有不同。TFLite本身是面向移动端推理的格式，其量化方案（训练后量化）与BPU的量化策略存在差异。建议先将TFLite转换为ONNX（使用tf2onnx工具），再走标准流程。但需注意，TFLite中的某些融合算子（如FusedBatchNorm）在转换后可能产生冗余节点，需要额外清理。

4.4 常见误区与总结复盘

在模型转换的工程实践中，以下误区最容易导致项目延期或性能不达标：

• 误区1：忽略输入输出的数据布局。BPU默认使用NHWC布局，而PyTorch导出ONNX时通常为NCHW。虽然工具链会自动插入Transpose节点，但过多的Transpose会增加内存拷贝开销。建议在导出ONNX时通过torch.onnx.export的input_names配合dynamic_axes明确指定布局，或使用opset_version=11的data_prop功能。
• 误区2：认为量化是“免费的”。INT8量化必然带来精度损失，尤其对检测、分割等密集预测任务。建议在量化前先进行敏感层分析（工具链提供hb_analyze命令），找出对量化最敏感的层，并考虑对这些层保留FP16或INT16精度。
• 误区3：忽视模型输入shape的固定性。BPU编译器要求输入shape完全静态。如果模型包含动态shape操作（如torch.onnx.export中的dynamic_axes），编译时会报错。务必在导出时固定所有维度，或使用hb_compile的--input-shape参数强制指定。
• 误区4：混淆“支持”与“高效”。某些算子（如Gather、Slice）虽然BPU支持，但实现效率极低。例如，在特征图上做Gather操作会被拆分为多个标量加载指令，性能下降数十倍。遇到这种情况，应重构网络结构，用卷积或池化替代。

最后，务必保留原始训练框架的模型文件与转换脚本的版本对应关系。当.bin文件在目标板上出现精度异常时，能够快速回溯是模型结构变化、量化校准集变化还是工具链版本升级导致的问题。建议在转换脚本中记录工具链版本、校准集路径、量化配置等元信息，形成可复现的转换环境。