NVIDIA 内部实践：AI 代理运维 GPU 集群的五个关键经验

GPU 集群规模扩大后，运维横跨计算、网络、硬件和调度多个层面。训练任务性能下降时，SRE 往往需要逐个打开不同仪表盘，分别检查调度器状态、GPU 温度、网络延迟和应用日志，才能定位根因。NVIDIA 的产品经理 Kavya G Y 和负责 agentic 系统与可观测性的工程师 Rohan Adwankar 在技术博客中记录了他们如何用一组 AI 代理解决这个重复劳动问题。

这套系统叫 AI Factory Operations Agent，运行在 NVIDIA 内部的 DGX H100、DGX B200 和 DGX GB300 生产集群上。核心思路不是用一个全能代理替代 SRE，而是让一组领域专用代理各司其职，通过 Model Context Protocol（MCP）相互通信。SRE 用自然语言向任何代理提问，可以切换调查方向，每一步操作都有审计记录。

NVIDIA 部署了六个领域代理。Job Recovery Agent 检测训练任务失败和 goodput 下降，在调度器、应用、硬件、网络之间执行多层根因分析，确认根因后推荐恢复步骤。Hardware Agent 在设备层面分诊 PCIe 错误、ECC 错误、GPU 故障、NVMe 故障和温度异常，把症状追溯到具体组件。Observability Agent 查询 Prometheus 历史指标和 Grafana Loki 日志，动态生成仪表盘直接显示在网页界面中。Research Agent 检索预载的 NVIDIA Mission Control 手册和 DGX SuperPOD 参考架构文档，也支持用户上传自己的 runbook。Kubernetes Agent 提供只读的集群状态感知，覆盖 Pod、服务、部署、GPU 资源、节点状态和调度状态。Cluster Management Agent 通过诊断 MCP 工具对接 NVIDIA Base Command Manager API，用于集群管理建议和故障排查。

架构中心是 NemoClaw 蓝图提供的用户侧代理运行时，接收 SRE 查询并路由到合适的领域代理。OpenShell 负责治理和控制。每次 shell 执行都在独立的 Kubernetes 沙箱中进行，而非在主网关 Pod 内运行，沙箱生命周期不会修改现有服务或生产负载。安全是分层的：Kubernetes 检查通过服务端 run_kubectl 工具调用固定版本的 kubectl 二进制文件，使用注册的只读凭证，OpenShell 本身不接收 kubectl 或 Kubernetes 凭证。RBAC 明确限定代理可以查看的资源范围——文章展示了实际权限验证结果：可以 get pods 和 configmaps，但不能 get secrets、create pods 或 update pods。

从生产使用中，NVIDIA 提炼出五条经验。第一，清晰的代理边界：重叠的职责归属制造噪音而非信号，每个代理只负责自己的领域。第二，先只读后自动化：准确的调查能力在自动化之前建立 SRE 的信任，让他们先看到代理能做什么、不能做什么。第三，跨层关联：框架将工作负载、硬件和网络信号连接起来，发现孤立工具遗漏的根因——这正是多仪表盘排查的核心痛点。第四，精确的 MCP 工具定义：清晰的工具描述改善路由并减少错误工具选择。第五，透明推理：SRE 需要在采取行动之前看到工具调用、证据和结论。

NVIDIA 持续通过衡量根因分析准确率、追踪 SRE 认同度和扩展代理生态来完善这套框架。对于大规模 AI 工厂，推荐的部署模型是将代理编排和推理放在与生产集群隔离的专用 GPU 加速控制平面上，生产集群只提供遥测数据，不消耗训练 GPU 也不干扰工作负载。内部部署在专用 GPU 容量上运行模型推理，用现有控制平面 CPU Kubernetes 管理空间承载运行时服务。较小规模可以用 RTX PRO Workstation 或 DGX Spark。

多租户场景下，通过限定范围的代理、工具、沙箱和 Kubernetes 权限控制每个租户可访问的集群数据、工具和节点。租户 SRE 只能看到自己的命名空间、任务和节点，中央运维保留更广泛的集群可见性。每个租户可以使用自己的领域代理和专用推理硬件。OpenShell 通过在每个租户的代理和工具运行于内核级限制的隔离沙箱中来强制执行这些边界。