(5)LMDeploy 大模型量化部署实践

视频地址：

https://www.bilibili.com/video/BV1iW4y1A77P/?vd_source=7ec57e9f8774c23edf14450231ffa086

MarkDown：

<u>https://github.com/InternLM/tutorial/blob/main/lmdeploy/lmdeploy.md</u>

Repo:

<u>https://github.com/internLM/lmdeploy</u>

1. 大模型部署背景

——模型部署

• 定义

将训练好的模型在特定软硬件环境中启动的过程，使模型能够接收输入并返回预测结果；

为了满足性能和效率的需求，常常需要对模型进行优化，例如模型压缩和硬件加速

• 产品形态

云端、边缘计算端、 移动端

• 计算设备

CPU、GPU、NPU、TPU等

——大模型特点

• 内存开销巨大

庞大的参数量。7B模型仅权重就需要14+G

内存采用自回归生成token,需要缓存Attention的kw,带来巨大的内存开销

• 动态shape

请求数不固定

Token逐个生成，且数量不定

• 相对视觉模型，LLM结构简单

Transformers结构，大部分是decoder-only

——大模型部署挑战

• 设备

如何应对巨大的存储问题？低存储设备（消费级显卡、手机等)如何部署？

• 推理

如何加速token的生成速度

如何解决动态shape,让推理可以不间断

如何有效管理和利用内存

• 服务

如何提升系统整体吞吐量？

对于个体用户，如何降低响应时间？

——大模型部署方案

• 技术点

模型并行、transformer计算和访存优化、低比特量化、Continuous Batch、Page Attention·…

• 方案

huggingface transformers、专门的推理加速框架

• 云端

Imdeploy、vllm、tensorrt-lIm、deepspeed

• 移动端

llama.cpp、mlc-llm

2.LMDeploy 介绍

LMDeploy是LLM在英伟达设备上部署的全流程解决方案。包括模型轻量化、推理和服务

 2.1 核心功能——量化

2.2.1 为什么做Weight Only的量化？

两个基本概念

• 计算密集(compute-bound):推理的绝大部分时间消耗在数值计算上 针对计算密集场景，可以通过使用更快的硬件计算单元来提升计算速度， 比如量化为W8A8使用INT8 Tensor Core来加速计算。

• 访存密集(memory-bound):推理时，绝大部分时间消耗在数据读取 上；针对访存密集型场景，一般是通过提高计算访存比来提升性能。

LLM是典型的访存密集型任务

• 常见的LLM模型是Decoder Only架构。推理时大部分时间消耗在逐Token生成阶段(Decoding阶段)，是典型的访存密集型场景。

Weight Only量化一举多得

• 4 bit Weight Only量化，将FP16的模型权重量化为INT4,访存量直接降为FP16模型的1/4，大幅降低了访存成本，提高了Decoding的速度。

• 加速的同时还节省了显存，同样的设备能够支持更大的模型以及更长的对话长度

2.2.2 如何做Weight Only的量化？

• LMDeploy使用MIT HAN LAB开源的**AWQ算法**，量化为4bit模型
• 推理时，先把4bit权重，**反量化回FP16**(在Kernel内部进行，从Global Memory读取时仍是4bit),依旧使用的是FP16计算
• 相较于社区使用比较多的GPTQ算法，AWQ的推理速度更快，量化的时间更短

2.2 核心功能——推理引擎TurboMind

2.2.1 持续批处理

• 请求队列
  • 推理请求首先先加入到请求队列中
• Persistent线程

  判断是否有request推理结束。结束的request,发送结果，释放槽位

  • 1.若batch中有空闲槽位，从队列拉取请求，尽量填满空闲槽位。若无，继续对当前batch中的请求进行forward
  • 2.Batch每forward完一次·
  • 转步骤1态的推理

2.2.2有状态的推理

2.2.3 blocked k/v cache

2.2.4 高性能 cuda kernel

2.3 核心功能——推理服务 api server

3.实践 ——安装、部署、量化

3.1 环境配置

创建并激活conda环境

