从KV Cache到Prompt Cache的应用

引子

从工程师的视角来观察，随着Scaling Law失效问题被更多的人提起，我越来越认同LLM正在逐渐进入「精打细算，收个果实的平庸时代」。Andrew Ng在他的感恩节给读者的来信中提到，AI可能存在泡沫但是一定不是在AI应用开发：

• AI 应用层： 投资不足。其潜力远超大多数人的认知。
• AI 推理基础设施： 仍需大量投资。
• AI 模型训练基础设施： 我对这一领域仍持谨慎乐观态度，但可能存在泡沫。

1. 大模型推理的物理瓶颈：透视KV Cache

在探讨具体的优化技术之前，必须从第一性原理出发，理解为何KV Cache会成为大模型推理的阿喀琉斯之踵。这不仅是显存容量的问题，更是显存带宽（Memory Bandwidth）与计算强度（Arithmetic Intensity）之间矛盾的体现。

1.1 Transformer解码的自回归特性

Transformer模型的推理过程分为两个阶段：预填充（Prefill）和解码（Decoding）。

1. 预填充阶段（Prefill）：模型并行处理输入的所有token。由于可以并行计算，这一阶段主要受限于GPU的计算能力（Compute-bound）。此时，GPU的利用率通常很高。
2. 解码阶段（Decoding）：模型逐个生成后续token。这是一个自回归（Autoregressive）过程，即生成第 $t$ 个token需要依赖于前 $t-1$ 个token的内部状态。

在标准的注意力机制（Self-Attention）中，计算公式为：

$$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$
其中，$Q$（Query）是当前时间步的查询向量，而 $K$（Key）和 $V$（Value）则包含了所有历史token的信息。为了避免在生成每一个新token时都重新计算前面所有token的 $K$ 和 $V$ 投影，系统会将这些计算好的向量存储在显存中，这就是 KV Cache。

1.2 显存占用的数学推导

KV Cache的显存占用量是序列长度的线性函数，且随层数、头数和隐藏层维度倍增。对于一个标准的Transformer模型，其KV Cache的大小可以通过以下公式精确计算：

$$ \text{Size}{KV} = 2 \times L{seq} \times B_{batch} \times N_{layers} \times H_{heads} \times D_{head} \times P_{prec} $$

其中：

• $2$：代表Key和Value两个矩阵。
• $L_{seq}$：当前的序列长度（上下文窗口大小）。
• $B_{batch}$：并发请求的批处理大小（Batch Size）。
• $N_{layers}$：Transformer的层数。
• $H_{heads}$：注意力头的数量。
• $D_{head}$：每个注意力头的维度（通常为 $D_{model} / H_{heads}$）。
• $P_{prec}$：数据精度（FP16为2字节，FP32为4字节）。

案例分析：Llama-2 70B模型
假设我们使用FP16精度（2字节），序列长度为4096，Batch Size为1。

• $N_{layers} = 80$
• $H_{heads} = 64$ (GQA之前)
• $D_{head} = 128$

单次请求的KV Cache大小为：

$$2 \times 4096 \times 1 \times 80 \times 64 \times 128 \times 2 \approx 10.7 \text{ GB}$$
如果我们将上下文扩展到100k tokens（如Claude或GPT-4 Turbo常见场景），单次请求的KV Cache将膨胀至 260 GB。这已经远远超过了单张NVIDIA A100 (80GB) 甚至 H100 (80GB) 的显存容量。这意味着，在长文本场景下，显存容量直接限制了Batch Size，导致GPU的算力无法被填满，推理成本急剧上升。

1.3 内存墙与带宽瓶颈

除了容量限制，更致命的是带宽限制。在解码阶段，每生成一个token，GPU都需要从高带宽内存（HBM）中读取整个KV Cache到片上SRAM进行计算。

• 计算量（FLOPs）：随着KV Cache的增长，计算量仅线性增长。
• 数据传输量（Bytes）：数据传输量也线性增长，但由于矩阵乘法中的一维退化为向量（Query vector），算术强度（Arithmetic Intensity，即FLOPs/Bytes比率）极低。

现代GPU（如H100）具有极高的算力（~1000 TFLOPS FP16）和极高的带宽（~3.35 TB/s）。然而，在解码阶段，由于每次矩阵向量乘法（GEMV）都需要搬运庞大的KV Cache，GPU大部分时间都在等待数据从HBM传输，导致计算单元闲置。这就是所谓的“内存受限”（Memory-bound）场景。

