持续追踪

Cloudflare 的155次串读:被拒绝的请求为什么仍然生成了答案

按时间保留当时的判断和后续核查;历史收录不代表刚刚重新验证。

2026-10-27 · 当时的记录

Cloudflare 披露,Workers AI 的 GLM-5.3 服务在8月27日至9月9日间,有155次响应可能包含其他请求的内容。团队9月8日收到报告,9日完成补救,10月26日公开复盘。已识别的受影响请求都超过681,280个 token;这不是模型凭空编造了私人信息,而是推理服务读到了不属于当前请求的缓存。

服务把处理输入的 prefill 与逐步生成答案的 decode 分到不同节点。KV cache 保存模型对先前 token 算出的键和值,解码节点要接收这些数据才能继续生成。配置允许约104万 token,但输入节点的缓存池只能容纳约68万;团队知道容量不一致,却以为超长请求会正常报错,测试也主要检查响应状态和吞吐。

问题出在拒绝状态没有被后续流程正确识别:超长输入被替成一个 token 的占位内容,解码端却仍按原长度预留页面。只传过来的一页覆写了部分空间,其余页面留着旧请求数据;随后生成仍返回 HTTP 200。修复一方面扩大实际缓存池,另一方面让超长请求在跨节点交接之前就退出。

复盘还区分了另一类风险:请求中止后,已经发出的异步远程写入仍可能继续;过早回收页面,会让迟到的数据污染新请求。SGLang 的协作说明给出这一竞态的受控复现和修复测试,但它与本次超长请求的确定性触发路径不同,不能混写为同一个原因。

本次记录的观点:kami23

回到当期正文 ↗

查看依据原文 · 原始依据