当前位置: 首页 > news >正文

现代 LLM 的核心架构设计其三:Decoder-Only 下的 KV Cache

其中的基石就是 KV Cache。

  1. Decoder-Only#
    18 年,OpenAI 提出了 GPT-1 :Improving Language Understanding by Generative Pre-Training,其核心内容就是现在的 Decoder-Only 架构,这是目前绝大多数通用大语言模型采用的基本架构。

有了之前的基础,Decoder-Only 的逻辑并不难理解:
研究人员发现,对于语言建模任务而言,并不一定需要单独的 Encoder。只要让模型根据已有文本不断预测下一个 Token,就能够学习语言规律。

因此现代大模型直接移除了 Encoder,同时删除了依赖 Encoder 输出的 Cross Attention,最终仅保留 Decoder 中的 Masked Self-Attention 与 FFN 结构:

image.png

可以看到原始的 GPT-1 基本逻辑仍然是在预训练的模型基础上,继续用特定数据训练,让模型适应某个任务或领域,也就是 Fine-tuning,而这种基础的任务能力现在已经可以靠 prompt 来激活了。
因此,了解 Decoder-Only 架构本身的相关逻辑即可,这里展开两个细节:

1.1 用户输入是如何作用的?#
既然没有 Encoder,一个自然的问题是:

用户输入由谁来理解?

答案是:

用户输入本身就是 Decoder 的输入序列。

我们直接举个例子,用户提问:

法国的首都是哪里?
这句话会直接被转换为 Token 序列:

法国 的 首都 是 哪里 ?
随后送入 Decoder。模型经过一次前向传播后,预测:

巴黎
此时序列变成:

法国的首都是哪里?巴黎
之后同理,继续生成直到生成结束标记:

法国的首都是哪里?巴黎。它位于……
这种根据已经出现的内容预测下一个 Token 的过程就是自回归生成(Autoregressive Generation)。

1.2 Attention 中的重复计算问题#
明白了 Decoder-Only 的生成逻辑后,现在我们来看一个推理时的问题:


步时,模型需要计算
个 token 之间的自注意力,然后预测第
个 token。然后第
步,输入变成
个 token,再算一遍注意力,预测第
个。

现在,假设模型已经生成到了第
个 token,第
步计算了 token

之间所有注意力。到了第
步,输入变成了 token

,标准做法会把 token

的 K 和 V 重新计算一遍。

问题就出在这个"再算一遍"上:

在第
步和
步之间,token

的 K 和 V 变了吗?

答案是没有。
在参数固定的推理阶段,token
在第一步后就固定了。token
的内容同理在第
步生成后就已经固定了。它们的 K 和 V 不会因为一个新 token 的加入而改变。每次重新计算都是纯粹的浪费。

显然,这里存在相当大的优化空间,这便是 KV Cache 要解决的问题。

21c1e846-9a9b-4f44-84c4-c8e2e6998ed3.png

  1. KV Cache#
    2.1 KV Cache 的内容#
    KV Cache 的思路很简单:

在第
步算完

后,把它们存起来。第
步只需要计算

,然后把它们追加到缓存中。所有之前 token 的 K 和 V 直接从缓存读取。

就像这样:

步骤 计算内容 缓存
生成 token 1 算
,存起来
生成 token 2 只算
,追加到缓存
生成 token 3 只算
,追加到缓存
… 每步只算一个
缓存逐步增长
于是,原本的每一步的注意力计算是这样:

现在加入 KV Cache 就变成了这样:

其中:

是缓存的历史。只有
是当前步需要计算的。

很显然,通过 KV Cache 我们消灭了计算 KV 投影时的无用功。在长文本生成时,其带来的性能差距是数量级的。

2.2 为什么 Q 不需要缓存?#
既然 K 和 V 都被缓存了,一个可能的问题是:

为什么不把 Q 也缓存起来复用?

区别在于它们的角色不同:
在自回归生成的每一步,当前 token 的 Q 作用是查询历史信息。
与所有历史 K 计算注意力分数,然后从所有历史 V 中聚合信息来预测下一个 token。

一旦这一步的预测完成,
的历史使命就结束了。
未来步的
只关心它们自己与历史的匹配,不再需要回头看



不一样。它们在第
步生成后,仍然会被未来的所有 token 查询。
只要未来某一刻的

)需要与第
步的信息做注意力计算,

