LLM 提示词缓存如何工作：详解 KV Cache 与 TTL

TL;DR — LLM 提示词缓存不是额外加上的优化，而是 Transformer 架构计算 attention 的自然结果。理解稳定前缀的 Key/Value 向量为什么可以直接复用后，真正值得关注的是它带来的双重收益：成本大幅下降（50–90%），首 token 延迟也大幅缩短（5–20×）。本文是五篇系列文章的第 1 篇，介绍缓存存在的架构原因、决定缓存是否划算的内存与计算权衡，以及每位开发者都需要理解的 TTL 行为。第 2 篇将深入分析各 provider 的具体实现。

系列文章：第 1 篇，共 5 篇 — 缓存原理 · 下一篇：第 2 篇 — Provider 对比与评估 · 第 3 篇 — 可运行代码教程 · 第 4 篇 — 按使用场景选择最佳 LLM · 第 5 篇 — LangChain 集成 · 单篇完整版本：提示词缓存完整指南

为什么 AI 应用的 token 账单增长速度超过用户量

只要你在开发聊天机器人、RAG 应用或 AI agent，多半都遇到过同一个问题：使用量没翻倍，账单却翻倍了。打开请求日志，你会看到同一段几千 token 的 system prompt、相同的工具描述和相同的知识库片段，在每次调用时反复发送。

这正是 LLM 推理的核心成本问题：模型是无状态的。每个请求都要从头处理完整上下文。一段 8K token 的 system prompt 调用 1,000 次，就意味着 800 万 token 的重复计算。每个 token 都要付费，用户也要为每次重复处理等待。

提示词缓存解决了这个问题。它不同于多数性能优化，并不是后来附加到架构上的功能，而是 Transformer attention 定义本身带来的自然结果。理解这一点后，后面的定价、TTL 和 provider 差异也就容易解释了。

1. LLM 为什么会有缓存：完整拆解 Transformer 推理流程

几乎所有“提示词缓存”教程都会跳过这一部分，但它恰恰解释了缓存为什么存在，也说明了 provider 给出的折扣并非随意设定的营销数字，而是由真实的 GPU 成本决定的。

1.1 用一个公式理解 Self-Attention

Decoder-only Transformer（GPT-4、Claude、Gemini、DeepSeek、Qwen 都属于这一类）通过反复执行 self-attention 来处理 token。对于包含 N 个 token 的序列，每个 token i 的 attention 输出为：

Attention(Q, K, V) = softmax( Q · Kᵀ / √d ) · V

其中，Q、K、V 是形状为 [N × d] 的矩阵，由输入 embedding 经过三个可学习的线性投影得到，每层、每个 head 都各有一组。该公式最初出自 Attention Is All You Need（Vaswani 等，2017）。

这个公式有两个对缓存至关重要的性质：

性质 1 — Causal masking。 在生成过程中，token i 只能关注位置 ≤ i 的 token。Attention 矩阵是下三角矩阵：前面 token 的 K 和 V 向量会被后续所有 token 使用，但后续 token 永远不会修改它们。

性质 2 — K 和 V 只取决于前缀。 K 和 V 由位置 1…i 的输入 embedding 通过固定权重矩阵计算得到，因此位置 i 的 K 和 V 向量是位置 1…i 上 token 的确定性函数，并且只由这些 token 决定。位置 i+1 的任何内容都无法改变 K_i 或 V_i。

结论很直接：如果两个请求共享长度为 P 的完全相同前缀，那么 K 和 V 的前 P 行也会逐 bit 完全一致。

这就是提示词缓存的全部理论基础。剩下的都是工程实现。

1.2 推理的两个阶段

现代 LLM 推理分为两个不同阶段，它们消耗 GPU 时间的方式差别很大。Efficiently Scaling Transformer Inference（Pope 等，2022）对这一划分做了详细说明。