安装lmdeploy

3.2 服务部署

3.2.1 模型转换

使用 TurboMind 推理模型需要先将模型转化为 TurboMind 的格式，目前支持在线转换和离线转换两种形式。在线转换可以直接加载 Huggingface 模型，离线转换需需要先保存模型再加载。

TurboMind 是一款关于 LLM 推理的高效推理引擎，基于英伟达的 FasterTransformer 研发而成。它的主要功能包括：LLaMa 结构模型的支持，persistent batch 推理模式和可扩展的 KV 缓存管理器。

3.2.1.1 在线转换

lmdeploy 支持直接读取 Huggingface 模型权重，目前共支持三种类型：

• 在 huggingface.co 上面通过 lmdeploy 量化的模型，如 llama2-70b-4bit, internlm-chat-20b-4bit
• huggingface.co 上面其他 LM 模型，如 Qwen/Qwen-7B-Chat

我们也可以直接启动本地的 Huggingface 模型。

以上命令都会启动一个本地对话界面，通过 Bash 可以与 LLM 进行对话。

2.2.1.2 离线转换

离线转换需要在启动服务之前，将模型转为 lmdeploy TurboMind 的格式。

执行完成后将会在当前目录生成一个 workspace 的文件夹。这里面包含的就是 TurboMind 和 Triton “模型推理”需要到的文件。

weights 和 tokenizer目录分别放的是拆分后的参数和 Tokenizer。如果我们进一步查看 weights 的目录，就会发现参数是按层和模块拆开的，如下图所示。

——关于Tensor并行

Tensor并行一般分为行并行或列并行，原理如下图所示。

*列并行*

*行并行*

简单来说，就是把一个大的张量（参数）分到多张卡上，分别计算各部分的结果，然后再同步汇总。

3.2.2 TurboMind 推理+命令行本地对话

模型转换完成后，我们就具备了使用模型推理的条件，接下来就可以进行真正的模型推理环节。

先尝试本地对话（Bash Local Chat），下面用（Local Chat 表示）在这里其实是跳过 API Server 直接调用 TurboMind。简单来说，就是命令行代码直接执行 TurboMind。

这里支持多种方式运行，比如Turbomind、PyTorch、DeepSpeed。但 PyTorch 和 DeepSpeed 调用的其实都是 Huggingface 的 Transformers 包，PyTorch表示原生的 Transformer 包，DeepSpeed 表示使用了 DeepSpeed 作为推理框架。Pytorch/DeepSpeed 目前功能都比较弱，不具备生产能力，不推荐使用。

启动后就可以和它进行对话了。

此时，Server 就是本地跑起来的模型（TurboMind），命令行可以看作是前端。

3.2.3 TurboMind推理+API服务

运用 lmdepoy 进行服务化。

“模型推理/服务”目前提供了 Turbomind 和 TritonServer 两种服务化方式。

此时，Server 是 TurboMind 或 TritonServer，API Server 可以提供对外的 API 服务。推荐使用 TurboMind。

首先，通过下面命令启动服务。

# ApiServer+Turbomind   api_server => AsyncEngine => TurboMind
lmdeploy serve api_server ./workspace \
	--server_name 0.0.0.0 \
	--server_port 23333 \
	--instance_num 64 \
	--tp 1

上面的参数中 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端口号>

而执行本命令需要添加本机公钥，公钥添加后等待几分钟即可生效。ssh 端口号就是下面图片里的 33087。

3.2.4 网页 Demo 演示

这一部分主要是将 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 端口号>

3.2.4.1 TurboMind 服务作为后端

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

3.2.4.2 TurboMind 推理作为后端

当然，Gradio 也可以直接和 TurboMind 连接，如下所示。

# Gradio+Turbomind(local)
lmdeploy serve gradio ./workspace

可以直接启动 Gradio，此时没有 API Server，TurboMind 直接与 Gradio 通信。

3.2.5 TurboMind 推理 + Python 代码集成

前面介绍的都是通过 API 或某种前端与”模型推理/服务“进行交互，lmdeploy 还支持 Python 直接与 TurboMind 进行交互，如下所示。

