SCOPE:面向大语言模型长序列生成的双阶段KV缓存优化框架

本文涉及的产品
实时数仓Hologres,5000CU*H 100GB 3个月
实时计算 Flink 版,5000CU*H 3个月
智能开放搜索 OpenSearch行业算法版,1GB 20LCU 1个月
简介: KV缓存是大语言模型(LLM)处理长文本的关键性能瓶颈,现有研究多聚焦于预填充阶段优化,忽视了解码阶段的重要性。本文提出SCOPE框架,通过分离预填充与解码阶段的KV缓存策略,实现高效管理。SCOPE保留预填充阶段的关键信息,并在解码阶段引入滑动窗口等策略,确保重要特征的有效选取。实验表明,SCOPE仅用35%原始内存即可达到接近完整缓存的性能水平,显著提升了长文本生成任务的效率和准确性。

Key-Value (KV)缓存已成为大语言模型(LLM)长文本处理的关键性能瓶颈。当前研究尚未充分关注解码阶段的优化,这一阶段具有同等重要性,因为:

1、对需要完整上下文的场景,预填充阶段的过度压缩会显著降低模型的推理理解能力

2、在长输出推理任务中存在重要特征的显著偏移现象

这篇论文提出SCOPE框架,通过分离预填充与解码阶段的KV缓存优化策略,实现高效的缓存管理。该框架保留预填充阶段的关键KV缓存信息,同时引入基于滑动窗口的新型策略,用于解码阶段重要特征的高效选取。

关键发现

KV缓存的推理过程分析

LLM的每次请求包含两个独立阶段:预填充阶段处理完整输入提示以生成初始输出标记;解码阶段通过迭代方式逐个生成后续输出标记。

预填充阶段分析

下图展示了在完整解码缓存条件下,三个任务在不同预填充阶段压缩比率下的性能表现:

Long-Bench中的PassageRetrieval-en和HotpotQA任务表现出显著的压缩容忍度:即使在20%的预填充阶段压缩比率下,模型仍能保持与完整缓存相近的性能水平,证实了模型在高压缩率下维持上下文理解能力的鲁棒性。然而在LONGGENBENCH的GSM8k+任务中,同样的20%压缩率导致准确率下降约95%

实验结果表明:对于依赖完整上下文的推理任务,预填充阶段的过度压缩会导致显著的性能损失

解码阶段分析

下图描述了在解码步骤1、300和500时,基于前15%注意力分数选取的重要特征在0、13和31层的位置分布:

观察发现,各层中保留的重要特征主要源自解码阶段生成的KV缓存,在长输出任务中,随着输出序列延长,特征偏移现象愈发显著。这一现象要求在保持预填充阶段识别的重要特征的同时,对解码阶段新出现的重要特征实施有效管理。数据表明,长文本生成的解码阶段采用贪婪算法可能引发重要特征的显著偏移

KV缓存预算分配优化

下图呈现了LONGGENBENCH中GSM8k+样本第13层的注意力热力图,以及注意力分数与生成标记位置的对应关系:

图中最左侧和最右侧分别对应预填充和解码阶段。对于需要并行处理多个问题的推理任务,准确定位当前预测位置至关重要。如图所示,这些关键信息可通过贪婪算法识别的重要特征有效捕获。预填充和解码阶段的KV缓存预算需要独立分配以实现最优性能。这一发现启发了SCOPE框架的设计理念:通过解耦预填充和解码阶段的压缩过程,实现KV缓存预算的精确分配,在保留预填充阶段全部KV缓存的同时,优化缓存预算的重分配效率

方法论

KV缓存压缩机制重构

初始化过程

KV缓存压缩的核心在于基于预设缓存预算进行动态调整。本文构建了缓存池Φ,其包含两个子集:存储预填充阶段KV缓存的Φp和存储解码阶段KV缓存的Φd。缓存池在时间步t实时更新,记为Φt。采用广泛验证的贪婪算法函数ΨK(Att)从给定注意力权重Att中筛选Top-K KV缓存

