Slack 概要介绍了其 AI 服务基础设施如何历经四个不同阶段的发展，从自托管的 Amazon SageMaker 部署演变为涵盖 AWS Bedrock 和 Google Cloud Vertex AI 的多云架构。按照该公司的说法，最终的配置使复杂推理工作负载的质量提高了约 10%，同时将短提示词的延迟降低了约 67%。
在该报告发布之际，为了提升系统韧性，获取更广泛的模型资源，降低对单一云平台的依赖，工程团队正越来越多地评估多供应商 AI 策略。
最初，Slack 的 AI 服务平台使用跨账户的 IAM 角色运行在 Amazon SageMaker 上，位于一个托管 VPC 中。虽然这种方法提供了强大的隔离性，但同时也需要手动进行容量预测、按计划扩展集群，并针对稀缺的 A100 和 H100 GPU 资源提前做好规划。每天有数百万用户依赖 AI 驱动的功能，因此，容量不足和基础设施问题可能会迅速演变为影响客户的实际问题。
为了减轻这一运维负担，Slack 迁移到了 Amazon Bedrock。该公司表示，这一举措消除了基础设施管理的开销，缩短了功能上线延迟，并能更快地访问 Anthropic 的新模型。工程师们不再需要直接管理 GPU 预留，这使得团队能够更加专注于模型性能和产品质量。Slack 通过合规性审查、负载测试以及基于功能开关的分阶段部署完成了这次迁移，根据他们的报告，期间未发生任何影响客户的事件。
另一项挑战仍然是流量波动。Slack 报告称，AI 工作负载在高峰期和非高峰期之间的波动幅度可达 10 倍。为了应对这些波动，其团队把 Bedrock 的“预配置吞吐量”（PT）和“按需”服务相结合，将交互式流量路由到延迟更低的 PT 端点，同时允许突发性的后台工作负载溢出到“按需”容量中。
这种混合容量模型解决了与处理大型 AI 工作负载相关的许多扩展挑战。然而，Slack 指出，一个重要的局限性依然存在：其 AI 平台仍然依赖于单一供应商。Slack 表示，对单一供应商的依赖继续引发了弹性方面的担忧，并且限制他们使用与这家供应商存在竞争关系的生态系统的模型。
这些担忧促使 Slack 采取了多云战略。
要集成 Google Cloud Vertex AI，该公司需要构建一个与供应商无关的部署层，使其能够在各种云环境中一致地运行。该平台引入了无密钥认证、API 标准化、统一的可观测性以及供应商之间的智能路由功能。该系统会通过“首次令牌获取时间”（TTFT）、p90 延迟和 5xx 错误率等指标持续地评估端点，将流量从性能下降的服务中重定向出去。该抽象层还支持 A/B 测试和受控的模型发布。
Slack 表示，这样构建出来的架构同时提升了性能和灵活性。除了已报告的质量和延迟方面的改进外，该公司还特别指出，他们能够访问更广泛的基础模型，增强了地理故障转移能力，并且降低了对任何单一云 AI 平台的依赖性。
在 AI 基础设施的其他领域，类似的做法也正在广泛涌现。Padiso 的工程师曾经介绍过，他们通过将 Anthropic Claude 的流量路由至 Bedrock、Vertex AI 以及 Anthropic 的直接 API，提升了系统韧性并控制了对服务提供商的依赖。同样，BentoML 也提倡基于延迟和可用性来路由流量的多云和跨区域推理策略。这些案例反映了与 Slack 所强调的可移植性、故障转移和运维灵活性相关的诸多共同关切。
对于开发基于 AI 的应用程序的平台团队而言，Slack 的经验说明，抽象层既有助于将应用逻辑与底层模型提供商分离，同时又能在韧性、性能以及对快速变化的模型生态系统的访问之间取得平衡。
