LLM 提示词缓存 #1：KV 缓存与 TTL 的工作原理

TL;DR — LLM 提示词缓存并不是外挂式的优化手段；它本就是 Transformer 架构计算注意力方式的自然产物。一旦你理解了为什么稳定前缀的 Key/Value 向量在数学上可以复用，真正令人惊讶的便是它的双重收益：大幅降低成本（50–90%）以及大幅降低首字延迟（5–20×）。本文是四篇系列文章的第 1 篇，讲解缓存存在的架构原因、决定缓存是否划算的内存-算力权衡，以及每位开发者都需要理解的 TTL 行为。第 2 篇将深入各家厂商的具体实现。

系列：四篇之第 1 篇 — 缓存原理 · 下一篇：第 2 篇 — 厂商对比与评估 · 第 3 篇 — 可运行代码教程 · 第 4 篇 — 按使用场景挑选最佳 LLM

为什么你的 AI 应用的 Token 账单涨得比用户还快

如果你在做聊天机器人、RAG 应用或 AI 智能体，你大概撞过同一堵墙：账单翻倍，使用量却没翻倍。打开请求日志，你会发现同一份数千 token 的系统提示词、同样的工具说明、同样的知识库片段——每次调用都在重新发送。

这就是 LLM 推理的核心经济难题：模型是无状态的。每个请求都从头重新处理整个上下文。一份 8K token 的系统提示词被调用 1,000 次，就等于 800 万 token 的重复工作。你要为每一个 token 付费——而你的用户要为每一个 token 等待。

提示词缓存解决了这个问题。但与大多数性能技巧不同，它并不是被加进架构里的——它是 Transformer 注意力定义方式的自然结果。一旦你看清这一点，文章的其余部分（定价、TTL、厂商差异）就会自然顺畅地理顺。

1. LLM 为何会有缓存：一次 Transformer 推理走查

这一节是几乎所有”提示词缓存”教程都跳过的部分。它解释了缓存为何会存在——以及为什么厂商给出的折扣并不是随意的营销数字，而是反映了真实的 GPU 经济学。

1.1 一个方程式概括自注意力

仅解码器（decoder-only）的 Transformer（GPT-4、Claude、Gemini、DeepSeek、Qwen 都属于这一族系）通过反复施加自注意力来处理 token。对于一个有 N 个 token 的序列，每个 token i 的注意力输出为：

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

其中 Q、K、V 是形状为 [N × d] 的矩阵，由输入嵌入经过三个学得的线性投影（每层每个注意力头各一组）得到。最初的定义出自 Attention Is All You Need（Vaswani 等人，2017）。

这个方程的两个性质对缓存极为关键：

性质 1 —— 因果掩码（causal masking）。 在生成过程中，token i 只能关注位置 ≤ i 的 token。注意力矩阵是下三角形的：早期 token 的 K 和 V 向量会被之后的每一个 token 使用，但之后的 token 永远不会修改它们。

性质 2 —— K 和 V 只依赖前缀。 因为它们是由位置 1…i 的输入嵌入经固定权重矩阵计算而来，位置 i 处的 K 和 V 向量是位置 1…i 这些 token 的确定性函数——而且仅依赖这些 token。位置 i+1 的任何信息都无法改变 K_i 或 V_i。

由此立即得出结论：如果两个请求共享一段长度为 P 的相同前缀，那么 K 和 V 的前 P 行是逐比特完全相同的。

这就是提示词缓存的全部理论基础。其余的一切都是工程实现。

1.2 推理的两个阶段

现代 LLM 推理分为两个截然不同的阶段，它们消耗 GPU 时间的方式大不相同。这一划分在 Efficiently Scaling Transformer Inference（Pope 等人，2022）中有详尽记载。

预填充（Prefill）阶段。 模型一次性吞入完整提示词。对于每一层，它为每个输入 token 计算 Q、K、V 并执行自注意力。预填充是**算力受限（compute-bound）**的：它会让 GPU 的矩阵乘法单元满载。由于注意力矩阵的存在，成本随提示词长度按 O(N²) 增长。

解码（Decode）阶段。 模型以自回归方式一次产生一个输出 token。在第 t 步，只计算新 token 的 Q；它会对之前所有 token 的 K/V 做注意力。解码是**内存带宽受限（memory-bandwidth-bound）**的——大部分时间花在从 GPU 内存读取 K/V，而非做乘法。成本按每个 token O(N) 增长（与当前上下文长度成线性）。

