SageMaker CloudWatch 監控與成本優化

SageMaker 基礎設施監控與成本優化，是將 ML 工程師與資料科學家區分開來的日常工作學科——選擇正確的 GPU 實例、設定實際追蹤需求的自動擴展、在不因中斷損失數天訓練的前提下善用 Managed Spot Training、以及防止端點艦隊每月悄悄燒掉數萬美元。在 MLA-C01 考試中，這些內容錨定 Domain 4（ML 解決方案監控、維護與安全，佔 24% 比重）的 Task 4.2（監控和優化基礎設施和成本）。社群反映的痛點——尤其是 Sourabh Sinha 的考試心得——明確指出成本優化問題在真實考試中出現的頻率高於預期，且需要 Spot 訓練、Savings Plans 和右型選擇的具體知識才能作答。

本指南以工程師視角建構。它涵蓋 SageMaker 訓練任務和端點的 CloudWatch 指標面、橫跨 ml.p3、ml.p4d、ml.p5、ml.g5、ml.g4dn、ml.inf2 和 ml.trn1 家族的 GPU 實例選擇、帶有目標追蹤和步驟擴展策略的端點自動擴展、帶有檢查點模式的 Managed Spot Training、SageMaker Savings Plans 對比隨需和保留容量定價、用於端點右型選擇的 Inference Recommender、用於迭代訓練的暖池，以及 MLA-C01 將透過排序和配對題型測試的成本驅動取捨。然後介紹架構設計，並以映射真實考試題幹模式的 FAQ 作結。

ML 工作負載基礎設施和成本監控的意義

ML 工作負載具有異常寬廣的成本差異——設定不當的訓練任務可能花費 $5,000，而它本應只花費 $200；設定不當的端點每月可能花費 $30,000，而它本應只花費 $3,000。兩個結構性原因。首先，ML 計算使用比通用 CPU 貴 10 至 50 倍的 GPU 和加速器；實例選擇錯誤會複合成本。其次，ML 工作負載具有間歇性需求模式——訓練任務執行數小時後停止；端點服務具有強烈的日間和週間週期性——粗放式配置為閒置容量過度支付。ML 的成本優化不是奢侈品；它在運維上至關重要。

SageMaker 部署的三大成本中心

典型的 SageMaker 堆疊有三條大的成本線。訓練計算——訓練任務和處理任務持續期間每秒每實例計費。推論計算——即時端點生命週期期間每秒每實例計費，無伺服器端點每次呼叫計費。儲存和資料傳輸——訓練資料和模型產出物的 S3 儲存、附加到訓練任務的 EBS 磁碟區，以及跨區域資料傳輸。每個成本中心有不同的優化槓桿；本指南重點關注計算成本線，因為它們主導成本。

CloudWatch 為 SageMaker 呈現什麼

SageMaker 在多個命名空間下向 CloudWatch 發布指標：/aws/sagemaker/Endpoints（每端點呼叫計數、延遲、錯誤、實例使用率）、/aws/sagemaker/TrainingJobs（每任務 CPU、GPU、記憶體、磁碟使用率）、/aws/sagemaker/ProcessingJobs（每任務處理使用率），以及兄弟主題涵蓋的 Model Monitor 命名空間。日誌進入可預測日誌組名稱下的 CloudWatch Logs——/aws/sagemaker/Endpoints/<endpoint-name> 和 /aws/sagemaker/TrainingJobs/<job-name>。這些共同構成了成本和效能的可觀測性面。

白話文解釋 SageMaker 成本優化

SageMaker 的成本優化跨越 GPU 定價、訓練排程、端點大小調整和預訂策略。三個具體類比讓結構更容易記憶。

類比一——餐廳廚房設備與人員配置

想像一家高端餐廳，設備成本是一般便餐廳的五倍——商業披薩爐而非家用爐、舒肥機而非鍋爐。SageMaker GPU 實例是 ML 計算的商業廚房設備：比純 CPU 實例貴 10-50 倍，但對正確的工作負載不可或缺。為正確的菜選擇正確的爐（為正確的模型選擇正確的 GPU）是第一個成本決策；只在需要時執行（自動擴展、Spot、排程訓練）是第二個。

