[具身智能-653]：地平线 .bin 与 .hbm 模型文件完整对比 + 技术发展背景说明

前置重要定义

• .bin：RT Model Bin，旭日 X3（Bayes 一代 BPU）部署最终模型文件
• .hbm：Horizon Binary Model，征程 5/J5、征程 6/J6、RDK X5（Bayes2/Nash 二代 BPU）部署最终模型文件

两者分属两代 BPU 架构产物，指令集完全隔离，文件不能跨芯片直接复用。

一、发展历史背景（理解两种格式诞生的根本原因）

1..bin的诞生背景（Bayes BPU / 旭日 X3 时代）

地平线第一代量产 BPU Bayes（旭日 X3、RDK X3），配套工具链hb_mapper V1。 工程痛点与设计取舍：

1. 早期边缘 AI 开发者缺少编译链接工程化思想，追求极简部署流程；
2. 工具链采用一体化单阶段编译链路： ONNX → 图优化 → PTQ 量化 → 算子切分 → BPU 微指令生成 → CPU fallback 算子嵌入 →一步输出 .bin
3. 文件定位：独立封闭单模型包✅ 优势：上手简单，一条命令产出可用模型； ❌ 历史遗留缺陷：

• 一个 bin 只能存放单个神经网络；
• 多模型并发推理时，多个 bin 独立加载，公共骨干权重无法共享，DDR 内存占用高；
• 模型无法拆分、复用、增量更新；
• CPU fallback 算子直接打包进模型，耦合度极高；
• 不支持动态输入 shape、多 batch 高级特性。

适用平台：旭日 X3、RDK X3、X3Pi；Runtime：旧版hb_dnnAPI。

2..hbm的诞生背景（Bayes2/Nash BPU / J5/RDK X5/J6）

随着大模型、多任务视觉方案（检测 + 跟踪 + 分类 + 分割）普及，.bin的架构短板凸显。地平线推出新一代工具链HBDK V2 / OE Toolchain V2，借鉴 C/C++「编译→链接」思想重构模型编译流程： 新增中间文件.hbo（Horizon Binary Object，模型目标文件） 完整链路：ONNX → convert → compile → 输出 .hbo（单模型目标文件，不可直接运行） → link 链接器 → 打包生成 .hbm

设计目标：

1. 支持多模型打包，一个 hbm 内部容纳多个网络；
2. 链接阶段自动识别共享权重（如多任务共用 Backbone），权重去重，降低内存占用；
3. 模型模块化管理，支持单独编译、增量链接；
4. 适配新一代 BPU 指令集，原生支持动态 shape、FP16 混合量化、更多硬件算子；
5. 解耦模型与 CPU 算子，降低耦合。

适用平台：RDK X5、征程 5 (J5)、征程 6 (J6)；Runtime：全新hrt_runtime(HRT)API，与 hb_dnn 完全不兼容。

二、.bin VS .hbm 结构化对比表

表格

三、关键工程结论

1. 不能直接转换：无法把 X3 的.bin 文件转换成 X5 可用的.hbm，必须使用新版工具链重新量化、编译；
2. 项目选型原则
   • 存量 RDK X3 旧项目：维持.bin；
   • 新项目 RDK X5 / 征程 5/6：强制使用.hbm；
3. 迁移成本模型重新编译 + C++ 推理代码全套 API 从 hb_dnn 迁移至 hrt_runtime；

四、常见误区澄清

1. ❌ 误区：改后缀名就能跨芯片运行 ✅ 正解：内部 BPU 微指令集完全不同，修改后缀直接加载会初始化失败；
2. ❌ 误区：.hbo可以直接推理 ✅ 正解：.hbo只是编译中间目标文件，必须 link 打包为 hbm 才能被 runtime 加载；
3. ❌ 误区：.bin 里的校准 bin（calibration bin）= 推理模型 bin ✅ 正解：校准用 bin 是图像数组，和 BPU 推理模型.bin 是完全不同的两类文件。