1. 摘要
本报告基于社区讨论及行业数据分析，深入探讨了主要大语言模型（LLM）提供商（Anthropic, Google, OpenAI, Cursor等）在提示词缓存（Prompt Caching）表现上的显著差异。核心发现表明，缓存比例的差异并非单纯反映模型智能水平，而是由应用类型分布 （编码智能体 vs. 通用聊天）、提示词结构稳定性 以及云端基础设施架构共同决定。对于编码智能体（Coding Agents）等高上下文复用场景，缓存命中率直接决定了运营成本，其重要性远超输入价格本身。
2. 缓存比例差异的现状与成因分析
2.1 主要提供商缓存表现概览
- 高缓存率群体：Anthropic (Claude) 和 Cursor 表现出显著高于行业平均的缓存 token 比例。
- 低缓存率群体：Google (Gemini) 缓存比例较低；OpenAI 缓存比例呈现快速上升趋势（从 ~30% 跃升至 ~75%）。
2.2 核心驱动因素
A. 应用工作负载类型差异 (Workload Distribution)
- 编码智能体主导：Cursor 和 Anthropic 的核心用户群高度集中在代码开发场景。编码任务具有长上下文、高上下文复用率的特点，天然适合缓存。
- 通用/短查询主导 ：Google 和 OpenAI（早期）更多被用于一次性简单查询、短期对话或非编码类任务（如分析、设计、文档编辑）。这些场景上下文变化频繁，缓存命中率低。
- 数据佐证：极少用户将 Gemini 作为主要编码模型使用，而 Claude Code 和 Codex 在编码领域的渗透率更高，直接导致 Google 缓存统计偏低。
B. 提示词结构与前缀稳定性 (Prefix Stability)
LLM 提供商的缓存机制多为基于前缀匹配（Prefix-based），即只有从请求开头字节完全相同的部分才能被复用。
- 高命中场景 ：编码智能体通常拥有稳定的系统提示、工具定义和仓库上下文，每次仅追加少量新内容，前缀变化极小。
- Cursor 案例：包含约 50k token 的未变更上下文，每次仅追加少量新内容，使得缓存部分迅速占据主导。
- 低命中场景：许多聊天机器人和 RAG（检索增强生成）应用将检索文档、时间戳或动态变量置于提示词顶部，导致每次请求的前缀不同，即使 90% 内容相同也无法缓存。
C. 工具调用智能体 (Tool Calling Agents)
- 工具调用场景是典型的高缓存使用案例。系统提示和工具定义在长运行中保持不变，仅追加新的工具执行结果，预期会快速推高缓存 token 比例。
3. 编码智能体场景下的成本与性能分析
在 Coding Agents 场景中，缓存读取价格及命中率对账单的影响远超基础输入价格。
3.1 成本对比数据 (以 100K 上下文、50 轮对话为例)
| 模型/提供商 | 未缓存价格 ($/M tokens) | 缓存后价格 ($/M tokens) | 成本降低倍数 |
|---|---|---|---|
| Claude Sonnet 5.5 | $2.00 | $0.10 | 20x |
| DeepSeek V4.1 Flash | $0.30 | $0.006 | 50x |
- 关键洞察：一次缓存未命中（Cache Miss）的成本极高。例如在 Sonnet 中，一次未命中的费用等于 25 次命中的费用。
3.2 缓存失效的主要诱因 (Cache Invalidation Triggers)
-
会话空闲超时 (TTL Expiration)：
- Anthropic API 默认 TTL 为 5 分钟。
- 典型场景：代码构建、测试套件运行或工具调用挂起超过 5 分钟，下一轮请求将支付全价。例如，6 分钟的构建过程会导致缓存失效。
-
提示词结构变动：
- 修改 Prompt 开头部分（系统提示、时间戳、动态上下文）会直接导致前缀不匹配。
- Agent 自行重写上下文也可能破坏前缀稳定性。
-
云端负载均衡路由 (Load Balancing Routing)：
- 若提供商未实现基于前缀感知的负载均衡，请求可能被分散到不同的服务器副本，即使 Prompt 完全一致也会丢失缓存命中。这是用户不可见的架构因素。
-
中途切换提供商：
- 在会话过程中切换 LLM 提供商会导致上下文窗口重置，缓存失效。
4. 监控与优化建议
4.1 关键监控指标
- 摒弃会话平均值：不要仅依赖整个会话的平均缓存比例，这会掩盖单次 Prompt 编辑带来的全额重读成本。
- 推荐指标 ：追踪每轮（Per-turn）的
cached_tokens占total_input_tokens的比例。 - 前缀哈希追踪 (Prefix Hashing) ：
- 记录每次请求 Prompt 前缀的哈希值。
- 价值：区分缓存未命中是由于"Agent 端重写了上下文"还是"Provider 端丢弃了缓存条目"。
4.2 架构与工程优化
- 保持提示词前缀稳定：确保系统提示、工具定义和静态上下文位于 Prompt 最前端，且内容恒定。
- 控制 Agent 空闲时间：在代码构建或长任务执行时，注意 API 的 TTL 限制（如 Anthropic 的 5 分钟），避免超时导致缓存失效。
- 负载均衡考量：若使用云 API，需了解提供商的负载均衡策略是否支持前缀感知路由。
- 本地模型备选方案：对于对成本极度敏感或上下文稳定性要求极高的场景，可考虑本地部署模型（如 Qwen 笔记本版），规避云端缓存未命中的计费风险，但需权衡推理延迟。
5. 结论与展望
- 缓存比例是工作负载的晴雨表：高缓存率（如 Cursor/Anthropic）反映了其在长上下文、高复用率的编码智能体领域的深度应用；低缓存率（如 Google）反映了其更广泛的通用型、短查询负载分布。
- 结构优于规模：在提示词工程中，前缀的稳定性比单纯增加上下文长度对缓存命中率的影响更大。RAG 应用需特别注意检索文档的放置位置。
- 成本模型的根本转变：对于智能体应用，缓存命中率已成为成本控制的核心变量。优化 Prompt 结构、管理会话状态和监控每轮缓存比例是降低 API 成本的关键手段。
- 趋势展望：随着 OpenAI 等提供商用户行为向长上下文任务迁移，其缓存比例有望继续上升。同时，提供商可能会推出更多前缀感知的负载均衡策略以提升用户体验。
https://ramp.com/data/googles-models-lag-in-agentic-ai-usage https://www.reddit.com/r/LLMDevs/comments/1xmpwyu/coding_agents_cache_price_matters_more_than_input/