Amazon MLS-C01: 部署、推論與服務 (ML 實作與維運) — 學習指南
屬於 AWS Machine Learning Specialty MLS-C01 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.
部署模式與服務選項
模型服務的選擇需要在延遲、成本、吞吐量和營運複雜性之間取得平衡。即時 SageMaker 端點（預配置或無伺服器）提供低於 100 毫秒到秒級的延遲，適合互動式 API；CPU 模型可選擇
undefined
等執行個體系列，GPU 模型可選擇
undefined
或
undefined
，而低成本、高吞吐量的 Inferentia 推論則可選擇
undefined
。非同步推論和批次轉換適合大批量或延遲可變的使用案例：批次轉換非常適合大型離線作業（將大型 S3 物件分割成碎片，並視需要使用
undefined
或 GPU 執行個體），而 SageMaker 非同步推論則支援較大的負載，並透過佇列實現近乎即時的批次處理。多模型端點在單一容器後託管多個模型，透過按需載入模型來減少儲存開銷；當模型較小、冷啟動成本不高且存取模式稀疏時，它們的效果最好。對於不可預測、低吞吐量的工作負載，選擇 SageMaker Serverless Inference 以避免管理執行個體；但要注意冷啟動和有限的執行時間。關鍵決策標準包括延遲 SLO、每次調用成本、並行模式、模型大小和冷啟動容忍度。一個常見的陷阱是將即時端點用於極高流量的批次工作負載——這樣成本高昂；應改用批次轉換、非同步推論，或透過批次處理和並行工作者來調用端點。
擴展、流量塑形與成本優化
自動擴展、流量轉移和成本控制必須與部署拓撲共同設計。使用 Application Auto Scaling，根據調用指標或自訂 CloudWatch 指標，透過目標追蹤策略來擴展 SageMaker 端點變體；定義合理的最小/最大容量和冷卻時間，以避免資源抖動 (thrashing)。對於藍/綠部署和金絲雀發布，使用多變體端點或更新 EndpointConfig，設定流量分割百分比並逐步增加；與 AWS CodeDeploy 整合以自動化流量轉移。成本優化包括模型剪枝、量化 (FP16 或 int8)、使用 SageMaker Neo 或 AWS Neuron 為 Inf1 進行編譯，以及將對延遲不敏感的工作負載轉移到批次轉換或無伺服器推論。Spot 執行個體可降低訓練成本，但不適用於即時端點；相反地，應適當調整執行個體類型的大小（cpu vs gpu vs inferentia），並在適當時使用多模型端點整合模型。注意陷阱，例如在不了解每個執行個體吞吐量的情況下使用目標追蹤導致過度配置，或假設多模型端點消除了記憶體限制——模型載入仍然需要記憶體，並可能增加延遲。此外，壓縮模型產物（ONNX、使用 gz 壓縮的 TF SavedModel）並使用延遲載入策略來減少儲存和冷啟動時間。
邊緣、低延遲推論與前/後處理的放置
對於超低延遲或離線環境，將模型部署到 AWS IoT Greengrass (v2) 或使用 SageMaker Edge Manager 在邊緣裝置上打包和監控模型；使用 SageMaker Neo 或 AWS IoT Greengrass 元件進行編譯，並使用量化來滿足記憶體/CPU 的限制。將預處理和特徵提取放置在能最大限度減少端到端延遲和成本的地方：簡單的過濾器可以在裝置韌體或 Greengrass Lambda 中運行，而批次處理和繁重的轉換則應在邊緣閘道器或雲端進行。對於串流事件視窗（例如，滑動的 10 分鐘視窗），使用 Amazon Kinesis Data Streams 或 Amazon MSK 進行擷取，使用 Kinesis Data Analytics 或 Flink/Apache Spark 進行視窗化和彙總，然後將摘要後的特徵轉發到 SageMaker 端點或輕量級的邊緣模型——這可以減少網路出口流量和模型調用頻率。小心陷阱，例如忽略邊緣裝置上的模型版本控制，或未能為模型產物配置足夠的裝置儲存空間。對於伺服器端的微服務，將預處理（API Gateway + Lambda 或 ALB + Fargate）部署在同一位置，以避免冷呼叫的開銷並減少發送到模型的負載大小。
監控、稽核、治理與資料處理
營運化的機器學習 (Operational ML) 需要持續的模型健康狀況監控與資料治理。使用 SageMaker Model Monitor 透過 DataQualityJob 為訓練資料建立基準線，並設定持續監控來偵測資料偏移 (data drift)、模型品質衰退、遺失值和自訂約束；在端點上啟用 DataCaptureConfig 以擷取輸入/輸出資料至 S3，並觸發 Model Monitor 任務。若要進行特徵層級的譜系追蹤與稽核，可使用 Amazon SageMaker Feature Store (線上與離線儲存區) 結合 AWS Glue Data Catalog 和 CloudTrail 來追蹤資料集的存取與轉換；Amazon Macie 和 Glue/SageMaker Processing 任務可以在訓練前發現並遮蔽 PII (個人可識別資訊)。加密的常見陷阱包括 SSE-KMS：當 S3 物件使用客戶管理的 CMK 加密時，請確保 SageMaker 執行角色擁有 kms:Decrypt 和 kms:GenerateDataKey 權限，且 CMK 政策已授予存取權；同時也要確保 S3 儲存貯體政策和 VPC 端點不會阻擋存取。對於每日產生的大型 S3 物件 (例如 100 GB)，應避免以單一檔案擷取——應將其分割為許多較小的物件，以 Parquet 格式儲存並壓縮，然後使用 Athena/Glue 進行結構描述偵測。常見的陷阱包括監控排程不足、未為 Model Monitor 產生適當的基準線，以及忘記將 KMS 存取權授予所有需要解密的服務主體 (SageMaker、Glue、Lambda)。
實務問題：使用情境
情境： Streamlytic Media 在 AWS 上營運一個 podcast 分析平台。他們使用 Kinesis Data Streams 擷取使用者事件，將匯總後的特徵儲存在 S3，並在 SageMaker 中託管模型以進行即時互動預測。資料偶爾包含 PII，並使用 SSE-KMS 客戶管理的金鑰進行加密。
挑戰： 針對滾動的 10 分鐘事件視窗提供低延遲預測、在模型訓練前遮蔽 PII、確保 SageMaker 能夠讀取加密的 S3 資料，並實作持續監控以偵測特徵偏移。
建議方法：
- 建立一個 Kinesis Data Stream 來擷取事件，執行 Kinesis Data Analytics (Flink) 來維護滾動的 10 分鐘視窗，並將匯總後的特徵以 Parquet 格式及每小時分區的方式發送到 S3。
- 使用 Amazon Macie 進行 PII 發現，並透過 SageMaker Processing 任務 (或 AWS Glue 任務) 應用確定性的遮蔽/權杖化；將結果儲存在 Feature Store 的離線儲存區以供訓練使用。
- 授予 SageMaker 執行角色對該 CMK 的 kms:Decrypt 和 kms:GenerateDataKey 權限，將該角色加入 CMK 的金鑰政策中，並確保 S3 儲存貯體政策或 VPC 端點允許 SageMaker 存取。
- 將模型部署為 SageMaker 即時端點，使用 ml.inf1 執行個體，啟用 DataCaptureConfig，從訓練資料建立 Model Monitor 基準線，並設定持續監控，將警示發送到 CloudWatch。
基本原理： 使用 Kinesis + Flink 進行串流匯總可將事件量和延遲降至最低；在處理階段進行資料遮蔽可保護隱私並確保合規性；明確的 KMS 權限可防止存取失敗；由 Inferentia 支援的端點和 Model Monitor 則在低推論成本與營運可觀測性之間取得了平衡。
← 訓練、分散式訓練與超參數最佳化 · 所有領域 · 安全性、隱私權與合規性 →
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →