首页
学习
活动
专区
圈层
工具
发布
技术百科首页 >KV 缓存机制 >单个 Token 的 KV 缓存大小由哪些参数决定?

单个 Token 的 KV 缓存大小由哪些参数决定?

词条归属:KV 缓存机制

1. 显存占用的基础公式

单个序列的 KV 缓存字节数可用如下一阶公式估算:

KV 缓存大小(字节) = 2 × L × H_kv × D × S × P

其中各参数含义为:2 表示键与值两个独立张量;L 为 Transformer 层数;H_kv 为键值头(KV Head)数量;D 为每个头的维度;S 为上下文长度(token 数);P 为每个元素的字节数(FP16 / BF16 为 2 字节,INT8 为 1 字节,INT4 为 0.5 字节)。

2. 单个 Token 的缓存由层数与头维度主导

单 token 的缓存大小为 2 × L × H_kv × D × P 字节,它随层数、键值头数、头维度与精度的增加而增加。例如采用多头注意力(MHA)的 LLaMA-2 7B(32 层、32 个键值头、头维度 128、FP16)单 token 缓存约为 512 KiB,在 4K 上下文下约占用 2 GB 显存。

3. 精度与架构对同一 Token 的影响

同一模型下,将缓存精度从 FP16 降到 FP8 或 INT4,可直接减半或减至四分之一的单 token 缓存;而采用分组查询注意力(GQA)或低秩压缩(MLA)等架构,则通过减少键值头数或压缩表示维度,从结构上缩小单 token 缓存。

相关文章
技术分析:DeepSeek 如何改进 Transformer 架构?
DeepSeek 最近发布了 DeepSeek v3,这是目前在开放权重模型中基准性能表现最好的模型,同时还发布了一份技术报告,详细描述了该模型的训练过程。令人印象深刻的是,他们仅使用了 280 万个 H800 小时的硬件训练时间就实现了这一 SOTA 性能——如果我们假设 40% MFU,这相当于大约 4e24 FLOP。这比性能类似的 Llama 3.1 405B 少了大约 10 倍的训练计算量。
大脸猫不吃鱼
2025-02-05
1.7K1
6.7k Star量的vLLM出论文了,让每个人都能轻松快速低成本地部署LLM服务
今年六月,来自加州大学伯克利分校等机构的一个研究团队开源了 vLLM(目前已有 6700 多个 star),其使用了一种新设计的注意力算法 PagedAttention,可让服务提供商轻松、快速且低成本地发布 LLM 服务。
机器之心
2023-09-25
2.7K0
想让LLM多想几轮,又不想显存爆炸?MELT 把循环 Transformer 的 KV 缓存解耦了
过去两年,让大模型"会思考"的主流路径是 Chain-of-Thought:模型在给答案前先把推理过程一段段地"说出来"。它有效,但也有清晰的代价——输出越长,延迟越高,KV 缓存越大。
唐国梁Tommy
2026-06-25
3040
KV Cache管理架构演进:从连续分配到统一混合内存架构
在生产环境部署过LLM的人都知道模型权重只是问题的一半,另一半是KV cache:存储注意力状态的运行时内存,让模型在生成token时不必从头开始重算。能不能管好这块内存决定了系统是一个卡顿的demo还是一个可用的推理服务。
deephub
2026-03-04
1.5K1
深圳腾讯云代理商:火山引擎GPU云服务器运行长上下文模型变慢?显存与带宽瓶颈解析
跑过长上下文模型的工程师大概都遇到过这种场景:一套prompt丢进去,模型处理短文档时丝滑流畅,换成几百页的合同文件,推理速度突然断崖式下跌,GPU利用率曲线像过山车。这背后是一连串显存管理和带宽分配的工程问题,而选对云上GPU实例的规格配比,往往比堆更多卡更管用。火山引擎GPU云服务器长上下文优化这件事,本质上就是把这些瓶颈一个一个拆开来看。
聚搜云-JuSouYun
2026-07-27
2670
点击加载更多
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
领券