从自托管到多云：Slack AI 基础设施四阶段演进，延迟降低 67%

企业协作平台 Slack 近日详细披露了其 AI 服务基础设施从单云自托管演进为多云架构的完整路径，展示了如何通过四个阶段的迭代解决容量规划、供应商锁定和弹性等关键挑战。据 Slack 官方报告，最终的多云配置使复杂推理工作负载的质量提高了约 10%，同时将短提示词的延迟降低了约 67%。

Slack 的 AI 服务平台最初运行在 Amazon SageMaker 上，采用跨账户 IAM 角色并置于托管 VPC 中。这种架构虽然提供了强大的隔离性，但运维负担沉重：工程师需要手动进行容量预测、按计划扩展集群，并提前规划稀缺的 A100 和 H100 GPU 资源。由于每天有数百万用户依赖 AI 驱动的功能，容量不足和基础设施问题会迅速演变为影响客户的严重事件。

为减轻运维压力，Slack 将 AI 服务迁移至 Amazon Bedrock。这一举措消除了基础设施管理的开销，缩短了功能上线延迟，并使其能够更快地访问 Anthropic 的新模型。工程师不再需要直接管理 GPU 预留，从而将精力聚焦于模型性能和产品质量。Slack 通过合规性审查、负载测试以及基于功能开关的分阶段部署完成了这次迁移，据称期间未发生任何影响客户的事件。

然而，流量波动成为新的挑战。Slack 报告称，AI 工作负载在高峰期和非高峰期之间的波动幅度可达 10 倍。为应对这一问题，团队将 Bedrock 的“预配置吞吐量”（PT）与“按需”服务相结合：交互式流量被路由到延迟更低的 PT 端点，而突发性的后台工作负载则溢出到“按需”容量中。这种混合容量模型有效解决了扩展难题，但 Slack 指出，其 AI 平台仍然依赖于单一供应商，这引发了弹性方面的担忧，并限制了他们使用与 AWS 存在竞争关系的生态系统的模型。

对单一供应商的依赖促使 Slack 采取多云战略。要集成 Google Cloud Vertex AI，该公司需要构建一个与供应商无关的部署层，使其能够在各种云环境中一致地运行。该平台引入了无密钥认证、API 标准化、统一的可观测性以及供应商之间的智能路由功能。系统通过“首次令牌获取时间”（TTFT）、p90 延迟和 5xx 错误率等指标持续评估端点，将流量从性能下降的服务中重定向出去。该抽象层还支持 A/B 测试和受控的模型发布。

Slack 表示，最终构建的多云架构同时提升了性能和灵活性。除了已报告的质量和延迟方面的改进外，该公司还特别指出，他们能够访问更广泛的基础模型，增强了地理故障转移能力，并且降低了对任何单一云 AI 平台的依赖性。

Slack 的做法并非孤例。在 AI 基础设施领域，类似的多云策略正广泛涌现。例如，Padiso 的工程师通过将 Anthropic Claude 的流量路由至 Bedrock、Vertex AI 以及 Anthropic 的直接 API，提升了系统韧性并控制了对服务提供商的依赖。BentoML 也提倡基于延迟和可用性来路由流量的多云和跨区域推理策略。这些案例反映了与 Slack 所强调的可移植性、故障转移和运维灵活性相关的共同关切。

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