构建 AWS Bedrock 模型可用性：将 AI 路由发现从数天缩短至数分钟
Source: Salesforce Engineering
Engineering Energizers Q&A – Spotlight on Scott Chang
Principal Engineer, AI Infrastructure – Agentforce 360
你的团队在为 Agentforce 构建 Bedrock Model Availability 时的使命是什么？
团队的核心使命是为 Agentforce 360 背后的 AI 服务提供 稳定、弹性和安全的基础设施，并高度关注运营卓越。
- 随着大语言模型（LLM）驱动的工作负载快速扩展和演进，底层基础设施的可靠性直接影响客户体验。
- 因此，确保模型路由、可用性以及回退行为在所有运行条件下保持可预测和安全至关重要。
Bedrock Model Availability 能力正是源于对运营卓越的关注。团队没有把模型路由视为静态配置，而是将其构建为包含自动化、可观测性和防护栏的 基础设施能力。其结果是一个坚实的基础，能够：
- 提升弹性
- 最小化运营风险
- 让 Agentforce 能在不牺牲正确性或合规性的前提下快速采用新模型
Agentforce 快速的区域扩张在跟踪模型和端点可用性方面引入了哪些可扩展性约束？
Agentforce 使用 多账户 AWS 架构 来：
- 保持区域分离
- 满足数据驻留要求
- 管理服务配额
全球扩张使平台的 AWS 账户数量增长到 30 多个，遍布不同地区。每个账户都需要为基础模型配置独立的路由设置，使得可用性管理成为一项庞大的工作。
额外挑战
- 新区域不断加入，同时模型提供商会在如俄勒冈或弗吉尼亚等中心地区率先推出新选项。
- 每个模型可能拥有不同的推理配置——区域内或全局端点——且随着容量变化而改变。
手动跟踪很快变得不可能。工程师需要花费数小时查找模型、检查配置文件，并为每次发布更新复杂的路由配置。
解决方案： 一个通过三个 AWS API 收集可用性数据的自动化系统。
- 区域性 AWS Lambda 函数 收集数据并将其发布为 CloudWatch 自定义指标。
- 这些指标供内部监控工具和单一 Grafana 仪表盘 使用。
- 工程师现在可以 实时 按区域和 ID 识别活动模型端点。
Result: 发现时间从数天缩短到数分钟。
当错误的端点被部署到生产环境时，出现了哪些正确性和合规性约束？
错误的端点部署可能导致：
- 将推理流量路由到意外的区域或不存在的端点 → 增加延迟或导致宕机。
- 违反 数据驻留要求，因为某些客户必须将数据保留在特定的区域或国家。
为防止此类故障演变为客户可见的事故，团队与外部 LLM 提供商的网关团队合作，实现了 确定性的基线回退机制：
- 将 基线区域（如弗吉尼亚、俄勒冈、法兰克福）确定为始终可用的 Bedrock 容量区。
- 如果主端点返回 HTTP 错误或不可用，流量会自动切换到该基线。
- 主路由逻辑与回退路径分离，确保陈旧或错误的配置数据不会导致长时间宕机。
该设计在真实运营条件下显著提升了 正确性、可靠性和合规性。
哪些路由和弹性约束影响了延迟、容量、数据驻留和可用性？
Source: …
bility when traffic was sent to the wrong geographic region?
跨区域路由会带来若干细微的挑战：
| 约束 | 影响 |
|---|---|
| 延迟 | 与整体 LLM 推理时间相比影响较小，但当流量跨越长距离时仍会增加开销。 |
| 容量 | 意外流量可能会超载未为该负载设计的区域生产容量，导致限流或失败。 |
| 数据驻留 | 违反客户规定的司法管辖限制（例如，欧盟数据必须留在欧盟）。 |
| 可用性 | 意外路由可能导致源区域和目标区域的服务降级或中断。 |
系统如何应对这些限制
- 分层路由 – 主路由选择最佳端点；确定性的回退机制处理故障。
- 实时可用性指标 – CloudWatch 和 Grafana 提供端点健康和容量的即时可视化。
- 合规感知路由表 – 区域标记有驻留约束；路由器在选择端点时会遵守这些标签。
- 容量感知限流 – 系统监控区域负载，并可在容量耗尽前将流量转移到基线区域。
通过这些机制，确保流量始终被指向 正确、合规且容量充足 的端点，既保持延迟目标，又满足监管要求。
模型路由与推理配置文件
AWS 托管的推理配置文件提供 区域内、国家内和全局故障转移 选项，以应对容量限制。与此同时，LLM Gateway 运行自己的故障转移逻辑：检测错误信号并将流量重新路由到预定义的备份端点。这些机制共同确保路由决策同时满足 延迟、容量、数据驻留和可用性 的要求。
模型路由与推理配置文件集成后提升了弹性。
自动化约束如何限制 Agentforce 快速采用新发布的 AWS Bedrock 模型？
在自动化之前，路由更新是一个 繁琐的多步骤手动过程：
- 发现模型可用性。
- 确认相应的端点。
- 更新配置文件。
- 创建拉取请求。
- 重新部署服务。
每一步都会引入延迟和出错的可能，使上线时间延长至 数天。
Bedrock 模型可用性 功能消除了这些瓶颈。团队现在能够自动：
- 收集、标准化并公开所有路由关键数据。
- 在 Grafana 仪表盘上展示这些数据，实现对跨区域模型可用性的 单一视图。
单一视图仪表盘将运营时间从天级缩短至分钟级。
影响
- 发现时间 从 ≈ 3 天 降至 10 分钟以内。
- 未来计划实现 全自动化，彻底消除路由配置延迟。
- 曾经需要 最长 7 天（发现 → 部署）的过程将变为 基本即时，动态更新将在服务层面自动传播。
此转变将路由从手动运维任务转变为 可随 Agentforce 自身节奏演进的可扩展基础设施能力。
了解更多
- 保持联系 — 加入我们的 Talent Community！
- 了解我们的 Technology and Product 团队，看看您如何参与。