GLM-5.3 Workers AI 模型中的跨请求 KV 缓存泄露及我们与 SGLang 的修复措施
内容提要
2026年8月27日至9月9日，Cloudflare的Workers AI平台GLM-5.3模型发生跨租户KV缓存泄露，原因有二：预填充GPU的KV缓存池仅681,280 token，小于1,048,576 token的上下文窗口；SGLang在分离式推理模式下未正确拒绝超长请求，导致解码节点读取到其他用户的残留数据。共155条超长提示响应受影响，无恶意利用证据。Cloudflare当日下线模型，扩大缓存池并修补引擎，9月9日恢复服务，并与SGLang上游协作发布修复版本。
延伸解读
配置与引擎缺陷叠加才触发泄露
这次事件并非单一漏洞，而是两个问题同时存在：预填充GPU的KV缓存池只有681,280 token，小于1,048,576 token的上下文窗口；同时SGLang在分离式推理模式下，对超长请求的拒绝路径处理不当，解码节点误以为缓存已被完整覆盖，实际读取了残留页面。只要任一环节正常，泄露就不会发生。这也说明，部署大模型时不能只依赖引擎自动报错，配置层面的容量匹配同样关键。
测试盲区：只看状态码不看输出
Cloudflare在事故复盘里承认，上线前的长上下文测试只验证了HTTP状态码和流式响应无错误帧，没有检查模型输出是否连贯、是否来自当前请求。超长请求返回200且内容看似正常，掩盖了底层缓存未正确覆盖的问题。对推理服务而言，响应码正常不等于结果可信，尤其涉及多租户隔离时，应增加输出一致性或标记校验，而不是把状态码当作安全信号。
修复分两层：配置兜底与引擎补丁
Cloudflare先扩大预填充缓存池到约204万token，约为上下文窗口的两倍，使合法请求不再进入拒绝路径；同时修补引擎，让被拒绝的请求在分离式准入队列就被终止，不再发生KV传输。前者能立即阻断本次问题，但依赖具体配置，量化、并行度或模型版本变化都可能让池大小再次失配。因此引擎侧修复才是长期兜底，相关补丁已进入SGLang v0.5.22。
对其他运营者的可操作提醒
文章给出的建议很具体：每次变更权重、量化、并行度或显存比例后，都要从引擎启动日志核对KV池大小与上下文长度；升级到包含#36988和#38935的版本；在预填充和解码两侧启用延迟释放，并限制Mooncake传输批次；在模型支持时开启KV校验和与canary检测。这些措施不能保证绝对安全，但能减少同类缓存生命周期错误被触发的机会。
Q&A
GLM-5.3 在 Workers AI 上发生的跨请求 KV 缓存泄露具体影响了多少请求？
共 155 条响应受影响，全部来自长度超过 681,280 token 的提示。没有发现恶意利用的证据。
为什么 GLM-5.3 的 KV 缓存池会小于上下文窗口？
Cloudflare 部署 GLM-5.3 时配置了 1,048,576 token 的上下文窗口，但预填充 GPU 上的 KV 缓存池只能容纳 681,280 token。SGLang 在启动时根据加载模型权重后剩余的 GPU 内存自动确定池大小，而上下文长度是单独的配置值，两者没有强制一致，Cloudflare 在启动前已知这一不匹配但未将其视为问题。
SGLang 在分离式推理模式下是如何导致解码节点读取到其他用户数据的？
当提示超过 KV 池容量时，SGLang 调度器会拒绝该请求，但拒绝路径将提示替换为一个 token 的占位符，并标记为“待完成”而非“已拒绝”。在分离式模式下，预填充和解码的准入队列只检查请求是否 finished()，而拒绝请求仍返回 False，因此被准入。预填充对占位符执行前向计算并传输一页 KV 到解码节点，解码节点收到“传输完成”信号后，误以为预填充已用完整提示覆盖了之前请求的 KV 缓存，实际大部分旧页面未被覆盖，解码时注意力机制读取了残留的其他用户数据。
Cloudflare 在发现漏洞后采取了哪些紧急修复措施？
Cloudflare 在 40 分钟内下线模型，并采取了两项修复：一是调整 GLM-5.3 配置，使预填充 KV 池扩大到约 204 万 token，约为上下文长度的两倍，确保有效请求不会触发拒绝路径；二是修补 SGLang 引擎，使携带待处理拒绝的请求在分离式准入队列处被提前终止并返回原始错误，阻止任何引导、分配或 KV 传输发生。两项修改均通过研究者的复现脚本和自建金丝雀标记测试验证后，于 9 月 9 日恢复服务。
其他使用 SGLang 分离式推理的运营者应该采取哪些防护措施？
建议：1）在每次更改权重、量化、并行度或内存比例后，从引擎启动日志中测量 KV 池大小并与上下文长度比较，若池较小则降低上下文长度；2）升级到包含 #36988 和 #38935 的版本（v0.5.22 或更高），确保超长请求在交接前被拒绝；3）在预填充和解码两端启用延迟 KV 释放，并限制 Mooncake 传输批次大小；4）在模型支持时开启 --disaggregation-enable-kv-checksum 和 --kv-canary 进行损坏检测；5）配置负载均衡器允许请求进行到第一个 token，避免不必要的跨节点中止。
Cloudflare 与 SGLang 上游合作发布了哪些修复版本？
Cloudflare 与 SGLang 维护团队（RadixArk）合作，将修复合并到上游。关键补丁包括：#36988（v0.5.20）在预填充结果到达解码前终止被中止的请求；#38935（v0.5.21）在准入阶段拒绝此类请求；以及多个针对竞态条件和生命周期问题的补丁。SGLang v0.5.21 于 2026 年 10 月 2 日发布，v0.5.22 于 10 月 19 日发布，建议所有运营者升级到 v0.5.22 或更高版本。
Cloudflare 在长期防止此类 KV 缓存泄露方面有哪些计划？
Cloudflare 计划从两方面入手：一是“构造性完整性”，即为每个物理 KV 页附加标签，在解码读取前检查请求是否拥有该页，原型测试吞吐和尾延迟损失低于 1%，正与 SGLang 团队合作将其产品化；二是“数学不可能性完整性”，即使用形式化验证方法对基于 RDMA 的 KV 缓存传输协议进行建模和安全性证明，目标是从根本上证明此类 bug 不会再次发生。
