前面的碎碎念

之前主要是业务上需要针对模型部署做一些调研和实践。其实模型部署推理框架的概念，更像是DevOps（部署运维）的概念的延伸，而除了之前介绍的TorchServe之外，还有NVIDIA的Triton Server，Kubernet的Kserve，BentoML等，都是在这个上面提供相关的功能，或者说，我们从“微服务架构”来看，相关的模型服务就是一个个微服务。而另一方面，在大模型兴起的背景下，相关的模型推理框架，比如TorchServe实际上并没有针对大模型有更多的优化（至少vllm和现在的sglang都不是pytorch出的），也估计没有更多的精力来适配大模型的服务的部署，所以这一块的消退也是必然的。

其实正如之前的TorchServe（现在已经停止更新了），但并不意味着模型推理系统就没有了，相反，对个人来说，更应该看到，相关的模型推理系统是针对一整个系统和框架来设定的，作为一个底层的框架选定一个即可，所以自然也没有什么更多的与深度学习相关技术的整合了。

所以在做了上述推理系统框架的选定以后，接下来就是真正针对模型的部署了，以前没有深入这一块的时候还会认为，我有了模型推理框架以后，就能够自动地让模型抵达最高的计算效率，随着最近几个月的深入认识发现，事实上并没有这么简单，上述的推理系统框架只是提供了一个可以运行的环境，而在这个环境中模型如何进行计算是需要手动去操作的。

模型部署与模型推理加速

那么当前的任务就转变成，我们我们有一个模型如何让其在相关的模型推理系统框架上尽可能快速，准确且多的服务更多的人，这就是模型部署和模型推理加速的主要目的，更具体地，我们分别对模型部署和模型推理加速做一个直观的描述：

单模型部署

当前我们有个模型，我们将其部署在一个计算节点上，该节点可以是单个物理机器的单个计算设备（CPU，GPU，NPU，xPU），单个物理机器的多个计算设备（多GPU分布式部署），多物理机（多计算节点分布式部署）。

多模型部署

由于多人使用模型服务的时候会造成单模型压力，此时我们可以部署多个模型进行压力分担，或者叫做负载均衡，以此保证服务所提供的稳定性，响应时间等。

模型推理加速

针对一个模型，在已经部署的基础上，通过模型推理加速技术，在不改变模型精度或者仅降低一点精度的前提下，使得模型推理速度加快。

接下来就在这里对上述的两个内容进行总体上的阐述，以及将相关的问题给简单罗列一下，有一个总体上的理解。

模型部署概述

从模型推理系统框架说起

其实这一块是延续着之前TorchServe的模型推理系统框架的，只不过这里略微有点区别的是，模型推理系统框架除了单模型的多计算节点多副本部署之外，最大的作用就是能够作为一个系统管理底层的计算资源，模型调度(对不同用户访问频次进行感知，动态调整模型副本数量)。

从这个角度来看，TorchServe确实也不适合作为“模型推理系统框架”的服务作为，因为它并不能感知用户的访问频率和使用量对其进行模型副本的调整，当然有其他的方式来做到，但是这样Torchserve也就可有可无的。事实上，我认为TorchServe想要做的创新可能主要是结合Pytorch.compile以及workflow这两个来组合小模型之间的快速部署和配合，但在大模型的背景下，一个模型就可以看很多事情，而不是很多模型协同干一个事情，也可以看出之前相关团队对技术发展的没有做好足够的判断。

在这里，本文并不对模型推理系统框架作更进一步的介绍，而是停留在单个模型的模型部署上，特别地，就是针对单个模型的单副本部署。一般来说，主要有这么几个场景：

边缘场景：基于ARM的CPU上、主流电脑x86的CPU上和主流电脑的GPU上(NVIDIA，AMD等)、一些专用芯片TPU，xPU上等。
集群/数据中心场景：在多个计算节点上进行模型部署。

具体来说，一般模型部署流程，首先在深度学习框架(比如Pytorch、TensorFlow等)上搭建好深度学习模型，并且利用数据和深度学习框架对这些模型训练训练完毕以后，就可以把模型结构和模型参数分离开来，对这一块部分进行模型部署。大部分情况下模型部署只需要模型前向传播的计算即可，少部分场景还可以通过运行过程中获取的数据进行模型的训练。前者叫做“离线训练”，数据都是模型非部署时候采集的对模型进行训练，在部署时不改变模型；后者叫做“在线训练”，模型部署上去的时候，同时采集数据，利用在线搜集的数据对模型进行训练。

模型部署所思考的问题

但是不管哪一种形式，模型部署和深度学习框架都脱离了，或者说，当一个场景确定使用某模型的时候，其训练方法和计算过程也被确定下来，而不需要再维持一种“模型开发”的组件，比如深度学习框架。所以在这个基础上，模型部署天然地带有运行环境轻便，或者说去掉了很多冗余组件的情况，比如你不需要带着一个深度学习框架来计算一个模型。甚至更极端地，我们完全可以通过将前向传播的过程用函数的方式固定下来(此时该程序是完全针对该模型定制化的程序)，使得该程序的体系尽可能小，这就是模型部署。