從不關閉的常備爐是固定實例數量且沒有自動擴展的端點——無論顧客是否點餐都 24/7 執行。當訂單到達時啟動、在空檔之間關閉的爐是帶有 InvocationsPerInstance 目標追蹤自動擴展的端點。只在早餐和午餐開放的流動餐車是在高峰之間縮小到零的無伺服器推論端點。週二的週末大批備料是 Managed Spot Training——只要廚房接受主廚可能被中途打斷並需要從快照恢復，計算時間就便宜得多。與食材供應商鎖定較低價格的年度合約是 SageMaker Savings Plan——以保證的計算支出換取折扣。主廚每月審查的廚房設備使用報告以識別未充分使用的設備，是 CPUUtilization、GPUUtilization、MemoryUtilization 的 CloudWatch 指標——驅動右型選擇決策的資料。當主廚注意到 $80,000 的舒肥機一天有 80% 的時間閒置時，行動是用 Inference Recommender 找到能處理實際負載的更小更便宜的設備。

類比二——電廠容量規劃

想像一個有幾種類型電廠的區域電力公司。基載燃煤電廠以固定輸出持續執行——每度電最便宜，但無法快速增減。天然氣調峰機組只在需求高峰時執行——每度電更貴但靈活。可再生太陽能/風能在天氣配合時便宜但不可靠。蓄電池平滑差距。SageMaker 計算決策遵循相同的架構。

基載燃煤是 Reserved Capacity 或 SageMaker Savings Plans——以深度折扣率承諾一到三年期，用於可預測的穩態工作負載（服務恆定流量的常開生產端點）。天然氣調峰機組是隨需實例——全價但在需求高峰時立即可用。可再生太陽能是 Managed Spot Training——比隨需便宜最多 90%，但在其他地方容量緊張時可能被中斷；只適合可以檢查點和恢復的工作負載。蓄電池是端點自動擴展和暖池——保持小型準備緩衝區以吸收高峰，而不支付全部配置容量費用。告訴操作員派遣多少基載、調峰和可再生能源的負載預測員是 CloudWatch 指標歷史加上 Inference Recommender——驅動容量規劃決策。只執行基載的公用事業在低需求期間過度支付；只執行調峰機組在穩態需求期間瘋狂過度支付。SageMaker 工作負載遵循相同的取捨。

類比三——長途貨運車隊運維

想像一家管理跨國貨運車隊的貨運公司。有全職司機的自有卡車可以執行任何負載、任何時間，但每英里費用高。老闆兼司機的承包商更便宜，但只在他們選擇時可用。現貨市場負載提供回程的突然折扣，但可能在途中被取消。與托運人的長期合約以低於現貨市場的費率鎖定穩定收入。SageMaker 訓練和推論車隊規劃的方式相同。

自有車隊是隨需 SageMaker 實例——隨時可用，全每小時價格。老闆兼司機池是 Spot 訓練，節省最多 90% 但需要兩分鐘中斷通知。被取消的現貨負載是需要檢查點的 Spot 中斷，以便下一個實例可以從途中繼續。長期托運人合約是 Savings Plans——在一到三年內承諾基準計算支出，享受 30-50% 折扣。顯示每輛卡車燃油、里程和休息時間狀態的調度員 GPS 主控台是每個訓練任務和端點的 CloudWatch 指標。根據成本和可靠性為每個負載選擇卡車的路線規劃軟體是用於端點大小調整的 Inference Recommender 和用於訓練實例選擇的手動決策樹。擁有所有卡車的貨運公司資本過度；只使用 Spot 的公司不可靠；正確的組合在隨需基載、容忍工作的 Spot，以及可預測穩態的 Savings Plans 之間取得平衡。

用於 SageMaker 端點的 CloudWatch 指標

端點可觀測性是成本優化的基礎。你無法對不能測量的東西進行右型選擇。

每端點呼叫指標

在 AWS/SageMaker 命名空間下，以 EndpointName 和 VariantName 為維度：