为了缓解这一问题，业界在过去两年中经历了从算法架构改革到系统工程优化的剧烈演变。

2. 注意力机制的架构演进：从MHA到MLA

为了从根本上减小KV Cache的体积，模型架构师们对Transformer的核心——注意力机制进行了多次手术。这一演进路径清晰地展示了从追求极致性能到追求效率与性能平衡的过程。

2.1 多头注意力（MHA）：昂贵的基准

在《Attention Is All You Need》原论文中提出的多头注意力（Multi-Head Attention, MHA）机制中，模型拥有 $H$ 个查询头（Query Heads），同时也对应拥有 $H$ 个键值头（Key/Value Heads）。

• 机制：每个Query Head都有自己独立的Key和Value投影矩阵。这意味着模型可以从 $H$ 个不同的子空间（Subspaces）捕捉信息，理论上表达能力最强。
• 代价：正如第1节中的计算所示，KV Cache的大小与头数 $H$ 成正比。对于大模型，这意味着巨大的显存开销。
• 现状：早期的BERT、GPT-2、GPT-3以及Llama-1均采用MHA。但在长上下文时代，MHA已成为不可承受之重。

2.2 多查询注意力（MQA）：激进的压缩

为了解决推理性价比问题，Noam Shazeer在2019年提出了多查询注意力（Multi-Query Attention, MQA）。

• 机制：无论有多少个Query Heads，整个层只保留1个 Key Head 和 1个 Value Head。所有的Query Heads共享这唯一的KV对。
• 压缩比：$H : 1$。如果模型有64个头，KV Cache的大小直接缩小64倍。
• 优势：极大地减少了显存占用和数据搬运量，使得推理速度显著提升，且能支持更大的Batch Size。
• 劣势：这种压缩过于激进，导致模型在处理复杂任务时，无法同时关注输入序列的不同方面，造成性能（Perplexity）下降和训练不稳定性。
• 应用：Google的PaLM模型和Falcon系列采用了MQA，但在开源社区并未立刻成为主流。

2.3 分组查询注意力（GQA）：中庸之道的胜利

在Llama-2发布时，Meta引入了分组查询注意力（Grouped-Query Attention, GQA），这一机制迅速成为当今开源大模型（如Llama-3, Mistral, Qwen）的实际标准。

• 机制：GQA是MHA和MQA的折中方案。它将Query Heads分为 $G$ 个组，每个组内的Query Heads共享一个KV Head。
• 配置：例如，Llama-2 70B使用了8个KV Heads（$G=8$），而Query Heads为64个。这意味着每8个Query Heads共享1个KV Head。
• 压缩比：$H : G$。在上述例子中，压缩比为8:1。
• 效果：研究表明，GQA在显存占用和推理速度上接近MQA，而在模型效果（Accuracy/Perplexity）上几乎等同于MHA。它成功地在帕累托前沿（Pareto Frontier）上找到了最佳平衡点。

2.4 多头潜在注意力（MLA）：DeepSeek的架构革命

DeepSeek-V2（及其后的V3）引入的MLA（Multi-Head Latent Attention）不仅仅是分组策略的调整，而是对KV Cache存储方式的根本性重构。这是DeepSeek能够提供极低API价格的核心技术支撑。

2.4.1 低秩矩阵压缩（Low-Rank Compression）原理

传统的注意力机制直接存储投影后的 $K$ 和 $V$ 矩阵，维度为 $d_{model} \times L$。MLA认为这些高维矩阵中存在大量的冗余信息，可以通过低秩分解来压缩。MLA不直接存储 $K$ 和 $V$，而是将输入的隐藏状态投影到一个低维的“潜在向量”（Latent Vector, $c_{KV}$）。

• 压缩：输入向量首先经过一个下投影矩阵，变为极低维度的潜在向量（例如，压缩比可达数十倍）。
• 存储：在KV Cache中，只存储这个压缩后的潜在向量。
• 还原：在计算注意力分数时，通过一个上投影矩阵，将潜在向量实时还原为用于计算的Key和Value。

这种方法将KV Cache的显存占用从 $O(H \times d_{head})$ 降低到了 $O(d_{latent})$，其中 $d_{latent}$ 远小于前者。

