lmdeploy量化部署_lmdeploy支持w4a8吗

大模型部署

模型部署概念

定义

• 将训练好的模型在特定软硬件环境中启动的过程，使模型能够接收输入并返回预测结果
• 为了满足性能和效率的需求，常常需要对模型进行优化，例如模型压缩和硬件加速

形态和设备

• 产品形态
  云端、边缘计算端、移动端
• 计算设备
  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
• 其他

移动端

• llama.cpp
• mlc-llm
• 其他

• LMDeploy介绍

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：因为这些参数少，而且非常重要

大模型的参数量化包括两类：

1. 仅量化模型参数，代表为W4A16（AWQ）
2. 同时量化模型参数和激活值，代表为W8A8（SmoothQuant）

推理评估指标为：吞吐量（Throughput）和延迟（Latency）。对于W4A16和W8A8，可以根据业务场景的实际需求分别选用：

1. 高吞吐 + 一般延迟：采用W8A8
2. 低延迟 + 一般吞吐：采用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
1
2
3

上面两行命令分别展示了如何直接加载 Huggingface 的模型，第一条命令是加载使用 lmdeploy 量化的版本，第二条命令是加载其他 LLM 模型。

直接启动本地的 Huggingface 模型，如下所示。

lmdeploy chat turbomind /root/model/Singa_Model/internlm-chat-7b  --model-name internlm-chat-7b
1

以上命令都会启动一个本地对话界面，通过 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
1
2
3
4

执行完成后将会在当前目录生成一个 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
1
2

显存占用

![请添加图片描述](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 并行数
1
2
3
4
5
6

上面的参数中 server_name 和 server_port 分别表示服务地址和端口，tp 参数我们之前已经提到过了，表示 Tensor 并行。还剩下一个 instance_num 参数，表示实例数，可以理解成 Batch 的大小

然后，我们可以新开一个窗口，执行下面的 Client 命令。如果使用官方机器，可以打开 vscode 的 Terminal，执行下面的命令。

# ChatApiClient+ApiServer（注意是http协议，需要加http）
lmdeploy serve api_client http://localhost:23333
1
2

查看接口：

​ 当然，刚刚我们启动的是 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
1
2
3
4
5

TurboMind 推理作为后端

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

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

可以直接启动 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推理