对话式人工智能

AI 智能体与 OODA 循环策略合力优化数据中心运营效率

对于任何数据中心来说,操作大型、复杂的 GPU 集群都不是件容易的事情!这其中存在着巨大的复杂性。在加速计算数据中心,冷却、电源、网络,甚至诸如风扇更换周期等无害的事情都必须得到有效管理和良好治理。管理所有这些需要加速了解来自计算堆栈每一层的 PB 级遥测数据。

现在,假设您能够直接与数据中心聊天,检查 GPU 集群的可靠性。考虑一下这样的问题:“在我们数据中心中最频繁更换的前 5 个部件中,哪一个具有最大的供应链风险?” 也许您的任务更复杂,例如:“检查每个 GPU 集群,并分配最相关的技术人员来解决 5% 的最大故障风险集群。”

为了回答这些类型的问题等,我们的 NVIDIA 团队启动了一个名为 LLo11yPop (LLM + Observability) 的项目,开发使用 OODA 循环(观察、方向、决策、行动)的可观察性 AI 智能体框架。

在本文中,我将概述我们如何在架构设计中使用多 LLM 复合模型构建用于 GPU 车队管理的可观测性代理框架。我还将介绍代理的各种角色,例如编排和任务执行。最后,我将分享经验教训,以便未来试验代理的可观测性框架。

用于与 GPU 集群对话的可观测代理框架

NVIDIA DGX 云团队负责管理涵盖所有主要云服务提供商的全球 GPU 机群,以及我们自己的数据中心。随着加速数据中心在全球的不断扩展,我们不得不发明全新的方法来观察机群,以便我们能够以最高效、最及时的方式向全球提供加速功能。

监控加速数据中心

GPU 的每次连续迭代都会增加所需的可观测性。利用率、错误和吞吐量等标准数据中心指标是基准。

要真正了解下一代数据中心的运行状况,您必须尽可能考虑其周围的物理环境。

  • 温度
  • 湿度
  • 电源稳定性
  • 延迟

分析加速 AI 工作负载时,有数十项指标至关重要,因为这些指标能让您更快地处理数据中心事件。鉴于专为训练基础模型而设计的 GPU 集群的复杂性更高,因此必须应用我们能够帮助应对挑战的各种技术。

为此,我们团队的第一个目标是构建一个系统,使您能够与GPU集群进行对话。在NVIDIA NIM微服务的启发下,我们已经建立了用户与数据库对话的能力。如果您能做到这一点,为什么不打开从可观测系统获得的高维数据的对话,让数据中心操作人员拥有这种能力?

在 NVIDIA,我们的车队中有许多可观测系统,可以使用 Elasticsearch 访问。因此,我们决定使用 NIM 微服务,使我们能够用人类语言与 Elasticsearch 进行对话。那样子,agent 系统就可以回答“哪些集群在车队中风扇故障问题最严重?”等问题,并获得准确、可行的结果。

模型架构

Diagram showing 5 types of agents. The orchestrator agent sets goals and routes queries. Analyst agents interpret domain-specific data. Retrieval agents access and retrieve ground truth information. Action agents trigger workflows based on observations. Task execution agents carry out specific steps in a predefined workflow.
图 1. 总体框架中代理类型的高级概述。

图 1 显示代理类型:

  • Director
    • Orchestrator 代理:将问题路由到正确的分析师,然后选择最佳行动作为回应。
  • Manager
    • 分析师代理:在特定功能领域接受训练,他们了解自己拥有的可用数据,并将广泛的问题转换为由检索代理回答的特定问题。
    • 动作代理:根据编排人员观察到的情况协调动作,例如在数据中心发生需要人类注意的情况时通知SRE。
  • Worker
    • 检索代理:使用 NVIDIA NeMo Retriever NIM 微服务,将给定主题中的问题转换为针对数据源或服务端点运行的代码。
    • 任务执行代理:通常通过工作流引擎执行特定任务。