当前主流模型部署框架有(并不全，只列举当前主流的框架)：

框架	地址	简介	支持平台
ONNX (Open Neural Network Exchange)	Github仓库	微软开发的开放模型格式标准，可以实现不同模型框架之间的转换	跨平台
TensorRT	Github仓库	NVIDIA开发的，针对NVIDAI计算设备的转换和优化	NVIDIA-GPU
OpenVINO	Github仓库	Intel硬件高性能推理	Intel-CPU、Intel-GPU、VPU
MNN (Mobile Neural Network)	Github仓库	阿里开发的，具有良好的通用性	ARM CPU、ARM GPU、X86 CPU、GPU等
TVM (Apache TVM)	Github仓库	深度学习编译器，支持多种后端硬件自动优化模型部署	多种CPU、GPU和专用加速器
mediapipe	Github仓库	Google开源，构建多模态应用机器学习管道，提供预构建组件（如目标检测、手势识别）	跨平台（移动、工作站、服务器）

从上面可以看到，当前模型部署的框架主要想要解决的就是，从已有的深度学习框架训练出来的模型如何在不同(指定)的硬件平台上以该硬件平台上运行的方式进行模型计算，如果硬件平台提供高效的计算方式，特别是矩阵计算方式，则能够提高模型计算速度。

简单来说，模型部署从编写代码到运行的时候可以看做，这一个程序脱离了之前的开发阶段，以一种精简的方式来进行运行，可能可以简单类比为JAVA程序能够在不同的硬件平台上运行，只要这个硬件平台能够运行底层的JAVA虚拟机。从上述主流的框架来看，可以针对移动端和边缘设备上部署，也可以针对特殊的设备比如NVIDIA设备进行部署。

可以简单总结这里面的问题：

模型开发所处的硬件平台并不是运行模型的硬件平台，需要适应部署的硬件平台。
那么，在初始平台中所表示的模型，就需要转换成部署的目标硬件平台
- ONNX就是解决了这种统一的表示(当然，最基本的表示仍然是模型公式，ONNX只是在计算机体系下如何进行模型的同一表示，所以其算子一直无法覆盖所有网络标识，也一直在更新)。

模型推理加速概述

接下来，在模型能够在任意的硬件平台部署的基础下，还需要思考一个问题如何让模型更快地进行推理，从实践经验来看，至少能够从两个视角来看一个深度学习模型：

从深度学习模型领域上看，大量的深度学习模型的主要任务是对目标任务进行优化，但其中会产生大量的计算冗余。这已经在一些针对深度学习现象的研究中已经多次指出了。
从高性能计算领域上来看，深度学习主要以矩阵计算为主(现在也在逐渐发展出稀疏的矩阵计算)，而一些计算上的融合，分块能够更高效地进行计算，从而能够加速模型推理。

接下来，就针对这两个简单展开来讲讲，在后续的章节会进行大量地讨论。

模型层面的加速

最近，或者说从深度学习(多层感知觉, MLP)一开始，就伴随着参数冗余的现象出现。在这里，并不去深入讨论起机制的产生，但起现象是一直伴随的。所以从模型层面描述模型推理加速，最重要的一点就是找到深度学习模型中冗余的部分，更准确来说，在尽可能不降低模型性能的基础上减少冗余部分，这本身是能够使得模型推理计算加速的。

高性能计算层面的加速

而从高性能计算角度来看，当前的深度学习模型主要以矩阵计算为主，并且最重要的，模型仍然是在当前的计算机体系中运行的，所以可以从针对矩阵计算优化，计算优化的角度来加速模型推理。

在这里简单做一点原理上的解释：那就是尽可能利用计算上的空间局部性和时间局部性来加速计算，简单来说就是，尽可能减少通信，尽可能做更多的计算，尽可能压缩计算。

而具体来看，在这里又有两方面的优化，一个是通用加速优化，也就是上述的矩阵计算的优化，还有一个是针对模型计算过程的优化，比如算子融合，计算图优化等操作。

总结

最后，对上述做一个总结。虽然看似是方向上的很大的转变，但实际上也是一步一步走过来逐渐认识到在更深层次还有这些需要去完善。

未来的规划

所以未来的方向，或者说更具体来说，针对模型部署来说，主要是针对模型推理加速这一方向来进行深入研究。具体来说，会有三方面的材料：

领域相关的最新的论文、博客和技术报告。
经典模型结构研究：有优化和加速价值的模型，其模型结构本身也是有价值的。
基础内容的回顾：包括计算数学，深度学习，计算机体系还有高性能计算。

额外再提一些相关内容

在当前，针对大语言模型的部署，还有vLLM和sglang框架，其实这一块属于模型部署上，它的定位(没有深入地理解)我感觉可以定位为，单副本部署的多用户服务，简单来说就是单个模型能够尽可能为更多的用户进行，因为简单来看vLLM的PagedAttention是让不同的Attention进行分页，从而相同的能够一起计算，充分管理好内存碎片，假设在没有进行模型本身的优化情况下，它能够提供更多的用户服务。所以这一块可以看做是模型部署的一个工作。

方向(部署与推理)的转变说明与整理