Prefill 阶段。 模型一次性读入完整 prompt。每一层都会为所有输入 token 计算 Q、K、V，并执行 self-attention。Prefill 属于计算密集型任务，会占满 GPU 的矩阵乘法单元。由于需要计算 attention 矩阵，其成本随 prompt 长度按 O(N²) 增长。

Decode 阶段。 模型以自回归方式逐个生成输出 token。在第 t 步，只计算新 token 的 Q，然后让它关注此前所有 token 的 K/V。Decode 属于内存带宽受限任务，大部分时间用于从 GPU 内存读取 K/V，而不是执行乘法。每个 token 的成本按当前上下文长度以 O(N) 线性增长。

对于典型的聊天机器人负载（8K token 的 system prompt、100 token 的用户问题、300 token 的回复），prefill 在总耗时和成本中的占比大约是 decode 的 4 倍。缓存省下的正是这部分工作。

Per call breakdown (8K prompt, 300 output tokens, Claude-class model):

  ████████████████████████████████░░░░░░░░  Prefill: ~80% of compute
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode:  ~20% of compute

1.3 KV Cache：保存 Prefill 结果供 Decode 使用

“KV cache”最初指的是单个请求内部的优化。Decode 时，每个新生成的 token 都需要关注此前所有 token 的 K 和 V。如果每一步都重新计算，decode 的复杂度就会从 O(N) 变成 O(N²)。因此，所有推理引擎都会把 prefill 产生的 K 和 V 保存在 GPU 内存中，并在整个 decode 阶段反复使用。这是所有商用 LLM 的通用做法，也是生成过程能够实际运行的基础。

Provider 对外提供的“提示词缓存”是在此基础上的进一步扩展：请求结束后继续保留 KV cache，下一个请求只要共享相同前缀，就直接复用。

1.4 内存与计算的权衡：TTL 为什么存在

为什么 provider 不把所有内容永久缓存？因为 KV cache 非常大。

假设模型有 L 个 transformer layer、H 个 attention head、head dimension 为 D，每个值占 B 字节（fp16 通常为 2），那么 N 个 token 的 KV cache 大小为：

KV cache size  =  2 × L × H × D × B × N
                  ↑   ↑   ↑   ↑   ↑   ↑
                  K&V layers heads head bytes tokens

以一个 70B 级模型为例：80 层，采用 grouped-query attention 后有 8 个 KV head，head dimension 为 128，权重格式为 fp16。每个 token 大约需要 320 KB。32K token 的上下文仅 KV cache 就需要 ~10 GB。一块现代 H100 GPU 有 80 GB 显存，因此同时最多只能放下少数几份这样的缓存。

PagedAttention（Kwon 等，2023，vLLM 背后的论文）就是为了解决 batch 层面的这项核心约束。同样的限制也决定了跨请求提示词缓存的上限：

因此，provider 的缓存 TTL 本质上是一套内存淘汰策略：GPU 迟早需要把这部分内存让给其他用户的活跃负载，缓存前缀随之被淘汰。常驻 HBM 的缓存通常是 5 分钟；换页到 DRAM 的缓存最长可到 1 小时；磁盘缓存则可以保留数小时。

DeepSeek 的做法。 DeepSeek-V2 引入了 Multi-head Latent Attention（MLA）。相比标准 grouped-query attention，它能将 KV cache 压缩约 4×（DeepSeek-AI，2024）。正是这种压缩能力，让 DeepSeek 可以把 KV cache 持久化到磁盘而不是 HBM。这样一来，最小缓存单元可以显著缩小（64 token，而常驻 HBM 的缓存通常是 1,024 token），有效 TTL 也更长。

这也解释了跨请求缓存为什么要求逐 token 完全一致的前缀。缓存以 token ID 的 hash 作为索引。任何差异，即使只是一个导致 tokenization 变化的字符，也会让该位置之后的 K 和 V 全部不同。这个层面不存在“模糊匹配”。模糊匹配属于语义缓存，是 gateway 中另一套机制。

1.5 两层缓存

