AI热榜 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 测试和受控的模型发布。
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接