题目重点：依据 Netflix VO1 逐项列出的 ML 调度追问，拆解训练、批量推断和评估任务的不同 SLA、GPU 配额、租户公平、worker heartbeat 与恢复。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版允许用户提交带 CPU/GPU/内存、预计时长、优先级、租户、镜像和输入输出位置的 job；题目未公开 API。
- 训练任务可 checkpoint 续跑，batch inference 可分片重试，零散 eval 追求较短排队时间；具体 SLA 和抢占规则由业务确认。
- 状态存储可持久化且任务执行至少一次，job 输出必须幂等或带 attempt id；不能默认恰好一次。
解题路线
- 先按任务类型定目标：training 可能占用多 GPU 长时运行并需 checkpoint；batch inference 可切成很多独立 shard；eval 可能短任务但延迟敏感。调度队列保存资源需求、截止期、优先级与租户，不用一套 FIFO 解决全部目标。
- 资源管理器从 worker heartbeat/设备指标维护可用 GPU 型号、显存、CPU/内存和故障状态。调度器从待运行队列挑出满足资源约束的任务，按租户配额或 dominant-resource fairness 给份额，再对同租户按优先级/等待时间排序；大训练任务可能需 gang scheduling，避免只分到部分 GPU 卡住。
- 通过 lease 将 job attempt 分配给 worker，状态机 `queued→reserved→running→succeeded/failed/retry` 写入持久存储；worker 心跳失效先等待租约超时，再释放资源并重试。checkpoint 与幂等输出防重复 attempt 污染结果。
- 监控排队时长、GPU 利用率、任务失败/重试率、checkpoint 恢复耗时与租户份额。控制面主备或 leader election、资源状态重建、消息重复处理和存储不可用时停止新分配都要有明确降级。
手动走一遍
训练例租户 A 提交 8 GPU 的长训练，租户 B 提交数十个短 eval。若只按提交顺序 FIFO，B 会等待过久；按租户最低保障和资源可用性保留少量 GPU 给 B，同时 A 的 8 GPU 作 gang 分配。A 的 worker 崩溃后租约到期，新的 attempt 从最近 checkpoint 恢复，旧 attempt 的迟到成功回报要被 fencing token 拒绝。
规模与取舍
J 个待调度任务、W 个 worker 的直接匹配扫描可到 O(JW)，需按资源类型与租户建立索引/队列降低候选量；资源碎片和公平性是实际瓶颈。checkpoint 频率越高恢复损失越少，但 I/O 与存储成本越高；长任务抢占可能浪费已完成计算。
易错点与追问
容易失分的边界
- 把 training、batch inference、eval 当成完全相同的短任务 FIFO。
- 只看 GPU 数量，不看型号、显存、拓扑与 gang 约束。
- worker 消失就立即重复运行，却没有 lease、fencing 与幂等输出。
- 跨租户只用全局优先级，导致某租户长期饥饿。
- 只给正常路径，无 crash handling 和资源监控。
继续深挖
- 如何在公平与 GPU 利用率之间做 backfill？
- 长训练可被抢占时怎样选 checkpoint 周期？
- 多 GPU 跨机器训练如何减少网络瓶颈？
- 一个租户提交海量短任务时如何限制控制面压力？
