通俗地讲讲算法开发和部署的流程

临在晨

已于 2023-08-31 20:35:03 修改

阅读量8.1k

点赞数 11

CC 4.0 BY-SA版权

文章标签：算法

于 2023-08-29 23:17:00 首次发布

本文链接：https://blog.csdn.net/cicy5219/article/details/132569303

许多学习资料都非常的碎片零散，算法是算法，部署是部署，开发是开发。学了算法不知道它怎么在机器上运行的，学了部署不知道开发是怎么调用它的，学了开发不知道算法要给你个什么玩意儿。

今儿个通俗地梳理一下整个算法开发和部署的流程，用我似懂非懂的理解。

1. 算法开发

简单理解，算法就是一种计算方法，无论是机器学习中的SVM，GBDT还是深度学习中的各种神经网络层，CNN，POOL，CBL，ELAN，SPPF，SPP，CSP，BOTTLENECK等等，都是一种计算方法，好比是一个参数待求的复杂的函数F(x)。需要从输入的数据中提取特征，经由函数映射到一个结果，可能是分类结果，也可能是回归结果。

1.1 明确目的与评估标准

就是我要实现个什么目的，一切都是为了解决真实问题，没有问题，就没有必要去开发，躺平就好。有了问题，就需要有应对方法，选择什么样的算法。而选择什么样的算法，有些前提条件，就是要满足使用要求，就像做土木工程的，盖房子有质量验收标准，比如要求结果墙体垂直度每层楼偏差正负八的话，要求高的话，就尽量用铝合金模板，这种工艺混凝土成型质量好。

算法的选择就像是选施工工艺，评估标准就是结果精度，这个精度可以是精准率、召回率、F1-score、AP值、mAP值、AUC等等。

1.2 算法设计/选型与数据准备

普通工程师选算法，研究员设计算法。工程师，就是个搭积木的，我不创造积木，当然偶尔有些想法能搞些出奇效的组合。

数据准备，需要去获取训练算法模型的数据集。这个活量大、技术含量低，一般外包给别人去做。到底需要多少量的数据，看经验，也看实际算法的结果。业内流传着一句话，决定算法精度的不是算法本身，而是数据，数据越大，效果也会更好，泛化性更强。

数据标签如果格式是VOC/XML的，如果需要转换成YOLO之类的格式的，又或者是CSV的需要转换成VOC的，转来转去，都只是一种形式，就像美少女衣服换来换去，关上灯还是一样的。

1.3 模型训练

有了算法、有了数据，就以训练了。

1.4 模型压缩

弄出来的模型参数量太大，上千万级别挺常见。这一堆参数就像是臃肿的机构，一开始咱也不知道谁能干谁不能干，但咱知道先把人堆起来，神奇的事情发生了，这机构的职能可以正常工作。所以也就暂且不管那些尸位素餐或者爱躺平的家伙了。慢慢地你会发现，能干的人越干越多，不能干的可有可无，浪费国家粮食。是不是像极了大企业大机构里的现象？臃肿就会导致给老百姓办事慢，做事效率低，还费钱。反应到算法上就是，模型占用内存大，模型推理速度慢。

模型剪枝，就是在给这个臃肿的机构裁员，能干的留下，不能干的（反应到参数上就是权重过小）滚蛋，今年裁它丫的50%，就真剩下50%的人（参数）了。工作量就像是水，盛它的小湖小沟少了，就自然要重新分流了。于时剪枝过后，还是要对算法fine-tune一下的。

模型蒸馏，这个还不会，以后弄明白了再说。

模型量化，简单理解为，在机构中以前管理很严格，表面工作很多，每次同事之间有点事情都需要写个报告，繁琐且没必要，耽误事儿。这类比的就是将FP32精度的权重，转换成FP16半精度甚至INT8的。每次有事同事之间不用搞那么仔细，随便说一下就行，这办事效率不就上来了么？但同样也会存在事情没说清楚的情况，导致结果有点偏差。

1.5 模型格式转换

这个世界有很多个国家，也有很多种语言，同样每个行业中也有很多种规范。比如建筑行业中，不同国家的设计标准是不一样的，即使是在中国不同省份的设计标准也有一些差异。这就是这个世界没有大一统整出来的费劲玩意儿，五花八门的框架，Pytorch, Caffe, Tensorflow, Keras, MXNet, Paddle-Paddle...

到模型部署的时候，硬件与软件支持的又有点儿不一样了，这些玩意儿弄出的模型格式不能用了，看不懂了，玩不转了。最后你还是得统一一下标准和格式，是要有GB（国标）还是要用BS（英标）还是要用ASTM（美标），不然承包商都不知道要什么要求干活，监理方也不知道按什么要求验收了。

这里有一个较为通用的格式ONNX，许多家推出深度学习框架的公司一起搞出来的，好比是一个通用标准。OpenVINO, TensorRT等常用的推理框架都支持。

2. 算法部署

2.1 部署框架选择

深度学习的框架有好多久，就像设计规范有好多种，最后要确定一种施工方能够接受的，熟悉的，适应的。有了模型，就好比是建筑业中有了设计，承包商拿到图纸后，得把房子盖起来。盖房子的过程好比是算法部署。

部署有很多种，有部署在服务器，部署在工控机，部署在手机，有的用的TPN（Tensor Processing Unit) / NPU(Neural Processing Unit) ，有的用的GPU(Graphic Processing Uint), 有的用的CPU。不同的平台不同设备资源，好比是干工地的，有的用挖机挖土，有的用人工挖土；打灰的有的用汽车泵打灰，有的人工推个小车打灰；有的工艺速度快，有的速度慢。

针对于不同部署环境，就有了不同的工艺和方法，也就是不同的推理框架。

有OpenVINO, TensorRT, NCNN, MCN, OnnxRuntime, TFLite, PyTorch Mobile等。

2.1 前处理与后处理

在模型训练、测试前是需要将数据进行预处理的，包括有必要的数据仿射变换（缩放、平移、旋转）、标准化、归一化、通道转换（BGR2RGB）等，训练阶段还包括诸如Mosaic, CopyPaste, HSV, RandomCrop, Flip, RandomScale等数据增强的处理。

模型输出的结果，还需要进行数据解码的操作。这些操作在部署是一样需要的。

2.2 模型推理

这些个推理框架封装了算法模型的解析工具，比如TensorRT里面就有NvOnnxParser这个工具，可以将导出的onnx格式的算法进行一个转换。当然也可以，利用TensorRT中内置的网络层重新构建一个算法模型。如果对网络层有定制化需求，也可以写一个TensorRT的插件。

有问题的是，为什么训练得到的模型不能直接用于部署呢？这是个好问题，这个世界破破烂烂，总有人缝缝补补。

2.3 打包生成SDK

这一堆玩意儿都写完后，整个项目并没有完，别人还是需要去调用这个推理代码。比如做了个可视化界面，用户可以拿起小鼠标点一点，就可以运行你的推理过程，又或者是自动的，总之还是有一些其它开发的活要做的，推理只是项目的一部分。

这时，做完了推理部署的代码后，需要将其打包，然后最好仅提供给别人几个它需要的接口即可。所谓接口，就好比是你使用"cout << "hello world!" << endl;" 一样，只是引入了一个头文件，然后编译时链接库文件即可。你要做的，就是把代码封装起来，编译成.so（动态库）或者.a（静态库）以及头文件，方便别人调用。所以在代码编写之前就要设计好，最后提供接口即可。