就必须一直存在。

所以总结来说就是:Q 是查完即弃,无需保留。

2.3 KV Cache 的内存开销#
KV Cache 不是免费的午餐,它的本质就是典型的空间换时间。

在推理过程中,我们将历史 token 的 K 和 V 保存在显存中,以避免后续步骤重复计算。计算省下来了,但这些缓存需要一直保留到生成结束。

对于传统 Multi-Head Attention,每一层 KV Cache 的大小近似为:

其中:

2:表示 K 和 V 各保存一份;
batch_size:批次大小,推理中为并行请求数。
seq_len:当前缓存中的累计 Token 数量。
:隐藏层维度。
dtype_bytes:数据精度占用字节数(FP32 为 4,FP16/BF16 为 2)。
很显然,这并不是一笔小开支。举个简单的例子,假设:

参数 取值
8192
Transformer 层数 80
上下文长度 4096
精度 BF16(2 Byte)
那么单层 KV Cache 大约需要:

80 层累计下来就是:

也就是说,一个拥有数千 token 上下文的大模型会话,仅 KV Cache 就可能占据十 GB 量级的显存。

如果进一步进行批量推理:
,那么 KV Cache 占用还会近似放大 64 倍。
因此,KV Cache 虽然解决了重复计算的问题,却把压力从计算转移到了内存上。

于是这种内存压力,又反过来驱动了注意力结构的变革和一系列配套工程优化,这便是之后的内容了。

http://www.cnnetsun.cn/news/3281879.html

相关文章:

  • 【AI编码】一文吃透AI规范开发工作流选型|BMAD / SpecKit / Superpowers / OpenSpec 全对比+实战命令代码
  • 虚幻引擎与MA2灯光控制台联动:环回网络配置与Art-Net通信全解析
  • 边缘AI部署实践:从模型压缩到多模态交互的技术解析
  • TypeScript 泛型工具实战:3 个真实业务场景下的高级类型体操
  • MATLAB App Designer 与 GUIDE 深度对比:2024年开发选型5个关键考量
  • 如何通过C++封装托盘服务,通过html调用打印机
  • svt_apb_if里的宏定义问题
  • hostha与Consul集成指南:构建可靠的OpenStack监控集群
  • 企业AI智能体落地过程中常见的5个避坑点
  • 深耕滇地全域数字化营销,布局 AI 新搜索流量蓝海
  • 3款主流双频GNSS模块对比:SKG122S、E108-GN07IS与TB LQ模块实测解析
  • 终极指南:3个技巧快速掌握PUBG鼠标宏压枪技术
  • Honey Select 2终极优化指南:如何用HS2-HF_Patch一键解决语言障碍与性能问题
  • 一套纯 OpenCode 配置实现 Agent 软路由 背景
  • 从Cell文献看空间单细胞蛋白组的转化研究价值:单细胞发现之后,为什么还要看蛋白和空间邻域?
  • S-R与D锁存器Verilog建模实战:3种电路结构对比与亚稳态规避
  • 基于K层下行异构蜂窝网络的网络覆盖率和速率计算matlab仿真
  • Python 3.12 字符串校验:isalpha() 等 12 个 is*() 方法全解析与 Unicode 陷阱
  • UE4SS脚本注入框架:Unreal Engine游戏实时修改与模组开发实战指南
  • 我用 AI 十分钟生成了一个科幻风智慧城市 3D 大屏,附完整 Prompt 和源码解析
  • 政策快报平台的全文检索:从ES到向量检索的演进
  • 鸿道安全云:面向轨道交通安全关键业务的新一代云化基础平台
  • Python图像识别自动化连连看实战指南:计算机视觉与游戏算法深度解析
  • Premiere Pro安装本质:从CC服务化架构到稳定工作流构建
  • 参数权重失控?风格崩坏?——Midjourney提示词精准控制全链路拆解,含37组AB测试对比数据
  • Hermes Agent不是聊天工具,而是轻量级智能体操作系统
  • SWE-1.7:高性能AI编程助手的成本效益突破与工程实践
  • Muse Image扩散模型解析:从原理到社交平台集成实践
  • AI 电动玩具车智能功率 高效率、小封装 完整选型方案
  • UE4SS终极指南:如何快速掌握虚幻引擎脚本系统的核心功能