Slack AI 的多云演进之路

背景

2023 年初，Slack 面临一个基础性挑战：如何以企业级规模提供大语言模型能力，同时满足客户对安全、可靠性和性能的要求。

这并不只是接入最新模型的问题。Slack 需要的是一个能够应对区域性故障、GPU 资源紧缺，并能持续支撑产品迭代的系统。其架构演进经历了从自管基础设施，到托管服务，再到混合与多供应商编排的过程。

第一阶段：SageMaker 时代

在 Slack AI 的早期建设中，AWS SageMaker 是自然的起点。它作为托管机器学习服务平台，提供了 Slack 当时所需的关键能力：

• 安全性
• FedRAMP 合规能力
• 模型可用性
• 对模型部署的控制能力

Slack 还采用了托管式隔离 VPC 策略，建立严格的“零知识”环境：Slack 的数据对外部提供方保持私有，而提供方的专有模型权重也不会被 Slack 访问。

为了服务全球用户并提升可用性，Slack 将相关容器部署在多个 AWS 区域。这意味着团队需要负责一系列运维工作，包括：

• 跨区域 IAM 角色管理
• 模型端点之间的流量均衡
• 主动容量规划
• 自动扩缩容逻辑

运维现实：安全换来了复杂度

SageMaker 提供了必要的安全能力，但也带来了很高的运维成本。Slack 总结出三类主要负担：

1. 扩容延迟：初始化时间较长，无法实现瞬时扩容。
2. 硬件稀缺：企业级 Nvidia GPU，例如 A100 以及后续的 H100 实例，经常不可用。
3. 过度预留：为了满足峰值服务等级目标，需要维持一定闲置资源。

到 2024 年初，Slack 通过按需容量预留和基于定时任务的主动扩容缓解了部分问题。但这也暴露出一个更根本的事实：工程团队花了太多时间在底层基础设施协调上。要继续扩大规模，Slack 需要自动化容量能力，而不是依赖人工协调。

模型能力滞后

随着 AI 生态和产品使用量快速增长，新模型和更高质量的模型迭代频繁出现。与此同时，AWS 将更多资源投入到 Amazon Bedrock 这一面向大语言模型的托管服务上。

Slack 在 SageMaker 上通过隔离 VPC 托管 Anthropic 模型时，经常陷入“追赶”状态：模型迭代和优化通常会先在 Bedrock 上推出，数周甚至数月后才在 SageMaker 上可用。

对于 Slack AI 来说，保持模型质量前沿是产品竞争力的一部分，因此这种滞后成为架构演进的重要推动因素。

第二阶段：迁移到 Amazon Bedrock

到 2024 年中，Amazon Bedrock 已经成熟许多，并获得 FedRAMP Moderate 合规能力，也能够满足 Slack 所需的安全要求。Slack 因此将 Bedrock 作为新的战略选择。

这次迁移带来了三个直接收益：

• 降低运维复杂度：不再需要自行管理 GPU 实例扩缩容，转向 AWS 托管服务。
• 更快获得新模型：模型提供方公开新模型后，Slack 能更快接入，减少能力滞后。
• 提升基础设施效率：Bedrock 提供 Provisioned Throughput 和 On Demand 两类基础设施选项。Slack 将前者用于频道摘要等交互式、低延迟功能，将后者用于 Recap 等突发型、计划型任务，以减少闲置计算成本。

从 GPU 实例到 Model Units

在 Bedrock 中，容量以 Model Units 衡量。每个 Model Unit 提供确定性的吞吐量，通常以每分钟 token 数计量。

这让 Slack 不再直接关心底层 GPU 实例，而是把注意力转向实际吞吐能力。为了降低迁移风险，Slack 优先使用 Provisioned Throughput，随后再推进 On Demand。

零事故迁移

Slack 通过多阶段策略完成迁移：