对于典型的聊天机器人负载（8K token 系统提示词 + 100 token 用户查询 + 300 token 回复），预填充在墙钟时间和金钱成本上以大约 4:1 的比例占主导。这正是缓存所节省的部分。

单次调用拆解（8K 提示词，300 输出 token，Claude 级模型）：

  ████████████████████████████████░░░░░░░░  Prefill：约 80% 算力
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode： 约 20% 算力

1.3 KV 缓存：把预填充的成果留给解码用

“KV 缓存”最初指的是请求内部的一种优化。在解码过程中，每个新生成的 token 都需要对之前每个 token 的 K 和 V 做注意力。如果每一步都重新计算这些，O(N) 的解码就会变成 O(N²) 的解码。因此每个推理引擎都会把预填充得到的 K 和 V 存在 GPU 内存里，并在整个解码阶段复用。这是普适做法——每个商用 LLM 都这么做。它正是让生成在算力上变得可行的关键。

而厂商以”提示词缓存”形式对外暴露的，是更进一步的推广：在请求结束后仍保留 KV 缓存，并在下一个共享相同前缀的请求中复用它。

1.4 内存-算力权衡（TTL 为何存在）

那为什么厂商不干脆把一切都永久缓存呢？因为 KV 缓存极其庞大。

对于一个有 L 个 Transformer 层、H 个注意力头、头维度为 D、每个值占 B 字节（fp16 通常为 2）的模型，N 个 token 的 KV 缓存大小为：

KV 缓存大小  =  2 × L × H × D × B × N
                ↑   ↑   ↑   ↑   ↑   ↑
                K&V 层  头  头维 字节 token

对于一个 70B 级别、80 层、8 个 KV 头（经分组查询注意力 GQA 后）、头维度 128、fp16 权重的模型，大约是每 token 320 KB。一个 32K token 的上下文 = 约 10 GB 的 KV 缓存，仅仅为了一个请求。一块现代 H100 GPU 有 80 GB；你最多只能同时塞下寥寥几个这样的上下文。

这正是 PagedAttention（Kwon 等人，2023，vLLM 背后的论文）在批处理层面着力解决的核心约束——而同样的约束也在跨请求层面限制了提示词缓存：

所以厂商的缓存 TTL 本质上是一种内存淘汰策略：到某个时刻，GPU 需要把内存腾给其他用户的活跃负载，缓存的前缀便被淘汰。对于驻留在 HBM 中的缓存是 5 分钟；对于换页到 DRAM 的缓存可达 1 小时；对于落盘的缓存则可达数小时。

DeepSeek 的妙招。 DeepSeek-V2 引入了多头潜在注意力（Multi-head Latent Attention，MLA），相比标准的分组查询注意力，它把 KV 缓存压缩约 4 倍（DeepSeek-AI，2024）。正是这种压缩让他们能把 KV 缓存持久化到磁盘而非 HBM——而这反过来又使得最小缓存单元小得多（64 token，而 HBM 驻留缓存为 1,024 token），有效 TTL 也长得多。

这也是为什么跨请求缓存需要逐 token 完全相同的前缀。缓存是按 token ID 的哈希索引的，任何分歧——哪怕只有一个字符导致重新分词不同——都会从该点起产生不同的 K 和 V。这一层没有”模糊匹配”（那是语义缓存做的事，但那是网关中的另一种机制）。

1.5 两层缓存

┌──────────────────────────────────────────────────────────────┐
│  第 1 层：请求内 KV 缓存（始终开启，每个厂商都有）           │
│  → 让解码保持 O(N) 而非 O(N²)                                │
│  → 你无需关注它；厂商自然会做                                │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  第 2 层：跨请求提示词缓存（本系列要讲的省钱又省时的部分）   │
│  → 在前缀匹配的请求间复用预填充 K/V                          │
│  → 暴露形式：显式 / 全自动 / 混合                            │
│  → 受 TTL 约束（由内存淘汰驱动）                             │
└──────────────────────────────────────────────────────────────┘

本系列其余内容——也是你作为开发者要调优的大部分内容——都位于第 2 层。

2. 双重胜利：成本与延迟

大多数文章把缓存定位为一种成本优化。这低估了它。延迟收益往往是生产团队采用缓存的更主要原因，尤其是面向用户的聊天场景。

2.1 成本计算

