Amazon MLA-C01: 模型部署與推論 — 學習指南

By Laurynas Brazys · 4 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

屬於 AWS Machine Learning Engineer Associate MLA-C01 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

即時、無伺服器、非同步與批次端點 — 核心概念

在 Amazon SageMaker 中的即時推論是一種低延遲、有狀態的服務模型，您需要建立一個 Model、一個 EndpointConfig 和一個 Endpoint，它會配置佈建的運算資源 (ml.* 執行個體類型) 並保持可用，以透過 InvokeEndpoint API 提供請求服務。CreateEndpointConfig 接受 ProductionVariants，而每個 ProductionVariant 都定義了 ModelName、InitialInstanceCount、InstanceType 和 InitialVariantWeight；您可以使用 UpdateEndpointWeightsAndCapacities 或 UpdateEndpoint 來變更流量和容量。對於可預測的低延遲需求，佈建的即時端點是主要選項，並支援多容器推論管道，以串接前處理、模型和後處理容器。

無伺服器推論 (Serverless Inference) 移除了執行個體管理，並在端點層級透過 ServerlessConfig 進行設定，該設定為每個 ProductionVariant 指定 MemorySizeInMB 和 MaxConcurrency；SageMaker 會管理容器的佈建，並在閒置時擴展至零，使其成為流量不穩定、吞吐量低的工作負載的理想選擇。非同步推論 (Asynchronous Inference) 針對需要長時間執行或用戶端不需要同步回應的請求進行了優化。非同步端點是透過 CreateEndpointConfig 中的 AsyncInferenceConfig (包含 S3OutputPath 的 OutputConfig、可選的 ClientConfig，以及 MaxConcurrentInvocationsPerInstance) 建立的，用戶端呼叫 InvokeEndpointAsync，並提供一個輸入的 S3 URI；結果會被寫入設定的 S3 輸出位置。批次轉換 (Batch Transform) 是一種獨立的任務類型 (CreateTransformJob)，用於大型離線推論工作負載；此 API 需要 TransformInput (包含 S3Uri 和 S3DataType 的 S3DataSource)、TransformOutput (S3OutputPath、Accept、AssembleWith) 和 TransformResources (InstanceType、InstanceCount)。當吞吐量比延遲更重要時，批次轉換是最佳選擇，它支援跨資料集的大規模平行處理。

多模型端點、推論管道、影子部署與 A/B 測試 — 關鍵服務與設定

當需要託管大量每個模型 QPS (每秒查詢次數) 較低的模型時，SageMaker 多模型端點 (Multi-Model Endpoints, MME) 允許單一容器託管數十到數千個儲存在 S3 中的模型成品，並根據需求載入它們。您需要建立一個實作 SageMaker 多模型伺服器模式的模型伺服器容器，或使用支援的框架映像檔，將模型 tarball 上傳到 S3，並建立一個參考該容器的 Model 資源。在調用時，您可以透過 InvokeEndpoint API 參數 TargetModel (或標頭 X-Amzn-SageMaker-Target-Model) 傳遞目標模型名稱，以便伺服器從 S3 將該模型載入記憶體。MME 為大型模型群節省了記憶體和營運成本，但會為尚未駐留在執行時期的模型增加冷啟動延遲。

推論管道被實作為多容器模型，其中 Model 資源會依序列出 Containers；端點會將負載依序路由通過第一個容器 (前處理)、模型容器，然後是後處理容器。在 CreateModel 中為每個容器定義其自己的 ModelDataUrl 和環境變數。對於金絲雀或藍/綠風格的測試，請在 EndpointConfig 中使用多個 ProductionVariants，並使用 InitialVariantWeight 控制流量分割，之後可透過 UpdateEndpointWeightsAndCapacities 進行調整。影子部署可以透過兩種方式實現：一是在應用程式層將每個請求的副本傳送到一個影子端點 (在生產端點上沒有流量權重)，或是建立一個低權重的 ProductionVariant，讓端點基礎設施接收一些鏡像流量；應用程式層的請求複製讓您可以完全隔離實驗並進行獨立的觀察。

