rag系列文章目录

---

前言

目前各个行业都在接入大模型，借助大模型的能力优化自己的业务。但是有一个问题，一直是需要面对的，就是速度，目前而言，大模型的首token速度仍是很慢，获取输出之前，需要等待几秒。这对实时性要求很高的系统而言，是难以接受的。

一般而言，优化推理主要从以下4个方面：
1、模型压缩技术（如量化和剪枝）
2、高效注意力机制
3、硬件加速策略
4、改进算法以提高解码速度
以下针对一些具体的方法进行说明。

一、量化

其核心思想是把模型中参数（权重、激活值）的高精度浮点数（如 FP32、FP16）映射到低精度整数（如 INT8、甚至 INT4），以减少存储和计算成本。
主要方式：

1. 后训练量化（Post-Training Quantization, PTQ）
   o 在模型训练完成后进行，不需要重新训练。
   o 常见方法：权重量化、激活量化。
   o 优点：简单快速。
   o 缺点：精度下降可能较大，特别是对敏感模型。
2. 量化感知训练（Quantization Aware Training, QAT）
   o 在训练过程中引入量化模拟（fake quantization），使模型适应低精度计算。
   o 优点：精度更好。
   o 缺点：需要重新训练，成本较高。

二、模型剪枝

其核心思想是通过删除模型中的冗余参数（如权重、神经元、注意力头），减少模型规模，从而加速推理。
主要方式：

1. 非结构化剪枝（Unstructured Pruning）
   o 按参数重要性（如权重接近 0）删除单个权重。
   o 优点：能达到高稀疏率。
   o 缺点：稀疏模式不规则，硬件难以高效利用，需要专门的稀疏优化库。
2. 结构化剪枝（Structured Pruning）
   o 删除整个通道、卷积核、注意力头等。
   o 优点：剪枝后模型结构规整，容易加速。
   o 缺点：对精度影响更大。

三、蒸馏

其核心思想是让一个大的、性能强的模型（教师模型 Teacher）把知识传递给一个小的、轻量的模型（学生模型 Student），从而得到体积更小、推理更快的模型。
主要做法：

1. 教师模型 先在大规模数据上训练，表现优秀，但可能太大，推理慢。
2. 学生模型 设计得更小、更快。
3. 在训练学生模型时，不仅用真实标签（ground truth）作为监督，还用 教师模型输出的“软标签”（soft label，概率分布）来指导学生。
   这样学生模型能学到：
   • 真实标签的信息（分类正确性）。
   • 教师模型的“暗知识”（类别间的细微差异，概率分布中的信息）。

四、Key-Value (KV) Caching

其核心思想是把历史 token 的 K、V 结果缓存起来，下一个 token 生成时直接复用，而不是重新计算。
• 第 1 步：输入 prompt，计算出所有 K、V，缓存下来。
• 第 2 步：生成第一个新 token，只需计算它的 Q，然后和缓存的 K、V 做 Attention。
• 第 3 步：生成第二个 token → 只计算这个 token 的 Q（+ 新的 K、V），再和缓存拼接。
这样，计算量从 O(t²) 降到 O(t)，极大加速推理。

KV Cache 的优点

1. 推理速度显著提升：避免重复计算历史上下文。
2. 更低的延迟：首 token 仍然较慢，但后续 token 的生成速度提升明显。
3. 高并发更友好：配合 PagedAttention / Continuous Batching 可以管理多个请求的缓存，提高吞吐量。

五、模型并行化

大模型（比如百亿、千亿参数的 LLM）有两个主要问题：

1. 参数太多，单 GPU 显存放不下。
2. 计算量太大，单 GPU 计算太慢。
   于是需要把一个模型拆开，分布在多块 GPU 上并行运行，这就是 模型并行化。

主要方式如下：

1. 张量并行（Tensor Parallelism, TP）
   思路：把单个层（layer）内部的矩阵运算拆开，分给多块 GPU 来做。
   • 例如：
   o Y=XW，其中 W是一个很大的矩阵，可以把它拆成多块（行分块/列分块）。
   o 每个 GPU 计算一部分，再合并结果。
   • 常用于 Attention/QKV 投影矩阵、Feedforward 层。
   优点：计算负载均衡，显存压力分摊。
   缺点：需要频繁通信（AllReduce / AllGather），通信开销大。