定价页给出了头条数字，却很少展示它们应用到真实负载上的结果。以一个客服机器人为例：8,000 token 系统提示词，每天 100K 次查询，200 token 用户消息。按 claude-sonnet-4-5 用 Anthropic 公布的 2026 费率定价（缓存输入 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 篇 — 教程）会展示其余各家厂商的真实实测数字。

2.2 延迟收益（往往是更重要的故事）

预填充不仅昂贵——对于任何超过几百 token 的提示词，它都是首字延迟（TTFT）的最大单一贡献者。缓存命中让你几乎可以跳过它的全部。

针对公开的 Synthorai 网关实测的流式 TTFT，2026-05-25，约 7,300 token 的稳定系统提示词：

单次运行、单租户。TTFT 收益在长提示词（>5K token）上最明显；对于短提示词，预填充占比太小，不足以主导延迟。Claude 实测的最大收益是成本（缓存读取时输入约省 88–89%）——对于 100K+ 量级的提示词规模，按 Anthropic 公布的数字，TTFT 收益会大幅叠加。

对于聊天 UI，用户有意识地感知到延迟的阈值大约是 TTFT 1 s、首段有用文本 2 s 左右。一个 10K token 的 RAG 提示词在不缓存时稳稳越过这条线。有了缓存，同样的负载感觉是即时的。

对于 15 步以上的智能体循环，成本故事不错（省 50%），但真正让产品可以上线的是延迟故事：15 步 × 5s 预填充 = 每个任务 75 s 的空等时间 → 有了缓存，15 × 0.5s = 7.5 s。

2.3 为何这对产品策略至关重要

一个常见的错误是把缓存当成”运维做的成本优化”——一个上线后再外挂上去的东西。但延迟收益意味着缓存同时是 UX 表层的一部分：

• 一个 TTFT 低于 1 s 的聊天机器人感觉鲜活；同一个机器人在 3 s 时感觉坏了。
• 一个检索+预填充耗时 4 s 的 RAG 产品，会输给同样产品耗时 1 s 的版本。
• 一个 20 s 完成任务的智能体，会胜过耗时 90 s 的那个。

你应该在决定模型和提示词结构的同时就决定缓存策略——而不是上线三个 sprint 之后才考虑。

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

TTL 问题是提示词缓存中被问得最多、解释得最少的部分之一。有两件事需要理解：

3.1 新鲜度有两层含义——别混为一谈

缓存新鲜度 ≠ 响应新鲜度。 两个截然不同的概念经常被混淆：

换句话说：缓存的响应在任何模型质量意义上都不是”陈旧”的。它们在数学上与未缓存的响应完全相同。但如果你把”当前时间是 14:32:05”放进系统提示词并依赖缓存命中，你的”当前时间”会一直停留在 14:32:05 直到 TTL 过期，而你的模型会自信满满地就此向用户撒谎。

3.2 各厂商的 TTL 行为

5 分钟的默认值并非随意——它大致是热门模型在峰值负载下的 GPU 内存压力时间窗。正如我们在 §1.4 计算的，一个大上下文的 KV 缓存可达数十 GB；厂商无力无限期持有它们。

3.3 面向 TTL 的设计

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

模式 A —— 保持会话温热。 对于聊天，自然的请求节奏（每轮之间数秒到数分钟）本身就能让缓存存活。不用担心 TTL；只要别把动态数据放进前缀就行。

模式 B —— 为批处理设置心跳。 对于跨越数小时的批处理作业，每隔 TTL/2 发送一个最小请求以保持缓存温热。成本基本为零（几个输入 token），并能避免缓存淘汰风暴。

模式 C —— 用长 TTL 厂商做冷存储。 如果你有一份 50K token 的文档，被零星查询（例如一周内每小时一次），那么 Gemini 显式缓存（24 小时 TTL）或 DeepSeek 磁盘缓存会胜过短 TTL 的替代方案，尽管要付存储费。

4. 每位开发者都应了解的普适原则

各家厂商以五种迥然不同的形态暴露缓存——显式标记、全自动、混合、架构层面的落盘，或者干脆没有。我们用下一篇文章专门做这个对比（第 2 篇 — 厂商对比与评估）。但有四条原则无论哪家厂商都适用，并直接源自我们刚刚走查过的架构：

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

因为位置 i 处的 K/V 依赖位置 1…i 的 token，厂商只能匹配从 token 0 开始的一段连续前缀。在位置 0 改动一个字符，整个前缀就失效了。稳定内容放在前面，易变内容放在后面。 这不是经验法则——它是自注意力因果结构（§1.1）的直接推论。

