Slack 概述了构建多云 AI 服务平台的四阶段发展路径

Slack

在该报告发布之际，为了提升系统韧性，获取更广泛的模型资源，降低对单一云平台的依赖，工程团队正越来越多地评估多供应商 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 基础设施的其他领域，类似的做法也正在广泛涌现。

对于开发基于 AI 的应用程序的平台团队而言，Slack 的经验说明，抽象层既有助于将应用逻辑与底层模型提供商分离，同时又能在韧性、性能以及对快速变化的模型生态系统的访问之间取得平衡。