如何降低大模型调用带来的成本降低大模型调用主要方法是利用好Prompt Caching有时候开了缓存之后命中率长期停在 20% 上下。所以我们要注意以下内容缓存的是 KV state不是答案传统 KV 缓存Redis 那种和 Prompt Caching 名字一样语义完全不同。Anthropic 的 Prompt Caching 缓存的是 Transformer 推理时 attention 层 prefill 阶段算出来的 KV 张量——下次请求前缀完全一致模型直接复用这套张量跳过 prefill。Anthropic 文档里给了 4 个断点、最小 1024 token、TTL 默认 5 分钟命中频率够高可延到 1 小时Anthropic Prompt Caching。OpenAI 这边更省心——超过 1024 token 的前缀自动缓存128 token 粒度匹配TTL 大约 5-10 分钟OpenAI Prompt Caching 指南。关键在前缀完全一致五个字。不是语义相似是字节级精确匹配。一个空格、一个时间戳、一个用户 ID 差异全部 miss。前缀按物理顺序匹配不看语义前缀按物理位置匹配不管两段 prompt 看起来多像。工程报告里有团队公开过类似观察花几个月把命中率从不到 10% 优化到 70%整段时间下来 token 成本直接砍掉近 60%。最常见的破功操作就三类写法 1system prompt 里塞时间戳# 永远 misssystemf当前时间{datetime.now()}。你是一个助手...# 时间放到 user message 末尾system你是一个助手...userf[当前时间{datetime.now()}]\n{question}写法 2system prompt 顶部放用户 ID / 请求 ID# 每个用户前缀都不同systemf用户ID:{user_id}...# 用户信息后置userf[用户:{user_name}]\n{question}写法 3动态生成工具定义——Agent 场景特别常见。工具集不变时把 JSON 序列化结果固定下来sort_keysTrue别每次随机顺序重排。动态内容不能塞在 system prompt 中间Agent 场景下这个最难处理。Agent 的 working memory 每一步都在变。按system prompt working memory 当前消息这种顺序拼 prompt 的话working memory 每次动一点前面的 system prompt 缓存就全废了——system prompt 自己一个字节没改也得从头算。一个叫 “Relocation Trick” 的简单解法把 working memory 从 system prompt 末尾移到 user message 末尾。只改一个位置命中率能从 20% 以下跳到 70% 这个量级。Agent 系统通常按三段拆断点 1静态系统提示TTL 拉满 ~1 小时断点 2最近 N 轮对话历史TTL 5 分钟断点 3工具定义工具集不变时极稳定working memory 和当前用户消息放最末尾不打断点——让它们独立失效不污染前面的缓存段。那到底能省多少、什么时候反而不划算前面的前提都踩对命中率能稳在 70% 以上。一个朴素的判断不到 50% 说明 prompt 结构有问题70% 以上算健康85% 以上说明前缀纪律做得很到位。定价层面拿 Anthropic Claude Sonnet 4.5 举例缓存读取 0.30 / 百万 token标准输入价 3.00首次写入 $3.75比标准输入贵 25%。想回本至少需要 2 次以上复用——单个 prompt 前缀被使用 2 次以上缓存就是合算的Anthropic 定价。OpenAI 这边自动给 50% 折扣没有写入溢价。两种模式各有取舍Anthropic 折扣更深但要手动打cache_control标签OpenAI 折扣浅但零配置。上线后建议盯这几个数光看 token 账单看不出缓存效果建议看这五个指标cache_creation_tokens写入缓存的 token 数cache_read_tokens从缓存读取的 token 数uncached_tokens完全没命中的 token 数hit_rate命中 token / 总 prompt token—— 核心指标TTFT首 token 时间—— 缓存命中能省 prefillTTFT 会显著下降基线参考命中率 70%低于这个值基本就是 prompt 结构有问题。对于自检我们需要考虑以下几点。system prompt 里有没有时间戳或用户 ID工具定义是不是每次动态生成system prompt 凑没凑够 1024 token不够就主动凑否则打不上断点监控里有没有看cache_read_tokens/cache_creation_tokensAgent 系统的 working memory 放在 prefix 中间还是末尾