Prompt Caching 四层与失效防护

• 四层缓存的命中键设计差异
• 各自过期与失效机制
• 一致性边界与多层协同（命中顺序、回源）

四层缓存定位不同：Provider 原生 Prompt Cache 命中键是"前缀 token 精确匹配"，由厂商自动维护，过期靠 TTL 与最旧前缀淘汰，一致性边界是"语义相同但字面不同则失效"；Server 端 KV Cache 命中键是"同前缀的连续 token 序列"，内存态，靠 LRU 与内存水位淘汰；Semantic Cache 命中键是"语义相似度大于阈值"，命中结果可复用，靠向量索引版本与 TTL 失效；Result Cache 命中键是"输入+参数+版本完全一致"，直接返回最终结果，靠 key 中带版本号主动失效。协同：请求先查 Result Cache（最快）→未命中查 Semantic Cache（相似命中）→再走 Provider 原生 Cache（省前缀计费）→Server KV Cache 加速推理，逐层回源并在每层记录命中率，避免层级间缓存互相污染。

四层缓存快慢、精确度、成本不同，协同遵循"先快后慢、先整后零"的命中顺序，同时每层有独立失效边界，避免最外层缓存返回过期答案。

• 最低计费块（如 1024 token）对命中的影响
• 自动前缀匹配与"稳定前缀"策略
• 显式断点（cache_control）定位

设计要点：一是把稳定内容（系统提示、工具定义、固定文档、Few-shot 示例）放在请求最前面，形成稳定的共享前缀，让多请求命中同一前缀块；二是动态内容（用户问题、时间戳、随机数）后置，避免打断前缀匹配；三是在长上下文中用显式断点（如 Anthropic 的 cache_control 标记）把"可缓存段"与"不可缓存段"分开，既保证系统提示常驻缓存，又避免整段前缀因尾部变化而全部失效；四是用最低计费块（如 1024 token 起步）来核算——前缀命中需达到最小块才有折扣，排布时尽量让共享前缀长度达到整块收益。

前缀缓存命中的关键是"前缀稳定且够长"；动态内容置后、断点分隔、达到最低计费块，三者缺一不可，否则长上下文请求会因前缀抖动而失去缓存收益。

• 不同业务对复用安全性的要求
• 阈值/索引版本/TTL 的差异化
• 误命中代价与业务权衡

不同业务对"复用必须准确"的容忍度不同：FAQ 问答答案稳定、误命中代价低，可用较高相似度阈值（如 0.9+）并设较长 TTL，答案可安全复用；代码生成要求高准确、版本敏感，阈值要更高（如 0.95+）且 TTL 短，因为代码版本/依赖变化会很快让旧结果失效，同时索引版本要紧跟代码库版本更新；创意写作个性化强、复用价值低，阈值要极高近乎全等，TTL 短甚至不缓存，避免返回模板化内容伤害体验。索引版本更新与 TTL 都要按业务敏感度设置，敏感业务版本更新即全量失效。

Semantic Cache 的通用阈值不可用，必须按"复用错误代价"与"内容时效性"差异化：FAQ 安全可长缓存，代码敏感需短 TTL 高阈值，创意类几乎不缓存。

• 三层各自的命中判定
• 各层失效策略
• 层间组合与联动

组合上：前缀缓存（Provider 原生）负责"稳定前缀"的 token 级复用，命中判定是前缀 token 精确匹配，失效靠 TTL/前缀淘汰；系统提示缓存专门缓存常驻的系统提示与工具定义，命中判定是"系统提示文本一致"，失效靠系统提示版本号变更即失效；语义缓存负责"语义相似请求"的整包复用，命中判定是 embedding 相似度超阈值，失效靠向量索引版本+TTL+内容版本。三层形成"前缀(token 级)→系统提示(固定段)→语义(整包)"的多级命中，前两层保稳定复用、第三层提供相似匹配，失效策略都遵循"版本号变更即全量失效"的原则，避免旧缓存污染。

三层缓存命中粒度不同、失效触发点不同，组合使用能覆盖"精确复用"与"相似复用"两类场景；版本号驱动的失效是防止读到旧答案的统一抓手。

• 确定性任务的判定
• 版本变化导致答案失效
• 缓存键含版本号

Result Cache 安全的前提是"相同输入必然产生相同正确输出"，即确定性任务：纯格式化、固定模板翻译、规则化摘要、无随机性的 FAQ 等。对这类任务，缓存键必须包含输入、核心参数、模型版本、Prompt 版本、知识库版本等维度，一旦其中之一变化，键就变，旧缓存自然失效，避免返回"旧模型语料/旧模板/旧知识库"下的过期答案。原因：模型版本升级会改变输出风格与知识，Prompt 改动会改变行为，知识库更新会改变检索事实，三者任一变化都可能导致旧答案错误，必须主动失效。

Result Cache 的收益来自"完全复用"，但版本变化会让旧结果失真；把版本号编入缓存键是既简单又安全的失效手段，非确定性任务（生成、抽签）则不应缓存。

