主题精读：Prompt caching 工程实践——缓存命中率、失效策略、隐私边界与成本收益 未开始

题记与说明

• 主题：Prompt caching 工程实践：缓存命中率、失效策略、隐私边界与成本收益（主题研究）
• 精读日期：2026-11-03
• 方法：先检索（WebSearch 4 轮），后精读 6 个来源（5 个全文逐字抓取：Anthropic、OpenAI、Gemini、DeepSeek 四家官方工程/定价文档 + vLLM 官方 APC 文档；1 个论文深度提取：ICML 2025《Auditing Prompt Caching in Language Model APIs》arXiv:2502.07776 摘要页 + 全文关键数据提取），交叉比对四家 API 的计费模型、TTL/失效语义、缓存隔离范围与监控字段，并推导成本收益模型
• 来源清单（6 个，均已精读）：
  1. Anthropic 官方文档：*Prompt caching* — https://docs.claude.com/en/docs/build-with-claude/prompt-caching （platform.claude.com 在本环境 307 区域重定向，改经 docs.claude.com 全文抓取成功）
  2. OpenAI 官方文档：*Prompt caching*（Prompt caching guide）— https://platform.openai.com/docs/guides/prompt-caching
  3. Google AI for Developers：*Context caching*（Gemini API，页面标注 Last updated 2026-10-23）— https://ai.google.dev/gemini-api/docs/caching
  4. DeepSeek API Docs：*Models & Pricing*（cache hit / cache miss 双价 + 峰谷定价）— https://api-docs.deepseek.com/quick_start/pricing
  5. Gu, Li, Kuditipudi, Liang, Hashimoto（Stanford）：*Auditing Prompt Caching in Language Model APIs*，ICML 2025，arXiv:2502.07776（v2, 2025-07-13）— https://arxiv.org/abs/2502.07776
  6. vLLM 官方文档：*Automatic Prefix Caching* — https://docs.vllm.ai/en/latest/features/automatic_prefix_caching.html
• 检索辅助来源（来自 WebSearch 摘要，未逐字精读，仅作旁证并明确标注）：DeepSeek 2024-08-02 官方公告《DeepSeek API introduces Context Caching on Disk》（cache hit $0.014/M、"up to 90%" 成本下降）；OpenAI cached tokens 五折计费的社区/二手汇总；vLLM 设计文档 *prefix_caching design*（hash 链 + LRU 细节，https://docs.vllm.ai/en/stable/design/prefix_caching ，直接抓取超时，细节来自检索摘要）；NDSS 2025《Prompt Leakage via KV-Cache Sharing in Multi-Tenant LLM Serving》与 arXiv 2605.30613（网关 API 缓存隔离审计，均未读全文，仅知存在）

一、七维提取

1. 核心问题：这份"主题"在解决什么问题

LLM 推理成本的大头在 prefill：同一份 system prompt、工具定义、文档上下文、多轮对话历史，会被一次又一次完整重算。Prompt caching 的目标是"前缀只算一次"——但把它从营销数字变成工程收益，要回答四个互相咬合的子问题：

• 命中率：缓存是精确前缀匹配（Anthropic："Cache hits require 100% identical prompt segments"；OpenAI："Cache hits are only possible for exact prefix matches within a prompt"）。所以命中率不是缓存系统的属性，而是 prompt 布局的属性——任何放在前缀里的时间戳、日期、随机 ID、重排的 JSON key 都会毁掉它。
• 失效策略：这里的"失效"不是 Redis 那种 key 过期或显式淘汰，而是前缀断裂——层级上（tools→system→messages）任何一处变动，使该层级及之后所有内容"理论可命中但实际全部 miss"；TTL（5 分钟/1 小时/24 小时）只是第二维的失效。厂商都不提供手动清缓存（OpenAI FAQ："Manual cache clearing is not currently available"）。
• 隐私边界：缓存里存的是从你的 prompt 派生的 KV 张量，"谁能命中你的缓存"就等于"谁能探测你的 prompt 是否出现过"。隔离范围（全局/组织/用户）是数据流问题，不只是性能参数——ICML 2025 审计发现 17 家供应商中 7 家存在跨用户全局共享。
• 成本收益：三种计费模型（显式写费+折扣读、自动无写费、自建免费）下，收益公式完全不同：Anthropic 式"写了没人读"反而贵 25%，OpenAI 式"miss 无损失"是免费期权，必须分开算账。

