发生了什么
AWS 表示，Salesforce 使用 SageMaker Components 部署了 Agentforce 模型，并使用新的 SchedulingConfig 参数跨可用区和实例分发模型副本。 Salesforce 报告称，通过在共享 GPU 上共同托管多个模型，基础设施成本降低了 8 倍，但默认放置行为并不能保证其生产模型所需的两区弹性。
AWS 和 Salesforce 描述了涉及 Agentforce（Salesforce 的代理人工智能基础）的生产服务问题。 SageMaker Components 允许多个模型共享 GPU 支持的基础设施，消息人士称这将 Salesforce 的基础设施成本降低了八倍。权衡是 SageMaker 的默认放置算法独立评估每个部署操作。因此，即使端点本身使用多个可用区，特定模型的副本也可能分布不均匀。这使得端点级多区域配置不足以保证模型级分发。问题具体在于共享基础设施和各个模型副本的放置之间的关系。
新控件通过 CreateInferenceComponent API 中的 SchedulingConfig 参数公开。其 AvailabilityZoneBalance 设置控制副本在区域之间的均匀分布方式，而 PlacementStrategy 控制每个区域内的放置。 SPREAD 将副本分布在尽可能多的实例上，以提高故障隔离能力； BINPACK 将副本放在更少的实例上以提高利用率。消息人士称，Salesforce 选择 SPREAD 是为了满足其生产高可用性要求。这些设置使预期的放置行为在部署时变得明确，并将分布的选择与所追求的操作目标联系起来。
AWS 提供了一个包含四个实例和四个模型副本的两区域示例。通过 SPREAD 和一个副本的最大不平衡，预期结果是每个区域中有两个副本。对于仅需要两个副本的模型，最大不平衡为零，目标是每个区域一个副本。相同的调度设置旨在在横向扩展、横向收缩以及端点或推理组件更新期间保持有效。该消息人士还建议在重复扩展操作后采取长期清理的整合策略。总之，这些详细信息将放置描述为持续的调度问题，而不是在初始部署时仅应用一次的设置。
为什么这很重要
该部署解决了服务人工智能系统的一个实际问题：多区域端点仍然可以将一个模型的所有副本集中在单个区域或实例中。该配置为企业团队提供了明确的控制，以平衡可用区放置以及在故障隔离和更高利用率之间进行选择。
对于在共享基础设施上运行许多人工智能模型的组织来说，端点级和模型级弹性之间的区别非常重要。多区域端点不会自动确保每个模型在每个区域都有一个副本。如果模型的副本集中，则实例故障或区域中断可能会删除该模型，即使端点上的其他工作负载仍然可用。这意味着广泛的可用区设计可以显得具有弹性，同时使特定模型暴露出来。因此，必须在每个模型副本的级别上评估放置问题。
放置功能将可靠性要求与明确的资源权衡联系起来。 SPREAD 可以减少实例故障中丢失的模型副本数量，而 BINPACK 可以通过集中工作负载来提高加速器利用率。对于 Salesforce，消息来源提出的选择是保留多模型 GPU 托管的经济效益，同时满足每个生产模型都支持两个区域的内部要求的一种方式。该配置并没有消除权衡；它为团队提供了一种直接的方式来选择其副本如何占用可用实例和区域。
报告的结果对于企业人工智能运营来说非常重要，因为它将高可用性从一般架构目标转移到了可以检查和管理的部署设置。消息人士称，Salesforce 的模型机群实现了两区合规性，保留了联合托管节省的成本，在扩展期间保持了分布，并避免在模型更新期间打破区域平衡。这些是来自 AWS 客户成功账户的声明，而不是经过独立审计的绩效结果。该帖子没有确定系统在实际区域中断期间的行为方式，也没有确定每个模型和区域是否具有相同的条件。因此，实施账户对于理解控制及其规定的结果非常有用，同时保持独立验证的开放性。
互动机制：它实际上是如何运作的
以交互方式探索这一发展背后的基础技术。
crm_get_transaction(id='4092').An agent must create a draft calendar event for Tuesday at 2 p.m. Which evidence would establish the requested result?
接下来看什么
该来源不提供独立的正常运行时间测量、中断测试结果、延迟数据或报告的成本降低的完整核算。采用该模式的团队需要验证每个目标区域的容量、监控扩展后的布局，并确定尽力布局是否满足自己的合规性要求。
容量仍然是一个主要限制。 AWS 建议在每个目标可用区中为区域受限的区域进行按需容量预留，消息人士称 Salesforce 预先配置了预留 GPU 容量，以帮助获得平衡的放置。如果没有足够的容量，SageMaker 可能会在可用实例上部分部署副本，因为所描述的强制模式是宽松的。这使得该功能可以在约束下使用，但它可能会使最终的分布比预期的不平衡。当所需容量在每个目标区域中不可用时，所需的配置和实际实现的布局可能会有所不同。
操作员需要监控所需的放置是否随着时间的推移而持续存在。消息来源指出，SageMaker AI Insights 和 CloudWatch 指标涵盖可用区域偏差、按区域划分的推理组件副本计数、重新平衡事件和持续时间以及容量不足错误。它还警告说，HA 关键组件不应减少为一份副本，因为一份副本不能跨越两个区域。实际问题是团队如何快速地发现并修复不平衡，以免其成为可用性问题。监控必须涵盖副本数量及其分布，尤其是在扩展和更新改变部署时。
重要细节仍未知。它没有说明涉及的地理区域、覆盖的生产端点或模型的数量、预留容量的成本、对延迟和吞吐量的影响，或者 Salesforce 试图满足的可用性目标。它还不提供针对默认算法的比较故障测试。因此，企业团队应该将帖子视为实施模式和客户报告的结果，然后在自己的环境中验证容量、故障转移行为、监控和总成本。这些检查对于确定报告的弹性和利用率之间的平衡是否适用于他们自己的工作负载和操作条件是必要的。