博文视点
推理架构

在推理阶段，大模型应用从技术层面可以分为五层，分别是硬件层、资源编排层、模型服务层、中间件层和应用编排层，如图1所示。

图1 大模型应用推理分层架构
1．硬件层
硬件层主要根据设备的硬件进行区分，其中主要有两个方面。
1）GPU或CPU设备
根据是否拥有GPU，以及不同的GPU供应商，会有不同的解决方案。例如，在推理加速引擎方面，对于英伟达平台，首推TensorRT，对于Intel平台，则首推OpenVINO。
2）设备类型
设备类型指的是服务器设备、个人计算机或边缘嵌入式设备。这些设备的形态和应用场景决定了上层解决方案，它们在算力、可靠性、性能要求等方面通常存在很大的不同。例如，数据中心集群化方案可能会采用K8s，而边缘设备集群方案可能会选择K3s。
在大模型领域，很多加速引擎在设计之初就将优化部署硬件作为出发点和落脚点，选择合适的理论方案，在设备特性和场景要求之间取得平衡。
2．资源编排层
提高可用性和资源利用率的方法通常会涉及弹性伸缩、负载均衡、智能调度等。在资源编排层中，数据中心服务资源编排领域的主导者是K8s，还有一些公有云，如Azure、AWS和GCP。通过这一层的封装，开发者可以方便地将推理服务扩展到推理集群中。该层有一些细分的解决方案，如多云管理方案，例如Rancher、Karmada，还有提供任务调度策略的解决方案，例如Volcano可以结合大模型任务特点，通过合理调度来提升GPU的利用率。
3．模型服务层
模型服务层的目标是构建核心模型推理服务，并为上层提供高级服务接口。这一层是本章的重点，众多的优化方案也在这一层应用。根据工具的封装程度，可以将其分为三类：推理执行引擎（Inference Execute Engine）、推理服务（Inference Server）和开箱即用的对话类系统（Chat System）。
如图2所示，推理执行引擎的形态一般是一个库或工具包，结合场景和设备情况，对模型的相关技术进行优化，如量化、并行化等。它既可以在本地调用，也可以与一些高性能的Web服务框架集成进而提供推理服务。

图2推理执行引擎的基本流程
为了降低开发者的使用复杂度，统一提供模型服务接口，优化全局性能，例如动态批处理、屏蔽底层优化实现细节等，也有一些项目专注开发高性能且易用的推理服务，如Triton Server。
有一些项目的目标甚至是实现类似于ChatGPT这样的产品级服务，做到开箱即用，使大模型应用开发者能够轻松地在OpenAI接口和自己部署的服务之间切换。对于普通开发者来讲，这是一个福音，因为无须考虑内部的复杂性。
4．中间件层
随着生产级应用的复杂度和外界环境的复杂性越来越高，需要有一层执行公共工作，如拦截、过滤、防御和改写等，以提升大模型服务的安全性和可控性。基于这些目的，可参考Python Django框架的命名方式，将其称为“中间件层”。其中最常见的就是缓存，通过一些缓存策略可以减少大模型应用对模型服务的调用量，不仅可以提高速度，还可以节约算力成本。除此之外，如提示漏洞防御、访问审计、资源及服务监控等方面也属于这一层。这一层涌现了许多优秀的框架，如Guiduice、Rebuff和GPTCache等。对于框架开发者来说，中间件层是一个新兴领域，有许多课题需要研究。
5．应用编排层
应用编排层主要负责业务逻辑的编排实现和底层组件的集成，是整个大模型应用的中枢。应用编排层基于场景积累了大模型应用常见的编程模式，开发者可以基于简单一致的编程接口编写出高质量的大模型应用，而不需要了解底层细节。一个典型的例子是BabyAGI。目前，应用编排层的方案基本形成了三足鼎立的局面，即LangChain、Llama Index和Semantic Kernel（SK）。它们各有所长，如LangChain专注开发Agent应用，Llama Index专注开发RAG应用，Semantic Kernel拥有大量的微软技术栈开发者。
整个大模型应用的每层并不是孤立的，而是有机地联系在一起，它们是从解决问题角度逐层展开的。选择每层方案都需要考虑其他层的影响，最终选择合适的方案。
接下来针对模型服务层的不同层次，从Web服务、推理执行引擎、推理服务和对话类系统等几个角度进行常见的项目介绍，并提供一些选型建议，如图3所示。

图3 大模型推理常见项目

Web服务

业界发布的大模型都提供了完整的模型推理脚本，开发者可以很方便地体验其效果。以ChatGLM3-6B为例，它以多种演示形式呈现，其中包括了Web演示。只需执行以下命令，即可启动基于Gradio网页版的演示，图4所示为ChatGLM3运行截图。
git clone https://github.com/THUDM/ChatGLM3cd ChatGLM2-6B