• 跨实例不可见的含义与影响
• 命中率、内存水位、首字延迟指标
• 调优方向（路由、预热、淘汰策略）

Server 端 KV Cache 存在每实例内存、跨实例不可见（缓存不跨节点共享），因此应用层要观测：命中率（前缀命中占比，过低说明缓存未生效）、内存水位（缓存占用是否逼近上限，触发淘汰与回填）、首字延迟（TTFT，命中时显著下降）、以及淘汰率/回填率联合。调优：用一致性路由把相同前缀请求固定到同一实例（session affinity），提升命中；对高频前缀做预热（提前注入）；按内存水位调淘汰策略（LRU 与容量平衡）；命中率低时检查前缀是否稳定、是否跨实例打散。

跨实例不可见意味着"同一前缀被路由到不同实例就丢失命中"，所以一致性路由是提升命中率的关键；指标层面用命中率看效果、内存水位看风险、首字延迟看收益。

• 命名空间隔离（跨账户/跨租户）
• 签名（版本、内容哈希）防止旧缓存
• 刷新策略与击穿防护

阻断策略：一是命名空间隔离，缓存键前缀带租户/账户/环境 ID，跨账户查询天然隔离，防止跨账户污染与数据泄漏；二是签名校验，缓存键含内容哈希/版本号（模型、Prompt、知识库、schema 版本），旧版本内容哈希不匹配即视为过期，阻断旧缓存污染；三是刷新策略，版本变更时主动批量失效或采用"双写新版本+延迟删除旧版本"过渡，避免击穿；四是击穿防护，缓存 miss 时用分布式锁/请求合并（singleflight）防止同一热点同时打爆回源，配合预热与降级。

命名空间管"隔离"，签名管"版本正确性"，刷新与击穿防护管"并发安全"，三者构成多层缓存的一致性防线，缺一不可。

• 命中率 vs 字节命中率
• 成本节省率口径
• 三者联合解读

三个指标口径不同：命中率（请求数维度，命中请求数/总请求数）反映"复用频率"；字节命中率（token 维度，缓存命中 token 数/总 token 数）反映"实际省了多少 token 计算"；成本节省率（成本维度，节省金额/总金额）反映"实际省钱"。不能只看命中率，因为命中率高但命中的都是小前缀、省不了多少 token；应联合统计：命中请求数、命中 token 数、缓存读写 token 数、折扣后成本，算出真实节省率。低成本省钱场景（如系统提示很大且常命中）字节命中率与成本节省率才高，优化对准这两个指标。

请求命中率高不代表省钱，因为 max 前缀 token 与折扣才决定成本；字节命中率与成本节省率才是成本优化的真实口径。

• 存储侧加密与访问控制
• 协议侧（缓存键、权限）校验
• 清除路径（删除/过期）

存储侧：对缓存值做加密（AES-GCM 等），密钥与缓存分存，按租户/账户隔离密钥；设置访问控制（缓存服务只许应用服务访问，禁止直接读取），并配置 TTL 与自动清除，敏感数据到期即删。协议侧：缓存键设计避免明文敏感信息（用哈希/脱敏 ID 代替原文），读写接口做鉴权与权限校验，防止跨账户越权读取；命中返回前校验租户/权限归属。清除路径：提供显式删除 API，用户删除/注销时同步清除其缓存，配合 TTL 兜底；敏感数据在日志与监控中也不落明文。

敏感缓存的安全要靠"存储加密+协议鉴权+主动清除"三侧共同保障，任何一侧缺失都可能泄露；键用脱敏 ID、值加密、按租户隔离是底线。

• 各层缓存失效触发点
• 版本号驱动的失效
• 一致性窗口与避免旧答案

原则是"版本号驱动失效"：把知识库版本、Prompt 版本、模型版本编入所有缓存键。任一层更新时，对应版本号变化，命中键不再匹配，旧缓存自然失效。同时做主动失效：知识库更新后批量删除涉及该知识域的 Semantic/Result 缓存；Prompt 更新后清空与该 Prompt 绑定缓存；模型更新后失效全部含旧模型签名的缓存。为避免"短暂读到旧答案"的一致性窗口，可先写新版本缓存、延迟删除旧版本，或更新时加短暂降级（直接回源），保证新版本立即可用。

版本号编入键是安全的被动失效，主动按域批量失效是更快的主动清理；两者结合把一致性窗口压缩到最小，避免旧答案被返回。

• 多模态 token 的缓存支持与折扣
• 动态内容破坏前缀命中
• 将动态内容结构化/后置

多模态输入（图像、音频）会被编码为 token 参与前缀匹配，部分 Provider 对多模态输入的缓存有折扣（如图像 token 缓存折扣），但需确认其缓存支持与计费规则。动态内容（时间戳、随机数、会话 ID）埋在 prompt 定义体中间会破坏前缀匹配，导致后续对话无法命中缓存；解法是把动态内容后置、结构化（放进独立字段或对话尾部），把稳定的系统提示、工具定义、图像描述等前置，保证共享前缀稳定。多模态语义缓存还应考虑图像底层哈希/相似度，而不只是文本。

