模式 1:無伺服器 ML 推論管道 - AWS 方案指引

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

模式 1:無伺服器 ML 推論管道

在許多企業環境中,團隊需要將 AI 注入操作工作流程,例如,分類使用者意見回饋、偵測傳入遙測中的異常,或即時評分風險。這些採用機器學習 (ML) 的功能通常內嵌在面向客戶的應用程式、行動應用程式或內部自動化系統中。

不過,傳統的 ML 推論工作負載通常需要下列項目:

  • 預先佈建的運算,例如 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體和容器

  • 手動擴展政策

  • 即使在閒置時仍持續基礎設施

  • 複雜的部署和監控管道

這些要求會導致下列情況:

  • 用於零星推論的未充分利用資源

  • 模型版本控制、容錯移轉和自動擴展的操作複雜性

  • 成本增加,特別是對於低頻率或高載工作負載

此外,工程團隊通常缺乏專門的 ML 基礎設施技能來維持這種複雜性,而 AI 採用在原型階段停滯。

無伺服器 ML 推論模式:輕量、事件驅動、可擴展

無伺服器 ML 推論管道模式使用全受管、事件驅動的 AWS 服務 模式來消除基礎設施負擔。此方法可啟用推論工作流程,這些工作流程只會在需要時觸發和執行,並根據需求自動擴展。

此模式非常適合執行下列任務:

  • 執行在 Amazon SageMaker 或本機訓練的輕量型 ML 模型。

  • 近乎即時地執行分類、評分或轉換。

  • 在微服務、APIs 或資料擷取管道中內嵌 ML 邏輯。

參考架構實作每一層,如下所示:

  • 事件觸發 – 將 Amazon API Gateway 用於使用者請求、將 Amazon EventBridge 用於商業事件,並將 Amazon S3 用於資料上傳。

  • 處理層 – 實作 AWS Lambda來標準化輸入、驗證結構描述和豐富中繼資料。

  • 推論層 – 部署 SageMaker Serverless Inference 端點以執行分類、迴歸或評分。

  • 後置處理 – 使用 Lambda 來格式化回應、存放日誌和發出新事件。

  • 輸出 – 實作 API Gateway 將結果傳回給使用者,或將事件發佈至 EventBridge 以進行下游處理。

注意

此整個管道可以使用 AWS Cloud Development Kit (AWS CDK) 或 ()、版本控制和可觀察,以基礎設施形式部署為程式碼 AWS Serverless Application Model (IaC AWS SAM)。

使用案例:客戶意見回饋的情緒分類

一家全球電子商務公司想要將保留在產品評論或支援票證上的客戶意見回饋分類,以提早識別缺點並排定後續的優先順序。分類系統必須滿足下列要求:

  • 流量在行銷活動期間具有高峰值的高度變化。

  • 推論必須即時發生,才能與支援分類系統整合。

  • 此模型輕量 (100 毫秒推論延遲),並在 SageMaker 中訓練。

在此使用案例中,無伺服器推論管道解決方案包含下列步驟:

  1. 使用者意見回饋會提交至 API Gateway,然後傳送至 EventBridge。

  2. Lambda 會預先處理並格式化文字承載。

  3. SageMaker Serverless Inference 端點會執行情緒分類模型。

  4. Lambda 會將「負面」結果路由到支援升級佇列。

  5. 結果會記錄在 Amazon DynamoDB 中進行分析和重新訓練。

無伺服器 ML 推論管道的商業價值

無伺服器 ML 推論管道在下列領域提供價值:

  • 可擴展性 – 自動擴展到每分鐘數千個推論,無需手動調校

  • 成本效率 – 僅支付閒置期間零成本的執行時間

  • 開發人員速度 – 可讓團隊部署end-to-end AI 推論工作流程,而無需管理基礎設施

  • 彈性 – 提供內建重試、記錄和無狀態執行,以確保穩健性

  • 觀測性 – 使用 Amazon CloudWatch 和 監控模型用量、輸入和輸出磁碟區和延遲 AWS X-Ray

無伺服器 ML 推論管道是許多希望以增量和實際方式採用 AI 的組織進入點。這是實現下列目標的理想模式:

  • 即時、低延遲 AI

  • 傳統 ML 模型的成本效益部署

  • 與現代無伺服器和事件驅動系統無縫整合

透過抽象化基礎設施,團隊可以專注於商業邏輯、模型準確性和提供實際價值,而不會犧牲營運控制或可擴展性。