PyTorch模型转ONNX完整指南：从训练到部署的实操记录

很多人做深度学习项目辛辛苦苦把数据集标注完模型也训练收敛了测试指标一切正常。结果一到真正部署环节直接卡在怎么把模型跑起来这一步。PyTorch训练出来的 .pth 文件在服务器上确实能跑但你要把它弄进手机App、边缘盒子、Web后端或者换个推理框架对方根本不认这个格式。我自己第一次遇到这个问题时也懵了后来才搞清楚行业里早就有一套标准流程来解决这件事核心就是先导出成ONNX文件再根据目标平台做后续转换。这篇内容就是一份完整的实操记录讲清楚从训练好的模型到生成ONNX文件的每一个步骤包含为什么必须这样做、具体代码怎么写、动态维度怎么配、导出之后怎么验证以及我在实际项目里踩过的各种坑。无论你是在跑YOLO系列的目标检测还是自己搭的语义分割模型这套流程都适用。1. 为什么要走ONNX这条路模型部署的第一性原理先说个反直觉的事实你用PyTorch或者是TensorFlow训练出来的模型文件本质上并不是一个纯粹的模型而是包含了训练过程各种信息的集合体。它里面有网络结构定义、权重参数还夹杂着训练框架自己的计算图表示、自动求导逻辑、甚至优化器的状态信息。这种文件只有在原始的框架环境里才能被完整加载和运行。部署环境恰恰是最不愿意装这些重型框架的。一个手机App不可能为了跑一个检测模型就内置一个完整的PyTorch运行时边缘计算盒子的存储和算力也经不起这种开销。ONNXOpen Neural Network Exchange这个格式就是为了解决这个问题而生的它像是一个模型界的通用语言把训练框架里的模型翻译成一套与框架无关的中间表示。翻译完之后不管底层跑的是ONNX Runtime、TensorRT、NCNN、RKNN还是OpenVINO都能直接识别和执行这个文件。这里要强调一个关键认知导出ONNX不是终点它只是部署链路的起点。我见过不少人以为导出完就万事大吉结果拿去做INT8量化或者转RKNN时发现各种算子不支持又得回头改模型结构。所以做这件事之前你要先想清楚最终部署的目标平台是什么是CPU服务器还是手机是NVIDIA显卡还是瑞芯微NPU。目标平台决定了你在导出阶段就要注意的若干约束条件。不过好消息是不管最终目标是什么PyTorch转ONNX这一段是共通的。只要这一段走通了后面的转换都是在ONNX的基础上再做一次翻译而已。所以这篇文章的核心就聚焦在这段共通的路径上把它彻底走通走顺。1.1 静态图和动态图的差别决定了转换方式要理解ONNX导出为什么有时候会莫名其妙报错得先理解PyTorch和ONNX在计算图表示上的本质差异。PyTorch采用的是动态图机制Define by Run也就是说你前向传播的代码第一次真正执行的时候计算图才被一点一点构建出来。这种机制非常灵活比如你可以根据输入数据的长度动态地写个 for 循环PyTorch会完美地处理它。但它的缺点是计算图在每次运行中都可能发生变化对部署场景来说这种不确定性是致命的。ONNX采用的是静态图机制Define by Run的反面它在导出那一刻就要把整个计算流程固定成一个确定的、没有分支歧义的图结构。这意味着什么意味着你在模型里写的很多动态逻辑比如如果某个条件满足就走这个分支否则走另一个分支在导出时都会被固定死在当前这个输入形状和条件下实际走过的路径。这也解释了为什么导出时必须给一个确定形状的 dummy_input。它不是随便走过场的而是用来触发整个前向传播流程让PyTorch按照这个输入的实际运算路径把计算图完整地记录下来再翻译成ONNX格式。所以凡是那些没有在 dummy_input 前向传播中被走到的代码分支都不会出现在最终的ONNX文件里。这是理解一切导出问题的地基。1.2 什么情况下不必导出ONNX写这篇文章前我得把边界说清楚。并不是所有场景都必须走ONNX。如果你只是在本地做研究或者推理环境就是一台能装PyTorch的GPU服务器而且你没有性能调优方面的硬性要求那直接用PyTorch推理反而更省事——毕竟少一层转换就少一份出错的可能。再比如你用了非常小众的自定义算子PyTorch框架里能跑但ONNX的算子集里压根没有对应项导出就会失败。我个人的判断标准很直接只要模型要离开我自己的训练环境跑到别的设备、别的框架、别的语言环境里去就值得走ONNX。尤其是现在服务化部署主流用的是TensorRT或者ONNX Runtime移动端主流是NCNN和MNNNPU上主流是RKNN和地平线工具链这些目标全部都能从ONNX格式出发做转换。所以ONNX更像是一个必经的中转站而不是最终形态。2. 导出前的模型体检不做好这一步后面全是坑很多人在导出ONNX时失败往往不是导出本身出了问题而是模型的代码写得太动态了。就像你把一件湿衣服直接塞进真空压缩袋压缩袋当然会鼓起来但你不能怪压缩袋质量差。所以在动手写导出代码之前我强烈建议先花半小时把模型代码体检一遍把那些会造成导出失败的隐患提前排除掉。2.1 模型结构固定把动态图思维改成静态图思维检查你模型里的所有运算是否都是形状可控的。最容易出问题的操作包括动态reshape_reshape_时用了依赖运行时才确定的尺寸信息、根据数据内容做的条件判断比如 if x.sum() 0、Python原生循环里依赖张量长度来决定循环次数。这些在PyTorch训练时都是好东西让代码非常灵活但到了导出时就会让转换器非常头疼。举个我真实踩过的例子。当时我写了一个轻量分割模型里面有个自适应池化层后面接了一个Flatten操作。训练时输入是固定尺寸的一切正常。导出时我给了不同的宽度结果就报错说维度对不上。根源在于我代码里有一处 view 操作写的是 view(-1, 64)这个 -1 在训练时能自动推断但ONNX严格要求每个维度的尺寸在静态图里可确定。后来我把这里的逻辑重构成了用自适应平均池化全局平铺问题立刻解决。所以导出前好好看看你的 forward 函数把所有依赖输入数据实际值大小的逻辑全部剔除。这就像是为了让一道菜可以大规模标准化生产你不得不放弃一些凭手感的烹饪方式一切都要用精确的克数和温度来控制。2.2 权重导出前的状态处理eval模式、no_grad、BatchNorm合并这个细节很多人会忽略但危害极大。训练完的模型处于 training 模式此时BatchNorm层会使用当前batch的统计量Dropout层会随机丢弃神经元。如果你不把模型切换到 eval 模式就直接导出导出的ONNX模型推理结果极不稳定甚至跟训练时的效果完全对不上。正确做法是import torch model.load_state_dict(torch.load(best_model.pth, map_locationcpu)) model.eval() with torch.no_grad(): torch.onnx.export(model, dummy_input, model.onnx, ...)eval() 会冻结BatchNorm的均值方差使用训练阶段积累的全局统计量no_grad 则是关闭梯度追踪一方面减少内存占用另一方面确保导出的计算图中不包含梯度相关算子。这两行代码是导出的基本功缺一不可。另外一个容易被忽视的点是PyTorch在导出ONNX时会对很多算子做融合和折叠特别是BatchNorm层它有可能被折叠进前面的卷积层中这也是为什么导出的ONNX文件里算子数量看起来比PyTorch模型少的原因之一。这是一件好事意味着推理时会少几次内存读写。2.3 输入输出命名与维度规划给模型的输入输出起名看起来是小事情但实际影响很大。后续推理时你要通过名字来喂数据和取结果名字起得含糊在排查问题时特别容易搞混。我一般遵循一个约定输入叫 input如果有多个输入就叫 input_1、input_2输出叫 output多个输出按语义命名比如 boxes、scores、labels。维度规划更关键。视觉模型默认是 NCHW 布局也就是 batch、channel、height、width 四个维度。这个不要去改它因为ONNX和大多数推理框架对NCHW的支持最完善。如果你训练时习惯用 HWC 通道在最后的格式导出时要在前处理里转回 CHW别想着让模型去迁就你的数据布局后面部署环节会有无数理由让你知道NCHW才是主流。3. 核心导出实操从checkpoint到onnx文件做完上面的准备工作就到了真正动手导出的环节。这段我会给出一套完整可跑的代码然后逐个参数拆解说明它们分别解决什么问题。你不需要再去看PyTorch官方文档翻来覆去直接拿这份代码改改模型路径和尺寸就能用。3.1 最基础的导出代码import torch import torch.onnx model torch.load(best_model.pth, map_locationcpu) model.eval() dummy_input torch.randn(1, 3, 640, 640) torch.onnx.export( model, dummy_input, model.onnx, input_names[input], output_names[output], opset_version13, dynamic_axes{ input: {0: batch_size}, output: {0: batch_size} }, do_constant_foldingTrue, ) print(export finished)这段代码就是最典型的目标检测模型导出配置。接下来我逐个解释为什么这些参数要这样设置以及不同场景下你需要怎么调整。3.2 dummy_input 到底怎么给dummy_input 是一个与模型真实输入布局强一致的假数据你不需要填充真实的值随机数就可以。但形状一定要准确批量大小、通道数、高、宽一个都不能错。比如你训练时用的是 640x640 的输入那这里就是 torch.randn(1, 3, 640, 640)。如果你的模型有多个输入比如有两个分支分别接收图像和文本这里就要传一个tupledummy_input (torch.randn(1, 3, 640, 640), torch.randn(1, 10, 512))必须强调的一点dummy_input 的维度直接影响ONNX之前导出的计算图对应的某些算子是否可以静态固定如果后续推理时使用了完全不同的输入尺寸需要对应地设置动态轴才行。所以别随手填一个尺寸思考和实际推理场景对齐后再设定。3.3 opset_version 到底选多少opset_version 指的是ONNX算子集的版本。不同版本的算子集支持的算子数量、算子的属性和行为都不一样。选得太低某些较新的算子无法表示导出直接报错选得太高一些老版本推理框架不支持对应opset又会反过来报加载失败。我的经验是目前 opset_version13 是一个比较安全的通用选择它支持INT8量化相关的大部分算子也能覆盖绝大多数PyTorch模型转换出来的算子组合。如果你的目标平台是NVIDIA的TensorRT那建议用更高的比如17或18但前提是你的推理框架版本支持。如果要做INT8量化opset不能低于13。如果目标设备是某些国产NPU芯片工具链文档通常会明确要求某个opset版本你照着设置就行。3.4 input_names 和 output_names 的深层作用除了让后续调用代码更可读这两个参数还有个重要作用它们是在给ONNX计算图中的节点做锚定。设置之后dynamic_axes 才能引用这个名字来指定动态维度后续在ONNX Runtime里推理时也是通过这个名字来定位输入输出张量的索引所以名字一旦定了后面所有调用它的代码都得保持一致。我见过有同事把 input 写成了 inputs结果后面所有推理脚本都跟着错了排查了半天最后发现只是多了一个 s这种低级错误真的会浪费一整天。3.5 do_constant_folding 该不该开do_constant_folding 代表是否开启常量折叠。这名字听着学术实际作用就是把模型结构里那些不依赖输入数据的子图比如某个固定权重矩阵乘提前计算好把多个计算节点合并成一个常量节点。这样导出的模型更小推理时也能省去一部分重复计算量。默认是True我建议保持开启没有特殊理由不要关。4. 动态维度配置让一个onnx适配多种输入尺寸做视觉模型的人一定遇到过这种需求模型导出时用的是 640x640结果到了真实场景里需要对不同尺寸的图片进行推理。如果不在导出时把宽高维度设为动态那么推理时只要输入尺寸跟导出时用的不一样程序直接就报错。这一节专门讲透动态维度配置。4.1 dynamic_axes 的基本语法先看基础写法dynamic_axes { input: {0: batch_size, 2: height, 3: width}, output: {0: batch_size, 2: height, 3: width} }这个字典的语义是对于名为 input 的张量第0维叫做 batch_size第2维叫做 height第3维叫做 width。同理 output 的第0维是 batch_size。一旦配置了动态轴ONNX图里这些位置就不会被固定成导出时的具体数值而是用名称作为占位符。以后你在推理时传入任意 batch_size、任意尺寸的输入它都接受。这里有个很容易搞混的知识点dynamic_axes 里的 0、2、3 这三个数字指的是张量的维度下标。以 NCHW 布局为例0就是N批量1是C通道2是H高度3是W宽度。一般通道维不要设置为动态因为大多数模型第一层的卷积权重是跟输入通道数绑死的通道变了整个网络结构都要变这种动态没有意义。4.2 多输出模型的动态维度写法如果你检测模型有多个输出头比如目标检测里常见的输出是 boxes、scores、labels 三个张量你需要在导出代码里把所有输出的名字都列出来并且分别指定它们的动态维度。我实际项目里用到的配置长这样torch.onnx.export( model, dummy_input, detector.onnx, input_names[input], output_names[boxes, scores, labels], opset_version13, dynamic_axes{ input: {0: batch_size, 2: height, 3: width}, boxes: {0: batch_size, 1: num_boxes}, scores: {0: batch_size, 1: num_boxes}, labels: {0: batch_size}, }, do_constant_foldingTrue, )注意一个细节boxes 和 scores 的第二个维度是检测框的数量 num_boxes。这个数量是模型根据输入图内容动态决定的不同图片检测出的目标数不同所以它必须设为动态。如果不设导出时只会保留导出那张假图检测出的目标数量后续推理时稍多一点目标就报形状不符。4.3 动态维度对后续转换的重要性你有没有遇到过这种情况导出的ONNX在ONNX Runtime里跑得好好的但拿去转NCNN或者RKNN的时候转换工具却报错说某个张量维度必须是静态的。原因就在于目标推理框架对动态形状的支持程度不同。以NCNN为例它对动态宽高的支持还算可以但对动态batch的支持就比较孱弱。在做边缘端部署时很多人干脆在导出阶段就把batch固定成1只把宽高设为动态这样转换工具的处理会更顺畅。这是一个典型的技术选型影响上游流程的例子。所以我在做导出前一定会先问一句这个模型最终是跑在哪个框架上如果你答不上来那就至少先把batch动态加上免得后面要跑多batch推理时回炉重造。如果目标平台明确不支持动态维度那就在导出阶段彻底固定形状反而能获得更好的优化空间。5. 导出后的验证链路别等部署了才发现模型是坏的ONNX文件生成成功不代表它就能正常工作。很多坑在导出时是完全沉默的只有在推理阶段才会爆发。我见过有人把模型导出后直接丢给部署同学部署完发现输出结果全是NaN回头排查了三天最后发现导出时少了eval()这一步。为了避免这种垃圾进垃圾出的情况建立一条可靠的导出验证链路是必须的。5.1 基础结构验证导出完成后第一件要做的事是用ONNX自带的检查器确认文件结构没有损坏import onnx model onnx.load(model.onnx) onnx.checker.check_model(model) print(model structure check passed)check_model 会遍历整个模型图检查所有节点的输入输出是否匹配、算子是否存在、属性是否合法。这个检查能拦下大部分结构性错误。如果你还想进一步查看模型内部结构可以用 onnx.helper.printable_graph(model.graph) 把计算图的内容以文本形式打印出来不过对于大模型来说输出非常长建议另存到文件里再用文本编辑器看。我对常用操作是先打印输入输出的基本信息确认跟预期一致for inp in model.graph.input: print(input:, inp.name, inp.type.tensor_type.shape) for out in model.graph.output: print(output:, out.name, out.type.tensor_type.shape)5.2 数值一致性测试与PyTorch原始模型对比这部分是验证链路里最核心的一环必须做不能跳过。思路非常简单用同一个随机输入分别跑 PyTorch 原始模型和 ONNX 模型对比两者的输出差异有多大。import numpy as np import onnxruntime as ort import torch # 随机输入注意要和导出时的预处理保持一致 test_input torch.randn(1, 3, 640, 640) # PyTorch推理结果 with torch.no_grad(): torch_output model(test_input) # ONNX Runtime推理结果 sess ort.InferenceSession(model.onnx, providers[CPUExecutionProvider]) input_name sess.get_inputs()[0].name output_names [out.name for out in sess.get_outputs()] onnx_output sess.run(output_names, {input_name: test_input.numpy()}) # 逐输出对比 for i, name in enumerate(output_names): diff np.abs(torch_output[i].numpy() - onnx_output[i]).max() print(foutput {name} max abs diff: {diff})diff 在什么范围内算正常绝大多数情况下如果模型没有用float16、没有做量化PyTorch的FP32输出和ONNX Runtime的FP32输出之间的误差应该在 1e-4 到 1e-6 这个量级。这种微小差异主要来自算子实现时浮点运算顺序的细微不同可以忽略。如果 diff 在 1e-2 这个量级以上那就要怀疑是导出过程中某个节点出错或者预处理不一致了。5.3 用onnxsim做模型精简验证数值通过之后我还会顺手做一步模型精简。这里用到的工具是 onnx-simplifier它的作用是通过一系列等价化简、常量折叠、算子融合把模型里的冗余节点清理掉让最终部署时更轻量、兼容性更好。安装和用法都非常简单pip install onnxsim python -m onnxsim model.onnx model_sim.onnx运行完注意对比一下简化前后的文件大小和数值一致性。我实际用过的最夸张的一个模型简化前有1200多个算子简化后只剩900多个文件体积小了差不多30%。而且有些算子转换工具比如某些NPU工具链对简化后的模型的兼容性反而更好因为它移除了很多不被支持的冗余子图。5.4 预处理一致性最容易翻车的隐形环节前面所有验证都通过部署后效果依然拉胯的情况90%出在预处理一致性上。你必须确保部署管线里的数据预处理和训练时完全一致包括但不限于是否统一缩放到 0-1 还是 0-255、是否有均值方差归一化、BGR和RGB的顺序、resize时用的是线性插值还是最近邻插值。我自己的做法是在导出ONNX的同时把训练代码里的预处理逻辑完整地摘出来写一份独立的预处理脚本部署端直接用这份脚本作为标准。这样能最大程度避免两边各搞一套预处理造成的隐性精度损失。这个习惯救过我很多次已经变成了我的标准操作。6. 从onnx到生产环境的最后一公里ONNX文件拿到手之后不同目标平台有不同的转换路径。这一节把最常见的几种后续链路列出来方便你心里有数。这一节不展开细讲每种转换里的所有细节但会给你指明方向。6.1 各大平台的转换路径概览这里我用一张表把常见目标平台和对应的转换方式列清楚目标平台转换工具链典型场景NVIDIA GPUTensorRTtrtexec 或 onnx-tensorrt云服务器、自动驾驶工控机移动端/嵌入式ARMNCNN / MNN / TNNAndroid App、国产化嵌入式设备瑞芯微NPUrknn-toolkit2 的 onnx2rknnRK3588/RK3568系列开发板地平线BPUhorizon_open_explorer 的 onnx转换旭日X3/J5等地平线芯片通用CPU服务器ONNX Runtime 直接加载后端服务化推理、批量离线推理Intel CPU/核显OpenVINOIntel平台服务端和边缘设备从这张表可以看出来ONNX几乎是一个绕不开的中转格式。所以我在前面强调导出ONNX只是第一步想清楚最终要去哪里才是完整的部署方案。6.2 INT8量化的基本流程注意点很多人处理器端模型时会考虑做INT8量化因为模型体积能缩小到原来的四分之一推理速度也能提升一截。量化可以在ONNX阶段做也可以在TensorRT阶段做。如果你需要在ONNX层面做量化推荐走 onnxruntime.quantization 这个官方API它支持动态量化和静态量化两种方式。动态量化最简单只需要准备校准数据不需要完整的前后向传播适合快速验证收益。静态量化则需要你提供一批有代表性的校准数据集工具会在这些数据上统计每个激活张量的数值范围然后计算出最佳的缩放和零点。校准数据集的质量直接决定量化后的精度损失程度一般建议准备几百到几千张有代表性的样本覆盖真实推理场景里会遇到的各种分布。做完量化后一定要回到第5节的数值一致性流程重新验证一遍量化模型的输出误差允许放宽到 1e-2 左右但如果超过 1e-1说明校准数据选得不好。6.3 碰到不支持的算子怎么办这是所有走ONNX路线的人早晚会遇到的问题我的模型明明导出了转目标平台工具链时报错说某个算子不支持。处理思路有几个层级第一选择是修改模型代码用目标平台支持的算子替换掉不支持的算子。比如有些NPU不支持某一种上采样方式换成双线性插值就能解决。这种情况比例不小。第二选择是升级opset_version很多算子的不支持只是转换工具用的opset版本太老升级到新版本后就有对应支持了。但要注意新版本算子在某些性能敏感的框架里可能支持不够好需要实测。第三选择是拆分导出把模型拆成几段单独导出在部署侧手动拼接成推理pipeline。这样做实现复杂度上去了但有时候确实是唯一出路。我心里有一条原则模型设计阶段就应该为部署而设计优先使用通用性强的标准算子避免花哨的自定义模块。如果你是从论文里复现的模型先看一眼它用了什么结构如果里面有非常规操作就要预判到后续部署的代价。7. 实测踩坑记录导出过程中我遇到过的典型问题这一节分享几个我真实遇到、排查了很久的问题。每个问题后面我都附上根因分析和解决路径希望能帮你缩短排查时间。7.1 动态维度导出失败的根因定位过程有次做一个车牌检测模型输入尺寸在训练时固定为 416x416但我希望部署时能支持 416x416 和 640x640 两种尺寸。于是我把宽度和高度都设成了动态轴结果导出时直接报错提示某个节点输入的形状不确定无法完成图优化。我不急着去动代码先打开ONNX可视化工具看一下报错节点的位置发现是在一个全连接层的前面。原来我的模型里在特征图经过卷积之后、进入全连接之前有一个显式的 reshape把空间维度压平。在静态尺寸下这一切正常但一旦宽高变成动态压平后的总长度就变成了一个动态值全连接层作为静态权重矩阵就无法接收到确定形状的输入了。解决办法是把全连接层替换为卷积核大小为 1x1 的卷积层这样就不需要对空间维度做压平动态尺寸也能畅通无阻。这件事给我一个教训动态维度不只是设置一个参数那么简单模型内部所有依赖空间尺寸的层全连接、固定形状的reshape都得重新审视。7.2 opset版本太低导致的算子报错还有一次我导出一个含Mish激活函数的轻量检测模型时怎么导都报 Unsupported operator: Mish。第一反应是ONNX里根本没这个算子后来查了算子集文档才发现Mish在ONNX里被拆成了多个基础算子组合只有opset版本13以上才支持这种分解方式。我把opset从11升到13问题立刻消失。这个经历说明导出报错时第一件事不是怀疑模型写错了而是先检查opset版本是不是过低。升级opset之后如果还有报错再去分析和模型结构的关系也不迟。7.3 预处理不一致带来的精度骤降最后一个问题最有迷惑性。有一次导出一个语义分割模型验证流程全部通过diff在1e-5量级看起来完美。结果部署到开发板上跑真实图片输出的分割图跟训练时的效果完全不在一个水平上严重偏色、边缘混乱。排查了一整天最后发现是部署代码和训练代码对图像缩放的顺序不同。训练时先归一化后缩放部署代码是先缩放后归一化两者在数值上产生细微差异。但别看差异小在分割任务里这个差异会被层层放大最终导致输出质量崩塌。从那以后我把预处理脚本作为模型导出的配套交付物一起提交给部署端再也没出现过这种问题。8. 总结但不空谈给你一份可以直接抄的导出清单写到这把整个过程梳理成一张检查清单方便你实际操作时对照使用。这些条目全部来自我实际项目中的血泪经验每条背后都有真实的踩坑案例。导出前确定目标部署平台反向确认要求的opset版本和动态维度支持情况检查forward函数移除所有依赖输入实际值的动态分支和动态reshape加载权重后调用 model.eval()导出过程包在 torch.no_grad() 里确认输入布局为NCHW通道数、宽高设置正确规划好输入输出张量的命名后面推理代码全部复用这套命名导出中torch.onnx.export 参数设置完整input_names、output_names、opset_version、dynamic_axes、do_constant_folding 全部显式指定动态维度配置时通道维固定batch和宽高按需动态导出完成后立即运行 onnx.checker.check_model排除结构性问题导出后用同一个随机输入对比PyTorch和ONNX Runtime的输出确认差异在可接受范围运行onnxsim精简模型再次验证数值一致性把训练时的预处理逻辑整理成独立脚本同步交付给部署端根据不同目标平台执行后续转换转换完成后做端到端精度验证关于最后一点我还想多啰嗦一句导出ONNX这件事属于会者不难难者不会的活。第一次做容易被各种报错折腾到怀疑人生多踩几次坑、多把每个参数的含义吃透之后你就能形成一套自己的标准操作流程。就像我现在从来不会临时抱佛脚去查文档所有参数配置都是刻在脑子里的肌肉记忆。这套方法论不仅适用于PyTorch转ONNX你以后接触TensorFlow转ONNX、PaddlePaddle转ONNX本质上都是同一个思路只是API略有差异。所以用心把这条链路吃透绝对值回票价。