书生·浦语大模型实战营笔记 05_我们先尝试本地对话(bash local chat),下面用(local chat 表示)在这里其实

LMDeploy 大模型量化部署实践

文档

---

目录

作业

本地对话

API 服务

​编辑

网页 Gradio

笔记

模型部署

大模型特点

大模型部署挑战

大模型部署方案

LMDeploy 介绍

KV Cache 量化的影响

W4A16 量化

量化的最佳实践

推理引擎 — TurboMind

推理服务

模型转换

部署场景

---

作业

• 使用 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 服务，然后在项目中直接调用接口。