4.2 缓存存储的是 K/V，而非答案

缓存命中并不返回之前生成的答案——它返回之前计算好的 K 和 V 向量，模型随后用它们对当前问题生成一个全新的响应。这意味着：

• 输出质量与未缓存调用完全相同（§1.1）。
• 输出在常规意义上是非确定性的——temperature、top-p 等仍然生效。
• 缓存的响应在模型质量意义上从不”陈旧”——只有你提示词的内容（时间戳、价格）才可能陈旧。再看一遍 §3.1。

4.3 缓存写入是投资，不是免费的

对于收取写入溢价的厂商（Anthropic 125%，Gemini 显式缓存 125%），用新前缀的第一次调用比不缓存更贵。回本很快（通常一次命中就够），但如果你的”稳定”前缀每个请求都在变，你就会反复支付写入成本却毫无回报。如果你在按相关性对检索到的文档排序，要警惕这一点——那是经典的反模式。

4.4 缓存 API 在厂商间不可移植

cache_control（Anthropic）≠ cached_content（Gemini）≠ cache_id（Qwen）。如果你的应用必须面向多家厂商运行，要么你维护三套集成，要么在前面放一个 Token 网关来统一它们。第 2 篇会详细讲这一点。

5. 提示词缓存是天上掉的钱吗？

差不多。它在以下情况下能带来回报：

• 你的提示词有一段稳定前缀——系统提示词、知识库、工具 schema
• 你的调用是频繁的或彼此关联的——同一会话、批处理负载、进行中的智能体运行
• 你能把提示词组织成让稳定内容位于最前面

满足这三点，你通常会看到开销降低 50–90%、TTFT 加快 3–20×，而且无需更换模型。

下一篇预告：第 2 篇 — 厂商提示词缓存对比与评估框架会把上面的架构图景转化为对 Claude、OpenAI、Gemini、DeepSeek、Qwen 的逐项功能对比，并给出一套为你的负载挑选合适厂商的评估准则。

快速上手：用 OpenAI SDK 访问每一家厂商

Synthorai 暴露一个兼容 OpenAI 的端点——把官方 openai SDK 指向它，每个模型（Claude、GPT、Gemini、DeepSeek、Qwen）都变成一行代码的模型切换。网关会把 cache_control 翻译成每家厂商原生的缓存语法。

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 字段。网关在标准的 OpenAI prompt_tokens_details.cached_tokens 字段中返回提示词缓存命中元数据，外加一个以 USD 计的 cost 字段，这样你就不必在本地维护一张按厂商区分的定价表。

常见问题

LLM 提示词缓存与语义缓存是一回事吗？ 不是。提示词缓存是基于前缀的——它在提示词开头对精确的 token 级匹配复用 K/V 值。语义缓存在语义层面匹配（通过嵌入），并返回一个先前的响应。两者都有用，好的 Token 网关会分层把它们结合起来。

提示词缓存会改变模型的输出吗？ 不会。K 和 V 是输入 token 的确定性函数（§1.1）。模型从缓存 K/V 产生的 logits 与从重新计算的 K/V 产生的在数学上完全相同。缓存是一种纯粹的效率优化，对质量没有影响。

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

KV 缓存和提示词缓存有什么区别？ KV 缓存是推理期间使用的内存数据结构。“提示词缓存”是对该 KV 缓存的跨请求复用。即上面 §1.5 中的第 1 层与第 2 层。

缓存的提示词会以损害质量的方式陈旧吗？ 从模型角度看不会。从你内容的角度看会——如果你的提示词编码了时效性信息。缓存存储的是 K/V 向量，而非关于世界的事实。参见 §3.1。

我如何测量缓存命中率？ 每家厂商都在响应的 usage 对象中返回它——cache_read_input_tokens（Anthropic）、cached_tokens（OpenAI）、cached_content_token_count（Gemini）、prompt_cache_hit_tokens（DeepSeek）。在你的日志管道中追踪这些字段。

参考资料与来源： Vaswani et al., “Attention Is All You Need” (NeurIPS 2017) · Pope et al., “Efficiently Scaling Transformer Inference” (2022) · Kwon et al., “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 architecture · Anthropic Prompt Caching docs · OpenAI Prompt Caching docs · Google Gemini Context Caching docs · DeepSeek KV Cache guide · Alibaba Bailian Context Cache

← 返回博客