大模型推理的上下文复用是一笔“用显存买算力”的账：前缀缓存命中时能省下大量重复计算，但缓存本身也在持续吃掉显存，算不清这笔账的人，往往会在长上下文场景里遇到“显卡够大却跑不动并发”的尴尬。
大模型推理上下文复用，显存账到底怎么算
很多人在部署大模型服务时，只知道上下文越长，KVCache占用越大，却忽略了上下文复用机制会把这笔账变得复杂，业内专家指出，理解这笔账的关键在于分清“算力节省”和“显存占用”是两个独立的维度。
KVCache和前缀缓存是两笔钱
传统的推理过程中，系统会把已经算过的历史token的Key和Value向量存下来，这就是常说的KVCache，它的作用是避免每次生成新token时重新计算旧token的中间状态，不开启复用时，这笔KVCache是一次性开销，用完即走。
而上下文复用（Prefix Caching）做的事情，是把KVCache从“用完即弃的临时工”变成“长期驻场的常驻员工”，系统会把用户请求的前缀部分对应的KV状态缓存起来，当后续请求拥有相同前缀时，直接读取缓存结果，跳过整个前缀的预填充（Pre-fill）阶段。
代价由此产生：缓存必须常驻显存，它不像普通KVCache可以在请求结束后释放，而是需要持续占据一块显存，只为等待“命中”的那一刻。
命中率直接决定这笔账是赚是亏
假设你的显卡是80GB显存的A100或H100，不开启复用时，你最多能同时跑几个长上下文请求；开启复用后，系统为了保存缓存块，会预留一部分显存作为KV池,在这部分预留空间里：
- 缓存命中的请求，预填充时间接近零，首token延迟可以降到极低
- 缓存未命中的请求，不仅没有省算力，反而因为KV池挤占了可用显存，导致能同时处理的并发数下降
行业共识认为，在真实业务中，缓存命中率能达到30%到60%已经算非常健康，多数情况下，真正的收益来自少数高频重复的系统提示词、工具定义和几轮固定的对话前缀。
vLLM prefix caching显存开销对比：三种主流方案的取舍
目前主流的推理框架对上下文复用的实现方式各有侧重，显存行为差异明显,这里直接对比最常见的三种方案。
vLLM的prefix caching用KV池换显存峰值
vLLM从0.4版本起引入了prefix caching功能（官方文档中称为Automatic Prefix Caching），它的实现逻辑是：所有历史请求的KVCache先不释放，而是放进一个哈希表中，新请求进来时,按token前缀匹配最长的公共部分。
显存账上的表现是：系统会自动把显存分成“预填充用”和“解码用”两块区域，其中解码区域的KVCache块会被缓存起来，如果缓存内容太多,vLLM会按LRU策略踢掉最久没命中的块。
实际操作中，vLLM的gpu_memory_utilization参数控制显存使用上限，当这个值设得过高，缓存块会挤占正常的解码空间，导致吞吐下降；设得过低，缓存容量不足，命中率上不去，常见实践是设置在85到0.92之间,具体要看请求的重复度。
SGLang的RadixAttention树状复用吞掉更多显存
SGLang采用RadixAttention算法，它将前缀缓存组织成树状结构，能够精细地共享嵌套前缀，比如两个请求的公共前缀是100个token，其中一个继续聊了20轮，另一个聊了30轮,树状结构能比vLLM的线性哈希多保存一些分支缓存。
但代价是：树状结构的分支KV块更碎片化，显存碎片率比vLLM高，在相同显存容量下，SGLang能缓存的总token数通常比vLLM少，但命中粒度更细，如果你的业务是深度的多轮Agent式对话，SGLang的收益更明显；如果主要是简短问答,vLLM的粗粒度缓存就够了。
当显存不够时，缓存会反过来拖累吞吐
很多人在8卡或16卡集群上部署时，以为显存越够用，缓存开着一定更好，但实测中常见的情况是：显存不足时，缓存占用的空间会迫使系统降低batch size，原本一次能处理16个并发请求，为了保住缓存块，实际只能处理8个,整体吞吐反而下降。
这种情况下，理性的选择是关闭缓存或调小KV池比例，判断标准很简单：如果缓存命中率低于20%，且显卡利用率已经接近瓶颈,关掉缓存往往更划算。
上下文缓存适合什么业务场景：从长文档问答到私有化部署
不同场景对这笔显存账的敏感度完全不同，与其纠结理论,不如直接看业务场景。
适合做缓存的场景
- 长文档问答系统：用户对同一份合同、论文、产品手册反复提问，文档内容固定，前缀缓存命中率极高，预填充时间几乎可以忽略
- Agent工具调用链：系统提示词和工具定义占了几千token，每次请求都在前面，缓存这部分，省下的计算量可观
- 私有化部署的固定Prompt场景：比如企业内部的知识库助手，所有员工共享同一套Prompt前缀，命中率天然很高
这些场景的共同点是：高频、长前缀、低多样性，前缀越长，复用价值越大预填充阶段的计算复杂度是token数的平方关系，缓存掉2000个token的公共前缀,比缓存掉200个token省下的算力多得多。
不该做缓存的场景
- 短对话客服机器人：用户问题五花八门，公共前缀通常只有几十个token，缓存收益微薄
- 高并发低显存部署：没有足够的显存冗余来支撑KV池，强开缓存只会降低整体并发
- 流式输出场景中对延迟不敏感的后处理：这类任务本就对首token延迟没要求，省预填充时间没意义
实际部署时怎么把显存账算平：估算与调参步骤
算清楚这笔账不能靠感觉,有一套可操作的流程。
动手前的显存估算
- 确定最大上下文长度：比如业务最长用到32K token
- 算出单请求KVCache峰值：单token的KV大小由层数、头数、维度决定，以7B模型为例，fp16精度下每个token约0.1MB到0.2MB；70B模型则翻数倍
- 估算缓存池容量：假设缓存池预算占总显存30%，用这个数值反推能缓存的最大token数，比如40GB可用显存，预留12GB给缓存池，能缓存约6万到12万个token的KV
- 对比请求流量：如果业务峰值并发需要的token数明显大于缓存池容量，说明缓存策略需要调整
三个值得调的参数
gpu_memory_utilization：vLLM环境下先从0.85起步，观察显存剩余量和命中率变化max_num_batched_tokens：这个值限制单次批量预填充的token总数，会影响缓存块的组织效率- 块大小（block size）：vLLM默认16或32，块越大缓存管理开销越小，但命中粒度越粗，如果公共前缀长度不一致，调小块大小能提升命中率
调参的核心逻辑是盯着两个指标：缓存命中率和有效并发数，命中率上去了但并发数掉得厉害，说明缓存挤占了推理空间；两者同时下降，说明命中率太低,缓存纯属浪费。
另外提一句，多卡环境下的显存规划更要小心，上下文缓存目前主流实现还是按单卡存储，跨卡的分布式缓存方案尚不成熟，因此在多卡部署时，缓存池大小要以单卡的剩余显存为上限来计算,而非简单地把所有卡的显存加起来。
Q&A：上下文复用的显存账常见疑问
大模型推理上下文复用显存占用多少，怎么省？
这没有固定答案，要看模型和上下文长度，一个直观参考：7B模型在4K上下文下，KVCache约0.4GB到0.8GB；32K上下文下约3GB到6GB，开启复用时，这部分开销需要等比例翻倍来预留缓存空间，想省钱，优先选用量化后的KV Cache（如FP8或INT8），能将缓存占用压缩一半,但对命中率的提升没有帮助。
多轮对话和长文档场景，哪个复用收益更大？
长文档场景收益更确定，多轮对话中，每一轮新增的对话内容都会改变前缀边界，实际能复用的公共部分往往集中在系统提示词那一小段，而长文档场景中整个文档都是固定前缀，越大越划算，据统计,长文档场景的命中率通常能达到长对话的3倍以上。
缓存会不会降低回答质量？
不会，复用的KV缓存与重新计算得到的数学结果完全一致，因为模型权重相同、输入相同，前向传播的输出必然是确定的，唯一需要关注的是显存不足时系统可能强制降batch导致的服务延迟,这不影响回答内容本身。