深度学习推理系统（二）：TorchServe的深入与性能监控

前提纪要

这应该是TorchServe系列最后一个(虽然总共也就两个)，而且因为TorchServe不更新了，所以哪怕是继续写推理框架系统，也大概率不会以TorchServe作为讨论对象了。

在上一篇中已经说到TorchServe的启动方式是以.mar打包方式进行模型服务的快速启动，但在当前深度学习模型参数量大的背景下，是压缩模型打包是很困难也是浪费时间的方式，所以当前能够较为舒服的使用的方式就是使用torch-model-archiver生成handler.py文件，去编写控制流程。

但不管是当前的大模型还是之前的深度学习模型，其处理流程都是类似的，用户发送请求，接着进行前处理、模型推理和后处理，然后再将生成的结果返回给用户，这里的具体细节由于上一篇已经讲过了，所以在这里不再赘述。除此之外，在上一篇还简单提到了，可以对模型进行ONNX和TensorRT等形式的转换，这一篇会深入去聊一聊。

不过这篇文章最主要的是，深入handler.py文件中的BaseHandler类，除了看看对用户的请求处理之外，我们还能够干什么。

BaseHandler类总览

正如之前所说，模型服务最核心的逻辑都在handler.py文件中，而在该文件中最重要的就是编写class Handler(BaseHandler)类方法，所以在这里展开来看这个类到底是什么。

首先，这个类是在base_handler.py文件中，在这个文件中，定义了很多与模型部署相关的组件和函数，具体来看：

• 导入部分：有日志模块logging和自定义时间记录模块timed，接着就是一些与部署组件相关的模块，诸如torch.compile、openvino、onnxruntime和torch_tensorrt等模块。
• handler.py类的函数：
  • 模型初始化相关的各种init、load等开头的函数：主要负责控制逻辑初始化和加载模型功能
  • 接着就是模型处理的:preprocess、inference和postprocess：也就是前处理，模型处理和后处理。
• 以及一些工具函数：handler、profiler等等。

总之整体的架构并不复杂，核心仍然是围绕着前处理，模型推理和后处理这三个步骤来的，在服务启动之前的可以叫做准备工作；对服务进行监控的比如timed可以叫做性能监控；在服务退出的时候，做回收处理，但这里似乎没有，可以理解到，深度学习模型服务中间不产生额外的文件，而作为一种函数性的处理方式在运行。

所以，上述的关系就可以这样表述：

可以看到，其主要有两部分，一部分就是模型启动，包括模型加载和预处理(可能存在模型需要转换等)，接着就是针对模型进行优化，首先需要进行性能检测，针对性能分析的结果进行模型调优，直到模型能够比较好地响应需求；另一方面，当模型作为一个服务部署提供服务的时候，仍然需要进行性能检测，此时则是进行动态调整和针对业务的进一步地再优化，比如当业务较多的时候通过负载压力来进行扩容，或者是通过性能检测发现存在的性能不足的问题，针对性地进行优化，从而能够以较小成本提供较多的提升。

告一段落的TorchServe

其实到这里，Torchserve已经可以告一段落了。也正如Torchserve那样，它出发点是以PyTorch为主要
启动器(当然也支持ONNX、TensorRT、OpenVino等模型模型框架，当然在自定义的前提下，也能够引入其他的部署模型框架)，同时在Pytorch-2.x版本中，还支持torch.compile直接对模型进行优化，以便快速构建小型深度学习模型的可快速移植可快速启动，以及搭配其工作流，将不同的模型搭配使用，构建一个复杂的模型工作流处理任务。

但这也随着大模型的到来，虽然在最近更新的版本中支持了huggingface和vllm等大模型相关的组件，对比其他的深度学习推理框架，比如TFserve其本身是因为TensorFlow的消失而跟着一起消失；Kserve，主要是以容器化的方式来支持模型服务运行(自定义更强)；TritonServer针对NIVIDIA有一定的优化，但个人也没用过不太好评价；BentoML和Kserve类似，主要是集中在容器化的工作。

所以从这个角度来看，Torchserve其实是一个很尴尬的局面，似乎它的发力点集中在小模型，以及小模型的配合上，所以当大模型登场（大模型一般会涉及到分布式部署），此时Torchserve就没办法很好地控制。而对于服务控制，特别是多个模型服务控制，其实就可以将他们看做是服务，所以多个服务的管理，使用容器化进行管理会比较好；另一方面，其本质上并不对针对模型进行优化，而只是提供基础通用的模型优化，如果对性能有极致地追求，仍然需要手工优化。

简单来说：

• 模型服务：
  • 在大模型视角下，之前主打小模型以及小模型的配合就是累赘。
  • 而针对大模型需要的分布式相关的功能并没有提供
• 模型推理：
  • 而对于性能上，在pyTorch的框架下提供部署和优化，如果需要极致性能追求，仍然需要手工完成。
  • 在大模型下的优化，就不单纯是直接优化那么简单。

所以，更好的选择就变成了，以分布式为主的容器化模型服务与通用基础、主流推理框架和自定义极致优化的方式搭配会更好。

后续的安排

所以关于TorchServe的内容就到此结束了，虽然里面有很多内容还可以继续深挖，但实际上，这些技术单拿出来也可以继续讲，而不需要依赖这个推理系统框架，但从入门的角度来看，从一个推理系统框架来进行入门其实是一个不算差的选择，因为首先它能够很快地提供一个快速上线的模板，熟悉了写基础模型服务以后，就可以开展两个方面的深入：

1. 容器化的推理框架模型：从当前活跃的推理系统框架来看，更多是侧重容器化管理，而主语模型能够提供什么服务，则并不关心，更多是模型作为一个服务来看待。
2. 模型部署与推理优化：而至于模型本身，特别是指针对已经训练好的模型进行部署与推理优化，其目标则是在已有的模型功能和参数的基础上，一方面实现基础的功能服务之外，另一方面针对推理性能上的问题进行优化。

所以后续这一系列的文章则是针对模型部署与推理优化作为主要讨论的方向，针对深度学习模型进行深入挖掘，而中间应该会涉有其他的以容器为主的推理系统框架介绍，大模型背景下的分布式式计算等相关技术。