预填充阶段设计

定义输入提示张量P ∈ RM×D,其结构为P = {P1,P2, . . . ,PM},其中:

  • Pi表示第i个标记的嵌入向量
  • M为输入标记数量
  • D为模型隐藏维度

键值张量的计算公式如下:

其中:

  • WK,WV ∈ RD×D分别为键和值的投影权重矩阵
  • KV对表示为KPVP
  • 注意力权重AttP通过P和KPVP计算得出,预填充阶段的压缩表达式:

其中:

·表示张量连接操作

函数Ψα1(AttP)从AttP[: −α2]中选择具有最高Top-α1注意力权重的KV缓存

解码阶段实现

解码阶段复用预填充阶段的KV缓存,并通过序列生成过程持续更新,对于时间步t处的新标记张量Xt,t∈{1,T },键值计算如下:

过程中,KtVt与缓存池Φ中的历史KV缓存进行连接,形成当前时刻的KV对。随后与查询张量Xt计算得到注意力权重Attt

  • 本方法与现有KV压缩方案的核心区别在于Φp和Φd在缓存池Φ中的动态分配机制

SCOPE框架详解

针对解码阶段设计了三种优化策略:滑动窗口、自适应调整和不连续更新,这些策略均专注于Φd的优化

滑动窗口机制

通过动态调整解码必要历史窗口β1和解码局部窗口β2实现解码阶段的KV缓存压缩:

  • β1负责捕获当前预测位置的上下文信息
  • β2保存与历史标记高度相关的全局特征

滑动策略在t > M + β1 + β2时触发,通过函数Ψβ1 (Attt[α1 + α2 : −β2])实现对Φd的定向更新,同时保持Φp不变。该机制通过限制选择函数Ψ的操作范围(从α1 +α2开始的Attt),有效规避了预填充阶段注意力权重的干扰

自适应调整策略

针对解码生成标记长度较短的情况,引入动态调整机制,避免过长的解码必要历史窗口β1导致的资源浪费。设计了基于时间步骤t和最大长度T的自适应函数,用于动态调整β1长度,其中T ≫ β1 + β2。窗口大小从基准值β2起始,随时间步t线性增长:

