书生大模型笔记5

哇塞，这节课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。

推理性能超越vLLM

 

 核心功能（主要理念在这部分）：

量化

两个基本概念

• 计算密集 (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算法 

推理引擎turbomid        

四大特性

推理服务 api server