為了進行隨需和持續監控，請在建立端點時設定 DataCaptureConfig，以將請求和回應的負載持續儲存到 S3。DataCaptureConfig 中值得關注的欄位包括 EnableCapture (true)、InitialSamplingPercentage、DestinationS3Uri 和 CaptureOptions (REQUEST、RESPONSE)。擷取的資料成為 SageMaker Model Monitor 和 SageMaker Clarify 部署後檢查的基礎；您可以使用 Model Monitor 的 CreateMonitoringSchedule 建立基準線，並執行臨機的 Processing 任務，這些任務使用內建的模型監控容器來計算約束條件和漂移指標。

設計模式與權衡取捨

當您需要個位數到低雙位數毫秒的延遲，且能負擔持續運作的容量時，請選擇佈建的即時端點。如果閒置時的每分鐘成本是主要考量因素，且流量是間歇性的，那麼無伺服器端點可以減少維運：為每個變體設定 ServerlessConfig.MemorySizeInMB 和 ServerlessConfig.MaxConcurrency，並讓 SageMaker 自動擴展。對於具有長時間運行推論或繁重酬載交換模式的工作負載，非同步端點可將客戶端的生命週期與運算分離；它們需要 S3 來處理輸入/輸出，且最適合客戶端可以輪詢或接收 S3 完成通知的情境。

多模型端點可減少記憶體重複和 S3 物件管理的複雜性，但它們會增加每個模型的冷啟動延遲，並且需要一個能夠依需求從 S3 載入並進行適當生命週期管理 (例如驅逐/LRU) 的模型伺服器。如果每個模型的延遲至關重要，請將熱門模型託管在專用的 ProductionVariants 上，並將低流量模型卸載到 MME。推論管道將前處理和後處理邏輯集中化，使其更靠近模型，從而減少客戶端程式碼並確保訓練和推論之間的一致性轉換，但它們會增加端點啟動的複雜性，並要求穩健的容器合約設計 (輸入/輸出編解碼器和內容類型)。

使用 ProductionVariant 權重進行 A/B 測試對於流量分割和離線指標收集來說相當簡單明瞭，但當您想在不影響生產指標的情況下進行流量鏡像時，應偏好使用應用程式層級的鏡像。對於漸進式部署和自動化回滾，可將 UpdateEndpointWeightsAndCapacities 整合到一個 CodePipeline 或 Step Functions 工作流程中，該流程包含使用 CloudWatch 指標和 Model Monitor 警示進行的自動指標評估，以及一個作為最終升級關卡的手動批准動作。

常見陷阱與決策標準

一個常見的操作錯誤是假設 Model Monitor 會偵測到標籤可用性的問題；Model Monitor 可以從捕獲的請求中偵測特徵分佈偏移和資料品質違規，但若要衡量基於標籤的指標（如 F1、recall）退化情況，您必須將真實標籤以監控任務可用的格式回傳至 S3，並排程一個監控任務來計算預測與真實值之間的差異。另一個陷阱是未能適當地設定 ServerlessConfig.MemorySizeInMB 的大小；記憶體配置不足會導致節流或容器崩潰，而過度配置則會增加成本。對於多模型端點，若忽略設定適當的 S3 物件佈局和生命週期（字首、模型清單），會使冷啟動變慢並使逐出策略複雜化。

在處理詐欺偵測的類別不平衡問題時，為了將操作開銷降到最低，應優先選擇演算法原生的加權方法，而非繁重的取樣管線；例如，XGBoost（SageMaker XGBoost 容器）支援 ‘scale_pos_weight’ 超參數，您可以將其計算為 negative_examples/positive_examples，並透過 CreateTrainingJob 呼叫中的 hyperparameters map 傳入。若要進行手動部署閘門，請使用 SageMaker Model Registry：建立一個 ModelPackageGroup，呼叫 CreateModelPackage 來註冊一個模型套件，並將模型套件狀態設為 PendingManualApproval；接著，外部的 CodePipeline 手動核准動作或 Step Functions + SNS 手動確認流程可以呼叫 UpdateModelPackage 將 ApprovalStatus 設為 “Approved”，然後再執行 CreateModel 或 CreateEndpoint。

