笔记--LMDeploy 的量化和部署

LMDeploy 的量化和部署

大模型部署背景

模型部署：需要优化加速，产品多样，计算设备多样。

大模型特点：内存开销大要14G+, 请求数不固定，token数不固定，

目前挑战：大内存开销—计算和访存优化

请求数不固定，token数不固定，加速推理—huggingface transformers 专门的推理加速框架

LMDeploy简介:高效性，完备易用性，交互式

推理性能：

静态推理性能 —固定batch,输入/输出token数量

动态推理性能–真实对话，不定长的输入/输出

可以看到LMDeploy 在静态推理和动态推理性能上都有非常大的提升

量化是一种以参数或计算中间结果精度下降换空间节省（以及同时带来的性能提升）的策略。

KV Cache 量化是指将逐 Token（Decoding）生成过程中的上下文 K 和 V 中间结果进行 INT8 量化（计算时再反量化），以降低生成过程中的显存占用。

4bit Weight Only量化，将 FP16 的模型权重量化为 INT4，Kernel 计算时，访存量直接降为 FP16 模型的 1/4，大幅降低了访存成本。Weight Only 是指仅量化权重，数值计算依然采用 FP16（需要将 INT4 权重反量化）

推理引擎TurboMind


推理服务api server

服务部署

从架构上把整个服务流程分成下面几个模块。

• 模型推理/服务。主要提供模型本身的推理，一般来说可以和具体业务解耦，专注模型推理本身性能的优化。可以以模块、API等多种方式提供。
• Client。可以理解为前端，与用户交互的地方。
• API Server。一般作为前端的后端，提供与产品和服务相关的数据和功能支持。

值得说明的是，以上的划分是一个相对完整的模型，但在实际中这并不是绝对的。比如可以把“模型推理”和“API Server”合并，有的甚至是三个流程打包在一起提供服务。

在线转换

利用lmdeploy直接启动本地的 Huggingface 模型

也可以从网上直接读取 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

离线转换

lmdeploy 在用户根目录将本地internlm-chat-7b 模型转为lmdeploy TurboMind 的格式

离线模型转换完成后，使用lmdeploy 可以启动TurboMind执行模型推理：

TurboMind推理+API服务

TurboMind 推理作为后端

Gradio 直接和 TurboMind 连接

TurboMind 推理 + Python 代码集成

创建相关Python 脚本

TurboMind 对模型推理/服务的提升

python infer_compare.py hf

python infer_compare.py lmdeploy

可以看到分别使用huggingface Transformers库消耗时间为32.89秒 平均36字/秒，LMDeploy 消耗时间7.24秒 平均156字/秒 LMDeploy应该是Transformers的4.54倍左右。

总结来讲：

• 我想对外提供类似 OpenAI 那样的 HTTP 接口服务。推荐使用 TurboMind推理 + API 服务。

• 我想做一个演示 Demo，Gradio 无疑是比 Local Chat 更友好的。推荐使用 TurboMind 推理作为后端的Gradio进行演示。

• 我想直接在自己的 Python 项目中使用大模型功能。推荐使用 TurboMind推理 + Python。

• 我想在自己的其他非 Python 项目中使用大模型功能。推荐直接通过 HTTP 接口调用服务。也就是用本列表第一条先启动一个 HTTP API 服务，然后在项目中直接调用接口。

模型配置实践

• 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 参数。
  • 该参数值越大，吞度量越大（同时接受的请求数），但也会占用更多显存。
  • 建议根据请求量和最大的上下文长度，按实际情况调整。

模型量化

KV Cache 量化

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

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

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

第二步：通过 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。

lmdeploy lite kv_qparams \
  --work_dir ./quant_output  \
  --turbomind_dir workspace/triton_models/weights/ \
  --kv_sym False \
  --num_tp 1

量化参数计算如下：

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

现在即用上了 KV Cache 量化，能更省（运行时）显存了。

W4A16 量化

第一步：同 KV Cache 量化第一步，不再赘述。

第二步的执行命令如下：

lmdeploy lite auto_awq \
  --model  /root/share/temp/model_repos/internlm-chat-7b/ \
  --w_bits 4 \
  --w_group_size 128 \
  --work_dir ./quant_output 

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

同样更改quant_policy 为4 以正常使用量化

值得注意的是W4A16量化模型和 KV Cache 量化也可以一起使用，以达到最大限度节省显存

TritonServer 作为推理引擎

通过 Docker 安装后，使用TritonServer推理+API服务，并作为后端

其实效果与TurboMind推理+API服务 类似。