大模型部署
模型部署概念
定义
- 将训练好的模型在特定软硬件环境中启动的过程,使模型能够接收输入并返回预测结果
- 为了满足性能和效率的需求,常常需要对模型进行优化,例如模型压缩和硬件加速
形态和设备
- 产品形态
云端、边缘计算端、移动端 - 计算设备
CPU、GPU、NPU、TPU等
大模型特点
- 内存开销巨大
庞大的参数量。 7B 模型仅权重就需要 14+G 内存采用自回归生成 token,需要缓存 Attention 的 k/v,带来巨大的内存开销 - 动态shape
请求数不固定
Token 逐个生成,且数量不定 - 结构简单
相对视觉模型,LLM结构简单Transformers 结构,大部分是 decoder-only
大模型部署的问题
- 设备
如何应对巨大的存储问题?
如果model模型无法存储,内存不够加载,就根本运行不了
低存储设备 (消费级显卡、手机等)如何部署? - 推理
如何加速 token 的生成速度?
如何解决动态shape,让推理可以不间断?
(batch 的大小是不一致的:大的batch可能推理很慢,导致推理阻塞
如何解决不一致的batch输入时的连续输出问题,避免等待)
如何有效管理和利用内存? - 服务
如何提升系统整体吞吐量?
对于个体用户,如何降低响应时间?
大模型部署技术
- 模型并行
- 低比特量化
- transformer 计算和访存优化
- Continuous Batch
- Page Attention
- 其他
大模型部署方案和框架
大模型综合框架
transformers里也有模型部署的相关功能
HuggingFace—transformer
modelscope
云端
- lmdeploy
- vllm
- TensorRT—LLM
- deepspeed
- 其他
移动端
LMDeploy功能简介
LMDeploy核心功能—量化
量化功能
- 显存占用大
- 生成速度(访存速度慢是主要瓶颈)
基础概念
- 计算密集 (compute-bound): 推理的绝大部分时间消耗在数值计算上;针对计算密集场景,可以通过使用更快的硬件计算单元来提升计算速度比如量化为 W8A8 使用INT8 Tensor Core 来加速计算。
- 访存密集(memory-bound) : 推理时,绝大部分时间消耗在数据读取上;针对访存密集型场景,一般是通过减少访存次数、提高计算访存比或降低访存量来优化来提升性能。
- LLM 是典型的访存密集型任务
常见的 LLM 模型是 Decoder Only 架构。
推理时大部分时间消耗在逐Token 生成阶段 (Decoding 阶段) ,是典型的访存密集型场景。
如下图:A100的 FP16 峰值算力为 312 TFLOPS。只有在 Batch Size 达到128 这个量级时,计算才成为推理的瓶颈。由于 LLM 模型本身就很大推理时的 KV Cache 也会占用很多显存,还有一些其他的因素影响 (如Persistent Batch),实际推理时很难做到 128 这么大的 Batch Size。
量化的作用
- 提升输入长度
- 提高生成速度(访存速度)
4bit Weight Only 量化,将 FP16 的模型权重量化为INT4,访存量直接降为 FP16 模型的 1/4,大幅降低了访存成本,提高了 Decoding 的速度。 - 显存优化
加速的同时还节省了显存,同样的设备能够支持更大的模型以及更长的对话长度 - 注意:低比特量化不一定能加快计算(甚至由于计算时需要反量化,计算速度还有所下降),但是由于主要问题在于访存,所以低比特量化的加速还是很明显。
量化对象
量化的对象为以下
- 模型权重参数量化
- KV Cache量化
- 激活函数
- 梯度(训练时的量化)
现在许多量化是只进行参数量化(Weight Only)
参数量化
可量化的参数包括: 权重和激活值(Weight and Activation),对于矩阵乘法Y = WX,W为权重,X就是激活值(输入)。
一般不会量化Bias和Normalization:因为这些参数少,而且非常重要
大模型的参数量化包括两类:
- 仅量化模型参数,代表为W4A16(AWQ)
- 同时量化模型参数和激活值,代表为W8A8(SmoothQuant)
推理评估指标为:吞吐量(Throughput)和延迟(Latency)。对于W4A16和W8A8,可以根据业务场景的实际需求分别选用:
- 高吞吐 + 一般延迟:采用W8A8
- 低延迟 + 一般吞吐:采用W4A16
量化算法
GPTQ
AWQ
LMDeploy核心功能—推理引擎TurboMind
功能概述
持续批处理(Continuous Batch)
有状态推理
即对于历史信息的动态分割与融合
输入,输出以及KV Cache会被缓存下来
理论上可以支持无限长的状态存储
空间充足时:token id和k/v block一起存储
空间不充足时:只存储token id,再输入命中时,再重新启动推理得到其k/v value
K/V Cache
K/V value作为重要推理中间结果,将K/V value进行缓存,能够避免每次都从头推理,有效加速自回归推理过程。
最简单的K/V Cache就是全量的缓存
Blocked K/V Cache
将所有K/V value进行分块,并按照状态缓存和使用对应block的K/V value
高性能kernal算子
LMDeploy核心功能—推理服务和接口
服务
API-server
Triton inference server
接口
python
gRPC
RESTful
LMDeploy 的量化和部署实践
模型直接推理
模型转换
使用 TurboMind 推理模型需要先将模型转化为 TurboMind 的格式,目前支持在线转换和离线转换两种形式。
在线转换可以直接加载 Huggingface 模型,离线转换需需要先保存模型再加载。
在线转换
lmdeploy 支持直接读取 Huggingface 模型权重,目前共支持三种类型:
- 在 huggingface.co 上面通过 lmdeploy 量化的模型,如 llama2-70b-4bit, internlm-chat-20b-4bit
- huggingface.co 上面其他 LM 模型,如 Qwen/Qwen-7B-Chat
通过网络读取
# 需要能访问 Huggingface 的网络环境
lmdeploy chat turbomind internlm/internlm-chat-20b-4bit --model-name internlm-chat-20b
lmdeploy chat turbomind Qwen/Qwen-7B-Chat --model-name qwen-7b
上面两行命令分别展示了如何直接加载 Huggingface 的模型,第一条命令是加载使用 lmdeploy 量化的版本,第二条命令是加载其他 LLM 模型。
直接启动本地的 Huggingface 模型,如下所示。
lmdeploy chat turbomind /root/model/Singa_Model/internlm-chat-7b --model-name internlm-chat-7b
以上命令都会启动一个本地对话界面,通过 Bash 可以与 LLM 进行对话。
离线转换
离线转换需要在启动服务之前,将模型转为 lmdeploy TurboMind 的格式,如下所示。
# 转换模型(FastTransformer格式) TurboMind
lmdeploy convert internlm-chat-7b /path/to/internlm-chat-7b
lmdeploy convert internlm-chat-7b /root/model/Singa_Model/internlm-chat-7b
执行完成后将会在当前目录生成一个 workspace
的文件夹。这里面包含的就是 TurboMind 和 Triton “模型推理”需要到的文件。
命令行本地对话
我们先尝试本地对话(Bash Local Chat
),下面用(Local Chat 表示)在这里其实是跳过 API Server 直接调用 TurboMind。简单来说,就是命令行代码直接执行 TurboMind。所以说,实际和前面的架构图是有区别的。
这里支持多种方式运行,比如Turbomind、PyTorch、DeepSpeed。但 PyTorch 和 DeepSpeed 调用的其实都是 Huggingface 的 Transformers 包,PyTorch表示原生的 Transformer 包,DeepSpeed 表示使用了 DeepSpeed 作为推理框架。Pytorch/DeepSpeed 目前功能都比较弱,不具备生产能力,不推荐使用。
执行命令如下。
# Turbomind + Bash Local Chat
lmdeploy chat turbomind ./workspace
显存占用
![请添加图片描述](https://img-blog.csdnimg.cn/direct/8d40734526ac44a5a4d4c8d0df587f9b.png
量化模型结果
KV cache
量化结果
显存占用
很奇怪,量化后并没有降低显存,肯定是哪里出了问题。
W4A16
lmdeploy chat turbomind ./workspace_quant
结果
显存占用
模型部署
我们把从架构上把整个服务流程分成下面几个模块。
属于C/S架构:Server端要将Inference和API拆分开,C端即客户端
- 模型推理/服务。主要提供模型本身的推理,一般来说可以和具体业务解耦,专注模型推理本身性能的优化。可以以模块、API等多种方式提供。
- Client。可以理解为前端,与用户交互的地方。
- API Server。一般作为前端的后端,提供与产品和服务相关的数据和功能支持。
值得说明的是,以上的划分是一个相对完整的模型,但在实际中这并不是绝对的。比如可以把“模型推理”和“API Server”合并,有的甚至是三个流程打包在一起提供服务。
API服务
- 启动本地API
在上面的部分我们尝试了直接用命令行启动 Client,接下来我们尝试如何运用 lmdepoy 进行服务化。
”模型推理/服务“目前提供了 Turbomind 和 TritonServer 两种服务化方式。此时,Server 是 TurboMind 或 TritonServer,API Server 可以提供对外的 API 服务。我们推荐使用 TurboMind,TritonServer 使用方式详见《附录1》。
首先,通过下面命令启动服务。
# ApiServer+Turbomind api_server => AsyncEngine => TurboMind
lmdeploy serve api_server ./workspace \
--server_name 0.0.0.0 \
--server_port 23333 \
--instance_num 64 \ # 可以认为就是batch slots
--tp 1 # tensor 并行数
上面的参数中 server_name
和 server_port
分别表示服务地址和端口,tp
参数我们之前已经提到过了,表示 Tensor 并行。还剩下一个 instance_num
参数,表示实例数,可以理解成 Batch 的大小
然后,我们可以新开一个窗口,执行下面的 Client 命令。如果使用官方机器,可以打开 vscode 的 Terminal,执行下面的命令。
# ChatApiClient+ApiServer(注意是http协议,需要加http)
lmdeploy serve api_client http://localhost:23333
查看接口:
当然,刚刚我们启动的是 API Server,自然也有相应的接口。可以直接打开 http://{host}:23333
查看
注意,这一步由于 Server 在远程服务器上,所以本地需要做一下 ssh 转发才能直接访问(与第一部分操作一样),命令如下:
ssh -CNg -L 23333:127.0.0.1:23333 root@ssh.intern-ai.org.cn -p <你的ssh端口号>
网页 Demo 演示
实际上就是通过gradio
展示推理页面,后端还是TurboMind(命令行 或 API) 推理
这一部分主要是将 Gradio 作为前端 Demo 演示。在上一节的基础上,我们不执行后面的 api_client
或 triton_client
,而是执行 gradio
。
由于 Gradio 需要本地访问展示界面,因此也需要通过 ssh 将数据转发到本地。命令如下:
ssh -CNg -L 6006:127.0.0.1:6006 root@ssh.intern-ai.org.cn -p <你的 ssh 端口号>
TurboMind server API作为后端
本地推理—>API server(23333)—>gradio展示(6006)—>远程转发(6006)
先启动turbomind server建立API服务,再基于API server作为后端
API server不启动也能打开网页,但启动API server后才能推理
API Server 的启动和上一节一样,这里直接启动作为前端的 Gradio。
# Gradio+ApiServer。必须先开启 Server,此时 Gradio 为 Client
lmdeploy serve gradio http://0.0.0.0:23333 \
--server_name 0.0.0.0 \
--server_port 6006 \
--restful_api True
TurboMind 推理作为后端
当然,Gradio 也可以直接和 TurboMind 连接,如下所示。
# Gradio+Turbomind(local)
lmdeploy serve gradio ./workspace
可以直接启动 Gradio,此时没有 API Server,TurboMind 直接与 Gradio 通信。
结果
API server
本地API对话
查看API server
网页Demo
server API作为后端
作业
基础作业:
- 使用 LMDeploy 以本地对话、网页Gradio、API服务中的一种方式部署 InternLM-Chat-7B 模型,生成 300 字的小故事(需截图)
进阶作业(可选做)
- 将第四节课训练自我认知小助手模型使用 LMDeploy 量化部署到 OpenXLab 平台。
- 对internlm-chat-7b模型进行量化,并同时使用KV Cache量化,使用量化后的模型完成API服务的部署,分别对比模型量化前后(将 bs设置为 1 和 max len 设置为512)和 KV Cache 量化前后(将 bs设置为 8 和 max len 设置为2048)的显存大小。
- 在自己的任务数据集上任取若干条进行Benchmark测试,测试方向包括:
(1)TurboMind推理+Python代码集成
(2)在(1)的基础上采用W4A16量化
(3)在(1)的基础上开启KV Cache量化
(4)在(2)的基础上开启KV Cache量化
(5)使用Huggingface推理