GPU 调度优先级：别让低价值任务抢走在线推理
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平台要在资源紧张时做出稳定取舍。
