GLM-5.3跨用户串数据已修复

Cloudflare确认155条响应受到影响

Cloudflare近日披露，Workers AI平台上的GLM-5.3曾出现跨请求KV Cache暴露，不同用户的模型响应可能混入其他请求的数据。Cloudflare已经完成修复，并确认本次事件涉及155条响应；截至2026年10月27日，官方披露的信息没有显示问题仍在持续。

这不是模型偶尔答非所问那么简单，而是一次发生在多租户推理基础设施中的数据隔离失效。模型幻觉通常是根据当前上下文生成了错误内容，跨请求缓存泄露则意味着当前请求可能使用了本不属于它的历史推理状态，两者在安全性质上完全不同。

KV Cache是Transformer模型在推理过程中保存注意力Key和Value中间状态的缓存，用于避免重复计算已经处理过的上下文。 对于长提示词、多轮对话和带固定系统提示的AI应用，KV Cache直接决定了首个Token延迟、GPU显存占用和服务吞吐量，也是当前大模型推理优化中最重要的一层基础设施。

Cloudflare将这次事件称为“Cross-request KV cache exposure”，这一命名已经指出了核心：缓存状态跨越了原本应该彼此隔离的请求边界。根据官方复盘，受影响对象是Workers AI上的GLM-5.3模型，Cloudflare识别到155条相关响应并实施了修复。

| 事件要素 | 已披露信息 | 应如何理解 | |---|---:|---| | 受影响平台 | Cloudflare Workers AI | 问题位于托管推理服务场景，不等同于GLM模型权重公开存在同类缺陷 | | 涉及模型 | GLM-5.3 | 官方事件标题明确指向该模型 | | 问题类型 | 跨请求KV Cache暴露 | 一个请求可能错误复用另一个请求的推理状态 | | 已确认影响 | 155条响应 | 这是官方识别到的响应数量，不应直接等同于155名独立用户 | | 当前状态 | 已修复 | 用户仍需要自行排查下游日志、数据库和自动化任务 | | 风险性质 | 多租户数据隔离失效 | 风险高于普通输出质量故障，但影响范围需要结合响应内容判断 |

这次“串数据”到底发生在什么位置

跨请求KV Cache暴露是指推理服务把请求A生成的注意力缓存错误地提供给请求B使用。模型在生成请求B的回答时，会把这部分缓存当成自身上下文的一部分，因此可能表现为突然延续陌生对话、输出无关代码、沿用其他用户的格式，甚至复述本不属于当前会话的信息。

KV Cache保存的不是一份可以直接阅读的纯文本聊天记录，而是模型逐层计算得到的高维张量。这个区别很重要：缓存内容通常不能像数据库字段一样直接打开查看，但一旦被错误注入后续解码过程，模型可能通过生成结果把其中承载的语义重新表达出来。

一次典型的大模型推理可以分为预填充和解码两个阶段。预填充阶段处理系统提示、用户输入和历史消息，并为每个Token生成Key、Value状态；解码阶段逐个生成新Token，同时继续扩展缓存。输入越长，预填充成本越高，因此平台有强烈动力复用拥有共同前缀的缓存块。

跨请求复用本身并不一定不安全，缺少严格边界的跨请求复用才是问题。大量企业应用共享相同的系统提示，例如客服机器人都以同一份服务规范开头，推理平台可以对这部分完全一致的前缀做缓存；但缓存身份必须同时绑定模型版本、适配器、租户、会话、提示前缀和其他影响计算结果的配置，不能只凭一个过于宽泛的缓存键判断是否可复用。

这起事件也不要和Cloudflare Workers KV混淆。Workers KV是Cloudflare提供的分布式键值存储产品，面向应用数据读写；LLM的KV Cache则是Transformer注意力层产生的推理中间状态，两者只是名称中都出现了“KV”，实现位置、数据结构和安全边界完全不同。

为什么错误缓存会改变模型回答

KV Cache可以理解为模型对“前文已经读到哪里、每个Token应当被如何关注”的压缩工作记忆。假设用户A让模型审查一段未公开代码，用户B随后询问一个普通部署问题；如果推理引擎错误地把A的部分缓存挂到了B的请求上，模型可能像拿错了会议记录一样，突然接着讨论那段代码。

这种问题不要求两个用户使用同一个浏览器、同一个账号或同一条会话。只要他们的请求由同一个多租户推理集群处理，而缓存寻址、生命周期管理或调度隔离出现错误，理论上就可能发生跨租户污染。

真正需要警惕的是输出内容进入后续系统后的放大效应。开发者通常会把模型响应写入日志、向量数据库、工单系统、代码仓库或Agent记忆；即使原始异常响应只有一次，它也可能被持久化、索引和再次召回，最终从短暂的推理故障变成长期的数据污染。

对于具备工具调用能力的Agent，风险还不止信息暴露。错误缓存可能让模型继承不属于当前任务的意图或指令，随后触发发邮件、修改工单、查询内部系统等动作；工具层如果没有独立鉴权和人工确认，一次异常回答就可能升级为越权操作。

