第五课-LMDeploy 大模型量化部署实践_大模型部署

一、大模型部署背景

1、定义

大模型部署就是将训练好的模型在特定软硬件环境中启动的过程，使模型能够接收输入并返回预测结果。为了满足性能和效率的需求，常常需要对模型进行优化，例如模型压缩和硬件加速。
产品形态：云端、边缘计算端、移动端。
计算设备：CPU、GPU、NPU、TPU 等。

2、大模型特点

内存开销巨大：庞大的参数量。 7B 模型仅权重就需要 14+G 内存；采用自回归生成 token，需要缓存 Attention 的 k/v，带来巨大的内存开销。
动态shape：请求数不固定；Token 逐个生成，且数量不定。
相对视觉模型，LLM结构简单：Transformers 结构，大部分是 decoder-only.

3、大模型部署挑战

设备：如何应对巨大的存储问题？低存储设备（消费级显卡、手机等）如何部署？
推理：如何加速 token 的生成速度；如何解决动态shape，让推理可以不间断；如何有效管理和利用内存。
服务：如何提升系统整体吞吐量？对于个体用户，如何降低响应时间？

4、大模型部署方案

技术点：模型并行；低比特量化；Page Attention；transformer 计算和访存优化；Continuous Batch等
方案：huggingface transformers；专门的推理加速框架；

1. 云端：lmdeploy；vllm；tensorrt-llm；deepspeed；
2. 移动端：llama.cpp；mlc-llm；

二、LMDeploy

1、简介

LMDeploy 由 MMDeploy 和 MMRazor 团队联合开发，是涵盖了 LLM 任务的全套轻量化、部署和服务解决方案。 这个强大的工具箱提供以下核心功能1 ：

高效推理引擎 TurboMind：基于 FasterTransformer，我们实现了高效推理引擎 TurboMind，支持 InternLM、LLaMA、vicuna等模型在 NVIDIA GPU 上的推理。
**交互推理方式：**通过缓存多轮对话过程中 attention 的 k/v，记住对话历史，从而避免重复处理历史会话。
多 GPU 部署和量化：我们提供了全面的模型部署和量化支持，已在不同规模上完成验证。
persistent batch 推理：进一步优化模型执行效率。

GitHub地址：
https://github.com/InternLM/lmdeploy

2、核心功能1-量化

为什么做 Weight Only 的量化？
两个基本概念：
计算密集（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。

Weight Only 量化一举多得
4bit Weight Only 量化，将 FP16 的模型权重量化为 INT4，访存量直接降为 FP16 模型的 1/4，大幅降低了访存成本，提高了 Decoding 的速度。
加速的同时还节省了显存，同样的设备能够支持更大的模型以及更长的对话长度。

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

3、核心功能2- 推理引擎 TurboMind

特点：
持续批处理：请求可以及时加入batch中推理，Batch中已经完成推的请求及时退出。
有状态的推理 ：对话 token 被缓存在推理侧，用户侧请求无需带上历史对话记录。
高性能 cuda kernel：Flash Attention 2；Split-K decoding；高效的w4a16, kv8 反量化 kernel。
Blocked k/v cache：Attention 支持不连续的 k/v block (Paged Attention）；

三、最佳实践

“模型推理/服务”：推荐使用TurboMind
后面的 API 服务和 Client 就得分场景了。

1. 我想对外提供类似 OpenAI 那样的 HTTP 接口服务。推荐使用 TurboMind推理 + API 服务。
2. 我想做一个演示 Demo，Gradio 无疑是比 Local Chat 更友好的。推荐使用 TurboMind
   推理作为后端的Gradio进行演示。
3. 我想直接在自己的 Python 项目中使用大模型功能。推荐使用 TurboMind推理 +Python。
4. 我想在自己的其他非 Python 项目中使用大模型功能。推荐直接通过 HTTP 接口调用服务。也就是用本列表第一条先启动一个 HTTP API 服务，然后在项目中直接调用接口。

常见的 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 权重反量化）
最佳实践流程图：

实战、实战

实战教程：
https://github.com/InternLM/tutorial/tree/main/lmdeploy
视频教程：
https://www.bilibili.com/video/BV1iW4y1A77P/