算力调度系统设计计费、配额与抢占策略——Kubernetes与Slurm集群调度实践算力池多租户混布时调度系统需要同时解决三件事资源按量计费、配额防超卖、抢占保高优。本文围绕 Kubernetes v1.28 与 Slurm 23.02 的调度扩展拆解计费、配额与抢占策略的工程实现包含 ResourceQuota、PriorityClass、Prometheus 计量和 QoS 抢占等具体参数适合需要自建训练平台或共享 GPU 资源池的工程师参考。1. 背景与痛点算力池的账单失真与抢占无序混合负载下的 GPU 资源池通常承载三类任务在线推理、离线训练和交互式开发。在线推理需要低尾部延迟离线训练偏好大吞吐和高显存占用交互开发则表现为碎片化、短周期。如果只按 Kubernetes 的 requests 分配而不按实际使用量计费用户会倾向于调大 requests 锁定资源导致节点出现大量“已预留但未使用”的缺口。工程上通常以“计费粒度”和“抢占粒度”区分计费需要贴近实际用量抢占需要明确的优先级与预算边界。百卡级资源池进入多团队共享后以下三个问题会快速暴露计费失真Pod 申请 16 核但实际平均使用 4 核按申请计费会抑制共享按用量计费又可能低估预留成本配额刚性Namespace 配额一次性锁定无法在空闲时段释放给其他租户抢占无序低优先级任务被随机驱逐可能引发数据重算或在线服务闪断这些问题在 Kubernetes v1.28 与 Slurm 23.02 中都有对应机制但需要组合使用而不是依赖单一调度器默认行为。2. 计费与配额基于 ResourceQuota 和 Prometheus 的双轨计量计费系统建议同时维护两条轨道申请值计费和实际使用值计费。申请值来自 Kubernetes Scheduler 的 requests实际值来自 Prometheus 采样。关键参数Prometheus 采样周期建议 15s–60s。小于 15s 会增加时序库压力大于 60s 会放大短任务账单偏差。计量数据流可概括为cAdvisor 暴露容器指标 → Prometheus 抓取 → PromQL 聚合 → 对象存储或数仓持久化 → 账单服务计算。账单公式如下费用 Σ(资源类型 × 计量值 × 单价 × 时长)其中 CPU 按核秒、GPU 按卡秒、内存按 GiB 秒。配额层面建议在 Namespace 上同时配置 ResourceQuota 与 LimitRange防止单容器绕过配额。下面是 team-a 的 GPU 配额示例apiVersion:v1kind:ResourceQuotametadata:name:team-a-gpunamespace:team-aspec:hard:requests.cpu:64requests.memory:256Girequests.nvidia.com/gpu:16limits.cpu:128limits.memory:512Gilimits.nvidia.com/gpu:32在动态配额场景中可接入 Kubernetes Scheduler 扩展点或自定义控制器根据闲时利用率调整配额。CPU 超卖比例可设置在 1.0–1.2 之间GPU 通常不建议超卖。避坑提示如果只记录 Prometheus 指标而不做账单持久化TSDB 数据到期后账单无法追溯。建议将小时级聚合结果写入对象存储或数仓。3. 抢占策略PriorityClass 与 Slurm preempt/qosKubernetes 侧通过 PriorityClass 定义优先级数值调度器在资源不足时驱逐低优先级 Pod。下面定义三个档位中的高优先档apiVersion:scheduling.k8s.io/v1kind:PriorityClassmetadata:name:high-priorityvalue:10000globalDefault:falsepreemptionPolicy:PreemptLowerPriorityPod 通过priorityClassName: high-priority声明后高优任务可触发抢占。为了防止重要服务被同时驱逐需配置 PodDisruptionBudgetPDB限制同一时间最大不可用副本数apiVersion:policy/v1kind:PodDisruptionBudgetmetadata:name:inference-pdbspec:minAvailable:2selector:matchLabels:app:inference优先级建议分档1000交互开发、5000离线训练、10000在线推理与紧急任务。分数过近容易因同分产生非预期抢占分数过远则可能使低优任务被大面积驱逐。Slurm 侧使用 QoS 抢占示例 slurm.confPriorityTypepriority/multifactor PreemptTypepreempt/qos PreemptModerequeue JobAcctGatherTypejobacct_gather/linuxPreemptModerequeue表示低优作业被抢占后重新排队而非直接取消适合可断点续跑的训练任务对不可中断任务可设置PreemptModecancel。避坑提示调度器执行抢占时会删除 Pod但不等待应用保存状态。需要配合terminationGracePeriodSeconds: 60给 checkpoint 或请求收尾留出时间。4. 对比分析与落地建议Kubernetes 与 Slurm 策略选型下表对比 Kubernetes 扩展方案与 Slurm/HPC 调度器在计费、配额、抢占三个维度上的差异维度Kubernetes 扩展Slurm/HPC 调度器计费粒度容器级依赖 Prometheus 采样与账单聚合作业级sacct 直接输出记账数据配额模型Namespace ResourceQuota / LimitRangeAccount QoS Partition抢占策略PriorityClass PDBPreemptTypepreempt/qos支持 requeue/cancel调度延迟秒级到分钟级受调度器吞吐影响作业级回填大规模 HPC 下更稳定多租户隔离细粒度需配合网络策略依赖账户与分区租户粒度较粗落地建议上的参数参考配置项建议区间说明Prometheus 采样周期15s–60s短周期提升精度但增加存储压力CPU 超卖比例1.0–1.2参考集群实际利用率调整GPU 超卖不超卖显存与计算单元抢占成本较高优先级分档1000 / 5000 / 10000档位间隔避免过近优雅终止时间30s–120s配合 checkpoint 与请求收尾实践建议小规模混合负载优先用 Kubernetes 原生 ResourceQuota PriorityClass减少组件数量大规模 HPC 或批处理可保留 Slurm 的 QoS 记账能力通过容器运行环境桥接。避坑小结不要只按 requests 计费否则会鼓励资源锁定不要在没有 PDB 的情况下启用激进抢占避免在线服务闪断不要用 Prometheus 长期保存账单明细账单数据需要离线持久化不要忽略 MIG/MPS 场景下的 GPU 计费粒度需按实例大小折算算力调度系统的计费、配额与抢占不是孤立模块而是围绕资源使用成本和任务优先级的一组耦合策略。工程落地时建议先确定计量粒度再配置配额边界最后引入分级抢占并用 PDB 保护关键服务。数据来源说明本文技术参数基于 Kubernetes v1.28 与 Slurm 23.02 官方文档、CNCF 公开调度器讨论及行业公开资料整理不包含生产环境私有数据。