用于数据中心 SLA 合规监控的多头注意力方法

# 一种用于数据中心 SLA 合规监控的多头注意力方法 ††感谢：已被第 46 届 IEEE 分布式计算系统国际会议接受发表。本工作的部分内容涉及一项待批准的专利申请。
来源: https://arxiv.org/html/2605.05354
###### 摘要

数据中心托管合同中的服务等级协议（SLA）为电力、温度和湿度定义了精确的阈值，并以层级违规罚金的形式表达为对每月经常性费用的抵扣信用。传统的被动式监控仅在违规行为发生后检测违规，限制了补救机会。我们提出了一种框架，将 SLA 规则编码为结构化 JSON 对象，以生成无需人工标注的训练数据。我们训练了每个客户一个多头 Transformer 模型，其中每个注意力头专注于一条 SLA 规则，学习提前 30 分钟预测违规的时间依赖性。训练后，推理服务发出结构化的预测事件，并转换为三种特定角色的视图：展示信用负债的财务架构、显示风险评分和建议干预措施的操作架构，以及将预测与不可变的遥测签名捆绑用于审计的合规架构。通过将模型架构直接与合同义务对齐，该框架使运营商能够预测 SLA 违规、优先处理纠正措施并最大限度地减少财务罚款。

## I引言

托管数据中心（或称为 colo）是大规模设施，出租空间以托管其服务器、存储和网络硬件，以满足企业客户的需求。与传统超大规模数据中心由大型科技企业拥有、管理和占用不同，托管数据中心由第三方提供商运营，专为多租户共享操作而设计。随着行业向越来越多的人工智能（AI）工作负载转变，租户对弹性、合规、持续可用且可扩展的基础设施的需求显著增加。虽然训练大型模型在超大规模设施中进行，但推理任务正推动企业租户以越来越快的速度采用托管模式。由于推理需要低延迟和租户邻近性，企业正在租赁托管空间，以更接近其数据源和客户运行“边缘”AI 模型。

由于这一行业转变，报告预测到 2030 年全球数据中心电力需求将增加 160-175%[9](https://arxiv.org/html/2605.05354#bib.bib4)，其中 AI 工作负载约占所有数字基础设施需求和计算工作负载的一半[6](https://arxiv.org/html/2605.05354#bib.bib3)。预计托管行业的年复合增长率（CAGR）将超过 35%，而更广泛的 AI 数据中心行业 CAGR 为 31%[4](https://arxiv.org/html/2605.05354#bib.bib5),[11](https://arxiv.org/html/2605.05354#bib.bib2),[1](https://arxiv.org/html/2605.05354#bib.bib1)。随着 NVIDIA 新 GPU 发布周期的一年一度节奏增加、向 ±400V 直流电的推动、直接芯片液冷以及每机架 100+ kW 的基础设施等其他行业驱动因素，预计托管部门的全球总电力需求到 2030 年将超过 150-200 GW[9](https://arxiv.org/html/2605.05354#bib.bib4),[11](https://arxiv.org/html/2605.05354#bib.bib2)。

从托管角度来看，向 AI 密集型工作负载的推动意味着租户不仅期望空间、电力和冷却，还期望严格遵守严格的服务等级协议（SLA）。这些 SLA 涵盖正常运行时间、电力可用性、环境稳定性和支持响应能力，同时规定当未达到这些合同约定的协议时，如服务信用等补救措施。这些 SLA 还排除了由计划维护、客户端设备故障或不可抗力事件引起的停机。

对于托管提供商而言，SLA 既是竞争差异点，也是财务风险工具。运营商通常保证 99.9%-99.999% 范围内的可用性（在行业中通常称为“3 个 9”和“5 个 9”），相当于每月仅几分钟的停机时间。这些保证由服务信用支持，在服务信用直接转换为美元金额时，违反协议阈值时会触发赔偿。相反，企业客户根据 SLA 透明度、可审计性、监控能力和过去对 SLA 合规性的演示来评估托管合作伙伴。2025 年曾发生一次此类合规失败，由于芝加哥地区设施的冷却系统机械故障，导致位于伊利诺伊州的 CME Group 发生 10 小时全球交易暂停[8](https://arxiv.org/html/2605.05354#bib.bib6)。这次中断导致 CME Group 损失了 15.8 亿美元的交易量，突显了对实时 SLA 监控的需求。

因此，托管设施的有效 SLA 合规监控必须满足以下几个相互竞争的目标：

- •使合同协议机器可读：SLA 文档通常是非结构化的自然语言合同和协议，具有租户和设施特定的规则，这些规则可以在设施之间一致执行。
- •从被动风险管理转向主动风险管理：现有的托管操作涉及在发生违规事件后被动管理 SLA 规则。这涉及在违规发生后标记违规。系统应预测违规的可能性和严重程度，给运营商时间在违规事件发生之前进行干预。
- •提供可审计的、特定于利益相关者的视图：金融、政府、医疗保健、法律客户对定制输出的需求各不相同，托管运营的金融、运营、法律团队也是如此。发布的信用、日志、关键绩效指标（KPI）和违规历史应提供对相同基础规则、物理系统的传感器数据以及相关违规事件的追溯。

为此，在本文中，我们描述了一种 SLA 合规监控架构，通过结合以下内容来满足托管提供商的上述需求。我们提出了一个基于 ReAct 的智能体框架，该框架摄入并解释租户 SLA 为结构化规则数据库（DB）。相关的结构化规则 DB 是在匿名化 SLA 文档并剥离所有客户敏感信息后形成的。接下来，针对每个客户训练一个多头 Transformer 模型，以根据过去的电力、温度和湿度遥测数据预测 SLA 违规事件。结果是一个端到端的合同感知 SLA 监控管道，专为多租户托管设施设计。每个客户的 SLA 都被明确建模，规则在实时条件下执行。为风险窗口预测即将发生的违规事件，并有足够的前瞻时间以避免罚款并保护运营活动的财务风险。

本文的其余部分组织如下。在第 II 节[2](https://arxiv.org/html/2605.05354#S2)中，我们详细概述了解决方案框架。在第 III 节[3](https://arxiv.org/html/2605.05354#S3)中，我们详细介绍了针对托管操作特定的多头注意力模型，用于 SLA 规则监控。第 IV 节[4](https://arxiv.org/html/2605.05354#S4)包含我们的初步实验结果和端到端系统的演示。最后，在第 V 节[5](https://arxiv.org/html/2605.05354#S5)中，我们提出了结论和未来工作。端到端框架控制流确保了一个闭环，其中纸上定义的合同义务直接驱动传感器/遥测数据的解释、运营和财务风险计算，并允许在发生（或预测到）违规事件后根据结构化 SLA 规则数据库（DB）直接修改 SLA 合同。

## II端到端 SLA 监控框架

本节描述了我们提出的端到端 SLA 监控框架的高级解决方案架构。从高层来看，该框架由四个主要系统组成，如图 1[1](https://arxiv.org/html/2605.05354#S2.F1)所示：SLA 摄入系统、规则提取 ReAct 框架系统、程序化数据标记系统，以及最后用于 SLA 违规预测的每个客户的多头注意力模型。

参见标题图 1：高密度托管数据中心实时 SLA 合规监控架构。该框架执行 3 个高层功能：

- •将租户 SLA 文档转换为机器可读的结构化规则 DB
- •使用规则 DB 以编程方式标记和解释托管数据中心遥测数据，以及
- •使用每个客户的多头注意力模型预测 SLA 违规事件，并将运营、财务和合规输出馈送到相关利益相关者。

这适用于托管环境，其中多个客户共享基础设施，但保持逻辑隔离的 SLA 和监控，通常为设施和机架配备自定义传感器以获取自己的遥测记录。

参见标题图 2：摄入和 PII 剥离系统图 1[1](https://arxiv.org/html/2605.05354#S2.F1)中的摄入和隐私系统解析异构合同文件，这些文件通常以自然语言、PDF、DOCX、其他格式维护。如图 2[2](https://arxiv.org/html/2605.05354#S2.F2)所示，在入口点，系统解析常见的企业文档格式，并通过格式解析器传递，以标准化文本编码并保留部分、条款边界，最重要的是，恢复文档中存在的 SLA 表和/或项目符号结构。这种归一化对于下游的 ReAct 智能体至关重要，后者依赖于解析数据中的一致结构（标题、项目符号、表行和定义）。接下来，通过 Python 中的 re 模块使用正则表达式（Regex）擦洗客户敏感和个人可识别信息（PII），如姓名、签名和直接联系方式、租户特定标识符等。检测到的实体要么被移除，要么替换为稳定的占位符，以在擦洗后保留合同语义（例如，CME Corp, Chicago-1 被替换为 Customer_A, Facility_1）。这与大型语言模型（LLM）管道中用于提示的 PII 擦除的新兴实践一致[5](https://arxiv.org/html/2605.05354#bib.bib7),[7](https://arxiv.org/html/2605.05354#bib.bib8)，其中隔离的擦除确保敏感数据永远不会离开受控基础设施，同时保留下游的正确语义。此时的输出是“清理后的 SLA 文档”对象，这是一个结构化构件，捆绑了归一化文本、部分、表条款和衍生元数据，作为向后续系统暴露的唯一接口。

如图 3[3](https://arxiv.org/html/2605.05354#S2.F3)所示，是将 PII 清理后的 SLA 文档数据转换为每个客户和合同的、一致的、可执行的规则集到规则 DB 的框架。

参见标题图 3：用于将 SLA 规则提取到规则 DB 的 ReAct 智能体框架从概念上讲，ReAct 框架系统围绕 LangGraph*编排智能体*和一组*N*个专门化的*研究智能体*构建。每个智能体根据其角色利用 GPT-4o-mini 模型（参见图 3[3](https://arxiv.org/html/2605.05354#S2.F3)）。编排智能体是接收上游清理后的 SLA 文档的唯一入口点，并维护一个共享状态，包括与接收到的 SLA 相关的当前规则假设、未覆盖的部分和开放问题。它还控制何时以及如何调用每个研究智能体。

LangGraph 用于以图的形式对此进行建模，图中每个智能体都有节点，边用于编码具有显式工作流控制的转换，而不是提示链[3](https://arxiv.org/html/2605.05354#bib.bib9)。由于 SLA 规则提取可以表述为有状态的、多智能体的、迭代推理问题，因此使用 LangGraph 是合理的。图 3[3](https://arxiv.org/html/2605.05354#S2.F3)中的基于图的编排、循环和状态管理使我们能够显式编码编排-研究-验证工作流，使管道比线性或基于提示链的替代方案更容易控制、扩展和调试。

为此，我们利用一个 ReAct 工作流，其中编排智能体控制流程，同时触发具有明确职责的下级研究智能体以推断特定性质的 SLA 规则[14](https://arxiv.org/html/2605.05354#bib.bib10)。编排智能体路由相关摘录文本，并为每个研究者添加上下文，并行触发所需数量的研究智能体[12](https://arxiv.org/html/2605.05354#bib.bib11),[10](https://arxiv.org/html/2605.05354#bib.bib12)。然后每个研究智能体在本地执行其核心 ReAct 循环。它思考分配的文本，通过发出结构化候选规则描述（JSON + 自然语言）来行动，可选择请求后续片段，最后发出结构化 JSON 输出。结构化输出被定义为具有{metric, thresholds, SLA-tier, violation_impact, comment-text}的特定 JSON 架构。候选 SLA 规则随后被聚合到“推断规则集”中，捕捉每个研究智能体的信念，但在这一阶段它们可能是重叠或不完整的。

然后，编排智能体触发自我批评/验证阶段，这是我们的 ReAct 范式的关键。它在关于全局规则集的推理（例如，“所有规则是否完整？”、“所有 JSON 架构中是否存在指标？”等）之间交替，并再次重新调用研究智能体以处理推断规则集中存在的不完整或不一致的项目。这形成了图中的一个决策节点。上述 ReAct 循环提取符合指定结构化架构的可解释和鲁棒的 SLA 规则，比单次 LLM 调用更鲁棒，并且需要多步推理。因此，它也消耗比单次 LLM 调用多得多的令牌。然而，这是合理的，因为通过框架解析为我们的结构化规则 DB 的 SLA 文档，除非 SLA 条款再次修改，否则不需要再次通过智能体工作流解析。在实际托管操作环境中，这仅在 SLA 生命周期结束时发生（数周到数月）。

此时，我们获得了结构化规则 DB（每个客户、每个 SLA 合同），这是下游其余系统的可审计单一事实来源。表 I[1](https://arxiv.org/html/2605.05354#S3.T1)显示了这样一个结构化规则实例的示例结果。剩余的系统利用过去的遥测数据和规则 DB 以编程方式标记传感器数据，以训练多头注意力模型来预测 SLA 违规。

## III用于托管 SLA 的多头注意力模型

每个客户的 SLA 与托管数据中心中的特定机架相关联。此时，我们从每个客户的两个输入开始：客户 GPU 机架的历史传感器数据时间序列（例如，消耗的电力、温度、湿度），以及以 JSON 字段存储的结构化规则 DB 中的合同特定规则。然后将历史遥测数据归一化、重采样并分割为固定长度的窗口（重叠的 30 分钟回溯序列），以便每个示例捕获足够的短 horizon 预测的时间上下文。

图 4[4](https://arxiv.org/html/2605.05354#S3.F4)中的程序化标记然后将 JSON 规则确定性地应用于每个窗口，以根据 SLA 规则 DB 条目派生标签。