LMDeploy 量化部署 LLM&VLM 实践

内容来自于：LMDeploy 量化部署 LLM-VLM 实践_哔哩哔哩_bilibili

本文章用于个人学习记录，详情请关注上方链接。

一、大模型部署背景

1.1定义

在软件工程中，部署通常指的是将开发完毕的软件投入使用的过程。

在人工智能领域，模型部署是实现深度学习算法落地应用的关键步骤。

简单来说，模型部署就是将训练好的深度学习模型在特定环境中运行的过程。

1.2场景

服务器端：CPU部署，单GPU/TPU/NPU部署，多卡/集群部署
移动端/边緣端：移动机器人，手机

（需要考虑具体部署环境、算力资源等参考因素）

1.3大模型部署面临的挑战

1.3.1计算量巨大

（1）大模型参数量巨大，前向推理时需要进行大量计算

（2）根据InternLM2技术报告提供的模型参数数据，以及OpenAI团队提供的计算量估算方法，               20B模型每生成1个token，就要进行约406亿次浮点运算；照此计算，若生成128个 token，           就要进行5.2万亿次运算

（3）20B算是大模型里的“小”模型了，若模型参数规模达到175B （GPT-3），Batch-Size                     （BS）再大一点，每次推理计算量将达到干万亿量级。

（4）以NVIDIA A100为例，单张理论FP16运算性能为每秒77.97 TFLOPsB（77万亿），性能捉             紧。

1.3.2内存开销巨大

（1）以FP16为例，20B模型仅加载参数就需40G+显存，175B模型（如GPT-3）更是需要                       350G+显存。

（2）大模型在推理过程中，为避免重复计算，会将计算注意力（Attention）得到的KV进行缓存。           根据InternLM2技术报告提供的模型参数数据，以及KV Cache空间估算方法，以FP16为                 例，在batch-size为16、输入512 tokens.输出32 tokens的情境下，仅20B模型就会产生                   10.3GB的缓存。

（3）目前，以NVIDIA RTX 4060消费级显卡为例（参考零售价¥2399B），单卡显存仅有                       8GB:NVIDIA A100单卡显存仅有80GB。

1.3.3访问瓶颈

大模型理是“访存密集”型任务。目前硬件计算速度“远快于”显存带宽，存在严重的访存性能瓶颈。

以RTX 4090推理175B大模型为例，BS为1时计算量为6.83TFLOPS，远低于82.58 TFLOPs的FP16计算能力：但访存量为32.62 TB，是显存带宽每秒处理能力的30倍。

1.3.4动态请求

请求量不确定；请求时间不确定；Token逐个生成，生成数量不确定。

二、大模型部署方法

2.1模型剪枝（Pruning）

剪枝指移除模型中不必要或多余的组件，比如参数，以使模型更加高效。通过对模型中贡献有限的冗余参数进行剪枝，在保证性能最低下降的同时，可以减小存储需求、提高计算效率。

（1）非结构化剪枝 SparseGPTI，LoRAPrune ，Wanda
指移除个别参数，而不考虑整体网络结构。这种方法通过将低于阈值的参数置零的方式对个别权重或神经元进行处理。
（2）结构化剪枝    LLM-Pruner   
根据预定义规则移除连接或分层结构，同时保持整体网络结构。这种方法一次性地针对整组权重，优势在于降低模型复杂性和内存使用，同时保持整体的LLM结构完整。

2.2知识蒸馏（Knowledge Distillation，KD）

知识蒸馏是一种经典的模型压缩方法，核心思想是通过引导轻量化的学生模型“模仿”性能更好、结构更复杂的教师模型，在不改变学生模型结构的情况下提高其性能。

（老师教学生，小模型学习大模型的思维方式，有点像迁移学习）

上下文学习（ICL）：ICL  distillation

思维链（CoT）:MT-COT, Fine-tune-CoT等

指令跟随（IF）：LaMini-LM

2.3量化（Quantization）

量化技术将传统的表示方法中的浮点数转换为整数或其他离散形式，以减轻深度学习模型的存储和计算负担。

量化感知训练（QAT）LLM-QAT

量化目标无缝地集成到模型的训练过程中。这种方法使得LLM在训练过程中适应低精度表示。

量化感知微调（QAF）PEQA, QLORA

QAF涉及在微调过程中对LLM进行量化。主要目标是确保经过微调的LLM在量化较为低位宽后仍能保持性能。

训练后量化（PTQ）LLM.int8， AWQ

在LLM的训练阶段完成后对齐其参数进行量化。PTQ的主要目标是减少LLM的存储和计算复杂性，而无需对LLM架构进行修改或进行重新训练。

三、LMDeploy简介

LMDeploy 由 MMDeploy和MMRazor 团队联合开发，是涵盖了 LLM 任务的全套轻量化、部署和服务解决方案。核心功能包括高效推理、可靠量化、便捷服务和有状态推理。

高效的推理：MDeploy开发了Continuous Batch,Blocked K/V Cache，动态拆分和融合，张量并行，高效的计算kernel等重要特性。InternLM2推理性能是vLLM的1.8倍。

可靠的量化：LMDeploy支持权重量化和k/v量化。4bit模型推理效率是FP16下的2.4倍。量化模型的可靠性已通过 OpenCompass评测得到充分验证。

便携的服务：通过请求分发服务，LMDeploy 支持多模型在多机、多卡上的推理服务。

有状态的推理：通过缓存多轮对话过程中Attention的k/v，记住对话历史，从而避免重复处理历史会话。显著提升长文本多轮对话场景中的效率。

3.1LMDeploy核心功能

3.1.1模型高效推理

参考命令：

lmdeploy chat -h

TurboMind是LMDeploy团队开发的一款关于LLM推理的高效推理引擎。它的主要功能包括：LLaMa结构模型的支持，continuous batch推理模式和可拓展的KV缓存管理器。

3.1.2模型量化压缩

参考命令：

lmdeploy lite -h

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

3.1.3服务化部署

参考命令：

lmdeploy serve -h

将LLM封装为HTTP API服务，支持Triton拓展。

在生产环境下，我们有时会将大模型封装为API接口服务，供客户端访问。

我们来看下面一张架构图：

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

• 模型推理/服务。主要提供模型本身的推理，一般来说可以和具体业务解耦，专注模型推理本身性能的优化。可以以模块、API等多种方式提供。
• API Server。中间协议层，把后端推理/服务通过HTTP，gRPC或其他形式的接口，供前端调用。
• Client。可以理解为前端，与用户交互的地方。通过通过网页端/命令行去调用API接口，获取模型推理/服务。

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

3.2LMDeploy性能表现

3.3LMDeploy推理视觉多模态大模型

新版本的lmdeploy支持了对多模态大模型llava的支持！可以使用pipeline便捷运行。

3.4LMDeploy更多支持模型

四、动手实践环节

实践课程文档：https://github.com/InternLM/Tutorial/blob/camp2/lmdeploy/README.md

作业地址：