哇塞,这节课1h30min,有得学了!
本节课主题是LMDeploy大模型量化部署,本笔记记录了理论部分。
大模型部署背景
回顾大模型特点:
内存开销巨大
- 庞大的参数量。 7B 模型仅权重就需要 14+G 内存
- 采用自回归生成 token,需要缓存 Attention 的 k/v,带来巨大的内存开销
动态shape
- 请求数不固定
- Token 逐个生成,且数量不定
相对视觉模型,LLM结构简单
Transformers 结构,大部分是 decoder-only
模型部署是什么?
定义:
- 将训练好的模型在特定软硬件环境中启动的过程,使模型能够接收输入并返回预测结果
- 为了满足性能和效率的需求,常常需要对模型进行优化,例如模型压缩和硬件加速
产品形态:
云端、边缘计算端、移动端
面临问题:
设备
- 如何应对巨大的存储问题? 低存储设备 (消费级显卡、手机等)如何部署?
推理
- 如何加速 token 的生成速度如何解决动态shape,让推理可以不间断如何有效管理和利用内存
服务
- 如何提升系统整体吞吐量?对于个体用户,如何降低响应时间?
现如今采用的大模型部署方案:
LMDeploy介绍
LMDeploy 是 LLM 在英伟达设备上部署的全流程解决方案。包括模型轻量化、推理和服务。
turbomind推理引擎室mmdeploy的创新点,是重点。(这部分的底层引擎是c++,但是mmdeploy封装是python,使用起来是用python)
opencompass是一个评测repo。
核心功能(主要理念在这部分):
量化
两个基本概念
- 计算密集 (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。
量化方法的对应论文:MIT HAN LAB最新的的AWQ算法,GPTQ算法