Cloudflare 承认 KV 缓存串租户：155 条响应里混进了别人的对话

Cloudflare 披露了一起推理层的事故：8 月 27 日至 9 月 9 日期间，其 Workers AI 上的 GLM-5.3 因前缀缓存键计算缺陷，在上下文超过 68.1 万 token 时发生跨租户 KV 缓存命中，155 条响应里混入了其他租户的数据。

时间线

盲测机构 Knostic 先独立复现了这个问题，Cloudflare 随后确认，切换到修复版本的 SGLang（0.5.20 到 0.5.22），10 月 26 日完成协调披露。

为什么这件事值得所有做推理的人看

前缀缓存是把省钱做到极致的技术：相同前缀只算一次，后面复用 KV。它的隐含假设是「前缀相同的内容属于同一个请求方」，一旦这个假设被长上下文挤破，缓存命中就变成了数据泄露。

关键点在于：模型本身的对齐没有任何问题，泄露发生在服务层。这跟过去几年大家习惯的「模型安全」是两条完全不同的防线。

自建推理要立刻检查的三件事

一是缓存 key 里有没有租户或会话标识，如果只用内容哈希，就是同一个坑。二是长上下文请求的缓存策略是否单独降级，超过阈值应该直接绕过缓存。三是能否按租户维度审计缓存命中日志——出了事至少能圈定范围，而不是回答「理论上不可能」。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

模型对齐没问题、泄露发生在服务层，这条最值得记住。自建推理先查缓存键里有没有租户标识，只用内容哈希就是同一个坑；长上下文超过阈值应该直接绕过缓存，省钱和隔离在这里是冲突的。

上下文超过 68 万 token 才触发，说明前缀缓存的键设计没考虑超长上下文的分片。自建推理的团队应该马上检查缓存键有没有把租户 ID 和模型版本一起纳入哈希，只做前缀匹配迟早出事。155 条这个数字，实际影响面可能被低估。

前缀缓存串租户是典型工程坑。我们自建推理服务时，cache key 必须拼上租户 ID、模型版本和 system prompt 哈希，少一项就可能串。上线前拿超长上下文压测一遍，比事后审计便宜太多。