所有智能体都基于任何从事知识工作的人类组织中可能存在的相同类型的组织层次结构进行建模。主任协调努力以实现任务,经理使用专业领域知识分配工作,并针对特定任务优化工人智能体。

The diagram shows how a classification part of the orchestrator agent selects the correct analyst agent based on the task, informing the supervisor part of orchestrator which agent to use. The orchestrator then directs the retrieval agents to query structured databases, gather relevant data, and use Python code to further refinement or preparation of data for presentation.
图 2. 第一个概念验证的交互

图 2 显示了我们为适应初始用例而构建的特定代理,在初始用例中,我们可以从异构来源分析各种类型的遥测,然后使用 Python 进行更详细的分析。

另一个关键发现是,需要特定类型的 agent 来检测非主题问题,我们早期了解到,如果没有这种guardrails,模型会更频繁地对系统范围以外的区域产生幻影。

转向多 LLM 复合模型

为了完成这项工作,我们意识到需要多个大语言模型(LLM)来处理所有不同类型的遥测数据,以有效管理集群。虽然需要 GPU 指标,但这些指标不足以理解堆栈的相关层:从 GPU 层到 Slurm 和 Kubernetes 等编排层的所有内容。

有关更多信息,请参阅从模型到复合AI系统的转变

使用智能体混合技术

为了满足这些不同的需求,我们最初采用了混合代理(MoA)方法。我们开发了一系列分析代理,这些分析代理是各自领域的专家,例如 GPU 集群运行参数、Slurm 作业数据和系统日志模式。然后,我们构建了一个监督模型,其任务是制定计划并将任务分配给分析代理,然后这些代理会向查询代理提问。

在第一个版本投入使用之前,我们使用提示工程来完成所有这些工作,而无需微调或其他复杂的技术。图3显示,我们提出的关于Slurm作业数据的问题,并获得了答案和支持图。

GIF of the UI answering a question about Slurm job failures that have occurred over a given time period, showing code generated by the LLM as the intermediate step prior to producing a full graph of the answer.
图 3. 向 Llo11yPop 提问关于 Slurm 作业失败的问题。

在图 3 中,我们展示了一个常见案例,即我们的资源管理团队需要了解我们在特定云提供商中管理的所有集群上 Slurm 作业失败的趋势。

系统会将问题传递给监督智能体,由其选择合适的智能体来回答问题。在本例中,是Elasticsearch Slurm 分析器。然后,智能体根据问题中反映的需求,从一个或多个查询智能体中收集数据。在本例中,是Elasticsearch 查询工具,可将问题转换为正确的SQL 方言,以便Elasticsearch REST 接口理解。

我们通常将此用作初步查询,以了解趋势,然后提出更多问题,并使用相同的模型进行深入探究。也许我们会在聊天会话中要求探索为什么五月的故障比正常情况多,或者我们可能会要求其他分析师更深入地了解。

通过提供即时答案、查看图形并快速转向下一个问题的能力,我们可以快速诊断各种问题,从我们如何分配 GPUs 到我们必须在可能遇到问题的 GPU 集群中进行进一步诊断。

通过使用代理群技术,我们将一系列小型、集中的模型链接在一起,并执行了几项有趣的优化。例如,我们可以微调为以 Elasticsearch 语法传递 SQL 而构建的模型,从一个构建代码生成的基础模型中,并使用不同的、更大的基础语言模型(LLM)来规划直接执行代理的任务。

从答案和行动到使用 OODA 循环的自治代理

当我们证明可以从我们的分析代理那里得到可靠的答案时,显然下一步就是闭合循环。这就产生了让一个自主的监督代理完成任务的想法。如果监督代理是AI工程总监,我们会给它一个指标,并分配给它一个随着时间的推移改进该指标的任务。与人类组织一样,您会期望您的AI总监在OODA循环中运行。

解决 GPU 集群可靠性问题

为使监督 AI agent 获得更高的可靠性,它应该执行以下操作:

  1. 观察以理解可观测性系统中的数据。
  2. 定位选择正确的代理进行分析。
  3. 决定决定要采取的行动。
  4. 调用动作。