多模态缓存依赖"前缀 token 稳定"，动态内容必须与稳定内容分离；把动态内容后置可最大化前缀命中，同时关注多模态 token 的缓存支持与折扣。

• 前缀对齐（稳定共享前缀）
• 系统提示稳定性
• 动态内容后置

三者配合：一是前缀对齐，把内容按"固定在前、动态在后"排序，保证所有请求共享同一前缀，并对齐 token 边界减少因格式差异导致的漏命中；二是系统提示稳定性，系统提示、工具定义、Few-shot 保持字节级稳定，不随请求变化，确保常驻缓存；三是动态内容后置，把用户问题、时间戳、随机数等变化内容放在 Prompt 尾部，避免打断前缀。三者共同保证"前缀最大且稳定"，从而让 Provider 前缀缓存与 Server KV 缓存命中率最大化。

前缀缓存命中率 = 稳定前缀长度/总长度；前缀对齐决定共享性，系统提示稳定决定缓存段，动态内容后置决定不打断，三者缺一不可。

• 降级策略
• 预热机制
• 并发限制/限流

协同方案：版本变化时先做预热——在低峰期把新版本的高频前缀/常用答案预先写入缓存，缩短空窗；回源压力大时启用降级，如返回降级结果、跳过非关键缓存、或临时放宽质量用更便宜模型兜底；同时用并发限制/限流（分布式锁、singleflight、令牌桶）合并同一热点请求，防止缓存 miss 瞬间打爆回源服务。三者配合：预热减少 miss、限流缓解峰值、降级保证可用性，且按重要性分级（核心请求优先、非核心降级）。

版本切换的瞬间所有缓存失效，回源流量会骤增；预热+限流+降级分别从"减少请求""平滑峰值""保可用"三方面兜底，缺一不可。

• 延迟节省量化
• 计费节省量化
• 投入产出比与不划算场景

量化：延迟节省 = (1 - 命中率) × 平均回源延迟差，即命中请求的 TTFT 下降；计费节省 = 命中 token 数 × (输入价 - 缓存价) - 缓存存储/索引/维护成本。收益 = 命中 token 节省金额 + 延迟降低带来的业务价值。缓存不划算的场景：命中率低（前缀抖动、请求高度个性化）、缓存内容价格本来就低（短输入）、缓存存储/索引成本高、以及缓存命中产生的错误答案导致返工成本超过节省。此时应放弃缓存或只缓存高价值高频部分。

缓存投入不一定划算，关键看命中 token 数与命中率；当命中率低、存储成本高、或错误命中代价大时，缓存是负收益，应做成本收益测算后再决定。

• 缓存键含租户 ID
• 命中判定校验租户
• 存储物理/逻辑隔离

隔离三层：一是缓存键维度，键前缀必须包含租户 ID/账户 ID，不同租户天然不同键，不会互相命中；二是命中判定维度，即使键构造漏了，返回前仍校验缓存归属租户与请求租户一致，防止越权命中；三是存储维度，按租户做逻辑或物理隔离（独立 namespace/分区/Redis 库），配合访问控制与加密，防止跨租户读取。同时敏感数据按租户密钥加密，清除时按租户级联删除。

多租户缓存最怕跨租户复用导致数据泄漏；键隔离是基础、命中校验是兜底、存储隔离是纵深，三层共同保证租户边界。

• 各 Provider 缓存折扣与计费规则
• 最低计费块差异
• 纳入选型成本模型

对比维度：折扣比例（如读写缓存 token 折扣、多模态折扣）、最低计费块（如 1024 token 起步，不足也按整块计）、命中入库计费（写入缓存是否计费、命中是否计费）、TTL 与自动管理。把各 Provider 的缓存规则代入真实请求分布（token 长度、前缀命中率、动态内容占比）估算成本，纳入选型评估而非只看基础单价。例如某 Provider 缓存折扣高但最低计费块大，短请求场景下并不划算；有的写入缓存计费高，需权衡。选型用"模拟请求样本 × 各 Provider 计费规则"算出总成本。

缓存计费规则差异很大，裸比较基础单价会误判；必须结合真实请求分布与各 Provider 的折扣、最低块、写入/命中计费做成本测算。

• 字节级差异导致漏命中
• 规范化策略（标准化空白/换行/消息结构）
• 缓存键与请求构造的配合

Provider 前缀缓存按字节/token 精确匹配，空白、换行、BOM、消息角色标签、字段顺序等细微差异都会导致前缀不匹配而漏命中。规范化策略：在应用层统一 prompt 构造模板，标准化空白与换行（统一 \n、去除多余空格、规范化 Unicode 与 BOM）、固定消息结构（角色与字段顺序固定）、对动态内容用固定占位并后置。缓存键与请求构造共用同一规范化函数，保证同一逻辑请求产生字节级一致的 Prompt，从而命中同一前缀。

前缀缓存是"字节级相等"匹配，任何格式抖动都等于 miss；规范化把"逻辑相同"的请求变成"字节相同"，是提升命中率的前提工程。