2.4.2 解耦旋转位置编码（Decoupled RoPE）

低秩压缩的一个巨大挑战是如何兼容旋转位置编码（RoPE）。RoPE对向量的旋转操作具有几何敏感性，直接在压缩向量上应用RoPE会破坏其位置信息，或者在还原时引入巨大误差。

DeepSeek创造性地提出了“解耦RoPE”策略：

1. 内容头（Content Head）：负责捕捉语义信息，采用上述的低秩压缩（不带RoPE）。
2. 位置头（Position Head）：一个单独的、维度很小的向量，专门用于携带RoPE位置信息。
3. 拼接（Concatenation）：在计算Attention Score时，将还原后的内容头与位置头拼接，共同参与计算。

通过这种方式，MLA既实现了极致的KV Cache压缩（仅存储压缩内容+少量位置信息），又完美保留了长上下文所需的位置感知能力。根据DeepSeek的报告，MLA使得KV Cache的大小在同等参数规模下只有GQA模型的1/5甚至更低，这使得将KV Cache放入显存之外的介质（如内存或SSD）成为可能，因为数据传输的带宽压力被大幅减轻了。

3. 系统级显存管理与优化：从分页到流式

如果说Transformer架构决定了KV Cache的“理论最小体积”，那么系统软件则决定了如何在物理硬件上高效地“摆放”这些数据。2023年以来，以vLLM为代表的推理框架通过引入操作系统领域的经典思想，彻底改变了显存管理的范式。

3.1 显存碎片化与PagedAttention (vLLM)

在vLLM出现之前，主流推理框架（如FasterTransformer）采用的是静态显存分配。对于一个请求，系统必须按照其“最大可能长度”（Max Sequence Length）预先分配一块连续的显存空间。

• 内部碎片（Internal Fragmentation）：如果预分配了2048长度，但用户只生成了50个token，剩余的空间全部被浪费。
• 外部碎片（External Fragmentation）：不同请求的显存块大小不一，导致显存中出现许多无法被利用的空隙。

据统计，这种方式导致的显存浪费率高达60%-80%。

3.1.1 PagedAttention的原理

vLLM团队受操作系统虚拟内存（Virtual Memory）分页机制的启发，提出了PagedAttention。

1. KV Block：将KV Cache切分为固定大小的块（Block），例如每块存储16个token的KV数据。
2. 非连续存储：这些Block在物理显存（HBM）中不需要连续存放，可以分散在任意位置。
3. 页表（Block Table）：系统维护一张映射表，记录每个请求的逻辑token顺序对应哪些物理Block。
4. 按需分配：只有当新的token生成填满当前Block时，系统才申请下一个Block。

优势：

• 零浪费：内部碎片仅存在于最后一个未填满的Block中，浪费率降至4%以下。
• 显存共享（Memory Sharing）：这是PagedAttention最强大的特性。对于这就如Python中的引用计数，如果多个请求共享相同的System Prompt（例如“你是一个有用的助手...”），vLLM只需在物理显存中存储一份该Prompt的KV Block，所有请求的页表都指向这一份数据。只有当各自生成不同的后续内容时，才触发“写时复制”（Copy-on-Write）。这为由Prompt Cache奠定了系统基础。

• 并行采样（Parallel Sampling）：在 Parallel Sampling 中，同一个 prompt 会生成多个候选输出，便于用户从多个备选中选择最佳响应，常用于内容生成或模型对比测试。在 vLLM 中，这些采样序列共享相同的 prompt，其对应的 KV Cache 也可以共用同一组物理块。PagedAttention 通过引用计数和 block-level 的 copy-on-write 机制实现共享与隔离的平衡：只有当序列出现不同分支时，才会触发复制操作。

3.2 动态前缀复用与RadixAttention (SGLang)

虽然vLLM解决了分配问题，但在处理复杂的、非线性的对话历史时，如何自动发现可复用的KV Cache仍是难题。SGLang框架提出了RadixAttention，将缓存管理提升到了一个新的维度。

3.2.1 Radix Tree（基数树）结构

SGLang不再将KV Cache视为线性的数组，而是将其维护为一个基数树（Radix Tree）。

• 节点：树的边代表token序列，节点代表KV Cache的状态。
• 路径：从根节点到叶子节点的路径代表一个完整的对话历史。

Hash RadixAttention 代码走读：

3.2.2 自动复用机制