2. 主要主张（各来源的核心论点）

3. 方法：这个主题的"论证方式"是什么

• 厂商文档走"机制+计费"路线：Anthropic 给出完整的机制细节（层级、断点、20-block 回看窗口、失效矩阵表、usage 字段），OpenAI 首次披露了路由层工程（前缀哈希路由 + prompt_cache_key + 15 rpm 溢出阈值），Gemini/DeepSeek 走"全自动 + 定价传导"路线。论证靠参数与表格，不靠跑分。
• 审计论文走"统计检验"路线：把"是否存在缓存"变成可检验假设——单侧双样本 Kolmogorov–Smirnov 检验，比较 cache-hit 与 cache-miss 两组 TTFT 分布，α=10⁻⁸ 加 Bonferroni 校正；配置为 5000 token 提示词、250 样本、PrefixFraction=0.95，单次测试成本仅 $1.69–8.44（约 3400 万 prompt token）。用最小代价把"供应商有没有偷偷全局共享缓存"变成可复现的测量。
• 自建路线（vLLM）走"系统设计"路线：APC 用 enable_prefix_caching=True 开启；按检索到的设计文档，KV cache 按 block 哈希（自身内容哈希+父块哈希构成哈希链），淘汰是 free queue 上的 LRU——与 Redis 完全不同的"内容寻址 + LRU"组合。

4. 数据与证据

（1）计费与 TTL 三模型对照（全部来自 2026-11-03 抓取的官方页面）

（2）成本收益模型（基于上表推导，非原文）

• Anthropic 式回本点：TTL 窗口内同一前缀复用 k 次，缓存成本 = 1.25 + 0.1(k−1)，不缓存 = k → k≥2 即回本（k=2 省 32.5%，k=10 省 78.5%）。写了没人读 = 白付 25%（1h TTL 则白付 100%）。
• 有效输入单价（Anthropic 5m 模式，p 为被命中 token 份额）：0.1p + 1.25(1−p)。p=50% → 0.675×（省 32.5%）；p=80% → 0.33×（省 67%）；p=90% → 0.215×（省 78.5%）。命中率就是钱，且一过 50% 就已经是三位数百分比的净赚。
• 1h TTL 的决策规则：两轮请求间隔 >5 分钟时，5m 缓存每轮重写 1.25×，1h 只写一次 2×+每轮 0.1×——从第二轮起 1h 就赢（2.1 vs 2.5）；间隔 <5 分钟则 5m 免费续期完胜。Anthropic 官方口径一致："1-hour cache is best used...when an agentic side-agent will take longer than 5 minutes, or when storing a long chat conversation...you generally expect that user may not respond in the next 5 minutes."
• DeepSeek 峰谷叠加：off-peak 半价后，flash 的 hit 价低至 $0.003/M——miss 价的 1/50，是本次所有来源中缓存命中折扣最深的定价。

（3）命中率杀手清单（官方文档明确列出的失效/未命中原因）

• 前缀内动态内容：时间戳、日期、per-user 信息放前面（OpenAI："put variable content...at the end"）
• 序列化不稳定：Anthropic 明确警告 "some languages (e.g. Swift, Go) randomize key order during JSON conversion, breaking caches"
• 工具定义变更：Anthropic 失效矩阵——"Modifying tool definitions (names, descriptions, parameters) invalidates the entire cache"；连开关 web search / citations 都会改 system prompt 从而使其失效
• tool_choice、图片、thinking 参数变动 → messages 层缓存失效
• 低于门槛（如 Haiku 4.5 要 4096 token）→ "requests to cache fewer than this number of tokens will be processed without caching"
• 并发预热陷阱：Anthropic "a cache entry only becomes available after the first response begins. If you need cache hits for parallel requests, wait for the first response"
• 路由溢出（OpenAI）：同前缀+key 超过约 15 req/min 会溢出到其他机器，"reducing cache effectiveness"
• 超过 20-block 回看窗口：Anthropic 的自动回查只往前找 20 个 block，长对话要在中部补显式断点

