Gemini 3.5 的提示缓存怎么用来降本增效：从原理到落地的成本控制手册

如果你在做研发/测试/内容生产，通常会遇到同一种尴尬：提示词越来越长、重复请求越来越多、成本也跟着线性上升。
Gemini 3.5 的“提示缓存（Prompt Caching）”就是为了解决这种重复计算浪费问题——当你请求里包含大量相同的前缀上下文（系统指令、长背景资料、固定规则模板），缓存可以让后续请求复用已处理过的部分，显著降低生成开销。

本文会以“工程落地”的方式手把手说明：提示缓存是什么、适用场景、如何设计提示结构、如何命中缓存、以及如何评估降本效果。

说明：不同产品/SDK 的具体缓存开关与参数命名可能略有差异。本文给的是通用工程方法与设计原则，你可对照你使用的 Gemini 3.5 平台文档做适配。

一、先搞清楚：提示缓存到底缓存了什么？

把它理解成“对提示前缀的预处理结果复用”。

• 当你请求里有一大段固定内容（例如：系统角色、任务规范、JSON 输出 schema、长背景知识、字段校验规则）
• 在同一个会话/同一种缓存策略下，后续请求的这一段内容基本不变
• 模型无需对这段重复计算同样的表示与对齐步骤（底层实现可能包括 token 级/片段级复用）

最终表现就是：相同前缀 → 后续请求成本下降（通常体现为减少的计算/计费部分与更快的响应）。

二、什么时候“提示缓存最划算”？（适用场景清单）

提示缓存最适合以下模式：

1. 长系统提示词 + 小变量输入

   • 例如：固定的“内容生成规范/风格指南/合规要求”占 70%
   • 每次只替换“主题、要点、素材”

2. 批量请求同一类任务

   • 例如：一批接口测试用例生成、同一模板多次填空
   • 例如：同一报告结构批量产出不同患者/不同项目（注意合规与脱敏）

3. 多轮对话，但“规则层”基本不变

   • 第一轮定义输出格式、字段约束、失败分析模板
   • 后续轮只补充输入数据与少量决策信息

4. 固定的结构化 schema

   • 比如强制输出 JSON，包含固定字段、固定校验逻辑

反过来，以下场景命中率可能低：

• 每次都大幅改系统提示（前缀不稳定）
• 大量随机内容前置（导致无法形成稳定前缀）
• 你把“可变内容”放在前面，缓存无法覆盖主要 token

三、最关键的工程技巧：把提示拆成“可缓存前缀 + 可变尾部”

命中缓存的核心是：让变化尽量集中在提示的后半段，前半段尽量保持一致。

推荐结构（稳定前缀）

• System / Developer message：固定角色 + 固定规则 + 固定输出格式（JSON schema/字段清单）
• Background / Context：固定背景材料（可抽象成“资料块”）
• Guardrails：固定合规/禁用项/质量标准

可变部分（尾部替换）

• 用户输入：只放变量字段
• 本次任务的输入数据：接口文档片段、业务约束具体值、要生成的对象清单

例子（概念示意）

前缀（每次几乎一样）：

• 你是资深编辑…
• 输出必须包含：标题/大纲/要点…
• 禁止出现…
• JSON 字段必须包含…

尾部（每次不同）：

• 主题：xxx
• 素材：{...}
• 生成字数：1200

这样缓存就能复用前缀的计算结果。

四、如何“设计提示”来最大化缓存命中率（可执行清单）

1）减少“前缀中的随机性”

例如：不要把当前时间戳、随机 UUID、每次不同的闲聊放在系统提示前面。
如果必须出现时间戳，尽量放到尾部，或用“相同标识但可复用”的方式（例如让模型忽略该字段）。

2）把长材料做成“资料块”

如果你有固定背景（如公司产品说明、接口字段定义、统一测试框架说明），建议把它作为稳定块放在前缀。

3）固定输出 schema（而不是每次换写法）

“字段名一致、结构一致”比“描述一致”更容易形成稳定前缀。
例如：固定输出为：

json

{ "summary": "", "steps": [], "risks": [] }

不要每次改字段顺序/字段名。

4）避免在前缀插入“本次才需要”的特定约束

如果只有某个任务需要特殊禁止项，把它放在尾部；不要把它写进前缀通用规则里。

五、落地步骤：从 0 到开始降本（推荐工作流）

1. 找出你的“重复最大块”
   • 通常是系统提示、风格/格式要求、schema、长背景说明
2. 把重复块固化到固定消息中
   • 尽量保持一致（措辞、顺序、字段名）
3. 把变化数据放到尾部
   • 变量只在最后一段输入出现
4. 启用提示缓存（按你平台/SDK 的方式）
   • 例如通过“缓存开关参数/缓存 key 策略/是否使用缓存上下文”
5. 对比同任务的账单与延迟
   • 用一组样本请求做 A/B：缓存前 vs 缓存后
6. 持续优化前缀稳定性
   • 通过日志检查缓存命中率与 token 命中覆盖比例（若有指标）

六、评估降本：你应该用哪些指标看“真降价”

建议至少看 4 个指标：

1. 缓存命中率（Hit Rate）：复用比例越高越划算
2. 有效输入 token：前缀 token 是否被复用（而不是每次都算）
3. 每请求成本（$/req 或 $/1k tokens）：最直观
4. 端到端延迟（Latency）：缓存有时也会带来更快响应

如果你只能看一项：看“每请求成本”并做同任务对比。

七、常见坑：明明开了缓存却不怎么省钱

1. 前缀被无意间破坏
   • 字段顺序变了、说明文案每次都改了、schema 每次微调
2. 可变信息太早出现
   • 你把“本次输入数据”放在前面导致缓存覆盖不到核心 token
3. 批量任务结构不一致
   • 不同任务用不同输出格式/不同规则块，无法形成同前缀
4. 会话生命周期不匹配缓存策略
   • 某些实现要求同会话/同缓存域；跨域请求无法复用
5. 安全/合规要求导致每次前缀不同
   • 例如每次都加不同免责声明或不同禁用项

结语：把缓存当成“提示工程”的一部分，而不是开关

提示缓存的价值，来自你对提示结构的工程化设计：
稳定前缀、变量尾部、固定 schema、减少随机性、用指标验证命中与成本下降。
当你把这些做到位，Gemini 3.5 的提示缓存就不只是“省钱按钮”，而会成为你系统的“默认成本优化策略”。