AWS Batch 为共享 GPU 增加配额调度
AWS Batch 为 SageMaker 训练任务增加配额管理，可按团队或工作负载划分 GPU 容量，并选择保留、出借或借入空闲资源。跨配额抢占支持收回借出容量，配额内抢占则让高优先级任务更早启动。
AI 深度解读
多支团队共用 GPU，难点不只在排队：给每队留死额度容易闲置，允许互相借用，又得解决资源何时归还。AWS Batch 新增的 quota management，试图把容量分配、闲时借用和任务抢占放进同一套调度规则。
作者转述了 AWS 的机制与演示：团队可以保留自己的容量，也可以出借空闲容量，等自己的任务到来时再收回。它值得关注的地方，是把共享资源的边界提前写成策略；但能否接受任务中断，仍然取决于训练任务自身。
GPU 份额既能保底，也能互相借用
AWS Batch 已经支持 SageMaker Training 作业的排队、调度和重试。此次增加的 quota management，则进一步处理多个团队、项目或工作负载之间的容量分配。
管理员把 GPU 容量划成多个 quota share，每个份额都有容量上限，并选择一种空闲处理策略：
RESERVE：容量留给自己，即使暂时没有任务也不出借。LEND：自己用不上的容量，可以借给其他有任务等待的份额。LEND_AND_BORROW：空闲时出借，需要更多容量时也能借入。
每个份额相当于作业队列内部的一条虚拟队列，调度器会优先照顾尚未达到容量上限的份额。
借用也有归还机制。某个份额把容量借出去之后，如果自己的任务到来，AWS Batch 会执行跨份额抢占（cross-share preemption），收回已出借的容量，不需要管理员逐个寻找借用中的任务。
借到的容量可以提高利用率，但不能被当成持续可用的保障。
紧急任务能插队，代价是其他任务可能中断
跨份额抢占解决资源归属，份额内抢占（in-share preemption）解决同一份额中的任务先后顺序。
开启份额内抢占后，处于已调度、启动中或运行中状态的低优先级任务，都可能被抢占，让队首的高优先级任务更早启动。新增的 UpdateServiceJob API 还允许研究人员提高已提交作业的优先级。
AWS 的演示建立了三个份额，每个容量上限都是一台 ml.g5.xlarge：
| 份额用途 | 空闲策略 | 份额内抢占 | 适合的任务 |
|---|---|---|---|
| 后台工作 | LEND_AND_BORROW |
开启 | 支持检查点、能容忍中断的任务 |
| 中等优先级工作 | LEND |
关闭 | 宁愿等待，也不想反复被抢占的任务 |
| 保留容量工作 | RESERVE |
原文未单独说明开关 | 需要保留容量的任务 |
演示中，后台任务先借用了中等优先级份额的空闲实例。中等优先级份额收到新任务后，容量从后台份额收回。随后，提高一个等待中作业的优先级，又触发了同一份额内部对运行中作业的抢占。
原文还指出，只保留容量的份额，在上限不变时，其作业不会被抢占。这里的条件要一起看，不能扩大理解为任何配置变更下都不会中断。
接入需要把队列、策略和容量约束连起来
配置并非只给任务增加一个优先级字段，而是涉及几层关联：
- 创建包含 quota share policy 的 scheduling policy。
- 创建 service environment，按具体实例定义容量约束。
- 将 SageMaker Training 作业队列同时关联上述策略和环境，再把 quota shares 挂到队列上。
任务通过 SageMaker Python SDK v3 的 aws_batch 模块提交。原文提到用户指南提供 CLI 和控制台示例，但没有给出具体命令或完整配置，不能据此直接复现。
该能力也支持 SageMaker AI training plans，让预留容量可以在多个团队之间共享。原文没有提供共享后的利用率、等待时间或成本变化数据。
我的判断
这套设计合理的地方，是把「谁能借、借了何时归还、谁能被中断」变成明确规则。相比固定切分容量，它允许闲置资源流动；相比完全依赖任务优先级，它又保留了团队份额的边界。
前提也很明确：后台训练要能承受抢占。检查点（checkpoint）就是把训练进度保存下来，方便中断后继续；但保存多频繁、恢复多耗时、被中断后会损失多少计算，原文都没有交代。
AWS 给出的演示证明了调度行为，没有证明整体收益。缺少对照数据，就不能把它写成降低训练成本或缩短整体排队时间的实测结论。对于任务数量不多、资源归属简单的团队，固定容量加普通排队仍可能更容易管理。
对前端和全栈读者，这也不是给普通 Node 服务增加弹性的方案。它面向 SageMaker Training；只有工作涉及训练任务提交、管理或共享 GPU 平台时，才有直接落地点。
能拿来做什么
- 如果团队已经通过 SageMaker Training 共用 GPU，可以先按任务能否中断分类，再决定使用
RESERVE、LEND还是LEND_AND_BORROW，不要只按部门机械分配。 - 如果要把后台训练放进可抢占份额，先验证检查点保存和恢复流程，并记录一次中断造成的进度损失，再评估借用容量是否划算。
- 如果在开发训练任务管理界面，可以考虑接入
UpdateServiceJob调整已提交任务的优先级，同时明确提示用户：开启份额内抢占后，提高优先级可能中断其他任务。 - 试用时同时记录容量利用率、任务等待时间和抢占后的恢复开销，用自己的工作负载判断收益，避免只看空闲 GPU 是否被用满。