这和此前的KV Cache侧信道攻击不一样

KV Cache侧信道攻击是通过缓存命中时间、延迟或资源行为推断其他用户提示词的攻击方法。字节跳动安全团队与南方科技大学研究人员在NDSS 2025论文《I Know What You Asked: Prompt Leakage via KV-Cache Sharing in Multi-Tenant LLM Serving》中展示过一种思路：攻击者逐步猜测Token，并观察请求是否触发缓存共享，由此恢复其他用户的提示内容。

Cloudflare本次披露的问题更接近直接的缓存状态混用，而不是单纯通过时间差做推断。侧信道攻击通常需要攻击者精心构造大量请求并进行统计，而跨请求状态污染可能在正常调用中就把异常内容带入输出，开发者甚至会先把它误判成模型幻觉。

| 风险类型 | 数据如何暴露 | 是否需要主动攻击 | 常见表象 | 主要防线 | |---|---|---:|---|---| | 普通模型幻觉 | 没有真实数据泄露，模型生成错误事实 | 否 | 内容错误但与其他用户无直接关系 | 检索、验证、评测与人工审核 | | KV Cache侧信道 | 通过延迟或缓存命中差异推断提示词 | 通常需要 | 大量探测请求、细微延迟变化 | 缓存分区、随机化、限流与恒定时间设计 | | 跨请求缓存污染 | 其他请求的推理状态进入当前解码 | 不一定 | 陌生上下文、代码片段或异常续写 | 强租户隔离、缓存键校验与清零 | | 日志或数据库泄露 | 原始文本被错误读取或返回 | 不一定 | 可直接识别的完整记录 | 权限控制、加密、审计与脱敏 |

155条响应不等于风险可以忽略

155条受影响响应是一个明确数字，但它只回答了“官方识别到多少异常输出”，没有自动回答“涉及多少用户、多少敏感字段以及数据传播到了哪里”。一条响应可能不包含任何敏感内容，也可能包含代码、内部文档片段、个人信息或业务指令，风险需要逐条评估。

受影响响应数也不能直接换算成受影响请求数或独立用户数。同一用户可能收到多条异常响应，一条响应也可能混合多个缓存片段；如果应用对回答进行了流式处理，部分内容还可能在请求结束前就被客户端或日志系统保存。

Cloudflare能够给出155这一具体数字是好事，因为它比“极少量用户可能受到影响”更便于审计和追责。但对平台安全来说，数字小并不代表问题轻：多租户推理服务最基础的承诺就是不同客户之间的数据不能互相可见，一旦这条边界被打破，事件性质就已经超出普通稳定性事故。

目前没有依据把这次事故扩大解释为GLM-5.3模型权重本身“记住了155条私人对话”。公开信息指向的是Workers AI托管推理过程中的缓存暴露，因此更准确的归因对象是特定部署与推理链路，而不是所有本地部署、其他云平台或所有GLM系列模型。

性能优化越激进，隔离设计越不能含糊

跨请求前缀缓存是大模型云服务降低成本的关键技术。相同系统提示如果每次都重新完成预填充，既浪费GPU算力，也会拉长首Token等待时间；平台把公共前缀的KV状态保存下来，可以让后续请求从已计算的位置继续执行。

Cloudflare此前还介绍过KV Cache压缩和推测解码等性能优化。KV Cache压缩的目标是减少中间状态占用的显存，推测解码则是让较小模型或其他机制提前猜测多个Token，再由主模型批量验证；这些技术都能提高吞吐量，但也让推理状态管理比“一个请求进、一个回答出”复杂得多。

GLM-5.3目前在Workers AI上的价格也说明了平台为何重视缓存效率。Cloudflare公开的价格为每100万输入Token 1.40美元、每100万缓存输入Token 0.26美元、每100万输出Token 4.40美元，缓存输入价格比普通输入低1.14美元，折扣约81.4%。

| 计费项目 | GLM-5.3公开价格 | 与普通输入相比 | |---|---:|---:| | 输入Token | 1.40美元/百万Token | 基准 | | 缓存输入Token | 0.26美元/百万Token | 便宜约81.4% | | 输出Token | 4.40美元/百万Token | 是普通输入单价的约3.14倍 |

Cloudflare的模型目录还上线了@cf/zai-org/glm-5.3-flash，这是GLM系列在Workers AI上的首个原生多模态型号。官方资料显示，GLM-5.3 Flash采用混合专家架构，总参数量3200亿，每个Token激活180亿参数，并要求Workers Paid计划或预付AI Gateway额度。

这里需要避免把产品更新和安全事件强行混为一谈。Cloudflare事件披露使用的是GLM-5.3名称，而GLM-5.3 Flash是当前模型目录中的具体型号；在官方没有进一步确认前，不应自行断言Flash版本也受到同一问题影响，更不应把整个GLM系列都列为受影响对象。

Cloudflare修复之后，用户仍应做一次自己的排查