from lmdeploy import turbomind as tm
 
# load model
model_path = "/root/share/temp/model_repos/internlm-chat-7b/"
tm_model = tm.TurboMind.from_pretrained(model_path, model_name='internlm-chat-20b')
generator = tm_model.create_instance()
 
# process query
query = "你好啊兄嘚"
prompt = tm_model.model.get_prompt(query)
input_ids = tm_model.tokenizer.encode(prompt)
 
# inference
for outputs in generator.stream_infer(
        session_id=0,
        input_ids=[input_ids]):
    res, tokens = outputs[0]
 
response = tm_model.tokenizer.decode(res.tolist())
print(response)

在上面的代码中，我们首先加载模型，然后构造输入，最后执行推理。

加载模型可以显式指定模型路径，也可以直接指定 Huggingface 的 repo_id，还可以使用上面生成过的 workspace。这里的 tm.TurboMind 其实是对 C++ TurboMind 的封装。

构造输入这里主要是把用户的 query 构造成 InternLLM 支持的输入格式，比如上面的例子中， query 是“你好啊兄嘚”，构造好的 Prompt 如下所示。

"""
<|System|>:You are an AI assistant whose name is InternLM (书生·浦语).
- InternLM (书生·浦语) is a conversational language model that is developed by Shanghai AI Laboratory (上海人工智能实验室). It is designed to be helpful, honest, and harmless.
- InternLM (书生·浦语) can understand and communicate fluently in the language chosen by the user such as English and 中文.
<|User|>:你好啊兄嘚
<|Bot|>:
"""

Prompt 其实就是增加了 <|System|> 消息和 <|User|> 消息（即用户的 query），以及一个 <|Bot|> 的标记，表示接下来该模型输出响应了。

3.2.6 最佳实践

3.2.6.1 方案实践

首先说 “模型推理/服务”，推荐使用 TurboMind，使用简单，性能良好。

LMDeploy应该是Transformers的3-5倍左右。

3.2.6.2 模型配置实践

weights 的目录，里面存放的是模型按层、按并行卡拆分的参数，不过还有一个文件 config.ini 并不是模型参数，它里面存的主要是模型相关的配置信息。下面是一个示例。

[llama]
model_name = internlm-chat-7b
tensor_para_size = 1
head_num = 32
kv_head_num = 32
vocab_size = 103168
num_layer = 32
inter_size = 11008
norm_eps = 1e-06
attn_bias = 0
start_id = 1
end_id = 2
session_len = 2056
weight_type = fp16
rotary_embedding = 128
rope_theta = 10000.0
size_per_head = 128
group_size = 0
max_batch_size = 64
max_context_token_num = 1
step_length = 1
cache_max_entry_count = 0.5
cache_block_seq_len = 128
cache_chunk_size = 1
use_context_fmha = 1
quant_policy = 0
max_position_embeddings = 2048
rope_scaling_factor = 0.0
use_logn_attn = 0

其中，模型属性相关的参数不可更改，主要包括下面这些。

model_name = llama2
head_num = 32
kv_head_num = 32
vocab_size = 103168
num_layer = 32
inter_size = 11008
norm_eps = 1e-06
attn_bias = 0
start_id = 1
end_id = 2
rotary_embedding = 128
rope_theta = 10000.0
size_per_head = 128

和数据类型相关的参数也不可更改，主要包括两个。

weight_type = fp16
group_size = 0

weight_type 表示权重的数据类型。目前支持 fp16 和 int4。int4 表示 4bit 权重。当 weight_type 为 4bit 权重时，group_size 表示 awq 量化权重时使用的 group 大小。

剩余参数包括下面几个。

tensor_para_size = 1
session_len = 2056
max_batch_size = 64
max_context_token_num = 1
step_length = 1
cache_max_entry_count = 0.5
cache_block_seq_len = 128
cache_chunk_size = 1
use_context_fmha = 1
quant_policy = 0
max_position_embeddings = 2048
rope_scaling_factor = 0.0
use_logn_attn = 0