┌──────────────────────────────────────────────────────────────┐
│  Layer 1: Per-request KV cache (always on, every provider)    │
│  → keeps decode O(N) instead of O(N²)                        │
│  → you don't pay attention to it; the provider just does it  │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  Layer 2: Cross-request Prompt Cache (the money-and-time      │
│           saver this series is about)                         │
│  → reuses prefill K/V across requests with matching prefixes  │
│  → exposed as: explicit / fully automatic / hybrid           │
│  → bounded by TTL (memory-eviction-driven)                   │
└──────────────────────────────────────────────────────────────┘

本系列后续内容，以及开发者需要调优的大多数参数，都位于 Layer 2。

2. 两项收益：成本和延迟

大多数文章只把缓存视为降低成本的手段，这低估了它的价值。生产团队采用缓存时，延迟改善往往才是更重要的原因，尤其是面向用户的聊天产品。

2.1 成本怎么算

定价页面通常只列出单价，很少把它代入真实负载。以一个客服机器人为例：system prompt 为 8,000 token，每天处理 100K 次查询，每条用户消息 200 token。按 Anthropic 公布的 2026 年 claude-sonnet-4-5 价格计算（缓存输入按 10% 计费，写入缓存加价 125%）：

不使用缓存

• 每次调用的输入：8,200 token × 基础输入费率
• 单次调用成本（单次实测）：~$0.022
• 每月成本：100K × 30 × $0.022 = ~$66,000

使用提示词缓存

• 一次性写入缓存：8,000 token × 125% 加价（相较每月调用量几乎可以忽略）
• 后续每次调用：8,000 token × 基础费率的 10% + 200 token × 基础费率 + 输出
• 单次调用的有效成本：~$0.003
• 每月成本：~$9,000

节省约 86%。 这是把 Anthropic 公布的折扣应用到真实输入结构后得到的结果。后续的第 3 篇 — 教程会给出其他 provider 的实际测量数据。

2.2 延迟收益：通常更重要

Prefill 不仅成本高，还是长度超过几百 token 的 prompt 中，影响首 token 延迟的最大单项因素。缓存命中后，这部分工作几乎可以全部跳过。

以下数据于 2026-05-25 通过公开的 Synthorai gateway 测得，采用 streaming TTFT，稳定 system prompt 约为 7,300 token：

以上为单次运行、单租户数据。长 prompt（>5K token）上的 TTFT 改善最明显；短 prompt 的 prefill 占比太小，不足以主导延迟。Claude 实测最显著的收益是成本，缓存读取可降低约 88–89% 的输入费用。根据 Anthropic 公布的数据，当 prompt 达到 100K+ 时，TTFT 收益会进一步放大。

对于聊天 UI，TTFT 超过约 1 s、第一段有用文本超过约 2 s 后，用户就会明显感知到等待。一个 10K token 的 RAG prompt 如果不使用缓存，显然会超过这个阈值。使用缓存后，同样的负载会让人感觉几乎即时响应。

对于包含 15 个以上步骤的 agent loop，节省 50% 成本固然不错，但延迟才是产品能否上线的关键：每个任务有 15 步 × 5s prefill，相当于 75 s 的纯等待时间；使用缓存后则变成 15 × 0.5s = 7.5 s。

2.3 为什么产品策略也必须考虑缓存

常见误区是把缓存当作“运维做的成本优化”，等产品上线后再补上。但由于缓存能显著降低延迟，它也是用户体验的一部分：

• TTFT 低于 1 s 的聊天机器人让人感觉响应自然；同一个机器人延迟 3 s，就像出了故障。
• 检索加 prefill 需要 4 s 的 RAG 产品，会输给只需要 1 s 的同类产品。
• 20 s 完成任务的 agent，会胜过需要 90 s 的产品。

缓存策略应该与模型选择和 prompt 结构同时确定，而不是上线三个 sprint 后再处理。

3. 缓存新鲜度、TTL 与运维模型

TTL 是提示词缓存中最常被问到、却最少得到完整解释的问题。需要先理解两件事：