特征:

  • 当t < T时,Φdt的预算规模为β2+(t−β2)·β1/ T−β2
  • 该设计有效优化内存利用率,因比率(t−β2 (T−β2)恒小于1
  • t达到T时,Φdt规模收敛于β1 + β2
  • 此调整机制与LLM的自回归编码特性高度契合,在不引入额外超参数的前提下提升资源利用效率

不连续更新机制

传统策略中,Top-K选择操作ΨK(Att)需执行T − β2次,这种频繁的GPU I/O操作带来显著性能开销。基于连续查询倾向于选择相似键的特性,提出不连续更新策略:

1、将Top-K选择操作ΨK(Att)的执行频率优化为每T−β2/β1间隔执行一次ζ

2、相比于传统的逐步执行方式,显著降低了计算开销

实验评估

实验环境配置

基于两个主流开源大语言模型构建实验平台:

  • LLaMA-3.1–8B-Instruct
  • Mistral-7B-Instruct-v0.3

Φp参数配置:

  • LongGenBench-4K场景:α1 + α2 = 2048(约占输入长度60%)
  • LongGenBench-8K场景:α1 + α2 = 4096(约占输入长度60%)
  • α2统一设置为8
  • β1 + β2参数设置:- 4K输出配置:512- 8K输出配置:1024- β2固定为256,用于适配答案中的推理链(Chain-of-Thought)长度,避免序列过短引发的性能退化

性能评估结果

基准系统对比分析

下表展示了在LONGGENBENCH基准测试中,基于LLaMA-3.1–8B-Instruct的SCOPE三种策略与现有方法的性能对比:

实验结果分析:

SCOPE框架的三种策略在所有解码压缩方案中均实现最优性能,其中针对内存使用和传输优化的不连续策略表现尤为突出。在高难度GSM8K+/GSM8K++任务上,SCOPE通过保留预填充阶段KV缓存的策略展现显著优势,而其他压缩方法出现明显的性能衰减。PyramidInfer与H2O的性能差异不显著,表明在长序列输出任务中,层间稀疏性特征的影响相对有限

预填充方法集成验证

下表呈现了LLaMA3.1-8B在LONGGENBENCH-4K的GSM8K+任务上的方法集成实验数据:

关键发现:

  • 部分优化策略在仅使用65%原始KV缓存的情况下,实现了超越完整缓存的性能表现
  • PyramidKV(SnapKV的变体)通过跨层预算重分配的尝试未能带来显著改善,验证了前期实证研究结果
  • 预填充阶段保留的KV缓存表现出类似StreamingLLM中"注意力汇聚点"的特性

深入分析

必要特征损失的缓解效果

H2O等统一压缩方法由于重要特征偏移导致关键KV缓存损失,影响了上下文理解能力,下图描述了预测位置与模型性能的关联关系:

数据显示H2O在后期预测中出现显著性能下降,而SCOPE的三种策略有效缓解了这一问题,证实了预填充KV缓存保留策略的有效性

关键参数影响分析

解码阶段的两个核心参数:

  • KV缓存预算 β1+β2
  • 特征选择算法 ΨK(Att)

下图展示了基于两种主流top-K选择算法对预算参数进行缩放的实验结果:

与预填充阶段相比,解码阶段展现出更强的压缩容忍度:25%的压缩率仅导致15%的性能降低,而类似压缩率在预填充阶段会导致GSM8k+任务性能的显著下降

系统效率评估

基于滑动窗口策略的自适应和不连续优化显著提升了内存效率,具体数据如下表:

相较于完整缓存和单一预填充压缩方案,本文提出的方法和统一压缩策略通过降低KV缓存存储量,有效缓解了内存压力,自适应策略通过动态预算调整机制进一步优化了系统性能。

泛化能力验证

下图展示了在β1 + β2 = 512配置下,∞BENCH中En.Sum任务的实验结果:

实验表明SCOPE的三种策略均优于完整缓存配置,充分验证了该框架的泛化能力

局限性分析

SCOPE框架通过分离预填充和解码阶段实现长文本生成任务的优化,在两个阶段均采用Top-K算法进行特征选择。当前框架存在以下待改进方向:

1、预填充阶段仍沿用传统top-K算法,未来研究可探索分块处理或其他新型技术,以提升历史标记的估计精度

2、解码阶段每步执行Top-K操作导致频繁的GPU I/O开销。虽然不连续策略在一定程度上优化了操作频率,但仍可通过减少I/O数据量进一步降低系统延迟

3、当前SCOPE主要验证了文本模态的长输出任务优化效果。框架具有扩展到视觉领域的潜力,特别是在多图像生成等需要大量KV缓存的任务场景

总结

SCOPE框架针对LLM长文本生成中的KV缓存优化问题提供了系统性解决方案

通过实验观察发现两个关键问题:

预填充阶段的过度压缩对推理能力造成显著影响,解码过程中存在重要特征的偏移现象

SCOPE通过以下机制解决上述问题:

保持预填充阶段必要的KV缓存完整性;引入滑动窗口策略实现解码阶段KV缓存的高效管理

大规模实验验证表明:

SCOPE仅使用35%原始内存即可达到接近完整KV缓存的性能水平,并且保持了与现有预填充压缩方法的良好兼容性

https://avoid.overfit.cn/post/e5ac0b501a1e4a4fb62eedcf49cd8675

作者:SACHIN KUMAR

目录
相关文章
|
2月前
|
缓存 NoSQL Java
什么是缓存?如何在 Spring Boot 中使用缓存框架
什么是缓存?如何在 Spring Boot 中使用缓存框架
51 0
|
2月前
|
缓存 监控 前端开发
在资源加载优化中,如何利用浏览器缓存提升性能?
通过以上这些方法,可以有效地利用浏览器缓存来提升资源加载的性能,减少网络请求次数,提高用户体验和应用的响应速度。同时,需要根据具体的应用场景和资源特点进行灵活调整和优化,以达到最佳的效果。此外,随着技术的不断发展和变化,还需要持续关注和学习新的缓存优化方法和策略。
96 53
|
2月前
|
缓存 监控 测试技术
如何利用浏览器的缓存来优化网站性能?
【10月更文挑战第23天】通过以上多种方法合理利用浏览器缓存,可以显著提高网站的性能,减少网络请求,加快资源加载速度,提升用户的访问体验。同时,要根据网站的具体情况和资源的特点,不断优化和调整缓存策略,以适应不断变化的业务需求和用户访问模式。
107 7
|
4月前
|
缓存 Java 开发工具
Spring是如何解决循环依赖的?从底层源码入手,详细解读Spring框架的三级缓存
三级缓存是Spring框架里,一个经典的技术点,它很好地解决了循环依赖的问题,也是很多面试中会被问到的问题,本文从源码入手,详细剖析Spring三级缓存的来龙去脉。
233 24
|
3月前
|
缓存 JavaScript 前端开发
Vue 3的事件监听缓存如何优化性能?
【10月更文挑战第5天】随着前端应用复杂度的增加,性能优化变得至关重要。Vue 3 通过引入事件监听缓存等新特性提升了应用性能。本文通过具体示例介绍这一特性,解释其工作原理及如何利用它优化性能。与 Vue 2 相比,Vue 3 可在首次渲染时注册事件监听器并在后续渲染时重用,避免重复注册导致的资源浪费和潜在内存泄漏问题。通过使用 `watchEffect` 或 `watch` 监听状态变化并更新监听器,进一步提升应用性能。事件监听缓存有助于减少浏览器负担,特别在大型应用中效果显著,使应用更加流畅和响应迅速。
112 1
|
4月前
|
缓存 JavaScript 中间件
优化Express.js应用程序性能:缓存策略、请求压缩和路由匹配
在开发Express.js应用时,采用合理的缓存策略、请求压缩及优化路由匹配可大幅提升性能。本文介绍如何利用`express.static`实现缓存、`compression`中间件压缩响应数据,并通过精确匹配、模块化路由及参数化路由提高路由处理效率,从而打造高效应用。
200 15
|
3月前
|
存储 缓存 监控
HTTP:强缓存优化实践
HTTP强缓存是提升网站性能的关键技术之一。通过精心设计缓存策略,不仅可以显著减少网络延迟,还能降低服务器负载,提升用户体验。实施上述最佳实践,结合持续的监控与调整,能够确保缓存机制高效且稳定地服务于网站性能优化目标。
58 3
|
4月前
|
缓存 监控 负载均衡
在使用CDN时,如何配置缓存规则以优化性能
在使用CDN时,如何配置缓存规则以优化性能
|
4月前
|
缓存 NoSQL Java
瑞吉外卖项目笔记+踩坑2——缓存、读写分离优化
缓存菜品、套餐数据、mysql主从复制实现读写分离、前后端分离
瑞吉外卖项目笔记+踩坑2——缓存、读写分离优化
|
5月前
|
缓存 NoSQL Java
SpringBoot的三种缓存技术(Spring Cache、Layering Cache 框架、Alibaba JetCache 框架)
Spring Cache 是 Spring 提供的简易缓存方案,支持本地与 Redis 缓存。通过添加 `spring-boot-starter-data-redis` 和 `spring-boot-starter-cache` 依赖,并使用 `@EnableCaching` 开启缓存功能。JetCache 由阿里开源,功能更丰富,支持多级缓存和异步 API,通过引入 `jetcache-starter-redis` 依赖并配置 YAML 文件启用。Layering Cache 则提供分层缓存机制,需引入 `layering-cache-starter` 依赖并使用特定注解实现缓存逻辑。
1288 1
SpringBoot的三种缓存技术(Spring Cache、Layering Cache 框架、Alibaba JetCache 框架)