OpenAI API 怎样配置提示词缓存降低重复输入成本

OpenAI API 的提示词缓存应围绕反复使用的稳定前缀配置：固定业务规则放在前面，变化的问题放在后面，再依据模型设置缓存边界。判断是否省钱，要同时统计缓存读取和写入，不能只看命中率。

官方地址：https://developers.openai.com/

下面用 GPT-5.6 Sol 的 Responses API 举例。模型和账户访问权限需自行具备；示例没有执行付费请求，数字均为计算示意。

先记录可比较的输入成本

设想客服工单分类服务：每次都携带同一份分类规范，只有工单正文变化。先保留现有实现作为基线，记录模型、规范版本、输入 token、输出 token、缓存读写量和端到端耗时。改造后使用同一组工单，避免把输出变短带来的降费归因于输入缓存。

建议每条记录包含请求标识和以下字段，不记录客户原文或 API 密钥：

这些指标应按整组请求汇总，并单列错误率。官方部署说明也要求把读写量与实际费用一起观察。

把稳定前缀单独设为缓存边界

把规范保存为 UTF-8 文件 support-rules.txt，固定措辞、示例及其顺序。前缀必须足够长：GPT-5.6 及以后模型的最低可缓存长度为 1024 个可见输入 token，字符数不等于 token 数；不要为了凑长度塞入无关内容。

下面将规范作为 developer 消息，并在文本块末尾标记显式断点。用户问题位于断点之后，保持前面的规范不变。显式模式下若没有断点，就不会读写提示词缓存。具体规则见提示词缓存文档。

import os
import time
from pathlib import Path
import requests

# 从环境读取密钥；规范文件应包含实际需要的稳定业务内容。
rules = Path("support-rules.txt").read_text(encoding="utf-8")
payload = {
    "model": "gpt-5.6-sol",
    "prompt_cache_options": {"mode": "explicit", "ttl": "30m"},
    "prompt_cache_key": "support-demo:customer-a:rules-v1",
    "input": [
        {
            "role": "developer",
            "content": [{
                "type": "input_text",
                "text": rules,
                "prompt_cache_breakpoint": {"mode": "explicit"}
            }]
        },
        {"role": "user", "content": "工单：收到的商品数量比订单少一件。"}
    ]
}
started = time.perf_counter()
try:
    # 真实调用会计费；后续请求只替换用户问题，保留稳定前缀。
    result = requests.post(
        "https://api.openai.com/v1/responses",
        headers={"Authorization": "Bearer " + os.environ["OPENAI_API_KEY"]},
        json=payload, timeout=90
    )
    result.raise_for_status()
    usage = result.json()["usage"]
except (requests.RequestException, KeyError, ValueError) as exc:
    # 不打印请求头、密钥或客户原文；由调用方接入自己的失败处理。
    raise RuntimeError("请求或用量解析失败，请检查权限、参数与服务日志") from None

details = usage["input_tokens_details"]
print({
    "input_tokens": usage["input_tokens"],
    "cached_tokens": details["cached_tokens"],
    "cache_write_tokens": details["cache_write_tokens"],
    "output_tokens": usage["output_tokens"],
    "elapsed_ms": round((time.perf_counter() - started) * 1000)
})

代码需要安装 requests，且运行环境已设置密钥。实际项目应把工单替换为业务输入；规范更改时升级版本，客户之间使用各自稳定的键。这里的键用于分开缓存记账，不能替代业务鉴权。

用冷请求与重复请求计算节省

先取一次没有可复用缓存的请求，再在有效期内复用相同规范发送多条不同工单。完整保留首条请求及后续请求的用量，按实际记录判断是否命中；单次耗时不代表稳定性能，可再比较同负载下的中位数与高分位耗时。

以下仅是算术示例：固定前缀 1600 token，动态工单每条 400 token，共 8 条。假设首条只写入固定前缀、后续 7 条均完整命中，动态内容全部按普通输入处理。

按 GPT-5.6 Sol 标准短上下文价格，每百万普通输入 4 美元、缓存读取 0.40 美元，30 分钟缓存写入按普通输入的 1.25 倍计，示例输入费用为 (3200 × 4 + 1600 × 5 + 11200 × 0.40) / 1000000 = 0.02528 美元；对照为 0.064 美元，算例降幅约 60.5%。这是假设用量推导，不是实测收益；不含输出、工具及其他适用费用。价格和上下文档位以模型页及价格页为准。

落到真实日志时，普通输入量等于输入总量减缓存读取量、再减缓存写入量，三个部分各按自己的费率计算。不要把已计入写入部分的 token 再按普通输入重复收费；不同保留时长的写入也不能混用一个价格。

处理未命中与模型差异

命中为零时，先比较前缀实际内容：请求编号、当前时间、动态检索资料若被放在规范前面，就可能破坏复用。然后确认前缀长度、断点和模型支持情况，再看缓存有效期及请求路由。相同的键不能让不同内容自动变成相同前缀。

GPT-5.5 及更早模型使用旧式 prompt_cache_retention，不能照搬本例的显式断点配置；迁移时应按模型支持范围改参数。对于只使用一次的长规范，写入成本未必能被后续读取摊薄，应比较实际请求组再决定是否缓存。

缓存会直接返回上次答案吗？

不会。提示词缓存复用前缀计算，并不是把客户的答案作为响应缓存。是否需要另外缓存业务结果，取决于业务对时效和一致性的要求。

把 ttl 改得更长就一定更省吗？

不一定。更长的可选时长可能对应更高写入费率，只有之后的复用能抵消额外支出时才有收益。先保留本例的 30m，再依据真实重复间隔计算。

可以把两次命中请求的费用当作整体收益吗？

不可以。应把首次写入、未命中、失败及重试造成的实际用量一起统计，并独立报告输出费。对缓存的判断单位应是完整业务负载。