Kevin Flansburg、Michelle Chen · Cloudflare · 阅读原文
原始来源：Kevin Flansburg、Michelle Chen · Cloudflare
发现渠道：Hacker News · LLM
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 的协作说明给出这一竞态的受控复现和修复测试，但它与本次超长请求的确定性触发路径不同，不能混写为同一个原因。
可信度 65 · 重要性 86 · 新颖度 75
技术与主题
系统与效率 · KV Cache · Prefill Decode · Request Isolation
kami23
Cloudflare复盘的HN评论；评价响应过程，没有独立复测。
忠实转述（非原句）：他赞赏团队明确承担责任并解释测试为什么漏掉问题，也重视平台能迅速停掉模型服务的能力。这个评价关心事故处置和可理解性，不能充当修复已经覆盖所有故障的证明。
编辑评读
这次事故把容量配置、请求状态和数据所有权连在了一起。错误并不只在“窗口开得太大”：即使配置失误，服务也应拒绝请求，而不是用未初始化为本请求内容的页面继续生成。对运营者而言，HTTP成功和延迟正常都不足以证明答案来自正确输入；需要在模型、量化或并行配置变化后核对实际缓存容量，并覆盖拒绝、中止与复用这些边界路径。
更可迁移的做法，是在资源交接处检查接收者真正需要的事实。等待所有写入结束再回收，解决迟到写入；读取时核验页面代际标签，解决页面是否仍归当前请求。两者不能互相替代，单纯等待超时也不证明写入已停。Cloudflare 报告的低于1%开销标签方案仍是原型，曾因可靠性问题停用；跨架构生产支持及形式验证属于后续工作。本文未复现故障，也不把其他用户的异常答案推断成同一漏洞。
需要留意
- 155次响应为运营方排查结果；超长拒绝路径与中止后的异步写入竞态分开，原型性能非通用生产保证。