聚合平台缓存命中率实测：能省多少钱？

最近我们在 KULAAI 上做成本优化测试时，重点盯上了 Prompt Caching 这个能力。厂商宣传说缓存命中能省 50% 到 90% 的输入成本，听起来确实诱人，但问题在于：经过聚合平台中转之后，这个折扣还能原封不动地落到用户头上吗？不同平台的缓存策略到底差多远？我们花了两周时间做了完整的对比压测，数据说话。

先搞懂：Prompt Caching 到底怎么省钱

Prompt Caching 的原理其实不难理解。想象一下，如果你的请求里有一段固定的前缀——比如长长的 system prompt、few-shot 示例、或者 RAG 检索回来的文档上下文——厂商第一次处理完会把它缓存下来。后续请求中，只要前缀没变，这部分就不再需要重新计算，直接复用缓存结果。

省钱效果取决于两个核心变量的乘积：缓存命中率（有多少比例的输入 token 命中了缓存）和缓存折扣率（命中缓存的 token 只收原价的多少，通常是 10% 到 50%）。

举个直观的例子：一次请求输入了 2000 token，其中 1500 token 是固定的 system prompt。如果缓存命中，这 1500 token 只收 10% 的费用。原本输入成本是 2000 token 全价，现在变成 500 全价 + 1500 × 10% = 650 token 等效成本，相当于省了 67.5%。

但这个漂亮数字成立的前提是：缓存真的命中了，而且平台把这个折扣完整地给了你。我们的测试就是围绕这两点展开的。

测试设计

测试场景
构造了三个典型场景，每个场景连续发 200 次请求：

• 场景一：长 system prompt（高缓存收益）。2000 token 的 system prompt 完全固定，user message 每次都变。这是缓存收益最大的场景——理论上第一次请求建立缓存后，后续 199 次都应该享受折扣。
• 场景二：RAG 场景（部分缓存收益）。500 token 的 system prompt 固定，每次请求会拼接一段 800 token 的检索文档（文档内容按轮次变化，但同一篇文档可能在多次请求中重复）。缓存收益取决于文档重复率。
• 场景三：多模态混合（图片前缀固定）。固定 300 token 的 system prompt + 同一张产品图片，user message 每次变化。图片也能被缓存，但不同模型对图片的缓存策略差异很大。

对比对象

• 直连厂商：直接调 OpenAI / Anthropic API，作为基准值
• KULAAI：聚合平台透传模式
• 平台 A：某聚合平台
• 平台 B：某聚合平台

核心指标

• cache_hit_rate：缓存命中的请求占比
• input_token_billed：实际计费的输入 token 数（等效 token）
• sa ving_vs_direct：相比直连厂商的节省比例
• discount_pass_through：厂商给的折扣是否完整传递给用户

场景一：长 System Prompt 的缓存收益

实测数据（200 次请求，2000 token 固定 system prompt）

平台	缓存命中率	平均输入 token 计费量	等效成本	相比直连节省
直连厂商（基线）	95.5%	380 token	基线	-
KULAAI	95.0%	385 token	≈基线	≈相同
平台 A	91.2%	620 token	+63%	折扣被部分截留
平台 B	87.3%	780 token	+105%	折扣被大幅截留

直连厂商的缓存行为
第一次请求建立缓存后，后续 199 次中 190 次命中（命中率 95.5%）。少数未命中的原因是厂商缓存有时间窗口限制，个别请求间隔较长导致缓存过期。命中后输入成本从 2000 token 降至约 200 token，节省 90%。

聚合平台的差异根因
KULAAI 近乎完整传递了缓存收益。命中率和计费量与直连厂商几乎一致，偏差在统计噪声范围内。平台没有在缓存链路中做任何破坏缓存的事——没有修改 prompt，没有拼接额外的 metadata 前缀，没有做格式转换。

平台 A 的缓存命中率掉了 4.3 个百分点。排查发现平台 A 会在请求中自动拼接一段内部的 trace ID 和租户标识到 system prompt 尾部。这段额外内容导致 prompt 前缀跟缓存键不完全匹配，部分本应命中的请求被判定为新请求。更隐蔽的是，平台 A 的计费逻辑对缓存命中的部分没有应用厂商的完整折扣——厂商给 90% 折扣，平台只给用户算了约 70%。

平台 B 的问题更严重。缓存命中率掉了 8.2 个百分点，且计费 token 数是直连的 2 倍还多。根因是平台 B 在高并发下会动态调整请求的路由——两次连续请求可能被分发到不同的厂商实例上，而缓存是按实例隔离的。实例一切换，缓存就没了，命中率当然大跌。

场景二：RAG 场景的部分缓存收益

实测数据（200 次请求，检索文档有重复）

平台	缓存命中率	平均输入 token 计费量	相比直连节省
直连厂商	62.3%	780 token	基线
KULAAI	61.8%	785 token	≈相同
平台 A	54.1%	920 token	-17%
平台 B	43.2%	1050 token	-35%

RAG 场景下的缓存命中率天然低于固定 system prompt 场景，因为检索文档会变化。但同一文档在不同请求中重复出现时，按理说仍应命中缓存。

平台 B 在这个场景下的表现尤其糟糕。命中率比直连低了近 20 个百分点。根因跟场景一相同——路由切换导致缓存实例不匹配。RAG 场景下文档上下文更零散，缓存更依赖于实例亲和性，平台 B 的负载均衡策略频繁切换实例，把本该复用的缓存全废掉了。

场景三：多模态混合的图片缓存

实测数据（200 次请求，固定图片）

