目录
作业
- 使用 LMDeploy 以本地对话、网页Gradio、API服务中的一种方式部署 InternLM-Chat-7B 模型，生成 300 字的小故事（需截图）
本地对话
API 服务
网页 Gradio
笔记
模型部署
- 定义
- 将训练好的模型在特定软硬件环境中启动的过程，使模型能够接收输入并返回预测结果
- 为了满足性能和效率的需求，常常需要对模型进行优化，例如模型压缩和硬件加速
- 产品形态
- 云端、边缘计算端、移动端
- 计算设备
- CPU、GPU、NPU、TPU 等
大模型特点
- 内存开销巨大
- 庞大的参数量。7B 模型仅权重就需要 14+G 内存（70亿参数，fp16半精度，即 2 字节存储，计算得出 14G）
- 采用自回归生成 token（token by token），需要缓存 Attention 的 k/v，带来巨大的内存开销
- 动态 shape
- 请求数不固定，batch size 不固定
- Token 逐个生成，且数量不定
- 相对视觉模型，LLM 结构简单
- Transformer 结构，大部分是 decoder-only
- 生成的过程其实就是采样
大模型部署挑战
- 设备
如何应对巨大的存储问题？低存储设备（消费级显卡、手机等）如何部署
- 推理
- 如何加速 token 的生成速度
- 如何解决动态 shape，让推理可以不间断
- 如何有效管理和利用内存
- 服务
- 如何提升系统整体吞吐量？
- 对于个体用户，如何降低响应时间？
大模型部署方案
- 技术点
模型并行、低比特量化、Page Attention、transformer 计算和访存优化、Continuous Batch...
- 方案
- huggingface transformers
- 专门的推理加速框架
- 云端
lmdeploy、vllm、tensorrt-llm、deepspeed...
- 移动端
llama.cpp、mlc-llm
LMDeploy 介绍
LMDeploy是 LLM 在 Nvidia 设备上部署的全流程解决方案。包括轻量化、推理和服务。
- 核心功能：
- 量化，Weight 和 KV Cache
- 推理引擎
- 服务
- 量化
- 基本概念
- 计算密集（compute-bound）
推理的绝大部分时间消耗在数值计算上；
针对计算密集场景，可以通过更快的硬件计算单元来提升计算速度，比如量化为 W8A8 使用 INT8 Tensor Core 来加速计算。
- 访存密集（memory-bound）
推力时，绝大部分时间消耗在数据读取上；
针对访存密集型场景，一般是通过提高计算访存比来提升性能。
- LLM 是典型的访存密集型任务
常见的 LLM 模型是 Decode Only 架构。推理时大部分时间消耗在逐 Token 生成阶段（Decoding 阶段），是典型的访存密集型场景。
- Weight Only 量化的作用—一举多得
- 4 bit Weight Only 量化，将 FP16 的模型权重量化为 INT4, 访存量直接降为 FP16 模型的 1/4，大幅降低了访存成本，提高了 Decoding 的速度。
- 加速的同时还节省了显存，同样的设备能够支持更大的模型及更长的对话长度
- 如何实现 Weight Only 量化 —— AWQ 算法
- LMDeploy 使用 MIT HAN LAB 开源的 AWQ 算法，量化为 4bit 模型
- 推理时，先把 4bit 权重反量化回 FP16（在 Kernel 内部进行，从 Global Memory 读取时仍是 4bit），依旧使用的是 FP16 计算
- AWQ 的推理速度和量化时间均由于 GPTQ 算法
KV Cache 量化的影响
量化后的模型，精度不仅没有明显下降，相反在不少任务上还有一定的提升。
可能得原因是，量化会导致一定的误差，有时候这种误差可能会减少模型对训练数据的拟合，从而提高泛化性能。
量化可以被视为引入轻微噪声的正则化方法；
或者，也有可能量化后的模型正好对某些数据集具有更好的性能。
总结一下，KV Cache 量化既能明显降低显存占用，还有可能同时带来精准度（Accuracy）的提升。
W4A16 量化
W4A16中的A是指Activation，保持FP16，只对参数进行 4bit 量化。
量化模型和 KV Cache 量化也可以一起使用，以达到最大限度节省显存。
4bit 模型可以降低 50-60% 的显存占用，效果非常明显。
总而言之，W4A16 参数量化后能极大地降低显存，同时相比其他框架推理速度具有明显优势。
量化的最佳实践
服务部署和量化是没有直接关联的，量化的最主要目的是降低显存占用：主要包括两方面的显存：模型参数和中间过程计算结果。前者对应 W4A16 量化，后者对应 KV Cache 量化。
量化在降低显存的同时，一般还能带来性能的提升，因为更小精度的浮点数要比高精度的浮点数计算效率高，而整型要比浮点数高很多。
所以最佳实践是：在各种配置下尝试，看效果能否满足需要。这一般需要在自己的数据集上进行测试。具体步骤如下：
- Step1：优先尝试正常（非量化）版本，评估效果。
如果效果不行，需要尝试更大参数模型或者微调。
如果效果可以，跳到下一步。
- Step2：尝试正常版本+KV Cache 量化，评估效果。
如果效果不行，回到上一步。
如果效果可以，跳到下一步。
- Step3：尝试量化版本，评估效果。
如果效果不行，回到上一步。
如果效果可以，跳到下一步。
- Step4：尝试量化版本+ KV Cache 量化，评估效果。
如果效果不行，回到上一步。
如果效果可以，使用方案。
除了上述流程外，还需要考虑框架、显卡的支持情况。
- 量化经验，生产情况下：
- 精度越高，显存占用越多，推理效率越低，但一般效果较好。
- Server 端推理一般用非量化版本或半精度、BF16、Int8 等精度的量化版本，比较少使用更低精度的量化版本。
- 端侧推理一般都使用量化版本，且大多是低精度的量化版本。这主要是因为计算资源所限。
自己探索的情况下：
- 如果资源足够（有GPU卡很重要），那就用非量化的正常版本。
- 如果没有 GPU 卡，只有 CPU（不管什么芯片），那还是尝试量化版本。
- 如果生成文本长度很长，显存不够，就开启 KV Cache。
推理引擎 — TurboMind
- 持续批处理
请求可以即使加入 batch 中推理；
Batch 中已经完成推理的请求即使退出
- 有状态的推理
对话 token 被缓存在推理侧；
用户侧请求无需带上历史对话记录
- Blocded k/v cache
Attention 支持不连续的 k/v；
block（Paged Attention）
- 高性能 cuda kernel
Flash Attention 2
Split-K decoding
高效的 w4a16, kv8 反量化 kernel
推理服务
- 一行命令启动 api server：
lmdeploy serve api_server InternLM/internlm-chat-7b --model-name internlm-chat-7b --server-port 8080
- 可以使用 swagger ui 查看并体验 api server 的 RESTful 接口
模型转换
使用 TurboMind 推理模型需要先将模型转化为 TurboMind 的格式，目前支持在线转换和离线转换两种形式。
在线转换可以直接加载 Huggingface 模型，离线转换需需要先保存模型再加载。
TurboMind 是一款关于 LLM 推理的高效推理引擎，基于英伟达的 FasterTransformer 研发而成。它的主要功能包括：LLaMa 结构模型的支持，persistent batch 推理模式和可扩展的 KV 缓存管理器。
- TurboMind 推理+命令行本地对话
模型转换完成后，我们就具备了使用模型推理的条件，接下来就可以进行真正的模型推理环节。
我们先尝试本地对话（Bash Local Chat），下面用（Local Chat 表示）在这里其实是跳过 API Server 直接调用 TurboMind。简单来说，就是命令行代码直接执行 TurboMind。所以说，实际和前面的架构图是有区别的。
这里支持多种方式运行，比如 Turbomind、PyTorch、DeepSpeed。但 PyTorch 和 DeepSpeed 调用的其实都是 Huggingface 的 Transformers 包，PyTorch表示原生的 Transformer 包，DeepSpeed 表示使用了 DeepSpeed 作为推理框架。Pytorch/DeepSpeed 目前功能都比较弱，不具备生产能力，不推荐使用。
部署场景
- 我想对外提供类似 OpenAI 那样的 HTTP 接口服务。推荐使用 TurboMind推理 + API 服务。
- 我想做一个演示 Demo，Gradio 无疑是比 Local Chat 更友好的。推荐使用 TurboMind 推理作为后端的Gradio进行演示。
- 我想直接在自己的 Python 项目中使用大模型功能。推荐使用 TurboMind推理 + Python。
- 我想在自己的其他非 Python 项目中使用大模型功能。推荐直接通过 HTTP 接口调用服务。也就是用本列表第一条先启动一个 HTTP API 服务，然后在项目中直接调用接口。
1666
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
