AI缓存的性能收益，应在隔离边界内计算

Cloudflare于2026年10月26日披露，其GLM-5.3部署在8月27日至9月9日期间出现跨请求数据暴露；公司称其他Workers AI模型未受影响。公司报告。

这是一宗具体事件，并不证明所有共享推理服务都会泄露信息。不过，它提出了一个更广泛的采购问题：供应商报告推理变快时，测试保留了哪些边界？只有服务仍在完成客户授权的工作，速度才有实际价值。

客户之间的隔离，也是工作负载的一部分

设想一个假设性的文档助手，由两家公司分别使用。双方都让它总结合同，也都采用同一套公开指令，但私有文件并不相同。如果性能测试把这些任务合并成一个方便调度的资源池，结果可能很漂亮，却没有代表客户真正需要的保密条件。

我们的分析建议是，把允许共享的群体写入工作负载定义。一次测试中的任务，究竟属于同一个人、一个团队、一家机构，还是彼此无关的机构？这些描述不能互换。即使在同一家公司，法务调查与普通客服对话也可能需要不同的访问边界。

这会改变采购方阅读性能比较的方式。假如一组测试允许广泛复用，另一组把各部门分开，前者的延迟更低，并不能单独证明实现更优秀。两者可能在提供不同的服务。应先对齐允许共享的范围，再比较这个范围以内的表现。

这里并不是说共享本身有错。所有参与者都有权看见的公开指令，允许复用可以是合理的设计选择。问题在于，方便的技术分组容易变成未经审视的授权决定。使用相同模型、挂在同一个计费账户下，或者提问措辞相近，都不能独自回答哪些任务应该共享派生状态。

对客户来说，购买的也不只是一次回答。客户通常希望同一套边界在繁忙时、任务结束时和使用方式改变时仍然成立。因此，隔离条件不应作为性能报告角落里的附注；它应与任务类型、输入规模和验收方式一起，成为解释结果的前提。

生成成功，不是验收的全部

SGLang的10月26日披露描述了被拒绝的请求继续进入分离式处理交接、读取未为该请求填充的缓存页，并另行讨论生命周期防护。维护者报告。

这一区分对我们的分析很重要：有意的计算复用，与意外接触另一请求的状态，是两类问题。管理前者的规则，不能被默认视为能够阻止后者。采购方既需要知道系统允许什么安排，也需要看到任务未正常推进时，实现是否仍然守住这种安排。

可以设想一次受控的验收演练：使用虚构文档，而不是真实客户资料。一组测试材料带有独特的项目标记，另一组没有权限读取它。评估者检查回答是否带入了错误群体的信息，同时检查合法摘要是否仍然有用。这是对授权测试的设计建议，不是在估计任何生产服务的故障发生率。

演练还应覆盖被拒绝、中途停止和重试的任务，因为这些都属于客户实际经历的服务。只包含顺利完成、格式正确的任务，会在测试结论与运营问题之间留下空隙。但通过这些测试也不能证明所有泄露可能性都已排除；它只能为特定配置、场景与观察时段提供证据。

因此，一份有用的报告应区分三种结果：获得授权且有用的回答、明确拒绝或失败，以及在现有权限下根本不应产生的回答。把所有返回内容平均成一个成功率，会掩盖最重要的差别。一个清楚说明失败的服务，有时比流畅却来源错误的回答更符合客户利益。

这种区分还会影响优化团队的激励。如果唯一目标是减少报错，团队可能倾向于让更多任务返回内容；如果目标是交付得到授权的有效结果，明确终止某些任务就可能是正确行为。这里讨论的是应如何设定验收目标，并非认定任何供应商存在这种激励失当。

先固定边界，再比较效率

作为另一种设计例子，vLLM文档介绍了可选的请求盐值，用于把前缀缓存复用限制在盐值匹配的请求之间；它不是所有缓存生命周期缺陷的通用修复。vLLM文档。

采购上的启示不是强制采用某一种实现，而是要求共享规则能够被采购方说清楚，也能由运营方检验。应用负责人可能允许同一项目内复用，同时把无关客户分开；另一位负责人可能愿意接受稍慢的服务，以减少共享的请求派生状态。只看每秒令牌数，无法评价这两种选择。

合理的反对意见是：隔离范围越窄，共同平台的经济收益可能越小，复杂测试也会延迟采用。这种取舍应当明确呈现，而不是隐藏起来。正确的比较对象，是满足同一隔离要求的不同方案，以及它们各自的延迟、容量和运营负担；不是把隔离服务与不受同样限制的测试当成等价产品。

当团队后来修改访问模型时，同一原则仍然适用。合并两个工作区，可能创造新的共享机会；移除一个参与者，可能缩小共享范围。在我们提出的治理方式中，这些变化应触发对性能假设的复核，而不只是修改用户目录。快速配置的价值，取决于它的权限是否仍然适合当前工作。

这些披露没有证明哪一种架构适合所有客户。它们促使评估者提出一个更准确的问题：在所需的隔离条件已经明确、并经过检验之后，还剩下多少有用的吞吐能力？与脱离信任边界的速度数字相比，这才是选择推理服务更有意义的依据。