当本地化引擎翻译文本时，发送给 LLM 的提示里，一部分在每次请求中都完全相同，另一部分则会随请求变化。提示缓存让引擎可以复用这部分稳定内容，而不必每次都重新付费处理。这些被复用的令牌会在你的用量数据中显示为 缓存令牌，成本仅为普通输入令牌的一小部分。
翻译提示是如何构成的#
引擎发送给模型的每个请求，都是由多层内容拼装而成。其中有些层对同一引擎和区域设置下的所有请求都保持稳定；还有一层是动态的，会随每次请求变化。
| 层级 | 稳定或动态 | 是否缓存 |
|---|---|---|
| 系统提示——引擎身份、本地化规则、语法 | 对每个引擎都保持稳定 | 是 |
| 你的指令和品牌语气，按区域设置区分 | 在你编辑引擎之前保持不变 | 是 |
| 为当前请求检索到的术语表条目 | 动态——每次请求都可能不同 | 否 |
| 待翻译文本 | 动态 | 否 |
这些稳定层会在提示开头形成一个连续前缀。引擎会把这个前缀的结尾标记为 缓存断点：断点之前的内容都可以被缓存并复用；断点之后的内容——包括每次请求的术语表、示例和输入文本——都会在每次请求中重新发送。
为什么术语表不会被缓存
术语表是根据你当前要翻译的精确文本按请求检索的，因此每次请求都可能不同。把它放在缓存断点之后，意味着无论某次请求拉取了哪些术语表条目，提示中其余稳定部分都仍然可以复用。
为什么缓存输入更便宜#
针对某个引擎和区域设置的第一次请求，会把稳定前缀 写入 提供商的缓存。之后每个复用该前缀的请求，都会从缓存中 读取 它，而不是再从头处理一遍。提供商对缓存读取的计费通常只是普通输入令牌费率的一小部分，因此提示里那块始终不变的“大头”，不再需要每次都按全价重复计费。
缓存是短时有效的，由模型提供商管理，而不是由你的引擎管理。这意味着，当你在较短时间窗口内，用同一引擎和区域设置处理大量翻译时，收益最大：请求会在前缀缓存仍然“热”的时候到达，并直接从缓存中读取。
缓存是自动生效的
你不需要做任何配置。某个请求是否会使用缓存，取决于实际处理它的模型——Anthropic 和 Google 的模型使用显式缓存断点，OpenAI 的模型会自动缓存长前缀，也有一些提供商根本不支持缓存。引擎会针对不同模型采用正确的处理方式。
直接收益#
- 成本更低——稳定前缀只需按全价支付一次，之后每次重复请求都按更低的缓存读取费率计费。
- 延迟更低——缓存令牌无需重新处理，因此“热”请求返回更快。
- 无需设置——缓存默认开启；无需在引擎配置中额外启用任何选项。
只要同一引擎和区域设置持续有稳定流量，这些收益就会不断累积——而这正是生产环境本地化流水线的典型形态：同一套配置连续处理一条又一条请求。
在用量中查看缓存令牌#
每次翻译响应都会提供一份用量明细，把缓存令牌和全新输入分开显示：
{
"usage": {
"inputTokens": 1200,
"outputTokens": 800,
"cacheReadTokens": 950,
"cacheWriteTokens": 0
}
}| 字段 | 含义 |
|---|---|
inputTokens | 本次请求中按全新输入处理的提示令牌 |
outputTokens | 模型生成的令牌 |
cacheReadTokens | 由提供商缓存返回的提示令牌。未命中缓存时为 0。 |
cacheWriteTokens | 本次请求中写入缓存的提示令牌——也就是缓存未命中 / 首次调用时的写入量。 |
针对某个引擎和区域设置的首次请求，通常会看到一个正数的 cacheWriteTokens（表示前缀正在写入缓存），以及值为 0 的 cacheReadTokens。如果后续请求到来时缓存仍然“热”，情况就会反过来：cacheReadTokens 上升，而 cacheWriteTokens 降到 0。你还可以在 Reports 中查看各个引擎的汇总令牌用量。
