模型架构与显存分析
什么是KV缓存？计算公式、显存估算与优化深度指南
深入解析键值缓存（KV Cache）如何加速自回归生成、为什么在长上下文时会引发突发性显存溢出（CUDA OOM），以及如何将其显存占用降低50%至75%。
Interactive KV Cache Calculator
See how architecture, context tokens, and precision dictate real GPU memory consumption.
32 layers · 32 query heads · 8 KV heads (4:1 GQA group)
Multi-user servers (like vLLM) multiply the KV cache by active parallel requests.
Formula: 2 (Keys + Values) × 32 layers × 8 KV heads × 128 head dim × 32,768 tokens × 2 bytes
Because this model uses GQA (8:1 ratio), this KV cache is 4x smaller than it would be with legacy MHA (which would have required 16.0 GiB).
1. 为什么自回归大模型生成必须使用KV缓存
在Transformer推理过程中，Token是一个接一个按顺序生成的。为了预测第N个Token，模型必须对前面所有的N-1个Token计算注意力。如果不使用KV缓存，每个生成步骤都必须重新计算前面所有Token的Key和Value向量，导致计算复杂度呈二次方O(N²)爆炸式上升。
通过在显存中缓存历史Key和Value向量，每一步生成的计算开销保持在线性O(N)。但这是一种典型的“以空间换时间”策略：上下文中的每一个新Token，都会让显存中的KV缓存不断膨胀，直至生成结束。
2. 精确数学计算公式
公式中的倍数2分别代表Key和Value。模型层数表示Transformer深度，KV注意力头数取决于是否采用GQA架构，单头维度为头向量尺寸，序列长度为当前上下文Token总量。
示例：Llama 3 8B采用GQA架构（8个KV头、单头维度128、32层），在FP16精度（每个参数2字节）下处理16k上下文：2 x 32 x 8 x 128 x 16,384 x 1 x 2 = 2.15 GB 显存（单个用户请求）。
3. 注意力架构演进：MHA vs GQA vs MLA
4. 如何量化KV缓存（节省50%至75%显存）
默认情况下，绝大多数推理框架使用FP16精度存储KV缓存（每个元素2字节）。如果将缓存量化为FP8（1字节）甚至INT4（0.5字节），即可在不重新量化模型本身权重的前提下，直接砍掉50%至75%的上下文显存占用。
在vLLM中，仅需添加启动参数 --kv-cache-dtype fp8 即可；在llama.cpp中，加入 -ctk q8_0 -ctv q8_0 或 -ctk q4_0 -ctv q4_0，即可显著降低32k以上超长对话时的显存压力。
常见问题解答
推理引擎会直接发生CUDA显存溢出（Out of Memory）导致程序崩溃退出；如果开启了滑动窗口机制，则会强行丢弃最早的历史对话。因此在部署时预留足够的显存余量至关重要。
取决于整个序列的总Token长度（提示词Token加生成Token之和）。20,000字的提示词配2,000字回答，与2,000字提示词配20,000字回答所占用的KV缓存字节数完全一致。
几乎不会。大量权威评测证明，采用FP8量化KV缓存对数学推导和逻辑推理任务的精度损失微乎其微，却能释放出宝贵的数GB显存用于承载更长的思考链路。
呈严格线性倍增。如果4个用户同时发起8k上下文的请求，KV缓存的显存开销就是单人状态的4倍。像vLLM这样的专业服务端引擎通过PagedAttention虚拟分页技术，能极大减少多并发时的显存碎片浪费。
MLA通过低秩矩阵压缩技术，在存入缓存前将臃肿的高维KV向量压缩为极小维度的Latent向量，相比传统MHA压缩率高达93%。这就是DeepSeek在128k上下文时依然极其省显存的底层核心秘诀。
测算你所需上下文的精确KV缓存大小
利用我们的交互式VRAM计算器，自由模拟不同模型、上下文长度与Batch设置下的实际显存开销。
Knowledge & Deep Dives
本地LLM与显存知识中心
深度技术指南、架构拆解与硬件选配手册，帮助开发者毫无压力地在本地部署、运行和扩展大语言模型。