用 SageMaker Inference Components 跨可用区分布模型副本，实现 Multi-AZ 高可用

2026-08-29 33 预计阅读时间: 1 分钟
来源: aws.amazon.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：10 分钟

当一个模型服务需要满足 Multi-AZ 高可用合规要求时，问题并不只是“启动更多实例”。如果多个模型副本恰好集中在同一个 Availability Zone（AZ），单个可用区故障仍可能让服务整体失去容量。

Salesforce 的实践重点在于：利用 Amazon SageMaker AI Inference Components 的 SchedulingConfig，让模型副本能够分布到多个 AZ，同时保留多模型共托管带来的成本效率。对于共享推理基础设施的团队，这是一种比简单增加实例数量更精细的容量与可用性控制方式。

多模型共托管为什么会遇到 AZ 分布问题

SageMaker Inference Components 允许在推理端点的实例上运行多个模型副本。这样做可以提高硬件利用率，避免为每个模型单独维护一组实例，尤其适合模型流量不均衡、模型数量较多的场景。

但共托管也引入了一个容易被忽略的调度问题：

  • 模型副本数量不等于 AZ 数量；
  • 副本可能因为当前容量、部署时机或调度策略而集中在少数 AZ；
  • 某个 AZ 发生故障时，剩余副本未必能满足延迟和吞吐要求；
  • “端点处于 InService”并不自动等于“模型副本满足跨 AZ 合规要求”。

因此，Multi-AZ 合规检查关注的不只是 SageMaker endpoint 是否使用了多 AZ 基础设施，还要确认目标 Inference Component 的副本确实被调度到了所需的可用区。

SchedulingConfig 解决的是副本放置策略

在这类设计中，可以把几个参数分开理解：

  • RuntimeConfig：描述运行时需要多少个模型副本，以及副本如何运行；
  • SchedulingConfig：描述副本何时算作就绪，以及调度器如何满足副本的可用性要求；
  • 端点的实例类型和数量：提供模型副本可落地的底层容量。

关键点是，SchedulingConfig 不是用来替代底层基础设施冗余的。它不能在只有一个 AZ、或底层容量不足时凭空创造高可用。要满足 Multi-AZ，通常仍需要：

  1. 端点部署在支持多 AZ 的网络和实例容量范围内；
  2. 配置足够的实例或可用计算资源；
  3. 设置与目标 AZ 分布相匹配的模型副本数量；
  4. 在部署和扩缩容后验证实际副本位置，而不是只检查配置文件。

例如，目标是让一个模型至少拥有 4 个副本，并覆盖 2 个 AZ。此时需要保证底层端点有足够容量，并让调度配置要求这些副本在达到就绪条件后才被视为可用。具体字段和可选值会随 SageMaker API 与 SDK 版本变化，生产环境应以当前区域的 API 文档和 boto3 模型为准。

一个可改造的 Python 部署示例

下面的示例展示了部署思路：在已有 SageMaker endpoint 和 endpoint variant 上创建一个 Inference Component，为模型配置多个副本，并通过 SchedulingConfig 表达调度要求。

示例假设：

  • AWS 区域已经存在名为 prod-realtime 的 endpoint；
  • endpoint 中存在名为 AllTraffic 的 production variant；
  • S3 中已有模型包，并已创建 SageMaker model risk-model-v3；
  • 当前使用的 boto3 版本支持目标区域中的 Inference Components API。

运行前先设置凭证和区域，并按实际环境修改变量：

python -m pip install --upgrade boto3
export AWS_REGION=us-east-1
export ENDPOINT_NAME=prod-realtime
export VARIANT_NAME=AllTraffic
export MODEL_NAME=risk-model-v3

将以下内容保存为 create_component.py：

import os
import boto3
from botocore.exceptions import ClientError

region = os.environ.get("AWS_REGION", "us-east-1")
endpoint_name = os.environ.get("ENDPOINT_NAME", "prod-realtime")
variant_name = os.environ.get("VARIANT_NAME", "AllTraffic")
model_name = os.environ.get("MODEL_NAME", "risk-model-v3")
component_name = "risk-model-v3-multi-az"

sm = boto3.client("sagemaker", region_name=region)