平台	图片缓存命中率	平均输入 token 计费量	相比直连节省
直连厂商	92.7%	920 token	基线
KULAAI	92.3%	925 token	≈相同
平台 A	78.5%	1350 token	-47%
平台 B	81.2%	1280 token	-39%

图片缓存其实比文本缓存收益更大，因为一张中等复杂度的图片可能消耗 500-2000 token 的输入量，缓存命中后这部分只收 10% 的费用。

平台 A 在图片缓存上翻了个大车。命中率比直连低了 14 个百分点。排查发现平台 A 在用户上传图片后做了一个“优化处理”——压缩、格式转换、加水印。这些操作修改了图片的二进制内容，而缓存键匹配是基于图片哈希的，内容一改，哈希值就变了，缓存自然命中不了。

平台 A 的这个“增值服务”初衷是帮用户减少上行带宽和 token 消耗，但实际效果是省了小钱丢了大钱——压缩省了几十毫秒的延迟，但破坏了缓存，让后续每次请求都按全价计费。

平台 B 的问题还是路由切换，图片缓存同样依赖于实例亲和性，而它的负载均衡策略再次破坏了这种亲和性。

缓存省钱效果的量化结论

把三个场景汇总，看聚合平台相比直连厂商的缓存省钱效果：

平台	场景一（长SP）	场景二（RAG）	场景三（多模态）	综合加权
直连厂商	基线（100%）	基线（100%）	基线（100%）	基线
KULAAI	98.7%	99.4%	99.3%	99.1%
平台 A	61.2%	82.1%	53.2%	63.5%
平台 B	48.7%	65.2%	60.8%	55.3%

综合加权相当于各平台在直连厂商缓存节省效果上的比例。100% 表示省钱效果跟直连完全一致。63.5% 意味着平台 A 只帮你省到了直连能省的三分之二不到，剩下的都被平台的各种操作损耗掉了。

一个具体的数字换算：假设你的月输入 token 费用是 5000 美元，直连的缓存能帮你省到 1500 美元（省 3500 美元）。走 KULAAI 能省到约 1520 美元，跟直连几乎一致。走平台 A 只能省到约 2780 美元，多花了 1260 美元。走平台 B 只能省到约 3080 美元，多花了 1580 美元。这些多花的钱不是给了厂商，而是被平台的缓存策略缺陷吃掉了。

缓存效果差异的根因分析

根因一：Prompt 注入污染
平台在用户 prompt 中自动拼接额外的 metadata（trace ID、租户标识、审计信息），破坏了缓存键的前缀匹配。好的平台（如 KULAAI）把这些信息放在 HTTP Header 而非 prompt body 中，不参与缓存键的计算。

根因二：实例亲和性缺失
厂商的缓存是按实例隔离的。请求 A 和请求 B 如果被分发到不同实例，即使 prompt 完全相同也无法复用缓存。直连厂商通常有会话级别的亲和性保障。好的聚合平台在转发请求时，会对同一租户、同一场景的请求尽量路由到同一厂商实例。

根因三：图片预处理
对图片做压缩、格式转换、水印等操作，改变了图片的二进制内容，导致基于内容哈希的缓存键失效。好的平台提供透传模式，对图片不做任何修改。

根因四：折扣截留
厂商给缓存命中部分的 token 折扣（通常 50%-90%），部分平台不完全传递给用户——厂商给 90% 折扣，平台给用户算 70%，中间差 20% 被平台截留为利润。

如何验证你的平台缓存是否够“良心”

1. 查账单，看输入 token 的等效计费量。 如果你的 system prompt 很长且固定，单次请求的输入 token 计费量应该远小于 system prompt 的原始长度。如果计费量接近原始长度，说明缓存根本没生效。
2. 做对比实验。 同一条请求分别走聚合平台和直连厂商各发 10 次。第一次都应该全价。如果第 2-10 次聚合平台的计费量明显高于直连，说明平台在缓存上做了手脚。
3. 检查 prompt 是否被平台修改。 在请求中插入一个特殊标记（如 __TRACE_MARKER__），看平台返回的原始请求回显中是否还有这个标记。如果标记位置变了或者被包裹了额外内容，说明平台修改了你的 prompt。
4. 图片缓存验证。 同一张图连续发 10 次请求，看输入 token 计费量是否从第二次开始显著下降。如果没有下降，说明图片缓存没生效。

总结

聚合平台的缓存省钱效果，核心结论可以浓缩为四句话：

长 system prompt 场景缓存收益最大，能省 60%-90% 的输入成本。 但前提是平台不做 prompt 注入、保持实例亲和性、完整传递折扣。这三个前提缺一个，收益都会大幅缩水。

图片缓存比文本缓存更脆弱。 平台对图片的任何“优化”都会破坏缓存，且图片 token 量大，一次缓存失效的代价远高于文本。

不同平台的缓存效果差异巨大，差平台可能让你多花一倍的钱。 综合加权对比中，好平台能帮你省到直连的 99%，差平台只省到 55%——中间差的 44% 不是给了厂商，是被平台的缓存策略问题吃掉了。

验证缓存效果很简单，10 次连续请求就能看出来。 不需要复杂的压测。找一条固定 system prompt 连发 10 次，看计费量变化。第二次开始应该显著下降，如果没有，果断排查。

Prompt Caching 是当前大模型 API 调用中最有效的成本优化手段，没有之一。但前提是你用的平台能把这个优化完整地传递给你。选平台之前，先花半小时做一轮缓存验证——这半小时可能帮你每年省下几千到几万美金的 token 费。