多人共用一个 key，缓存命中率会不会因此降低？

团队刚把一堆 AI 调用并到一个大模型推理套餐上，月底账单摊开，有人拍桌子："是不是咱们这么多人共用一个 key，把缓存命中率搞崩了？"

这话对一半，错一半。

对的是，多人共用套餐确实可能把命中率拉下来。错的是，锅根本不在"key 相同"上。缓存命中这件事，从头到尾跟 API key 没关系。

缓存到底在缓存什么

先说清楚缓存到底在缓存什么。大模型每回推理，都要把 prompt 前面那一截 token 的注意力中间结果算出来，这东西叫 KV Cache。下一回再来一个请求，系统从第一个 token 开始逐段比对：前面 N 个 token 跟之前缓存的完全一致，这 N 个就直接复用算好的结果，不用重算。

省的是哪段算力？主要是 prefill------把输入 token 喂进模型、算注意力那一步。system prompt 越长、工具 schema 越厚，每次重算越亏。命中之后，这部分按低价计费，通常只有正常输入价的四分之一到十分之一。一个 Agent 跑一轮动辄上万 token 的上下文，命中率每掉十个点，账单就是实打实的数字。

所以别把命中率当性能指标看，它是预算杠杆。团队越大，这根杠杆越长。

匹配的维度是模型，不是 key

关键在四个字：前缀一致。匹配维度是（模型, 前缀 token 序列），不是（账户, key）。不同人用不用同一个 key，只要调的是同一个模型、前面那串 token 长得一样，就命中同一条缓存。

所以"共 key 互相拖后腿"即使真的发生，本质也是缓存池容量被一堆杂前缀挤占的副作用，不是匹配失败。这一点得先掰过来，不然团队一准在"要不要每人发一个 key"上较劲，方向就歪了。

有人觉得"那我每次请求都带个缓存标识不就完了"。不是这么回事。标识不是魔法开关，前缀不一致，标识填对了也白搭，反而有污染风险，这个后面说。

前缀稳定到底什么意思

"前缀一致"说白了就是 prompt 最开头那段别乱动。

最典型的坑，是在 system prompt 里写"今天是 2026 年 9 月 1 日"。过个零点，日期一变，整个 system prompt 的前缀就对不上了，所有缓存瞬间失效，首 token 延迟当场飙起来，用户体感就是"这模型怎么突然卡了"。正确做法是把时间这种动态东西沉到最后一个 user message 里，system prompt 纹丝不动。

工具 schema 的顺序是另一个隐蔽杀手。很多人序列化 JSON 时不锁 key 顺序，今天 tool_A 在前、明天 tool_B 在前，前缀从第一个工具定义就开始错位，命中率悄悄往下掉。按名字字典序固定下来，这一条就能白捡几个点。trace_id、用户名、随机数这些，只走请求头，别进 prompt。

一棵前缀树想明白的事

前缀匹配这件事，我后来画了一棵前缀树才彻底想透：

A        => 缓存 A
AB       => 命中 A，缓存 AB
ABC      => 命中 AB，缓存 ABC
AD       => 命中 A，缓存 AD
ADE      => 命中 AD，缓存 ADE

A 是公共根，AB 和 AD 是它的两个分叉。请求不是"整条命中或者整条 miss"，而是从根往叶子一层层比对，能复用多少复用多少。这棵树直接告诉我们两件事。

第一，"两人共用同一个缓存"是个伪命题。张三走 ABC、李四走 ADE，他们根本不是在同一条请求上复用，而是各自命中了公共根 A。缓存命中的单位是前缀节点，不是整条任务。所以团队里每个人干的活完全不同，照样能在 A 这一层命中------只要 A 是一样的。

第二，命中率的最高杠杆，是让 A 尽可能长、尽可能贵。A 通常是工具 schema 加上全局规范，这两段往往是整个 prompt 里 token 数最多的，动辄几千。把它们抽成最前面、全团队共用（或同业务线共用）的根，命中收益最大。到这儿就明白，所谓的"团队共用前缀"不是让所有人写一模一样的 system prompt------那是既不现实也没必要的极端。真正要做的，是共用那个最贵最稳定的根。

几个平台通用的手段

光理解原理不够，几家主流平台都有差不多的抓手，得用上。

请求级的缓存标识或断点：主流平台都支持告诉缓存系统"哪段前缀可以复用"，有的叫 cache breakpoint，有的叫 cache key。填对话 ID，别填会话 ID，不同对话换不同值。为什么要换？因为不换的话，不同对话的 KV 会串，模型开始答非所问。

会话亲和路由：把同一个会话的连续请求路由到同一个推理实例，那台机器上的 KV 常驻，局部命中率能拉到接近满。反过来说，如果你把不同业务线的请求打散到不同实例，每台机都得冷启动重建一次，等于自己把命中率打下去。这正好印证了"同类任务排队连跑"------不是玄学，是实例局部性的硬约束。

监控：云厂商都提供缓存命中率指标，而且多半能按 key 或业务线维度拆。团队按业务线分 key，每个 key 的命中率一目了然，谁的 system prompt 在乱动，看板上一眼就露馅。

团队怎么落地

策略就一句话：按业务线分叉，不是全团队一字不差。

A 根是工具 schema 加全局安全/格式规范，全团队共用；B、D 是角色声明加业务指令，同角色共用；C、E 是用户问题和检索结果，甩在最后。张三写后端、李四写前端，角色不同，但根 A 相同，都命中 A。

还有一笔白送的命中，很多人没算进去：Agent 跑一个任务本来就是多轮循环。同一段 system prompt 在二十轮里原样出现二十次，每轮都命中前面那段。这跟跨人共用没关系，是单任务自己喂出来的。所以哪怕团队前缀再乱，只要每个人自己的 system 稳定，单任务内的命中率就不会差。共用根解决的是另一个问题：让每个新会话的第一轮也命中，不用从冷启动开始烧。

翻车的地方

这套也有翻车的时候，而且翻起来很疼。

最狠的是发版。你改了 system prompt，全团队的缓存前缀一夜之间全不匹配，命中率从百分之八九十直接掉到零，账单当场翻倍。所以 system prompt 必须进版本管理，改动走预热加灰度，别一把梭全量。发版前先用少量模拟会话把 KV 建起来，再灰度放流量，这是各家平台文档都在说的老生常谈，但真出事的基本都是没做这步的。

缓存污染是另一个坑。有人图省事，把缓存标识设成全团队一个固定值，想让所有人共用前缀。如果平台是只按标识匹配、而不是按标识加前缀内容联合匹配，不同对话的上下文会被错误复用，模型答非所问。这个玩法没有官方背书，要上生产得先 A/B 测，别赌。

别拍脑袋

说到底，缓存命中率这事没有玄学。打开命中率看板，按 key 排个序，命中率低的那条业务线，回去查它的 system prompt 是不是写了日期、schema 顺序抖没抖。比拍脑袋猜"是不是共 key 的锅"管用一百倍。