网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言：为什么“推理比训练更烧钱”？

在大模型落地之后，一个非常反直觉的现象开始频繁出现：

GPU 还没满载
但显存已经 OOM

甚至在很多生产环境中：

GPU 利用率：30%
显存占用：95%

这就引出了一个关键问题：

为什么推理阶段这么“吃显存”？

答案只有一个核心：

KV Cache（Key-Value Cache）正在悄悄吞掉所有显存。

一、KV Cache 并不是“缓存优化”，而是“状态爆炸”

很多人第一次听 KV Cache，会以为它只是：

Transformer 的加速技巧

但在工程实现中，它其实是：

Transformer 推理的“历史状态存储器”

为什么必须要 KV Cache？

来看 Transformer 自回归生成：

Token1 → Token2 → Token3 → Token4 → ...

如果没有 KV Cache：

每生成一个 Token，都要重新计算所有历史 Attention

第1步：算 1 个 token
第2步：重新算 2 个 token
第3步：重新算 3 个 token
...

复杂度直接爆炸：

O(n²)

KV Cache 的本质就是：

把历史 Token 的 Key / Value 存下来，避免重复计算

也就是说：

只算新的 Q
复用历史 K / V

二、KV Cache 到底存了什么？

很多人误解 KV Cache：

• 不是缓存模型
• 不是缓存输出
• 不是缓存 embedding

它缓存的是：

每一层 Transformer 的：
    Key Tensor
    Value Tensor

并且：

每一层都有一份！
每个 token 都要存！

KV Cache 结构本质：

Layer 1: K + V
Layer 2: K + V
Layer 3: K + V
...
Layer N: K + V

关键点（非常重要）：

KV Cache 是随着 Token 数“线性增长”的状态数据

三、KV Cache 为什么会“吞显存”？

我们用公式说清楚：

KV Cache Size ≈
Layers × Tokens × Hidden × 2 × Batch × dtype

举个真实例子（70B 模型）

假设：

Layers = 80
Heads = 64
Head Dim = 128
Context = 8K
FP16

那么，单用户 KV Cache：

≈ 几百 MB ~ 1GB+

如果是 32K context？

直接 ×4

变成：

4GB ~ 8GB / 用户

结论：

KV Cache 比模型参数更“吃显存”

四、多用户并发：为什么 GPU 会瞬间爆？

很多线上服务会遇到：

单用户正常
10用户勉强
50用户 OOM

原因非常简单：KV Cache 是“每个用户一份”

用户A → KV Cache A
用户B → KV Cache B
用户C → KV Cache C

显存增长模型：

总显存 ≈ 用户数 × 单用户 KV Cache

结论：

KV Cache 是“线性扩展型显存炸弹”

五、PagedAttention：vLLM 为什么能提升吞吐？

传统 KV Cache 问题：

连续内存 + 碎片严重 + 利用率低

vLLM 的解法：分页机制

类似操作系统：

虚拟内存分页（Paging）

KV Cache 被拆成：

Block 1
Block 2
Block 3
...

优势：

• 避免显存碎片
• 支持动态分配
• 支持多请求复用

本质：

KV Cache 从“连续内存”变成“可调度内存池”

六、Prefix Cache：为什么重复 Prompt 可以省钱？

很多系统都有固定前缀：

System Prompt
角色设定
规则约束

传统方式，每次重新算 KV Cache

Prefix Cache：

缓存系统 Prompt 的 KV

直接复用：

System KV Cache ✔

价值：

• 极大降低重复计算
• 提升 TPS
• 降低冷启动成本

七、FlashAttention ≠ KV Cache 优化

这是一个非常常见误区，错误理解：

FlashAttention = KV Cache 优化

正确理解：

技术	优化对象
FlashAttention	Attention 计算
KV Cache	Memory 存储

结论：

FlashAttention 优化“算得快”，KV Cache 优化“存得少”

八、企业级 KV Cache 架构长什么样？

真正生产环境通常是这样：

Request
   ↓
Scheduler
   ↓
KV Cache Manager
   ↓
Memory Pool
   ↓
GPU Attention Kernel

KV Cache Manager 负责：

• 显存分配
• 生命周期管理
• Prefix 复用
• Page 调度
• 回收策略

九、KV Cache 优化手段全景图

1、KV Quantization

FP16 → INT8 / INT4

直接减半甚至 1/4 显存

2、Sliding Window

只保留最近 N tokens

控制 KV 上限

3、KV Offloading

GPU → CPU → NVMe

牺牲速度换容量

4、Context Compression

长对话 → 摘要

从源头减少 KV

十、KV Cache 的本质问题

总结一下 KV Cache 的核心矛盾，三大问题：

1. 随 Token 线性增长
2. 随用户线性增长
3. 无法共享（默认）

本质结论：

KV Cache 不是优化问题，而是“系统架构问题”

总结：KV Cache 才是推理系统的真正成本黑洞

很多人以为大模型推理贵是因为：

模型太大

但真实情况是：

推理成本的真正核心，是 KV Cache

一句话总结全文：

KV Cache 是 Transformer 推理过程中的“历史状态存储系统”，它决定了模型的上下文能力，同时也是 GPU 显存消耗的最大来源。

最终结论：

模型参数 → 决定“能力上限”
KV Cache → 决定“系统成本”