跳转至

Slack AI: The Path to Multi-Cloud

Ch01.857 Slack AI: The Path to Multi-Cloud

📊 Level ⭐⭐ | 7.5KB | entities/slack-ai-path-to-multi-cloud.md

Slack AI: The Path to Multi-Cloud

摘要

Slack AI 从单云 AWS SageMaker 到多云 LLM 推理的演进历程跨越三年四个阶段。从最初的 SageMaker 自托管（面临扩缩容延迟、GPU 稀缺、过度预置三大痛点），到迁移至 Amazon Bedrock 获得模型访问速度和运维简化，再到引入 Bedrock On-Demand 模式解决空闲容量问题，最终扩展到 GCP Vertex AI 实现真正的多云架构。核心创新在于构建了智能路由层（Intelligent Routing Layer）——基于实时遥测指标（TTFT、错误率、P90 延迟）自动在跨云、跨模型间分发请求，并实现熔断恢复机制。

核心要点

  • 四阶段演进：SageMaker 自托管 → Amazon Bedrock PT（预置吞吐） → Bedrock On-Demand 混合模式 → GCP Vertex AI 多云架构
  • 智能路由层：指标驱动的模型选择（质量基准决定主模型）+ 自动熔断器（监测 TTFT、5xx 错误率、P90 延迟）+ A/B 测试能力
  • 多云收益：消除单云单点故障、复杂推理任务质量提升 ~10%、高吞吐低 Token 工作负载延迟降低 ~67%
  • 混合路由策略：延迟敏感的高频功能用预置吞吐保证"秒开"体验，突发批处理任务走 On-Demand，超过预留上限时自动"溢出"到按需端点
  • 运维复杂度：API 归一化层、统一监控栈、跨云成本归因、工程师跨云技能要求——这些是多云架构的隐藏成本

深度分析

四阶段演进的工程动因

Slack AI 的架构演进不是预先规划的蓝图，而是每个阶段被特定痛点驱动的务实选择。

Phase 1 → Phase 2（SageMaker → Bedrock PT） 的驱动力是"特性滞后"——AWS 优先在 Bedrock 上发布新模型（Claude 等），SageMaker 的 escrow VPC 方案导致 Slack 需要等待数周甚至数月才能用上新模型。对于以模型质量为竞争壁垒的 AI 产品，这个滞后是不可接受的。

Phase 2 → Phase 3（Bedrock PT → On-Demand 混合） 的驱动力是"闲置容量"——全球工作日的流量模式导致 Slack 必须为 US East/West 的早高峰预置大量 MU（Model Units），APAC 和 EU 时段的低峰期这些容量完全闲置。更关键的是，PT 要求 1-6 个月的承诺期，在 LLM 快速迭代的环境下，这实质上拖慢了模型升级速度。

Phase 3 → Phase 4（AWS 单云 → AWS+GCP 多云） 的驱动力是"单点风险"——无论在一个云内做多少故障转移，仍然无法应对整个云服务商级别的中断。同时，最佳模型往往具有云厂商独占性，锁定在单一云意味着可能错过最先进的能力。

智能路由层的架构深度

智能路由层是 Slack AI 多云架构的"大脑"，包含三个核心机制：

指标驱动的模型选择：每个 AI 特性都有一个主模型和一个或多个备用模型。路由决策基于内部质量基准——如果某个模型在"频道摘要"任务上表现最优，路由器将该特性的流量导向该模型。备用模型的存在确保了主模型出问题时系统能无缝切换。

自动熔断器（Circuit Breaker）：这是一个实时看门狗，持续监测端点级别的健康信号——TTFT（Time to First Token）升高、5xx 错误率飙升、P90 延迟超标等。当检测到异常时，熔断器"跳闸"，自动将流量转移到健康的备用模型。熔断器半开状态允许少量请求通过以验证恢复，逐步恢复正常流量。这种渐进恢复机制避免了传统熔断器的"全有或全无"问题。

A/B 测试能力：路由层原生支持流量分割，使 Slack 能够将一定比例的流量导向新模型进行在线验证。这将从模型选型到全量上线的周期从周级缩短到天级。

多云的真实代价

Slack 对多云代价的坦率描述是这份技术分享中最有价值的部分之一：

  1. API 与行为摩擦：每个云厂商有不同的 API 模式、专有错误码和限流行为。需要构建归一化层确保"Rate Limit Exceeded"和"Throttling Exception"在应用层被统一处理。
  2. 监控复杂度：不能依赖各云的原生仪表盘。需要构建跨云的统一监控栈，使值班工程师无需在不同控制台之间切换即可诊断问题。
  3. 成本归因挑战：当工作负载在云之间动态转移时，准确跟踪每个特性的成本变得极其困难——需要深度仪表化跨多个计费系统。
  4. 工程师技能要求升级：工程师不能再是单一云生态的专家——需要跨多家云的基础设施模式和网络细微差别的深度专业知识。

"零事故迁移"方法论

Slack 从 SageMaker 到 Bedrock 的迁移实现了零客户事故，其方法论值得借鉴：

  1. 合规前置：迁移生产流量前先获得法务、安全和 FedRamp 签批
  2. 容量对标：通过大规模负载测试精确匹配新平台的 Model Unit 数量
  3. 质量 A/B：使用 A/B 测试框架并排对比新旧环境的输出，验证质量和延迟一致性
  4. 渐进切换：通过特性标志逐步转移流量，具备即时回滚能力

这四条准则可以推广到任何关键基础设施的迁移场景。

实践启示

  1. 不要过早追求多云：Slack 的单云阶段（SageMaker → Bedrock）持续了两年多。多云引入的复杂度是巨大的——应该在单云优化遇到根本性限制（单点故障风险、模型独占性）时才启动多云战略。
  2. 智能路由层是多云的前提条件：在接入第二个云之前，先构建好抽象层。如果没有统一的模型选择、熔断和流量分配逻辑，多云只会增加混乱而非弹性。
  3. 预置+按需混合是成本优化的最佳模式：Slack 的"预置保延迟 + 按需降成本 + 溢出兜底"三层路由模式，为所有面向用户的 AI 推理系统提供了成本优化的参考范式。
  4. 迁移的黄金法则：合规前置、容量对标、质量 A/B、渐进切换——这四条准则适用于任何关键基础设施的迁移。
  5. 架构是活的文档：Slack 强调"managed services mature monthly"——每个季度重新评估云服务和模型选项，保持厂商中立性才能在技术快速演进中保持主动。

相关实体

→ 原文存档