当一个新的请求到达时，系统将Prompt作为搜索键在Radix Tree中进行最长前缀匹配（Longest Prefix Match）。

• 场景A（多轮对话）：用户问“A”，模型答“B”。用户接着问“C”。RadixAttention自动匹配到“A->B”的路径，直接复用其KV Cache，只需计算“C”。
• 场景B（Few-Shot Learning）：多个请求使用相同的Few-Shot示例，但在最后的问题上不同。RadixAttention自动锁定公共前缀节点，无需人工干预。
• LRU淘汰：当显存不足时，系统根据最近最少使用（LRU）原则，从叶子节点开始剪枝，释放显存。

prefix hash 代码走读：

与vLLM早期的前缀缓存相比，RadixAttention无需用户手动配置，且能处理更复杂的分支结构（如Tree-of-Thoughts推理），显著提高了复杂Agent任务的吞吐量。

3.3 无限流式生成与StreamingLLM

对于需要7x24小时运行的数字人或长期助理，KV Cache理论上会无限增长直至显存溢出。简单的“滑动窗口”（Sliding Window，只保留最近N个token）会导致模型崩溃，因为Transformer在训练时并未适应这种信息的突然截断。

3.3.1 注意力汇聚（Attention Sink）现象

MIT的研究人员发现，Transformer模型在推理时，会倾向于将大量的注意力分数分配给序列开头的几个token（通常是前4个）。这些token充当了“锚点”（Anchor），稳定了后续层的注意力计算，即使它们本身可能没有太多语义信息。

3.3.2 StreamingLLM机制

基于上面的发现，StreamingLLM提出了一种特殊的缓存策略：

1. 保留汇聚点：永久保留序列开头的几个token（Attention Sinks）的KV Cache。
2. 滑动窗口：对后续的token使用滑动窗口，只保留最近的N个。
3. 位置编码调整：对RoPE进行相对位置的平移，使模型感知到正确的距离。

这种方法使得模型可以在有限的显存（例如只缓存2048个token）下，处理长度达到400万甚至无限的输入流，且困惑度（Perplexity）不发生爆炸。

4. 极致压缩：KV Cache量化技术

除了架构和系统优化，降低数据本身的精度是另一个维度的压缩手段。KV Cache量化（Quantization）正从研究走向生产环境。

4.1 精度格式的演变

• FP16/BF16：传统的基准，每个参数2字节。
• FP8 (E4M3/E5M2)：NVIDIA H100原生支持。将KV Cache压缩到1字节/参数。vLLM和TensorRT-LLM已经支持FP8 KV Cache，通常能带来2倍的吞吐量提升，且精度损失微乎其微。

4.2 激进量化：INT4与非均匀分布挑战

将KV Cache压缩到4-bit（INT4）可以将显存占用减少4倍，但这面临巨大挑战。

4.2.1 异常值（Outliers）问题

研究发现，Key和Value矩阵中的数值分布并非均匀的高斯分布。特定的通道（Channels）或Token会出现数值极大的异常值。如果使用标准的均匀量化（Uniform Quantization），这些异常值会拉大量化范围（Range），导致大部分小数值的精度被严重吞噬，模型彻底失效。

解决方案：

1. SmoothQuant / Atom：引入平滑因子，将激活值（Activation）中的异常值迁移到权重（Weight）中，或者在量化前对通道进行缩放（Per-channel scaling），使得分布更平滑，适合INT8/INT4量化。
2. KIVI / KVQuant：采用非均匀量化策略，或者将少量的异常值单独以高精度（FP16）存储，而对绝大部分数据进行INT4甚至2-bit量化。
3. 分组量化：类似于GQA，对每128个或64个元素进行独立的量化统计，减小异常值的影响范围。

目前，INT4 KV Cache在部分长文本场景下已可投入使用，但在高精度要求的逻辑推理任务中仍需谨慎评估。

5. 各大厂商Prompt Cache支持情况深度评测

2025年以来，随着上述技术的成熟，各大模型厂商纷纷推出了面向开发者的“Context Caching”或“Prompt Caching”服务。这一功能被视为RAG（检索增强生成）和Agent（智能体）应用的经济基石。

5.1 DeepSeek：磁盘缓存与价格屠夫

DeepSeek（深度求索）是目前市场上最具颠覆性的玩家。依托于其独特的MLA架构，DeepSeek实现了真正的磁盘级上下文缓存。