一般情况下，我们并不需要对这些参数进行修改，但有时候为了满足特定需要，可能需要调整其中一部分配置值。这里主要介绍三个可能需要调整的参数。

• KV int8 开关：
  • 对应参数为 quant_policy，默认值为 0，表示不使用 KV Cache，如果需要开启，则将该参数设置为 4。
  • KV Cache 是对序列生成过程中的 K 和 V 进行量化，用以节省显存。我们下一部分会介绍具体的量化过程。
  • 当显存不足，或序列比较长时，建议打开此开关。
• 外推能力开关：
  • 对应参数为 rope_scaling_factor，默认值为 0.0，表示不具备外推能力，设置为 1.0，可以开启 RoPE 的 Dynamic NTK 功能，支持长文本推理。另外，use_logn_attn 参数表示 Attention 缩放，默认值为 0，如果要开启，可以将其改为 1。
  • 外推能力是指推理时上下文的长度超过训练时的最大长度时模型生成的能力。如果没有外推能力，当推理时上下文长度超过训练时的最大长度，效果会急剧下降。相反，则下降不那么明显，当然如果超出太多，效果也会下降的厉害。
  • 当推理文本非常长（明显超过了训练时的最大长度）时，建议开启外推能力。
• 批处理大小：
  • 对应参数为 max_batch_size，默认为 64，也就是我们在 API Server 启动时的 instance_num 参数。
  • 该参数值越大，吞度量越大（同时接受的请求数），但也会占用更多显存。
  • 建议根据请求量和最大的上下文长度，按实际情况调整。

3.3 模型量化

本部分内容主要介绍如何对模型进行量化。主要包括 KV Cache 量化和模型参数量化。总的来说，量化是一种以参数或计算中间结果精度下降换空间节省（以及同时带来的性能提升）的策略。

正式介绍 LMDeploy 量化方案前，需要先介绍两个概念：

• 计算密集（compute-bound）: 指推理过程中，绝大部分时间消耗在数值计算上；针对计算密集型场景，可以通过使用更快的硬件计算单元来提升计算速。
• 访存密集（memory-bound）: 指推理过程中，绝大部分时间消耗在数据读取上；针对访存密集型场景，一般通过减少访存次数、提高计算访存比或降低访存量来优化。

常见的 LLM 模型由于 Decoder Only 架构的特性，实际推理时大多数的时间都消耗在了逐 Token 生成阶段（Decoding 阶段），是典型的访存密集型场景。

那么，如何优化 LLM 模型推理中的访存密集问题呢？ 我们可以使用 KV Cache 量化和 4bit Weight Only 量化（W4A16）。KV Cache 量化是指将逐 Token（Decoding）生成过程中的上下文 K 和 V 中间结果进行 INT8 量化（计算时再反量化），以降低生成过程中的显存占用。4bit Weight 量化，将 FP16 的模型权重量化为 INT4，Kernel 计算时，访存量直接降为 FP16 模型的 1/4，大幅降低了访存成本。Weight Only 是指仅量化权重，数值计算依然采用 FP16（需要将 INT4 权重反量化）。

3.3.1 KV Cache 量化

3.3.1.1 量化步骤

KV Cache 量化是将已经生成序列的 KV 变成 Int8，使用过程一共包括三步：

①第一步：计算 minmax。主要思路是通过计算给定输入样本在每一层不同位置处计算结果的统计情况。

• 对于 Attention 的 K 和 V：取每个 Head 各自维度在所有Token的最大、最小和绝对值最大值。对每一层来说，上面三组值都是 (num_heads, head_dim) 的矩阵。这里的统计结果将用于本小节的 KV Cache。
• 对于模型每层的输入：取对应维度的最大、最小、均值、绝对值最大和绝对值均值。每一层每个位置的输入都有对应的统计值，它们大多是 (hidden_dim, ) 的一维向量，当然在 FFN 层由于结构是先变宽后恢复，因此恢复的位置维度并不相同。这里的统计结果用于下个小节的模型参数量化，主要用在缩放环节（回顾PPT内容）。

