HotKV语义缓存实测：Claude token成本降70%的真相

一次严谨但有限制的基准测试

HotKV 团队在 BankING77 数据集上做了一次端到端测试：把 3000 条客服问题分别发给四个 Claude 模型，一次直连模型（保留 Anthropic 提示缓存），一次在模型前加一层 HotKV 缓存。结果很抓眼球——模型调用、输入输出 token 和 API 成本都降了约 70%。

但这份报告最有价值的部分，恰恰是它对适用边界的坦白。HotKV 自己强调：这不是一个通用的“省 70%”承诺，而是特定负载下的测量结果。

缓存到底怎么工作

HotKV 在调用模型前做两次查找。第一次是精确匹配，对标准化后的问题、模型标识和系统提示词版本做 SHA-256 哈希，命中则直接返回。第二次是语义匹配，用 OpenAI 的 text-embedding-3-small 生成向量，在缓存里找余弦相似度超过阈值的问题。两次都未命中，才真正调用模型，并把答案写回缓存。

测试前把语义阈值固定在 0.81。这个值是在 Banking77 训练集上校准的——保证语义命中至少 98% 指向同一意图的最低阈值。但在实际测试集上，语义命中的意图一致率是 96.7% 到 96.8%，每个模型有 30 到 31 次命中错误意图。这说明意图标签级别的准确率，已经不能完全等价于答案正确率。

余弦相似度衡量的是两个向量在方向上的接近程度，取值在 -1 到 1 之间，越接近 1 表示两段文本的语义越相似。语义缓存把每个问题映射为高维向量后，正是靠这个数值来判断新问题是否"等同于"缓存中的旧问题。阈值 0.81 意味着只有相似度达到 0.81 以上才会命中缓存。需要理解的是，余弦相似度高只说明向量方向接近，并不保证答案可以互换——这正是文中"近似问题"误命中风险的数学根源："存款"与"取款"的向量可能相当接近，但意图截然相反。

text-embedding-3-small 是 OpenAI 提供的嵌入模型，负责把文本转换成固定维度的数值向量，供相似度检索使用。它体积小、调用成本低、延迟短，因此常被用于语义缓存和检索增强这类需要"每条请求都做一次向量化"的场景。但嵌入模型只捕捉语义的总体方向，对单个关键细节（如金额、方向词、否定词）的区分能力有限，这解释了为什么语义缓存的命中判断会在细微改动的问题上失准。

省下来的钱从哪来

四个模型（Fable 5.1、Opus 5.5、Sonnet 5.5、Haiku 5.5）合计调用次数从 12000 降到 3588，token 降 70.1%，成本降 69.6%。约 70% 的请求由缓存回答，其中精确匹配贡献约 39%，语义层额外贡献约 31%。

关键洞察是：大部分节省来自问题的完全重复，而非语义相似。如果去掉语义层，仅精确匹配最多需要 1264 次模型调用（对应 1264 个不同问题），已经能省约 58%。语义层在这个负载上只额外贡献了约 12 个百分点——而它正是答案质量风险的来源。

另一个容易被误读的数字是 token 构成。计数的 token 中 90% 到 93% 是同一个 2200 token 系统提示词的缓存读取，Anthropic 对这种读取收费极低。输出 token 只占 token 总量的 6% 到 9%，却占基线成本的 73% 到 92%。所以成本下降的主因是消除了完整调用，而不是 token 计数的表面游戏。

提示缓存（prompt caching） 是 Anthropic 等厂商提供的机制：当多次请求共享同一段很长的前缀（如 2200 token 的系统提示词）时，模型可将该前缀的计算结果缓存复用，对缓存读取部分按远低于常规输入的价格计费。文中 token 计数里 90% 到 93% 是系统提示词的缓存读取，正是这一机制在起作用。理解这一点很关键：它说明"token 数降 70%"和"成本降 70%"是两件不同的事，成本下降的主因是消除了整次模型调用，而非 token 单价的账面变化。

速度提升与代价

