K8s集群GPU成本优化：从监控到调度实战指南

K8s集群GPU成本优化的核心结论很直接：先确认GPU是否真的被用满，再决定是共享、调度还是缩容。
如果GPU平均利用率低于30%，大多数情况下不需要加卡，而是通过共享调度、自动缩容和按需实例把闲置资源释放掉。
本文按“监控→配置→验证→避坑”的顺序展开，适合有基础Linux和K8s操作经验、但没做过GPU成本治理的运维人员。

第一步：先看清GPU到底浪费在哪里

优化前必须拿到数据，否则容易把“业务低峰”误判成“资源浪费”。
在装有NVIDIA驱动的节点上，登录节点执行：

nvidia-smi --query-gpu=index,name,utilization.gpu,memory.used,memory.total --format=csv -l 5

这条命令每5秒输出一次GPU利用率和显存占用。
观察5-10分钟，重点看两个指标：利用率长期低于20% 和 显存占用远大于计算占用。
前者说明计算资源闲置，后者说明任务只是占着显存但没真正算。

如果节点多，不建议逐台登录。
部署DCGM Exporter并把指标接入Prometheus，查询语句示例：

avg(DCGM_FI_DEV_GPU_UTIL) by (node)

这个查询能按节点看到GPU平均利用率。判断标准：连续一周平均利用率低于30%的节点，才纳入优化范围；
低于10%的节点优先处理。

第二步：根据任务类型选择共享或调度策略

确认浪费后，不要直接删任务，而是按任务类型处理。

推理类任务（如模型服务）：多数时间利用率低但要求随时响应，适合开启GPU共享。
如果使用NVIDIA A100/A30等支持MIG的卡，可切分MIG实例：

nvidia-smi mig -cgi 1g.5gb,1g.5gb -C

执行后把每个MIG实例作为独立资源暴露给K8s，多个小模型可跑在同一张卡上互不干扰。
注意MIG切分后单实例显存和算力固定，不适合需要大显存的任务。

训练类任务：通常需要整卡或整机，优化方向是排队和抢占，而不是共享。
配置优先级让高优任务优先调度，低优任务在资源不足时自动让出。

时间片共享方案：如果卡不支持MIG，可在Device Plugin中启用时间片。
修改DaemonSet环境变量：

env:
- name: SHARED_DEVICE
  value: "true"

应用后重启Device Plugin Pod。
时间片共享的代价是任务之间会互相争抢算力，只建议给低优先级、能容忍延迟波动的任务使用。

第三步：用自动缩容和竞价实例压掉固定成本

共享只解决单卡利用率，集群层面还要减少闲置节点。

配置Cluster Autoscaler缩容：确保GPU节点池开启缩容，并设置合理的缩容阈值。
关键参数：

--scale-down-utilization-threshold=0.5
--scale-down-unneeded-time=10m

含义是节点连续10分钟利用率低于50%就触发缩容。注意：如果任务没有配置资源请求（requests），Autoscaler无法判断节点是否空闲，缩容会失效。
务必给GPU Pod设置：

resources:
  limits:
    nvidia.com/gpu: 1

使用竞价实例或抢占式实例：训练和批处理任务对中断不敏感，可放到竞价节点池。
在节点标签中标记：

kubectl label nodes  node-type=spot

再用nodeSelector把任务调度过去。避坑：推理服务和有状态服务不要放竞价节点，实例被回收时会导致服务不可用。

第四步：验证优化效果并设置告警

调整后不要凭感觉判断，用数据复查。
重新执行第一步的利用率查询，对比优化前后的两个数字：GPU平均利用率和单位任务成本。
如果利用率从20%提升到60%以上，或者同等工作量下GPU节点数减少，说明优化有效。

设置告警规则，避免优化后出现资源不够：

avg(DCGM_FI_DEV_GPU_UTIL) by (node) > 85

当节点利用率持续超过85%时告警，提醒可能又要加卡或扩容。
同时监控Pod的Pending数量，如果大量GPU Pod排队，说明缩容过头。

常见问题与避坑清单

问题一：开启MIG后任务报显存不足。 检查MIG切分规格是否小于任务实际需求，大模型任务应使用整卡或大规格MIG实例，不要为了省成本强行切小。

问题二：Autoscaler不缩容。 优先检查Pod是否设置了resources.requests，以及是否有PodDisruptionBudget阻止驱逐。
GPU节点上的DaemonSet也可能让节点一直“非空”，需要确认DaemonSet是否被正确忽略。

问题三：共享后任务变慢。 时间片共享本质是分时复用，多个任务同时跑会互相影响。
对延迟敏感的服务，建议单独占用MIG实例或整卡，不要混部。

避坑提醒：任何缩容、改调度策略前，先确认业务低峰期和回滚方案。
GPU任务重启成本高，训练任务尤其要保留checkpoint。
不要在生产集群一次性全量开启共享，先拿一个节点池灰度验证。
如果涉及删除节点或改DaemonSet，建议先备份相关YAML：

kubectl get daemonset -n kube-system nvidia-device-plugin -o yaml > nvidia-device-plugin-backup.yaml

收尾建议

服务器K8s集群GPU成本优化的顺序不能颠倒：先监控拿到利用率，再按任务类型选共享或调度，最后用自动缩容和竞价实例降低固定支出。
每做完一步都要用Prometheus数据验证，避免“看起来省了”但业务变慢。
如果你的集群还没有GPU监控，建议先把DCGM Exporter和告警搭起来，再动调度配置。