在我们的 Banking77 基准测试中，HotKV 将 Claude 的 Token 用量降低了 70%

语义缓存的承诺是：对重复和相似的问题直接从内存中作答，而不是调用模型，从而削减 LLM 开支。我们对此进行了端到端测量：将同样的 3,000 个客服请求向四个 Claude 模型各发送两遍，一遍直接发给模型，一遍经由前置的 HotKV，两次运行都开启了 Anthropic 自身的提示词缓存。下面详细说明我们运行了什么、发现了什么，包括其不足之处。

简而言之：在四个模型中的每一个上，HotKV 都将模型调用次数、输入加输出 Token 以及 API 成本降低了约 70%。其中大部分来自完全重复的问题。语义层在此之上再贡献约 12 个百分点。在默认的 0.81 相似度阈值下，缓存答案被评判为切合原问题的比例比新答案低 5.8 至 10.7 个百分点。在我们唯一做了阈值扫描的模型（Sonnet 5.5）上，阈值为 0.88 或更高时没有出现这种差距。

2026 年 10 月 12 日更新：本文现在报告的是我们在四个当前 Claude 模型上进行的更大规模运行。它取代了较早一次在 GPT 和 Claude Sonnet 5 上进行的 1,500 个请求的运行，那次运行测得 Token 减少约 60%，我们已不再展示该结果。

测试内容

工作负载

我们重放了 Banking77（PolyAI，CC BY 4.0）测试集中的客服问题。这是一个由简短银行问题组成的公开数据集，标注了 77 个意图。它由 Casanueva et al., 2020 提出。这 3,000 个请求以固定种子抽取。意图热度服从指数为 1.0 的 Zipf 分布，这是一种人为设定的偏斜，少数意图出现的频率远高于其余意图；在每个意图内均匀抽取问题，允许重复。全部 77 个意图都有出现，3,000 个请求中有 1,264 个是互不相同的问题（通过重放带种子的请求生成器统计得出）。这家银行及其客服政策均为虚构。我们编写了一份约 2,200 Token 的政策，在每个请求中作为系统提示词发送，要求用两到四个简短的句子作答。

模型与设置

我们运行了 claude-fable-5-1、claude-opus-5-5、claude-sonnet-5-5 和 claude-haiku-5-5。Fable 5.1 和 Opus 5.5 以最低推理强度运行，因为它们的思考无法关闭。Sonnet 5.5 以其最低设置运行，即关闭预先思考；Haiku 5.5 则禁用了思考。Fable 和 Opus 的最大输出为 2,000 Token，Sonnet 和 Haiku 为 400 Token，每个回答都正常结束，没有被截断。两种模式下都同时运行八个请求，调用不使用流式传输，每种条件只运行一次。

两次运行

• 基线：每个请求都直接发给模型，并开启 Anthropic 的提示词缓存（在系统提示词上设置 cache_control，使用默认的五分钟有效期）。这是本文所采用的配置基线，并不表示已用尽服务商侧的所有优化手段。
• 使用 HotKV：HotKV 位于同样的流量和同样的系统提示词之前，缓存从空开始。

统计方式

每个 Token 数都取自 API 响应的 usage 块：未缓存的输入、缓存读取和写入，以及输出（包括思考）。嵌入 Token 单独计算。成本按 Anthropic 2026 年 10 月 11 日的标价计算，包含语义查找所需的嵌入调用，不包含 HotKV 的托管和运维费用。这些数字并非当前价格的报价。

缓存的工作原理

对于每个问题，HotKV 会在调用模型之前尝试两次查找：

1. 精确匹配：对一个 SHA-256 键执行 GET，该键由模型、系统提示词版本和规范化后的问题（转为小写，合并空白字符）生成。它能捕获措辞完全相同的问题。
2. 语义匹配：使用问题的嵌入向量（OpenAI text-embedding-3-small，余弦相似度）调用 SCACHE.GET。它查找相似的问题。仅凭相似度分数无法保证缓存答案切题。

