隨著各組織繼續在 GPU 基礎設施上投入數十億資金用於 AI 工作負載，監控和可觀測效能力方面出現了一個關鍵缺口。Neurox 作為一個新的自託管平臺，旨在透過提供專為 Kubernetes 環境設計的全面 GPU 監控來解決這一問題。
 |
|---|
| 這張截圖顯示了 Neurox Control Helm Chart 的 GitHub 倉庫，該倉庫支援 Kubernetes 環境中的 GPU 監控 |
GPU 可觀測性問題
AI 基礎設施的快速增長暴露了現有監控解決方案的重大侷限性。根據技術社群的討論，當前的工具無法回答關於 GPU 利用率、所有權和成本的基本問題。像 DCGM_FI_DEV_GPU_UTIL 這樣的傳統指標可以顯示 GPU 正在發生什麼，但無法解釋原因 - 導致團隊無法診斷資源利用率低下、應用程式配置錯誤或作業靜默回退到 CPU 處理等問題。
「GPU 可觀測性已經崩潰... 儘管公司在 GPU 上投入了數十億資金，但仍然沒有簡單的方法來回答基本問題：我的 GPU 發生了什麼？誰在使用它們？這個專案花費了我多少錢？」
目前，大多陣列織正在使用 Prometheus、Grafana 和 kubectl 指令碼拼湊解決方案，為他們的 GPU 基礎設施建立了一個分散的檢視。當團隊需要了解跨多雲環境的指標、Kubernetes 狀態和財務資料之間的關係時，這種方法就顯得不足。
Neurox 的 GPU 監控方法
Neurox 結合了三個關鍵資料來源，提供全面的可觀測性：來自 NVIDIA SMI 的 GPU 執行時統計資料，來自 Kubernetes 狀態的執行 pod 資訊，以及來自 Kubernetes 狀態的節點資料和事件。這種整合使團隊能夠追蹤諸如 pod 狀態失敗、排程不正確以及應用程式未正確利用 GPU 資源等問題。
該平臺為組織內的不同角色提供了專門構建的儀表板。研究人員可以在工作負載螢幕上監控從建立到完成的工作負載，而財務團隊可以在報告螢幕上訪問按團隊或專案分組的成本資料。這種基於角色的方法滿足了管理員、開發人員、研究人員和財務審計人員在使用 GPU 基礎設施時的多樣化需求。
Neurox 平臺要求：
- Kubernetes 和 CLI 1.29+
- Helm CLI 3.8+
- 12 個 CPU
- 24 GB 記憶體
- 120 GB 持久卷儲存
- 至少 1 個 GPU 節點
- 可從網際網路訪問的入口
主要功能：
- 即時 GPU 利用率監控和閒置 GPU 告警
- 按應用/團隊/專案的成本細分
- 統一檢視 AWS、GCP、Azure 和本地基礎設施
- 支援 Kubernetes：將節點指標與執行中的 pod、作業和所有者關聯
- GPU 健康檢查
部署靈活性和資料隱私
Neurox 架構的一個關鍵方面是控制平面和工作負載元件之間的分離。該平臺被設計為自託管軟體，以確保敏感資料保留在組織的基礎設施內。對於 GPU 叢集儲存有限的團隊，Neurox 提供了分離部署模型 - 控制平面可以安裝在任何具有持久儲存的 Kubernetes 叢集上（如 EKS、AKS 或 GKE），而只有輕量級的工作負載代理需要在 GPU 叢集上執行。
這種靈活性解決了文件中提到的 120GB 持久儲存需求的問題，使該解決方案適用於本地儲存有限的裸金屬 GPU 叢集。該架構還可能允許未來的雲託管控制平面選項，同時保持工作負載資料的安全性。
Neurox 提供了一個免費層級，可監控多達 64 個 GPU，涵蓋了許多個人、學術和輕商業用例。雖然目前不是開源的，但該公司已表示他們正在考慮這條路徑，認識到隱私和成本問題驅動了對開源替代方案的興趣。
隨著 AI 基礎設施在多雲環境中繼續增長複雜性和規模，像 Neurox 這樣的專用可觀測性工具可能對希望最佳化其大量 GPU 投資的組織變得越來越重要。