• 技术原理：由于MLA将KV Cache压缩到了极小（约为MHA的1/10甚至更低），数据量小到足以从SSD硬盘阵列中实时读取，而不会造成严重的延迟瓶颈。这打破了“KV Cache必须在显存”的铁律 6。
• 缓存策略（Implicit）：自动触发。无需用户显式创建缓存ID，系统自动识别重复的前缀。
• 价格体系：
  • 缓存命中（Cache Hit）：$0.014 / 百万tokens。这是一个惊人的数字。相比之下，GPT-4o的输入价格约为$2.50，DeepSeek的价格仅为OpenAI的 0.5%。
  • 缓存未命中（Cache Miss）： 约 $0.14 - $0.27 / 百万tokens（取决于具体版本），依然远低于竞品。
  • 存储费：免费。得益于磁盘存储的低成本，DeepSeek不收取额外的时间存储费。
• 持久性：由于存储在磁盘，其TTL（生存时间）远长于基于显存的竞品，理论上可达数小时甚至数天（取决于系统调度），非常适合低频但长尾的知识库查询。

5.2 Google Gemini：TPU加持下的灵活双模

Google Vertex AI利用其TPU Pod的庞大显存池，提供了最为灵活的“隐式+显式”双轨制。

• 隐式缓存（Implicit）：针对Gemini 2.5 Flash等模型。自动检测，无需代码更改。
  • 门槛：1024或2048 tokens以上。
  • 价格：命中时约为标准输入价格的25%（即75%折扣）。无存储费。
• 显式缓存（Explicit）：针对企业级长文档。
  • 机制：用户调用API创建CachedContent对象，获得一个ID。
  • 价格结构：包含两部分。
    • 计算费：命中缓存的Token价格极低（甚至在某些层级接近免费）。
    • 存储费：按小时计费。例如，Gemini 2.5 Pro约为$4.50 / 100万tokens / 小时。
  • 适用场景：** 这是一种“租赁显存”的模式。只有当你的查询频率非常高（例如每小时数百次查询同一份文档），节省的计算费才能覆盖存储费。如果只是偶尔查询，显式缓存反而更贵。

5.3 Anthropic Claude：极速流转的显存租赁

Anthropic的策略非常激进，专注于“高频会话”场景，尤其是配合Claude 4 Sonnet强大的编码能力。

• 显式断点：用户需在API参数中设置 cache_control: {"type": "ephemeral"} 断点。
• TTL（5分钟）：这是最大的争议点与特点。缓存仅保存5分钟。每次命中（Read），TTL重置为5分钟。这意味着它不适合长期存储，只适合连续不断的对话。
• 价格：
  • 写入（Write）：1.25倍标准输入价格。你需要支付溢价来创建缓存。
  • 读取（Read）：0.1倍（10%）标准输入价格。90%的折扣。
• 盈亏平衡点：由于有25%的写入溢价，用户必须在5分钟内至少复用一次缓存（即第二次提问），才能开始省钱。如果写入后5分钟内没有再次提问，缓存失效，用户的写入溢价就“白花了”。

5.4 OpenAI：保守的黑盒策略

OpenAI在Prompt Cache上显得相对保守和不透明。

• 机制：纯隐式。自动匹配1024 tokens以上的块。
• 支持模型：GPT-4、5等系列。
• 价格：
  • 写入：原价（无溢价）。
  • 读取：50%折扣。
• 分析：50%的折扣力度远小于DeepSeek (95%+) 或 Anthropic (90%)。但由于没有写入溢价，这是一种“无风险”的优惠——即使没命中也不会亏。
• TTL：不透明，通常为5分钟-24小时，受系统负载影响极大。这使得开发者很难依赖它来做严格的成本控制。

5.5 阿里云 Qwen (通义千问)：混合模式

阿里云Model Studio紧跟国际步伐，提供了类似的机制。

• 隐式：命中时按标准价的20%计费（80%折扣）。
• 显式：
  • 写入：1.25倍价格。
  • 读取：20%价格。
• Qwen-Long：支持文件ID引用的长上下文，本质上是一种持久化的上下文缓存，支持高达10M tokens，适合超长文档分析。

5.6 厂商对比汇总表

5.7 成本情景模拟：法律文档分析

