这次我们看一类经常被混在一起的角色和能力AI行业中的 Infra 和 GPU 运维开发。很多团队在搭建AI平台时会默认“基础设施组”应该顺带搞定GPU运维于是把驱动升级、显存监控、节点调度全部塞给 Infra 团队。结果GPU节点一出故障两边互相推诿Infra 说“卡点爆了是上层调度问题”GPU运维开发说“你底层网络都通不了让我怎么调”。其实两者的关系并不复杂Infra 是底座GPU运维开发是底座上专门针对AI算力的深化。Infra 保证“资源能用”GPU运维开发保证“资源用得好”。底座不稳GPU运维开发再强也跑不动大模型底座再稳没有GPU运维开发做拓扑优化和任务调度一万张卡也发挥不出应有的效率。这篇文章直接把两者的职责边界、协作流程、工具链、监控排障和工程化建议拆开讲。包括各自的定位、什么时候需要独立团队、怎么在 K8s 集群里做GPU监控和调度、怎样用 DCGM 采显存指标以及常见的排障思路。适合AI平台工程师、算法工程师、运维开发以及对AI Infra方向感兴趣的开发者阅读。1. 核心概念速览Infra 与 GPU 运维开发的关系维度Infra基础设施GPU 运维开发核心定位提供计算、存储、网络、集群管理底座面向 GPU 算力的专项运维、调度与性能优化常见产出K8s 集群、对象存储、DNS、网络策略GPU 监控面板、调度策略、驱动/固件管理、资源配额技术栈Linux、虚拟化、Kubernetes、Ceph、TCP/IPNVIDIA 驱动、DCGM、CUDA、Prometheus、GPU Operator关键指标节点可用性、网络带宽、存储性能GPU 利用率、显存占用、GPU 故障率、任务排队时间典型问题节点挂掉、网络分区、磁盘写满显存泄漏、驱动报错、GPU 卡扣死、任务卡在 Pending两者的关系可以用一句话概括Infra 提供“通用地基”GPU运维开发在地基上造“AI算力专用房间”。Infra 关心的是所有业务都能跑GPU运维开发关心的只有GPU负载能不能高效稳定地跑。从团队协作看GPU运维开发通常是 Infra 团队里的深度细分角色。小团队可能一个人兼着干大团队会拆成独立小组。最理想的状态是Infra 保证集群和基础服务稳定GPU运维开发专注GPU硬件、驱动、调度和性能。2. 适用场景与职责边界2.1 什么场景需要独立的 GPU 运维开发不是所有AI团队都需要独立的 GPU 运维开发。需要投入独立人力的信号包括训练任务频繁触发NCCL timeout但基础网络监控正常。GPU 利用率长期低于 30%却没有人分析瓶颈。显存泄漏问题反复出现没有统一监控和回收机制。驱动升级后部分节点失败需要批量处理和回滚方案。多个团队共用一个GPU集群资源配额和排队策略没人维护。如果只是零散跑几台带GPU的机器做推理那 Infra 工程师兼着处理驱动和nvidia-smi检查就够了。但一旦进入多机多卡训练、大规模推理集群阶段GPU运维开发是必需品。2.2 Infra 的职责边界Infra 负责的“地基”包括裸金属服务器和虚拟机管理。存储系统包括分布式存储、文件系统、对象存储。网络规划包括VPC、子网、负载均衡。集群管理包括 Kubernetes 的部署、升级、证书管理。基础监控包括节点存活、CPU 负载、磁盘空间、网络流量。Infra 不会主动关心你的训练任务用了几张卡、显存够不够、GPU 拓扑是否合理。这些属于上层算力调度和运维开发的范围。2.3 GPU 运维开发的职责边界GPU运维开发负责的是 AI 算力专项事务GPU 驱动、CUDA 版本、cuBLAS、NCCL 的版本管理和升级。GPU 硬件状态采集包括温度、功耗、显存使用、ECC错误。训练任务的 Pod 调度策略包括 GPU 资源声明、拓扑亲和性。GPU 资源的配额和排队机制防止某个团队独占全部计算卡。性能问题定位例如多机多卡训练慢是网络问题、PCIe 瓶颈还是显存分配问题。简单说Infra 解决“节点能不能跑”GPU运维开发解决“GPU任务跑得快不快、稳不稳、坑不坑人”。3. 协作模式从资源申请到任务上线实际开发中Infra 和 GPU运维开发的工作是穿插的。下面是一套常见的协作流程。3.1 资源规划阶段Infra 负责采购和上架GPU服务器完成基础网络配置。GPU运维开发负责验收卡的健康状态记录每台节点的 GPU 拓扑、驱动版本和固件版本。两边共同确认 K8s 节点的 GPU 资源标签例如labels: nvidia.com/gpu-product: A100-SXM4-40GB nvidia.com/gpu-count: 8 gpu-type: training3.2 环境部署阶段Infra 部署 K8s 集群和 GPU 设备插件。GPU运维开发通过 NVIDIA GPU Operator 管理驱动、监控和运行时。部署顺序通常是Infra 准备操作系统和基础网络。GPU运维开发配置驱动和容器运行时。Infra 接入存储和镜像仓库。GPU运维开发安装 DCGM exporter 和调度器插件。3.3 训练任务阶段算法工程师提交资源需求。调度器根据 GPU 运维开发配置的资源池和拓扑策略分配节点。Infra 保证网络和存储不成为瓶颈。GPU运维开发在任务结束后检查 GPU 状态回收异常显存处理故障卡。这个流程里Infra 的角色像“后勤保障”GPU运维开发像“算力运营”。4. 核心工具链与命令实操搞清楚关系之后最关键的是知道各自用哪些工具干活。下面按模块拆开。4.1 Infra 侧常用工具Kubernetes容器编排与资源调度。Helm部署 GPU Operator 等组件。Ceph/MinIO提供存储。Calico/Cilium网络策略。Prometheus AlertManager基础监控告警。例子查看集群节点 GPU 标签和状态# 查看节点及标签 kubectl get nodes --show-labels # 查看节点上的 GPU 资源总量 kubectl describe node gpu-node-01 | grep -A5 Allocatable4.2 GPU 运维开发侧常用工具NVIDIA Driver显卡驱动。DCGM数据中心 GPU 管理工具负责采集指标。NVIDIA GPU Operator在 K8s 中自动化部署 GPU 组件。nvidia-smi手动查看 GPU 状态。dcgm-exporter将 GPU 指标暴露给 Prometheus。最常用的单卡诊断命令# 查看 GPU 型号、显存、驱动、利用率 nvidia-smi # 查看 GPU 拓扑NVLink 连接情况 nvidia-smi topo -m # 实时监控 NVIDIA GPU 状态 nvidia-smi dmon -s pucvmet4.3 GPU Operator 的典型部署方式用 Helm 安装 GPU Operator 时需要指定驱动版本、DCGM、监控组件helm install gpu-operator nvidia/gpu-operator \ --namespace gpu-operator \ --create-namespace \ --set driver.version535.104.12 \ --set dcgm.enabledtrue \ --set dcgmExporter.enabledtrue注意驱动版本必须和显卡型号匹配。实际版本号要参考 NVIDIA 官网和你的内核版本不能直接套用。安装完成后验证是否正常工作kubectl get pods -n gpu-operator kubectl logs -n gpu-operator -l appnvidia-dcgm-exporter4.4 手工测试 GPU 调度创建一个使用 GPU 的测试 PodapiVersion: v1 kind: Pod metadata: name: gpu-test spec: restartPolicy: OnFailure containers: - name: cuda-vector-add image: nvidia/samples:vectoradd-cuda11.2.1 resources: limits: nvidia.com/gpu: 1提交并且观察kubectl apply -f gpu-test.yaml kubectl get pod gpu-test -o wide kubectl logs gpu-test如果 Pod 正常进入 Running 并打印Test PASSED说明 GPU 调度链路正常。如果一直 Pending要检查节点标签、GPU 设备插件和调度器。5. 功能测试与效果验证这里给出一个可以照做的验证流程用来判断 Infra 和 GPU运维开发的协作是否顺畅。5.1 验证 GPU 设备插件是否工作kubectl get node -o custom-columnsNAME:.metadata.name,GPU:.status.capacity.nvidia\.com/gpu如果所有节点都显示预期的 GPU 数量说明设备插件正常。如果部分节点为 0需要看kubectl describe node或对应节点上的nvidia-device-plugin日志。5.2 验证 GPU 指标采集检查 DCGM exporter 是否暴露指标curl http://127.0.0.1:9400/metrics | grep DCGM_FI_DEV_GPU_UTIL如果输出中包含 GPU 利用率指标说明监控链路没问题。常见的指标包括DCGM_FI_DEV_GPU_UTILGPU 利用率。DCGM_FI_DEV_FB_USED显存使用量。DCGM_FI_DEV_GPU_TEMPGPU 温度。DCGM_FI_DEV_ECC_UNCORRECTABLE_TOTAL不可纠正的 ECC 错误数。5.3 验证调度策略分别提交两个申请全部 GPU 资源的任务观察第二个任务是否进入 Pending从而验证配额生效。kubectl create ns gpu-test kubectl create quota gpu-quota --hardnvidia.com/gpu4 -n gpu-test如果其中一组 Pod 申请超过 4 张卡会被直接拒绝。这是 GPU运维开发设置配额的最基础方式。5.4 验证显存泄漏回收抗显存泄漏的任务导致节点 GPU 显存被占满时先通过nvidia-smi --query-compute-appspid,used_memory找到进程再决定如何清理。nvidia-smi --query-compute-appspid,used_memory --formatcsv如果是 K8s 上的 Pod 残留要 kill 对应进程并确认显存是否释放kill -9 pid nvidia-smi如果显存不释放一般需要排查 GPU 容器是否有句柄泄漏或者驱动是否异常。这一步就是典型的 GPU运维开发工作。6. 监控系统与 API 对接Infra 和 GPU运维开发不可能一直盯着命令行。实际生产环境需要一套完整的监控和告警体系。6.1 Prometheus Grafana 监控栈推荐方案Prometheus 负责采集和存储指标。DCGM exporter 暴露 GPU 指标。Grafana 展示 GPU 利用率和显存。Alertmanager 发送告警。部署编排apiVersion: v1 kind: Service metadata: name: dcgm-exporter namespace: gpu-operator spec: selector: app: nvidia-dcgm-exporter ports: - port: 9400 targetPort: 9400 --- apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: dcgm-exporter namespace: gpu-operator spec: endpoints: - port: metrics selector: matchLabels: app: nvidia-dcgm-exporter6.2 通过 API 查询 GPU 指标有了 Prometheus就可以用 API 查询 GPU 状态。import requests prometheus_url http://prometheus-host:9090/api/v1/query query avg by (node) (DCGM_FI_DEV_GPU_UTIL) response requests.get( prometheus_url, params{query: query}, timeout10 ) print(response.json())这个接口可以接到自己的巡检脚本或告警系统里。GPU 利用率长时间为 0 时自动触发告警这就是最基础的 GPU运维开发自动化能力。6.3 批量任务中的 GPU 资源检查在提交批量训练任务之前建议先检查所有 GPU 节点的健康状态避免任务跑到坏卡上。for node in $(kubectl get nodes -l nvidia.com/gpu.presenttrue -o name); do echo $node kubectl describe $node | grep -E nvidia.com/gpu|Allocated resources | head -n 20 done这个脚本可以替换成 OpenTelemetry 或自研巡检工具核心是定期扫描 GPU 资源余量。7. 资源占用与性能观察性能是 GPU运维开发的核心产出。观察性能和定位瓶颈需要同时关注三层硬件层、系统层、任务层。7.1 硬件层指标GPU 利用率不是越高越好但长期低于 50% 通常说明算力没喂饱。显存占用如果常驻显存接近容量上限容易出现 OOM。GPU 温度超过 90 度需要考虑散热。ECC 错误出现 uncorrectable ECC 错误一般意味着硬件故障。NVLink 带宽多卡训练时拓扑影响显著。命令示例nvidia-smi --query-gpuindex,temperature.gpu,utilization.gpu,memory.used,ecc.errors.uncorrected.total --formatcsv7.2 系统层指标系统层主要看CPU 负载数据加载和预处理是否拖后腿。网络流量NCCL 通信是否占满带宽。磁盘 IO数据集读取是否成为瓶颈。内存用量CPU 侧内存不足会影响 GPU 数据搬运。这些指标通常由 Infra 侧监控覆盖但 GPU运维开发接调时也要能看懂。7.3 任务层指标任务层要看GPU 利用率曲线。训练吞吐例如 samples/s。显存增长趋势。等待数据和等待通信的时间。如果 GPU 利用率在 90% 以上且训练吞吐稳定基本说明 Infra 和 GPU 运维开发配合到位。如果利用率忽高忽低要往上查数据加载和网络通信不能只盯着显卡。8. 常见问题与排查方法Infra 和 GPU运维开发最容易遇到的坑按现象、可能原因和处理方式整理成表。问题现象可能原因排查方式解决方案GPU Pod 一直 Pending节点没有 GPU 标签、设备插件异常、配额不足kubectl describe pod查看节点可分配资源修复设备插件调整 label检查 ResourceQuota训练出现 NCCL timeout网络策略限制、VPC 带宽不足、跨交换机通信延迟nccl-tests测试多机通信查看交换机日志优化网络拓扑调整 Pod 亲和性增大 MTU显存占用异常增长有残留容器句柄或驱动异常nvidia-smi --query-compute-apps检查被占用的显存清理异常进程重启节点升级驱动GPU 利用率长期为 0任务未使用 GPU调度器没分配或监控采集失败kubectl exec进容器执行nvidia-smi检查容器资源 limits确认设备插件指标DCGM exporter 没有指标服务端口没暴露、ServiceMonitor 未关联curl验证 /metrics检查 Service Selector调整 Service 标签重建 ServiceMonitor驱动升级后部分节点失败驱动和内核模块版本不匹配dmesg查看内核模块报错检查/var/log/nvidia-installer.log选择匹配内核的驱动版本先小规模验证再滚动升级调度器把任务打散到不可用卡节点污点和容忍配置错误kubectl describe node查看 Taints检查 Pod 的 Tolerations修正污点策略给故障卡打 NoSchedule 污点显存确实充足但任务 OOMCUDA 版本和框架组合有 bug查看 dmesggrep -i oom检查 GPU 驱动和容器运行时版本这套排查表格不能保证覆盖所有问题但帮你在团队协作时先确认“这块是 Infra 负责还是 GPU运维开发负责”。网络问题先找 Infra驱动和显存问题先找 GPU运维开发任务和代码问题找算法工程师。9. 工程化最佳实践与团队协作建议9.1 把 GPU 视为可编程资源而不是裸硬件好的 GPU运维开发团队会把 GPU 封装成标准资源。通过 K8s 的 Extended Resource 暴露给上层用户只声明需要几张卡不用关心驱动和拓扑细节。建议在集群级别做四个标准化标准化驱动版本和 CUDA 底座。标准化 GPU 资源标签。标准化监控指标和告警规则。标准化故障卡处理流程。9.2 建立 Infra 和 GPU 运维开发的协作接口比较好的协作方式是定义一套“接口文档”Infra 提供网络、存储、集群的基础信息。GPU运维开发提供 GPU 资源视图和调度策略。算法工程师只提交训练或推理请求。例如GPU运维开发可以提供一份资源视图表格| 资源池 | GPU 型号 | 数量 | 驱动版本 | 调度策略 | 使用方 | | --- | --- | --- | --- | --- | --- | | training-a100 | A100 40G | 32 | 535.104.12 | 单任务独占 | 算法A组 | | inference-4090 | RTX 4090 | 16 | 535.104.12 | 多副本共享 | 推理平台 |9.3 自动化比手工操作重要GPU 运维开发不能停留在“帮算法工程师手敲 nvidia-smi”的阶段。要把常用操作脚本化健康检查脚本。GPU 故障自动隔离脚本。显存泄漏巡检脚本。驱动升级前的节点排空脚本。一个比较实用的健康检查脚本模板#!/bin/bash # 检查 GPU 状态并输出异常信息 for i in $(seq 0 $(nvidia-smi --query-gpuindex --formatcsv,noheader | tail -n1)); do util$(nvidia-smi -i $i --query-gpuutilization.gpu --formatcsv,noheader) temp$(nvidia-smi -i $i --query-gputemperature.gpu --formatcsv,noheader) echo GPU $i: util$util, temp$temp done9.4 合规和数据安全提醒监控和运维过程中会接触到训练数据、模型权重和用户容器。需要做好三件事访问控制只有运维开发人员能查看 GPU 容器里的监控信息。日志脱敏告警通知中不暴露训练数据内容。审计留痕谁执行了重启、谁更新了驱动要能追溯。如果在生产环境里做 GPU 资源监控不要把用户代码和训练日志直接拉到外部平台要在内部完成分析和告警。10. 总结与下一步Infra 和 GPU运维开发的关系不是上下级而是底座和专项的关系。Infra 让集群活起来GPU运维开发让算力用起来。团队如果只有一个人把他定位成“AI Infra 工程师”最合理如果团队够大一定要拆出 GPU 运维开发负责算力层。如果你是算法工程师最值得先验证的一步是你的训练任务能不能稳定拿到 GPU并且 GPU 利用率能持续稳定在高位。如果做不到先别急着调模型把 Infra 和 GPU运维开发的流程理清楚。如果你准备入行 AI Infra 方向优先补的基础技能是 Linux 和 Kubernetes然后是 GPU 驱动的安装和故障定位最后是 DCGM、Prometheus 这套监控体系。把这三层打通你就已经具备和 Infra、算法两方协作的能力。最容易踩的坑是两边都认为“GPU 问题不是我的问题”。建议每个团队都指定一个 GPU 故障责任人并且让 Infra 工程师和 GPU运维开发工程师共同维护一份 GPU 资源清单。这样至少能保证出问题的时候有人第一时间接单而不是等到训练任务挂了一天之后才开始排查。 
长河君 · 2026/10/23 6:48:58 · 阅读 1.2k AI Infra与GPU运维开发：职责边界、工具链与K8s调度实践
这次我们看一类经常被混在一起的角色和能力AI行业中的 Infra 和 GPU 运维开发。很多团队在搭建AI平台时会默认“基础设施组”应该顺带搞定GPU运维于是把驱动升级、显存监控、节点调度全部塞给 Infra 团队。结果GPU节点一出故障两边互相推诿Infra 说“卡点爆了是上层调度问题”GPU运维开发说“你底层网络都通不了让我怎么调”。其实两者的关系并不复杂Infra 是底座GPU运维开发是底座上专门针对AI算力的深化。Infra 保证“资源能用”GPU运维开发保证“资源用得好”。底座不稳GPU运维开发再强也跑不动大模型底座再稳没有GPU运维开发做拓扑优化和任务调度一万张卡也发挥不出应有的效率。这篇文章直接把两者的职责边界、协作流程、工具链、监控排障和工程化建议拆开讲。包括各自的定位、什么时候需要独立团队、怎么在 K8s 集群里做GPU监控和调度、怎样用 DCGM 采显存指标以及常见的排障思路。适合AI平台工程师、算法工程师、运维开发以及对AI Infra方向感兴趣的开发者阅读。1. 核心概念速览Infra 与 GPU 运维开发的关系维度Infra基础设施GPU 运维开发核心定位提供计算、存储、网络、集群管理底座面向 GPU 算力的专项运维、调度与性能优化常见产出K8s 集群、对象存储、DNS、网络策略GPU 监控面板、调度策略、驱动/固件管理、资源配额技术栈Linux、虚拟化、Kubernetes、Ceph、TCP/IPNVIDIA 驱动、DCGM、CUDA、Prometheus、GPU Operator关键指标节点可用性、网络带宽、存储性能GPU 利用率、显存占用、GPU 故障率、任务排队时间典型问题节点挂掉、网络分区、磁盘写满显存泄漏、驱动报错、GPU 卡扣死、任务卡在 Pending两者的关系可以用一句话概括Infra 提供“通用地基”GPU运维开发在地基上造“AI算力专用房间”。Infra 关心的是所有业务都能跑GPU运维开发关心的只有GPU负载能不能高效稳定地跑。从团队协作看GPU运维开发通常是 Infra 团队里的深度细分角色。小团队可能一个人兼着干大团队会拆成独立小组。最理想的状态是Infra 保证集群和基础服务稳定GPU运维开发专注GPU硬件、驱动、调度和性能。2. 适用场景与职责边界2.1 什么场景需要独立的 GPU 运维开发不是所有AI团队都需要独立的 GPU 运维开发。需要投入独立人力的信号包括训练任务频繁触发NCCL timeout但基础网络监控正常。GPU 利用率长期低于 30%却没有人分析瓶颈。显存泄漏问题反复出现没有统一监控和回收机制。驱动升级后部分节点失败需要批量处理和回滚方案。多个团队共用一个GPU集群资源配额和排队策略没人维护。如果只是零散跑几台带GPU的机器做推理那 Infra 工程师兼着处理驱动和nvidia-smi检查就够了。但一旦进入多机多卡训练、大规模推理集群阶段GPU运维开发是必需品。2.2 Infra 的职责边界Infra 负责的“地基”包括裸金属服务器和虚拟机管理。存储系统包括分布式存储、文件系统、对象存储。网络规划包括VPC、子网、负载均衡。集群管理包括 Kubernetes 的部署、升级、证书管理。基础监控包括节点存活、CPU 负载、磁盘空间、网络流量。Infra 不会主动关心你的训练任务用了几张卡、显存够不够、GPU 拓扑是否合理。这些属于上层算力调度和运维开发的范围。2.3 GPU 运维开发的职责边界GPU运维开发负责的是 AI 算力专项事务GPU 驱动、CUDA 版本、cuBLAS、NCCL 的版本管理和升级。GPU 硬件状态采集包括温度、功耗、显存使用、ECC错误。训练任务的 Pod 调度策略包括 GPU 资源声明、拓扑亲和性。GPU 资源的配额和排队机制防止某个团队独占全部计算卡。性能问题定位例如多机多卡训练慢是网络问题、PCIe 瓶颈还是显存分配问题。简单说Infra 解决“节点能不能跑”GPU运维开发解决“GPU任务跑得快不快、稳不稳、坑不坑人”。3. 协作模式从资源申请到任务上线实际开发中Infra 和 GPU运维开发的工作是穿插的。下面是一套常见的协作流程。3.1 资源规划阶段Infra 负责采购和上架GPU服务器完成基础网络配置。GPU运维开发负责验收卡的健康状态记录每台节点的 GPU 拓扑、驱动版本和固件版本。两边共同确认 K8s 节点的 GPU 资源标签例如labels: nvidia.com/gpu-product: A100-SXM4-40GB nvidia.com/gpu-count: 8 gpu-type: training3.2 环境部署阶段Infra 部署 K8s 集群和 GPU 设备插件。GPU运维开发通过 NVIDIA GPU Operator 管理驱动、监控和运行时。部署顺序通常是Infra 准备操作系统和基础网络。GPU运维开发配置驱动和容器运行时。Infra 接入存储和镜像仓库。GPU运维开发安装 DCGM exporter 和调度器插件。3.3 训练任务阶段算法工程师提交资源需求。调度器根据 GPU 运维开发配置的资源池和拓扑策略分配节点。Infra 保证网络和存储不成为瓶颈。GPU运维开发在任务结束后检查 GPU 状态回收异常显存处理故障卡。这个流程里Infra 的角色像“后勤保障”GPU运维开发像“算力运营”。4. 核心工具链与命令实操搞清楚关系之后最关键的是知道各自用哪些工具干活。下面按模块拆开。4.1 Infra 侧常用工具Kubernetes容器编排与资源调度。Helm部署 GPU Operator 等组件。Ceph/MinIO提供存储。Calico/Cilium网络策略。Prometheus AlertManager基础监控告警。例子查看集群节点 GPU 标签和状态# 查看节点及标签 kubectl get nodes --show-labels # 查看节点上的 GPU 资源总量 kubectl describe node gpu-node-01 | grep -A5 Allocatable4.2 GPU 运维开发侧常用工具NVIDIA Driver显卡驱动。DCGM数据中心 GPU 管理工具负责采集指标。NVIDIA GPU Operator在 K8s 中自动化部署 GPU 组件。nvidia-smi手动查看 GPU 状态。dcgm-exporter将 GPU 指标暴露给 Prometheus。最常用的单卡诊断命令# 查看 GPU 型号、显存、驱动、利用率 nvidia-smi # 查看 GPU 拓扑NVLink 连接情况 nvidia-smi topo -m # 实时监控 NVIDIA GPU 状态 nvidia-smi dmon -s pucvmet4.3 GPU Operator 的典型部署方式用 Helm 安装 GPU Operator 时需要指定驱动版本、DCGM、监控组件helm install gpu-operator nvidia/gpu-operator \ --namespace gpu-operator \ --create-namespace \ --set driver.version535.104.12 \ --set dcgm.enabledtrue \ --set dcgmExporter.enabledtrue注意驱动版本必须和显卡型号匹配。实际版本号要参考 NVIDIA 官网和你的内核版本不能直接套用。安装完成后验证是否正常工作kubectl get pods -n gpu-operator kubectl logs -n gpu-operator -l appnvidia-dcgm-exporter4.4 手工测试 GPU 调度创建一个使用 GPU 的测试 PodapiVersion: v1 kind: Pod metadata: name: gpu-test spec: restartPolicy: OnFailure containers: - name: cuda-vector-add image: nvidia/samples:vectoradd-cuda11.2.1 resources: limits: nvidia.com/gpu: 1提交并且观察kubectl apply -f gpu-test.yaml kubectl get pod gpu-test -o wide kubectl logs gpu-test如果 Pod 正常进入 Running 并打印Test PASSED说明 GPU 调度链路正常。如果一直 Pending要检查节点标签、GPU 设备插件和调度器。5. 功能测试与效果验证这里给出一个可以照做的验证流程用来判断 Infra 和 GPU运维开发的协作是否顺畅。5.1 验证 GPU 设备插件是否工作kubectl get node -o custom-columnsNAME:.metadata.name,GPU:.status.capacity.nvidia\.com/gpu如果所有节点都显示预期的 GPU 数量说明设备插件正常。如果部分节点为 0需要看kubectl describe node或对应节点上的nvidia-device-plugin日志。5.2 验证 GPU 指标采集检查 DCGM exporter 是否暴露指标curl http://127.0.0.1:9400/metrics | grep DCGM_FI_DEV_GPU_UTIL如果输出中包含 GPU 利用率指标说明监控链路没问题。常见的指标包括DCGM_FI_DEV_GPU_UTILGPU 利用率。DCGM_FI_DEV_FB_USED显存使用量。DCGM_FI_DEV_GPU_TEMPGPU 温度。DCGM_FI_DEV_ECC_UNCORRECTABLE_TOTAL不可纠正的 ECC 错误数。5.3 验证调度策略分别提交两个申请全部 GPU 资源的任务观察第二个任务是否进入 Pending从而验证配额生效。kubectl create ns gpu-test kubectl create quota gpu-quota --hardnvidia.com/gpu4 -n gpu-test如果其中一组 Pod 申请超过 4 张卡会被直接拒绝。这是 GPU运维开发设置配额的最基础方式。5.4 验证显存泄漏回收抗显存泄漏的任务导致节点 GPU 显存被占满时先通过nvidia-smi --query-compute-appspid,used_memory找到进程再决定如何清理。nvidia-smi --query-compute-appspid,used_memory --formatcsv如果是 K8s 上的 Pod 残留要 kill 对应进程并确认显存是否释放kill -9 pid nvidia-smi如果显存不释放一般需要排查 GPU 容器是否有句柄泄漏或者驱动是否异常。这一步就是典型的 GPU运维开发工作。6. 监控系统与 API 对接Infra 和 GPU运维开发不可能一直盯着命令行。实际生产环境需要一套完整的监控和告警体系。6.1 Prometheus Grafana 监控栈推荐方案Prometheus 负责采集和存储指标。DCGM exporter 暴露 GPU 指标。Grafana 展示 GPU 利用率和显存。Alertmanager 发送告警。部署编排apiVersion: v1 kind: Service metadata: name: dcgm-exporter namespace: gpu-operator spec: selector: app: nvidia-dcgm-exporter ports: - port: 9400 targetPort: 9400 --- apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: dcgm-exporter namespace: gpu-operator spec: endpoints: - port: metrics selector: matchLabels: app: nvidia-dcgm-exporter6.2 通过 API 查询 GPU 指标有了 Prometheus就可以用 API 查询 GPU 状态。import requests prometheus_url http://prometheus-host:9090/api/v1/query query avg by (node) (DCGM_FI_DEV_GPU_UTIL) response requests.get( prometheus_url, params{query: query}, timeout10 ) print(response.json())这个接口可以接到自己的巡检脚本或告警系统里。GPU 利用率长时间为 0 时自动触发告警这就是最基础的 GPU运维开发自动化能力。6.3 批量任务中的 GPU 资源检查在提交批量训练任务之前建议先检查所有 GPU 节点的健康状态避免任务跑到坏卡上。for node in $(kubectl get nodes -l nvidia.com/gpu.presenttrue -o name); do echo $node kubectl describe $node | grep -E nvidia.com/gpu|Allocated resources | head -n 20 done这个脚本可以替换成 OpenTelemetry 或自研巡检工具核心是定期扫描 GPU 资源余量。7. 资源占用与性能观察性能是 GPU运维开发的核心产出。观察性能和定位瓶颈需要同时关注三层硬件层、系统层、任务层。7.1 硬件层指标GPU 利用率不是越高越好但长期低于 50% 通常说明算力没喂饱。显存占用如果常驻显存接近容量上限容易出现 OOM。GPU 温度超过 90 度需要考虑散热。ECC 错误出现 uncorrectable ECC 错误一般意味着硬件故障。NVLink 带宽多卡训练时拓扑影响显著。命令示例nvidia-smi --query-gpuindex,temperature.gpu,utilization.gpu,memory.used,ecc.errors.uncorrected.total --formatcsv7.2 系统层指标系统层主要看CPU 负载数据加载和预处理是否拖后腿。网络流量NCCL 通信是否占满带宽。磁盘 IO数据集读取是否成为瓶颈。内存用量CPU 侧内存不足会影响 GPU 数据搬运。这些指标通常由 Infra 侧监控覆盖但 GPU运维开发接调时也要能看懂。7.3 任务层指标任务层要看GPU 利用率曲线。训练吞吐例如 samples/s。显存增长趋势。等待数据和等待通信的时间。如果 GPU 利用率在 90% 以上且训练吞吐稳定基本说明 Infra 和 GPU 运维开发配合到位。如果利用率忽高忽低要往上查数据加载和网络通信不能只盯着显卡。8. 常见问题与排查方法Infra 和 GPU运维开发最容易遇到的坑按现象、可能原因和处理方式整理成表。问题现象可能原因排查方式解决方案GPU Pod 一直 Pending节点没有 GPU 标签、设备插件异常、配额不足kubectl describe pod查看节点可分配资源修复设备插件调整 label检查 ResourceQuota训练出现 NCCL timeout网络策略限制、VPC 带宽不足、跨交换机通信延迟nccl-tests测试多机通信查看交换机日志优化网络拓扑调整 Pod 亲和性增大 MTU显存占用异常增长有残留容器句柄或驱动异常nvidia-smi --query-compute-apps检查被占用的显存清理异常进程重启节点升级驱动GPU 利用率长期为 0任务未使用 GPU调度器没分配或监控采集失败kubectl exec进容器执行nvidia-smi检查容器资源 limits确认设备插件指标DCGM exporter 没有指标服务端口没暴露、ServiceMonitor 未关联curl验证 /metrics检查 Service Selector调整 Service 标签重建 ServiceMonitor驱动升级后部分节点失败驱动和内核模块版本不匹配dmesg查看内核模块报错检查/var/log/nvidia-installer.log选择匹配内核的驱动版本先小规模验证再滚动升级调度器把任务打散到不可用卡节点污点和容忍配置错误kubectl describe node查看 Taints检查 Pod 的 Tolerations修正污点策略给故障卡打 NoSchedule 污点显存确实充足但任务 OOMCUDA 版本和框架组合有 bug查看 dmesggrep -i oom检查 GPU 驱动和容器运行时版本这套排查表格不能保证覆盖所有问题但帮你在团队协作时先确认“这块是 Infra 负责还是 GPU运维开发负责”。网络问题先找 Infra驱动和显存问题先找 GPU运维开发任务和代码问题找算法工程师。9. 工程化最佳实践与团队协作建议9.1 把 GPU 视为可编程资源而不是裸硬件好的 GPU运维开发团队会把 GPU 封装成标准资源。通过 K8s 的 Extended Resource 暴露给上层用户只声明需要几张卡不用关心驱动和拓扑细节。建议在集群级别做四个标准化标准化驱动版本和 CUDA 底座。标准化 GPU 资源标签。标准化监控指标和告警规则。标准化故障卡处理流程。9.2 建立 Infra 和 GPU 运维开发的协作接口比较好的协作方式是定义一套“接口文档”Infra 提供网络、存储、集群的基础信息。GPU运维开发提供 GPU 资源视图和调度策略。算法工程师只提交训练或推理请求。例如GPU运维开发可以提供一份资源视图表格| 资源池 | GPU 型号 | 数量 | 驱动版本 | 调度策略 | 使用方 | | --- | --- | --- | --- | --- | --- | | training-a100 | A100 40G | 32 | 535.104.12 | 单任务独占 | 算法A组 | | inference-4090 | RTX 4090 | 16 | 535.104.12 | 多副本共享 | 推理平台 |9.3 自动化比手工操作重要GPU 运维开发不能停留在“帮算法工程师手敲 nvidia-smi”的阶段。要把常用操作脚本化健康检查脚本。GPU 故障自动隔离脚本。显存泄漏巡检脚本。驱动升级前的节点排空脚本。一个比较实用的健康检查脚本模板#!/bin/bash # 检查 GPU 状态并输出异常信息 for i in $(seq 0 $(nvidia-smi --query-gpuindex --formatcsv,noheader | tail -n1)); do util$(nvidia-smi -i $i --query-gpuutilization.gpu --formatcsv,noheader) temp$(nvidia-smi -i $i --query-gputemperature.gpu --formatcsv,noheader) echo GPU $i: util$util, temp$temp done9.4 合规和数据安全提醒监控和运维过程中会接触到训练数据、模型权重和用户容器。需要做好三件事访问控制只有运维开发人员能查看 GPU 容器里的监控信息。日志脱敏告警通知中不暴露训练数据内容。审计留痕谁执行了重启、谁更新了驱动要能追溯。如果在生产环境里做 GPU 资源监控不要把用户代码和训练日志直接拉到外部平台要在内部完成分析和告警。10. 总结与下一步Infra 和 GPU运维开发的关系不是上下级而是底座和专项的关系。Infra 让集群活起来GPU运维开发让算力用起来。团队如果只有一个人把他定位成“AI Infra 工程师”最合理如果团队够大一定要拆出 GPU 运维开发负责算力层。如果你是算法工程师最值得先验证的一步是你的训练任务能不能稳定拿到 GPU并且 GPU 利用率能持续稳定在高位。如果做不到先别急着调模型把 Infra 和 GPU运维开发的流程理清楚。如果你准备入行 AI Infra 方向优先补的基础技能是 Linux 和 Kubernetes然后是 GPU 驱动的安装和故障定位最后是 DCGM、Prometheus 这套监控体系。把这三层打通你就已经具备和 Infra、算法两方协作的能力。最容易踩的坑是两边都认为“GPU 问题不是我的问题”。建议每个团队都指定一个 GPU 故障责任人并且让 Infra 工程师和 GPU运维开发工程师共同维护一份 GPU 资源清单。这样至少能保证出问题的时候有人第一时间接单而不是等到训练任务挂了一天之后才开始排查。