你团队的基准测试正在互相欺骗：共享评估基础设施的污染问题

你的红队刚完成了一次越狱扫描。他们发现了三个新型攻击向量，将其整理成文档，并把这些提示词放入共享提示词库，供其他人学习。一周后，安全团队运行基线评估，报告鲁棒性提升了 12%。所有人都在庆祝，却没人问为什么。

实际发生的是：安全团队的基线评估悄悄纳入了红队的攻击提示词。模型并没有变得更健壮——是评估被污染了。你的基准测试现在衡量的是对已知攻击的免疫力，而非对新攻击的泛化能力。

这就是共享评估基础设施污染问题，它比大多数团队意识到的要普遍得多。症状是指标被人为拉高，根本原因是把评估基础设施当生产基础设施来对待——优化了共享和效率，而非隔离性和保真度。

共享评估基础设施毒害结果的三种方式

渠道一：缓存补全泄漏

现代 LLM 推理系统会缓存常见前缀的键值（KV）状态以降低推理延迟。这在生产环境中是正确行为。在共享评估基础设施中，却成了隐患。

当 A 团队运行评估时，他们的提示词会被缓存。当 B 团队的评估随后在同一推理实例上运行时，若提示词前缀重叠，可能会悄悄命中缓存状态。根据缓存策略的不同，B 团队的结果部分由 A 团队的评估运行决定——而非模型的全新推理。

跨租户 KV 缓存共享的研究表明，单凭缓存命中或未命中的模式就能以较高准确率重建其他团队的提示词。即便没有恶意，跨团队的重叠提示词前缀（常见的系统提示模板、共享的指令格式、复用的少样本示例）也会让状态悄悄通过缓存渗漏。

实际后果：在不了解评估运行时缓存状态的情况下，你无法信任在共享推理基础设施上生成的绝对分数。看似 3% 的提升，可能有 1.5% 来自缓存，只有 1.5% 是真实改进。

渠道二：顺序运行污染

第二种污染渠道更为隐蔽，它不依赖缓存，而是依赖时间。

当评估运行在共享基础设施上顺序执行时，一次运行的残留物会持续影响下一次：遗留文件、累积的内存状态、带有残留梯度状态的热启动模型进程、影响后续读取的文件系统条目。这些残留物在评估结果中往往不可见，却影响可复现性。

还有一个确定性幻觉的问题。团队常常以为固定随机种子就能保证跨次运行的可复现输出，但事实并非如此。在采样层，torch.multinomial 等操作在不同批量大小下本质上是不确定的——GPU 调度顺序会改变有效随机性。研究表明，仅仅改变 GPU 数量或评估时的批量大小，即便种子不变，也会让准确率偏移高达 9%。

这意味着两个团队在不同日期、不同队列深度和批量配置下运行"相同"评估、使用"相同"种子，会得到系统性的不同数字。没有哪个结果本身是错的，但它们不可比较，把它们当作可比较的数字正是污染进入的地方。

渠道三：提示词状态渗漏

第三种渠道是组织层面的，而非技术层面的。当供评估框架使用的共享资源——提示词库、数据集注册表、示例存储——在运行之间发生变化且没有显式版本控制时，就会发生渗漏。

回到开篇的红队场景，但更不显眼的版本到处都是：

• 开发人员在调试时向共享提示词模板的"训练示例"部分添加了对抗样本，然后忘记撤回。
• 基线提示词在数周内被不同团队成员反复改进，却没有留下任何记录。
• 共享数据集注册表部署了新版本，因为有人修复了标注错误——而这恰好删除了模型表现较差的样本。

每种情况下，评估框架评估的内容都与上周略有不同，但版本标签没有改变。指标提升了，污染却是隐形的。

为什么"固定种子"和"隔离命名空间"还不够

认识到这一问题的团队通常会实施两种局部缓解措施：确定性种子和基础设施隔离（独立的 Kubernetes 命名空间、独立的队列）。这两种方法单独使用都不够。

固定种子会失效，因为确定性只在单进程、单批次、单 GPU 配置的层面上得到保证。改变其中任何一项——这在共享基础设施中随负载波动而时常发生——你的种子就会产生不同的样本。零温度也无济于事：即便没有采样随机性，模型输出仍取决于浮点累加顺序，而这随硬件和批量大小而变化。"确定性"运行只在相同二进制文件、相同硬件、相同批量大小、相同日期的狭义条件下才是可复现的。

隔离命名空间会失效，因为它隔离的是计算资源，而非数据。如果 A 团队和 B 团队共享提示词注册表、数据集存储，甚至是公共评估框架配置，命名空间隔离仍然允许提示词状态污染通过这些共享数据层流动。

所需要的是在每个可能共享状态的层面进行隔离：计算、缓存和数据。

真正有效的隔离原语

密封评估环境

密封评估环境运行时没有任何共享外部状态。在实践中，这意味着：

• 每次评估运行使用全新容器：每次评估从已知良好的镜像开始，不携带前次运行的任何状态。这意味着没有热身缓存收益，但也意味着没有污染。
• 内存中模拟服务：替代原本会在运行期间访问共享数据库或模型注册表的服务。
• 显式环境快照：在运行开始时捕获确切配置——模型检查点、提示词版本、数据集哈希——并与结果一起存储。

加载中…