AI 智能體與 OODA 循環策略合力優化數據中心運營效率

為了回答這些類型的問題等，我們的 NVIDIA 團隊啟動了一個名為 LLo11yPop (LLM + Observability) 的項目，開發使用 OODA 循環（觀察、方向、決策、行動）的可觀察性 AI 智能體框架。

在本文中，我將概述我們如何在架構設計中使用多 LLM 復合模型構建用于 GPU 車隊管理的可觀測性代理框架。我還將介紹代理的各種角色，例如編排和任務執行。最后，我將分享經驗教訓，以便未來試驗代理的可觀測性框架。

用于與 GPU 集群對話的可觀測代理框架

NVIDIA DGX 云團隊負責管理涵蓋所有主要云服務提供商的全球 GPU 機群，以及我們自己的數據中心。隨著加速數據中心在全球的不斷擴展，我們不得不發明全新的方法來觀察機群，以便我們能夠以最高效、最及時的方式向全球提供加速功能。

監控加速數據中心

GPU 的每次連續迭代都會增加所需的可觀測性。利用率、錯誤和吞吐量等標準數據中心指標是基準。

要真正了解下一代數據中心的運行狀況，您必須盡可能考慮其周圍的物理環境。

• 溫度
• 濕度
• 電源穩定性
• 延遲

分析加速 AI 工作負載時，有數十項指標至關重要，因為這些指標能讓您更快地處理數據中心事件。鑒于專為訓練基礎模型而設計的 GPU 集群的復雜性更高，因此必須應用我們能夠幫助應對挑戰的各種技術。

為此，我們團隊的第一個目標是構建一個系統，使您能夠與GPU集群進行對話。在NVIDIA NIM微服務的啟發下，我們已經建立了用戶與數據庫對話的能力。如果您能做到這一點，為什么不打開從可觀測系統獲得的高維數據的對話，讓數據中心操作人員擁有這種能力？

在 NVIDIA，我們的車隊中有許多可觀測系統，可以使用 Elasticsearch 訪問。因此，我們決定使用 NIM 微服務，使我們能夠用人類語言與 Elasticsearch 進行對話。那樣子，agent 系統就可以回答“哪些集群在車隊中風扇故障問題最嚴重？”等問題，并獲得準確、可行的結果。

模型架構

圖 1 顯示代理類型：

• Director
  • Orchestrator 代理：將問題路由到正確的分析師，然后選擇最佳行動作為回應。
• Manager
  • 分析師代理：在特定功能領域接受訓練，他們了解自己擁有的可用數據，并將廣泛的問題轉換為由檢索代理回答的特定問題。
  • 動作代理：根據編排人員觀察到的情況協調動作，例如在數據中心發生需要人類注意的情況時通知SRE。
• Worker
  • 檢索代理：使用 NVIDIA NeMo Retriever NIM 微服務，將給定主題中的問題轉換為針對數據源或服務端點運行的代碼。
  • 任務執行代理：通常通過工作流引擎執行特定任務。

所有智能體都基于任何從事知識工作的人類組織中可能存在的相同類型的組織層次結構進行建模。主任協調努力以實現任務，經理使用專業領域知識分配工作，并針對特定任務優化工人智能體。

圖 2 顯示了我們為適應初始用例而構建的特定代理，在初始用例中，我們可以從異構來源分析各種類型的遙測，然后使用 Python 進行更詳細的分析。

另一個關鍵發現是，需要特定類型的 agent 來檢測非主題問題，我們早期了解到，如果沒有這種guardrails，模型會更頻繁地對系統范圍以外的區域產生幻影。

轉向多 LLM 復合模型

為了完成這項工作，我們意識到需要多個大語言模型（LLM）來處理所有不同類型的遙測數據，以有效管理集群。雖然需要 GPU 指標，但這些指標不足以理解堆棧的相關層：從 GPU 層到 Slurm 和 Kubernetes 等編排層的所有內容。

有關更多信息，請參閱從模型到復合AI系統的轉變

使用智能體混合技術

為了滿足這些不同的需求，我們最初采用了混合代理（MoA）方法。我們開發了一系列分析代理，這些分析代理是各自領域的專家，例如 GPU 集群運行參數、Slurm 作業數據和系統日志模式。然后，我們構建了一個監督模型，其任務是制定計劃并將任務分配給分析代理，然后這些代理會向查詢代理提問。

在第一個版本投入使用之前，我們使用提示工程來完成所有這些工作，而無需微調或其他復雜的技術。圖3顯示，我們提出的關于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 層次結構的測試金字塔

在經典微服務架構中，通常對特定服務進行測試，通常使用自己的單元測試、功能測試或端到端測試。與經典微服務一樣，對單個組件進行更多測試的效率最高，在向上移動層次結構時，測試次數減少但更全面（圖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代理應用程序。