許多工程團隊在開發 AI 應用時，最初往往會選擇最方便的單一雲端服務。但隨著用戶量增加與業務複雜化，單一供應商的依賴會帶來風險。Slack 分享了他們將 AI 推理平台從單一 AWS 環境演進到多雲架構的四個階段，這對於需要處理大規模流量且對可用性要求極高的團隊具有很高的參考價值。
第一階段：自建基礎設施的挑戰
最初，Slack 使用 Amazon SageMaker 進行 AI 模型佈署。SageMaker 是一個完整的機器學習平台，允許開發者自行管理模型佈署、擴展與監控。當時他們將其放置在獨立的 VPC（虛擬私有雲，用於隔離網路環境）中，並透過 IAM 角色（身份與存取管理，用於控制權限）來確保安全性。
然而，自建模式帶來了巨大的維運壓力。工程師必須手動預測容量、排程擴展集群，且在 A100 或 H100 等高性能 GPU 資源稀缺時，必須提前規劃預約。對於擁有數百萬用戶的 Slack 來說，任何容量不足或基礎設施故障都會直接導致用戶端的功能失效。
第二階段：轉向伺服器無伺服化 AI 服務
為了降低維運負擔，Slack 將平台遷移至 Amazon Bedrock。Bedrock 是一種 Managed Service（託管服務），它將模型以 API 的形式提供，開發者不需要再管理底層的 GPU 伺服器或處理集群擴展。
這次遷移讓團隊能將重心從基礎設施管理轉移到模型性能與產品品質上，並能更快地採用最新的模型版本。為了確保遷移過程零事故，Slack 採取了合規審查、壓力測試以及使用 Feature Flag（功能開關，允許在不重新佈署的情況下控制功能開啟或關閉）逐步放行的策略。
第三階段：解決流量波動與延遲問題
在規模化過程中，Slack 發現 AI 工作負載具有極高的波動性，尖峰與離峰時段的流量差距可達 10 倍。單純依賴隨用隨付的 On-Demand 模式無法保證低延遲。
為此，他們採取了混合容量策略：將對延遲敏感的互動式流量導向 Provisioned Throughput（預留吞吐量，確保固定資源可用），而將背景執行、對時間不敏感的批次工作導向 On-Demand 模式。這種做法在確保性能的同時，也優化了成本與擴展能力。
第四階段：構建多雲抽象層以實現高可用
儘管有了預留資源，但依賴單一雲端供應商依然存在風險。如果該供應商發生區域性故障，整個 AI 功能將癱瘓。此外，不同雲端平台提供的模型生態系有所不同，限制了技術選擇。
為了達成多雲策略，Slack 引入了 Google Cloud Vertex AI，並在上方構建了一個 Provider-agnostic Serving Layer（供應商不可知推論層）。這是一個抽象層，其核心功能包括：
API 標準化：將不同雲端平台的 API 接口統一，使上層應用無需關心底層是 AWS 還是 Google Cloud。 無密鑰認證：實現 Secretless Authentication，簡化跨雲端的安全認證流程。 統一觀測與智能路由：系統會持續監控 Time-to-first-token（首個 Token 產出時間，衡量 AI 回應速度的關鍵指標）、p90 延遲以及 5xx 錯誤率。當某個供應商服務品質下降時，路由會自動將流量切換到健康的平台。
最終成果與實務影響
透過這套多雲架構，Slack 在複雜推理任務上的品質提升了約 10%，且短提示詞的延遲降低了約 67%。更重要的是，他們獲得了地理級別的故障轉移能力（Geographic Failover），以及靈活切換不同基礎模型的能力。
對於 Junior 工程師來說，這個案例揭示了一個核心設計原則：當系統規模增加時，應該透過抽象層將應用邏輯與底層基礎設施解耦。這樣不僅能避免供應商鎖定（Vendor Lock-in），還能在追求性能、穩定性與成本之間取得更好的平衡。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。