后端算法部署总结-python项目开发经验

hn_lgc

已于 2024-04-23 19:14:35 修改

阅读量503

点赞数 1

文章标签：深度学习图像处理

于 2024-03-29 20:20:05 首次发布

本文链接：https://blog.csdn.net/hn_lgc/article/details/137155129

版权

总体

后端算法才是未来，大号模型大参数才是未来。
以前总是执着于移动端，边缘端部署。
各种寻找小模型，边缘端优化技术，支持功能少，效果也没那么好。
眼光局限了。

这真是苦涩的教训阿。
OpenAI：与其执着于各种人工优化技巧，不如相信更大的算力（更多的参数和数据）。
https://www.bilibili.com/read/cv32692627/
http://www.incompleteideas.net/IncIdeas/BitterLesson.html

当前（2024年3月29日），算法进步是很快的，现在不行的任务功能，过一段时间可能就行了。

运行算法demo很简单，顺利的话半个小时
**但是部署没这么简单，有很多工作要做，**要了解算法相当多的细节，要嵌入到现有系统中，要处理输入输出接口化，还要考虑内存，速度，进度等的问题
基本上每个算法都是这样，全部弄下来的一两天了

比如即使是工程化已经做得十分完善的yolov8，都还要做很多工作
包括但不限于：选那个模型，耗时多少可以接受，输入图片大小控制，输出结构是怎么样的，了解了然后转换为系统可接受的形式，嵌入到当前的服务端框架里面，等等

想要完成某个功能任务，专门针对的算法没有，但是可以寻找其它通用算法来解决。
比如用sam，解决很多分割相关的任务。
用yolov8训练出来的算法检测人脸，比很多专门优化的人脸检测算法还好。

部署调试-联调经验

服务器用postman调试，方面快捷得多，不要用软件，idea发送连接调试，各种问题，操作量增加，慢几倍、
Python comfyui调试节点，直接运行节点文件代码！不要还去跑一遍comfyui，跑网页，点击再调试
端上测试用缓存好的结果就行，不要每次请求服务器再调试
整体来说，涉及到多端，就是调试链路越短越好，尽可能只在一个端上充分调试好
因为每个端都可能出问题，操作量增加很多，时间慢几倍，甚至由于高成本，最后根本做不出来，难以成功
复杂则做不了原理，不是难做到，是直接就没了，做不到

算法端部署完了，多测试些用例，比如一般拿测试文件夹所有图片跑一遍

耗时和优化相关

模型已经加载到CPU，启动运行模型，包括加载到GPU也会耗时，这个耗时还相当长，yolov8 100M的模型需要半秒，其它会更多
cpu线程和GPU不是同步的，当cpu的推理代码运行完了，或者说tensor已经到了步骤C，cpu的步骤可能还在B，会出现我们最后从tensor获取结果，比如加载到cpu，的时候，还需要等待相当长时间才能获取结果

显存相关

pytorh的显存复用机制

显然，我们多次运行同一段代码，
当你多次运行相同的代码段时，如果涉及的 Tensor 尺寸不变，PyTorch 通常能有效地复用先前分配的显存。这是通过内部的缓存机制实现的，其中包括：

显存池：PyTorch 维护一个内部的显存池，它可以从这个池中快速分配和释放显存，而不是每次都向操作系统请求或释放显存，这减少了管理开销。
重用现有空间：如果一个操作请求的显存大小与缓存中已释放的显存块大小匹配，这块显存将被重新分配给新的操作，而不需要额外的显存分配步骤。

可以参考comfyui的model_management.py文件看看怎么管理模型的

python十分灵活，但这种灵活会影响后续代码维护修改

python写多了才知道，变量类型对于维护修改是十分重要的东西

要注意到，python动态语言的灵活性，写代码的时候方便很多，可以后续阅读，维护修改就增加了很大难度。
这时候，就要借助静态语言里面的很大东西，避免这个问题，如下

方法传参，固定类型，包括类型内部的东西
完成项目时要固定类型，包括类型内部的东西，比如ndarray维度：
由于动态特性，鸭子类型，你在写代码的时候，可能想方法传参不用固定类型，灵活传各种类型
但是，对于完成的项目，这样是不行的
问题：
后续阅读修改代码困难，不知道类型，你修改代码无从下手，理解代码逻辑也有困难，还得调试的时候看一遍、
参数更应该给出良好的注释，包括内部注释
类型过于灵活，即使你固定了参数类型，但是参数内部的东西也十分灵活，比如传递list进来，list里面又可能包含各种类型。
比如传递ndarray进来，它的维度是多少，内部数据类型是float还是int，这些不同也都会导致理解代码和修改代码困难

所以，在代码注释里面，要更加明确的标明这些东西。

其它地方的变量代码，也应该对类型、类型内部给与足够的注释
一样的道理，鸭子类型，过几天再看，你就不知道代码里面的变量具体是什么了
比如list，list内部到底是什么？
np数组，到底维度多少，类型是啥？
这些对于代码修改维护都是十分重要的东西
很多时候，代码操作不要过于灵活，除非性能等其它考虑
虽然节省代码行数，但是却会带来后续阅读，修改的困难
好的代码应该简单，简洁