不同客户的对话串到了一起:推理上规模之前,老板要先定好这道门槛

发生了什么：155 条回复，串了别人的对话

Cloudflare 和模型厂商在 10 月 26 日公开披露了这件事：平台上一个模型的 155 条回复里出现了其他用户请求的内容。全部受影响的请求都有一个共同点：对话特别长。排查后确认，没有发现有人刻意利用这个缺陷，但内容确实串了。

时间线很短：9 月 8 日研究员报告问题，9 月 9 日 Cloudflare 在 25 分钟内复现，随即把模型下线，10 月 19 日厂商发布修复，10 月 26 日双方公开披露。

两个疏忽怎么叠加成一次事故

第一个疏忽是容量没算对。模型对外宣称能处理约 104 万 token 的对话，但实际负责处理的那部分系统只能装约 68 万 token。Cloudflare 事前知道这个差距，但预期系统会在处理不了时报错，而测试也都返回了成功，于是没把差距当回事。

第二个疏忽更危险：超长对话装不下时，系统内部把它标记为拒绝，却换成一个占位符继续往下走，还向下一环节发了"已完成"的信号。下一环节以为已经用本次对话覆盖了缓存，实际上里面还留着上一个用户的内容。于是用户拿到的是"成功"，回复里却带着别人的对话片段。

单独看，容量错配只是配置错误，边界处理问题也只是个缺陷。两个叠在一起，配置错误触发了缺陷路径，缺陷路径又把错误藏成了成功响应。

为什么"显示成功"是最危险的部分

很多团队的测试只验"成功了没有、速度正常不正常"。Cloudflare 在复盘里承认，自己的测试正是这么做的：验了状态码和性能，没验输出内容。泄漏的回复恰恰"看起来正常"：字数对得上、回复通顺、速度甚至更快，因为它根本没做完整的处理。

这个细节对所有要上规模的企业都适用：测试不能只看成功失败，还要看内容对不对。拿一段带唯一标记的长对话跑，输出里出现不属于本次对话的标记就判定失败。没有这层校验，隔离失效在监控里就是隐形的。

转型落点

从试点到推广，推理服务的隔离变成一道上线门槛，老板要定的就四件事：容量对没对齐，谁签字放行；超长请求在入口就直接挡回去，不要进系统内部；测试要验内容，不只验成功；一次上一个业务线，每扩一条线就重对一遍容量表。否则一次串对话，漏的不只是技术细节，是别的部门的数据。