INT64除法算子约束与Cast修复全流程

地平线 征程 6 部署 YOLO26：从 INT64 Div 算子约束到 Cast 修复全流程

坦白说，在模型部署这条路上，总会遇到一些让人印象深刻的“坑”。今天要聊的这个，就跟 INT64 类型有关——在征程 6E/M 的 BPU 平台上部署 YOLO26 时，一个看似不起眼的类型问题，可能直接把推理速度拖慢一个档次。但问题的根源和解决方案，其实比想象中要干净利落得多。

一、YOLO26 的结构与创新

YOLO26 是基于 YOLOv8 架构改进而来的新一代目标检测模型，主要亮点有三。

DFL 移除

分布焦点损失（DFL）模块虽然有效，但导出时复杂度高，对硬件的兼容性也有限。YOLO26 直接把它拿掉了，推理流程简化了不少，对边缘设备和低功耗场景也更友好。

端到端无 NMS 推断

传统探测器往往要依赖 NMS 作为独立的后处理步骤，而 YOLO26 是端到端的——预测数据直接生成，延迟更低，集成进生产系统也更轻便、更可靠。加上 ProgLoss 和 STAL 改进后的损失函数，模型对小物体的识别能力有了显著提升。对物联网、机器人、航拍这类边缘应用来说，这一点至关重要。

MuSGD 优化器

一款结合了 SGD 与 Muon 的新型混合优化器，灵感来自 Moonshot AI 的 Kimi K2。它的核心贡献是把大模型训练中的先进优化方法引入了计算机视觉领域，带来了更稳定的训练过程和更快的收敛速度。

二、问题出现：HMCT 转换时的 Warning

事情的起因很常见：使用地平线的模型转换工具 HMCT（hb_mapper）把 YOLO26 的 ONNX 模型转成 .hbm 格式时，屏幕上弹出了这样的警告：

Warning: HMCT does not support input qtype: float32 for node: /model.23/Div_1; INT64 can't be quantized to float32Warning: HMCT does not support input qtype: float32 for node: /model.23/Gather_3; INT64 can't be quantized to float32

翻译成大白话就是：模型后处理部分藏着 INT64 类型的算子，HMCT 认不出，量不了。

三、根本原因：INT64 数据链路分析

借助诊断脚本，把 ONNX 模型里所有 INT64 节点过一遍，整个问题链路就清楚了：

TopK (/model.23/TopK_1)└── 输出 indices: INT64← ONNX 规范强制，无法修改 ↓ Div (/model.23/Div_1) 输入: INT64 / 常量80(INT64) ↓输出: INT64 ↓Gather 等后续节点

为什么 TopK 输出必须是 INT64？

没办法，这是 ONNX 算子规范写死的：TopK 算子的 indices 输出类型固定为 INT64，开发者没法改。只要 Div 的输入来自 TopK，那它的数据类型就只能是 INT64。

四、征程 6E/M BPU 对 Div 算子的约束

再查一查地平线征程 6E/M 的 ONNX 算子 BPU 约束列表，看看 Div 的限制：

lhs:quantized type 支持 int8, int16, int32其他类型支持 int16, int32, float16, float32rhs:lhs 和 rhs 的类型必须相同output:quantized type 支持 (int8/int16/int32 → int8/int16/int32)其他类型输入输出类型必须一致

关键信息来了：BPU 支持的整数类型是 int8、int16、int32，但唯独不支持 INT64。

这就带来了两个连锁后果。

后果一：HMCT 转换时报 Warning

HMCT 发现 Div 节点的输入是 INT64，无法量化，于是报警。

Warning: HMCT does not support input qtype: float32 for node: /model.23/Div_1; INT64 can't be quantized to float32

后果二：算子被迫回退到 CPU 执行

更严重的问题来了：因为 INT64 不在 BPU 算子约束的支持列表里，HMCT 没办法把 Div 及其下游节点调度到 BPU 上执行——这些节点会被自动丢给 CPU 处理。

这意味着整个推理流程变成了：

BPU 执行主干网络↓CPU 执行 Div 等节点← 严重拖慢推理速度↓输出结果

BPU 和 CPU 之间的数据搬运涉及内存拷贝，本身就有开销。再加上 CPU 串行执行这些节点，在实时检测场景下，这个延迟会变成明显的瓶颈，BPU 的算力优势完全发挥不出来。

修复目标很明确：把 Div 的数据类型改成 INT32，让它满足 BPU 算子约束，从 CPU 回退变回 BPU 执行，恢复完整的 BPU 推理链路。

五、为什么不能直接把 Div 改成 INT32

你可能会想：直接改 Div 节点的类型不就行了？

答案是行不通。原因在于：ONNX 计算图中，节点的输出类型是由它的输入类型推断出来的。Div 的第一个输入来自 TopK 的 INT64 输出，类型是锁死的。就算你强行修改节点的类型声明，shape_inference 和 checker 也会检测出输入输出类型不一致，模型校验通不过，onnxruntime 加载时一样会报错。

六、解决方案：在关键节点前插入 Cast

正确的做法是在类型不兼容的节点之间插入 Cast 算子，专门做类型转换。Cast 是 ONNX 里负责 tensor 类型转换的算子：

输入 tensor(INT64) → Cast → 输出 tensor(INT32)

修复后的链路是这样的：

TopK 输出 INT64↓Cast(INT64 → INT32)← 必须，TopK 强制 INT64，Div 不接受 INT64↓Div (INT32输入 → INT32输出) ← 满足 BPU 约束，可在 BPU 上执行↓GatherElements 等后续节点（INT32，BPU 执行）

真正要做的事其实就两件：

第一，在 TopK 输出后插入一个 Cast（INT64→INT32），从源头切断 INT64 的传播。

第二，把所有相关的旧 value_info 记录提前清理干净，让 shape_inference 从零开始重新推断整条链路的类型，自然收敛为 INT32。这样就不会出现旧的 INT64 声明和新推断结果冲突的问题。

另外，Div 用到的常量输入 Constant_21（值为 80，INT64）也需要同步转换成 INT32，保证 lhs 和 rhs 类型一致，满足 BPU 约束中“lhs 和 rhs 类型必须相同”的要求。

七、总结

核心经验：在地平线这类 BPU 平台上部署模型时，INT64 是个高频踩坑点。问题并不只是几个 Warning 那么简单——INT64 算子会因为不满足 BPU 约束而整体回退到 CPU 执行，导致 BPU/CPU 频繁切换和数据搬运开销，严重拖累推理性能。ONNX 规范中部分算子（比如 TopK）强制输出 INT64，解决思路不是硬改算子本身，而是在类型边界处插入 Cast 算子做类型转换，把整条链路改成 BPU 支持的 INT32，让这些节点重新回到 BPU 上执行。说到底，这是“规范约束”和“平台特性”之间的一次典型博弈，而 Cast 就是那个优雅的调和方案。