一、项目背景

我们观察到网关日志里大量请求高度相似：同一个产品介绍、同一份政策问答、同一类模板生成，被不同用户、不同时间段反复调用，每次都走一遍完整推理，既烧 GPU 又慢。月初一次大促，光活动规则说明这一个问题的重复调用就占了当天总量的近两成。我们意识到，不解决复用，算力永远不够用，扩多少台机器都不解渴。更夸张的是，同一个内部员工一天能就同一个政策问七八遍，每次都重新算一遍，白白占用推理队列。

二、落地场景

我们在网关层加了一层语义缓存：请求进来先算 embedding，和缓存里的历史请求做近邻比对，相似度超过阈值就直接返回历史结果，不再调模型。命中缓存的响应从原来的两三秒降到毫秒级。适用场景主要是事实类、模板类、政策类问答，这类问题答案稳定，缓存复用风险低。创意生成类则默认不缓存，避免千篇一律。业务侧完全无感，只是发现这类问题突然变快了，高峰期也不再排队，体感上像模型凭空变强了。

三、关键技术挑战与解决思路

缓存最大的雷是答非所问。相似不等于相同，把 A 的回答给 B 会出事故。我们设了三道保险：第一，只对高稳定场景开放缓存，动态数据类强制直连；第二，相似度阈值卡得紧，低于 0.95 不命中，宁可多算也不错答；第三，给缓存结果带 TTL 和版本号，政策一更新旧缓存自动失效。去重方面，我们用 SimHash 对请求做指纹，防止同一问题微小措辞差异绕过缓存。命中率监控实时跑，太低就报警说明场景选错了，及时关掉。我们还按业务域分别设缓存池，避免跨域污染导致张冠李戴。

四、效果数据

上线约四个月，语义缓存整体命中率约三成，高稳定场景（政策问答、产品介绍）命中率超五成。网关日均模型调用量因此下降约两成，对应 GPU 利用率峰值下降明显，月度算力成本省下约两成。缓存命中响应 P99 从 2.8 秒降到 120 毫秒以内。期间因阈值收紧，未发生一起错答投诉，误命中率为零。缓存命中分布显示，政策类问答贡献了六成以上的节省量，产品介绍次之，这块投入产出比最高，我们后续把预算优先投在了这两个场景的缓存调优上。

五、可复用经验总结

缓存不是银弹，选错场景比不缓存更危险。我们一开始想全量开缓存，被算法同学拦下，改成先圈定稳定场景试点，是对的。阈值宁紧勿松，错答的代价远大于多算几次的成本，这点我们达成共识后就没再松过口。TTL 和版本号是缓存的保险丝，政策类内容没有失效机制迟早出事，这点生产环境教训足够多。命中率监控要跟上，它直接告诉你这个场景该不该继续缓存，别让它变成没人看的摆设。先小范围验证再推广，比一口气全开稳得多，也更容易拿到业务信任。

结语

缓存这东西，我们一开始雄心勃勃想全量开，被算法同学一盆冷水泼醒，才老老实实先圈稳定场景试点，现在看那个拦是对的。错答的代价远大于多算几次，这个共识是我们用生产环境的教训换来的，所以阈值一直卡得很紧。政策类内容我们特意都带了版本号，更新即失效，宁可短暂多算也不让新旧规则混答。踩过的另一个坑是初期命中率监控没人盯，后来固化成日报才真正用起来，工具上了还得有人看。整体来说缓存是省钱的，但省的是该省的，不是拿准确率去换，这条线我们划得很死，下一步想试试语义缓存和结果缓存的组合，但会先在小流量验证。

我们后来把缓存命中率直接挂进了网关大盘，哪个场景该不该继续缓存一眼就知道。政策类内容我们特意都带了版本号，更新即失效，宁可短暂多算也不让新旧规则混答，这条线我们划得很死，省下的算力成本足够再养几个高稳定场景的缓存。

缓存最怕命中率虚高，所以我们上线前专门测过各种措辞变体，确认相似度阈值卡得够紧才放开，宁可多算几次也不放错一条，这条原则到现在没松过口。高稳定场景的缓存我们还做了版本维度隔离，政策一变旧缓存立刻失效，运维不用半夜爬起来手动清，这也是踩过坑之后才补的保险。

案例片段（已脱敏）： 请求指纹比对日志： 用户 A：你们会员退费规则是什么 → embedding 与缓存条目 C-3381 相似度 0.97 → 命中，返回历史答案，耗时 90ms 用户 B：会员费怎么退 → 相似度 0.96 → 命中 用户 C：我上个月的会员费能退吗（含时间限定） → 相似度 0.82 → 未命中，转模型推理 当月政策问答场景命中率 53%，误命中 0，节省模型调用约 11 万次。一次政策更新后，旧缓存按时失效，未出现新旧规则混答，监控看板上的命中率曲线未出现突变，运维据此确认失效逻辑生效。