（4）隐私审计实测数据（ICML 2025，2024-09~10 测量）

• 范围：17 家供应商（Anthropic、Amazon Bedrock、Azure OpenAI、Cohere、Deep Infra、DeepSeek、Fireworks、Google、Groq、Hyperbolic、Lepton、Mistral、OctoAI、OpenAI、Perplexity、Replicate、Together）。
• 检出缓存的 8 家中，7 家跨用户全局共享：Azure（text-embedding-3-small）、Deep Infra、Fireworks、Lepton、OpenAI（embedding）、Perplexity、Replicate；仅组织级共享：Anthropic Claude 3 Haiku、OpenAI GPT-4o mini。
• 检测质量：分类平均精度约 0.8（0.71–1.00，Replicate 服务端达 1.00）；报告的是 p 值（如 Perplexity p=5.3×10⁻⁷⁴、Replicate p=8.6×10⁻¹⁵⁰）而非毫秒差。
• 完整 prompt 提取未实现："we were unable to execute practical prompt extraction attacks"——精确前缀匹配意味着错一个 token 就全断，逐 token 爆破不可行；但"某前缀是否出现过"的成员推断是成立的。
• 架构泄露：前缀缓存只在 decoder-only Transformer 上可行，由此推断出 OpenAI embedding 模型架构 "which was previously not publicly known"；命中时 embedding 各坐标有 ~10⁻⁴–10⁻⁵ 漂移，暗示 KV cache 以更低精度存储。
• 事后：OpenAI embedding 全局共享在负责任披露后已修复，至少 5 家供应商做了调整；DeepSeek 实测 per-user（通过返回的 cache-hit token 计数验证）且无可检出的时序差异。

5. 结论

1. Prompt caching 是 LLM 应用里 ROI 最高、且完全由工程侧掌控的优化：布局决定命中率，命中率直接换算成 0.1×–0.5× 的有效输入价，TTFT 显著下降（OpenAI 口径最高 80%）。
2. 它是约束驱动的架构决策，不是一个开关：prompt 静态前置、序列化稳定、工具 schema 当作"缓存破坏性部署"管理、请求节奏（间隔 vs TTL）与路由粘性（prompt_cache_key、前缀感知负载均衡）都要配合。
3. 失效的正确心智模型是"前缀断裂"而非"过期淘汰"：TTL 只是兜底，真正的失效来自层级上任意的提前变动；厂商不给手动清除，一切靠"把会变的东西放到最后"。
4. 隐私边界 = 缓存共享范围：头部厂商的组织级隔离承诺明确且经审计验证（Anthropic、GPT-4o mini 均为 org 级），但 2024 年审计中 7/17 存在全局共享、OpenAI extended retention 影响 ZDR 资格、网关/中转链路的缓存归属尚未被充分审计——"缓存在谁那边、跟谁共享、存多久"应成为供应商评估的标准三问。
5. 三种计费模型没有绝对优劣，取决于流量形态：高复用（agent 循环、多轮、批量处理同一文档）下 Anthropic 显式式最深（0.1×）；自动式（OpenAI/Gemini/DeepSeek）是免费期权、miss 无罚；DeepSeek 分价+峰谷给了"错峰省钱"这第四个杠杆。

6. 局限（作者承认的 + 我推断的）

• 快照风险：所有价格与特性为 2026-11-03 页面快照。页面自身就显示变化很快：Gemini explicit caching 正被 4 代弃用、DeepSeek 型号已更替为 v4 系列（2024 年公告的 $0.014/M hit 价已不适用于现价）、OpenAI 新增 24h extended retention。
• OpenAI cached 折扣倍数未逐字核对：官方 guide 只给"input token costs by up to 90%"的总量声明；"cached tokens 五折"来自检索摘要中的二手/社区资料，未在 OpenAI 定价页原文确认。
• 审计论文时效：测量窗口是 2024 年 9–10 月，论文自己说明至少 5 家此后已修改策略——"7/17 全局共享"不能外推到今天。
• 未实测：本次没有生产流量，所有命中率/成本数字均为模型推导与官方口径，没有自己跑的 TTFT 双峰检验。
• 抓取失败与降级：Cursor《Prompt caching》工程博客抓取失败（网络 500），缺少"应用层二次改造缓存"的实践视角；vLLM 设计文档直接抓取超时，hash 链/LRU 细节仅来自检索摘要；Anthropic platform.claude.com 在本环境被区域重定向，内容取自 docs.claude.com 镜像页。
• 未读全文的相关工作：NDSS 2025 KV-cache 共享攻击、arXiv 2605.30613 网关隔离审计仅有标题级信息，多租户自建场景的攻击面论证不完整。

