这两年做大模型应用我踩得最深的坑几乎都和一个词有关上下文。多轮对话跑到第 20 轮长文档才读了一半显存就开始报警响应速度肉眼可见地变慢极端情况下直接 OOM 崩溃。很多人以为只要换一个上下文窗口更大的模型就行可换完之后账单上去了、延迟也上去了问题还在。上下文压缩就是在这种背景下被越来越多人认真对待的一类技术路线。它不改变模型能力本身而是从输入和缓存两个维度给模型“减负”让同样的显存装下更多信息让同样的延迟内输出更高质量的回答。这篇文章我会把我自己从“硬扛长上下文”到“主动压缩上下文”这段过程里学到的东西完整写一遍。包括 KV Cache 到底吃掉多少显存、主流压缩技术各自适合什么场景、具体参数怎么定、以及我实际踩过的坑。内容面向正在做 AI 应用开发、推理服务优化或者对模型内部机制感兴趣的读者我会尽量把每个“为什么”都讲透。1. 上下文为什么成了大模型的“隐形负担”1.1 先算一笔账KV Cache 吃掉了多少显存很多人对上下文开销没有直观概念总觉得“显存不够就加显存”但加了卡也不一定解决问题。先看一组真实计算。假设一个 7B 参数规模的模型结构是 32 层 Transformer 解码器隐藏维度 4096采用 FP16 精度存储 KV Cache。每生成一个 Token每一层都要保存该 Token 的 Key 和 Value也就是 2 个向量每个向量 4096 维每维占 2 字节。单层就是 4096 × 2 × 2 16 KB32 层合计 512 KB。也就是说每生成一个 Token缓存就要增加约 512 KB。这组数字摊开算一下就很吓人上下文 8192 Token 时KV Cache 大约 4 GB而模型权重本身也就 14 GB 上下上下文拉到 32768 Token缓存直接飙到 16 GB比权重还大。要是换成 70B 级别的模型隐藏维度 8192、80 层单 Token 的缓存就超过 2.6 MB128K 长上下文场景下缓存能到几百 GB单张卡根本装不下只能靠多卡流水线硬扛。所以每次有人吹“我们支持百万 Token 上下文”的时候我第一反应不是羡慕而是替他的推理成本担忧。缓存不释放显存就会一直被占着在线服务的并发度直接下降每一路请求的内存成本也翻着倍涨。上下文压缩首先解决的就是这个问题在不明显牺牲回答质量的前提下把缓存和输入塞进更小的空间。1.2 上下文变长不只是显存问题就算你显存很大长上下文还有一个被低估的问题信息密度太低。真实业务里的长文档大部分篇幅是背景介绍、重复描述、格式噪音真正跟当前问题相关的可能只有几句话。模型却要对所有 Token 一视同仁地计算注意力把无关内容也读一遍时间和算力都花在没必要的地方。更麻烦的是模型在超长上下文里容易“迷路”。Transformer 的自注意力虽然理论上能建模任意距离的依赖但实际推理时早期位置的关键信息会被大量无关 Token 稀释。比如一个客服场景用户在第 2 轮说了自己的订单号第 40 轮的回复里模型把订单号张冠李戴就是因为前面的信息在注意力分布里占比太低。这个问题不是模型聪明一点就能解决的它本质上是上下文过长导致的信噪比失衡。延迟也一样。上下文越长每生成一个 Token 需要读取的缓存就越多注意力矩阵的尺寸也越大。市面上各种高效的注意力算子能缓解一部分计算压力但缓存的显存占用和内存带宽瓶颈始终存在。我实测过同样的模型上下文从 4K 涨到 32K首 Token 延迟和后续每个 Token 的生成延迟都是成倍增加而且用户感受到的回答“变笨”往往也发生在上下文很长的时候。1.3 压缩的本质是“信息筛选”那是不是把上下文砍短就行了不行。粗暴截断会把关键信息一起丢掉。上下文压缩真正的核心不是“删减”而是“筛选加重构”——用更少的 Token 保留对后续生成最有用的信息。这个概念可以类比成整理办公桌把一桌子的文件、便签、表格收进一个三层文件架常用材料放第一层偶尔要查的放第二层过期作废的直接碎掉。整理完桌子还是那张桌子但你找东西快了脑子也清爽了。放到大模型场景里压缩发生在两个层面。第一层是物理层面KV Cache 本身就是一组张量可以对它做量化、淘汰、低秩分解在不改变输入 Token 数量的情况下减少存储和计算。第二层是语义层面输入内容本身可以改写把长文档压缩成摘要、要点、或者一组更小的向量表示让模型“看”到的信息不变但 Token 数大幅减少。两层并不互斥。实际生产环境里我通常会把它们组合使用先做语义层面的改写压缩大幅降低 Token 数再做缓存层面的量化淘汰进一步压低显存占用。两层叠加起来往往能把资源开销打到原来的十分之一甚至更低。2. 上下文压缩的主流技术路线2.1 KV Cache 量化直接给缓存“降分辨率”先说最容易理解也最实用的一条路KV Cache 量化。原理跟模型权重量化一样把 FP16 的 Key 和 Value 张量转成 INT8 甚至 INT4 存储计算时再反量化回高精度。FP16 转 INT8缓存直接减半转 INT4再砍一半。前面算的 7B 模型 32K 上下文需要 16 GB 缓存INT8 后降到 8 GBINT4 后只有 4 GB效果相当直接。但量化不是简单地“把 float 塞进 int”里面有细节。最重要的一步是校准需要准备一组有代表性的数据统计每层 Key、Value 张量的数值范围然后确定量化缩放因子。校准集跟真实业务数据差异太大量化的误差会非常明显。INT8 一般还好INT4 对数值范围更敏感经常需要按通道或者按 128 个元素分组做量化把局部数值范围控制住。实际使用中我的体感是KV Cache 量化对多数任务损失很小因为它针对的是缓存张量不像权重量化那样影响所有计算路径。但有一个坑——长上下文的误差累积。Token 越多反量化引入的小误差就一层层叠加上去到最后几层的时候注意力分布可能已经偏离正常值。所以做长上下文场景时我会给量化加一点保护比如对前几层的缓存保持高精度只量化后面层或者混合用不同位宽。2.2 缓存淘汰保留哪些 Token 才不丢记忆量化是“降低每个 Token 的存储成本”淘汰策略则是“直接决定哪些 Token 不值得继续留缓存”。这一类方法很多核心思想都来自一个观察长上下文里每个 Token 对后续生成的重要性差异巨大有些 Token 几乎不会被再次关注留着纯属浪费。最早一批工作提出的是根据注意力分数淘汰。模型在历史上下文上计算注意力时那些被多次关注、累积注意力分数很高的 Token称为重要 Token必须保留累积分数低的 Token 可以大胆丢。听起来合理但我自己复现的时候发现一个问题单次注意力分数高不代表长期重要有些 Token 只在某一步被突然关注一次之后就再也没人理。实践中我会用累积注意力在多个解码步上累计得分来判断而不是只看单步这样判断更稳。另一类思路是位置维度的保留策略。学术界有一类很知名的观察序列开头的若干 Token 和最近一段窗口里的 Token 在绝大多数任务里都承担了重要角色。开头 Token 承载了全局主题、指令信息最近 Token 承载了当前讨论焦点。所以一个极简且有效的策略是保留固定数量的开头锚点 Token保留最近 N 个 Token中间的“历史中段”按注意力分数逐步淘汰。这个方案工程上非常好落地因为不需要什么复杂打分模块直接按位置裁剪就行。淘汰策略的最大优势是零额外模型开销纯工程手段推理框架改动也不大。风险在于信息是硬删除一旦关键内容被淘汰就找不回来。所以设计淘汰策略时我总是留一个“安全边际”宁可多留一点也不要激进到让模型彻底丢失早期关键事实。2.3 上下文改写把“原文”变成“摘要”真正实现“大幅压缩”的路线是语义级的上下文改写。思路很简单用一个额外的语言模型或者专门的压缩模块先把长文档读一遍产出压缩后的形式再把这个压缩结果喂给主模型。压缩后的形式可以是 200 字的摘要、若干条要点、或者抽取出的关键实体和事件也可以是训练出来的连续向量也就是通常说的 Soft Prompt。这条路我最早是从处理长文档问答开始的。客户给了一本几十页的产品手册直接全部塞进上下文一次对话就把窗口占满了。后来我改成先跑一次摘要把手册压成两页纸的“精简版”再带着问题和精简版一起进主模型。实测 Token 数能降到原来的十分之一到二十分之一回答质量在大多数问题上没有明显下降。但是得说清楚代价摘要天然会丢细节。如果一个用户的问题是“手册里第 18 页右下角那个参数的单位是什么”摘要可能根本没有保留这个参数模型只能瞎猜。所以我现在的建议是上下文改写适合整体理解型任务不适合需要逐字精确检索的任务。后者要么走下面的检索裁剪要么保留一个可检索的全文索引。Soft Prompt 路线更进一步把压缩结果直接编码成向量不经过离散 Token。好处是压缩比更高理论上信息保留更完整。坏处是工程复杂度高一般需要针对特定模型做训练或微调对应用层开发者不够友好。目前我看到的生产级实践不算多属于值得关注但入坑成本明确较高的方向。2.4 检索裁剪让模型只看该看的部分严格说检索裁剪不算压缩但它的目标效果跟压缩完全一致控制进入模型的 Token 数量。做法是先对长文档切块、做向量化用户提问后把问题也向量化通过相似度检索把最相关的几个段落挑出来拼接成精简上下文喂给模型。整个流程跟大家熟悉的检索增强生成RAG几乎一样。我之前一直把 RAG 和上下文压缩当成两件事后来发现它们应该结合着用。RAG 负责“选对材料”上下文压缩负责“把选出来的材料再压一压”。比如一个客服知识库可能有几百篇文档RAG 先挑出 5 段最相关的然后我可以对这 5 段做改写压缩把整体 Token 再降一半。两件事叠加效果比单独用任何一种都好。检索裁剪的短板在于检索质量本身。向量相似度高不代表语义上真正相关有时挑出来的段落恰恰缺了最关键的一句话。所以做知识库型应用时我会在检索环节多花功夫调整切块大小、尝试不同的 embedding 模型、加上关键词召回作为补充而不是把宝全押在向量检索上。压缩解决的是“怎么省”检索解决的是“怎么选”前者不能弥补后者的失误。3. 实操如何为一个模型设计上下文压缩方案3.1 压缩前的收益估算动手之前先回答三个问题当前瓶颈是什么压缩目标是什么场景适合哪条路线先看瓶颈。用监控工具看推理服务的显存峰值、平均延迟、每路请求的缓存大小。如果显存是瓶颈优先做 KV Cache 量化和淘汰如果延迟是瓶颈优先做语义压缩和检索裁剪因为减少 Token 数对注意力计算量的削减是最直接的。再算目标。比如当前模型是 7B 规模32K 上下文里缓存占 16 GB目标是把在线服务的并发度从 4 提到 8那就需要把单请求显存降到 8 GB 以下。INT8 量化就能达标不一定需要更激进的 INT4 加淘汰。目标越明确方案越保守后面返工的概率越低。最后看场景。我习惯按下面这个粗规则分路场景特征首选路线补充手段单篇长文档整体理解上下文改写压缩KV 量化多轮对话、状态持续累积缓存淘汰加锚点保留KV 量化多文档知识库问答检索裁剪上下文改写超长 Agent/工具调用循环组合使用改写加淘汰INT8/INT4 量化这个表格只是起点不是标准答案但它能帮你在面对一团乱麻的工程需求时先找到下刀的地方。3.2 关键参数怎么选路线定了之后真正花时间的是参数调试。我把自己常用的参数起点列一下供参考。KV 量化方面先用 INT8 起步group size 设 128如果显存还紧张再试 INT4但要把校准集从 1 份扩到至少 3 份不同来源的业务数据。淘汰策略方面锚点 Token 数建议 20 到 50 个滑窗最近上下文保留 2000 到 4000 个 Token淘汰打分用累积注意力分数淘汰阈值初始设在能保留 70% 缓存量的位置再逐步收紧。上下文改写方面压摘要时目标长度设为原文档的 10% 左右超长文档可以分层做先每章摘要再章节摘要汇总。检索裁剪方面切块大小 512 Token 配 128 重叠是多数场景下不容易出错的起点Top-K 从 5 开始调。这些参数的核心逻辑都是同一个留足信息冗余。压缩做得太狠指标难看再一点点收紧。宁可多花一周调参也不要第一天就把 32K 压到 1K第二天客户投诉回答开始胡说。3.3 一套可落地的实施流程我会把整个实施流程拆成七步每一步都有明确的产出物。第一步是性能画像。跑一批有代表性的请求记录不加任何压缩时的显存峰值、延迟和成功率作为基线。第二步是建立评测集。至少准备三个维度长文档问答考事实保留、多轮对话考指代跟踪和记忆、短对话基线考通用能力有没有被压缩方案破坏。第三步选定主路线按上面的场景表来。第四步实现原型先用最小改动版本比如先只加 INT8 量化跑通全流程再说。第五步校准和调参量化的校准集要贴近真实数据淘汰的阈值要对照评测集调整。第六步做完整评测对比压缩前后的显存、延迟和任务完成度确定收益和损失都在可接受范围。第七步灰度上线先在低流量环境跑一段时间收集真实案例回归。这个流程看着笨但它能把“压缩后效果变差”这类问题提前挡在上线之前。我吃过亏——早期跳过评测集直接上线结果线上模型开始漏关键信息回滚之后老老实实补了评测环节。3.4 评测体系别被困惑度骗了做压缩的人容易陷入一个误区只看困惑度PPL。困惑度是语言模型对下一个 Token 预测的置信度指标压缩后缓存变了PPL 轻微上涨是正常的。问题在于PPL 只是轻微上涨任务能力可能已经崩了。我做过一次对比把长文档压缩到 20% 后PPL 只涨了 0.3但文档问答的准确率从 92% 掉到 61%。如果只盯 PPL我会得出“压缩没有损失”的错误结论。所以评测一定要围绕任务本身。我给压缩方案定了一套最小评测集指代消解类问题比如“刚才提到的那个订单后来怎么样了”事实抽取类比如“文档里指定的截止日期是哪天”数值计算类比如“三个项目各自的预算加起来是多少”以及长对话记忆类比如“用户在第 3 轮提到的偏好到第 30 轮还能不能正确引用”。每个维度跑 50 条以上样本对比压缩前、压缩后的准确率差距超过 5 个百分点就要警惕。显存和延迟也要量化。我会记录峰值显存、平均每 Token 生成延迟、首 Token 延迟、以及内存带宽利用率。只有收益明确显存降幅明显、并发提升且损失可控任务准确率降幅可接受的方案才值得留下。4. 踩坑实录与问题排查4.1 压缩后模型像“失忆”这是我遇到最多的一类问题。现象很典型多轮对话压过之后模型时不时忘了用户早前提过的信息。用户说“我姓王叫我王老师就行”聊了二十轮后模型开始称呼“李先生”。排查了几次之后我确认问题出在缓存淘汰策略把开头几轮的 Token 全部清掉了。模型不是真的“忘记”而是承载那段记忆的缓存被物理删除了。解决办法有两种。一种是在淘汰时保留锚点 Token把序列开头的关键信息一直留在缓存里另一种更稳的做法是“记忆外置”在对话过程中周期性生成一段摘要状态比如每五轮把当前对话关键信息提炼成几条要点放进缓存头部淘汰时优先保护这部分。我后来在正式项目里用的是后者因为纯靠开头锚点保留不了那些分散在对话中段的关键事实。排查这类问题时我的建议是先复现再怀疑。用同一个问题走压缩与非压缩两条路径对比输出差异再把压缩开关逐个关闭定位到是量化、淘汰还是改写造成的。一次只动一个变量别同时调三个参数否则出了问题根本不知道怪谁。4.2 阈值设置引发连锁反应淘汰阈值是一个非常敏感的参数。阈值设得太松缓存没省多少方案白做阈值设得太紧大量 Token 被误杀模型回答质量迅速恶化。最典型的问题表现是压缩后回答变得“笼统”和“含糊”详细程度明显下降。原因就是模型用来支撑细节的事实 Token 被淘汰得太多它只能靠泛化能力硬撑输出自然变得空泛。一个让我印象深刻的坑是不同层的淘汰要区别对待。浅层注意力更多处理局部语义深层注意力更多聚合全局信息用同一个阈值去切所有层深层的关键信息经常先被误杀。调整之后我把策略改成深层网络用更宽松的淘汰比例浅层网络用更激进的淘汰比例整体效果立刻改善。这个细节在很多开源实现里没有直接暴露需要自己动手调。排查这类问题可以盯注意力分布的热力图。把压缩前后的注意力图对比一下如果发现某个位置本该有的高注意力区域消失了基本就能确定淘汰策略误伤了重要 Token。这种可视化手段比单纯看准确率数字更直观也更方便定位是哪一层出的问题。4.3 量化叠加淘汰的坑单独做量化和单独做淘汰都能跑通但两个一叠加问题就来了。我有一次在 INT4 量化之上再加淘汰策略结果显存降得很多但回答质量出现偶发性的剧烈波动。排查下来发现先把缓存淘汰掉一部分之后剩余 Token 的数值分布发生了变化而量化校准是在未淘汰的完整分布上做的两者不匹配导致反量化误差被放大。正确做法是先淘汰、后量化。先确定哪些 Token 会被保留再用保留后的数据分布去做量化校准这样误差最小。另外校准数据集要多准备几组覆盖不同的上下文长度和主题分布。我后来最少用三组数据做校准短对话、长文档、混合场景量化误差的波动基本消失了。还有一个数值层面的坑INT4 量化之后部分通道的数值范围超出预期导致溢出。解决办法是统计 scaler 的时候加一个安全系数把量化范围稍微放宽一点而不是贴着最大值用。别看这是个小细节线上跑久了遇到极端输入就可能炸出异常回答。4.4 多种注意力实现在这里打架现代推理框架普遍引入了各种优化的注意力计算算子这些算子和压缩方案之间经常出现兼容性问题。最典型的例子是淘汰策略需要修改注意力计算的掩码逻辑而很多高性能算子为了最大化吞吐对掩码格式有固定假设你改了缓存结构它要么报错要么悄悄回退到慢速实现性能收益直接归零。另一个隐蔽问题是位置编码。Transformer 的位置信息是编码在 Token 里的如果压缩方案丢弃了部分 Token剩余 Token 的位置索引应该保持原始位置而不是重新从 1 开始编号。很多第一次做淘汰实现的人容易在这里翻车重新编号之后模型对距离和顺序的感知整个乱掉回答质量莫名其妙地下滑。你需要确保缓存的末尾位置信息被正确传递。我的建议是在动手改缓存逻辑之前先把你使用的推理框架的注意力算子文档通读一遍确认它对掩码、缓存结构、位置编码的支持方式。很多人一上来就对着源码加自己的淘汰逻辑最后卡在框架层面对不齐时间全耗在调试底层接口上。先跑通最朴素的实现确认业务效果没问题再考虑引入高性能算子优化这个顺序能省掉大量排查时间。5. 一些只有上手才知道的细节最后分享几个我在实际项目中反复验证过的小经验都是文档里不太会写的内容。第一个经验不要一上来就追求极限压缩比。20 倍的压缩听起来很酷但带来的信息损失往往在你不注意的地方突然冒出来。比较务实的做法是先做 2 到 4 倍的压缩跑稳了再逐步加码每一步都有评测数据把关。压缩收益和损失的关系不是线性的通常压到 5 到 10 倍左右还能保住大部分质量再往下损失就会陡增。知道这个拐点在哪里你的方案才能真正进入生产。第二个经验压缩策略必须跟着业务场景走。同一个模型客服场景和文档分析场景需要完全不同的压缩组合。客服场景的关键是多轮记忆要保住用户画像和早期约定文档分析场景的关键是内容完整性要保住结构、结论和数字。我见到很多团队的失败不是因为技术不够强而是拿一个通用压缩组件直接套到所有业务上结果每个业务都在某个维度上受损。第三个经验上线后一定要持续回归。压缩方案不是上线就完事的。线上数据分布会漂移今天跑得好的校准集可能两个月后就不匹配了。我现在的做法是每周抽一批线上真实请求跑一遍压缩和非压缩的对比评测数据有异常立刻告警。这套机制看起来繁琐但帮我在早期拦下过好几次回退事故。最后一个技巧用压缩省下来的算力去换更好的生成质量。我见过不少团队把压缩省下来的显存拿去堆并发这当然是合理的但还有一个更有价值的用法——省下来的上下文空间可以用来放思维链推理、放更多示例提示、放外部工具返回的结果。模型的回答质量往往比省下的那点延迟更值钱。上下文压缩真正的意义是让你在有限资源里装下更多对回答有价值的东西而不是单纯地让系统变得更省。
)
)
)
)
)
