一次「安静」的跨租户泄漏
10 月 26 日，Cloudflare 披露了一起发生在其 Workers AI 平台上的跨租户数据暴露：在 8 月 27 日至 9 月 9 日期间，部署在平台上的 GLM-5.3 模型因底层推理引擎 SGLang 的预填充/解码不匹配，导致部分响应中混入了其他客户近期请求的片段。受影响的是 155 条超长上下文（提示超过 681,280 词元）的响应。Cloudflare 称未找到主动利用的证据，但暴露面本身已经构成一起值得记录的多租户隔离事故。
这类事故的特殊之处在于：它不是某家小厂的偶发 bug，而是出现在头部边缘与云厂商的共享推理基础设施上，影响的也是「长上下文」这种正被越来越多企业采用的能力。
故障链：池子比窗口小，拒绝路径留了缝
技术细节值得拆开看。GLM-5.3 标称上下文窗口为 1,048,576 词元，但预填充 GPU 上的 KV 缓存池只容纳 681,280 词元。工程师原本相信超长提示会干净地报错，而短路径上的长上下文测试也一直通过，于是这个 mismatch 长期处于潜伏状态。
当某条提示超过缓存池时，SGLang 在分离式预填充/解码模式下把请求标记为拒绝、替换成一个单词元占位符，却仍把部分 KV 状态传给了解码节点；解码端假定预填充已覆写缓存页，于是上一轮会话遗留的缓存页在生成时仍可被读取。换言之，漏洞需要极长提示才触发，但一旦触发，就存在真实的机密性风险。
影响面与处置
Cloudflare 的处置分容量与逻辑两层：把缓存池扩容到约 2.04 百万词元（约为标称上下文的两倍），确保合法提示总能落进池子而不走拒绝路径；同时加固拒绝路径，让被中止的预填充不再留下可被活的解码会话复用的陈旧 KV 页。SGLang 维护方也发布了协同指引，建议运营方升级到 v0.5.22 或更高版本，并把分离式模式下的池子尺寸变化视为敏感项。
平台侧还披露，除 GLM-5.3 外没有其他 Workers AI 模型受影响，公司也未发现 deliberate 利用的证据。但法律风险并不因此消失——当提示中可能含有源码、患者摘要或未公开财务模型时，跨租户泄漏即便「低概率」也可能触发 GDPR 等框架下的 breach 评估义务。
为什么这件事值得写
它揭示了一个被长期低估的真相：在共享推理基础设施上，KV 缓存的尺寸与复用策略不只是性能旋钮，更是安全边界。任何对量化、张量并行或 CUDA 图的改动，都可能悄悄缩小有效池子尺寸；而多数团队的持续集成只测happy-path 延迟，不测「提示单调增长到拒绝」时的缓存清零。
对自托管 SGLang 的工程师，可操作的清单很具体：用对抗式测试把提示长度递增到拒绝点，验证拒绝是否真正清零或隔离缓存行；把 token 计数与模型 ID 记入日志；对接近百万词元的文档摘要类工作流，评估是否应放到带合同隔离保证的单租户专用集群。
给采购与治理的启示
对采购方，这起事件强化了「公共 API 看似便宜，但隔离失败虽罕见却对信任是毁灭性」的判断。评估云 AI 供应商时，应直接追问其预填充/解码部署如何测试超长提示、是否做缓存行金丝雀校验。
余波方面，预计会出现类似 SOC 2 扩展的认证，专门审计推理调度器的缓存复用模式；开源引擎也会加入在请求间用 canary 值涂抹 KV 页的调试模式，以便在预发环境检出陈旧读取。对银行这类对模型风险团队，这起事件也是一次提醒：允许员工在共享托管 LLM 上做实验而不记录提示长度，本身已是基线卫生的缺口。