• Invocations——每分鐘推論請求計數。
• InvocationsPerInstance——呼叫次數除以實例數；標準自動擴展目標。
• InvocationErrors——4xx 和 5xx 錯誤計數。
• ModelLatency——在模型容器中花費的時間（微秒）。
• OverheadLatency——在 SageMaker 開銷中花費的時間（網路、序列化）。
• InvocationsModelErrors vs InvocationsClientErrors——將上游客戶端錯誤與模型失敗分開。

對於延遲，分別監控 P50、P90 和 P99——平均值具有誤導性，因為尾部延遲主導用戶體驗。

每端點實例使用率指標

在 /aws/sagemaker/Endpoints 命名空間下，以端點名稱、變體和實例為維度：

• CPUUtilization——每核心每實例 CPU 百分比。
• MemoryUtilization——每實例 RAM 百分比。
• GPUUtilization——每實例 GPU 百分比（僅對 GPU 實例類型）。
• GPUMemoryUtilization——GPU 記憶體百分比。
• DiskUtilization——已使用磁碟百分比。

這些以 1 分鐘粒度發出。它們是右型選擇信號——如果 CPUUtilization 平均 15%，實例過大；如果 MemoryUtilization 平均 95%，實例過小。

自訂應用程式指標

容器可以透過 CloudWatch agent 或 Embedded Metric Format 發出自訂指標。對於服務多個模型版本的 ML 服務，按版本標記的自訂指標有助於區分每版本效能。對於批次推論任務，每秒處理記錄數的自訂指標驅動吞吐量調整。

用於 SageMaker 訓練任務的 CloudWatch 指標

訓練任務指標呈現直接轉化為浪費計算支出的低效。

每訓練任務資源指標

在 /aws/sagemaker/TrainingJobs 命名空間下：

• CPUUtilization、MemoryUtilization——每主機。
• GPUUtilization、GPUMemoryUtilization——每主機每 GPU。
• DiskUtilization——EBS 磁碟區使用率。

常見的訓練低效：GPU 使用率維持在 30%，而 CPU 維持在 99%——資料載入器正在瓶頸 GPU。診斷：將輸入模式從 File 切換到 Pipe 或 FastFile，增加資料載入器工作器，或將預處理移到單獨的 Processing 任務。

用於訓練時分析的 SageMaker Debugger

SageMaker Debugger 分析——在模型評估主題中有更深入的介紹——在訓練期間呈現硬體瓶頸。Insights 視圖顯示 GPU 使用率時間線、識別熱點算子，並建議如混合精度訓練、更大批次大小或不同實例類型等優化。Debugger Insights 是 CloudWatch 指標的診斷對應物——後者用於告警，前者用於調試。

為何 GPU 使用率低於 70% 是紅旗

GPU 實例很昂貴。ml.p3.16xlarge 的隨需價格約為 $24/小時。如果 GPU 使用率平均 40%，工作負載在使用不到一半容量的情況下支付全實例費用。修復：增加批次大小、啟用混合精度（FP16）訓練、切換到具有更少 GPU 的實例，或使用 SageMaker Training Compiler 提取更多吞吐量。持續的 GPU 使用率超過 80% 是目標。

GPU 實例選擇——成本驅動的決策樹

GPU 選擇是單一最高影響力的成本決策。MLA-C01 考試測試家族之間的邊界。

主要訓練能力 GPU 家族

• ml.p3（V100）——每實例 4 到 8 個 V100 GPU。較舊但對許多工作負載仍然更便宜。ml.p3.2xlarge 有 1 個 V100；ml.p3.16xlarge 有 8 個。
• ml.p4d（A100）——每實例 8 個 A100 GPU，總共 320 GB GPU 記憶體。大型模型訓練的標準。啟用 EFA 用於分散式訓練。
• ml.p5（H100）——每實例 8 個 H100 GPU，640 GB GPU 記憶體。基礎模型訓練的頂級配置。非常昂貴。
• ml.g5（A10G）——最多 8 個 A10G GPU。比 p4d 更低成本，適合中等工作負載，特別是微調和小到中型訓練。
• ml.g4dn（T4）——較低價格的 T4 GPU；適合推論和輕量訓練。
• ml.trn1（Trainium）——AWS 自訂訓練晶片。對支援的框架，比等效 GPU 實例便宜最多 50%。
• ml.inf2（Inferentia2）——AWS 自訂推論晶片。對支援的模型架構，比 GPU 便宜最多 70%，每次推論成本最低。

