Amazon SageMaker 实例偏好列表取代手动 GPU 重试，但无法取代容量规划
Amazon 推出了 Amazon SageMaker 实例偏好列表，允许单个训练请求包含最多五种按优先级排序的计算选项，而非固定指定一种实例类型。SageMaker AI 会按优先级检查这些选项，并启动第一个具备可用容量的配置。
这项改动针对的是一个长期存在的运维难题。当所需硬件不可用时，基于 GPU 的 SageMaker 训练任务可能会持续处于等待状态。团队此前通常只能监控容量、重新提交任务，或维护尝试替代配置的脚本。
AWS 现在将这一重试决策移入托管调度器。不过，该功能不会凭空增加 GPU 容量，也不能证明不同加速器能够正确运行某项工作负载。其价值取决于团队能否真正让训练代码、性能目标和成本控制适应不同硬件。
这一差异给一种常见的云实践带来了压力：将实例类型视为每项任务的固定属性。Google Cloud 已通过其 Dynamic Workload Scheduler 对灵活的加速器请求进行排队。Azure Machine Learning 用户同样需要围绕区域和实例系列特定的计算配额进行规划。AWS 如今正将声明式硬件灵活性变为单个 SageMaker 任务的一等组成部分。
AWS 通过 Amazon SageMaker 实例偏好列表做出了哪些改变
单个 SageMaker 请求现在可以表达多个可接受的计算配置，无需外部重试控制器。
AWS 于 2026 年 9 月 15 日宣布了这项功能，同时适用于训练和处理任务。根据该公司的区域可用性公告，该功能可通过 SageMaker API、SDK、命令行工具和控制台使用，并已在所有提供 SageMaker AI 的 AWS 区域上线。
一个偏好列表包含两到五种按优先级排序的实例类型。SageMaker 会验证列表、执行内存中的扫描，并选择第一个具有可用容量的配置。一个任务只会运行所列配置中的一种。
如果没有任何选项可以立即使用，任务将进入事件驱动队列。SageMaker 会随着容量变化进行重试，而无需客户端进程轮询服务并重新提交请求。总等待时间可以通过 MaxPendingTimeInSeconds 限制。
该超时适用于整个偏好列表，而非分别适用于每个选项。AWS 还表示，只有在至少一个所列配置使用了 ml.p、ml.g 或 ml.trn 等系列的加速计算时，该超时才会生效。
这一行为很重要，因为偏好项不仅仅是另一个实例名称。团队可以为每个选项分配不同的实例数量。例如，一个任务可能优先使用两个 ml.g6.48xlarge 节点，但在第二种配置仍能提供足够聚合吞吐量时，接受四个 ml.g5.48xlarge 节点。
AWS 支持两种数量模型。共享的 ResourceConfig.InstanceCount 可以应用于所有偏好项，或者每个偏好项都可以定义自己的数量。正如 API 参考文档所述，混用这两种方式无效。
该功能还可与 SageMaker Flexible Training Plans 配合使用，后者可在指定期限内预留受支持的 GPU 容量。训练任务可以先放置一个与计划匹配、由计划支持的配置，然后列出按需替代方案。如果预留选项无法完成资源配置，SageMaker 将继续依次尝试其余偏好项。
这种集成仅限训练任务。处理任务获得相同的有序回退机制，但无法将偏好项与 Flexible Training Plans 关联。
处理场景仍然意义重大。SageMaker Processing 为数据准备、特征工程、评估及相关工作运行托管基础设施。与经过严格优化的分布式训练任务相比，这些任务通常能容忍更广泛的硬件范围。
AWS 在其发布文章中将这一改动定位为手动重试循环和容量监控脚本的替代方案。这是最直接、最清晰的收益。一个流水线只需提交一个任务，而 SageMaker 会在声明的边界内负责搜索容量。
调度器不会自行挑选一台它认为等效的任意机器，而是遵循客户指定的顺序。这保留了有用的责任划分：运维人员决定哪些配置有效，SageMaker 决定哪个有效选项可以最先启动。
这是一次小型 API 改动，却带来更大的运维影响。基础设施灵活性现在可以随任务定义一同传递，而非存在于外围编排代码中。
为什么 SageMaker GPU 容量成为调度问题
稀缺资源不再只是 GPU，而是在正确区域、正确时刻获得正确的集群配置。
AI 训练团队常将加速器视为可互换单元，但云容量分布在不同实例系列、规格、区域、可用容量池、配额和预留模式之间。客户可能有权请求某台机器，但这不代表机器能立即被分配。
这种碎片化带来了棘手的故障处理问题。一个流水线在技术上可能完全正确，却仍可能因选定配置无法启动而损失数小时。随后，工程师必须决定是等待、更换硬件、调整节点数量，还是迁移工作负载。
在偏好列表出现前，SageMaker 训练任务在提交时只能指定一种实例类型。接受替代方案的团队必须在其他地方编码这种灵活性。有些团队围绕 API 失败构建重试函数，另一些则提交多个变体，并在其中一个启动后取消其余任务。
这两种模式都会带来协调工作。多个活跃请求可能使可观测性和取消操作更加复杂。顺序重试脚本则需要状态管理、退避规则、超时处理、权限管理，以及防止重复执行的保护机制。
容量监控也会变成另一套生产系统。团队必须在 SDK 行为变化时维护它、暴露其故障，并确保重启后的控制器不会重复启动同一项昂贵任务。
Amazon SageMaker 实例偏好列表吸收了其中一部分控制平面功能。任务请求携带一组受限的可接受结果，而托管服务会在找到容量后做出选择。
这一模型反映了许多真实工作负载的行为方式。微调、评估、预处理和模型实验通常有首选配置，而非某种数学上必须的唯一配置。团队可能偏好更新的 GPU 以获得速度，但当启动时间更重要时，也可以接受较旧的 GPU。
相同原则也适用于节点数量。两个更快的节点和四个更慢的节点有时可以实现相近的完成目标。它们并非天然等效，但开发者可以对其进行测试，并声明两者均可接受。
AWS 并非唯一将稀缺性转化为调度接口的云厂商。Google Cloud 的 Flex-start 模式会将加速器请求排队，直至所有必需资源均可用。Google 将其定位为适合能够容忍灵活启动时间的训练任务。
两者的机制不同。Google 的模式强调满足所请求的加速器分配和使用时长；AWS 则允许一个 SageMaker 任务在按顺序排列的实例类型和数量集合中切换。这两种方法都要求客户表达灵活性，而不是反复探测容量。
Azure Machine Learning 则揭示了约束的另一部分。其计算配额按区域和 VM 系列进行管理，并对工作区和订阅使用设置了不同限制。取决于订阅类型，GPU 系列一开始可能没有默认的专用核心配额。
这些系统说明，加速器可用性不能被简化为一张产品目录页面。某个列出的实例可能受支持，却不一定能在特定账户、地点、任务规模或时间窗口中使用。
对于 AWS 客户而言，直接压力将落在维护自定义资源配置逻辑的团队身上。如果某项重试服务只是在 SageMaker 实例类型之间轮换，其核心功能如今已与平台能力重叠。
该功能也给那些每个模型只批准一种实例类型的僵化内部标准带来压力。这些标准简化了基准测试和治理，却会让每一次容量短缺都成为阻塞因素。团队现在有理由为每项工作负载认证多种配置。
这并不意味着编排将被消除。流水线仍需要依赖关系、制品跟踪、故障策略和运行后验证。这项改动通过将一个反复出现的决策——哪种可接受配置能够启动——移入 SageMaker 本身，缩小了编排的职责范围。
灵活性取代重试逻辑，而非容量约束
这一机制改善了对可用基础设施的搜索，但无法提供并不存在的基础设施。
当任务到达时，SageMaker 会根据受支持资源和限制验证其配置及偏好列表。随后，调度器会按声明顺序检查各个选项。第一个可用选项将胜出并开始配置资源。
如果所有选项都不可用，事件驱动队列会等待相关容量发生变化。这比客户持续轮询更高效，但它仍然是一个队列。任务可能持续处于等待状态，直到超时。
在评估 AWS 关于该功能可帮助任务更快启动的说法时，这一边界很重要。其比较对象是固定在单一不可用配置上的任务，或较慢的客户自管重试系统。AWS 尚未发布独立基准测试，以展示不同区域、实例系列或集群规模下中位启动时间的改善情况。
一个列表也不会组合来自多个条目的部分容量。如果某个偏好项请求八个节点，SageMaker 必须能够配置这一选定配置。系统会选择一个完整的偏好项，而不是用可用碎片拼装异构集群。
这使实例偏好项区别于 SageMaker 异构集群。异构集群会在一个训练任务中有意运行多个实例组；偏好列表则代表互斥的替代方案，其中只有一个会成为任务的计算环境。
这种区别保障了执行一致性。分布式训练框架通常期望任务启动后拥有已知的拓扑结构。选择一种预定义配置，比动态混合硬件架构、网络特性和内存配置文件更简单。
Training Plan 集成增加了另一层决策。一个偏好项可以指向匹配的预留计划，而后续条目使用按需容量。当运维人员将预留选项放在首位时，AWS 会优先评估该预留选项。
这一机制让组织能够直接优先使用预付费容量，而不将其设为任务唯一可走的路径。不过，回退方案可能改变最终的经济结果。按需替代方案的实际成本可能不同，而更大的节点数量会放大这种差异。
该功能似乎也并非用于取代 Managed Spot Training。Managed Spot Training 通过使用可中断的 EC2 Spot 容量来应对另一种权衡。AWS 表示，这种方法可以降低计算成本，但中断可能延长完成时间，并要求使用检查点机制。
实例偏好主要解决的是在可接受配置中进行初始容量选择。Spot 训练则是在工作负载获得计算资源后，处理购买模式和中断风险。团队必须分别评估这两个维度。
因此，最适合的场景是对重启敏感、但硬件适配较灵活的任务。例如，一个夜间评估流水线可在多个 GPU 世代上运行。错过早晨的报告窗口会带来影响，但并不一定非要使用绝对最快的加速器。
团队可以认证多种配置，按完成时间与预期成本之间的理想平衡进行排序，然后设置最长等待时间。SageMaker 会在这一经过测试的范围内进行选择。
大规模预训练任务则更具挑战性。其通信模式、内存需求、检查点行为和拓扑结构可能围绕某一种加速器及互连方案进行了调优。名义上受支持的回退方案，可能让任务变慢、成本更高或变得不稳定。
新调度器无法判断这种回退在科学或经济层面是否仍然有效。这项判断仍由工作负载所有者负责。
因此，Amazon SageMaker 实例偏好列表是声明式的，而非广义上的自适应。SageMaker 会响应容量信号，但不会为模型进行基准测试、重写分布式设置，或根据截止时间优化列表。
这仍然很有意义。当托管服务从每位客户手中接过一项重复且边界清晰的责任，并将其一次性实现时，就能创造价值。容量回退正符合这一模式，前提是客户提供真实的兼容性边界。
兼容性与成本仍由运营方负责
最重要的风险并不是 SageMaker 选择了错误的偏好项；而是团队将不安全的偏好项声明为可接受。
AWS 明确警告，SageMaker 不会验证跨实例类型的兼容性。该服务不会判断容器是否支持每种 GPU 架构、驱动程序是否匹配，或分布式配置是否需要 Elastic Fabric Adapter 网络。
因此，任务可能通过请求验证，却仍在资源配置后失败。这种结果会消耗启动时间，并削弱自动回退的预期收益。
框架行为尤其值得关注。CUDA 功能、集合通信库、混合精度格式、编译器输出和设备特定内核，可能因加速器世代而异。已在 H100 硬件上测试过的容器，不应被默认认为在 A100 或 L40S 硬件上表现完全一致。
内存是另一条边界。即使总体理论吞吐量看起来相近，能容纳于一种加速器上的工作负载，也可能超出另一种设备的显存。增加节点数量并不能自动解决单设备内存限制。
分布式拓扑同样影响性能。将两个高带宽节点替换为四个较慢节点，会改变通信量、同步开销和故障暴露面。相同的 GPU 数量或近似的计算量估算，并不能保证相同的完成时间。
AWS 的示例说明的是意图，而非通用的等价公式。其中一个示例将两个 ml.g6.48xlarge 实例排在四个 ml.g5.48xlarge 实例之前。客户必须自行判断这种关系是否适用于其模型、批次大小、网络模式和软件栈。
团队应使用与生产环境相同的容器镜像、数据路径和分布式启动器，对列表中的每项配置进行基准测试。形成的审批记录应包含运行时间、收敛检查、利用率、故障率和输出验证。
成本策略也需要同样的严谨性。偏好顺序表达的是优先级，而不是预算上限。使用更多实例的回退方案可能更早启动，却比首选方案产生更高的总账单。
反过来，旧硬件的运行时间可能更长，从而抹去表面上的单实例节省。相关衡量标准应是完整的任务结果，包括启动延迟、执行时间、重试、存储，以及对任何下游截止时间的影响。
此次发布也带来了可观测性要求。团队需要记录哪一项偏好最终被选中、任务等待了多久、为何对替代方案进行排序，以及实际性能是否符合基准测试结果。
没有这些记录，自动选择就会变得不透明。工程师可能会看到运行时间或成本出现更大波动，却不知道根本原因是不同运行之间的实例系列发生了变化。
治理规则可能也需要更新。AWS 支持通过身份策略限制 SageMaker 实例类型。组织获批的偏好列表必须符合这些控制措施、账户配额和区域可用性。
预留容量还可能带来另一种误解。Flexible Training Plan 偏好可以提供更强的容量承诺，但回退并不会把不可用的预留容量变成更多的预留供应。它只是将任务转移到另一条单独可接受的按需路径。
处理任务需要单独审查。对于某些转换操作，CPU 回退可能合理，但也可能显著改变完成时间。团队不应仅仅因为 API 允许，就列出 CPU 选项。
缺乏已发布的现场数据，是当前最大的不确定性。AWS 已说明调度流程和配置规则，但客户尚未获得关于不同资源紧缺情况下启动时间改善幅度的广泛证据。
有价值的测量应将该功能与每个团队现有的基线进行比较。这包括从提交到执行的时间、使用回退方案的任务比例、超时率、总计算消耗，以及由配置变化导致的运营事件。
这些测量将揭示 SageMaker GPU 容量灵活性究竟是消除了真正的运维负担，还是仅仅将波动性转移到了一个不那么显眼的层面。
三项信号将显示该功能是否在实践中奏效
是否采用该功能，应以任务结果为标准，而不是看有多少团队在配置中增加了第二种实例类型。
第一项信号是回退频率与启动时间的结合。团队应衡量 SageMaker 选择非首选项的频率，以及这如何改变从提交到启动的延迟。
较高的回退率若伴随更短的等待时间，将支持 AWS 的核心主张。这表明，即使首选类型受到限制，容量仍存在于更广泛的资源池中。
较高的回退率若未带来更短的等待时间，则会削弱这一论点。这可能意味着列出的替代方案共享同一地区瓶颈、请求的集群过大，或事件驱动队列并未实质改善该工作负载的资源满足情况。
第二项信号是不同所选配置之间的性能和成本波动。每次回退都应关联到运行时间、利用率、完成状态和总资源消耗。
稳定的结果将强化将基础设施视为偏好集合的理由。较大偏差则表明，即使每项配置在技术上都能执行该容器，这些替代方案也并不真正等价。
这对于周期性流水线尤为重要。团队可能会接受紧急实验中一次较慢的运行，但不会接受日常生产计划中持续存在的不可预测性。
第三项信号是 AWS 如何扩展该功能及其周边遥测能力。客户应关注更丰富的选择事件、更清晰的等待状态说明、具备成本感知能力的排序工具，以及与流水线控制更广泛的集成。
对更精细策略的支持同样重要。运营方最终可能希望设定诸如截止时间、支出边界，或要求回退吞吐量保持在已验证范围内等约束。当前的有序列表需要手动编码这些判断。
竞争对手的反应可提供辅助背景，但决定性证据将来自客户运营。Google 已通过 Dynamic Workload Scheduler 将加速器稀缺视为调度问题。Azure 则公开了影响托管任务能否运行的配额边界。
AWS 的独特之处在于，直接在 SageMaker 训练或处理请求中放入多种可接受的配置。如果客户能够实现更快启动且不会产生不可接受的波动，这一模式将很难被托管 ML 平台忽视。
短期测试很直接。选择一个硬件适配灵活的工作负载，对每个候选配置进行基准测试，并在启用自动回退前定义最长等待时间。然后，至少将数次运行与旧有的重试流程进行比较。
记录所选实例类型、队列时长、执行时间、完成状态和总资源使用情况。不要将一次成功启动视为全部结果。
Amazon SageMaker 实例偏好列表减少了容量管理中的手动操作，但也要求做好准备。验证过替代方案的团队可以移除脆弱的基础设施代码。填入推测性回退方案的团队，可能只是将发现不兼容性的过程自动化。
真正有用的问题不是五个选项是否优于一个，而是你的组织能否定义五种真正可接受的结果，审慎地为它们排序，并衡量 SageMaker 在其中选择时实际会发生什么。
