训练代码已经准备好，作业却因为首选实例没有容量而启动不了——这类问题往往把工程师拖进“换机型、重提任务、盯容量”的循环。Amazon SageMaker AI 新增的实例偏好列表，将这部分选择逻辑交给服务处理：为训练或处理作业指定最多五种实例类型，按顺序排列，SageMaker AI 会选择列表中第一个有可用容量的类型启动作业。

它解决的是启动时如何选择实例，不是让不同实例的性能、成本和运行环境变得相同。

把单一机型要求改成有顺序的候选列表

过去围绕容量不足编写的脚本，常常承担类似的职责：尝试一个实例类型，失败后换下一个，再重新提交作业。实例偏好列表把这种容量选择从外部脚本移到了 SageMaker AI 内部。

根据发布摘要，可以明确的行为包括：

• 适用于训练作业和处理作业。
• 可以指定一个有序列表，最多包含五种实例类型。
• 服务会选择列表中第一个有可用容量的实例类型启动作业。

这里的“偏好”有实际意义：列表顺序决定选择优先级。把某种实例放在第一位，表示有容量时优先使用它，而不是让服务在所有候选中寻找最低价格或最高性能。

也不要将这个能力理解为运行期间的实例迁移、失败恢复或自动扩缩容；这些行为不在提供的发布摘要中。

候选机型要可替换，不只是名字不同

可以这样实践：先确定作业的硬约束，再给符合条件的实例排序。

例如，不能因为某种实例有容量，就把依赖 GPU 的训练任务改到 CPU 实例上。即使都使用 GPU，显存和设备数量变化也可能影响批大小、并行策略与吞吐量。

一个实用排序方式是：已经验证的首选机型 → 性能和成本可接受的替代机型 → 能满足截止时间的保底机型。不必为了凑满五种而加入未经验证的类型。

可以这样实践：先生成并检查团队的候选配置

提供的摘要没有给出具体 SDK 字段或请求结构，因此下面使用一个本地配置示例，不是 SageMaker API 请求。它可以直接运行，用于检查候选数量、重复项和顺序，再由项目的提交代码映射到官方支持的参数。

运行前，将示例实例类型替换为你已验证、且适合目标作业的类型。脚本只检查列表结构，不检查 AWS 容量、机型有效性或配额。

cat > instance_preferences.py <<'PY'
import json
import sys

types = sys.argv[1:]

if not 1 <= len(types) <= 5:
    raise SystemExit("请提供 1 到 5 个实例类型，按偏好顺序排列。")

if len(types) != len(set(types)):
    raise SystemExit("实例类型不能重复。")

plan = {
    "schema": "local-job-plan-v1",
    "instance_preferences": types,
}

print(json.dumps(plan, indent=2, ensure_ascii=False))
PY

python instance_preferences.py \
  ml.m5.4xlarge \
  ml.m5.8xlarge > job-plan.json

cat job-plan.json

输出中的字段由本地项目自行定义：

{
  "schema": "local-job-plan-v1",
  "instance_preferences": [
    "ml.m5.4xlarge",
    "ml.m5.8xlarge"
  ]
}

接入真实作业时，应查阅当前 SageMaker AI 文档，确认训练或处理作业对应的参数、SDK 版本和功能限制，不要把上述 JSON 直接当作服务请求提交。

建议把这份配置纳入版本管理，并记录每种候选实例的验证结果。这样一次排序调整就是可审查的配置变更，而不是隐藏在重试脚本里的临时决定。

上线时，删掉容量轮询，不要删掉所有容错

实例偏好列表的直接价值，是减少因为实例容量选择而维护的手动重试循环和容量监控脚本。但它并不意味着作业一定能够启动，更不意味着作业启动后一定成功。

采用前可以按下面的清单检查：

• 验证全部候选类型：至少跑一次有代表性的训练或处理任务。
• 设置成本边界：不能只比较小时单价，还要比较完成整个作业的成本。
• 记录实际实例类型：分析运行耗时或结果差异时，需要知道最终用了哪种机型。
• 保留非容量错误处理：权限、配额、镜像、数据路径和程序错误仍需处理。
• 确认列表全部无容量时的行为：发布摘要没有描述该边界，应以当前服务文档为准。

