Hello各位好久不见~
继续老潘的含泪经验，紧接着AI算法工程师的一些含泪经验（一），除了训练模型阶段的注意点，这次更多的是一些部署方面的经验，希望能够对大家有帮助。依然是抛砖引玉，持不同意见的小伙伴欢迎留言！
再次强调一下训练集、验证集和测试集在训练模型中实际的角色：训练集相当于老师布置的作业，验证集相当于模拟试卷，测试集相当于考试试卷，做完家庭作业直接上考卷估计大概率考不好，但是做完作业之后，再做一做模拟卷就知道大体考哪些、重点在哪里，然后调整一下参数啥的，最后真正考试的时候就能考好；训练集中拆分出一部分可以做验证集、但是测试集千万不要再取自训练集，因为我们要保证测试集的”未知“性；验证集虽然不会直接参与训练，但我们依然会根据验证集的表现情况去调整模型的一些超参数，其实这里也算是”学习了“验证集的知识；千万不要把测试集搞成和验证集一样，”以各种形式“参与训练，要不然就是信息泄露。我们使用测试集作为泛化误差的近似，所以不到最后是不能将测试集的信息泄露出去的。
数据好坏直接影响模型好坏；在数据量初步阶段的情况下，模型精度一开始可以通过改模型结构来提升，加点注意力、加点DCN、增强点backbone、或者用点其他巧妙的结构可以增加最终的精度。但是在后期想要提升模型泛化能力就需要增加训练数据了，为什么呢？因为此时你的badcase大部分训练集中是没有的，模型没有见过badcase肯定学不会的，此时需要针对性地补充badcase；那假如badcase不好补充呢？此时图像生成就很重要了，如何生成badcase场景的训练集图，生成数据的质量好坏直接影响到模型的最终效果；另外图像增强也非常非常重要，我们要做的就是尽可能让数据在图像增强后的分布接近测试集的分布，说白了就是通过图像生成和图像增强两大技术模拟实际中的场景。
当有两个数据集A和B，A有类别a和b，但只有a的GT框；B也有类别a和b，但只有b的GT框，显然这个数据集不能直接拿来用（没有GT框的a和b在训练时会被当成背景），而你的模型要训练成一个可以同时检测a和b框，怎么办？四种方式：1、训练分别检测a和检测b的模型，然后分别在对方数据集上进行预测帮忙打标签，控制好分数阈值，制作好新的数据集后训练模型；2、使用蒸馏的方式，同样训练分别检测a和检测b的模型，然后利用这两个模型的soft-label去训练新模型；3、修改一下loss，一般来说，我们的loss函数也会对负样本（也就是背景）进行反向传播，也是有损失回传的，这里我们修改为，如果当前图片没有类别a的GT框，我们关于a的损失直接置为0，让这个类别通道不进行反向传播，这样就可以对没有a框的图片进行训练，模型不会将a当成背景，因为模型“看都不看a一眼，也不知道a是什么东东”，大家可以想一下最终训练后的模型是什么样的呢？4、在模型的最后部分将head头分开，一个负责检测a一个负责检测b，此时模型的backbone就变成了特征提取器。
工作中，有很多场景，你需要通过旧模型去给需要训练的新模型筛选数据，比如通过已经训练好的检测模型A去挑选有类别a的图给新模型去训练，这时就需要搭建一个小服务去实现这个过程；当然你也可以打开你之前的旧模型python库代码，然后回忆一番去找之前的demo.py和对应的一些参数；显然这样是比较麻烦的，最好是将之前模型总结起来随时搭个小服务供内部使用，因为别人也可能需要使用你的模型去挑数据，小服务怎么搭建呢？直接使用flask+Pytorch就行，不过这个qps请求大的时候会假死，不过毕竟只是筛选数据么，可以适当降低一些qps，离线请求一晚上搞定。
目前比较好使的目标检测框架，无非还是那些经典的、用的人多的、资源多的、部署方便的。毕竟咱们训练模型最终的目的还是上线嘛；单阶段有SSD、yolov2-v5系列、FCOS、CenterNet系列，Cornernet等等单阶段系列，双阶段的faster-rcnn已经被实现了好多次了，还有mask-rcnn，也被很多人实现过了；以及最新的DETR使用transformer结构的检测框架，上述这些都可以使用TensorRT部署；其实用什么无非也就是看速度和精度怎么样，是否支持动态尺寸；不过跑分最好的不一定在你的数据上好，千万千万要根据数据集特点选模型，对于自己的数据集可能效果又不一样，这个需要自己拉下来跑一下；相关模型TensorRT部署资源：https://github.com/grimoire/mmdetection-to-tensorrt 和 https://github.com/wang-xinyu/tensorrtx
再扯一句，其实很多模型最终想要部署，首要难点在于这个模型是否已经有人搞过；如果有人已经搞过并且开源，那直接复制粘贴修改一下就可以，有坑别人已经帮你踩了；如果没有开源代码可借鉴，那么就需要自个儿来了！首先看这个模型的backbone是否有特殊的op（比如dcn、比如senet，当然这两个已经支持了），结构是否特殊（不仅仅是普通的卷积组合，有各种reshape、roll、window-shift等特殊操作）、后处理是否复杂？我转换过最复杂的模型，backbone有自定义op，需要自己实现、另外，这个模型有相当多的后处理，后处理还有一部分会参与训练，也就是有学习到的参数，但是这个后处理有些操作是无法转换为trt或者其他框架的（部分操作不支持），因此只能把这个模型拆成两部分，一部分用TensorRT实现另一部分使用libtorc实现；其实大部分的模型都可以部署，只不过难度不一样，只要肯多想，法子总是有的。
转换后的模型，不论是从Pytorch->onnx还是onnx->TensorRT还是tensorflow->TFLITE，转换前和转换后的模型，虽然参数一样结构一样，但同样的输入，输出不可能是完全一样的。当然如果你输出精度卡到小数点后4位那应该是一样的，但是小数点后5、6、7位那是不可能完全一模一样的，转换本身不可能是无损的；举个例子，一个检测模型A使用Pytorch训练，然后还有一个转换为TensorRT的模型A`，这俩是同一个模型，而且转换后的TensorRT也是FP32精度，你可以输入一个随机数，发现这两个模型的输出对比，绝对误差和相对误差在1e-4的基准下为0，但是你拿这两个模型去检测的时候，保持所有的一致（输入、后处理等），最终产生的检测框，分数高的基本完全一致，分数低的（比如小于0.1或者0.2）会有一些不一样的地方，而且处于边缘的hardcase也会不一致；当然这种情况一般来说影响不大，但也需要留一个心眼。
模型的理论flops和实际模型执行的速度关系不大，要看具体执行的平台，不要一味的以为flops低的模型速度就快。很多开源的检测库都是直接在Pytorch上运行进行比较，虽然都是GPU，但这个其实是没有任何优化的，因为Pytorch是动态图；一般的模型部署都会涉及到大大小小的优化，比如算子融合和计算图优化，最简单的例子就是CONV+BN的优化，很多基于Pytorch的模型速度比较是忽略这一点的，我们比较两个模型的速度，最好还是在实际要部署的框架和平台去比较；不过如果这个模型参数比较多的话，那模型大概率快不了，理由很简单，大部分的参数一般都是卷积核参数、全连接参数，这些参数多了自然代表这些op操作多，自然会慢。
同一个TensorRT模型（或者Pytorch、或者其他利用GPU跑的模型）在同一个型号卡上跑，可能会因为cuda、cudnn、驱动等版本不同、或者显卡的硬件功耗墙设置（P0、P1、P2）不同、或者所处系统版本/内核版本不同而导致速度方面有差异，这种差异有大有小，我见过最大的，有70%的速度差异，所以不知道为什么模型速度不一致的情况下，不妨考虑考虑这些原因。
转换好要部署的模型后，一般需要测试这个模型的速度以及吞吐量；速度可以直接for循环推理跑取平均值，不过实际的吞吐量的话要模拟数据传输、模型执行以及排队的时间；一般来说模型的吞吐量可以简单地通过1000/xx计算，xx为模型执行的毫秒，不过有些任务假如输入图像特别大，那么这样算是不行的，我们需要考虑实际图像传输的时间，是否本机、是否跨网段等等。
未完待续...
往期回顾
关注“oldpan博客”，持续酝酿深度质量文
我是老潘，我们下期见~
打上星标✨不再错过老潘的及时推文
如果觉得有收获，来个点赞加好看
1560
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