• 合规确认：在切换生产流量前，完成法律、安全和 FedRAMP 相关确认，维持既有数据隐私标准。
• 容量验证：通过大量压测，确定不同流量场景下需要多少 Model Units 才能匹配 SageMaker 基线。
• 质量评估：通过 A/B 测试和评估框架，对比不同环境下的输出，验证质量与延迟是否一致。
• 灰度发布：使用功能开关逐步迁移流量，并保留即时回滚能力，确保切换期间服务可用。

Slack 将这套方法总结为一条工程原则：先测量，逐步迁移，持续监控。

迁移后的收益

迁移到 Bedrock 后，Slack 在工程效率和用户体验上获得了明显改善：

• 工程师不再需要大量处理端点管理、GPU 生命周期、容量预留等底层问题，可以更多关注模型表现和功能质量。
• 由于 Bedrock 是新模型的重要发布渠道，Slack 能更早为用户提供模型升级和质量改进。
• 在 AI Search 等功能中，Slack 能更快接入推理能力更强的新模型，从而提供更精准、更具上下文感知能力的回答。

在新架构下，Slack 从“被动扩容”转向“战略预测”：提前数周预测容量需求，并与云服务团队协调，以尽量提前 확보所需资源。

第三阶段：转向 Bedrock On Demand

虽然 Provisioned Throughput 对稳定、可预测的负载非常有效，但并不能完美覆盖所有工作负载。

Slack 遇到两个主要效率问题：

1. 过度预留周期

   Slack AI 的使用量与全球工作日节奏高度相关。为了保证美国东海岸和西海岸早晨高峰期间，AI 摘要和搜索功能依然响应迅速，Slack 需要维持较高的 Model Units 基线。

   但在亚太、欧洲早晨以及周末等低谷时段，这些预留容量会出现明显利用不足。

2. 承诺周期锁定

   Provisioned Throughput 通常需要一到六个月的使用承诺。在大语言模型快速迭代的环境下，这会限制模型升级速度。即使更好的模型已经发布，Slack 也可能需要等现有承诺到期后再迁移。

因此，Slack 开始引入 On Demand，以在可靠性、成本效率和模型迭代速度之间取得更好平衡。

混合路由策略

Slack 并没有一次性将所有负载切换到 On Demand，而是采用混合路由：

• 高频、低延迟、对交互体验敏感的功能继续使用 Provisioned Throughput。
• 夜间 Recap 等异步、突发型任务迁移到 On Demand。
• 当预留容量被突发流量打满时，超出的请求会自动溢出到按需端点，避免因为容量上限而丢弃请求。

这种模式既保留了核心功能的稳定体验，也提升了应对波动负载的弹性。

On Demand 的取舍

On Demand 减少了人工容量规划，也让 Slack 能更快切换到通过内部质量和指标验证的新模型。对于峰值与低谷差异可达 10 倍的功能，效率提升非常明显。

但它也带来了新的变量：

• 服务等级波动：与专用预留容量不同，On Demand 通常基于共享资源池，稳定性特征会有所不同。
• 区域容量编排：成功使用 On Demand 依赖云服务商在区域内管理整体客户需求的能力，而不是为 Slack 明确保留硬件。
• 集中风险：如果过度依赖单一供应商的按需资源池，当该资源池出现容量或区域问题时，风险会集中放大。

对工程团队的启示

Slack AI 的演进显示，企业级 LLM 基础设施并不只是“选一个模型”或“接一个 API”。真正困难的部分在于：

• 如何在安全和合规前提下部署模型能力；
• 如何应对 GPU 与托管容量的不确定性；
• 如何在延迟、成本和可用性之间取舍；
• 如何避免长期容量承诺拖慢模型升级；
• 如何通过灰度、压测和监控降低迁移风险。

从 SageMaker 到 Bedrock，再到 Provisioned Throughput 与 On Demand 的混合使用，Slack 的路径体现了一个现实趋势：随着 AI 功能进入企业级生产环境，基础设施架构必须从单点部署走向更灵活的容量编排。