读懂｜Cloudflare 串出别人数据，该算 GLM 的账吗？

Cloudflare 披露托管的 GLM-5.3 有 155 条回答混进其他客户的数据。责任在它自己的配置和开源推理引擎，修复 47 天后才公开，报告没写是否通知受影响客户。

托管开源模型时，数据会不会串到别人那里，取决于托管方怎么部署，而不是模型本身。

不该算 GLM 的账。Cloudflare 10 月 26 日发布的事故报告写明，它托管的 GLM-5.3 在 8 月 27 日到 9 月 9 日之间，有 155 条回答混进了其他客户此前请求里的内容。

原因有两个：一是 Cloudflare 自己的配置，二是开源推理引擎 SGLang 的缺陷。两样都与智谱（Z.ai）发布的模型权重无关。

更值得追问的是另外两件事：同一个缺陷七月就有人公开报过，修复之后又过了 47 天才对外公开。

上线第一天起，超长提问就会读到旧缓存

据 Cloudflare 的事故报告，GLM-5.3 在 Workers AI 上对外标的上下文长度是 1,048,576 个词元。但负责处理提问的那组 GPU，缓存池只装得下 681,280 个。

Cloudflare 承认上线前就知道这个差距。它原以为引擎会对装不下的提问直接报错，测试时又只看了返回码和速度，没有核对回答内容。

实际发生的是另一回事。SGLang 把装不下的提问标记为拒绝，换成只有一个词元的空请求，却没有终止它。生成回答的那组 GPU 以为缓存已经写好，读到的却是上一个请求留下的页面。客户收到的仍是正常的成功响应，回答通顺，里面夹着别人的提问和部分生成内容。

报告给出的时间线如下，时间为协调世界时：

Cloudflare 称排除自己和研究员的测试后，相关请求的时间与数量符合正常的长文本使用，没有发现蓄意利用。这是它的自查结论，目前没有第三方核对。

这个缺陷并不新。报告提到，另一名用户 7 月 6 日已在 SGLang 的代码仓库报过同类问题。

打开那条 SGLang issue #30233 可以看到，报告人用的正是 GLM-5.2，上下文同样标为 1,048,576，缓存池只有 28 万多。他写的现象是解码端「产生垃圾输出」，并附上了补丁。这条报告 9 月 5 日被自动化机器人以已完成关闭，只有一条评论。

同一个缺陷，在一家单独部署的用户那里表现为乱码，在多客户共用的托管平台上就成了数据外泄。把它当成输出质量问题处理，是这条报告在两个月里没有升级的原因之一，这是分析推断，依据是报告的措辞与关闭方式。

报告还写到一处细节：Cloudflare 夏天做过一个在读取缓存前核对页面归属的原型，8 月中旬在 GLM-5.2 上测试后，因可靠性问题停用。报告没有说明，这个原型如果开着，能否拦下这次泄露。

9 月 9 日修好，10 月 26 日公开，中间隔了 47 天。报告的时间线列出了这段时间做的事：和 SGLang 维护方开会，把修复合进上游，等新版本发布，再协调公开。

这个顺序对其他运营方有用，用同一引擎的平台可以在公开前先升级，这是分析推断，依据是修复版本 10 月 19 日发布、公开在 10 月 26 日。但对 155 条回答背后的两类客户，报告都没有交代。一类是数据被读走的客户，另一类是收到别人数据的客户。

我们在报告全文里检索过，没有找到是否逐一通知受影响客户、何时通知的说明。这不等于 Cloudflare 没有通知，只是它没有公开写。混进回答的具体是哪类数据，报告也只说是其他客户的提问和部分生成内容。

The Inference 注意到，事故公开后，有评论把问题归到 Z.ai 头上。它的结论是责任在 Cloudflare：模型权重是开源发布的，下载权重、在自己的 GPU 上运行模型的都是 Cloudflare。

我同意这个结论，并且认为它说明了一件更具体的事：托管开源模型时，数据隔离是托管方的责任，模型厂商管不到。企业采购这类服务时，要问的是托管方，问题也很具体：缓存池是否覆盖标称的上下文长度，引擎版本是否包含这次的修复，出了事多久通知自己。

有人会说，155 条回答、只限超过 68 万词元的超长提问、没有发现恶意利用，影响很小，追问披露时间有些小题大做。规模小这一点我接受。但收到别人数据的客户拿到的是正常响应，自己无从察觉；数据被读走的客户，如果没有收到通知，也无从知道。

报告还建议所有用同类分离部署的运营方核对缓存池大小、升级引擎。其他托管平台在同一时期有没有过相同暴露，目前没有公开信息。

小事故的价值在于它暴露了规则空白：什么时候公开、通知谁，目前都由托管方自己决定。如果之后有托管平台把客户通知的时限写进服务条款，这个判断就需要改。