多租户 GPU 资源超卖与大促紧急抢占基于 Volcano 的弹性配额治理实战在企业级 AI 算力平台中高昂的 GPU 硬件成本要求平台在日常运行中必须尽可能提高算力利用率。为了压榨每张显卡的价值基础设施团队通常会采用多租户超卖调度Over-subscription将离线数据清洗、算法评估、LoRA 批量微调以及研发人员的交互式 Notebook 任务混部在同一个大型 GPU 资源池中。在平峰期这种超卖机制能够将整体 GPU 利用率从 30% 提升至 75% 以上。然而一旦进入大促峰值阶段如果多租户治理体系缺乏刚性的优先级隔离和秒级抢占机制超卖就会演变成一场灾难当线上核心推理服务因突发洪峰急需弹性扩容 32 张 GPU 时发现集群中所有显卡都被低优先级的离线训练任务占满更糟糕的是如果调度器没有实现针对分布式任务的整体驱逐与弹性配额借还Borrow Reclaim零散杀掉几个训练 Pod 不仅无法凑出完整的 8 卡 NVLink 拓扑还会导致整个算法团队的离线作业陷入重试风暴。为了在大促期间实现“日常极致超卖、战时秒级归还”必须基于 CNCF Volcano 批调度器与 Kubernetes PriorityClass构建多租户层级队列Hierarchical Queues与多卡拓扑感知紧急抢占体系。[多租户 GPU 混合资源池 (A100 / H800)] │ ┌───────────────────────┴───────────────────────┐ ▼ ▼ [日常平峰阶段: 弹性超卖模式] [大促战时阶段: 紧急抢占模式] - 核心推理队列 (Guarantee: 40, Limit: 64) - 线上推理突发扩容申请 32 卡 - 离线微调队列借用空闲算力 (使用量: 80) - Volcano 触发弹性配额强行收回 (Reclaim) - 整体 GPU 综合利用率 80% - 秒级优雅驱逐离线 Job释放整机拓扑 │ │ └───────────────────────┬───────────────────────┘ ▼ [Volcano 批调度引擎: 插件化执行链路] 1. drf (主资源公平分配算法) 2. priority (基于 PriorityClass 抢占判定) 3. gang (满足整组任务 Coscheduling 最小拓扑)Volcano 层级队列与弹性配额定义Capacity GuaranteeVolcano 的核心优势在于引入了Guarantee保障配额、Limit最大上限以及Reclaimable可回收的弹性配额模型。在大促期间我们为在线核心业务和离线训练分别划分独立的 Queue# 1. 大促核心在线推理专用队列 (强保障、高权重、随时可回收借出资源) apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: promo-online-queue spec: weight: 100 reclaimable: true guarantee: resource: nvidia.com/gpu: 128 # 硬性保障 128 张 GPU capability: resource: nvidia.com/gpu: 192 # 允许最大超发至 192 张 --- # 2. 离线算法研发与微调队列 (低权重、无保障、允许借用空闲、随时被抢占) apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: offline-research-queue spec: weight: 10 reclaimable: true guarantee: resource: nvidia.com/gpu: 0 # 平峰期使用闲置算力无硬性保障 capability: resource: nvidia.com/gpu: 128 # 最多借用 128 张空闲卡生产级 Volcano 调度器配置与抢占插件链在 Volcano Scheduler 的 ConfigMap 中必须正确配置插件链Plugins与执行动作Actions确保抢占Preempt和配额回收Reclaim严格遵循业务优先级apiVersion: v1 kind: ConfigMap metadata: name: volcano-scheduler-configmap namespace: volcano-system data: volcano-scheduler.conf: | actions: allocate, backfill, preempt, reclaim tiers: - plugins: - name: priority # 严格遵循 PriorityClass 数值 - name: gang # 确保分布式任务整组满足避免半死不活 - name: drf # 主资源公平调度 - name: predicates - name: nodeorder分布式离线任务的优雅保存与快速让道当高优先级的大促在线推理 Pod 触发抢占时调度器不能像对待普通无状态容器那样直接发送SIGKILL强杀训练进程否则会导致离线分布式任务数小时的训练中间状态丢失。我们开发了基于 Go 的 Pod 优雅终止与状态保存控制器package preempt import ( context fmt os/exec time corev1 k8s.io/api/core/v1 metav1 k8s.io/apimachinery/pkg/apis/meta/v1 k8s.io/client-go/kubernetes ) type PreemptionManager struct { client kubernetes.Interface } func NewPreemptionManager(client kubernetes.Interface) *PreemptionManager { return PreemptionManager{client: client} } // GracefulEvictBatchJob 在抢占时向离线任务发送保存 Checkpoint 信号并设置 30 秒优雅期 func (m *PreemptionManager) GracefulEvictBatchJob(ctx context.Context, pod *corev1.Pod) error { fmt.Printf(收到大促紧急抢占请求准备驱逐离线 Pod: %s/%s\n, pod.Namespace, pod.Name) // 1. 设置 Pod 优雅终止期限为 30 秒 var gracePeriodSeconds int64 30 eviction : corev1.Binding{ ObjectMeta: metav1.ObjectMeta{ Name: pod.Name, Namespace: pod.Namespace, }, } // 2. 调用 Kubernetes Eviction API 触发 Pod 内部 preStop 钩子 err : m.client.CoreV1().Pods(pod.Namespace).Delete(ctx, pod.Name, metav1.DeleteOptions{ GracePeriodSeconds: gracePeriodSeconds, }) if err ! nil { return fmt.Errorf(触发优雅驱逐失败: %w, err) } return nil }大促抢占演练的验收标准在大促封网前组织的多租户抢占演练中平台必须验证以下三项硬指标抢占时延达标当在线推理突发申请 64 张 GPU 时Volcano 控制器必须在 15 秒内完成配额回收与离线任务驱逐30 秒内完成在线 Pod 的全量拉起与就绪拓扑不碎片化被抢占出来的 GPU 节点必须是完整的整机8 卡NVLink 拓扑严禁出现将多个离线 Pod 的残余卡拼凑给在线服务的现象离线任务自愈挂起被驱逐的离线训练 Job 必须自动进入Pending/Suspended状态待大促峰值过去、在线配额释放后自动恢复断点续训。