第一步执行命令如下：

# 计算 minmax
lmdeploy lite calibrate \
  --model  /root/share/temp/model_repos/internlm-chat-7b/ \
  --calib_dataset "c4" \
  --calib_samples 128 \
  --calib_seqlen 2048 \
  --work_dir ./quant_output

这一步由于默认需要从 Huggingface 下载数据集，国内经常不成功。所以我们导出了需要的数据，大家需要对读取数据集的代码文件做一下替换。共包括两步：

第一步：复制 calib_dataloader.py 到安装目录替换该文件：cp /root/share/temp/datasets/c4/calib_dataloader.py /root/.conda/envs/lmdeploy/lib/python3.10/site-packages/lmdeploy/lite/utils/

第二步：将用到的数据集（c4）复制到下面的目录：cp -r /root/share/temp/datasets/c4/ /root/.cache/huggingface/datasets/

②第二步：通过 minmax 获取量化参数。主要就是利用下面这个公式，获取每一层的 K V 中心值（zp）和缩放值（scale）。

zp = (min+max) / 2
scale = (max-min) / 255
quant: q = round( (f-zp) / scale)
dequant: f = q * scale + zp

有这两个值就可以进行量化和解量化操作了。具体来说，就是对历史的 K 和 V 存储 quant 后的值，使用时在 dequant。

第二步的执行命令如下：

# 通过 minmax 获取量化参数
lmdeploy lite kv_qparams \
  --work_dir ./quant_output  \
  --turbomind_dir workspace/triton_models/weights/ \
  --kv_sym False \
  --num_tp 1

在这个命令中，num_tp 的含义前面介绍过，表示 Tensor 的并行数。每一层的中心值和缩放值会存储到 workspace 的参数目录中以便后续使用。kv_sym 为 True 时会使用另一种（对称）量化方法，它用到了第一步存储的绝对值最大值，而不是最大值和最小值。

③第三步：修改配置。也就是修改 weights/config.ini 文件，这个我们在《2.6.2 模型配置实践》中已经提到过了（KV int8 开关），只需要把 quant_policy 改为 4 即可。

这一步需要额外说明的是，如果用的是 TurboMind1.0，还需要修改参数 use_context_fmha，将其改为 0。

接下来就可以正常运行前面的各种服务了，只不过咱们现在可是用上了 KV Cache 量化，能更省（运行时）显存了。

3.3.1.2 量化效果

官方给出了 internlm-chat-7b 模型在 KV Cache 量化前后的显存对比情况

KV Cache 可以节约大约 20% 的显存。

在 opencompass 平台上测试了量化前后的精准度（Accuracy）对比情况

可以看出，精度不仅没有明显下降，相反在不少任务上还有一定的提升。可能得原因是，量化会导致一定的误差，有时候这种误差可能会减少模型对训练数据的拟合，从而提高泛化性能。量化可以被视为引入轻微噪声的正则化方法。或者，也有可能量化后的模型正好对某些数据集具有更好的性能。

总结一下，KV Cache 量化既能明显降低显存占用，还有可能同时带来精准度（Accuracy）的提升。

3.3.2 W4A16 量化

3.3.2.1 量化步骤

W4A16中的A是指Activation，保持FP16，只对参数进行 4bit 量化。使用过程也可以看作是三步。

①第一步：同 1.3.1，不再赘述。

②第二步：量化权重模型。利用第一步得到的统计值对参数进行量化，具体又包括两小步：

• 缩放参数。主要是性能上的考虑（回顾 PPT）。

• 整体量化。

第二步的执行命令如下：

#量化权重模型
lmdeploy lite auto_awq \
  --model  /root/share/temp/model_repos/internlm-chat-7b/ \
  --w_bits 4 \
  --w_group_size 128 \
  --work_dir ./quant_output 

命令中 w_bits 表示量化的位数，w_group_size 表示量化分组统计的尺寸，work_dir 是量化后模型输出的位置。这里需要特别说明的是，因为没有 torch.int4，所以实际存储时，8个 4bit 权重会被打包到一个 int32 值中。所以，如果你把这部分量化后的参数加载进来就会发现它们是 int32 类型的。