这项功能最适合“有多个经过验证的替代机型，但不想自己维护容量选择逻辑”的团队。把候选范围收紧，把顺序写清楚，才是从“自动换实例”走向可靠作业提交的关键。

SageMaker AI Instance Preference Lists: Choose Available Training Capacity Automatically

A training job can be ready to run and still get stuck because the preferred instance type has no available capacity. Amazon SageMaker AI now offers instance preference lists for training and processing jobs, moving that selection logic into the service.

You can specify up to five instance types in priority order. SageMaker AI launches the job on the first type in the list with available capacity, reducing the need for manual resubmissions and capacity-watching scripts.

The feature addresses instance selection at launch. It does not make different instance types equivalent in performance, cost, or runtime compatibility.

Replace a single choice with an ordered set of alternatives

External retry scripts often try one instance type, switch to another when capacity is unavailable, and submit the job again. Instance preference lists let SageMaker AI handle that capacity-based choice.

The announcement summary establishes three behaviors:

• The feature applies to training and processing jobs.
• Each ordered list can contain up to five instance types.
• The service selects the first listed type with available capacity.

Order matters. Putting an instance first means you prefer it when capacity is available; it does not ask the service to optimize across all candidates for price or performance.

The supplied summary does not describe runtime migration, failure recovery, or autoscaling. Those should not be inferred from this launch-selection feature.

Alternatives must fit the workload

A practical approach is to define hard workload requirements before ranking candidates.

A GPU-dependent training job cannot simply fall back to a CPU instance because one is available. Even switching between GPU instances may require checking device memory, device count, and parallelism settings.

A useful ordering is: validated preferred type → acceptable performance-and-cost alternative → validated deadline-oriented fallback. There is no reason to fill all five slots with untested options.

Practical example: validate a local preference configuration

The supplied summary does not include SDK fields or request schemas. The following is therefore a local project configuration example, not a SageMaker API request.

It checks the number of candidates, rejects duplicates, and preserves priority order. Your submission code can later map the configuration to the officially supported parameters.

Before running it, replace the instance types with candidates validated for your workload. This script does not check AWS capacity, instance validity, or quotas.

cat > instance_preferences.py <<'PY'
import json
import sys

types = sys.argv[1:]

if not 1 <= len(types) <= 5:
    raise SystemExit("Provide 1 to 5 instance types in preference order.")

if len(types) != len(set(types)):
    raise SystemExit("Instance types must not repeat.")

plan = {
    "schema": "local-job-plan-v1",
    "instance_preferences": types,
}

print(json.dumps(plan, indent=2))
PY

python instance_preferences.py \
  ml.m5.4xlarge \
  ml.m5.8xlarge > job-plan.json

cat job-plan.json

The resulting fields are defined by the local project:

{
  "schema": "local-job-plan-v1",
  "instance_preferences": [
    "ml.m5.4xlarge",
    "ml.m5.8xlarge"
  ]
}

For a real integration, consult the current SageMaker AI documentation for the relevant training or processing parameters, SDK version, and feature restrictions. Do not submit this local JSON directly as a service request.

Keep the configuration in version control alongside validation results for each candidate. A change in preference order then becomes a reviewable decision rather than an improvised edit to a retry script.

Remove capacity polling, not every recovery mechanism

The immediate benefit is less custom logic for capacity-based instance selection. It does not guarantee that a job will launch or complete successfully.

Before adoption:

• Test every candidate with a representative workload.
• Set cost limits using total job cost, not just hourly rates.
• Record the actual instance type to explain runtime and result differences.
• Keep handling unrelated errors, including permissions, quotas, images, data paths, and application failures.
• Confirm what happens when no candidate has capacity; the supplied summary does not specify that boundary.

Instance preference lists are most useful when a team already has several validated alternatives and wants to stop maintaining its own capacity-selection loop. A carefully chosen list is more valuable than a long one.

English SEO Summary

Amazon SageMaker AI instance preference lists select available capacity for training and processing jobs. Learn ordering, validation, and adoption checks.