场景：上传一本50,000 tokens的法律法典，并在接下来的2小时内进行100次问答查询。

1. Anthropic (Claude 3.5 Sonnet):
   • 首单（写入）：$50k \times $3.75/M = $0.1875$
   • 后续99次（读取）：$99 \times 50k \times $0.30/M = $1.485$
   • 总计：~$1.67
   • 风险：如果中间停顿超过5分钟，需重新支付写入费。
2. Google (Gemini 2.5 Pro - 显式缓存):
   • 写入：$50k \times $1.25/M = $0.0625$ (假设基础价)
   • 存储：$2 \text{小时} \times 0.05M \text{ tokens} \times $4.50/M/hr = $0.45$
   • 读取：$100 \times 50k \times $0.30/M = $1.50$
   • 总计：~$2.01
   • 优势：即使2小时内没人提问，缓存也在。
3. OpenAI (GPT-4o):
   • 首单：$50k \times $2.50/M = $0.125$
   • 后续99次：$99 \times 50k \times $1.25/M = $6.18$
   • 总计：~$6.30
   • 劣势：读取折扣力度不够。
4. DeepSeek (V3):
   • 首单：$50k \times $0.14/M = $0.007$
   • 后续99次：$99 \times 50k \times $0.014/M = $0.069$
   • 总计：~$0.076

6. 语义缓存与应用层优化

除了依赖模型厂商的Prompt Cache，开发者在应用层（Client-side）还可以通过语义缓存（Semantic Caching）进一步降低成本。这与Prompt Cache是互补关系。

6.1 语义缓存的原理

传统的缓存（如Redis）基于Key-Value精确匹配。如果用户问“苹果的价格？”和“苹果多少钱？”，传统缓存会视为两个请求。
语义缓存引入了向量嵌入（Embedding）技术：

1. Embedding： 将用户Query转化为向量。
2. 向量搜索： 在向量数据库（如Milvus, Qdrant, Redis Vector）中搜索历史Query。
3. 相似度阈值： 如果发现一个历史Query的余弦相似度大于阈值（如0.95），则直接返回之前缓存的LLM回答 36。

6.2 开源工具：GPTCache

GPTCache是目前最流行的开源语义缓存库，支持LangChain集成。

• 模块化设计： 支持多种Embedding模型（OpenAI, HuggingFace）和多种向量存储（Redis, FAISS）。
• 后处理： 甚至支持对缓存的回答进行评估，确保时效性。
• 对比：
  • Prompt Cache (服务端)： 解决的是“长Context复用”的问题。输入是旧的（书），问题是新的。
  • Semantic Cache (客户端)： 解决的是“高频重复问题”的问题。输入是新的（问题），但意义是旧的。
• 最佳实践： 只有当用户的提问具有高重复性（如客服系统常见问题）时，语义缓存才有意义。对于开放式分析任务，Prompt Cache更为关键 。

7. Prompt Cache在X-Sec中的应用

7.1 Prompt Cache

  # Qwen3 等支持 Cache 的 LLM 使能 Prompt Caching
from langchain_core.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_messages([
  SystemMessage(
    # Qwen启动显示prompt cache能力
    content=[
      {
        "type": "text",
        "text": app_prompt_template.format(vars),
        "cache_control": {"type": "ephemera"},
      }
    ]
  ),
  HumanMessage(content=app_user_prompt_template.format(input_data),
])

# OpenAI 使能 Prompt Caching
from openai import OpenAI

client = OpenAI()

completion = client.chat.completions.create(
    model="gpt-4o",
    # openai 支持 24h 保存 cache
    prompt_cache_retention: "24h"
    messages=[
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "Tell me a joke."},
    ]
)

7.2 Semantic Cache

X-Sec需要Memory系统的支持（langchain checkpoint支持vector store），所以当前还没有实现数据。Stay Tuned！

7. 总结

大模型推理的演进史，本质上是一部与显存带宽和容量搏斗的抗争史。