只有两次查找都未命中时，请求才会到达模型，其答案随后通过 SET 和 SCACHE.SET 写回。语义命中的相似度阈值在运行前就固定为 0.81。我们在独立的 Banking77 训练集上以 0.01 为步长选出了它：它是能让语义命中至少 98% 指向同一意图的最低值（在训练集上为 98.2%）。在本次运行中，在未动用过的测试集上，96.7% 至 96.8% 的语义命中与所提问题的意图一致：每个模型在 926 至 936 次语义命中中有 30 或 31 次意图错误。

结果

调用、Token 与成本

四个模型合计，调用次数从 12,000 降至 3,588，Token 减少 70.1%，成本降低 69.6%。在每个模型上，约 70% 的请求由缓存应答：约 39% 来自精确匹配，31% 来自语义匹配。

调用次数、Token 和费用同步下降，因为 HotKV 省去的是整次调用。解读 Token 数字时需要谨慎：所统计的 Token 中有 90% 至 93% 是对同一份 2,200 Token 政策提示词的缓存读取，而 Anthropic 对这部分只按正常输入价格的一小部分计费。输出 Token 只占 Token 总数的 6% 至 9%，却占基线成本的 73% 至 92%。

速度

整个运行的响应时间中位数在 Fable 5.1 上从 2.7 秒降至 127 ms，在 Opus 5.5 上从 2.9 秒降至 126 ms，在 Sonnet 5.5 上从 1.8 秒降至 128 ms，在 Haiku 5.5 上从 1.4 秒降至 125 ms，即快了 11 至 23 倍。重复问题的返回时间中位数约为 0.05 ms，由与 HotKV 位于同一台机器上的 Python 客户端通过本地回环测得，因此这是本地数据，而非网络数据。由语义缓存应答的改写问题耗时约 130 ms，几乎全部花在嵌入 API 调用上。

整个运行的中位数落在语义命中的区间内，因为精确命中（约占请求的 39%）本身不足以决定中位数，而精确命中和语义命中加起来（70%）超过了一半。慢的一端变化较小：30% 的请求仍要调用模型。在 Fable 5.1 上，第 99 百分位数在使用 HotKV 时约为 6.4 秒，不使用时为 6.6 秒，Haiku 5.5 上大致相同。在 Opus 5.5 上（4.7 秒对比约 6 秒）和 Sonnet 5.5 上（2.7 秒对比 3.3 秒）则更低。调用不使用流式传输，因此这些是获得完整答案的时间，而非获得首个 Token 的时间。

预热

缓存从空开始，因此早期的请求仍会到达模型。由缓存应答的请求比例在最初一千个请求中约为 52%，在最后一千个请求中约为 81%。

节省从何而来

大部分节省来自单纯的重复。仅用精确匹配缓存时，3,000 个请求最多需要 1,264 次模型调用，每个不同的问题一次，即减少约 58%。语义层将这一比例提高到约 70%，因此在这一工作负载上它贡献了约 12 个百分点。正如下一节所示，答案质量的风险也正来自这一部分。这一结论是根据请求序列和日志推算的，而不是单独测量的一次运行。

答案质量

语义命中指的是意图相同，而不是正确答案相同。为了衡量正确性，我们让另一个 Claude 模型评判每一次语义命中。评判模型看到客户的问题和以随机顺序排列的两个答案：HotKV 提供的缓存答案，以及同一模型在基线运行中针对该原问题给出的新答案。它判断每个答案是否正确回答了该原问题。Opus 5.5 评判 Fable 5.1、Sonnet 5.5 和 Haiku 5.5 的答案，Fable 5.1 评判 Opus 5.5 的答案，因此没有任何模型评判自己的输出。

默认阈值下

在 0.81 阈值下，缓存答案切合原问题的比例比同一模型的新答案低 5.8 至 10.7 个百分点。语义命中约占请求的 31%，因此放到全部响应中，并将精确命中视为无影响，这一差距约为 2 至 3 个百分点（1.8 至 3.3）。各评判模型的严格程度不同，因此只应在同一模型内比较缓存答案与新答案。

提高阈值

我们在另外四个阈值下重新运行了 Sonnet 5.5，每次都从空缓存开始，并使用同一个评判模型。基线成本为 $5.51。