当然,要让人确信 AI 总监正在做出相关决策,大多数初始操作都是为站点可靠性工程师(SRE)创建工单,以便进行分析并采取行动(如果相关)。这类似于人类的操作方式。

与自动驾驶汽车非常相似,数据中心运营自动化存在于从人工辅助驾驶到完全自主的频谱中。在采用的早期阶段,人类始终处于循环之中。

当我们收到集群优化建议时,我们的 SRE 团队会分析请求,对其进行验证,并在相关情况下执行任务,如果建议不存在问题,则提供反馈。这形成了从人类反馈中进行强化学习(RLHF)循环,使我们能够随着时间的推移改进系统,并将其与使用系统本身遥测的其他技术相结合。

适用于 LLM 层次结构的测试金字塔

Diagram shows a large number of individual agent evaluations, medium number of analyst agent tests, and few end-to-end tests. ests near the bottom are cheap, fast, and better for individual agent troubleshooting, while tests near the top are expensive, slower, more comprehensive, and test the entire system.
图 4. 适用于agent层次结构的测试金字塔概念

在经典微服务架构中,通常对特定服务进行测试,通常使用自己的单元测试、功能测试或端到端测试。与经典微服务一样,对单个组件进行更多测试的效率最高,在向上移动层次结构时,测试次数减少但更全面(图4),这使您能够平衡两个相互竞争的目标,即在较低级别上实现快速反馈,在较高级别上实现全面性,以及更快速地诊断问题。

最后一个优势是一个关键的区别,因为如果您尝试使用大型整体模型执行所有操作,那么诊断给定主题领域可能会产生幻影的原因就会变得更加具有挑战性。

虽然 LLM 测试是一个大型主题领域,超出了单篇博文的范围,但请务必指出,经典软件单元测试的框架发生了重大的变化。

例如,您可能会问 LLM:“有多少 GPUs 超过了正常温度范围?”您会得到诸如“三个”、“三个 GPUs 超过”、“3”、“3.00”等回答,或表达相同想法的其他方式。为此,我们使用了第二个通常更强的 LLM,在一套包含 200 多个不同测试的测试套件中验证答案的概念等效性,这些测试在每个系统构建上运行,在系统的不同级别上运行。

从构建可观测性AI智能体中汲取的经验教

首先,您不需要,坦率地说,在开始时不应该跳过训练或调整模型。我们通过进行prompt工程和使用LangChain 将一系列 NIM 微服务连接起来,实现了功能性原型。

该系统中使用的著名模型包括 Mixtral 8x7b 和最近推出的新 Llama 3.1 405b NIM 模型来自 ai.nvidia.com。借助这些模型,您可以入门,并可以自由选择在图形的每个节点中使用的模型,而无需承担模型训练的沉降成本。在您拥有适用于 90% 以上案例的出色模型后,然后对特定模型进行微调,以将准确性提高到您用例所需的阈值。

其次,为正确的工作选择合适的模型。编码模型非常适合作为人类转SQL或其他工具的基础,这些工具可以执行格式化输出等操作。较小的模型非常适合处理更简单的领域,并有助于提高速度并节省token成本。对于最艰巨的任务,通常在 orchestrator-agent 级别使用更大的模型,因为需要更多的上下文来理解整体情况。

最后,在没有人类参与循环的情况下,不要完全自动化,除非您有有力的证据证明代理系统采取的操作准确、有用且安全。就像在实施自动驾驶汽车时,您不会从完全自动驾驶开始,要获得系统操作人员的信任,先行走,然后才能在生产中实现完全自动驾驶系统。

开始构建您的 AI 智能体应用

有关如何使用 NVIDIA 生成式 AI 技术和工具构建自己的 AI 代理和应用程序的更多信息,请参阅 ai.nvidia.com 或试用 NVIDIA NIM APIs

如果您刚刚开始,请参阅构建您的第一个LLM代理应用程序

 

Tags