长上下文 LLM 推理为什么越来越贵？这篇 24 页综述把 KV cache 优化的「五大流派」一次性讲清楚了
- 关联论文：2603.20397
你有没有注意到一件事：
- 同一个 ChatGPT，问一句"今天天气怎么样" 和 丢给它一本 50 万字的小说让它总结，后台花的钱可能差出几十倍；
- 你公司想上一套 RAG（Retrieval-Augmented Generation，让模型先检索外部知识再回答）知识库，问答窗口一旦拉到 100K token，GPU 集群账单就直接起飞；
- 你看推理引擎 vLLM、SGLang、TensorRT-LLM 的 changelog，每周都有一批 PR 在改「KV cache」相关逻辑，但你完全听不懂他们在优化什么。
不是你的问题——是这门手艺的「语言」太工程了。
今天这篇科普，用最朴素的话，把一篇 24 页综述（arXiv 2603.20397）讲透：LLM 推理时那条"看不见的内存开销"是什么、为什么它成为长上下文的最大瓶颈、业界五条主流路线各自能砍掉多少成本、2026 年的工程团队到底该怎么选型。
看完你会明白：为什么说"单一最优技术不存在"，自适应多阶段流水线才是正确答案。
一句话抛结论
这是一篇系统性综述，把目前散落在几百篇论文里的 KV cache 优化技术归纳为五大方向——eviction（淘汰）/ compression（压缩）/ hybrid memory（异构内存）/ novel attention（新型注意力）/ combination（组合策略）——并把每条技术映射到 7 类实际部署场景，明确告诉你：「没有银弹」。
最值得记住的核心结论只有一句：
最优策略随上下文长度、硬件和工作负载特性变化，"组合拳"才是实战答案。
KV cache 到底是个什么东西？为什么它能让长上下文这么贵？
我们一步一步讲。
Transformer 类 LLM 在自回归生成时——也就是逐字往外蹦——需要为每一个已经生成的 token 缓存它的 Key / Value 向量（这两份向量是注意力计算里"这位置之前看过哪些上下文"的浓缩记忆）。
为什么要缓存？因为不缓存的话，每蹦下一个字都要把所有历史字重新算一遍注意力，复杂度直接爆炸。
听起来很合理对吧？但撞上了三个硬约束：
- 内存容量：KV cache 的体量随上下文长度线性增长。从千级上下文（早期 GPT）→ 万级（Claude 2）→ 十万级（GPT-4 Turbo）→ 百万级（Claude 3 / Gemini 1.5），光 cache 本身就能把整张 H100 撑爆。
- 内存带宽：自回归解码每生成一个 token，都要读取完整 KV cache。长上下文下，访存（把数据从显存搬到计算单元）才是主要瓶颈，不是计算本身。
- 推理吞吐：cache 越大，单卡能并发的请求数就越少，数据中心 P99 延迟和总成本双双恶化。
工程上因此出现一个尖锐矛盾：
"长上下文"既是 LLM 产品的核心卖点，又是其成本与吞吐的主要拖累。
这就引出了这篇综述真正要回答的问题：在 2026 年这个时间点，工程团队可以从哪几条技术路线里挑组合策略？
五条技术路线，各砍一刀
路线一：Cache Eviction（cache 淘汰）——把不重要的扔掉
核心思路：上下文里很多历史 token 对当前 query 的注意力贡献极小，动态扔掉就行。
代表方法：
- StreamingLLM：保留 attention sink（注意力沉点，即开头几个被所有后续 token 强烈关注的"锚点"）+ 滑动窗口；
- Scissorhands：识别持久重要的 head（某些注意力头总是关注同一批 token）；
- H2O（Heavy-Hitter Oracle）：按累计注意力权重筛选"常驻嘉宾"。
机制都是给每个 token 打一个"重要性分数"，低于阈值或滑出窗口即丢弃其 KV。
工程含义：适合 batch decoding（多个请求同时生成）和长会话场景，但压缩比和下游任务精度通常有 tradeoff（两难取舍）。
路线二：Cache Compression（cache 压缩）——不扔，改表示
不去掉 token，而是改写 token 在 cache 里的数值表示。把高精度存成低精度：
- 量化：把 K/V 矩阵从 FP16（半精度浮点，16 bit 表示一个数）降到 INT4（4 bit 整数）/ INT8（8 bit 整数）/ INT2（2 bit 整数），代表工作如 KIVI、KVQuant；
- 低秩分解：把 K·V 近似成两个小矩阵乘积（用更少的维度近似完整信息），如 ASVD；
- 稀疏化：只保留 K/V 中某些 block 或 channel（只存关键位置）。
机制属于"精度换内存"。通常对 perplexity（困惑度，衡量语言模型预测质量的指标，越低越好）影响有限，但对极长上下文 retrieval 任务可能放大噪声。
重点：4-bit 量化在大多数任务上精度损失 <1%，是性价比最高的入门改造。
路线三：Hybrid Memory（异构内存分层）——承认"cache 不该都放 GPU"
承认一个现实：KV cache 应该一部分在 GPU HBM（高带宽显存），一部分在 CPU 内存、SSD、NVMe。
- 分层方案：hot token（当前频繁访问的 token）放 GPU，cold token（当前用不到的历史 token）spill 到 CPU 内存或 NVMe，代表工作如 FlexGen、InfiniteContext；
- 统一寻址：通过 paging（分页管理）或类虚拟内存接口对上层屏蔽差异；
- 预取 / 异步加载：用 approximate attention（近似注意力）或预计算掩盖访存延迟。
机制上接近 OS 的多级 cache 设计。目标是把单卡可服务上下文长度扩出一个数量级。
百万 token 上下文的现实路径是这条路——纯 attention 算法改造门槛太高。
路线四：Novel Attention（新型注意力机制）——从根上换掉标准 attention
从根上换掉标准注意力，间接把 KV cache 的复杂度从 O(N) 降到 O(1) 或 O(log N)：
- Linear attention（Performer、RetNet）：状态用矩阵替代逐 token 缓存；
- Sparse attention（Longformer、BigBird）：只对部分位置计算注意力；
- State-space / RNN 风格混合（Mamba、RWKV）：把"历史"压缩成定长 state；
- Multi-Query / Grouped-Query Attention：通过共享 K/V 头减少 cache 体积（已用于 PaLM、LLaMA-2 等主流模型）。
机制属于"更便宜的归纳偏置换更省的 cache"。对代码、对话等序列类型有不同适应度。
路线五：Combination Strategies（组合策略）——单一技术吃不下所有场景
最优策略随上下文长度、硬件和工作负载特性变化。这一方向研究的是怎样把 eviction + quantization + offload + sparse attention 等串成流水线：
- 早期 token 用 eviction 砍掉；
- 中段保留的 KV 做 INT4 量化；
- 后段热点再用 kernel-level 加速（底层算子级优化，如 FlashAttention、PagedAttention v2）；
- 跨阶段由一个调度器根据 current workload 自适应切换。
论文的核心 insight 之一就在这里：组合策略才是实战答案。
7 个部署场景的横向映射
论文最有工程价值的地方，是把抽象技术映射到 7 个真实部署场景：
- 长上下文单请求：hybrid memory 最值；
- datacenter 高吞吐：eviction + 量化 + PagedAttention（分页注意力，vLLM 的核心机制）叠加；
- 边缘设备：eviction + INT4 必须一起上；
- 多轮对话：eviction 收益最大；
- 准确率敏感的推理：少砍 KV，多保留；
- 长 code 任务：保持 eviction（代码上下文里很多 token 注意力贡献低），谨慎量化；
- 多模态上下文：单独议题，论文未充分覆盖（这是一个被点名的局限）。
几个被忽视的工程坑
- vLLM 的 PagedAttention 本身是一种 cache 管理策略，不是单纯的 kernel 优化（底层算子加速）。它和 eviction / compression 属于同一优化空间的不同层次，可以叠加使用，不要割裂看待。
- 4-bit 量化需要 calibration（用代表性数据校准量化参数），calibration 数据分布必须与推理分布一致，否则 INT4 精度损失可达 5-10%，而不是论文说的 <1%。校准集建议 1-2GB 代表性数据。
- INT4 + GQA 叠加：70B 模型单卡 KV cache 可从 ~40GB 降至 ~5GB。
- Hybrid memory 的异步 spill 风险：prefetch miss（预取没赶上）会导致 generation 停顿；CPU-GPU 拷贝出错时无自动恢复，需要 application-level retry。
- NVMe 延迟：即使最快的 NVMe，读取延迟也在 50-100μs 量级（vs GPU HBM 1μs）。预取必须提前至少 20-50 tokens 发起才能掩盖延迟。
- KV cache 侧信道攻击：恶意请求可以触发特定 KV block 的 evict，导致后续请求性能退化（一种侧信道 DoS）；KV dump 泄露若包含 PII 也比原始 prompt 更难审查。多租户 SaaS 场景必须加请求级隔离检查。
- 超长上下文（>128K）的 batch 难题：单卡 batch size 趋近于 1，纯靠优化 KV cache 无法解决 1M+ context 的吞吐问题，分布式是必经之路。
当前最实用的工程起点（按性价比排序）
- GQA（Grouped-Query Attention，分组查询注意力）：如果训练新模型，这是零成本、收益最大的决策。推理阶段 KV cache 成本直接 4-8x 缩小。
- vLLM + PagedAttention：已在生产验证，迁移成本低，内存利用率 +1.6-2x。
- INT4 量化（AWQ）：在精度验证通过后叠加，batch size 再翻 2-4x。
- StreamingLLM 滑动窗口：针对长会话场景，memory 增长从线性变为常数。
- Hybrid Memory：需要 1M+ context 且预算允许，再考虑引入。
谁该读这篇
- LLM 推理基础设施工程师：挑选下一步优化方向时必读；
- 平台 / 性能 SRE：理解为何长上下文请求的成本与短文本可能差 10 倍；
- LLM 应用架构师：决定 self-hosted 还是调用 API 前，需理解 cache 成本；
- 科研新人：找 KV cache 优化的入门地图，按五类方向选投哪条线；
- 不太适合：纯应用层 PM、对底层 scheduler 不感兴趣的纯 prompt 工程师——会觉得抽象。
一句话带走
"长上下文"是 LLM 产品的核心卖点，也是最大的成本拖累。2026 年的工程答案不是"挑一种技术用到底"，而是"分层 + 自适应组合"——eviction 处理 80% 重复 token → 量化再砍 4x 内存 → 长尾 cold token 用异构内存 spill。
三个标题变体
- 长上下文 LLM 推理为什么越来越贵？这篇 24 页综述把 KV cache 优化的「五大流派」一次性讲清楚了
- 为什么你的 70B 模型在 128K 上下文下吞吐归零？——一篇综述把 KV cache 优化的"五大流派 + 七个部署场景"全梳理了
- 长上下文是 LLM 的最大卖点，也是最大成本拖累——这篇综述告诉你 2026 年的工程团队到底该怎么选 KV cache 优化路线
小红书风格卡片文案（可直接发布）
📚 为什么你的 LLM 一上长上下文就烧钱？ 📚
你有没有发现——
- 问"今天天气怎么样"和"帮我读这 50 万字小说"，后台花费差出几十倍 💸
- 想自己部署 RAG 知识库？上下文一旦拉到 100K token，GPU 账单直接起飞 📈
- vLLM / SGLang / TensorRT-LLM 每周都在改「KV cache」相关 PR，但你完全听不懂 🤯
别慌，arXiv 2603.20397（24 页综述）把这件事一次讲清楚：
KV cache 是 LLM 推理时那条"看不见的内存开销"——每蹦一个字就要把所有历史字的记忆读一遍，上下文越长，访存成本越爆炸 💥
作者把现有优化技术整理成 五大流派：
1️⃣ Eviction（淘汰）：把不重要的历史 token 直接扔掉 - 代表：StreamingLLM、Scissorhands、H2O 2️⃣ Compression（压缩）：不扔，改用低精度存 - 代表：KIVI / KVQuant（INT4 量化精度损失 <1%） 3️⃣ Hybrid Memory（异构内存）：承认 cache 不该都放 GPU - 代表：FlexGen / InfiniteContext（百万 token 上下文的现实路径） 4️⃣ Novel Attention（新型注意力）：从根上换掉标准 attention - 代表：Mamba / RWKV / RetNet / GQA（已用于 PaLM、LLaMA-2） 5️⃣ Combination（组合策略）：单一技术吃不下所有场景 - eviction + 量化 + 异构内存 + kernel 优化串成流水线 ✨
🔥 核心结论只有一句：
最优策略随上下文长度、硬件和工作负载特性变化，"组合拳"才是实战答案
📊 当前最实用的工程起点（按性价比排序）： - 🥇 GQA：训练新模型零成本、收益最大的决策（KV cache 直接 4-8x 缩小） - 🥈 vLLM + PagedAttention：内存利用率 +1.6-2x - 🥉 INT4 量化（AWQ）：batch size 再翻 2-4x - 🏅 StreamingLLM 滑动窗口：长会话场景 memory 从线性变常数 - 🏅 Hybrid Memory：1M+ context 预算允许再上
⚠️ 几个被忽视的坑： - INT4 量化必须有 calibration 数据，分布不一致损失可达 5-10% - 超长上下文（>128K）单卡 batch size 趋近于 1，纯靠 cache 优化不够，必须分布式 - KV cache 侧信道攻击：多租户 SaaS 场景必须做请求级隔离 - Hybrid memory 的 NVMe 延迟（50-100μs） 是 GPU HBM（1μs）的 50-100 倍，预取必须提前 20-50 tokens
🎯 谁该读： - ✅ LLM 推理基础设施工程师 - ✅ 平台 / 性能 SRE - ✅ LLM 应用架构师（决定 self-host 还是 API 前必看） - ✅ 想找入门地图的科研新人 - ❌ 纯应用层 PM（会觉得抽象）
📎 论文 ID：2603.20397 💬 评论区聊聊：你被长上下文的成本坑过吗？🙋♀️