7. 对我的启发

1. 给 nightly 批量管线（我自己就在跑的）：多任务共享的系统提示、技能文档、输出规范应该做成逐字节稳定的超长前缀；同一批任务先串行发第一个请求"暖缓存"，再并行发余下（Anthropic 并发条款的直接应用）；批量任务还能压进 DeepSeek off-peak 时段吃半价。
2. 给 agent/编码工具的日常使用：Claude Code 式工具循环是缓存最佳场景——但改一次工具定义 = 全缓存失效，所以"随手改 system prompt 措辞/工具描述"其实是很贵的操作；会话闲置超 5 分钟再继续，就重付一遍写费，长思考任务该考虑 1h TTL。
3. 把缓存指标纳入可观测性：凡是记 trace 的地方加三列——cache_read_input_tokens、cache_creation_input_tokens、有效输入单价（= 总输入费用/总输入 token）。命中率突降几乎总是意味着 prompt 模板被人动了（把模板漂移当作告警信号，这和前端性能监控里"缓存命中率是所有指标之首"是同一条经验）。
4. 供应商评估清单加一条"缓存三问"：共享范围（org/user/全局）？保留时长与存储形态（KV 张量是否落盘/持久化，ZDR 是否仍成立）？命中是否占限流额度（Anthropic 不占、OpenAI 占，影响容量规划）？经手敏感客户数据时，还应确认中转/网关层有没有自己的共享缓存。
5. 写作素材：这批材料正好补全"缓存跨层共性"主题的一个新层级——CPU cache line 的空间局部性 ↔ 前缀匹配；写穿/写回 ↔ 写费/读费；缓存隔离（进程/组织）↔ 侧信道（Spectre ↔ timing audit）。同一条物理约束（复用 vs 隔离的张力）在每一层都重新出现一次。

二、逐来源精读

2.1 Anthropic《Prompt caching》——显式缓存的完整设计空间

Anthropic 是四家中唯一"显式声明 + 写费"模型，因此文档把机制写得最透，是理解其他家行为的心智模板：

• 结构：静态内容（工具定义、system、上下文、示例）放开头，用 cache_control 标记可复用内容末端。层级 tools → system → messages 逐级构建，"Cache keys are cumulative"——每块的缓存键哈希了它之前的所有块。
• 回看窗口机制（其他家文档没有的细节）：断点之后系统从断点向前逐块回查，最多 20 个 block。改了 30 块对话里的第 25 块：从 30 回查到 25 失配、24 命中——只重算 25–30；改第 5 块：20 次回查内找不到，全部重算，除非第 5 块处显式设过断点。结论（原文）："Always set an explicit cache breakpoint at the end of your conversation... Additionally, set breakpoints just before content blocks that might be editable."最多 4 个断点，且 "Cache breakpoints themselves don't add any cost."
• TTL 与计费：默认 5 分钟，命中免费续期（"The cache is refreshed for no additional cost each time the cached content is used"）；1h 写费 2×。混用规则：长 TTL 必须在短 TTL 之前，计费按最高命中点 A、最后 1h 断点 B、最后断点 C 三段切分（读 A + 1h 写 (B−A) + 5m 写 (C−B)）。
• 失效矩阵（要点）：工具定义改动 → 全失效；web search/citations 开关 → system 起失效；tool_choice、图片、thinking 参数 → 仅 messages 失效；扩展思考下混入非 tool-result 的用户消息 → 之前的 thinking 块整体被剥离出缓存。
• think 缓存细节：thinking 块不能显式标记，但会随请求内容被自动缓存，读回时计入 input token。
• 监控：cache_creation_input_tokens（新建写入）、cache_read_input_tokens（命中）、input_tokens（最后断点之后的未缓存部分）。
• 隔离与副作用："Organization Isolation: Caches are isolated between organizations"；命中率红利还延伸到限流——"cache hits are not deducted against your rate limit"。

