留存是一项请求策略，而不是一个默认前提

为什么要设置窗口，而不是假定它

"默认就够了"的反射，假设缓存窗口能活得比工作负载在两次复用之间留出的间隔更长。 在接受这个假设之前，值得把两件事并排放一下。第一件是 Microsoft Learn 记录的： 留存策略有两种，in_memory 与 24h。内存中的条目通常在非活动 后 5～10 分钟内被清除，并且必定在最后一次使用后的 1 小时内被删除；而扩展留存可以 把缓存前缀保持为可路由状态，最长到 24 小时。在 gpt-5.4 之前的模型上， 省略该值即表示 in_memory，且两种策略下提示缓存的价格相同。第二件是本 仓库源运行里取出、按留存模式分组、稀疏且经脱敏的公开聚合，用来描述在 in_memory 与 24h 下，首 token 延迟和缓存命中率实际是怎么动的。

值得停下来的，正是那个"成对"的部分。只看命中率会让人安心，但留存的选择体现在 别处。在这类场景里，两种模式都保持高命中率（约 0.93～0.96），所以单看它，会以为 留存模式几乎不起作用。首 token 延迟的长尾，讲了另一半故事——在基数为 1 时， in_memory 序列的 p95 约 106,000 ms，而 24h 序列约 9,900 ms。 所以留存的选择体现在延迟长尾，而不是命中率上。也正因如此，留存应当挨着缓存 token 占比、和延迟一起读：它不只是一个性能参数，而是一项请求策略，也是一个治理选择。 两种留存模式、它们的寿命、in_memory 默认、相同的价格、扩展留存的同区域 条件，是 Microsoft Learn 记录的；把延迟摆在命中率旁边的那组公开测量，则是本仓库 愿意为之背书的源运行证据，而不是一条通用的延迟曲线。下面的图把这一对明示出来。

官方行为 · 两种留存模式

自动缓存，并不等于显式的留存

Microsoft Learn 说明了两种提示缓存留存策略，in_memory 与 24h。内存中的缓存条目通常在非活动后 5～10 分钟内被清除，并且 必定在最后一次使用后的 1 小时内被删除。使用扩展留存，则可以把缓存前缀 保持为活动状态更久，最长到 24 小时。

观测证据 · 稀疏的公开测量

延迟把留存的选择显形了

运维策略 · 遇到歧义即失败关闭

如果留存很重要，就让那个选择可观测

公开仓库里包含一个小小的留存策略助手：对那些有文档记载默认是 in_memory 的模型，它会拒绝省略该值。听起来很严格，但这正是为了防住一种常见的失败模式—— 设计上假定了更长的缓存期，请求体却悄悄采用了短的默认值。

治理说明 · 留存不只关乎延迟

更长的留存还需要一次治理核查

Microsoft Learn 表示，内存提示缓存与所有数据驻留区域都兼容；至于扩展留存， 只有在 Regional Standard 或 Regional Provisioned 模式下，缓存数据才留在区域内。 这让留存既是性能判断，也是治理判断。

因此扩展留存既是性能判断，也是治理判断。在依赖扩展窗口之前，先确认你的服务 模式会把缓存数据保持在区域内，不要把这个选择交给默认值。

来源与证据边界

Tier 1 — 服务契约（Microsoft Learn）。两种留存策略、内存的清除 与删除窗口、24 小时扩展留存上限、gpt-5.4 之前的 in_memory 默认、两种策略相同的价格，以及数据驻留行为，都记录在这里。

• [1] Prompt caching with Azure OpenAI — 记录了 in_memory 与 24h 留存策略、非活动后 5～10 分钟内的内存清除与最后一次使用后 1 小时内的删除、24 小时扩展留存上限、gpt-5.4 之前模型的 in_memory 默认、两种留存策略相同的提示缓存价格，以及"只有在 Regional Standard 或 Regional Provisioned 部署类型下扩展留存才把缓存数据保持在区域内"的数据驻留规则。来源：Microsoft Learn 文档（2026-06-04 访问）· 存档。

Tier 2 — 运维推断（本仓库）。对默认 in_memory 的模型在 省略该值时失败关闭的留存策略助手，以及稀疏的公开命中率与首 token 延迟测量，不是 Learn 规范，而是本仓库的运维推断与源运行证据。

• [2] 本仓库，docs/12-prompt-cache-key-policy.md — 提示缓存键与留存的运维手册。§4 从有文档记载的逐模型默认推导出 in_memory 默认表，并规定显式声明 prompt_cache_retention。来源。
• [3] 本仓库，batch-runner/batch_runner/cache/retention_policy.py — 对有文档记载默认是 in_memory 的模型，在省略该值时抛出异常的 ensure_explicit 助手。它是运维推断，而非 Learn 规范。来源。
• [4] 本仓库，results/cache-key-bucketing/cache_hit_ratio_vs_cardinality.csv — 留存命中率与首 token 延迟表背后那一份稀疏的公开聚合测量。它是源运行证据， 不是通用的延迟规则。来源。

本文证明了什么、又没证明什么。它记录了截至访问日期 Microsoft Learn 明示的提示缓存留存契约——in_memory 与 24h 策略、内存的清除与 删除窗口、24 小时扩展上限、gpt-5.4 之前的 in_memory 默认、两种 策略相同的价格、扩展留存的同区域条件——以及本仓库的经验法则：显式声明 prompt_cache_retention，并在默认 in_memory 的模型上一旦省略就 失败关闭。单个公开测量显示，在基数为 1 时留存把首 token 延迟显了形。那是源运行证据， 而不是对所有模型、区域、流量形态都成立的通用延迟曲线的证明。