024、ONNX作为算子中间表示的优缺点分析

024、ONNX作为算子中间表示的优缺点分析

从一次惨烈的模型部署翻车说起

去年有个项目,团队花了两周训了一个YOLOv5变体,精度指标漂亮得很。到了部署阶段,我习惯性地用PyTorch导出ONNX,心想“ONNX嘛,业界标准,稳得很”。结果在RK3588的NPU上跑,前向推理直接崩了——算子不支持。查日志,发现一个Resize算子的coordinate_transformation_mode参数填了half_pixel,NPU的驱动只认asymmetric。改参数、重导出、再跑,又崩了,这次是ScatterND算子,NPU的编译器直接报“unsupported op”。

那两天我对着ONNX模型文件用onnxruntimeinference_session反复调试,最后不得不手写了一个自定义算子替换方案,才把模型跑起来。这次经历让我对ONNX又爱又恨——它确实解决了框架锁定的问题,但远没有宣传中那么“一次导出,到处运行”。

ONNX的“中间表示”定位:它到底想解决什么?

ONNX(Open Neural Network Exchange)最初是微软和Facebook在2017年搞出来的,目标很明确:让PyTorch训的模型能无缝跑到Caffe2上(当时Facebook还在推Caffe2)。后来演变成了一个跨框架、跨硬件的模型交换格式。

从技术角度看,ONNX本质上是一个

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值