从 0.88 起，缓存答案相对新答案没有表现出劣势，同时在 0.88 时仍能将成本降低 64%，在 0.90 时降低 61%。证据并不充分。在 0.90 时，差值的 95% 区间大约从差 4 个百分点到好 7 个百分点，0.95 这一行只有 50 次命中，而且每一行评判的是不同的命中子集。这只是一个模型、一个评判模型，每个阈值各运行一次，因此既不能证明质量相当，也不能说明存在普遍适用的安全阈值。

几乎相同的问题

真正的风险在于看起来几乎相同、却需要不同答案的问题，例如存款与取款。我们让 Opus 5.5 编写了 119 组问题对，每组包含一个真实的训练集问题，以及一个改动了某个关键细节的版本，然后统计在缓存中只有原问题时，有多少改动后的问题会越过阈值。这些问题对是刻意构造的难题，未经人工审核，展示的是最坏情况，而不是实际流量中出现的频率。

提高阈值能降低风险，但无法消除风险。即使在 0.90，仍有 25% 的刻意相近的问题对会被匹配，而且能被匹配的真正改写问题也会变少。

规模化后意味着什么

将实测的单次请求成本外推到每天 100 万次请求、每月 30 天，并假设流量模式不变，可得出以下每月数字：

• claude-fable-5-1：不使用 HotKV 约 $303,100，使用后为 $91,800，约节省 $211,300。
• claude-opus-5-5：不使用 HotKV 约 $146,000，使用后为 $45,000，约节省 $101,000。
• claude-sonnet-5-5：不使用 HotKV 约 $55,100，使用后为 $16,600，约节省 $38,500。
• claude-haiku-5-5：不使用 HotKV 约 $2,700，使用后为 $800，约节省 $1,900。

这是基于实测单次请求成本的算术推算，而不是又一次实测运行。它不包含托管费用，而且支撑这一请求量所需的容量并未测量。在我们实际运行的 3,000 个请求中，Haiku 5.5 只节省了 $0.19，Fable 5.1 节省了 $21.12。四个模型均以简短回答运行，Fable 5.1 和 Opus 5.5 使用最低推理强度，因此更长或推理更密集的回答会让每次避免的调用价值更高。

局限性

这并不是一个笼统的“HotKV 能为您节省 70%”的说法。这是我们在这一工作负载上测得的结果，而起主要作用的正是这一工作负载。

• 节省幅度取决于重复程度：如果每个意图出现的概率相同，而不是呈 Zipf 偏斜，Sonnet 5.5 和 Haiku 5.5 上的成本降低了 56%。如果 3,000 个问题全都互不相同，成本降低了 38%，这完全来自同一意图下不同问题之间的语义匹配，而 Banking77 中这类问题很多。没有重复或相似问题的工作负载不会有任何节省。
• 合成流量：每次抽取相互独立，没有突发、会话或多轮上下文。仅使用一个由简短银行问题组成的公开数据集、一份为本测试编写的虚构政策，以及一个约 3,080 个测试问题的有限问题池。
• 由模型评判答案：没有人工审核，没有第二个评判模型，并且所有评判模型都是 Claude 模型。新答案未通过评判模型“切题”检验的比例在 1% 到 21% 之间，因此这是一个严格的标准。
• 意图相同不等于答案相同：0.81 阈值是根据意图标签校准的，而不是根据答案质量。阈值扫描和几乎相同问题测试只覆盖了一个模型和一个嵌入模型。
• 小型测试环境：每种条件只运行一次，单台 4 vCPU 服务器，客户端位于同一台机器上，并且在 HotKV 运行前缓存没有预热。
• 成本仅为 API 成本：不包含 HotKV 的托管和运维费用。请用您自己的问题验证答案质量，并在不适合语义复用的场景中使用精确缓存或新答案。

各模型的数据也可在 AI 页面上查看。

亲自试一试

本测试中的精确匹配缓存只使用普通的 GET 和 SET，每个 HotKV 套餐都包含这两条命令。语义缓存（SCACHE.*）随 Performance 及以上套餐提供（价格）。在 HotKV Cloud 上开始使用，并将现有流量指向它；如果您想先针对自己的工作负载算一算这些数字，也可以联系销售。