2. 流水线并行（Pipeline Parallelism, PP）
   思路：把模型的层切分成几段，不同段放在不同 GPU 上，像生产线一样流水计算。
   • 例如：
   o GPU1 负责前 12 层，GPU2 负责中间 12 层，GPU3 负责后 12 层。
   o 输入先经过 GPU1，再传给 GPU2，再传给 GPU3。
   • 推理时可以 微批次（micro-batch）并行，不同 GPU 同时处理不同 batch 的不同部分。
   优点：显存需求减少，适合深层模型。
   缺点：需要 carefully 调度，不然会出现“流水线气泡”（pipeline bubble，GPU 空闲等待）。

六、注意力机制优化

注意力机制（Attention） 是 Transformer 里计算量和显存占用的“大头”，因此很多推理加速的优化手段，都围绕 Attention 来做改进。

一个常见的注意力机制优化是FlashAttention
• 思路：优化矩阵乘法的计算和内存读写顺序，减少显存 IO。
• 特点：
o 不改变算法本质，只是实现更高效。
o 通过 Tile + 流式计算 + 在线 softmax，避免显存中存储完整 n×n 注意力矩阵。
• 优点：显存占用从 O(n²) 降到 O(n)，速度提升 2-4 倍。
• 现状：几乎是 LLM 框架的 标配（vLLM、Transformers 都支持）。

七、Static KV-Cache and torch.compile

前面介绍了 KV 缓存的概念，而静态 KV 缓存方法则是对这一技术的专门优化。与前面讨论的动态缓存方法不同，静态 KV 缓存预先分配了一个固定大小的缓存，这样就能与 PyTorch 的 torch.compile 功能兼容。这种组合可以显著提高速度，尤其是在前向传递中。

这样做的代价是缓存大小的灵活性降低，但对于像 Llama 这样支持这种方法的模型来说，性能提升是非常可观的。这种静态分配策略与编译相结合，不仅能提高内存效率，还能提高计算速度，使其成为在支持的模型中进行推理优化的强大工具。

此外，如果推理运行之间的实际序列长度变化很大，在未使用全部缓存的情况下可能会浪费一些内存。因此，在决定使用这种技术时，仔细考虑应用程序中的典型序列长度至关重要。

尽管有这些考虑因素，但对于许多应用程序，尤其是涉及交互式文本生成或完成任务的应用程序，静态 KV-cache 和 torch.compile 带来的性能提升可以减少延迟并提高吞吐量，从而显著改善用户体验。

八、推测解码

推测解码（Speculative Decoding） 就是让一个小模型快速生成“草稿 token”，再由大模型并行验证/修正，从而把 LLM 推理的串行过程变得更并行，显著提升速度而不降低精度。

九、Prompt查找解码

大语言模型（LLM）推理时，主要瓶颈在：

1. 自回归生成是串行的 → 每次只能生成一个 token。

2. 很多生成内容其实很常见，模型每次都要重新算，重复劳动。
   例如：
   • 用户输入「Once upon a」 → 模型很可能接「time」。
   • 但每次都要通过大模型完整推理一遍。
   能不能直接“跳过”这些高频常见短语？

   它的思路就是用缓存（Lookup Table）来代替部分推理。
   具体做法：

3. 在训练或服务过程中，维护一个 Prompt → 后续 Token 序列 的数据库（cache/memory）。
   o 类似一个“记忆库”，存储高频的 prompt continuation。
   o 可以是短语级别、n-gram 级别。

4. 当用户输入的 prompt 或生成过程中的前缀 命中数据库：
   o 直接查表，返回一段候选 token，而不是让大模型从零开始生成。

5. 如果没命中，或者查到的 token 不完全合适 → 再回退到大模型继续推理。

十、Model Serving Techniques

即便模型结构已经优化（量化、剪枝等），实际推理速度和成本 还很大程度上依赖于 如何服务化部署。

批处理：这项技术可同时处理多个推理请求，最大限度地提高 GPU 利用率和吞吐量。它根据请求的到达时间对其进行动态分组，确保高效利用计算资源。

推测推理： 这种方法可预测未来的请求并预先计算潜在的响应。通过并行处理多个序列步骤，推测推理可显著缩短响应时间，提升用户体验。

---

总结

上面提到了各种模型推理优化策略，具体到某个场景，需要首先定位到底是 显存限制、计算瓶颈、还是服务层延迟。然后考虑优化策略的顺序，如果模型太大放不下考虑量化 / 剪枝 / 蒸馏，如果生成速度太慢考虑Speculative/FlashAttention，如果吞吐量不足 考虑Batching / Caching / Serving 优化。

推理优化没有“一招鲜”，需要结合业务特点做 trade-off。建议先做 量化 + KV Cache 优化 + Continuous Batching，这是 性价比最高的组合。

参考文档