155 份回复里装着别人的上下文，GLM 缓存串号始末

你发了一个超长提示词，收到的回复却带着别人问题的痕迹。这种事在 Cloudflare 的推理服务上真的发生了，155 次。

一、发生了什么

Cloudflare 10 月 26 日发布复盘：8 月 27 日到 9 月 9 日间，Workers AI 上的 GLM-5.3 模型出现跨请求缓存串读，少数客户收到的回复里混入了其他客户在不久前的请求内容。受影响共 155 条响应，全部是提示词超过 68 万 token 的超长请求；其他模型未受影响，也没有证据显示被蓄意利用。

根因是两个问题叠加。配置层面，GLM-5.3 以约百万 token 的上下文窗口上线，但预填充阶段的缓存池只装得下约 68 万 token，上线前已知不匹配却没当成风险——测试只看了响应码，没看输出内容是否连贯。引擎层面，推理引擎 SGLang 在请求超池时的拒绝路径有一个缺陷：请求被拒后仍被当作存活，解码端于是对着没被覆写的旧缓存页做计算，旧页里正是上一个用户留下的数据。讽刺的是，返回的状态码是 200，token 计数也对得上，读起来通顺，肉眼几乎无法察觉。

9 月 8 日晚，来自 Knostic 的研究员通过漏洞赏金项目提交报告。Cloudflare 次日宣布事件后 40 分钟内下线模型，25 分钟里就用两个独立账号复现了泄露，当天完成配置回滚与引擎补丁并恢复公开。修复后的缓存池扩到约 204 万 token，是上下文窗口的两倍，正常请求永远碰不到那条出错路径。

二、跟你有什么关系

推理服务使用者：超长上下文请求是这次事故的唯一触发条件，用长文本跑第三方推理接口时要意识到这类风险真实存在。

自建推理团队：缓存池大小和上下文窗口是两套逻辑算出来的，没人替你校验一致性，这个坑谁家都可能有。

AI 应用开发者：多租户场景的隐私承诺，靠的是基础设施而不是模型本身，选供应商时值得问一句缓存怎么隔离。

三、怎么判断

1. 用 SGLang 的立刻升级到 v0.5.22 或更高，这批修复已进正式版本。
2. 自查部署配置：缓存池容量必须不小于上下文窗口，且两处数字要写在同一条检查项里；引擎的拒绝路径要有测试覆盖。
3. 长上下文测试别只看状态码，抽检回复内容是否只包含你发的内容。

四、三个别信的说法

「模型安全了就没事」。 这次模型本身没有毛病，出事的是配置和调度。买「安全模型」不能替代审基础设施。

「串号是极端罕见事故，说明平台不行」。 换个角度看：整个窗口期只有 155 条受影响，报告到下线只用一晚，复盘完整公开。真正糟糕的是出了事不公布的那种。

「回复看起来正常就是没泄」。 恰恰相反，串号响应带着正确的 token 计数、读起来连贯，靠肉眼几乎发现不了。这次是研究员主动猎捕才现形的。

五、一句话结论

多租户的缓存不擦干净，下一个用户就可能读到上一个用户的秘密——隔离是基础设施的责任，不是模型的。

信息来源

• Cloudflare 博客：GLM-5.3 跨请求 KV 缓存泄露的根因与修复（2026-10-26）

功能与价格以官方公告为准。本文写于 2026 年 10 月 27 日。