1. 架构与硬件的协同：DeepSeek MLA的成功证明了算法创新（低秩压缩）可以解锁硬件潜力（SSD存储），从而颠覆商业模式。这预示着未来模型设计将更多地考虑底层硬件特性，而非单纯追求参数量。
2. 有状态API（Stateful API）的兴起：HTTP无状态协议已不再适应LLM应用。Prompt Cache的普及标志着LLM服务正演变为“有状态”的操作系统。开发者必须学会管理“Context 生命周期”，像管理数据库连接池一样管理Prompt Cache。
3. 成本的断崖式下降：随着$0.014/M tokens这种价格的出现，RAG应用的瓶颈将从“检索多少文档省钱”转变为“模型能处理多少文档不幻觉”。全量知识库注入（Full Context）正在取代部分切片检索，成为新的技术趋势。
4. 对于Agent应用开发者而言，当下的最优策略是：对于高频低延时任务（如代码助手）选择Anthropic或vLLM自建服务；对于海量数据分析和知识库问答，DeepSeek的磁盘缓存方案提供了目前无法匹敌的性价比优势。

References

1. Optimizing Transformer Inference with Grouped Query Attention | Towards AI, accessed November 27, 2025, https://towardsai.net/p/machine-learning/optimizing-transformer-inference-with-grouped-query-attention
2. arXiv:2305.13245v3 [cs.CL] 23 Dec 2023, accessed November 27, 2025, https://arxiv.org/pdf/2305.13245
3. Attention Mechanisms in Transformers: Comparing MHA, MQA, and GQA | Yue Shui Blog, accessed November 27, 2025, https://syhya.github.io/posts/2025-01-16-group-query-attention/
4. Understanding Multi-Head Latent Attention, accessed November 27, 2025, https://planetbanatt.net/articles/mla.html
5. DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model, accessed November 27, 2025, https://arxiv.org/html/2405.04434v2
6. DeepSeek API introduces Context Caching on Disk, cutting prices by an order of magnitude, accessed November 27, 2025, https://api-docs.deepseek.com/news/news0802
7. MLA: Redefining KV-Cache Through Low-Rank Projections and On-Demand Decompression - Hugging Face, accessed November 27, 2025, https://huggingface.co/blog/NormalUhr/mla-explanation
8. How PagedAttention resolves memory waste of LLM systems - Red Hat Developer, accessed November 27, 2025, https://developers.redhat.com/articles/2025/07/24/how-pagedattention-resolves-memory-waste-llm-systems
9. Introduction to vLLM and PagedAttention | Runpod Blog, accessed November 27, 2025, https://www.runpod.io/blog/introduction-to-vllm-and-pagedattention
10. vLLM and PagedAttention: A Comprehensive Overview | by Abonia Sojasingarayar | Medium, accessed November 27, 2025, https://medium.com/@abonia/vllm-and-pagedattention-a-comprehensive-overview-20046d8d0c61
11. vAttention: Dynamic Memory Management for Serving LLMs without PagedAttention - arXiv, accessed November 27, 2025, https://arxiv.org/html/2405.04437v1
12. When to Choose SGLang Over vLLM: Multi-Turn Conversations and KV Cache Reuse, accessed November 27, 2025, https://www.runpod.io/blog/sglang-vs-vllm-kv-cache
13. SGLang: Efficient Execution of Structured Language Model Programs - arXiv, accessed November 27, 2025, https://arxiv.org/pdf/2312.07104
14. Fast and Expressive LLM Inference with RadixAttention and SGLang | LMSYS Org, accessed November 27, 2025, https://lmsys.org/blog/2024-01-17-sglang/
15. Arxiv Dives - Efficient Streaming Language Models with Attention Sinks - Oxen.ai, accessed November 27, 2025, https://ghost.oxen.ai/arxiv-dives-efficient-streaming-language-models-with-attention-sinks/
16. Efficient Streaming Language Models with Attention Sinks - arXiv, accessed November 27, 2025, https://arxiv.org/html/2309.17453v4
17. [2309.17453] Efficient Streaming Language Models with Attention Sinks - arXiv, accessed November 27, 2025, https://arxiv.org/abs/2309.17453
18. Attention Sinks for LLM - Endless Generation - Analytics Vidhya, accessed November 27, 2025, https://www.analyticsvidhya.com/blog/2023/12/attention-sinks-for-llm/
19. FP8 E5M2 KV Cache - vLLM, accessed November 27, 2025, https://docs.vllm.ai/en/v0.6.3.post1/quantization/fp8_e5m2_kvcache.html
20. FP8 quantization with AMD Quark for vLLM — Tutorials for AI developers 8.0, accessed November 27, 2025, https://rocm.docs.amd.com/projects/ai-developer-hub/en/latest/notebooks/gpu_dev_optimize/fp8_quantization_quark_vllm.html
21. KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization, accessed November 27, 2025, https://www.stat.berkeley.edu/~mmahoney/pubs/neurips-2024-kvquant.pdf
22. AsymKV: Enabling 1-Bit Quantization of KV Cache with Layer-Wise Asymmetric Quantization Configurations - ACL Anthology, accessed November 27, 2025, https://aclanthology.org/2025.coling-main.158.pdf
23. FireQ: Fast INT4-FP8 Kernel and RoPE-aware Quantization for LLM Inference Acceleration, accessed November 27, 2025, https://arxiv.org/html/2505.20839v1
24. NQKV: A KV Cache Quantization Scheme Based on Normal Distribution Characteristics, accessed November 27, 2025, https://arxiv.org/html/2505.16210v1
25. Gemini Developer API pricing, accessed November 27, 2025, https://ai.google.dev/gemini-api/docs/pricing
26. Context caching overview | Generative AI on Vertex AI - Google Cloud Documentation, accessed November 27, 2025, https://docs.cloud.google.com/vertex-ai/generative-ai/docs/context-cache/context-cache-overview
27. Context Caching In Google Gemini: Better Than RAG For Memory - Empathy First Media, accessed November 27, 2025, https://empathyfirstmedia.com/context-caching-google-gemini/
28. Prompt Caching Support in Spring AI with Anthropic Claude, accessed November 27, 2025, https://spring.io/blog/2025/10/27/spring-ai-anthropic-prompt-caching-blog
29. Prompt caching - Claude Docs, accessed November 27, 2025, https://platform.claude.com/docs/en/build-with-claude/prompt-caching
30. Prompt Caching is a Must! How I Went From Spending $720 to $72 Monthly on API Costs | by Du'An Lightfoot | Medium, accessed November 27, 2025, https://medium.com/@labeveryday/prompt-caching-is-a-must-how-i-went-from-spending-720-to-72-monthly-on-api-costs-3086f3635d63
31. Prompt caching - OpenAI API, accessed November 27, 2025, https://platform.openai.com/docs/guides/prompt-caching
32. Prompt Caching in the API - OpenAI, accessed November 27, 2025, https://openai.com/index/api-prompt-caching/
33. How does Prompt Caching work? - OpenAI Developer Community, accessed November 27, 2025, https://community.openai.com/t/how-does-prompt-caching-work/992307
34. Context Cache feature of Qwen models - Alibaba Cloud Model Studio, accessed November 27, 2025, https://www.alibabacloud.com/help/en/model-studio/context-cache
35. Qwen context window: token limits, memory policy, and 2025 rules - Data Studios, accessed November 27, 2025, https://www.datastudios.org/post/qwen-context-window-token-limits-memory-policy-and-2025-rules
36. Semantic Cache: How to Speed Up LLM and RAG Applications - Medium, accessed November 27, 2025, https://medium.com/@svosh2/semantic-cache-how-to-speed-up-llm-and-rag-applications-79e74ce34d1d
37. Semantic Cache: Accelerating AI with Lightning-Fast Data Retrieval - Qdrant, accessed November 27, 2025, https://qdrant.tech/articles/semantic-cache-ai-data-retrieval/
38. Semantic caching for faster, smarter LLM apps - Redis, accessed November 27, 2025, https://redis.io/blog/what-is-semantic-caching/
39. zilliztech/GPTCache: Semantic cache for LLMs. Fully integrated with LangChain and llama_index. - GitHub, accessed November 27, 2025, https://github.com/zilliztech/GPTCache
40. Reducing LLM Costs and Latency via Semantic Embedding Caching - arXiv, accessed November 27, 2025, https://arxiv.org/html/2411.05276v2
41. If your app process many similar queries, use Semantic Caching to reduce your cost and latency : r/LangChain - Reddit, accessed November 27, 2025, https://www.reddit.com/r/LangChain/comments/1f4rlx0/if_your_app_process_many_similar_queries_use/
42. 图解vLLM Automatic Prefix Cache(RadixAttention), https://zhuanlan.zhihu.com/p/693556044
43. Gemini 3技术是跳蛙式超越 https://www.youtube.com/watch?v=EMQxQwoFSb4
44. Andre Ng issue 329 | deeplearning.ai batch https://www.deeplearning.ai/the-batch/issue-329/