Salesforce 如何借助 SageMaker 推理组件实现多可用区高可用部署

Salesforce 的 Agentforce 平台依赖大量 AI 模型提供智能体能力，这些模型的稳定性直接影响企业客户的生产环境。SageMaker 推理组件允许多个模型共享同一组 GPU 实例，相比为每个模型单独分配资源，成本降低幅度高达 8 倍。然而，这种共托模式也带来了新的风险：默认的放置算法以单次操作为视角独立优化每次部署，不考虑跨 AZ 的整体均衡，导致同一模型的多个副本可能集中在同一个可用区，一旦该 AZ 发生故障，整个模型服务将完全中断。

为应对这一挑战，AWS 推出了 SchedulingConfig 参数，嵌入在 CreateInferenceComponent API 中。该参数包含两个关键子参数：AvailabilityZoneBalance 控制副本在不同 AZ 之间的均衡分布，支持通过 MaxImbalance 配置可容忍的最大副本数差值；PlacementStrategy 则控制单个 AZ 内部的实例级分布策略，SPREAD 模式将副本尽量分散到不同实例以提升容错能力，BINPACK 模式则将副本集中到较少实例以提高 GPU 利用率。两者组合使用，可以在可用性与成本效率之间灵活取舍。

在具体实践中，Salesforce 的多 AZ 端点包含 4 个实例，分布在 2 个可用区（每区 2 个实例）。部署拥有 4 个副本的模型时，团队将 PlacementStrategy 设为 SPREAD，并将 MaxImbalance 设为 1，允许两个 AZ 之间最多相差 1 个副本。SageMaker 随即将 4 个副本均匀分配至 4 个实例，每个 AZ 各承载 2 个副本。对于仅需 2 个副本的轻量模型，则将 MaxImbalance 设为 0，强制执行严格的每 AZ 一个副本策略，确保任何单一 AZ 故障不会导致服务完全不可用。

扩缩容操作同样需要维持 AZ 均衡。当执行扩容时，SageMaker 会根据已配置的 SchedulingConfig 参数，将新增副本优先放置在副本数较少的 AZ；缩容时则对称地从各 AZ 移除副本。团队特别强调，对于高可用关键模型，CopyCount 绝不能设为 1，因为单个副本只能驻留在一个 AZ，会立即违反双 AZ 合规要求。此外，对于长期运行中因反复扩缩容导致的副本分布碎片化问题，可通过在端点配置中启用 CONSOLIDATION 策略，由后台清理程序定期整合副本并释放空闲实例。

新放置算法在架构层面引入了三项核心改进：其一，算法评估的是最终分布的均衡状态，而非仅关注当次操作的即时需求；其二，SageMaker 在端点和推理组件更新操作期间持续保持多 AZ 分布，确保模型更新过程中高可用性不被破坏；其三，AZ 内部的实例级分布由 PlacementStrategy 独立控制，Salesforce 选择 SPREAD 策略以优先保障故障隔离，防止单实例故障同时影响同一模型的多个副本。这三项改进共同构成了满足 Salesforce 合规要求的技术基础。

这一案例揭示了企业级 AI 基础设施建设中的一个普遍张力：成本优化与高可用合规往往存在结构性冲突。SageMaker 推理组件的多模型共托能力本质上是通过资源聚合降低成本，而高可用要求则需要资源分散以规避单点故障。SchedulingConfig 参数的引入提供了一种在两者之间精细调节的机制，使团队无需在成本与合规之间二选一。对于同样面临 GPU 成本压力和可用性合规要求的企业，这套方案提供了可直接参考的工程路径。

要点

• SageMaker 推理组件默认放置策略以单次操作为视角，不保证跨 AZ 均衡，可能在多 AZ 端点中产生单点故障风险
• SchedulingConfig 参数通过 AvailabilityZoneBalance 和 PlacementStrategy 两个维度，实现跨 AZ 分布与实例级放置的独立精细控制
• 高可用关键模型的 CopyCount 不得设为 1，扩缩容操作应依赖 SchedulingConfig 保持 AZ 均衡，长期碎片化问题则通过 CONSOLIDATION 策略解决
• Salesforce 通过 SPREAD 策略优先保障故障隔离，在维持 8 倍成本优势的同时满足了每个生产模型必须覆盖至少两个可用区的内部合规要求
• 模型更新操作期间 SageMaker 会持续维持多 AZ 分布，确保高可用性在整个模型生命周期内不被中断