Salesforce 通过 SageMaker 推理组件实现多可用区高可用

当 Salesforce 着手让 Agentforce（Salesforce 的 AI 基础层，用于驱动 Agent）在多个可用区（AZ）间实现高可用（HA）时，团队面临一个缺口。Amazon SageMaker AI Inference Components（IC）能够降低 GPU 成本，但其默认放置方式无法满足 Salesforce 合规标准所要求的多 AZ 弹性。

对 Salesforce 而言，IC 通过在共享 GPU 上共托管多个模型，实现了基础设施成本降低 8 倍。然而，这一成本优势带来了一个新问题：如何让 IC 端点在多个 AZ 间实现高可用？

本文探讨 Salesforce 如何利用新的 IC Placement 功能（通过 CreateInferenceComponent API 中的 SchedulingConfig 参数暴露）来满足其多 AZ HA 合规要求。

挑战：IC 部署中的单点故障

默认情况下，SageMaker 放置算法独立优化每个 IC 部署操作，在各实例间均匀分布新副本，而不考虑 AZ 均衡。即使端点本身是多 AZ 的，这种单次操作视角也意味着特定模型的副本可能最终不均匀地分布在各 AZ 中，从而产生潜在的单点故障：

实例级故障：单个实例崩溃会导致模型的所有副本不可用。

AZ 级故障：一个 AZ 断电会使整个模型不可用。

合规风险：Salesforce 要求每个生产模型必须支持 2 AZ。IC 的默认放置方式仅针对成本优化，尚未达到其内部 2 AZ 合规标准。

解决方案：SchedulingConfig

AWS 在 CreateInferenceComponent API 中引入了 SchedulingConfig 参数。它使客户能够细粒度地控制 IC 副本在实例和 AZ 间的放置方式。两个关键子参数驱动 HA 行为：

AvailabilityZoneBalance：控制跨 AZ 分发，以可配置的失衡容忍度在可用区之间均衡分配副本。

PlacementStrategy（每个 AZ 内）：SPREAD 将副本分散到尽可能多的实例上以实现故障隔离。BINPACK 将副本打包到更少的实例上以提高利用率。

代码示例：部署具有多 AZ HA 放置的 IC

场景：Salesforce 有一个多 AZ SageMaker 端点，包含 4 个实例均匀分布在 2 个可用区（AZ-1 中 2 个实例，AZ-2 中 2 个实例）。团队希望部署一个具有 4 个 IC 副本的模型，使其分布在两个 AZ 上以实现高可用。

以下 CreateInferenceComponent 调用以 SPREAD 放置和 AZ 均衡方式部署模型：

response = client.create_inference_component(
    InferenceComponentName='salesforce-llm-ic-ha',
    EndpointName='salesforce-multiaz-endpoint',
    VariantName='AllTraffic',
    Specification={
        'ModelName': 'salesforce-einstein-llm-v2',
        'ComputeResourceRequirements': {
            'NumberOfAcceleratorDevicesRequired': 1,
            'MinMemoryRequiredInMb': 65536
        },
        'DataCacheConfig': {'EnableCaching': True},
        'SchedulingConfig': {
            'PlacementStrategy': 'SPREAD',
            'AvailabilityZoneBalance': {
                'EnforcementMode': 'PERMISSIVE',
                'MaxImbalance': 1
            }
        }
    },
    RuntimeConfig={'CopyCount': 4}
)

使用 SPREAD 时，SageMaker 将 4 个副本分布到 4 个实例：AZ-1 中 2 个，AZ-2 中 2 个。当设置 MaxImbalance 为 1 时，配置系统最多容忍任意两个 AZ 之间 1 个副本的差异。

对于只需要 2 个副本的轻量模型，MaxImbalance: 0 强制严格均衡：每个 AZ 恰好 1 个副本：

# Lighter model: strict 1-copy-per-AZ balance
'SchedulingConfig': {
    'PlacementStrategy': 'SPREAD',
    'AvailabilityZoneBalance': {
        'EnforcementMode': 'PERMISSIVE',
        'MaxImbalance': 0
    }
},
RuntimeConfig={'CopyCount': 2}

在扩展时保持 AZ 均衡

当你执行扩容和缩容操作时，SageMaker 通过配置的 SchedulingConfig 参数帮助你维持 AZ 均衡。扩容时，SageMaker 会放置新副本以保持均匀的 AZ 分布。减少 CopyCount 时，SageMaker 会跨 AZ 对称地移除副本。

重要提示：对于 HA 关键模型，切勿将 CopyCount 设置为 1。单个副本只能驻留在一个 AZ 中，这意味着你将立即破坏 2 AZ 合规要求。

