文章目录1. 显存去哪了钱都花哪了1.1 模型权重一次付清的房贷1.2 KV Cache按用量收费的水电1.3 激活值与碎片地板缝里的钢镚1.4 账本算给你看2. 老办法有多败家按最大长度预留2.1 内部碎片租了四居室只睡一张床2.2 预留浪费签完合同就锁死2.3 外部碎片满屋饼干渣拼不出整块2.4 败家数据60% 到 80%3. 跟操作系统偷师PagedAttention3.1 先回忆大学欠下的课3.2 KV Cache 版分页3.3 效果从败家子到精算师4. 拼车文化前缀缓存4.1 大家都在说一样的开场白4.2 给块办个指纹身份证4.3 引用计数拼车的人下车才退租4.4 RadixAttention从查字典到抄作业5. 空口无凭跑个实验6. 给缓存减肥量化6.1 scale把大件行李压进登机箱6.2 e4m3 和 e5m2谁管大谁管细6.3 默认不校准追求稳可以校6.4 什么时候别乱减6.4.1 上下文很短7k token 以内6.4.2 head_dim 为 256 的模型且在意 prefill 延迟6.4.3 未校准精度持续下移6.4.4 混合注意力模型的小滑窗层7. 显存还是不够搬家到内存7.1 抢占先踢出去回头重排7.2 卸载把冷数据搬进车库7.3 LMCache缓存界的仓管系统7.4 卸载主要是给前缀缓存扩容8. 划重点收工P.S. 目前国内还是很缺AI人才的希望更多人能真正加入到AI行业共同促进行业进步增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 传送门http://blog.csdn.net/jiangjunshow教程通俗易懂高中生都能看懂还有各种段子风趣幽默从深度学习基础原理到各领域实战应用都有讲解我22年的AI积累全在里面了。注意教程仅限真正想入门AI的朋友否则看看零散的博文就够了。先问个扎心的问题你给推理服务配的显卡显存到底被谁掏空的别急着骂黄牛显卡只是背锅的真正的吞金兽另有其人。1. 显存去哪了钱都花哪了推理的时候一块 GPU 的显存大概分四份模型权重、KV Cache、激活值临时缓冲、碎片和框架预留。听起来像家庭开支分类实际上也差不多。1.1 模型权重一次付清的房贷权重加载完就定死了一个 FP16 的 7B 模型大概 13 GiB。这钱跟房贷一样签完合同就不动了想省只能靠量化——那是另一篇文章的故事。1.2 KV Cache按用量收费的水电KV Cache 是所有在跑请求的缓存总和随并发数和序列长度蹭蹭涨。负载越重账单越吓人。它是显存里唯一随流量浮动的大头其他都是小虾米。1.3 激活值与碎片地板缝里的钢镚激活值是前向计算的中间产物算完就释放属于过路财神。碎片和预留是分配器留下的犄角旮旯就像你家里那些永远找不到用途的抽屉扔了可惜留着占地方。1.4 账本算给你看KV Cache 的大小有个公式2 × 层数 × KV 头数 × 头维度 × 序列长度 × 每元素字节数。别问为什么有个 2K 和 V 是两口子得一人一份公平起见。拿 Qwen3-0.6B 这种小模型举例一个 token 的缓存约 112 KB一条 4k 序列就是 448 MiB。也就是说你发一条 4000 token 的“在吗”比发一张照片还费显存。于是矛盾来了调度器刚把并发拉满显存先举手投降。现实里卡住服务吞吐的往往不是算力而是显存。算力不够还能排队等显存不够直接白屏给你看。2. 老办法有多败家按最大长度预留先看最朴素的做法请求一进来直接按最大可能长度给它预留一整段连续显存。max_model_len设 4096哪怕你只想说个“你好”4096 个 token 的地盘先占上跑完才还。这个做法不是不行是败家而且败得很均匀一共三种败法。2.1 内部碎片租了四居室只睡一张床按最大长度预留实际用多少算多少。大部分请求的真实长度远小于上限预留了没用上的部分就一直空着。相当于你租了个四居室天天睡客厅沙发另外三间房落灰还锁着门。2.2 预留浪费签完合同就锁死请求刚开始生成第 1 个 token后面几千个 token 的位置就被锁定了别的请求眼巴巴看着也用不上。像你刚点完菜服务员就把整本菜单的钱都划走了后面排队的客人连个位子都没有。2.3 外部碎片满屋饼干渣拼不出整块不同请求预留的段长不一显存被切得七零八落。剩余总量看着够但凑不出一段连续的来接待新请求。就像一袋饼干碎成渣总量够你吃三天但你拼不出一块完整的。2.4 败家数据60% 到 80%vLLM 团队实测过传统系统里这类浪费能占到 KV Cache 显存的 60% 到 80%。翻译成人话10 块钱的饭6 到 8 块倒掉了剩下两口勉强喂饱你。显存利用率上不去能并发的请求数就上不去continuous batching 攒出来的调度优势全白搭。钱花了活没干成属于典型的人财两空。3. 跟操作系统偷师PagedAttentionvLLM 团队SOSP 2023一作 Woosuk Kwon干了件特别会抄作业的事把操作系统管理内存的分页机制原封不动搬到了 KV Cache 上。3.1 先回忆大学欠下的课操作系统从不要求一个进程的内存物理上连续。它把内存切成固定大小的页进程看到的是连续的虚拟地址背后由页表把虚拟页映射到分散在物理内存各处的物理页。用多少分多少进程结束就回收。当年上课睡觉的同学注意了工作之后这课还得补只不过补课费是显卡。3.2 KV Cache 版分页PagedAttention 的玩法KV Cache 不再是一整段连续空间而是切成固定大小的块每块存固定数量 token 的 K 和 VvLLM 默认一块 16 个 token。每个请求看到的仍是一串连续的逻辑块实际数据存在显存里分散的物理块上。块表维护逻辑块到物理块的映射相当于页表。请求每生成满一个块的 token才向空闲块池申请下一个物理块——像吃自助吃一盘拿一盘而不是先把整家店的菜全点上。3.3 效果从败家子到精算师分页之后三类浪费基本被消掉内部碎片只剩最后一个没填满的块一条序列最多浪费 15 个 token外部碎片没了所有块尺寸相同任何空块都能直接用预留浪费也没了因为根本不预留。论文数据浪费降到 4% 以内。同一块显卡能容纳的并发请求数翻了好几倍。同样的钱以前住单间现在住群租房还带独立卫生间那种。有人问块改小点浪费不更少吗理论上是的但块太小块表就变长管理开销变大。16 个 token 一块是工程上的平衡点vLLM 的默认值也能用启动参数调。4. 拼车文化前缀缓存分块管理还有个意外之喜块可以被多个请求共享。这就是前缀缓存今天第二个主角。4.1 大家都在说一样的开场白实际服务里大量请求的前缀一模一样系统提示词同一个应用的所有请求开头都是同一段 system prompt动辄几百上千 token。多轮对话客户端每次都要把完整历史重新发给服务端第 N 轮请求的前缀就是第 N-1 轮的完整内容。Few-shot 示例一批任务共用同一段输入输出样例只有最后的问题不同。翻译成大白话像相亲大会每个嘉宾上来都背同一段自我介绍。没有前缀缓存时这段自我介绍每个人都要现场背一遍还是背给同一个评委听评委耳朵都起茧了。4.2 给块办个指纹身份证做法很直接给每个块的内容算一个 hashkey 里包含块内 token id 和它前面所有前缀的信息。新请求进来先按块查 hash命中说明显存里已经有内容完全相同的块直接把物理块映射进自己的块表prefill 只算没命中的部分。4.3 引用计数拼车的人下车才退租共享块上挂着引用计数被几个请求引用就记几。请求结束计数减一减到零的块才进空闲池等待复用或回收。像拼车最后一个下车的负责关门关灯还得检查有没有人落下东西。收益是双份的省显存共享的前缀只存一份省计算命中部分的 prefill 整个跳过TTFT 直接下降。长系统提示词和多轮对话这类负载命中率可以非常高。4.4 RadixAttention从查字典到抄作业vLLM 管这个叫 Automatic Prefix CachingAPCV1 引擎里默认开启。SGLang 更狠搞了个 RadixAttention不用 hash 表按块匹配用一棵基数树组织缓存。基数树是压缩的前缀树公共前缀天然是同一条路径可以做任意长度的前缀匹配。淘汰再配合 LRU优先逐出最久没用的节点。多轮对话、树状探索这类共享模式复杂的场景RadixAttention 的命中率比固定块大小的 hash 匹配更稳。简单说hash 是按页抄作业Radix 是按题抄作业抄得更细错得也更少。5. 空口无凭跑个实验概念吹得再好不如跑一次。用 vLLM 起一个 OpenAI 兼容服务显式打开前缀缓存$ vllm serve Qwen/Qwen3-0.6B --enable-prefix-caching--port8000新版本 V1 引擎默认就开不加这个参数效果一样。老版本需要显式指定。然后写个客户端连续发两个请求共享一段很长的系统提示词分别测一下 TTFTimporttimefromopenaiimportOpenAI clientOpenAI(base_urlhttp://localhost:8000/v1,api_keyEMPTY)# 构造一段较长的公共前缀模拟应用层的系统提示词system_prompt你是一位资深的技术编辑回答要准确简洁。*200defmeasure_ttft(question):starttime.perf_counter()respclient.chat.completions.create(modelQwen/Qwen3-0.6B,messages[{role:system,content:system_prompt},{role:user,content:question},],max_tokens8,streamTrue,)for_inresp:# 收到第一个 token 就计时结束breakreturntime.perf_counter()-startprint(第一次请求 TTFT:,measure_ttft(介绍下 KV Cache))print(第二次请求 TTFT:,measure_ttft(介绍下 PagedAttention))我实际跑出来的结果第一次请求 TTFT: 0.32561847753822803 第二次请求 TTFT: 0.01986777689307928第一次要完整 prefill 整段系统提示词几百上千个 token 逐个算一遍TTFT 约 326 毫秒第二次前缀完全相同命中缓存这段 prefill 整个跳过只有约 20 毫秒。差了 16 倍。什么概念第一次像早高峰挤地铁排到怀疑人生第二次像老板专用电梯门一开直达。具体毫秒数和提示词长度、硬件强相关但命中后明显变快这个趋势非常稳定。服务端日志也能直接看到命中情况(APIServer pid176492) INFO 08-24 07:40:29 [loggers.py:310] Engine 000: Avg prompt throughput: 222.7 tokens/s, Avg generation throughput: 1.6 tokens/s, Running: 0 reqs, Waiting: 0 reqs, GPU KV cache usage: 0.0%, Prefix cache hit rate: 49.8%第一个请求命中率 0%第二个公共前缀全部命中两次平均下来正好一半左右日志里的 49.8% 严丝合缝对上了。最后提醒一句前缀匹配是在 token 层面精确进行的。系统提示词差一个字符、聊天模板换一个版本token 序列就变了缓存全部失效。线上服务必须保证前缀部分的内容和模板严格稳定。这严格程度比查手机还较真。多打一个空格整个缓存当场社死一点情面都不讲。6. 给缓存减肥量化除了换分配方式还有一条更直接的路让缓存里每个元素占更小的空间。回看公式最后一个因子是每元素字节数FP16 是 2 字节换成 FP8 或 INT8 只占 1 字节KV Cache 直接减半能容纳的并发或上下文长度近似翻倍。vLLM 一行参数的事$ vllm serve Qwen/Qwen3-0.6B --kv-cache-dtype fp86.1 scale把大件行李压进登机箱FP16 的数值压进 8 位信息总有损失损失多少取决于一个关键系数scale缩放系数。FP8 能表示的数值范围很小e4m3 格式最大只有 448而 KV Cache 里的实际数值范围可能超出它所以需要一个缩放系数把原始数值压缩进 FP8 的量程读出来时再放大回去。scale 定得不准要么数值超出量程被截断要么量程没占满白白损失精度。相当于行李箱压缩袋拉链拉到一半卡住了里面的衣服全皱成一团掏出来还都是褶子。6.2 e4m3 和 e5m2谁管大谁管细e4m3 是 FP8 的一种格式名字就是它的结构1 位符号、4 位指数e、3 位尾数m。指数位决定量程4 位指数让它最大表示到 448尾数位决定精度3 位尾数意味着相对精度只能到 1/8 左右。FP8 还有种 e5m2指数多一位、尾数少一位量程更大但精度更粗训练里存梯度用得多。推理场景的 KV Cache 量化一般用 e4m3vLLM 的fp8选项默认就是它。一句话e5m2 是“装得多但装得糙”e4m3 是“装得少但装得精”。像行李箱和首饰盒的区别一个管量大管饱一个管精致细作。6.3 默认不校准追求稳可以校vLLM 默认不校准所有 scale 直接设 1.0多数模型上效果够用。想更稳官方推荐用 llm-compressor 做离线校准拿几百条有代表性的数据过一遍模型统计 K、V 激活值的实际分布算出合适的 scale保存成一个带 scale 的新模型目录vLLM 加载时自动读取。粒度还能细化从逐张量一个 scale 到每个注意力头一个 scale目前只有 Flash Attention 后端支持。8 位终究比 16 位少了一半信息对生成质量影响多大实践的结论是可控的。KV Cache 里的数值分布相对集中8 位量化对生成质量的影响很小这也是各家引擎都敢默认提供这个选项的原因。像默认不量体温直接进考场多数人没事个别的再补测。6.4 什么时候别乱减FP8 也不是在所有情况下都划算官方博客列了几种该留在 BF16或部分留在 BF16的情况6.4.1 上下文很短7k token 以内FP8 每步有一笔固定开销缓存变小的收益随长度线性增长太短就抵不回来这时 BF16 的 token 间隔反而略好。像打车起步价还没跑完就到家了亏。6.4.2 head_dim 为 256 的模型且在意 prefill 延迟为了保证长上下文精度FP8 注意力计算里用了两级累加这笔开销在大头维度下会吃掉 FP8 的算力优势长上下文时 TTFT 最高涨到 1.6 倍。6.4.3 未校准精度持续下移个别模型比如用 FlashMLA 后端的 Kimi-K2.5在 scale 取 1.0 时会出现系统性的精度下降不是随机噪声这时就该用 llm-compressor 在目标数据上校准。6.4.4 混合注意力模型的小滑窗层滑动窗口层的缓存大小有界固定开销摊不回来。这种情况不用放弃 FP8加个参数让滑窗层保持原精度、其余层量化即可$ vllm serve Qwen/Qwen3-0.6B --kv-cache-dtype fp8 --kv-cache-dtype-skip-layers sliding_window7. 显存还是不够搬家到内存分页、共享、量化全用上显存还是装不下怎么办7.1 抢占先踢出去回头重排默认情况下vLLM 的调度器给请求分配不到新的 KV 块时会抢占一部分在跑的请求来腾地方从运行集的尾部开始踢也就是最新加入、优先级最低的请求先被牺牲它们的 KV 块被释放出来其余请求继续跑。被踢的请求回到等待队列等显存有了空位再重新调度上来。V1 引擎默认的抢占方式是重算RECOMPUTE被抢占的请求不留缓存恢复时从 prefill 重新跑一遍。之所以敢直接丢是因为被抢占请求的缓存是还没算完的半成品保存价值不高重算的开销比换出再换回更划算。服务日志里如果出现preempted by PreemptionMode.RECOMPUTE的警告就说明显存开始紧张了该考虑调大gpu_memory_utilization或者收紧上一篇讲的max_num_seqs。像餐馆翻台客人还没吃完就被请出去等会儿再进来重新点一遍菜。7.2 卸载把冷数据搬进车库但不是所有块都适合一丢了之。前缀缓存里的块是算完的成品后面还可能被其他请求反复用到丢了下次就得整段 prefill 重算。对这类有复用价值的块更省的办法是挪到 CPU 内存里存着而不是直接丢掉这就是卸载Offload。vLLM 现在有原生的 CPU 卸载两个参数就能开$ vllm serve Qwen/Qwen3-0.6B --kv-offloading-size64--kv-offloading-backend nativekv-offloading-size指定拿出多少 GiB 内存做卸载缓冲kv-offloading-backend默认native也可以换成lmcache也就是 LMCache 这类外部组件它把卸载做成了完整的多级缓存CPU 内存之后还能再接 NVMe 磁盘和远端存储。像冬天的羽绒服夏天收进柜子要穿再拿出来。比天天挂外面占着客厅强多了。7.3 LMCache缓存界的仓管系统LMCache 是一个开源的 KV Cache 管理层以插件形式挂在 vLLM 这类推理引擎上把 KV 块的存放从 GPU 显存扩展到 CPU 内存、本地磁盘甚至远端存储还支持跨请求、跨引擎的缓存共享。可以理解成给推理引擎外挂一套缓存中间件专门管“东西放哪、谁要用、什么时候清”比你自己手写搬砖靠谱。7.4 卸载主要是给前缀缓存扩容注意卸载主要不是给单个请求扩上下文而是给前缀缓存扩容。被挤出显存的块在内存里仍然挂着 hash后续请求做前缀匹配时可以直接命中到内存里的块省掉的是重算 prefill 的时间。代价是数据要走 PCIe 来回搬运命中内存里的块比命中显存慢但比重算一遍 prefill 快得多。所以它适合当显存之后的第二级缓存而不是主力手段。一级不够放二级二级不够放硬盘妥妥的缓存叠罗汉一层一层往上摞。8. 划重点收工今天这篇围着 KV Cache 的显存管理讲了三个层次1. 问题显存里权重是死的KV Cache 是随负载动态增长的大头。朴素做法按最大长度预留内部碎片、预留浪费、外部碎片加起来浪费 60% 到 80%。2. PagedAttentionvLLM 团队 SOSP 2023 的方案类比操作系统分页把 KV Cache 切成固定大小的块逻辑块经块表映射到不连续的物理块按需分配浪费降到 4% 以内。3. 前缀缓存分页让块可以跨请求共享对块内容算 hash系统提示词、多轮历史这类公共前缀命中后只存一份、只算一遍省显存也省 TTFT。SGLang 的 RadixAttention 用基数树做了更细粒度的共享。4. 量化与卸载KV Cache 存 FP8/INT8 再省一半显存实在不够时把不活跃的块挪到 CPU 内存。四个字总结省、享、瘦、搬。能省的地方省下来能共享的地方共享出去同一块显卡能服务的请求数翻了几倍。显存问题到此闭环。下一个问题是速度每个请求本身还能不能跑得更快量化、投机解码、PD 分离我们下次聊。看完觉得有用点个赞再走别让显存白白流泪。P.S. 目前国内还是很缺AI人才的希望更多人能真正加入到AI行业共同促进行业进步增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 传送门http://blog.csdn.net/jiangjunshow教程通俗易懂高中生都能看懂还有各种段子风趣幽默从深度学习基础原理到各领域实战应用都有讲解我22年的AI积累全在里面了。注意教程仅限真正想入门AI的朋友否则看看零散的博文就够了。