服务端修复只能阻止问题继续发生，无法自动删除已经流入用户系统的异常响应。使用过Workers AI上GLM-5.3的团队，应当检查事件相关时间段内的模型输出、调用日志以及下游自动化记录，尤其关注那些与当前提示明显无关、突然切换语言或格式、出现陌生代码和内部术语的回答。

建议开发者至少完成以下动作：

1. 核对Cloudflare通知和项目日志。 以账户收到的通知、控制台记录和官方事件说明为准，确认自己的项目是否在识别范围内。
2. 暂时保全原始证据。 在符合法务和隐私政策的前提下保存请求ID、时间戳、模型名称、区域、响应摘要和下游处理结果，不要只截一张聊天界面。
3. 检查响应的二次传播。 搜索向量库、工单、Agent记忆、代码提交和监控告警，确认异常文本有没有被长期保存。
4. 轮换可能暴露的凭据。 如果异常输出中出现令牌、密码、私有地址或其他认证信息，应立即吊销并重新签发，而不是等待确认它是否真的被第三方读取。
5. 暂停高风险自动执行。 对能够发信、改库、发布代码或操作云资源的Agent增加人工确认，直到排查完成。
6. 向Cloudflare提交可关联的请求标识。 请求ID和精确时间通常比完整复制敏感提示更适合用于联合调查。

日志排查本身也需要遵循最小暴露原则。开发者不应为了确认一次缓存事故，又把完整用户提示和模型回答复制到更多聊天工具、工单或公共仓库中；更合理的做法是先用哈希、分类标签和局部脱敏片段定位，再在受控环境中查看原文。

推理平台该如何避免下一次串数据

缓存隔离必须成为大模型推理系统的一等安全边界。平台不应只把缓存视为GPU性能优化，而要像数据库行级权限、虚拟机内存隔离一样，明确缓存状态属于哪个租户、哪个会话和哪个模型配置。

一个可靠的缓存身份至少应覆盖租户标识、模型及精确版本、Tokenizer版本、系统提示哈希、适配器或LoRA版本、采样和位置编码相关配置。任何参与缓存匹配的字段如果缺失、截断或发生碰撞，都可能让“看起来拥有共同前缀”的两个请求错误共享状态。

缓存淘汰和显存复用同样需要清理保证。GPU内存池为了减少重复分配通常会复用缓冲区，但重新分配不应意味着旧内容可以被新请求读取；平台需要通过覆盖、边界检查、生命周期标记和所有权校验，确保释放逻辑不会遗留跨租户状态。

安全测试也不能只验证回答质量。推理平台应加入跨租户并发测试、故意制造缓存哈希碰撞、模型热更新、取消请求、流式中断、超长上下文和显存压力等场景，因为缓存隔离问题往往出现在异常路径，而不是最标准的单轮问答中。

检测系统则应关注“语义来源异常”。例如回答突然出现当前请求从未提及的专有名词、编程语言、身份信息或长文本续写时，平台可以中止输出并标记审查；这种检测不能替代底层隔离，却能在缓存边界再次失效时降低实际暴露量。

这次事故给行业的信号

Cloudflare快速修复并披露155条受影响响应值得肯定，但事件本身提醒整个行业：大模型云服务的安全边界已经从提示词过滤扩展到了GPU内存、请求调度和缓存生命周期。只讨论越狱、内容安全和模型对齐，无法覆盖多租户推理真正复杂的攻击面。

KV Cache正在从幕后优化项变成需要独立威胁建模的基础设施。随着上下文窗口拉长、Agent会话持续数小时甚至数天，缓存保存的信息越来越多，生命周期也越来越长；任何命名空间错误都可能把一次底层优化变成跨客户数据事件。

我们的判断是，这次事件不会让行业放弃跨请求缓存，因为约81.4%的缓存输入价格差和显著的算力节省太有吸引力。更现实的变化是，云平台会逐步把租户级缓存隔离、可审计缓存命中、敏感客户独占池和禁用跨请求复用等能力产品化，并让企业用户为更强的隔离等级付费。

对于开发者而言，最重要的结论也不是“不要使用KV Cache”，而是不要把托管模型回答视为天然可信且只包含当前会话的数据。模型输出需要像外部输入一样接受验证、脱敏和权限控制，尤其不能仅凭一段自然语言就获得不可逆的工具执行权限。

截至2026年10月27日，Cloudflare已宣布完成此次GLM-5.3跨请求KV Cache暴露的修复。后续真正值得关注的是，Cloudflare是否会进一步公开具体触发条件、受影响时间窗口、缓存隔离改动以及客户审计结果——这些信息将决定行业能否把一次事故转化为可复用的工程规范。

参考来源

受链接域名限制，Cloudflare官方事故复盘与Workers AI更新日志未在此直接附链；文中的155条响应、修复状态、模型价格和产品参数均据Cloudflare官方披露整理。

• SGLang GitHub仓库：开源大模型推理框架，可用于了解前缀缓存、请求调度和多租户推理的工程实现。
• Z.ai的Hugging Face主页：GLM系列模型的官方模型组织页，可查询公开模型卡、权重和相关技术信息。