1. 为什么需要专门的 GPU 调度器
通用 Kubernetes 调度器以 Pod 为单位，以 CPU/内存为核心资源进行调度。然而 AI 训练与推理 workloads 有着本质区别：
- 长时间占用：一次分布式训练任务可能连续运行数天甚至数周
- 多维资源依赖：GPU 型号（V100/H100/A100）、NVLink 拓扑、InfiniBand 网络缺一不可
- 弹性能力受限：GPU 无法像 CPU 一样超发（oversubscribe），资源碎片化严重
2. GPU 调度策略设计
2.1 Gang Scheduling（组调度）
分布式训练要求所有计算节点同时启动，否则先启动的节点会空转等待。Gang Scheduling 保证一组关联 Pod 要么全部调度成功，要么全部不调度。
注意：原生 Kubernetes 不支持 Gang Scheduling，需使用 Volcano、Koordinator 或 YuniKorn 等调度器扩展。
2.2 Bin-Packing 与 Spread
对于推理服务，优先使用 Bin-Packing 将更多副本压入少数节点，减少 Pod 间网络跳数；对于训练任务，Spread 策略可避免单点故障导致的整个 job 失败。
2.3 GPU 资源共享（Time-Slicing）
通过 NVIDIA MPS（Multi-Process Service）或容器时间片切片，可以让多个小任务共享同一块 GPU，提高 GPU 利用率。适用于推理场景，生产训练通常不建议。
3. 算力成本优化实战
3.1 抢占式 Spot 实例
AWS Spot、阿里云抢占式实例价格仅为按量付费的 30%-50%。配合 Checkpoint 机制（每 N 个 step 定期保存模型状态），可以在实例被回收时从最近 checkpoint 恢复，几乎零损失。
3.2 弹性伸缩（Autoscaling）
基于 Prometheus 指标的 HPA/VPA 结合 KEDA，实现训练任务的动态伸缩。推理服务可使用 Horizontal Pod Autoscaler 基于 QPS 或 GPU 利用率自动扩缩容。
3.3 混合云调度
敏感数据训练在私有云，非敏感任务使用公有云 GPU 资源。通过 Federation 或 Karmada 实现跨集群统一调度，结合成本优先/性能优先策略路由。
4. 监控与可观测性
推荐 DCGM（Data Center GPU Manager）+ Prometheus + Grafana 组合，监控 GPU 利用率、显存、温度、功耗。设置利用率阈值告警（如 GPU 利用率连续 5 分钟低于 30%），自动触发资源回收。
5. 总结
GPU 集群调度的核心挑战是资源匹配精度与利用率最大化之间的平衡。通过gang scheduling 保证训练效率，通过弹性伸缩和 Spot 实例降低成本，通过完善的监控体系保障稳定性，三者协同才能构建高效、经济的 AI 算力平台。