我的归纳：Anthropic 文档给出的不是"怎么开缓存"，而是缓存友好的 prompt 工程规范——静态前置、断点前置可变块、序列化稳定、变更管理。这四条在任何厂商都适用，只是别家不写这么细。

2.2 OpenAI《Prompt caching》——把缓存做成路由问题

OpenAI 走另一个极端：全自动、无配置、无写费。它披露的路由层是本次精读最大的增量信息：

• 自动启用：≥1024 token 自动生效（128 token 增量），无代码改动；"reduce latency by up to 80% and input token costs by up to 90%"（guide 页原文，2026-11 快照）。
• 路由即缓存："Requests are routed to a machine based on a hash of the initial prefix of the prompt. The hash typically uses the first 256 tokens."——缓存命中首先要求请求被路由到同一台机器。prompt_cache_key 参数与前缀哈希组合参与路由，让"同一会话/同一租户"粘在同一台机器；每前缀+key 组合约 15 req/min 的上限，超了会溢出到新机器（新的冷缓存）。
• 两级保留：in-memory（默认）：空闲 5–10 分钟、off-peak 最长约 1h，只存在易失 GPU 显存；extended retention（prompt_cache_retention: "24h"，限 gpt-4.1/gpt-5 系列等）：KV 张量卸载到 GPU 本地存储，最长 24h，"Only the key/value tensors may be persisted in local storage; the original customer content...is only retained in memory."
• 隐私与合规语义（原文级细节）：组织隔离；不能手动清；in-memory 满足 ZDR，extended 不满足（"because the key/value tensors may be held in GPU-local storage"——派生物也算数据）；in-memory 兼容所有 Data Residency 区域，extended 仅限 Regional Inference 区域。
• 限流反差：与 Anthropic 相反，"Do cached prompts contribute to TPM rate limits? Yes"。

我的归纳：OpenAI 的模型是"你不用管缓存，但缓存在管你的路由"。工程含义：prompt_cache_key 的粒度选择（按会话？按租户？按文档？）本质是在做一致性哈希的分区键设计——粒度太粗撞 15 rpm 溢出，太细则机器间缓存碎片化。

2.3 Gemini《Context caching》——implicit 化与"增量门槛"

• implicit 默认开启："Implicit caching is enabled by default for all Gemini 2.5 and newer models"，自动把节省传导给用户；起缓存门槛 2.5 系列 2048 token、3.x/4 系列 4096 token。
• 显式缓存退场："Explicit caching (manually creating and managing cache objects) is not supported in the Interactions API, or for Gemini 4 Argon and onward."——方向和 Anthropic 相反：Anthropic 在给显式控制加码（多断点、双 TTL），Google 在把控制权收走换成自动。工程含义：不要把架构押在"手动管理缓存对象"上，这是正在关闭的 API 表面。
• 多轮增量门槛（独有设计）："Gemini caches the full previous request only if the new request adds at least 2,050 tokens. Model output, thought, and function results all count toward this total. For smaller additions, Gemini re-processes the last 2,050 tokens of the previous request at the standard input rate."——即增量太小（短回合）反而把尾部 2050 token 按全价重算，agent 短回合场景要注意。
• 监控：usage.total_cached_tokens。

2.4 DeepSeek——缓存即定价

