GPU 调度优先级：别让低价值任务抢走在线推理
一、GPU 集群最怕所有任务看起来一样重要
云原生 AI 平台里，在线推理、离线批处理、评测任务和实验训练经常共用 GPU 节点。如果调度层不区分优先级，低价值任务可能占满资源，导致在线推理排队。GPU 不是普通 CPU，扩容慢，成本高，一旦被错误工作负载占用，恢复也慢。
优先级设计的目标不是让某类任务永远优先，而是让平台在资源紧张时做出可解释的取舍。在线推理要保障延迟，批处理可以等待，实验任务可以被抢占。规则越早写清楚，事故时越少靠人临时判断。
二、用 PriorityClass 和队列分层表达业务价值
Kubernetes 原生的 PriorityClass 可以表达 Pod 优先级，但仅靠它不够。还需要结合命名空间配额、队列和抢占策略。平台层应把业务任务映射到不同队列，再由调度策略决定资源顺序。
flowchart TD A[任务提交] --> B{任务类型} B -->|在线推理| C[高优先级队列] B -->|批推理| D[普通队列] B -->|实验任务| E[低优先级队列] C --> F[GPU 节点池] D --> F E --> F F --> G{资源不足} G -->|是| H[抢占低优先级] G -->|否| I[正常调度]这个链路需要配套可观测性。只配置优先级，却看不到谁被抢占、为什么抢占，就会让使用者觉得平台不可预测。
三、配置优先级时要避免所有人都申请最高级
PriorityClass 的配置应由平台统一管理，业务方通过任务类型选择，而不是手写任意优先级。
apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: ai-online-critical value: 100000 globalDefault: false description: "Online inference workloads with strict latency SLO." --- apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: ai-batch-normal value: 1000 globalDefault: false description: "Batch inference jobs that can wait when GPU is constrained."如果每个团队都能随意使用最高优先级，优先级就失效了。Admission Webhook 可以限制不同命名空间可使用的 PriorityClass，并在提交时写入审计。
四、抢占不是免费午餐，要处理恢复和成本
抢占低优先级任务会释放资源，但也会带来浪费。批推理任务如果没有 checkpoint，被抢占后需要重跑。实验任务如果写中间结果不完整，可能污染产物。平台应要求可抢占任务具备幂等和恢复能力。
还要设置节点池隔离。在线推理和低优先级实验最好不要完全混在一个池里。可以保留一部分在线专用容量，另一部分做共享池。共享池再通过优先级处理突发。
指标上要看抢占次数、等待时间、GPU 利用率和在线延迟。单纯追求高利用率会压缩在线服务余量。GPU 平台的目标不是每秒都满载，而是在关键请求到来时有能力接住。
五、总结
GPU 调度优先级要把业务价值映射到平台规则。在线推理、批处理和实验任务应进入不同队列，配合 PriorityClass、配额和准入控制。抢占策略必须考虑恢复成本和审计可见性。不要让所有任务平等地争抢 GPU，平台要在资源紧张时做出稳定取舍。