訓練實例選擇的決策樹

• 基礎模型預訓練、數十億參數模型、多週任務——ml.p5.48xlarge 帶 EFA 分散式。
• 大型模型訓練（1B-10B 參數）、週長任務——ml.p4d.24xlarge 帶 EFA 分散式。
• 中型模型訓練（100M-1B 參數）、日長任務——ml.p3.16xlarge 或 ml.g5.12xlarge，取決於模型架構。
• 微調預訓練模型、小時長任務——ml.g5.xlarge 到 ml.g5.12xlarge，取決於記憶體需求。
• 表格 ML（XGBoost、Linear Learner）——通常是純 CPU ml.m5 或 ml.c5 家族；GPU 是浪費。
• Trainium 支援的框架（帶 Neuron SDK 的 PyTorch）——如果框架支援已驗證，使用 ml.trn1 節省成本。

推論實例選擇的決策樹

• 高吞吐量低延遲即時推論、複雜深度模型——ml.g5 家族提供高效的 GPU 成本。
• 大規模最低每次推論成本、支援的模型架構——ml.inf2 家族用於 Inferentia2。
• 表格模型、簡單架構——純 CPU ml.m5 或 ml.c5；GPU 是過度設計。
• 突發低量工作負載、偶發請求——帶縮小到零的無伺服器推論。
• 大型非同步批次推論任務——ml.g5 或 ml.inf2 上的非同步端點。

為何 Inferentia 和 Trainium 值得為考試了解

AWS 自訂晶片——用於訓練的 Trainium 和用於推論的 Inferentia——在考試指南中被反覆提及作為成本優化槓桿。Trainium 在支援的工作負載上可節省最多 50% 成本；Inferentia2 可節省最多 70% 成本。問題是：框架支援比 Nvidia GPU 更有限。考試測試候選人是否知道當題幹說「最低成本」加上「支援的框架」——通常是帶有 AWS Neuron SDK 的 PyTorch——時選擇 Inferentia/Trainium。

端點自動擴展——目標追蹤與步驟擴展

服務可變流量的端點必須自動擴展，否則它們在高峰期過度配置，在低谷期浪費。

目標追蹤自動擴展

推薦的擴展策略。為指標設定目標值（通常是 SageMakerVariantInvocationsPerInstance 在每分鐘每實例 1000 次呼叫），SageMaker 調整實例數量以保持指標接近目標。在背後使用 CloudWatch 告警和比例控制邏輯。設定簡單，在流量形狀變化下具有健壯性。

步驟擴展自動擴展

手動策略：當指標超過門檻 A 時，新增 N 個實例；當指標超過門檻 B 時，新增 2N 個實例；當指標低於門檻 C 時，移除實例。比目標追蹤更靈活但更難調整。只在目標追蹤無法捕捉所需行為時使用——例如，非對稱的擴展和縮減速度。

排程自動擴展

對於具有強日間或週間週期性的工作負載（工作日 9 到 5 使用的內部公司模型），基於排程的擴展在已知高峰前預熱實例，並在已知非上班時間縮減。與目標追蹤配對，以防止不可預測的高峰。

自動擴展限制與設定

MinCapacity（最小實例數；永不低於此值縮減）、MaxCapacity（防止失控支出的上限）、ScaleInCooldown 和 ScaleOutCooldown（擴展動作之間等待的秒數；防止抖動）。對於延遲敏感的工作負載，設置較短的 ScaleOutCooldown（60 秒），使高峰被快速吸收；設置較長的 ScaleInCooldown（300 秒），使短暫的低谷不會導致過早縮減。

縮減到零——無伺服器推論

即時端點最少一個實例；它們無法縮減到零。對於有零流量時段的工作負載，使用無伺服器推論端點，自動從零擴展到設定的最大並發執行數，並按呼叫計費。首次呼叫後閒置時會有冷啟動。最適合閒置成本比最壞情況延遲更重要的偶發、突發工作負載。

Managed Spot Training——最多 90% 成本節省

Spot 訓練是 ML 計算的主要成本槓桿。掌握它是必要的。