3.1 新鲜度有两层含义，不要混淆

缓存新鲜度 ≠ 响应内容新鲜度。 这两个概念经常被混为一谈：

从模型质量来看，缓存后的响应并不会“过期”，它在数学上与未使用缓存的结果完全一致。但如果 system prompt 里写着“当前时间是 14:32:05”，并持续依赖缓存命中，那么在 TTL 到期前，“当前时间”会一直停留在 14:32:05，模型也会很有把握地向用户提供错误时间。

3.2 各 Provider 的 TTL 行为

默认 5 分钟并非随意选择，而是热门模型在峰值负载下大致能承受的 GPU 内存压力周期。正如 §1.4 所算，一份长上下文的 KV cache 就可能占用数十 GB，provider 无法无限期保留。

3.3 围绕 TTL 设计系统

生产环境中有三种行之有效的模式：

模式 A — 保持会话热度。 对聊天场景而言，用户通常每隔几秒到几分钟发起一次请求，这种节奏本身就能让缓存保持有效。无需特别担心 TTL，只要不要把动态数据放进前缀即可。

模式 B — 为批处理发送心跳。 对于持续数小时的 batch job，每隔 TTL/2 发送一个最小请求，让缓存保持热状态。这类请求的成本几乎为零，只有几个输入 token，却能避免缓存集中淘汰引发的抖动。

模式 C — 冷数据使用长 TTL Provider。 如果有一份 50K token 的文档，只会被间歇性查询，例如一周内每小时一次，那么即使需要支付存储费，Gemini 的显式缓存（24 小时 TTL）或 DeepSeek 的磁盘缓存也会比短 TTL 方案更合适。

4. 每位开发者都应该掌握的通用原则

不同 provider 以五种截然不同的方式提供缓存：显式标记、全自动、混合模式、架构级磁盘持久化，或完全不支持。下一篇文章会专门比较这些方案（第 2 篇 — Provider 对比与评估）。但无论使用哪家 provider，都有四条通用原则。这些原则直接来自前面介绍的架构。

4.1 缓存基于前缀，顺序很重要

由于位置 i 的 K/V 取决于位置 1…i 的 token，provider 只能匹配从 token 0 开始的连续前缀。只要位置 0 上有一个字符发生变化，整个前缀都会失效。稳定内容放前面，易变内容放后面。 这不是经验规则，而是 self-attention 因果结构的直接结果（§1.1）。

4.2 缓存保存的是 K/V，不是答案

缓存命中不会返回以前生成过的答案，而是返回之前计算的 K 和 V 向量。模型随后基于它们，为当前问题生成新的响应。因此：

• 输出质量与未缓存调用完全一致（§1.1）。
• 输出仍然具有通常意义上的非确定性，temperature、top-p 等参数照常生效。
• 从模型质量角度看，缓存响应永远不会“过期”。只有 prompt 中的内容，例如时间戳和价格，才可能过期。参见 §3.1。

4.3 写入缓存是一项投资，并非免费

对于写入缓存需要加价的 provider（Anthropic 为 125%，Gemini 显式缓存为 125%），新前缀的第一次调用反而比不使用缓存更贵。通常只要命中一次就能回本。但如果所谓的“稳定”前缀每次请求都在变化，你就会反复支付写入成本，却得不到收益。按相关性对检索文档排序时尤其要注意，这是最典型的反模式。

4.4 不同 Provider 的缓存 API 无法直接移植

cache_control（Anthropic）≠ cached_content（Gemini）≠ cache_id（Qwen）。如果应用必须同时支持多个 provider，要么维护三套集成，要么在前面增加 Token Gateway 来统一处理。第 2 篇会详细介绍。

5. 提示词缓存等于白捡收益吗？

几乎可以这么说。满足以下条件时，缓存就能带来收益：

• Prompt 具有稳定前缀，例如 system prompt、知识库和工具 schema
• 调用足够频繁或彼此关联，例如同一会话、batch workload 或正在运行的 agent
• Prompt 结构允许把稳定内容放在最前面