③最后一步：转换成 TurboMind 格式。

#转换模型的layout，存放在默认路径 ./workspace 下
lmdeploy convert  internlm-chat-7b ./quant_output \
    --model-format awq \
    --group-size 128

这个 group-size 就是上一步的那个 w_group_size。如果不想和之前的 workspace 重复，可以指定输出目录：--dst_path，比如：

lmdeploy convert  internlm-chat-7b ./quant_output \
    --model-format awq \
    --group-size 128 \
    --dst_path ./workspace_quant

接下来和上一节一样，可以正常运行前面的各种服务了，不过咱们现在用的是量化后的模型。

最后再补充一点，量化模型和 KV Cache 量化也可以一起使用，以达到最大限度节省显存。

3.3.2.2 量化效果

官方在 NVIDIA GeForce RTX 4090 上测试了 4-bit 的 Llama-2-7B-chat 和 Llama-2-13B-chat 模型的 token 生成速度。测试配置为 BatchSize = 1，prompt_tokens=1，completion_tokens=512，结果如下表所示。

可以看出，TurboMind 相比其他框架速度优势非常显著，比 mlc-llm 快了将近 30%。另外，也测试了 TurboMind 在不同精度和上下文长度下的显存占用情况，如下表所示。

可以看出，4bit 模型可以降低 50-60% 的显存占用，效果非常明显。

总而言之，W4A16 参数量化后能极大地降低显存，同时相比其他框架推理速度具有明显优势。

3.3.3 最佳实践

本节是针对《模型量化》部分的最佳实践。

首先我们需要明白一点，服务部署和量化是没有直接关联的，量化的最主要目的是降低显存占用，主要包括两方面的显存：模型参数和中间过程计算结果。前者对应《3.2 W4A16 量化》，后者对应《3.1 KV Cache 量化》。

量化在降低显存的同时，一般还能带来性能的提升，因为更小精度的浮点数要比高精度的浮点数计算效率高，而整型要比浮点数高很多。

所以我们的建议是：在各种配置下尝试，看效果能否满足需要。这一般需要在自己的数据集上进行测试。具体步骤如下。

• Step1：优先尝试正常（非量化）版本，评估效果。
  • 如果效果不行，需要尝试更大参数模型或者微调。
  • 如果效果可以，跳到下一步。
• Step2：尝试正常版本+KV Cache 量化，评估效果。
  • 如果效果不行，回到上一步。
  • 如果效果可以，跳到下一步。
• Step3：尝试量化版本，评估效果。
  • 如果效果不行，回到上一步。
  • 如果效果可以，跳到下一步。
• Step4：尝试量化版本+ KV Cache 量化，评估效果。
  • 如果效果不行，回到上一步。
  • 如果效果可以，使用方案。

简单流程如下图所示。

另外需要补充说明的是，使用哪种量化版本、开启哪些功能，除了上述流程外，还需要考虑框架、显卡的支持情况，比如有些框架可能不支持 W4A16 的推理，那即便转换好了也用不了。

根据实践经验，一般情况下：

• 精度越高，显存占用越多，推理效率越低，但一般效果较好。
• Server 端推理一般用非量化版本或半精度、BF16、Int8 等精度的量化版本，比较少使用更低精度的量化版本。
• 端侧推理一般都使用量化版本，且大多是低精度的量化版本。这主要是因为计算资源所限。

以上是针对项目开发情况，如果是自己尝试（玩儿）的话：

• 如果资源足够（有GPU卡很重要），那就用非量化的正常版本。
• 如果没有 GPU 卡，只有 CPU（不管什么芯片），那还是尝试量化版本。
• 如果生成文本长度很长，显存不够，就开启 KV Cache

建议大家根据实际情况灵活选择方案。

---

基础作业

• 网页Demo——TurboMind 推理作为后端

• 网页Demo——TurboMind 服务作为后端