Spot 定價模型

Spot 實例是 AWS 以大幅折扣出售的閒置 EC2 容量——通常比隨需便宜 70 到 90%——問題是 AWS 在隨需需求上升時可以以兩分鐘通知收回它們。Managed Spot Training 為 SageMaker 訓練任務包裝 Spot，處理中斷邏輯、S3 檢查點和恢復。

設定 Managed Spot Training

Estimator 上的 use_spot_instances=True，加上 max_run（最大訓練時鐘時間，包括中斷）、max_wait（等待 Spot 容量的最大總時間），以及 checkpoint_s3_uri（檢查點落地的位置）。訓練腳本必須定期將檢查點儲存到 /opt/ml/checkpoints/；SageMaker 自動將該目錄同步到設定的 S3 路徑。在中斷時，SageMaker 配置新的 Spot 實例，將檢查點還原到 /opt/ml/checkpoints/，腳本從最近的檢查點恢復。

檢查點頻率決策

檢查點太少（100 個訓練週期中每個週期一次）在每次中斷時浪費數小時的訓練。檢查點太頻繁（每個批次）浪費 I/O 頻寬和儲存。大多數工作負載的甜蜜點：每 30 到 60 分鐘的訓練時間。對於具有昂貴檢查點序列化的非常大的模型，每小時是可以接受的；對於具有廉價檢查點的較小模型，每 15 分鐘更安全。

何時不使用 Spot 訓練

• 硬截止日期工作負載——必須在明天下午 6 點前完成，不論如何；Spot 中斷可能不可預測地延長時鐘時間。
• 沒有檢查點支援的模型——一些自訂訓練腳本無法輕鬆在週期中途設置檢查點。
• 協調成本主導的分散式訓練——在中斷後重啟全歸約協調可能超過成本節省。
• 非常短的訓練任務——30 分鐘以下的任務很少從 Spot 中受益；中斷-恢復開銷比例較高。

實際節省

引用的「最多 90%」假設理想條件。跨多樣工作負載的實際平均值：60-75%。仍然是 SageMaker 堆疊中影響力最高的成本槓桿。

SageMaker Savings Plans——計算承諾折扣

Savings Plans 是第二個成本槓桿，與 Spot 互補。

Savings Plans 如何運作

承諾每小時基準計算支出（每小時 $X）持續一到三年。AWS 以折扣費率（通常比隨需便宜 30-50%）計費所有 SageMaker 計算使用量直到承諾上限。超出承諾的使用量以隨需計費。承諾跨實例類型、區域和 SageMaker 任務類型靈活適用。

一年對比三年、無預付對比全額預付

期限和支付選項使折扣倍增。一年無預付提供最小折扣；三年全額預付提供最大折扣（最多 50%）。選擇取決於現金流偏好和對穩態使用的信心。對於大多數生產工作負載，一年無預付是安全的起點。

Savings Plans 對比 Reserved Instances

SageMaker 提供 Savings Plans，而非 Reserved Instances。標準 EC2 Reserved Instances 不適用於 SageMaker 計費。一些在 SageMaker Notebook Instances 上運行的舊式 ML 部署可能產生 Reserved Instance 適用的計算費用，但主流 SageMaker 訓練任務和端點只由 Savings Plans 覆蓋。

將 Savings Plans 與 Spot 結合

Savings Plans 覆蓋穩態基載——生產端點、每日批次處理任務。Spot 覆蓋間歇性再訓練工作負載。兩者結合為基載提供可預測折扣，為靈活工作提供激進折扣。

何時不購買 Savings Plans

• 需求高度可變的工作負載——承諾超過低需求期使用量的基準浪費承諾。
• 預生產探索性工作——實例類型和數量快速變化；Savings Plans 的不靈活性帶來損害。
• 短期項目——最少一年期超過大多數試點項目的生命週期。

Inference Recommender——右型端點

右型選擇是第三個主要成本槓桿。Inference Recommender 使其自動化。

預設 Recommender 任務

在 Model Registry 中建立模型包，然後以預設模式執行 create_inference_recommendations_job。SageMaker 在 45 分鐘內針對精心策劃的常見實例類型短清單測試模型，並產出按每次推論成本、延遲和吞吐量排名的推薦報告。工程師從排名列表中選擇。