• 现行定价（2026-11 抓取）：deepseek-flash：hit $0.003（off-peak）/ $0.006（peak）vs miss $0.15 / $0.30；deepseek-v4-pro：hit $0.022 / $0.044 vs miss $0.66 / $1.32；输出价 $0.6–1.2 / $1.98–3.96。峰时定义为 "01:00 - 04:00 and 06:00 - 10:00 UTC, Monday through Friday"（北京白天），其余全部 off-peak 半价。
• 缓存全自动、默认开启（2024-08 公告："Context Caching on Disk...enabled by default for all users"，当时 hit 价 $0.014/M、"up to 90%" 成本下降——数字已随型号更替，机制未变）。
• 第三方实测（ICML 2025 论文）：per-user 缓存、无可检出时序差异——在审计样本里是隐私表现最好的一档。
• 工程含义：DeepSeek 的账要按"hit 份额 × 1/30~1/50 + miss 份额"来算，且把可推迟的批量任务挪进 off-peak，等效于又砍半。对个人 API 预算，这是四家里杠杆最多的一家（hit 折扣 × 峰谷 × 全自动无写费）。

2.5 vLLM APC——自建时的同一原理

• 定义："Automatic Prefix Caching (APC in short) caches the KV cache of existing queries, so that a new query can directly reuse the KV cache if it shares the same prefix with one of the existing queries, allowing the new query to skip the computation of the shared part."开启方式：enable_prefix_caching=True。
• 收益边界（原文）："APC only reduces the time of processing the queries (the prefilling phase) and does not reduce the time of generating new tokens (the decoding phase)."——长输出、短前缀的负载几乎无收益；收益集中在"同一长文档反复问答"与"多轮对话"两类负载。
• 机制（设计文档，经检索摘要，未逐字核对）：KV cache 按 PagedAttention 分块，块哈希 = 自身内容哈希 ⊕ 父块哈希，构成哈希链——前缀相同则块哈希天然相同；淘汰为 free queue 上的 LRU。自建缓存属于你自己，无跨租户泄露面；但多副本部署时，无前缀感知的负载均衡器会把同一前缀的请求撒到不同实例，命中率归零——这是自建方案里和 OpenAI prompt_cache_key 同构的问题，要自己做会话粘性或前缀感知路由。
• 注意：vLLM APC 本身不改变计费（自建没有"缓存价"），收益是吞吐与 TTFT——和 API 缓存"省钱"不同，自建缓存"省算力"。

2.6 ICML 2025 审计论文——隐私边界的实证

• 问题：缓存命中 = 响应更快 → 时序是可观测的 → "这个 prompt（前缀）今天/曾经被谁请求过"变成了可测量的布尔量。若缓存跨用户共享，攻击者可以用候选前缀探针检测其他用户的 prompt 是否出现过（成员推断）。
• 方法：对 17 家供应商做统计审计。单侧双样本 KS 检验比较 hit/miss 两组 TTFT 分布（原假设：无缓存），α=10⁻⁸ + Bonferroni；5000 token 随机字母提示词、250 样本、PrefixFraction=0.95、受害者请求数 {1, 5, 25}；单次测试成本 $1.69–8.44。方法本身就是可以抄走用的——任何人都能用几十美元审计自己的供应商。
• 结果：8 家检出缓存；7 家全局共享（含 OpenAI text-embedding-3-small，披露后已修复）；Anthropic Claude 3 Haiku 与 GPT-4o mini 为 org 级；DeepSeek per-user 且无可检出时序差。
• 攻击的现实边界（重要，防止过度恐慌）："we were unable to execute practical prompt extraction attacks"——精确前缀匹配使逐 token 爆破组合爆炸，成员推断可行、内容重建不可行（在论文威胁模型下）。附带产出：架构推断（OpenAI embedding 是 decoder-only）与低精度 KV 存储的证据（命中时 embedding 值 ~10⁻⁴–10⁻⁵ 漂移）。
• 给出的缓解清单：per-user 隔离（保住大部分加速收益）；缓存策略披露（共享层级、TTL）；纯延迟防御（故意把命中响应拖慢到与 miss 不可区分，供应商仍省 GPU）；彻底关闭缓存（只有它能完全阻断架构/IP 泄露）。
• 相关但未读全文：NDSS 2025《Prompt Leakage via KV-Cache Sharing in Multi-Tenant LLM Serving》把攻击面推进到自建多租户共享 KV cache 场景；arXiv 2605.30613 审计网关 API（OpenRouter 类聚合器）的缓存隔离——这两块是当前隐私边界的最前沿，本次仅存目。

三、工程实践清单（可直接执行）

布局（命中率的主要来源）