request = {
    "InferenceComponentName": component_name,
    "EndpointName": endpoint_name,
    "VariantName": variant_name,
    "Specification": {
        "ModelName": model_name,
        "ComputeResourceRequirements": {
            "NumberOfCpu coresRequired": 2,
            "MinMemoryRequiredInMb": 4096,
        },
    },
    "RuntimeConfig": {
        "CopyCount": 4,
    },
    # 这是跨 AZ 调度的配置入口。字段名称和值域请以当前 boto3/API 版本为准。
    "SchedulingConfig": {
        "MinReadyInstanceCount": 4,
    },
}

try:
    response = sm.create_inference_component(**request)
    print("Created:", response["InferenceComponentArn"])
except ClientError as exc:
    print("Create failed:", exc)
    raise

注意：上面的 NumberOfCpu coresRequired 仅用于说明资源需求结构，实际代码中应替换成当前 SDK 接受的字段名，例如某些版本使用 NumberOfCpuCoresRequired。同样，SchedulingConfig 的具体字段应通过当前 SDK 的服务模型确认。这个示例的重点是把“副本数量”和“调度就绪条件”显式纳入部署请求，而不是依赖默认放置行为。

可以用下面的命令检查组件状态：

aws sagemaker describe-inference-component \
  --inference-component-name risk-model-v3-multi-az \
  --region "$AWS_REGION" \
  --query '{Status:InferenceComponentStatus,Runtime:RuntimeConfig,Scheduling:SchedulingConfig}'

在生产环境中，还应将以下信息纳入部署验证和监控：

  • Inference Component 的状态是否为 InService；
  • 实际 ready 副本数是否达到目标；
  • 副本是否分布在要求的 AZ 集合中；
  • 某个 AZ 被隔离后，剩余副本是否还能满足 SLO；
  • 滚动发布、扩缩容或实例替换后，分布是否仍然满足要求。

如果当前 SDK 不接受示例中的字段，先用以下命令确认本地服务模型和版本，再升级 SDK 或根据当前 API 调整请求：

python - <<'PY'
import boto3
print("boto3:", boto3.__version__)
sm = boto3.client("sagemaker", region_name="us-east-1")
operation = sm.meta.service_model.operation_model("CreateInferenceComponent")
print(operation.input_shape.members.keys())
PY

成本效率与高可用之间如何做取舍

跨 AZ 放置不会免费获得容量。为了让调度器有空间分布副本，通常需要预留更多底层实例，或者接受副本数量和单副本资源规格的重新规划。

可以按以下方式做容量设计：

  • 先确定故障目标：需要容忍一个 AZ 故障，还是只要求副本跨两个 AZ 分布；
  • 再确定副本数量：不要把“每个 AZ 一个副本”误认为足够，还要根据故障后的吞吐需求计算余量；
  • 保留共托管优势：把资源需求相近、流量峰值错开的模型放入同一端点，减少碎片化；
  • 避免过度共托管：模型之间若存在明显的 CPU、内存或延迟争用，成本节省可能被尾延迟和扩容压力抵消；
  • 把验证自动化：发布流水线应在组件变为就绪后检查副本数量和 AZ 分布，不满足条件就阻止上线。

这也是 Salesforce 方案的现实价值所在：不是在“高可用”和“多模型共托管”之间二选一，而是通过更明确的副本调度控制，在满足合规的前提下继续利用共享基础设施。

落地前检查清单

上线类似方案前，可以逐项确认：

  • [ ] Endpoint、子网和安全组配置支持目标 AZ；
  • [ ] 底层实例类型在每个目标 AZ 有足够容量；
  • [ ] Inference Component 的 CopyCount 与故障容量目标一致；
  • [ ] SchedulingConfig 使用的是当前 SDK 支持的字段；
  • [ ] 部署后能观测 ready 副本数和实际 AZ 分布；
  • [ ] 做过单 AZ 故障或容量缩减演练；
  • [ ] 共托管模型之间的资源争用有压测数据支持；
  • [ ] 扩缩容和滚动更新不会短暂破坏合规分布。

对于需要 Multi-AZ 高可用的 SageMaker 推理服务，真正值得审查的是“每个模型副本在哪里、什么时候可用、故障后还剩多少容量”。把这些问题显式交给 Inference Components 的调度配置，并配合底层容量和自动化验证，才能同时兼顾可靠性、合规性与成本效率。

# AI # AWS # 云平台 # 机器学习

相关推荐