满足这三个条件后，通常不需要更换模型，就能实现成本降低 50–90%，并让 TTFT 提升 3–20×。

下一篇：第 2 篇 — Provider 缓存对比与评估框架会把上面的架构原理转化为逐项功能对比，涵盖 Claude、OpenAI、Gemini、DeepSeek 和 Qwen，并提供一套评估标准，帮助你为具体负载选择合适的 provider。

快速开始：用 OpenAI SDK 调用所有 Provider

Synthorai 提供兼容 OpenAI 的 endpoint。将官方 openai SDK 指向该 endpoint 后，Claude、GPT、Gemini、DeepSeek、Qwen 之间只需改一行模型 ID 即可切换。Gateway 会把 cache_control 转换成各 provider 原生的缓存语法。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-4-5",                       # swap freely
    max_tokens=256,
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user",   "content": "Hello"},
    ],
)

print(resp.choices[0].message.content)
print(resp.usage.prompt_tokens_details)  # cached_tokens when upstream reports it
print(resp.usage.cost)                   # USD per call (gateway-computed)

同一调用也适用于 gpt-5.4-mini、gemini-2.5-pro、deepseek-v4-flash、qwen3-max，只需修改 model 字段。Gateway 会通过标准 OpenAI prompt_tokens_details.cached_tokens 字段返回提示词缓存命中元数据，并额外提供以 USD 计价的 cost 字段，因此无需在本地维护各 vendor 的价格矩阵。

常见问题

LLM 提示词缓存与语义缓存相同吗？ 不同。提示词缓存基于前缀，复用的是 prompt 开头在 token 层面精确匹配的 K/V 值。语义缓存则在语义层面进行匹配，通常借助 embedding，并返回之前的响应。两者都很有用，完善的 Token Gateway 会分层组合使用它们。

提示词缓存会改变模型输出吗？ 不会。K 和 V 是输入 token 的确定性函数（§1.1）。模型基于缓存 K/V 生成的 logits，与重新计算 K/V 后生成的 logits 在数学上完全一致。缓存只是效率优化，不会影响质量。

为什么缓存 TTL 这么短，不能永久保留吗？ KV cache 非常大（§1.4：70B 模型每个 32K 上下文约占 10 GB）。GPU 内存是瓶颈，服务器需要为活跃负载腾出内存时，就会淘汰缓存。磁盘缓存（DeepSeek）可以保留数小时，但内存缓存通常做不到。

KV cache 与提示词缓存有什么区别？ KV cache 是推理过程中使用的内存数据结构。“提示词缓存”则是在不同请求之间复用 KV cache。也就是上文 §1.5 中的 Layer 1 与 Layer 2。

缓存后的 prompt 会不会因过期而降低质量？ 从模型角度看，不会。如果 prompt 包含时效性信息，从内容角度看则会。缓存保存的是 K/V 向量，而不是现实世界中的事实。参见 §3.1。

如何测量缓存命中率？ 每个 provider 都会在响应的 usage 对象中返回相关数据：cache_read_input_tokens（Anthropic）、cached_tokens（OpenAI）、cached_content_token_count（Gemini）、prompt_cache_hit_tokens（DeepSeek）。应在日志 pipeline 中持续跟踪这些字段。

参考文献与资料来源： Vaswani 等，《Attention Is All You Need》（NeurIPS 2017） · Pope 等，《Efficiently Scaling Transformer Inference》（2022） · Kwon 等，《Efficient Memory Management for LLM Serving with PagedAttention》（SOSP 2023，vLLM） · DeepSeek-AI，《DeepSeek-V2: A Strong, Economical, and Efficient MoE Language Model》（2024）— MLA 架构 · Anthropic Prompt Caching 文档 · OpenAI Prompt Caching 文档 · Google Gemini Context Caching 文档 · DeepSeek KV Cache 指南 · Alibaba Bailian Context Cache

← 返回博客