ONNX
第一部分:ONNX结构分析与修改工具
ONNX结构分析
ONNX结构的定义基本都在这一个onnx.proto文件里面了,如何你对protobuf不太熟悉的话,可以先简单了解一下再回来看这个文件。当然我们也不必把这个文件每一行都看明白,只需要了解其大概组成即可,有一些部分几乎不会使用到可以忽略。
解析模型用到的结构主要如下:
- ModelProto:最高级别的结构,定义了整个网络模型结构;
- GraphProto:graph定义了模型的计算逻辑以及带有参数的node节点,组成一个有向图结构;
- NodeProto:网络有向图的各个节点OP的结构,通常称为层,例如conv,relu层;
- AttributeProto:各OP的参数,通过该结构访问,例如:conv层的stride,dilation等;
- TensorProto:序列化的tensor value,一般weight,bias等常量均保存为该种结构;
- TensorShapeProto:网络的输入shape以及constant输入tensor的维度信息均保存为该种结构;
- TypeProto:表示ONNX数据类型。
上述几个Proto之间的关系:
将ONNX模型load进来之后,得到的是一个ModelProto
,它包含了一些版本信息,生产者信息和一个非常重要的GraphProto
;
在GraphProto
中包含了四个关键的repeated数组
-
node
(NodeProto
类型):存放着模型中的所有计算节点 -
input
(ValueInfoProto
类型):存放着模型所有的输入节点 -
output
(ValueInfoProto
类型):存放着模型所有的输出节点 -
initializer
(TensorProto
类型):存放着模型所有的权重
那么节点与节点之间的拓扑定义方式,每个计算节点都同样会有input
和output
这样的两个数组(不过都是普通的string类型),通过input
和output
的指向关系,我们就能够利用上述信息快速构建出一个深度学习模型的拓扑图。最后每个计算节点当中还包含了一个AttributeProto
数组,用于描述该节点的属性,例如Conv
层的属性包含group
,pads
和strides
等等,具体每个计算节点的属性、输入和输出参考这个Operators.md文档。
需要注意的是,刚才所说的GraphProto
中的input
输入数组不仅仅包含我们一般理解中的图片输入的那个节点,还包含了模型当中所有权重。举个例子,Conv
层中的W
权重实体是保存在initializer
当中的,那么相应的会有一个同名的输入在input
当中,其背后的逻辑应该是把权重也看作是模型的输入,并通过initializer
中的权重实体来对这个输入做初始化(也就是把值填充进来)
修改ONNX模型
解决问题的最好办法是从根源入手,也就是从算法同学那边的模型代码入手,我们需要告诉他们问题出在哪里,如何修改。但是也有一些情况是无法通过修改模型代码解决的,或者与其浪费那个时间,不如我们部署工程师直接在ONNX模型上动刀解决问题。
还有一种更dirty的工作是,我们需要debug原模型和转换后的ONNX模型输出结果是否一致(误差小于某个阈值),如果不一致问题出现在哪一层,现有的深度学习框架我们有很多办法能够输出中间层的结果用于对比,而据我所知,ONNX中并没有提供这样的功能;这就导致了我们的debug工作极为繁琐
所以如果有办法能够随心所欲的修改ONNX模型就好了。要做到这一点,就需要了解上文所介绍的ONNX结构知识了。
比如说我们要在网络中添加一个节点,那么就需要先创建相应的NodeProto
,参照文档设定其的属性,指定该节点的输入与输出,如果该节点带有权重那还需要创建相应的ValueInfoProto
和TensorProto
分别放入graph中的input
和initializer
中,以上步骤缺一不可。
经过一段时间的摸索和熟悉,我写了一个小工具onnx-surgery并集成了一些常用的功能进去,实现的逻辑非常简单,也非常容易拓展。代码比较简陋,但是足以完成一些常见的修改操作
第二部分:各大深度学习框架如何转换到ONNX
(需要说明的是,由于深度学习领域发展迅速,本文提到的几个框架也在快速的迭代过程中,所以希望本文提到的一些坑和bug在未来的版本当中能够逐一解决,也希望大家永远不要踩本文所提到的那些坑)
MXNet转换ONNX
MXNet官方文档给出了一个非常简单的例子展示如何转换
import mxnet as mx
import numpy as np
from mxnet.contrib import onnx as onnx_mxnet
import logging
logging.basicConfig(level=logging.INFO)
# Download pre-trained resnet model - json and params by running following code.
path='http://data.mxnet.io/models/imagenet/'
[mx.test_utils.download(path+'resnet/18-layers/resnet-18-0000.params'),
mx.test_utils.download(path+'resnet/18-layers/resnet-18-symbol.json'),
mx.test_utils.download(path+'synset.txt')]
# Downloaded input symbol and params files
sym = './resnet-18-symbol.json'
params = './resnet-18-0000.params'
# Standard Imagenet input - 3 channels, 224*224
input_shape = (1,3,224,224)
# Path of the output file
onnx_file = './mxnet_exported_resnet50.onnx'
# Invoke export model API. It returns path of the converted onnx model
converted_model_path = onnx_mxnet.export_model(sym, params, [input_shape], np.float32, onnx_file)
这个重点提一下MXNet转换ONNX模型可能会遇到的一些问题,不排除在未来版本MXNet修复了相关问题,也不排除未来ONNX版本更新又出现新的不兼容问题。
转换中坑比较多,具体可参考
Insightface中ArcFace MxNet2ONNX踩坑
Insightface中Retinaface MxNet2ONNX踩坑
-
与MXNet的BatchNorm层中的fix_gamma参数有关,当fix_gamma参数为True时,其含义是将gamma这个参数固定为1,即(x-mean)/var * gamma + beta;但是这里就出现了不兼容的问题,因为在ONNX当中是没有fix_gamma这个属性的,如果fix_gamma为False不会有问题,如果fix_gamma为True就会出现两者计算结果不一致问题。解决方法很直观,当fix_gamma参数为True时,我们必须手动将ONNX当中的gamma参数全部置为1
-
与MXNet的Pooling层中的count_include_pad属性有关,这个问题应该是MXNet贡献者的疏忽,当Pooling层的类型为’avg’时,忘记了在生成ONNX节点时设置该属性。解决方法就是在_op_translation.py文件里增加一个分支,将这个遗漏属性补上。
count_include_pad = 1 if attrs.get("count_include_pad", "True") in ["True", "1"] else 0
# ...
# ...
# ...
elif pool_type == "avg":
node = onnx.helper.make_node(
pool_types[pool_type],
input_nodes, # input
[name],
count_include_pad=count_include_pad,
kernel_shape=kernel,
pads=pad_dims,
strides=stride,
name=name
)
- SoftmaxActivationm,在mxnet中,表明This operator has been deprecated.解决办法:手动修改SoftmaxActivation的op为softmax,axis=1对应channel。
当然,如果你不想直接修改MXNet的导出代码,也可以直接修改ONNX模型达到同样的目的,方法可以参考上一篇文章中的小工具
TensorFlow模型转ONNX
tf的模型转换ONNX已经有现成的转换工具,https://github.com/onnx/tensorflow-onnx,先将tf的模型freeze_graph之后得到pb文件,再利用该转换工具即可转换为onnx模型
freeze_graph的方式网上有很多版本,我这里用的是一个老版本的方法(tensorflow==1.8.0)
# your network def
import network
input_size = (224, 224)
ckpt_model_path = "./model.ckpt"
pb_model_path = "./model.pb"
output_node_name = "your model output name"
graph = tf.Graph()
with graph.as_default():
placeholder = tf.placeholder(
dtype=tf.float32, shape=[None, input_size[0], input_size[1], 3], name="pb_input"
)
output = network(placeholder)
# your can get all the tensor names if you do not know your input and output name in your ckpt with this code
# nl = [n.name for n in tf.get_default_graph().as_graph_def().node]
# for n in nl:
# print(n)
saver = tf.train.Saver()
sess = tf.Session(
config=tf.ConfigProto(
gpu_options=tf.GPUOptions(
allow_growth=True, per_process_gpu_memory_fraction=1.0),
allow_soft_placement=True
)
)
saver.restore(sess, ckpt_model_path)
output_graph_def = graph_util.convert_variables_to_constants(
sess, sess.graph_def, [output_node_name]
)
with tf.gfile.FastGFile(pb_model_path, mode="wb") as f:
f.write(output_graph_def.SerializeToString())
# you can get the input and output name of your model.pb file
# maybe a "import/" is needed to append before the name if you
# get some error
# gf = tf.GraphDef()
# gf.ParseFromString(open('./model.pb', 'rb').read())
# nl2 = [n.name + '=>' + n.op for n in gf.node if n.op in ('Softmax', 'Placeholder')]
# for n in nl2:
# print(n)
需要指出的是大部分tf模型的输入layout都是NHWC,而ONNX模型的输入layout为NCHW,因此建议在转换的时候加上--inputs-as-nchw
这个选项,其他选项可以参考文档,非常详细
典型的转换命令如下所示:
python3 -m tf2onnx.convert --input xxxx.pb --inputs pb_input:0 --inputs-as-nchw pb_input:0 --outputs resnet_v2_101/predictions/Softmax:0 --output xxxx.onnx
注意,由于tensorflow的模型输入一般会比较灵活,输入的batch_size可以留空,可以在运行时传入不同大小的batch_size数据。但是一般在ONNX和TensorRT这些框架中,我们习惯于指定一个固定的batch_size,那如何修改呢,可以参考上一篇文章中我写的那个小工具,有一个例子展示如何修改ONNX模型的batch_size
PyTorch模型转ONNX
在PyTorch推出jit之后,很多情况下我们直接用torch scirpt来做inference会更加方便快捷,并不需要转换成ONNX格式了,当然如果你追求的是极致的效率,想使用TensorRT的话,那么还是建议先转换成ONNX的。
import torch
import torchvision
dummy_input = torch.randn(10, 3, 224, 224, device='cuda')
model = torchvision.models.alexnet(pretrained=True).cuda()
input_names = [ "input" ]
output_names = [ "output1" ]
dynamic_axes = {"input":{0:"batch_size"}, "output1":{0:"batch_size"},}
torch.onnx.export(model, dummy_input, "alexnet.onnx", verbose=True, input_names=input_names, output_names=output_names,opset_version=12,dynamic_axes=dynamic_axes)
TensorRT7.以后支持动态batch操作,tensorRT7.2.2.3支持opset_version=12,pytorch导出时设置dynamic_axes参数,导出后onnx输入输出变成input[batch_size,3,224,224],output[batch_size,1000]
当然也可以直接修改onnx方式,找到input和output进行修改,一般默认的data是model.graph.input[0],但是如果对graph的data做过删除再添加操作idx就修改了,可以遍历输入查找。
def createGraphMemberMap(graph_member_list):
member_map = dict()
for n in graph_member_list:
member_map[n.name] = n
return member_map
model = onnx.load_model(onnx_r)
graph = model.graph
input_map = createGraphMemberMap(model.graph.input)
if 'data' in input_map:
data_indx = list(input_map).index('data')
d = model.graph.input[data_indx].type.tensor_type.shape.dim
rate = (input_shape[2] / d[2].dim_value, input_shape[3] / d[3].dim_value)
print("rate: ", rate)
#d[0].dim_value = input_shape[0]
d[0].dim_param = '?'
d[2].dim_value = int(d[2].dim_value * rate[0])
d[3].dim_value = int(d[3].dim_value * rate[1])
for output in model.graph.output:
d = output.type.tensor_type.shape.dim
#d[0].dim_value = input_shape[0]
d[0].dim_param = '?'
d[2].dim_value = int(d[2].dim_value * rate[0])
d[3].dim_value = int(d[3].dim_value * rate[1])
onnx.save_model(model, args.onnx)
第三部分:ONNX到目标平台
ONNX实际只是一套标准,里面只不过存储了网络的拓扑结构和权重(其实每个深度学习框架最后固化的模型都是类似的),脱离开框架是没有办法直接进行inference的。大部分框架(除了tensorflow)基本都做了ONNX模型inference的支持,这里就不进行展开了。
那么如果你想直接使用ONNX模型来做部署的话,有下列几种情况:
第一种情况,目标平台是CUDA或者X86的话,又怕环境配置麻烦采坑,比较推荐使用的是微软的onnxruntime,毕竟是微软亲儿子;
第二种情况,而如果目标平台是CUDA又追求极致的效率的话,可以考虑转换成TensorRT;
第三种情况,如果目标平台是ARM或者其他IoT设备,那么就要考虑使用端侧推理框架了,例如NCNN、MNN和MACE等等。
第一种情况应该是坑最少的一种了,但要注意的是官方的onnxruntime安装包只支持CUDA 10和Python 3,如果是其他环境可能需要自行编译。安装完成之后推理部署的代码可以直接参考官方文档。
第二种情况要稍微麻烦一点,你需要先搭建好TensorRT的环境,然后可以直接使用TensorRT对ONNX模型进行推理;然后更为推荐的做法是将ONNX模型转换为TensorRT的engine文件,这样可以获得最优的性能。关于ONNX parser部分的代码,NVIDIA是开源出来了的(当然也包括其他parser比如caffe的),不过这一块如果你所使用的模型中包括一些比较少见的OP,可能是会存在一些坑;好在NVIDIA有一个论坛,有什么问题或者bug可以在上面进行反馈,专门有NVIDIA的工程师在上面解决大家的问题,不过从我两次反馈bug的响应速度来看NVIDIA还是把TensorRT开源最好,这样方便大家自己去定位bug
第三种情况的话一般问题也不大,由于是在端上执行,计算力有限,所以确保你的模型是经过精简和剪枝过的能够适配移动端的。几个端侧推理框架的性能到底如何并没有定论,由于大家都是手写汇编优化,以卷积为例,有的框架针对不同尺寸的卷积都各写了一种汇编实现,因此不同的模型、不同的端侧推理框架,不同的ARM芯片都有可能导致推理的性能有好有坏,这都是正常情况。
来源参考