進階 Recommender 任務

指定自訂實例類型集和自訂流量模式（隨時間的請求率、負載大小分佈）。執行時間更長（數小時），產生更深入的基準資料。用於預設短清單不包含候選實例的效能關鍵端點。

用於 SageMaker 的 Compute Optimizer

對於訓練任務，AWS Compute Optimizer 根據歷史 CloudWatch 資料呈現右型選擇建議。有助於追溯識別過度配置的訓練任務，並將未來執行轉移到更便宜的實例。

右型選擇節奏

在每個新模型版本生產部署前執行 Inference Recommender。對於長期端點，每季重新執行——工作負載模式漂移，之前正確的實例選擇可能變得錯誤。

暖池——減少訓練啟動開銷

訓練任務有啟動開銷——配置實例、下載容器、下載訓練資料、初始化框架。對於頻繁短任務的迭代實驗，這種開銷主導了時鐘時間。

暖池的作用

暖池在可設定的保留期（最多 7 天）內在任務之間保持訓練實例叢集已配置。下一個匹配實例類型、實例數量和映像的任務在幾秒鐘而非幾分鐘內開始。成本：在保留視窗期間為暖池的閒置容量付費。

暖池何時划算

對於每 30 分鐘進行 10 分鐘訓練任務迭代超參數 8 小時的工程師，暖池將總時鐘時間縮短 50% 以上。對於每週一次生產重新訓練單一模型的情況，暖池在閒置容量上浪費金錢。

設定

Estimator 上的 KeepAlivePeriodInSeconds。SageMaker 在任務完成後為設定的持續時間維持叢集；下一個相容任務重用它。

ML 工作負載的成本架構模式

成熟的 ML 部署在分層模式中結合多個成本槓桿。

模式一——生產端點堆疊

帶有目標追蹤自動擴展、MinCapacity 2、MaxCapacity 10 的即時端點，在 Inference Recommender 選擇的實例家族上，由 Savings Plan 覆蓋基準容量。一個用於大負載離線評分的非同步端點。如果模型架構支援 Neuron SDK，使用 Inferentia2 實例。

模式二——迭代訓練堆疊

帶有頻繁檢查點的 Spot 訓練，max_run 4 小時，max_wait 24 小時，在 ml.g5 家族上以獲得高效 GPU 成本。在活躍開發衝刺期間啟用 7 天保留期的暖池，非迭代時禁用。Savings Plan 覆蓋小的穩態基準；Spot 用於大部分計算。

模式三——偶發推論堆疊

無伺服器推論端點從零擴展到設定的最大並發執行數。沒有 Savings Plan（工作負載變化太大）。如果冷啟動延遲不可接受，為已知高峰視窗提供配置並發。

模式四——基礎模型訓練堆疊

帶有 EFA 分散式網路的 ml.p4d 或 ml.p5 叢集，隨需定價（多日任務的 Spot 中斷是災難性的），覆蓋承諾計算的 3 年全額預付 Savings Plan，頻繁檢查點到 S3 用於容錯。

MLA-C01 成本優化常見考試陷阱

陷阱一——Spot 訓練總是節省 90%

錯誤。引用的最大值是 90%；實際平均值取決於中斷頻率和檢查點效率，為 60-75%。沒有適當檢查點的工作負載在 Spot 上比隨需花費更多，因為中斷時的冗餘計算。

陷阱二——Savings Plans 適用於所有 AWS 服務

錯誤。SageMaker Savings Plans 只覆蓋 SageMaker 計算。Compute Savings Plans（不同的產品）覆蓋 EC2、Lambda 和 Fargate，但不覆蓋 SageMaker。考試測試哪種 Savings Plan 適用於哪種服務。

陷阱三——即時端點可以縮減到零

錯誤。即時端點的最小容量為 1（通常為 2 用於高可用性）。要縮減到零，使用無伺服器推論端點。考試設置縮減到零是需求的題幹；無伺服器是答案。

陷阱四——自動擴展步驟策略是預設值

