2. 基础知识
在正式进入地平线模型转换流程之前，先把“模型转换”这件事本身讲清楚。很多初学者会把模型转换简单理解为“把 PyTorch 的 .pt 文件换成 .bin 文件”，但真正落地到地平线征程（Journey）系列芯片上时，它其实是一条从训练框架到板端可执行产物的完整链路。理解这条链路上的概念、术语和工具，是后续实操不踩坑的前提。
一、什么是模型转换：从浮点图到板端可执行产物
模型转换（Model Conversion）是指把在通用训练框架中训练好的模型，经过图解析、算子映射、量化校准、编译优化等步骤，转换为目标芯片能够高效执行的部署产物的过程。对地平线工具链而言，最终产物通常是 .bin 模型文件，它由板端推理库 libdnn 加载运行。
这里有一个关键认知：模型转换不是“格式翻译”，而是“面向硬件的重新编译”。训练框架里的算子（如 Conv2d、LayerNorm、Softmax）需要映射到地平线 BPU（Brain Processing Unit）支持的算子集合；浮点权重需要经过量化变成定点表示；计算图需要经过融合、重排、内存分配等优化，才能匹配 BPU 的并行计算架构。因此，转换过程会涉及精度、性能、算子支持度三者的权衡。
二、常见术语：先统一语言，再动手操作
地平线工具链文档中有大量专有名词，初学时容易混淆。下面用一张表把最核心的术语集中说明，建议在阅读后续章节时随时回查。
| 术语 | 含义 | 在流程中的位置 |
|---|---|---|
| ONNX | 开放神经网络交换格式，训练框架与地平线工具链之间的通用中间表示 | 转换输入 |
| BPU | 地平线自研神经网络加速单元，负责板端推理计算 | 目标硬件 |
| 量化（Quantization） | 把浮点权重/激活映射为定点表示，降低计算与带宽开销 | 精度与性能的关键环节 |
| 校准（Calibration） | 用一批代表性数据统计激活分布，确定量化 scale | 量化前处理 |
| 算子支持列表 | BPU 支持的算子及其约束条件清单 | 模型检查依据 |
| 模型检查（Checker） | 检查 ONNX 模型是否符合工具链要求，提前暴露不支持算子 | 转换前置步骤 |
| 编译（Compiler） | 把量化后的模型编译为 BPU 可执行指令与内存布局 | 生成 .bin |
| Runtime / libdnn | 板端推理库，负责加载 .bin 并调度 BPU 执行 | 部署运行 |
除了表格中的术语，还有几个高频词需要留意：输入布局（如 NCHW 与 NHWC）、动态维度（dynamic shape）、算子融合（fusion）、回退 CPU（fallback）。这些词会在转换日志和精度对比中反复出现。
三、典型应用场景：模型转换到底服务于什么
模型转换不是孤立的技术动作，它服务于具体的业务场景。理解场景有助于判断“该优先保精度还是保速度”。
- 智能驾驶感知：BEV 感知、障碍物检测、车道线分割等模型，通常对精度敏感，量化时需谨慎校准。
- 舱内交互：驾驶员监控（DMS）、手势识别、语音唤醒视觉前端，强调低延迟与低功耗。
- 机器人/低速无人车：视觉 SLAM 前端、目标跟踪，模型较小但要求实时性稳定。
- 边缘视频分析：多路视频流检测，关注吞吐量，常需要多模型并行与内存复用。
不同场景对转换策略的要求不同。例如，检测模型中的后处理（NMS）如果放在 BPU 上，需要确认算子支持；如果回退到 CPU，则要评估对整体帧率的影响。这些判断都建立在“先理解场景，再选择转换配置”的基础上。
四、地平线工具链概览：一条从训练到部署的流水线
地平线 OpenExplorer 工具链围绕“转换—量化—编译—部署”组织，核心组件包括模型检查工具、量化校准工具、编译器以及板端推理库。下图展示了从训练框架到板端运行的完整信号与数据流，帮助建立整体地图。
从图中可以看到，工具链并不是单点工具，而是一条有方向的数据流：训练框架导出 ONNX，模型检查提前暴露问题，量化校准决定精度基线，BPU 编译生成 .bin，最后由板端 Runtime 加载执行。任何一环配置不当，都会在后续环节放大成精度下降或性能不达标。