實務問題：使用案例情境

FraudDetectCo 正在建立一個線上詐欺偵測系統，該系統必須整合 S3 中的交易日誌和地端的 MySQL 客戶資料表、訓練一個 XGBoost 模型、以近乎即時的延遲進行部署、對生產發布強制執行手動審核閘門，並能隨選偵測資料集異常和模型偏移。

資料彙總與預處理：使用 AWS Database Migration Service (DMS) 或 AWS Glue 的 JDBC 連接器，將地端的 MySQL 資料表持續複製到 S3 (parquet 格式) 或支援 Amazon RDS/Athena 的資料湖中；使用 AWS Glue 進行編目，並將特徵註冊到 Amazon SageMaker Feature Store 的離線儲存區，以提供一致的訓練和線上服務特徵查詢。這可以集中管理特徵血緣，並強制執行 S3 安全策略和 Lake Formation 治理以進行隔離。
訓練與類別不平衡處理：使用 SageMaker XGBoost 內建容器來執行 SageMaker Training jobs。計算訓練標籤的比例，並在 CreateTrainingJob 的 HyperParameters map 中設定 XGBoost 的 “scale_pos_weight” 超參數，以最少的預處理來解決類別不平衡問題。為訓練通道使用 Pipe mode（將 DataSource 的 S3DataSource 和 S3DataType 設為 S3Prefix，若使用 Pipe mode 則啟用 “RecordWrapperType”:“None”），以減少連續任務之間的啟動時間和資料下載延遲。
模型註冊表與手動審核：在 ModelPackageGroup 中呼叫 CreateModelPackage，將訓練好的模型註冊到 SageMaker Model Registry。將初始的 ApprovalStatus 設為 PendingManualApproval，整合一個包含 AWS Manual Approval 動作的 AWS CodePipeline，並在手動確認後呼叫 UpdateModelPackage 將 ApprovalStatus 設為 “Approved”，然後再透過 CreateModel 和 CreateEndpointConfig 將 ModelPackage 推廣到生產環境。
部署與推論拓撲：將模型部署到一個已佈建的即時端點，以進行低延遲評分。如果之後需要託管數百個模型，請評估使用 Multi-Model Endpoint，並利用 InvokeEndpoint 的 TargetModel 參數來指定 S3 中儲存的特定模型。設定 DataCaptureConfig (EnableCapture=true, InitialSamplingPercentage=100, DestinationS3Uri=s3://<bucket>/captures, CaptureOptions=[‘REQUEST’,‘RESPONSE’]) 來收集請求/回應的酬載，以供隨選分析之用。
監控與異常偵測：使用 CreateMonitoringSchedule 來排程 SageMaker Model Monitor 的基準線，以監控資料品質和特徵偏移。對於資料集層級的異常偵測和視覺化，將捕獲的 S3 資料饋送到 Amazon Lookout for Metrics 以自動偵測異常，並饋送到 Amazon QuickSight 以建立儀表板。若要進行隨選的偏差和偏移評估，可以針對捕獲的資料執行 SageMaker Clarify 處理任務，或啟動一個臨時的 Model Monitor Processing job（透過 CreateProcessingJob），該任務會套用已儲存的基準線限制並產生比較報告。

理由：此方法集中管理特徵以實現可重現的訓練和低延遲的服務，使用 XGBoost 的 scale_pos_weight 以最低的管線複雜度處理類別不平衡，在與 CodePipeline 整合的 Model Registry 中強制執行手動審核，透過使用 Pipe mode 串流訓練資料來減少訓練啟動延遲，並利用捕獲的推論資料提供自動化異常偵測 (Lookout for Metrics) 和隨選的公平性/偏移檢查 (Clarify + Model Monitor)。

← 模型評估與選擇 · 所有領域 · MLOps 與模型生命週期管理 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →