Amazon MLA-C01: ML 工作負載的成本優化 — 學習指南

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

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

核心概念：成本來源與您可以運用的手段

機器學習工作負載的成本主要來自三個基本類別：用於訓練和推論的運算、用於資料集和檢查點的儲存與資料傳輸，以及因基礎設施未充分利用或配置不當所產生的維運開銷。當您訓練大型模型或進行大量實驗時，訓練通常是最大的單一成本項目。當您大規模提供模型服務或需要為互動式應用程式提供低延遲時，推論成本則佔主導地位。核心的優化手段包括：選擇執行個體系列和大小、購買選項（隨需 vs Spot vs Savings Plans）、模型生命週期模式（批次 vs 即時 vs 無伺服器），以及執行期優化，例如模型編譯、快取和執行個體整合。

維運技術將這些手段付諸實踐。使用具備檢查點功能的受管 Spot 訓練，與隨需執行個體相比，可將訓練運算成本降低高達 70%，但需搭配檢查點功能（CreateTrainingJob 參數 CheckpointConfig → S3Uri）並將 CreateTrainingJob 的旗標 EnableManagedSpotTraining 設為 true，這樣任務才能在中斷後恢復。透過分析實際的 CPU/GPU/IO 使用情況（例如 CloudWatch 的 GPUUtilization、HostCPUUtilization 指標，以及來自 SageMaker Debugger 的分析器追蹤）來適當調整執行個體大小，然後切換到符合工作負載特性的運算系列（ml.c5/ml.c6 用於 CPU，ml.g5/ml.p4 用於 GPU，ml.r5 用於記憶體密集型）。對於推論，偏好採用成本與使用量成比例的模型：對於流量有尖峰、低吞吐量的工作負載，使用無伺服器推論（在 CreateEndpointConfig 的 production variant 中設定 ServerlessConfig → MemorySizeInMB 和 MaxConcurrency）；對於許多小型模型，使用多模型端點或模型編譯（SageMaker Neo）來縮減執行個體需求；並將大型或對延遲不敏感的工作負載轉移到非同步或批次轉換（AsyncInferenceConfig 和 Batch Transform）。

關鍵服務與組態

Amazon SageMaker 提供明確的成本控制選項。為了降低訓練成本，請使用受管 Spot 訓練：在 CreateTrainingJob API 中設定 EnableManagedSpotTraining=true，包含 CheckpointConfig.S3Uri，並設定 MaxWaitTimeInSeconds > MaxRuntimeInSeconds 以允許獲取 Spot 容量。在 SageMaker Python SDK 中，您可以設定 estimator.use_spot_instances=True、estimator.max_wait 以及將 estimator.checkpoint_s3_uri 設定為 S3 檢查點位置。為了在連續的訓練任務中獲得可重現的低延遲，當實驗節奏有此需求時，可以利用 SageMaker Processing 或在持續性佈建的基礎設施上執行訓練容器來保持容器暖機；否則，可透過使用較小的容器映像檔、預先建置的 SageMaker 容器，或在開發環境中重複使用持續性的訓練執行個體來縮短容器啟動時間。

在推論成本控制方面，CreateEndpointConfig/UpdateEndpointConfig 支援多種策略。在 ProductionVariants 中使用 ServerlessConfig，讓 SageMaker 管理擴展並根據叫用次數和記憶體計費，而非完整的執行個體小時數；ServerlessConfig 需要 MemorySizeInMB 和 MaxConcurrency 的值。對於穩定、高吞吐量的工作負載，使用佈建的執行個體，並對端點應用 Application Auto Scaling 目標追蹤政策，以避免過度佈建。當您託管許多不常使用的模型時，多模型端點可透過共用單一容器並依需求從 S3 載入模型成品來降低成本。若需模型大小的建議，可在 Inference Recommender 中呼叫 CreateInferenceRecommendationsJob，它會提供執行個體類型、批次大小和延遲/吞吐量的指引。

帳務承諾最好透過 SageMaker Savings Plans 或 AWS Compute Savings Plans 來處理。透過 AWS Billing 主控台購買 Savings Plan，承諾在 1 年或 3 年的期間內每小時支付一定金額（$/hour）；這會對所有執行個體系列的隨需 SageMaker 運算（訓練和託管）提供折扣。請注意，Savings Plans 適用於隨需用量，不適用於 Spot，因此應結合不同策略：為基準的穩定用量購買 Savings Plans，並將 Spot 用於突發性或實驗性的訓練。

設計模式與權衡取捨

「受管 Spot + 檢查點」模式是長期或大型分散式訓練任務的首選。它僅需要最少的程式碼變更：啟用 EnableManagedSpotTraining，提供 CheckpointConfig.S3Uri，並設定一個合適的 MaxWaitTimeInSeconds 以容忍 Spot 排程。其權衡之處在於，如果 Spot 中斷頻繁，重啟會變得複雜，且實際執行時間 (wall-clock time) 會稍長；但好處是成本能大幅降低。對於重視連續任務之間啟動延遲的迭代式實驗，請維持一個暖機的開發環境：使用較小、已佈建的 ml.m5 或 ml.c5 執行個體，並在 NVMe/本機快取上預先載入資料，或使用 SageMaker Processing 或 Studio 筆記本，在同一個執行個體上以本機處理任務的形式執行多個實驗。這會增加基礎成本，但能縮短總週期時間。

對於推論，應根據流量模式在無伺服器和已佈建端點之間進行選擇。無伺服器推論 (ServerlessConfig) 無需進行容量規劃，且對於間歇性、不可預測的流量來說成本最低，因為您是按調用次數和記憶體配置付費。其權衡之處在於冷啟動延遲和大小限制；對於有嚴格低延遲 SLA 的情況，應優先選擇具備自動擴展功能的已佈建執行個體，並考慮使用 SageMaker Neo 進行模型優化以減少執行個體數量。在需要託管多個模型但每個模型的流量都很低的情況下，多模型端點可以整合磁碟和記憶體使用量，並降低每個模型的成本，其代價是對於未載入的模型，冷啟動載入時間會稍高一些。

規模優化 (Right-sizing) 應首先依賴觀察，而非猜測。使用 SageMaker Debugger 分析和 CloudWatch 來收集 GPUUtilization 和 DiskReadOps；然後執行一個 Inference Recommender 任務 (CreateInferenceRecommendationsJob) 來驗證執行個體的類別/類型和效能。如果模型延遲要求很嚴格，可考慮模型量化或使用 SageMaker Neo 進行編譯，或使用 Elastic Inference 加速器將部分 GPU 推論能力附加到 CPU 執行個體上；Elastic Inference 讓您能將一個小型加速器附加到 CPU 執行個體上，與某些模型使用完整 GPU 執行個體相比，這能降低成本。

常見陷阱與決策標準

一個常見的錯誤是將單一的成本優化策略應用於所有工作負載。Savings Plans 對於穩定的基準使用率非常有效，但應與用於實驗性工作負載的 Spot 執行個體，以及用於尖峰推論的無伺服器 (serverless) 模式結合使用。不要假設 Spot 是免費的——它需要檢查點 (checkpointing) 和容錯的訓練邏輯；請設定 CreateTrainingJob.CheckpointConfig 和 EnableManagedSpotTraining，並計算一個能反映您可接受延遲啟動時間的 MaxWaitTimeInSeconds。另一個陷阱是忽略遙測 (telemetry)：若沒有進行效能剖析 (profiling)（使用 SageMaker Debugger、CloudWatch 和 Inference Recommender），您可能會面臨過度佈建 (over-provisioning) 或選擇 CPU、GPU 與記憶體特性不匹配的執行個體系列的風險。最後，無伺服器推論雖然簡化了成本計算，但可能引入無法預測的冷啟動 (cold starts)；在使用 ServerlessConfig 時，應測量端對端延遲，並在有嚴格 SLA 要求的場景下，改回使用具備自動擴展 (autoscaling) 功能的已佈建端點。

實務問題：使用案例情境

公司：FinSight Analytics。挑戰：FinSight 必須建立一個詐欺偵測管線，該管線需能：頻繁地對儲存在 S3 的交易日誌和客戶資料進行訓練、保持資料隔離、支援模型版本治理並在生產部署前進行手動審批、降低夜間重新訓練的成本、在快速實驗期間最小化每個任務的啟動延遲，以及提供一個對尖峰流量具成本敏感性的低延遲即時端點。

集中化且安全的資料與模型註冊表。將資料儲存在一個安全的 S3 儲存桶中，啟用預設加密，並使用儲存桶策略將存取權限限制給 SageMaker 執行角色。在 SageMaker Model Registry 中註冊模型；使用 SageMaker Pipelines 的 RegisterModel 步驟來建立模型套件 (model packages)，並將 ModelApprovalStatus 預設為 “PendingManualApproval”。透過建立一個能產出模型套件和手動審批步驟的 SageMaker Pipeline 來實作手動審批的人工工作流程；當授權的審核人員完成驗證後，他們會呼叫 boto3 sagemaker.update_model_package(ModelPackageName=..., ModelApprovalStatus='Approved') 來允許部署。理由：Model Registry 提供集中化的版本控制，而 ModelApprovalStatus 直接與 SageMaker API 整合，可將客製化操作降至最低。
具成本效益的夜間重新訓練。透過建立訓練任務時設定 EnableManagedSpotTraining=true 來使用受管 Spot 訓練，包含 CheckpointConfig.S3Uri 以持久化優化器狀態，並適當設定 MaxRuntimeInSeconds 和 MaxWaitTimeInSeconds，以便任務在 Spot 中斷後能夠恢復。將此方法與一個基準 Savings Plan 購買計畫結合，其規模應足以涵蓋平均的隨需 (on-demand) 訓練/推論時數以降低穩定成本，並在可容忍中斷的實驗中使用 Spot。理由：受管 Spot 能以最少的程式碼變更降低運算成本；Savings Plans 則適用於基準的隨需用量，以降低可預測的開銷。
降低實驗的啟動延遲。對於互動式實驗週期，在 SageMaker Studio 中維護一個持久的開發執行個體設定檔（例如 ml.c5 或 ml.m5），或一個在 EBS/NVMe 上預載資料集的小型專用 Notebook Instance，並重複使用該環境進行多次快速的訓練執行。對於生產環境的夜間任務，仍然使用具備檢查點功能的受管 Spot。理由：持久的環境避免了容器冷啟動，並提高了迭代速度，同時為重度運算保留了成本節約的優勢。
低延遲、成本敏感的即時服務。將已批准的模型部署到一個已佈建的端點以獲得基準的低延遲，並為該端點附加一個 Application Auto Scaling 策略，以便在離峰時段縮減規模。對於無法預測的流量尖峰，可為低流量模型設置一個無伺服器推論選項，或對於非即時的大型批次評分任務使用非同步推論（使用 AsyncInferenceConfig 並設定 S3 OutputConfig）。在部署前對模型應用 SageMaker Neo 編譯，以減少 CPU/GPU 的資源佔用。理由：已佈建端點結合自動擴展提供了穩定的低延遲和成本控制；無伺服器或非同步端點能更具成本效益地處理尖峰或批次工作負載，而 Neo 則降低了對執行個體的需求。

此方法結合了使用 EnableManagedSpotTraining 與 CheckpointConfig 來降低訓練成本、使用 SageMaker Model Registry 和 UpdateModelPackage 進行手動審批、使用持久的開發執行個體來減少啟動延遲，以及混合使用已佈建、無伺服器和編譯後的模型來優化推論成本。

← 生成式 AI 與基礎模型 · 所有領域 · 電腦視覺、NLP 與專業化 ML →

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