深度学习模型部署浅思

从深度学习模型Web服务展开来讲

对当前深度学习模型思考主要还是针对对应的数据集上如何构建模型，训练模型，以及模型在相关数据集（测试集）上的评估指标对模型进行评估。自然，从这一条线出发，考虑的就是模型如何设计以及相关的设计如何达到既定的目标。

而在具体生产生活中，深度学习模型迭代到一个合理版本的模型后，自然考虑的就是如何提供相应的模型处理服务以供大家使用。对于个人或是中小型公司一般而言会采用交互界面和模型处理逻辑结合的方式提供服务，目前，主要有三个方案可以选择：

一、Gradio + 深度学习模型

如果我们将深度学习服务开发看做传统的Web服务开发，那么Gradio可以看做是前端和API的结合体，而模型与模型的前后处理则是是后端处理模块。Gradio可以让开发者快速开发出一个拥有基础交互方式的界面，以提供给用户一个前端交互界面能够与相关模型进行交互，而不是直接命令行（因为如果是深度学习模型训练那一条线，大部分情况都需要和命令行交互）。

所以最快的构建方式是，利用Gradio快速搭建前端交互逻辑，运行模型，利用Gradio所自带的API服务公开自己的Web服务。

但这可能存在一个问题是，当用户比较多的时候，由于传统的深度学习模型无法进行异步执行，导致后一个用户需要等待模型处理完前一个用户的需求才能够执行后续用户的需求。

不过，在这里可以略微改进一点的是，增加一个等待请求池，其功能是在模型正在处理当前用户需求的情况下，将新来的用户请求放入等待请求池，给定一个批次（batch），每次取这些批次的请求一起丢入模型进行处理，增大整个模型运行的吞吐量。

二、前端 + API + 模型

（由于这里主要讨论的是Web服务，事实上，在这里还有另一种提供服务的方式是，开发桌面应用程序，应用程序启动的时候，模型也启动，并且根据对应的电脑硬件选择CPU还是GPU运行。） Gradio虽然提供了一个快速开发前端界面的功能，但是对真实场景的前端需求是不足以满足涉及需求的，因为Gradio设计初衷仅仅只是能够让模型能够有一个基础的交互界面，事实上并不能作为“真正”的前端开发工具。所以为了能够提供给用户一个更好的交互界面，当然仍需要回到传统的前端开发框架上。

那么这里就需要不同语言之间进行交互，因为传统的前端开发经常使用Vue.js + Java，而由于大部分的深度学习是基于python代码，所以对于模型的运行和部署主要还是在python代码上，就需要从python代码中提供API服务，常见的有Flask和Fastapi快速提供一个可用的API接口，以供前端调用。

不过在这里，还可以理解其他情况：

两种情况

只开发前端那么所有相关的模型则由互联网上的运营商所提供。此时还要注意一点的是，由于相关的模型运营厂商只提供一个基础模型的调用，模型的前处理和后处理仍然需要前端完成。
只提供模型服务这一类相当于将自己放在模型厂商的位置上，可以提供常用模型，也可以提供个性化模型设计。将相关的模型服务包装成API提供给用户进行调用。

其实走到这一步，已经基本上满足大部分应用的开发需求，因为只需要将模型看做是一个代码中的一个处理函数，就可以融入到之前的开发思路上。

但从实际的场景来看，由于深度学习模型本身参数较大，特别是在2023年开启的大模型时代，虽然其模型能力很强，但其运行成本也相对传统的算法处理函数更多。所以在实际开发中，就不得不需要考虑运行模型所带来的成本问题，以及如何降低模型运行的成本。

同时由于深度学习模型存在批次问题，或者说，由于大部分的深度学习是矩阵乘积的形式：，在较小的下，模型运行时间是差不多，因为此时的计算瓶颈仍然是通信瓶颈，所以同时处理更多的数据并不会增加模型的处理时间。

而另一方面，如果一个Web服务提供多个模型的服务，还需要考虑当前的设备是否能够支持多个模型运行，以及多个模型运行是否会导致模型之间争夺资源的问题。

当然，这些事情的考虑在模型服务提供厂商来说都可以解决，换句话说，如果负责前端开发就不需要关心这些事情，但如果需要自主模型部署则需要考虑。

三、前端 + 模型推理框架

所以，如果需要做到一个企业级的模型运行服务，或者至少能够尽可能让设备运行起来的服务，在这里就可以采用模型推理框架。

相关的模型推理框架一方面能够快速提供对应的API服务，同时针对模型的批次特点进行优化，同时对多个模型运行有负载均衡和调度的优化，能够根据当前硬件资源进行自主调度。但最现实的情况也是，当硬件性能有限的情况下，留给调度和性能平衡的空间就越小，硬件资源多的情况下，留给平衡的空间就大。

在这里简单列一下深度学习模型需要的推理服务框架的特点（不一定全）：

特点

能够合并请求在一个批次中进行推理。这应该是最常见的需求，不管是从训练的角度来说，模型可以一次性计算多个批次的数据，还是有强大计算能力的GPU，它在运行模型，可以一次性计算多个批次的数据而不影响模型推理速度，合并请求在一个批次都应该是一个很重要的能力。
热启动模型。与Flask和FastAPI不一样的是，推理服务框架本身可以单独启动，中间的模型可以在服务框架启动以后再进行启动，或启动以后注销。这能够加速模型服务的开发。
支持模型优化。由于模型推理服务，是不会有类似模型训练一样，需要梯度计算（但有一些服务提供微调服务，是需要这部分的内容的。）所以可以节省一定的计算量。类似地，如何更好地与硬件结合起来也是当前主流的研究方向，类似支持onnx等格式转换和运行。只不过有一些情况，相关硬件和推理框架配合得不是特别好，只能使用一个比较低效方式运行模型。
支持模型前后处理。类似CV模型，传入的图片数据需要做变换，以及图像处理以后也需要做处理，在一些轻量级的模型推理框架，这一部分也是能够在框架内部处理，并做成一个服务。

不过，由于我目前没有搜集太多关于服务推理框架的内容，所以在这里也只是做一个简单的收录：

服务框架	时间	特点
TensorFlow Serving	2016	只支持TensorFlow，但TF已经逐渐式微
Triton	2018	全都支持，但入门稍难
BentoML	2019	全都支持
kserve(原Kubeflow)	2020	全都支持
TorchServe	2020	只支持PyTorch，入门稍简单，但文档比较差

后续个人会拿一个到几个作为入门熟悉模型部署这一内容。