书生·浦语大模型 笔记+作业 LMDeploy 大模型量化部署实践

课程视频、文档

大模型部署背景

模型部署

定义

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

产品形态

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

计算设备

CPU、GPU、NPU、TPU 等

大模型特点

内存开销巨大

• 庞大的参数量。 7B 模型仅权重就需要 14+G 内存
• 采用自回归生成 token，需要缓存 Attention 的 k/v,带来巨大的内存开销

动态shape

• 请求数不固定
• Token 逐个生成，且数量不定

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

• Transformers 结构，大部分是 decoder-only

大模型部署挑战

设备

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

推理

• 如何加速token的生成速度
• 如何解决动态shape，让推理可以不间断
• 如何有效管理和利用内存

服务

• 如何提升系统整体吞吐量？
• 对于个体用户，如何降低响应时间？

大模型部署方案

技术点

• 模型并行
• transformer计算和访存优化
• 低比特量化
• Continuous Batch
• Page Attention 参考链接 :暂时理解成FlashAttention进一步优化方案
• …

方案

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

云端

• Imdeploy
• vllm
• tensorrt-llm
• deepspeed

移动端

• llama.cpp
• mlc-llm

LMDeploy 简介

项目地址： https://github.com/InternLM/lmdeploy
InternLM 实现在Nvidia设备（服务端）上部署LLM的全流程解决方案

turbomind

量化

为什么做 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 的速度。
• 加速的同时还节省了显存，同样的设备能够支持更大的模型以及更长的对话长度
  

如何做 Weight Only 的量化?

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

TurboMind

推理服务

作业

基础作业

1. 模型转化
   
   协助将模型转化为lmdeploy支持结构
   生成内容结构
   
   基础作业：Happy Ending.
   

进阶作业

首选 获取量化参数
1、主要是统计各个模型的值

2、基于统计的输出进行量化

3. 对于模型weight进行int4 量化

未量化前

显存占用 14910MB

量化后

显存占用5756MB