大模型实战营Day5 LMDeploy 大模型量化部署实践

大模型部署背景

大模型特点

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

模型部署

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

大模型部署挑战

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

大模型部署方案

• 技术点
  模型并行
  transformer计算和访存优化
  低比特量化
  Continuous Batch
  Page Attention

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

LMDeploy

LMDeploy是LLM在英伟达设备上部署的全流程解决方案。包括模型轻量化、推理和服务。

推理性能

核心功能一量化

为什么要做量化？

为什么做Veight 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量化一举多得
4 bit Weight Only量化，将FP16的模型权重量化为NT4,访存量直接降为FP16模型的1/4，大幅降低了访存成本，提高了Decoding的速度。
加速的同时还节省了显存，同样的设备能够支持更大的模型以及更长的对话长度


核心功能-推理引擎TurboMind

• 持续批处理
  请求可以及时加入batch中推理
  Batch中已经完成推的请求及时退出
  

• 有状态的推理
  对话token被缓存在推理侧
  用户侧请求无需带上历史对话记录

• Blocked k/v cache
  Attention支持不连续的kW
  block(Paged Attention)
  

• 高性能cuda kernel
  Flash Attention 2
  Split-K decoding
  高效的w4a16,kv8反量化kernel
  

核心功能-推理服务api server

相关链接

课程链接：LMDeploy 大模型量化部署实践
课程文档github