AI Infra实战12GPU成本优化实践本篇目标掌握GPU资源的成本分析和优化方法让每块卡都物尽其用。学完本篇你将掌握GPU成本的构成分析常见浪费场景识别竞价实例策略基于队列长度的自动扩缩容闲置GPU检测和回收右sizing选对GPU型号GPU为什么贵GPU型号按需价格AWS每月成本对比T4$0.53/h~$380相当于一台中配服务器A10G$1.01/h~$730A100 40GB$3.67/h~$2,640相当于一个人的月薪H100$8.10/h~$5,830一张A100空跑一个月就要2640美元。所以GPU利用率每提升10%都是真金白银。上表价格为示意量级随AWS区域、实例家族和时间变化较大实际以AWS官方定价页为准每月成本按约720小时估算。T4到H100每月成本的量级差距越贵的卡空跑浪费越大常见浪费场景浪费场景表现浪费程度开发调试占着GPU不用GPU利用率长期5%高最严重模型太小GPU吃不饱1.5B模型跑在A100上高流量低谷不缩容凌晨没请求但GPU在跑中没有设置请求超时死请求占住GPU中单卡跑多能共享的服务每个服务独占一张卡低优化策略一右sizing选对型号原则模型大小匹配GPU规格不要大马拉小车。模型大小推荐GPU理由1-3BT4 (16GB)模型占3-6GBT4够用且最便宜7BT4 或 A10GT4勉强A10G(24GB)更舒服13BA10G 或 A100需要24-30GB显存70BA100×2 或 H100必须多卡我们的例子Qwen2-1.5B跑在T4上显存用了12GB/16GB 75%这个匹配是合理的。如果跑在A10080GB上利用率只有15%:严重浪费。同一个1.5B模型跑A100利用率约15%跑T4约75%选对型号才不浪费优化策略二竞价实例Spot Instance维度按需实例竞价实例价格原价打3-7折稳定性不会被中断可能被回收2分钟通知适合生产推理服务开发测试、可中断的训练、弹性扩容部分混合策略生产推理服务 基础副本2个Pod → 按需实例保证稳定 弹性扩容部分 → 竞价实例省钱被回收也不影响基础服务# K8s中使用竞价实例节点spec:affinity:nodeAffinity:preferredDuringSchedulingIgnoredDuringExecution:-weight:80preference:matchExpressions:-key:node.kubernetes.io/instance-typeoperator:Invalues:[spot]# 优先调度到竞价节点优化策略三自动扩缩容重要前提缩Pod不一定省钱很多人以为缩Pod就能省钱:这取决于你的Node是怎么买的Node购买方式缩Pod能省钱吗原因包年包月不能Node一直在付费不管上面跑不跑Pod按需按小时能Pod缩了→Node空了→Cluster Autoscaler回收Node→停止计费竞价实例能同上包年包月的GPU节点即使你把Pod缩到0Node的成本依然存在。这种情况下优化方向不是缩容而是把GPU利用率拉满见下面的补充策略。按需/竞价节点HPA缩Pod Cluster Autoscaler回收空Node 真正省钱。同样缩Pod包年包月节点费用不变弹性节点回收后费用才真正下降真正省钱的链路弹性节点 流量下降 → HPA缩Pod(10→2) → 部分Node变空 → Cluster Autoscaler回收空Node → 停止付费 包年包月节点 流量下降 → HPA缩Pod(10→2) → Node还在 → 费用没变 → 不能 没省钱推荐架构固定弹性混合K8s GPU集群 ┌─────────────────────────────────────┐ │ 固定节点包年包月2台 │ ← 保底跑常驻服务 │ - 成本固定利用率要拉满 │ │ - 适合基础流量、离线任务填充 │ └─────────────────────────────────────┘ ┌─────────────────────────────────────┐ │ 弹性节点按需/竞价0-5台 │ ← 按流量伸缩 │ - 流量高时自动加节点 │ │ - 流量低时自动回收节点 → 真省钱 │ │ - 适合高峰扩容、突发流量 │ └─────────────────────────────────────┘固定节点保底拉满利用率弹性节点按流量高峰扩容、低谷回收包年包月节点的优化方式不靠缩容既然Node费用固定思路是让GPU别闲着策略做法效果多服务共享一张GPU跑多个小模型时间片/MIG同样的钱服务更多业务填充离线任务推理空闲时跑训练/数据处理GPU不浪费到期评估利用率长期30%的节点到期不续费减少固定支出右sizing下次采购时选对型号和数量源头控制弹性节点的自动扩缩容配置以下配置只在弹性节点场景下才真正省钱基于队列长度扩缩vLLM 暴露了队列深度指标vllm:num_requests_waiting。要把它用作 HPA 的扩缩依据需要先通过 prometheus-adapter 把这个 Prometheus 指标注册成 K8s 的自定义指标HPA 才能引用。下面的 metric name 用注册后的自定义指标名示例写作vllm_num_requests_waiting实际名称以 adapter 配置为准。# HPA配置根据vLLM队列深度自动扩缩# 前提已用 prometheus-adapter 把 vllm:num_requests_waiting 注册为自定义指标apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:vllm-hpaspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:vllm-serviceminReplicas:1maxReplicas:5metrics:# 当队列中等待请求 5 时扩容-type:Podspods:metric:name:vllm_num_requests_waitingtarget:type:AverageValueaverageValue:5基于GPU利用率扩缩metrics:# GPU利用率 80% 扩容 30% 缩容-type:Externalexternal:metric:name:DCGM_FI_DEV_GPU_UTILtarget:type:AverageValueaverageValue:80定时扩缩已知流量模式如果流量有明显的作息规律白天高、夜间低可以定时扩缩。注意 CronHorizontalPodAutoscaler 不是 Kubernetes 原生资源需要安装第三方组件如阿里云 ack 的 kubernetes-cronhpa-controller 或 KEDA 的 Cron scaler。示例如下# 工作日白天扩到3副本晚上缩到1副本# 注意CronHorizontalPodAutoscaler 为第三方 CRD需先安装对应控制器apiVersion:autoscaling/v2kind:CronHorizontalPodAutoscalerspec:scaleTargetRef:name:vllm-servicejobs:-name:scale-upschedule:0 9 * * 1-5# 周一到周五9点targetSize:3-name:scale-downschedule:0 22 * * 1-5# 周一到周五22点targetSize:1-name:weekendschedule:0 0 * * 0,6# 周末targetSize:1如果不想引入第三方组件也可以用原生 CronJob 定时执行kubectl scale deployment vllm-service --replicasN达到同样效果。优化策略四闲置检测和回收监控面板GPU闲置检测# Prometheus告警GPU连续30分钟利用率5%-alert:GPUIdleexpr:avg_over_time(DCGM_FI_DEV_GPU_UTIL[30m]) 5for:30mlabels:severity:warningannotations:summary:GPU闲置超过30分钟利用率5%action:考虑缩容或回收自动回收策略检测到GPU闲置30分钟 ↓ 发送告警通知企业微信/钉钉 ↓ 等待15分钟给使用者时间反应 ↓ 仍然闲置 → 自动缩容HPA缩到minReplicas优化策略五GPU共享回顾第8篇场景方案效果开发环境多人共用时间片共享1卡→4份成本降75%多个小模型MIG切分A100切成多份一卡跑多服务低流量服务多服务共享同一张卡避免每服务独占成本优化效果量化优化前后对比假设场景10张T4的推理集群弹性节点注意以下数据基于弹性节点按需付费场景。如果是包年包月节点缩容和竞价实例这两项无法直接省钱需要换成利用率提升和到期不续费来计算。优化项优化前成本/月优化后成本/月节省原始10张T4按需$3,800--竞价实例弹性部分-$3,040-20%自动扩缩夜间缩容-$2,432-36%右sizing换掉不需要的A100-$1,900-50%闲置回收-$1,710-55%在这个示意场景下综合优化把月成本从约3800美元降到约1710美元降幅约55%。这是弹性节点假设下的测算用于说明各优化项叠加的量级实际项目需按自身节点方式和流量重新计算。成本监控面板设计一个实用的GPU成本看板通常包含三块内容顶部概览卡本月GPU费用、平均利用率、闲置卡数一眼看总体状况。各实例利用率逐台GPU的利用率横向对比低于阈值的实例高亮标出便于定位闲置。成本与建议单位请求的GPU成本趋势以及自动生成的优化建议如某台闲置建议回收、夜间可缩容。GPU成本看板示意顶部费用与利用率概览、各实例利用率对比低利用率实例高亮、成本趋势与优化建议实践边界本篇是GPU成本优化的方法论和配置模板整理自AWS定价、K8s扩缩容和NVIDIA GPU共享的常规实践不新增云资源成本为0。需要说明文中GPU价格、优化前后对比表和40到55%的节省幅度都是示意场景10张T4弹性集群用于说明各优化项的相对量级不是某个真实项目的实测结果。实际节省取决于节点购买方式、流量模式和业务约束。右sizing、GPU共享时间片、MIG的机制在第08篇已说明竞价实例、HPA、CronHPA等配置为可落地模板接入自定义指标还需 prometheus-adapter 等组件配合。包年包月与弹性节点的省钱逻辑完全不同套用前先确认自己的节点是怎么买的。不把示意测算写成已验证的降本成果是为了让读者清楚哪些是方法、哪些需要结合自身环境测算。小结本篇核心收获右sizing最重要:1.5B模型别用A100选T4就够竞价实例:弹性部分用竞价可省20-70%自动扩缩容:按队列长度或GPU利用率动态调整闲置检测:利用率5%超过30分钟触发告警和回收综合优化的空间可观:在弹性节点场景下右sizing、竞价、扩缩容和闲置回收叠加通常能带来相当比例的成本下降具体幅度需结合自身环境测算系列总结AI Infra实战系列12篇到这里全部完成。你现在具备的AI Infra能力阶段能力GPU基础01-02GPU认知、K8s GPU调度、GPU监控模型Serving03-07vLLM部署调优、方案选型vLLM/Triton/KServe集群运维08-10GPU资源管理、模型版本管理、SLO设计平台化11-12模型CI/CD Pipeline、GPU成本优化参考链接AWS GPU实例定价K8s HPA文档NVIDIA GPU共享方案Spot Instance最佳实践