1. 静态→动态单向排列：tools → system → few-shot → 文档 →（断点）→ 会话历史 → 当前输入。
2. 前缀禁入：时间戳、随机 UUID、"今天是 X 日"、用户名——要么删除，要么挪到前缀之外。
3. 序列化稳定：JSON key 排序输出、温度参数外置、图片与 tool_choice 保持一致；Swift/Go 等语言注意 key 顺序随机化问题（Anthropic 明确警告）。
4. 工具 schema 变更 = 缓存破坏性发布：改描述、改参数 = 全部前缀重算，尽量批量攒着改。

节奏与路由

1. 会话间隔 <5min：什么也不用做（5m 免费续期）；间隔 >5min 且前缀大：Anthropic 用 1h TTL（第二轮起就回本）。
2. 并行批量前先发一个请求暖缓存（Anthropic 并发条款）。
3. OpenAI 用 prompt_cache_key 做会话粘性，粒度控制在同 key ≤15 req/min；自建 vLLM 做前缀感知负载均衡。
4. Gemini 短回合注意 2,050 token 增量门槛，回合太短会按全价重算尾部。

观测与核算

1. trace 里记 cache_read_input_tokens / cached_tokens / total_cached_tokens；看板指标：token 命中率、有效输入单价、TTFT 分布（双峰=缓存在工作）。
2. 命中率骤降 → 先查 prompt 模板 diff，再查供应商侧（路由/策略变更）。
3. 预算模型：Anthropic 有效输入价 = 0.1p + 1.25(1−p)（p=token 命中份额，5m 模式）；写费只在"写了没人读"时是纯损失。

隐私与合规

1. 供应商评估"缓存三问"：共享范围？保留形态与时长（KV 张量是否持久化，ZDR 是否成立）？命中占不占限流？
2. 敏感数据优先选 org 隔离或 per-user 的供应商；用聚合网关时把网关自己的缓存策略也问一遍。
3. 高敏场景防御：把可探测性考虑进威胁模型（成员推断可行、内容重建在精确前缀匹配下目前不可行）；可要求供应商采用 per-user 隔离或延迟拉平。

四、重要原文引述汇编（供写作引用）

• Anthropic："Cache hits require 100% identical prompt segments, including all text and images up to and including the block marked with cache control."
• Anthropic："Modifying tool definitions (names, descriptions, parameters) invalidates the entire cache."
• Anthropic："By default, the cache has a 5-minute lifetime. The cache is refreshed for no additional cost each time the cached content is used."
• OpenAI："Requests are routed to a machine based on a hash of the initial prefix of the prompt. The hash typically uses the first 256 tokens."
• OpenAI："Prompt caches are not shared between organizations. Only members of the same organization can access caches of identical prompts."
• OpenAI："Only the key/value tensors may be persisted in local storage; the original customer content, such as prompt text, is only retained in memory."
• Gemini："Implicit caching is enabled by default for all Gemini 2.5 and newer models."
• ICML 2025（摘要）："We detect global cache sharing across users in seven API providers, including OpenAI, resulting in potential privacy leakage about users' prompts."
• ICML 2025（全文）："we were unable to execute practical prompt extraction attacks."
• vLLM："APC only reduces the time of processing the queries (the prefilling phase) and does not reduce the time of generating new tokens (the decoding phase)."

五、来源链接

1. https://docs.claude.com/en/docs/build-with-claude/prompt-caching
2. https://platform.openai.com/docs/guides/prompt-caching
3. https://ai.google.dev/gemini-api/docs/caching
4. https://api-docs.deepseek.com/quick_start/pricing
5. https://arxiv.org/abs/2502.07776 （全文数据提取：https://arxiv.org/html/2502.07776v2 ）
6. https://docs.vllm.ai/en/latest/features/automatic_prefix_caching.html

检索辅助（未逐字精读）：https://api-docs.deepseek.com/news/news250801 （2024 缓存公告，检索摘要）；https://docs.vllm.ai/en/stable/design/prefix_caching （设计文档，检索摘要）；https://www.ndss-symposium.org/wp-content/uploads/2025-1772-paper.pdf （仅存目）；arXiv 2605.30613（仅存目）。