錯誤。目標追蹤是推薦的預設值。步驟擴展用於進階案例。

陷阱五——暖池是免費的

錯誤。暖池在保留視窗期間為閒置容量計費。只在活躍迭代期間使用才具有成本效益。

陷阱六——Inferentia 實例執行任何模型

錯誤。Inferentia 需要 AWS Neuron SDK，並支援特定的模型架構清單。清單外的模型無法在 Inferentia 上執行。

陷阱七——更多 GPU 總是訓練更快

錯誤。分散式訓練有可能主導計算的通信開銷。對於能放在單個 GPU 上的模型，單實例訓練通常比多實例分散式更快且更便宜。

陷阱八——CloudWatch 指標在任何量都是免費的

錯誤。CloudWatch 指標每個 AWS 帳戶的前 10 個是免費的，之後收費。高基數的自訂指標可能產生出人意料的 CloudWatch 帳單。

陷阱九——Savings Plans 折扣在每個區域相同

部分正確。Savings Plans 跨區域、實例類型和 SageMaker 計算類型靈活，但公布的折扣率是針對特定區域中特定實例家族的。跨區域使用的折扣率可能低於標題率。

陷阱十——Compute Optimizer 對端點進行右型選擇

錯誤。Compute Optimizer 為 EC2 和 SageMaker 訓練任務呈現建議。端點右型選擇是 SageMaker Inference Recommender 的工作。

必記數字與重要事實

CloudWatch 指標

• AWS/SageMaker 命名空間用於呼叫指標
• /aws/sagemaker/Endpoints 用於實例使用率
• /aws/sagemaker/TrainingJobs 用於訓練指標
• 預設 1 分鐘粒度
• 始終分別監控 P50、P90、P99 延遲

自動擴展

• SageMakerVariantInvocationsPerInstance 上的目標追蹤是預設值
• 即時端點最小容量 1；無法縮減到零
• 無伺服器推論從零擴展到設定的最大並發
• 始終設置 MaxCapacity 作為失控支出防護欄

Spot 訓練

• 宣傳最多 90% 節省；實際 60-75%
• 需要 checkpoint_s3_uri 並寫入 /opt/ml/checkpoints/
• max_run 和 max_wait 參數是強制的

Savings Plans

• 一年或三年期限
• 無預付、部分預付、全額預付支付選項
• 只覆蓋 SageMaker 計算——不覆蓋 EC2 或 Lambda
• 與 Spot 結合以分層成本覆蓋

GPU 家族

• ml.p3（V100）、ml.p4d（A100）、ml.p5（H100）用於訓練
• ml.g5（A10G）用於高效訓練和推論
• ml.inf2（Inferentia2）推論便宜最多 70%
• ml.trn1（Trainium）訓練便宜最多 50%

工具

• Inference Recommender 用於端點右型選擇（預設 45 分鐘，進階數小時）
• Compute Optimizer 用於訓練任務右型選擇
• 暖池用於迭代訓練（最多 7 天保留期）

FAQ——成本優化熱門考試問題

Q1——團隊的 GPU 訓練叢集在 8 GPU ml.p4d 實例上的使用率為 30%。正確的成本優化是什麼？

在更換實例之前先診斷瓶頸。CPU 在 99% 表明資料載入器正在瓶頸 GPU——切換到 Pipe 或 FastFile 輸入模式並增加資料載入器工作器。如果修復資料管線後 GPU 使用率仍然低，工作負載不需要 8 個 GPU——切換到較小的實例如 ml.p4d.24xlarge（較少 GPU），或切換到 ml.g5.12xlarge 以獲得更低的每小時費率。執行 SageMaker Debugger 分析以確認瓶頸根本原因。在未分析的瓶頸上使用更小的實例是猜測；考試偏好先診斷的答案模式。

Q2——即時端點平均每分鐘服務 50 個請求，但偶爾高峰到 5000 個。最具成本效益的設定是什麼？

