024、ONNX作为算子中间表示的优缺点分析
从一次惨烈的模型部署翻车说起
去年有个项目，团队花了两周训了一个YOLOv5变体，精度指标漂亮得很。到了部署阶段，我习惯性地用PyTorch导出ONNX，心想“ONNX嘛，业界标准，稳得很”。结果在RK3588的NPU上跑，前向推理直接崩了——算子不支持。查日志，发现一个Resize算子的coordinate_transformation_mode参数填了half_pixel，NPU的驱动只认asymmetric。改参数、重导出、再跑，又崩了，这次是ScatterND算子，NPU的编译器直接报“unsupported op”。
那两天我对着ONNX模型文件用onnxruntime的inference_session反复调试，最后不得不手写了一个自定义算子替换方案，才把模型跑起来。这次经历让我对ONNX又爱又恨——它确实解决了框架锁定的问题，但远没有宣传中那么“一次导出，到处运行”。
ONNX的“中间表示”定位：它到底想解决什么？
ONNX（Open Neural Network Exchange）最初是微软和Facebook在2017年搞出来的，目标很明确：让PyTorch训的模型能无缝跑到Caffe2上（当时Facebook还在推Caffe2）。后来演变成了一个跨框架、跨硬件的模型交换格式。
从技术角度看，ONNX本质上是一个