update_response = client.update_inference_component(
    InferenceComponentName='salesforce-llm-ic-ha',
    RuntimeConfig={'CopyCount': 8}  # Scale out: 4 per AZ
)

注意：SchedulingConfig 管控每次单独扩展操作的放置计划。对于持续的整合和重新平衡（例如，在反复的缩容/扩容周期之后），请配置端点的 ScaleInPolicy 为 CONSOLIDATION 策略。使用此配置后，后台清理程序会定期整合 IC 副本并在遵守 AZ 均衡约束的前提下释放空闲实例。

# Step 1: Create an endpoint config with CONSOLIDATION ScaleInPolicy
client.create_endpoint_config(
    EndpointConfigName='salesforce-multiaz-endpoint-config-v2',
    ProductionVariants=[{
        'VariantName': 'AllTraffic',
        'InstanceType': 'ml.g5.xlarge',
        'InitialInstanceCount': 4,
        'ManagedInstanceScaling': {
            'Status': 'ENABLED',
            'MinInstanceCount': 2,
            'MaxInstanceCount': 8,
            'ScaleInPolicy': {
                'Strategy': 'CONSOLIDATION'
            }
        }
    }]
)

# Step 2: Update the endpoint to use the new config
client.update_endpoint(
    EndpointName='salesforce-multiaz-endpoint',
    EndpointConfigName='salesforce-multiaz-endpoint-config-v2'
)

放置算法的三大支柱

新放置算法引入了三个基本改进。每一项都直接解决了 Salesforce 的 HA 需求：

均衡的最终分布：算法考虑最终分布的均衡性，而不仅仅是即时放置需求。

感知可用区的分布：SageMaker 在最大努力的基础上跨 AZ 均匀分布副本。端点和推理组件更新操作保留多 AZ 放置，因此在模型更新期间 HA 得到保持。

AZ 内优化：在每个 AZ 内，PlacementStrategy 管控实例级分布。BINPACK 将副本打包到更少实例上以最大化 GPU 利用率。SPREAD 将副本分布到尽可能多的实例上以实现最大故障隔离。

Salesforce 为第三支柱选择了 SPREAD，将故障隔离置于打包密度之上。这有助于防止单个实例故障导致同一模型的多个副本不可用。

目标架构：前后对比

延续前面的场景：Salesforce 的端点在 2 个 AZ 中有 4 个实例。随着时间推移，团队向此端点部署了三个 IC，每个 IC 在独立操作中创建：IC1（4 个副本）、IC2（2 个副本）和 IC3（2 个副本）。

后来，团队部署 IC3，这是一个只需要 2 个副本且要求严格 AZ 均衡的轻量模型：

response = client.create_inference_component(
    InferenceComponentName='salesforce-light-model-ic3',
    EndpointName='salesforce-multiaz-endpoint',
    VariantName='AllTraffic',
    Specification={
        'ModelName': 'salesforce-summarizer-v1',
        'ComputeResourceRequirements': {
            'NumberOfAcceleratorDevicesRequired': 1,
            'MinMemoryRequiredInMb': 16384
        },
        'SchedulingConfig': {
            'PlacementStrategy': 'SPREAD',
            'AvailabilityZoneBalance': {
                'EnforcementMode': 'PERMISSIVE',
                'MaxImbalance': 0
            }
        }
    },
    RuntimeConfig={'CopyCount': 2}
)

使用 MaxImbalance: 0，配置算法以每个 AZ 恰好 1 个副本为目标，这有助于即使整个 AZ 故障也能保持 IC3 可用。

下图展示了当三个 IC 都部署到同一端点时，默认放置与新 SchedulingConfig 放置的差异：

Figure 1: Default placement compared to SchedulingConfig placement across two Availability Zones

注意：每个副本需要多个 GPU 的模型（例如，需要 4 个加速器的大型语言模型 LLM）遵循相同的放置逻辑。SPREAD 有助于将每个多 GPU 副本放置在单独的实例上，而 AZ 均衡将它们均匀分布到各区域。

实施注意事项

以下各节涵盖多 AZ HA 部署的容量规划、配置和监控。

容量预留

AWS 强烈建议在 AZ 受限区域进行容量规划时使用按需容量预留（ODCR）。Salesforce 在每个目标 AZ 中预配置保留的 GPU 容量，以帮助验证均衡的 IC 放置。如果没有 ODCR，按需容量限制可能会限制你在高需求区域的所需分布。

注意：放置算法支持部分部署。如果容量约束阻止完全 AZ 均衡，SageMaker 仍会在可用实例上放置副本，而不是完全失败操作。这意味着即使没有 ODCR，该功能也可使用。然而，均衡可能不是最优的。

