第3章-上下文与缓存

第 3 章 · 上下文与缓存

导读：在 AI 对话引擎里，最贵的从来不是网络带宽，而是你把多少 token 一遍遍喂给 GPU。上下文越长，prefill 越慢、KV Cache 越胀、显存越紧张；而真实流量里，绝大多数请求其实都在重复问相似的问题、重复读相似的上下文。本章要做的，就是用「多级缓存」和「上下文压缩」这两把刀，把重复计算砍掉一大半——这是整套架构里投入产出比最高的降本杠杆。

为什么是这一章

把一座百万级 QPS 的对话引擎拆开看，成本结构出奇地集中：推理集群的算力开销占据了运营成本的绝对大头，而推理开销的核心驱动因素又是两个——「被喂给模型的 token 总数」和「这些 token 被重复算了多少遍」。

第一章我们校准了 QPS 口径，第二章我们在接入层把流量「挡」在了门外（限流、降级、排队）。但挡住的是「不该进来的请求」，进来的请求依然要算。本章换一个角度：让该进来的请求，算得更少、更省。这里有两个最直接的抓手：

• 缓存：把已经算过的结果、已经 prefill 过的 KV 状态留下来，下次相似请求直接复用，跳过昂贵的计算。
• 上下文压缩：在把 token 喂给模型之前，先把冗余、陈旧、可检索的部分裁掉，用最少的 token 保住回答质量。

这两个抓手本质上是同一件事的两面——都是在「减少重复计算」。缓存是时间维度的复用（同一份结果不重算），压缩是空间维度的精简（同一份上下文不重复塞）。二者配合，能把推理集群的压力砍掉一两成甚至更多：经验上，缓存整体命中率每提升 10 个百分点，约可省下 10% 的算力。

本章路线图

• 3.1 多级缓存设计：讲透结果缓存、前缀 KV 缓存、语义缓存这三级缓存，以及它们如何串成一道「命中率漏斗」，让每一层都替下一层削掉一部分成本和延迟。
• 3.2 上下文压缩与窗口管理：讲透滑动窗口、对话摘要、RAG 按需检索与上下文预算，把有限的上下文窗口用在刀刃上，避免多轮对话和长文档把显存撑爆。

读完这两节你会明白：缓存和压缩不是「锦上添花的可选优化」，而是百万级对话引擎能不能「算得起」的生死线。我们也会点出几个 90% 的人都会踩的坑——比如前缀缓存命中率为 0 的经典悲剧，以及只做滑动窗口导致的「长程依赖断裂」。