中位响应时间从 1.4 到 2.9 秒降到约 125 到 128 毫秒，提升 11 到 23 倍。但这是整体中位数，因为 70% 的请求走缓存把中位线拉进了语义命中的区间（约 130 毫秒，主要是 embedding API 调用）。精确命中本身的中位延迟约 0.05 毫秒，但这是本机环回测量，不是网络环境。

长尾改善有限：30% 的请求仍然调用模型，P99 延迟在 Fable 5.1 上从 6.6 秒降到 6.4 秒，几乎没变。对于延迟敏感型应用，缓存只能解决重复和相似请求，无法消除冷启动或长尾延迟。

答案质量：真正的软肋

这是整份报告最诚实也最值得关注的部分。HotKV 让一个不同的 Claude 模型来评判每次语义命中：给评委看用户问题、缓存答案和基线答案，判断哪个真正回答了问题。

在 0.81 阈值下，缓存答案“符合问题”的比例比新鲜答案低 5.8 到 10.7 个百分点。换算到全部响应（语义命中约占 31%），整体质量损失约 2 到 3 个百分点。Haiku 5.5 的差距最大，达 10.7 个百分点，缓存答案合格率仅 67.9%。

提高阈值能缓解问题。在 Sonnet 5.5 上扫描多个阈值后发现，0.88 以上缓存答案不再显示质量劣势，同时仍能省 64% 成本；0.90 省 61%。但证据很薄弱：0.90 时差异的 95% 置信区间从差 4 点到好 7 点，0.95 只有 50 次命中，且每行评判的是不同子集。

更严峻的是“近似问题”测试。HotKV 让 Opus 5.5 生成了 119 对问题，每对是一个真实问题加一个只改了一个关键细节的版本（比如存款 vs 取款）。在 0.81 阈值下，62% 的改动问题会错误命中；即使提高到 0.90，仍有 25% 会命中。真正的同义改写命中率却从 39% 降到 4%。这意味着语义缓存天然面临一个权衡：阈值越高越安全，但能覆盖的改写越少。

这组数字该怎么读

节省高度依赖重复率。把意图分布从 Zipf 倾斜改成均匀分布，Sonnet 和 Haiku 的成本降幅从 70% 掉到 56%；如果 3000 个问题全部不同，降幅只有 38%，且全部来自同一意图下不同问题的语义匹配。完全没有重复或相似问题的负载，节省为零。

规模化推算也要谨慎。按每天 100 万请求、每月 30 天推算，Fable 5.1 每月可省约 21.1 万美元，Haiku 5.5 只省约 1900 美元。这个推算是基于测量到的单请求成本做的算术，不是另一次实测，而且排除了 HotKV 自身的托管和运维成本。

测试环境本身也有局限：每个条件只跑一次，单台四核服务器，客户端与缓存同机，缓存未预热（前 1000 个请求缓存命中率约 52%，后 1000 个约 81%）。

Zipf 分布（齐夫定律）描述的是"少数高频、大量低频"的长尾现象：排名第 n 的项其出现频率大致与 1/n 成正比。真实的客服问题分布高度符合这一形态——少数常见问题被反复问及，大量问题则很少出现，因此缓存能覆盖大部分流量。文中把分布改成"均匀分布"做对照，本质上是人为消除这种头部集中效应，用来量化"节省到底有多少来自问题重复"。这也提示开发者：评估语义缓存收益前，应先测量自身流量的重复率分布，而非直接套用 70% 这一数字。

对开发者的实际建议

这份基准测试的最大价值，是它清楚划出了语义缓存的适用边界。对于客服、FAQ 这类高重复、意图收敛的场景，缓存的经济账很划算，但需要接受一定的答案质量折损，或把阈值调高到 0.88 以上来换取安全。对于问题几乎不重复、或细微措辞差异导致答案截然不同的场景（金融交易指令、医疗剂量等），语义缓存的风险可能超过收益，精确匹配或直接调模型更稳妥。

HotKV 的精确匹配缓存所有套餐都包含，语义缓存（SCACHE.*）需要 Performance 及以上套餐。团队建议先在自有问题上验证答案质量，再决定是否启用语义复用——这个建议本身比 70% 这个数字更值得记住。