关键配置参数

下表汇总了多 AZ HA 放置的推荐参数值：

注意：DataCacheConfig 和 RoutingConfig 是独立于 IC 放置策略的通用端点/IC 配置功能。它们包含在此表中是因为它们补充了 HA 部署，但它们不是 SchedulingConfig 放置功能本身的一部分。

使用 SageMaker AI Insights 监控 AZ 均衡

SageMaker AI Insights 为 IC 放置健康状况提供内置可观测性。启用详细可观测性后，以下指标有助于验证和维护多 AZ HA：

AZ 倾斜（可靠性选项卡）：显示跨 fleet 的分布失衡百分比。在扩展事件后使用此功能检测均衡放置的漂移。

每个 AZ 的 IC 副本数：确认每个推理组件在可用区之间保持预期的副本分布。

重新平衡事件和持续时间：跟踪 SageMaker 自动重新平衡副本的时间及操作耗时。

每个 AZ 的容量不足错误（ICE）计数：按 AZ 和实例类型监控 ICE 事件。你可以使用此功能帮助确定是否需要调整 ODCR 容量。

你可以在 SageMaker AI Insights 仪表板和 Amazon CloudWatch 中访问这些指标。面向基于 IC 的端点可观测性的详细演练将在后续博客文章中介绍。

以下屏幕截图展示了 SageMaker AI Insights 可靠性选项卡中 AZ 均衡指标的示例：

Figure 2: SageMaker AI Insights Reliability tab with AZ balance metrics

通过使用 IC Placement 功能，Salesforce 的 AI 团队实现了：

多 AZ HA 合规：Salesforce fleet 中的每个模型部署都满足其 2 AZ 支持要求。

消除单点故障：任何模型都不会因单个实例或 AZ 故障而完全离线。

保持成本效率：多模型共托管继续提供基础设施成本节省，而 SPREAD 放置在实例间最大化故障隔离。

弹性扩展：扩容和缩容操作保持多 AZ 分布。

通过更新保持 HA：模型更新不再有破坏 AZ 均衡的风险。

企业 AI 团队的关键要点

Salesforce 在 SageMaker Inference Components 上实现多 AZ HA 的历程提供了几个经验教训。企业 AI 团队应考虑以下内容：

在 IC 级别而非仅在端点级别设计 HA。即使端点是多 AZ 的，如果没有明确的放置控制，IC 副本也可能集中在单个 AZ 中。

对于有高可用性要求的工作负载，使用带有 SPREAD 和 AvailabilityZoneBalance 的 SchedulingConfig。这是大多数有 HA 要求的模型的推荐起始配置。

使用 ODCR 预配置容量。要实现均衡的 AZ 放置，你必须在每个目标 AZ 中配置可用容量。不要依赖按需容量进行 HA 关键部署。

将最小 CopyCount 设置为 2，最小实例数设置为 2 作为 HA 基线。

切勿将 HA 关键模型缩容到 CopyCount: 1。单个副本只能驻留在一个 AZ 中，这意味着你将立即破坏 2 AZ 合规要求。

使用 SageMaker AI Insights 持续监控 IC 分布。跟踪可靠性选项卡上的 AZ Skew、每个 AZ 的 IC 副本数和重新平衡事件，以在失衡成为可靠性问题之前检测并纠正。

IC Placement 赋予企业 AI 团队所需的控制能力，以满足严格的可用性要求而不牺牲成本效率。对 Salesforce 而言，此功能解锁了其生产 Agentforce 模型的多 AZ HA 合规。它还可作为在 SageMaker 上运行有严格可用性要求 AI 工作负载的企业的参考模式。

AI 工作负载日益成为业务关键且有严格的正常运行时间要求。精确控制模型副本如何分布在基础设施上的能力不再是"锦上添花"。它是基本要求。

更多信息请参见以下资源。

CreateInferenceComponent API (Boto3) — 使用 SchedulingConfig 部署 IC 的完整参数参考。

InferenceComponentSchedulingConfig — PlacementStrategy（SPREAD/BINPACK）和调度配置。

InferenceComponentAvailabilityZoneBalance — EnforcementMode 和 MaxImbalance 参数。

Optimizing Salesforce's Model Endpoints with Amazon SageMaker AI Inference Components — Salesforce + SageMaker 成本优化故事的原始文章。

Monitor Endpoint Metrics and Create Alarms — SageMaker AI Insights 可观测性指标参考。

Inference Cost Optimization Best Practices — SageMaker 成本优化策略。

Inference Optimization for SageMaker AI Models — 量化、编译和模型优化。