调度系统概述：调度器作用、调度策略分类、调度性能指标
在大规模 GPU 集群中，调度器是连接“资源供给”与“作业需求”的核心控制平面组件。它并非简单地“把任务放到某台机器上”，而是要在数万张 GPU、数千个节点、多种异构资源（显存、算力、网络带宽、存储 IO）以及不断到达的作业流之间，持续做出全局最优的分配决策。理解调度器的职责边界、策略分类与性能度量方式，是后续深入优化调度算法的基础。
调度器的核心作用
调度器本质上是一个资源匹配与决策引擎。它维护集群的实时资源视图，接收用户提交的作业请求，并根据预设策略决定：作业何时开始运行、运行在哪些节点上、分配多少 GPU 与 CPU 资源、以何种顺序执行。其作用可以拆解为四个层面：
- 资源抽象与视图维护：将物理节点上的 GPU、显存、CPU、内存等资源抽象为可量化的资源模型，并持续跟踪空闲量、已分配量、预留量。例如，一张 A100 80GB 的 GPU 可被抽象为“1 个计算单元 + 80GB 显存”，调度器需要实时感知其分配状态。
- 作业排队与优先级管理：当作业请求的资源总量超过集群可用容量时，调度器需要维护一个等待队列，并根据优先级、公平性、用户配额等策略决定出队顺序。
- 放置决策（Placement）：为选中的作业选择具体的节点和 GPU 集合。这一决策需要考虑数据 locality（如训练数据是否已在节点本地缓存）、网络拓扑（如是否需要在同一交换机下以利用 NVLink 或 RDMA）、资源碎片化程度等因素。
- 生命周期管理：包括作业启动时的资源预留与绑定、运行过程中的资源监控与抢占处理、结束后的资源回收与状态更新。
一个典型的调度决策流程可以概括为：
作业提交 → 合法性校验 → 资源需求解析（GPU数/显存/约束条件）
→ 入队等待 → 调度周期触发（事件驱动或周期扫描）
→ 过滤（Filtering）：剔除不满足约束的节点
→ 打分（Scoring）：对候选节点按策略排序
→ 绑定（Binding）：选定节点与GPU实例
→ 资源预留 → 通知执行器启动作业调度策略分类
调度策略决定了“在众多可行方案中，选择哪一个”。不同策略在集群利用率、作业延迟、公平性之间做出不同的权衡。可以从两个维度进行分类：决策时机与优化目标。
按决策时机分类
| 类型 | 特点 | 典型场景 |
|---|---|---|
| 在线调度（即时调度） | 作业到达后立即尝试分配资源，若资源不足则排队等待 | 交互式任务、开发调试、小规模推理服务 |
| 批量调度（周期调度） | 以固定时间窗口（如每 30 秒）收集一批作业，统一决策 | 大规模训练任务、离线批处理作业 |
| 抢占式调度 | 高优先级作业可抢占低优先级作业已占用的资源 | 混部场景、在线推理与离线训练共存 |
按优化目标分类
- 利用率优先：以最大化 GPU 平均利用率为目标，倾向于将作业紧密打包到少量节点上，减少碎片。典型算法如 Bin Packing（最佳适应递减）。
- 延迟优先：以最小化作业排队时间为目标，倾向于为作业预留充足资源，避免等待。适用于 SLA 敏感的推理任务。
- 公平性优先：确保多个用户或团队之间获得与其配额成比例的资源。典型算法如 Dominant Resource Fairness（DRF），按主导资源份额进行公平分配。
- 拓扑感知：优先将作业分配到满足数据并行通信需求的拓扑位置（如同一个 NVSwitch 域内），减少跨交换机流量。
实践提示：生产级调度器（如 Kubernetes + GPU 插件、Slurm、Volcano、Torque）通常不是采用单一策略，而是采用多级策略组合。例如，先通过优先级过滤出候选作业集合，再通过公平性策略调整队列顺序，最后通过拓扑感知策略完成节点选择。
调度性能指标
衡量调度系统好坏不能只看“调度速度”，需要从系统效率与用户体验两个维度建立指标体系。以下是核心指标：
| 指标名称 | 定义 | 影响 |
|---|---|---|
| 调度延迟（Scheduling Latency） | 从作业进入待调度队列到完成资源绑定的时间 | 影响作业启动速度，对短任务影响显著 |
| 吞吐量（Throughput） | 单位时间内成功调度的作业数量 | 反映调度器处理大规模作业流的能力 |
| 集群资源利用率（Utilization） | GPU 实际运行时间 / 总可用时间 | 直接决定集群 ROI，利用率过低意味着资源浪费 |
| 作业排队时间（Queueing Delay） | 作业提交到开始执行之间的等待时长 | 影响用户体验与 SLA 达成率 |
| 调度成功率 | 成功完成资源分配的作业数 / 总提交作业数 | 反映调度器对复杂约束的处理能力 |
| 资源碎片率 | 无法被分配的零散 GPU 数量 / 总 GPU 数量 | 碎片率过高会导致“有卡但不能用”的假性不足 |
在实际运维中，还需要关注调度器自身的资源开销（CPU 与内存占用）以及调度决策的扩展性——当集群规模从 100 节点扩展到 10000 节点时，调度器的决策时间是否呈线性增长。若调度器成为瓶颈，即使集群有充足资源，作业也无法及时启动。
典型场景与案例分析
以某互联网公司的大规模训练集群为例，集群包含 2000 个节点，每个节点 8 张 A100 GPU，总计 16000 张 GPU。日常运行三类作业：
- 在线推理服务：延迟敏感，需要秒级启动，资源需求稳定。
- 周期性训练任务：每天固定时间提交，资源需求大（数百张 GPU），运行数小时。
- 临时探索性实验：数据科学家提交的小规模调试任务，资源需求小，但数量多。
初期采用简单的 FIFO + 首次适应（First Fit）策略，结果出现严重问题：
- 大训练任务到达后，由于资源不足而长时间排队，但集群中却存在大量碎片化 GPU（每个节点剩余 1-2 张），无法满足大任务需求。
- 在线推理服务与训练任务混部时，推理服务因资源被抢占而频繁超时。
- 调度器扫描 2000 个节点进行资源匹配耗时过长，平均调度延迟达到 15 秒。
优化后的方案采用了分层调度架构：
第一层：作业队列管理（按优先级 + 公平性配额）
第二层：节点过滤（基于资源量、标签、拓扑域）
第三层：节点打分（综合利用率提升 + 拓扑亲和 + 数据本地性）
第四层：GPU 分配（按显存大小与算力匹配）同时引入增量调度机制，仅对状态变化的节点重新计算，将调度延迟从 15 秒降至 800 毫秒。对于推理服务，设置独立的优先级队列并启用资源预留池，确保 P99 延迟稳定。
常见误区与复盘
误区一：追求 100% 利用率。将 GPU 利用率作为唯一目标会导致作业被过度打包，引发显存溢出、PCIe 带宽争抢、训练性能下降。利用率应结合作业性能衰减曲线综合评估，通常 85%-92% 是健康区间。
误区二：忽略调度器自身的扩展性。当集群规模增长时，若调度器采用全量节点扫描，决策时间会线性恶化。应使用分而治之的层级过滤、缓存资源视图、异步事件驱动等机制。
误区三：抢占策略过于激进。无条件抢占低优先级作业可能导致“惊群效应”——被抢占的作业反复重启，反而降低整体吞吐。应设置最小运行时间保护（如运行超过 10 分钟的作业不可被抢占），并限制同一时刻的抢占数量。
另一个常见问题是资源需求预估不准确。用户往往高估 GPU 需求（例如申请 8 张卡但实际只用 4 张），导致调度器过度预留。解决方法是引入弹性调度——允许作业在运行过程中动态调整资源，或通过历史数据训练资源预估模型。
调度系统是集群的“大脑”，其设计质量直接决定了大规模 GPU 集群能否在复杂多变的负载下保持高效、稳定、公平的运行。理解调度器的作用边界、策略选择依据与性能度量方法，是后续进行调度参数调优、算法定制与故障排查的前提。