流量模式是突發性且平均值低。兩個可行選項。選項 A：帶有目標追蹤自動擴展的即時端點，MinCapacity 1，MaxCapacity 根據高峰大小，目標約每實例每分鐘 1000 次呼叫——即使在安靜期間也持續為至少一個實例付費。選項 B：從零擴展的無伺服器推論端點，按呼叫計費——在空閒期間不付費，但首次空閒後請求有冷啟動延遲。如果冷啟動延遲可以接受，選選項 B；如果每個請求必須低於 100ms，選選項 A。無伺服器上的配置並發是第三個選項，用於溫熱但仍按分鐘計費的行為。

Q3——團隊啟用了帶有 use_spot_instances=True 的 Managed Spot Training，但下一個訓練任務的實際成本高於隨需基準。為什麼？

幾乎可以肯定是缺少檢查點設定。沒有 checkpoint_s3_uri 和訓練腳本寫入 /opt/ml/checkpoints/，每次 Spot 中斷都會丟棄所有進度，任務從頭重新開始。多次中斷後，總計算時間超過隨需時鐘時間。修復：設定檢查點，每 30-60 分鐘的訓練時間寫一次，適當設定 max_run 和 max_wait。在第一次訓練執行期間透過檢查設定的 S3 路徑來驗證檢查點是否工作。

Q4——生產端點 24/7 以穩定流量執行。團隊希望在不改變行為的情況下降低成本。正確的方法是什麼？

購買覆蓋穩態每小時計算支出的 SageMaker Savings Plan。一年無預付期限提供約 30% 折扣；三年全額預付提供最多 50% 折扣。端點設定不變；帳單只是打折。與 Inference Recommender 結合，驗證當前實例類型是否右型選擇——如果過度配置，先縮小尺寸，然後在較小的基準上承諾 Savings Plan。不要為過度配置的端點承諾 Savings Plan；節省會鎖定浪費。

Q5——如何監控端點的尾部延遲違規而非平均延遲？

CloudWatch 指標 ModelLatency 作為統計指標發出——在 CloudWatch 中繪製時，將統計指標設為 p99（或 p99.9）。在 p99 統計上建立告警，門檻與你的 SLA 匹配。與獨立的平均延遲告警配對作為合理性檢查，但 p99 告警是用戶體驗信號。EventBridge 訂閱告警狀態變更，並路由到 PagerDuty 用於尾部延遲事件回應。平均延遲告警完全錯過尾部問題，是考試的錯誤答案模式。

Q6——團隊正在訓練一個需要最少 8 個 GPU 且執行 5 天的 10 億參數語言模型。他們應該使用 Spot 訓練嗎？

可能不應該。在 Spot 上執行 5 天的分散式訓練任務風險很高：每次中斷需要完整的分散式叢集重啟、通信成本重新初始化，以及從最新檢查點恢復。累積的中斷開銷可能將時鐘時間延長數天。對於多日分散式訓練，隨需更安全。用覆蓋承諾計算的 3 年 SageMaker Savings Plan 緩解成本。為較短、較簡單的訓練任務（單實例、日以下時鐘時間）保留 Spot，其中中斷成本是有限的。

Q7——如何在沒有手動基準測試的情況下對 SageMaker 端點進行右型選擇？

執行 SageMaker Inference Recommender。在 Model Registry 中登記模型，以預設模式執行 create_inference_recommendations_job（45 分鐘針對精心策劃的實例短清單）適合大多數情況，或以進階模式（自訂實例集、自訂流量模式）適合效能關鍵工作負載。輸出按每次推論成本、P99 延遲和吞吐量排名實例類型。選擇滿足延遲 SLA 的最便宜實例。每季重新執行；工作負載模式漂移，之前正確的選擇可能變得錯誤。

延伸閱讀——官方 AWS 文件

權威的 AWS 來源是 SageMaker 開發人員指南（CloudWatch 監控、自動擴展、Spot 訓練、Savings Plans、Inference Recommender、暖池、檢查點部分）、用於 SageMaker 的 AWS 定價計算器（互動式成本建模）、AWS Well-Architected Framework 成本優化支柱（一般原則），以及用於 AWS 自訂晶片決策的 AWS Trainium 和 Inferentia 文件。MLA-C01 官方考試指南在 Domain 4 Task 4.2 下特別強調成本優化；Skill Builder MLA-C01 準備計劃強化了真實考試測試的 GPU 實例選擇和 Spot 檢查點模式。