当模型推理被做成按请求计费的多租户服务，缓存复用带来的性能收益与请求隔离之间的张力，就会以最直接的方式暴露出来。

发生了什么

Hacker News 上出现一条讨论，标题为「Cross-request KV cache exposure in the GLM-5.3 Workers AI model」，指向 GLM-5.3 在 Workers AI 平台上出现的跨请求 KV 缓存暴露问题，讨论帖获得约 155 条回复、12 个点赞。从标题表述看，问题核心在于不同请求之间的 KV 缓存没有被正确隔离，导致一个请求的缓存状态可能被另一个请求触及。目前公开信息仅限于这条讨论本身，具体的触发条件、影响范围和修复状态尚不明确，讨论热度远高于点赞数，说明话题本身比帖子传播度更受关注。

为什么重要

KV 缓存是大模型推理里最关键的优化手段之一：把已计算的注意力键值对留存下来，避免重复计算，直接决定首 token 延迟和单位算力成本。在多租户推理平台上，缓存复用几乎是必选项——同一系统提示词、同一前缀的请求共享缓存，是压低成本的标准做法。

问题在于，缓存一旦跨请求共享，隔离边界就从「进程」退化为「缓存键的设计」。如果缓存键没有把租户、会话或请求上下文完整纳入，共享就从性能优化变成信息泄露通道。对推理平台而言，这类问题的严重性不在于算力损失，而在于它触及了多租户服务最基本的信任前提：我的输入不会出现在别人的输出里。

Workers AI 的定位是边缘侧托管推理，强调低门槛和就近响应，这类平台往往把易用性放在隔离粒度之前。GLM-5.3 作为国产模型在海外边缘平台上提供服务，也让这个问题具备了额外的观察价值：模型能力出海的同时，服务侧的工程约束是否同步跟上。

影响与看点

对开发者而言，最直接的影响是重新评估在托管推理平台上处理敏感输入的边界——系统提示词、用户上下文、检索到的私有文档，都属于不应跨请求可见的内容。对平台方，这是一次关于缓存键设计与租户隔离的提醒：性能优化不能以模糊隔离语义为代价。

值得关注的几个点：官方是否给出问题确认与修复说明；影响是限于特定调用模式还是更普遍；以及是否会推动托管推理服务在文档层面明确缓存复用策略。

一个独立判断：这类问题的价值不在于单次事故，而在于它把「推理服务的隔离语义」从工程细节推到了产品契约层面——当缓存成为默认优化，隔离就必须成为默认承诺。