安装依赖pip install -r requirements.txtpip install gradio

python web_demo_gradio.pyLoading checkpoint shards: 100%|████████████████████| 7/7 [00:12<00:00, 1.79s/it]Running on local URL: http://127.0.0.1:7860
从开发者生态的角度来看，业界已经形成了一个基本惯例，即将训练好的模型发布到HuggingFace上，从而共享模型并形成生态，类似于Docker Hub或Maven Nexus，如图5所示。

图4 ChatGLM3运行截图

图5 HuggingFace网站截图
开发者利用HuggingFace提供的工具包transformers，可以方便地进行自然语言处理模型的训练、推理和优化（高效参数微调库就是其中一部分）。例如，通过下面的代码可以拉取ChatGLM3-6B模型，在本地调试。

from transformers import AutoTokenizer, AutoModel>> > tokenizer = AutoTokenizer.frompretrained（”THUDM/chatglm3-6b”, trust remotecode=True）>> > model = AutoModel.from_pretrained（”THUDM/chatglm3-6b”, trust_remote code=True, device=’cuda’）>> > model = model.eval（）>> > response, history = model.chat（tokenizer, “你好”, history=[]）>> > print（response）你好👋!我是人工智能助手ChatGLM3 - 6B,很高兴见到你, 欢迎问我任何问题。>> > response, history = model.chat（tokenizer, “晚上睡不着应该怎么办”, history=history）>> > print（response）
如果因为网络环境问题或者需要在私有环境中操作，那么可以先将模型下载到本地再加载。从HuggingFace Hub下载模型需要先安装Git LFS，然后复制到本地。如果从HuggingFace下载速度慢，那么也可以从国内的ModelScope等模型社区下载。
在原型演示阶段，并不需要过多地考虑资源和响应速度等工程化问题，而是应将重点放在模型效果和流程的实现上。需要封装模型，提供推理接口或UI界面，以便用户或服务进行查看或调用。因此，能够快速开发原型，并尽可能减少不同角色和人员的参与，能够独立完成工作就成了这个阶段最重要的需求。
从快速构建模型原型服务的角度来看，对于主流的4个框架——Streamlit、Gradio、FastAPI、Flask，前两者可以通过编写Python代码生成带有界面的Web服务，后两者可以方便地构建API服务（Gradio也是基于FastAPI构建的）。ChatGLM3-6B服务就是利用这几个框架实现的推理演示服务。
1.Streamlit与Gradio
Streamlit与Gradio受欢迎的主要原因是它们是纯Python库，这使机器学习科学家或工程师可以轻松地使用自己熟悉的语言开发前端服务。它们的展示效果也相当不错，特别是Streamlit提供的图表非常酷炫。最重要的是，它们足够简单，可以快速地构建一个模型演示程序。以Gradio为例，只需要使用一行代码便能生成一个模型演示网页，如图6所示。
from transformers import pipelinegr.Interface.from_pipeline（pipeline（”question-answering”, model= “uer/roberta-base-chinese-extractive-qa”））.launch（）

图6 Gradio生成模型演示网页
如果需要自定义界面，那么也可以通过Python代码实现（类似于Java中的Swing），如图7所示。

图7 Gradio自定义界面
Gradio使用简单，专为机器学习模型场景演示而生，HuggingFace上的模型演示通常使用它，而且Notebook也可以原生嵌入。Streamlit的功能更加全面，界面样式更为美观，如果有数据可视化的需求，则可以重点考虑Streamlit，其界面如图8所示。总的来讲，二者的差别并不大。

图8 Streamlit界面
2.FastAPI与Flask
推理服务的关键在于将模型转变为服务（Model as Service），提供API接口，方便前端或其他服务调用。虽然这种方式也存在批量推理的需求，但相对较为简单，本文不进行讨论。FastAPI与Flask是完全用Python编写的Web 应用框架，可用于快速开发API服务。表9-1所示为Flask与FastAPI的差异对比。
表9-1 Flask与FastAPI的差异对比

Flask基于WSGI（Web Server Gateway Interface），成熟度和生态丰富性更好，总体用户量占优，是不折不扣的实力派；FastAPI基于 ASGI（Asynchronous Server Gateway Interface），是站在巨人肩膀上的新兴框架，大有赶超之势。FastAPI的亮点在于原生支持异步处理、速度快，同时内置数据类型检查和API文档生成功能，在开发工作中更高效。由于开发风格具有相似性，因此许多Flask用户已经向FastAPI迁移。FastAPI和Flask都是大模型后端的主流框架，我们在实际工作中选择哪种框架都不会有问题。
本文节选自《探秘大模型应用开发》（李瀚，徐斌，著；电子工业出版社）。