【Atlas 200 DK玩转系列】【模型转换】模型转换失败时该怎么做(二)
紧接着上次讲到的模型转换失败时该怎么做(一),我们知道:
OMG是Framework的一个模型转换工具,OMG处理流程包含Parse解析->Optimize优化->Quantization量化->Build构建->Fusion融合和获取Task信息这几个步骤。
Parse解析中,Framework对原始网络文件及权重数据进行解析。如果网络本身有不满足Framework处理的要求的地方,会在此阶段打印错误日志。
Optimize优化中,Framework会对整个网络进行不同形式的优化,且当前的优化实际上是会在整个模型转换过程多个阶段的中进行,包括Scope融合,Pattern融合,节点删除等等。此阶段较少出现终止转换的报错,可能会出现一些不影响模型转换的ERROR,例如Pattern融合失败。
量化是模型转换中的可选流程,仅在转换命令中携带了量化配置才会进行量化。量化的过程是使用校准集作为输入,在host上进行量化推理,并根据结果计算量化参数,最终保存到模型中。量化过程基本与其他流程独立,所支持的算子也只是整个D平台支持算子的子集。
Build阶段是模型转换出错较多的阶段。此阶段将已经优化、量化完成的模型,按照模型拓扑结构,逐个算子进行build,完成om模型中的算子构建。此过程将根据算子输入shape和算子参数,计算算子输出shape并进行权重数据转换。此阶段常见问题是shape信息与Davinci要求的不匹配,或者算子参数组合不支持。
Fusion融合和获取Task信息阶段将build完成的算子进行底层优化融合,然后进行一次“假推理”,获得算子推理task信息。此阶段出错,主要还是底层校验算子报错,不满足其推理的要求。需要结合算子实际情况,根据整个模型转换的处理过程,分析出错原因。
Serialize阶段,将om算子,task信息等全部序列化保存为om模型文件,几乎不会报错。
当前Framework与具体的算子和网络存在一定耦合性,定位问题需要先明确Framework在业务流程各个阶段的动作和目标,然后结合具体问题场景进行分析!
今天再看一个例子:
ShuffleNet模型转换的时候选择8bit量化后模型转换失败,convertModel.log日志如下:
[ERROR] FMK:2019-05-23-10:20:29.220.547 CreateOp:framework/domi/calibration/op/op_factory.cpp:20:"OpFactory::CreateOp: Not supported OP, type = ShuffleChannel"
如下图所示:
图3-8 模型转换失败日志
从上面的日志中很清晰的可以看到,是在量化阶段出现的问题(calibration),报不支持的OP!
那我们先来了解下量化这个概念:
量化是指对高精度数据进行低Bit量化,从而达到节约网络存储空间、降低传输时延以及提高运算执行效率的目的。
当前支持Caffe:卷积算子:Convolution,全连接算子:FullConnection以及深度卷积:ConvolutionDepthwise;TensorFlow:卷积算子:Conv2D,全连接算子:MatMul算子的量化,包括权重、偏置、数据量化。量化模式分为:无offset、数据offset。
量化后的权重、偏置在离线模型生成阶段即被保存在离线模型中,在模型推理阶段使用量化后权重、偏置对数据进行计算。
各概念的说明如下:
无offset:权重和数据都采用无偏移模式。
数据offset:数据采用有偏移模式,权重采用无偏移模式。
权重量化:根据量化算法对权重文件进行Int8量化。若是有offset量化模式,则输出Int8权重、scale和offset;若是无offset量化模式,则输出Int8权重和scale。当前权重量化仅支持无offset量化模式。
数据量化:经过有限输入(校准集,用于训练量化参数、保证精度)进行推理执行,根据频率统计和散度计算算法等,若是数据offset量化模式,则计算出量化数据的scale和offset;如果无offset量化模式,则计算出量化数据的scale。
偏置量化:根据权重量化的scale、数据量化的scale,将FP32偏置数据量化为Int32输出。
现在我们知道了,shufflenet模型中的shuffleChannel算子暂时还不支持量化。
只有当算子支持量化时,才可以使用exclude_op选项将算子加入黑名单使之不进行量化。
当前只支持量化的算子有Convolution、Full Connection与ConvolutionDepthwise。
那么模型转换的时候暂时不要用量化了,重新转换成功。
- 点赞
- 收藏
- 关注作者
评论(0)