每天 1.4 亿次调用中，有多少请求在重复提问？从缓存命中条件到流量规模，看看语义缓存如何减少重复调用的开销。
Starsg 网关每天处理 1.4 亿次调用，其中 31% 的提示词与过去 24 小时内处理过的请求意思相近。精确匹配缓存只能识别其中约三分之一；语义缓存则按含义判断，覆盖其余部分。对多数团队来说，这是不更换模型就能显著降低成本的一种方式。
语义缓存怎样判断命中
收到提示词后，我们先将它转换成嵌入向量，再到该租户的向量索引中查找相似请求。余弦相似度超过对应路由的阈值，就判定为命中。事实查询的默认阈值为 0.97；调用方标记为生成类的请求，阈值为 0.99。未达到阈值时，请求仍会发往上游，返回的响应再写入索引。
- 客服与常见问题：命中率 52%，用户反复询问的主要是同样的二十个问题。
- 商品目录补全：命中率 38%，重复的 SKU 描述带来了较多命中。
- 编程辅助：命中率 19%，因为提示词往往带有各自不同的文件上下文。
- 开放式聊天：命中率 6%，这类场景不宜把缓存作为主要优化手段。
调用量越大，命中率就越高吗
决定命中率的是相似提示词有多集中，而不只是调用次数。当索引积累了约 5 万条不同提示词后，每天 1 万次调用和每天 1000 万次调用的场景，命中率会逐渐接近。调用量主要影响缓存积累的速度：大租户可能几小时就能积累足够的数据，小租户则可能需要几周。
上季度，在启用缓存的租户中，语义缓存平均减少了 41% 的上游计费 Token。缓存命中时，额外延迟的中位数为 11 毫秒。
开启与调优
client.chat.completions.create(
model="claude-sonnet-4-5",
messages=messages,
extra_body={
"amplink": {
"cache": {"mode": "semantic", "threshold": 0.97, "ttl": 86400}
}
},
)
建议先用较保守的阈值，观察一周的 served-from-cache 响应头，再按路由逐步放宽。在质量要求相同的前提下，针对不同路由分别调优，比全局使用一套参数的命中率通常高出 8–12 个百分点。