探秘Transformer系列之（24）--- KV Cache优化

探秘Transformer系列之（24）--- KV Cache优化


目录

• 探秘Transformer系列之（24）--- KV Cache优化
  
  
  
  • 0x00 前言
    
  • 0x01 背景知识
    
    
    
    • 1.1 度量指标
      
      
      
      • 1.1.1 吞吐量
        
      • 1.1.2 延迟
        
      
      
    • 1.2 内存危机
      
    • 1.3 KV Cache问题
      
    
    
  • 0x02 总体思路
    
    
    
    • 2.1 分类
      
    • 2.2 从公式角度优化
      
      
      
      • 2.2.1 难以利用的选项
        
        
        
        • 减少模型层数
          
        • 减少batch size
          
        
        
      • 2.2.2 LLM推理加速的优化方向
        
      
      
    • 2.2 按照特性进行优化
      
      
      
      • 2.2.1 prefill
        
      • 2.2.2 Decoding
        
      • 2.2.3 分离与否
        
      • 2.2.4 内存管理
        
      • 2.2.5 调度
        
      
      
    • 2.3 按照阶段来优化
      
    
    
  • 0x03 按照公式优化
    
    
    
    • 3.1 减少注意力头的数量
      
    • 3.2 减少每个参数占用的字节
      
    • 3.3 减少注意力头维度
      
      
      
      • 3.2.1 Double Sparsity
        
        
        
        • 洞见
          
        • 方案
          
        
        
      
      
    • 3.4 减少Layers
      
      
      
      • 3.4.1 总体思路
        
      • 3.4.2 LayerSkip
        
        
        
        • 动机
          
        • 方案
          
        
        
      • 3.4.3 YOCO
        
        
        
        • 模型架构
          
        • 训练和推理
          
        • 效果
          
        
        
      • 3.4.4 CLA
        
      • 3.4.5 MLKV
        
      
      
    • 3.5 减少序列长度
      
    
    
  • 0x04 按照特性进行优化
    
    
    
    • 4.1 针对Prefill特性进行优化
      
      
      
      • 4.1.1 Chunking
        
      • 4.1.2 KV-Runahead
        
        
        
        • 动机
          
        • 方案
          
        
        
      
      
    • 4.2 内存管理优化
      
      
      
      • 4.2.1 问题
        
      • 4.2.2 Paged Attention
        
        
        
        • 实现
          
        • 架构
          
        • KV Cache管理器
          
        • 基本场景的解码算力
          
        • 劣势
          
        
        
      • 4.2.3 vAttention
        
        
        
        • 洞察
          
        • 设计概述
          
        
        
      
      
    • 4.3 调度
      
      
      
      • 4.3.1 Prefix-aware Scheduling
        
      • 4.3.2 Preemptive and Fairness-oriented scheduling
        
      • 4.3.3 Layer-specific and Hierarchical Scheduling
        
      
      
    
    
  • 0xFF 参考
    
  
  

0x00 前言

目前的大型语言模型（LLM）服务系统采用KV Cache来避免在解码阶段重复计算键和值的投影。虽然这对于单个客户端请求生成短序列而言是一个有效的解决方案，但是，面对多个客户时，每个请求都保留自己的KV缓存，从而增加了推理过程中的总体KV缓存大小。另外，即使是针对单个客户端请求，当我们生成长序列或处理多轮对话时，KV Cache 依然会对推理性能造成极大的影响。比如，束搜索和平行采样也被广泛用于生成更好的输出或为客户提供候选选择。这些技术也会像批处理推理一样增加KV缓存的大小，因为它们会同时处理多个序列。
KV Cache问题的核心在于，KV Cache 占用了大量内存和访存带宽，同时在生成阶段引入了大量重复计算。从而阻止了我们处理或生成非常长的序列和处理大批量数据，无法最大化硬件效率。这就好比一个图书馆管理员每天忙于检索每本书的信息，却没有时间去为用户去拿书。而总体趋势上，LLM 的窗口长度也在不断增大，因此就出现一组主要矛盾，即：对不断增长的 LLM 的窗口长度的需要与有限的 GPU 显存之间的矛盾。
因此优化 KV cache 就显得非常必要，KV Cache 压缩技术也成为了 LLM 推理领域的热门研究方向。本文会带领大家深入剖析KV Cache的各项特性，并详细阐述了当前用于优化LLMs中KV Cache空间使用的各种方法，阐明了它们之间的相互关系，并比较它们的核心思想。
注意：因为KV Cache优化的内容太多，因为我们将分为三篇文章来仔细学习。
注：全部文章列表在这里，估计最终在35篇左右，后续每发一篇文章，会修改此文章列表。
cnblogs 探秘Transformer系列之文章列表
0x01 背景知识

1.1 度量指标

推理加速一般可以从两个层面体现：吞吐量与延迟。这两个层面的指标参见下图。

生成式LLM可以用于各种具有不同SLO（ Service Level Objective/服务级别目标）的任务。对于批处理任务（例如摘要），TTFT或TBT延迟指标不如吞吐量重要。另一方面，对于对延迟敏感的任务（例如对话API），TTFT和TBT是更重要的指标，其SLO更严格。
1.1.1 吞吐量

吞吐量 (Throughput)  是从系统的角度来看的指标，或者说是 LLM 服务的成本指标，表示每生成一个 token 服务商需要支付的算力成本。吞吐量有多种评估方式，比如 tokens per second（tps），即推理服务器单位时间内能处理针对所有用户和请求生成的输出token数。如果不仅考虑预填和解码，还考虑内存限制和上下文切换，则可以考虑基于会话的吞吐量，即在给定时间内的并发用户交互数量，是一个端到端的目标。

\[\begin{align}    \texttt{throughput} = \frac{\texttt{number of user interaction sessions}}{\texttt{time}}\notag\end{align} \]
吞吐量衡量的是所有用户和请求中完成的请求或词元的数量，因此忽略了时延要求。有研究人员引入了有效吞吐量（goodput），即每秒完成请求的遵守 SLO（TTFT 和 TPOT 要求）的数量。因为有效吞吐量捕获了在 SLO 达成下的请求吞吐量 —— 因此既考虑了成本又考虑了服务质量。
1.1.2 延迟

模型为用户生成完整响应所需的总时间可以使用这两个指标来计算：TTFT和TPOT。
首次token生成时间（Time To First Token，简称TTFT）

TTFT是在用户输入查询的内容后，模型生成第一个输出token所需要的时间。在人机实时交互的过程中，让用户得到快速的响应至关重要，返回结果越快，用户体验越好。但对于离线工作负载则不太重要。在实践中，我们一般会人为设置一个TTFT SLO（Service Level Objective）。举例来说，假设我们定P90 TTFT SLO = 0.4s，那么这意味着我们对该系统的要求是：“90%的request的TTFT值都必须