GPT-6 对提示缓存做了几项直接影响生产系统的改进：更高的缓存命中率、新的诊断能力、显式缓存断点，以及更细粒度的缓存控制。它们解决的不只是“能不能缓存”，而是开发者更关心的三个问题：为什么没有命中、哪些内容适合复用，以及如何在正确性与成本之间做取舍。
缓存优化的核心是稳定前缀
大模型应用的请求通常可以拆成两部分：
- 稳定部分：系统指令、工具定义、输出格式、长篇背景资料；
- 动态部分：用户问题、当前时间、会话状态、检索结果和临时权限信息。
如果每次请求都把动态字段插入稳定内容中间，即使两次提示看起来几乎相同，也可能难以复用缓存。更稳妥的组织方式是把变化较少的内容集中到前面，把每次都会变化的内容放到后面。
例如，不要在系统指令开头写入请求 ID 或当前时间：
请求 ID：req-92831
当前时间：2026-04-20T10:15:00Z
你是一名代码审查助手……
[固定的审查规则]
[固定的工具定义]
可以改成：
你是一名代码审查助手……
[固定的审查规则]
[固定的工具定义]
--- 缓存断点 ---
请求 ID：req-92831
当前时间：2026-04-20T10:15:00Z
[本次待审查代码]
GPT-6 提供的显式断点让这种边界不必完全依赖服务端猜测。工程上可以把断点理解为一条声明：此前内容是缓存候选区，此后内容按请求动态处理。具体 API 字段和限制仍应以实际 SDK 或接口文档为准。
诊断信息比单纯的命中率更重要
整体命中率只能说明结果，无法直接解释原因。新的诊断能力适合用来回答以下问题：
- 请求是否命中缓存；
- 哪一段前缀参与了匹配；
- 提示在哪个位置开始发生变化；
- 缓存是否因为策略、作用域或其他条件被跳过；
- 命中后节省了多少可缓存输入，以及延迟是否同步下降。
来源摘要没有给出具体诊断字段名，因此接入时不应假设存在 cache_hit、cached_tokens 等固定字段。更安全的做法是先把供应商返回的原始诊断对象完整记录到受控日志，再根据正式接口定义建立指标映射。
建议至少建立以下观测维度：
| 指标 | 用途 |
|---|---|
| 缓存命中率 | 判断提示结构是否稳定 |
| 可缓存前缀长度 | 发现断点放置过早的问题 |
| 未命中原因分布 | 区分内容变化、策略绕过与配置错误 |
| 命中/未命中的 P50、P95 延迟 | 验证缓存是否真正改善用户体验 |
| 每类请求的输入成本 | 判断优化是否值得持续维护 |
不要只看全站平均值。应按模型版本、提示模板版本、租户、工作流和缓存策略拆分，否则某个高流量短提示可能掩盖长上下文任务的真实收益。
一个可运行的提示分层与诊断示例
下面的 Python 程序不会调用真实 GPT-6 接口，而是演示应用侧如何构造稳定前缀、标记显式断点并生成可追踪的前缀指纹。示例中的 cache 和 breakpoint_char_offset 是概念字段，接入时需要替换成正式 API 的参数名。
将代码保存为 prompt_cache_demo.py，可直接用 Python 3 运行：
#!/usr/bin/env python3
import argparse
import hashlib
import json
SYSTEM_INSTRUCTIONS = '''你是一名代码审查助手。
只报告能够明确定位的问题。
输出 JSON，字段为 severity、file、line 和 explanation。'''
TOOL_DEFINITION = '''工具：lookup_guideline
用途：查询团队编码规范
参数：topic（字符串）'''
def normalize(text: str) -> str:
lines = [line.rstrip() for line in text.strip().splitlines()]
return '\n'.join(lines) + '\n'
def main() -> None:
parser = argparse.ArgumentParser()
parser.add_argument(
'--question',
default='请检查 payment.py 中的重试逻辑。',
)
parser.add_argument(
'--cache-mode',
choices=['auto', 'bypass'],
default='auto',
)
args = parser.parse_args()
stable_prefix = normalize(
SYSTEM_INSTRUCTIONS + '\n\n' + TOOL_DEFINITION
)
dynamic_suffix = normalize('用户请求：' + args.question)
full_prompt = stable_prefix + dynamic_suffix
prefix_hash = hashlib.sha256(
stable_prefix.encode('utf-8')
).hexdigest()
request_plan = {
'model': 'gpt-6',
'input': full_prompt,
'cache': {
'mode': args.cache_mode,
'breakpoint_char_offset': len(stable_prefix),
},
}
local_diagnostics = {
'stable_prefix_sha256': prefix_hash,
'stable_prefix_chars': len(stable_prefix),
'dynamic_suffix_chars': len(dynamic_suffix),
'note': '字符数不是 token 数；真实命中状态应读取 API 响应诊断。',
}
print(json.dumps({
'request_plan': request_plan,
'local_diagnostics': local_diagnostics,
}, ensure_ascii=False, indent=2))
if __name__ == '__main__':
main()
运行命令：
python3 prompt_cache_demo.py \
--cache-mode auto \
--question '请检查订单取消流程中的并发问题。'
应用侧指纹不应被当作 GPT-6 的真实缓存键，它的用途是帮助排查问题：如果同一提示模板产生了不同指纹，说明稳定前缀在进入 API 前已经发生变化。可以进一步把模板版本、指纹和服务端诊断关联到同一条追踪记录中。
上线时别忽略边界与隔离
更高的缓存命中率并不意味着应该缓存所有内容。生产接入可以按以下顺序推进：
- 先挑长且稳定的工作流：例如固定规则的代码审查、文档问答或工具调用代理。
- 为提示模板设置版本号：修改系统指令时主动切换版本，避免新旧行为难以区分。
- 把动态数据移到断点之后：包括时间戳、请求 ID、用户输入和实时检索结果。
- 保留绕过缓存的控制项：用于调试、敏感请求和行为对照测试。
- 验证租户与权限隔离：不要为了提高命中率，把本应隔离的用户上下文混在同一复用范围内。
- 同时观察质量、延迟和成本：缓存策略不能以牺牲提示正确性或数据边界为代价。
GPT-6 的改进让提示缓存从一项偏黑盒的性能优化，转向可诊断、可分段、可控制的工程能力。真正的收益仍取决于提示结构：稳定内容越集中、断点越清晰、观测越完整，缓存带来的延迟与成本改善才越容易持续。