AWS 機器學習架構框架Part 4

模型開發

模型開發包括模型”建構、訓練、調整和評估”。在模型開發階段,選擇適合問題的ML演算法,然後訓練 ML 模型。 為演算法提供訓練資料,為 ML 模型設定要最佳化的客觀指標,並設定超參數來優化訓練過程。

模型訓練、調整和評估需要準備好的資料和特徵工程。 此階段的主要活動如下,如下圖所示:

  • Features-在保證資料品質後,選擇特徵作為資料處理的一部分
  • Building code-模型開發包括建構演算法及其支援代碼。 代碼建置過程應該有版控以及透過pipeline持續"建置、測試和整合"。
  • Algorithm selection-選擇正確的演算法涉及透過可用選項進行參數調整來運行許多實驗。 評估每個選項時要考量的因素包括成功指標、模型可解釋性和運算需求(訓練/預測時間和記憶體需求)。
  • Model training(data parallel、model parallel)-訓練 ML 模型的過程涉及向演算法提供學習的訓練資料。 分散式訓練可以跨運算實例分割大型模型和訓練資料集,從而減少訓練時間。 Model parallelism與data parallelism是實現分散式訓練的技術。
    — Model parallelism是在多個實例或節點之間拆分模型的過程。
    —Data parallelism是將訓練集分割為小批量,均勻分佈在節點上的過程。 因此,每個節點只在總資料集的一小部分上訓練模型。
  • Debugging/profiling-ML訓練作業可能的問題包括:系統瓶頸、過度擬合、飽和活化函數(saturated activation functions)和梯度消失(vanishing gradients)。 這些問題可能會損害模型效能。 debugger透過監控、記錄和分析資料提供ML訓練過程的可見性。 它定期捕捉訓練作業的狀態。
  • Validation metrics — 通常,訓練演算法會計算多個指標,例如loss and prediction accuracy。 這些指標決定了模型是否能夠很好地學習和泛化(generalizing),從而對未見過的資料進行預測。 演算法報告的指標取決於業務問題和所使用的ML技術。 例如,confusion matrix是用於分類模型的指標之一,而RMSE(Root Mean Squared Error)是用於迴歸模型的指標之一。
  • Hyperparameter tuning-可以調整以控制ML演算法行為的設定稱為超參數。 ML演算法中超參數的數量和類型特定於每個模型。 常用超參數的範例包括:learning rate/number of epochs/hidden layers/hidden units /activation functions。 超參數調整或最佳化是為演算法選擇最佳超參數的過程。
  • Training code container— 使用訓練代碼及其整個相依性堆疊建立container images。 這將使任何規模的模型快速可靠地訓練和部署成為可能。
  • Model artifacts-模型工件是訓練模型所產生的輸出。 它們通常由經過訓練的參數、描述如何運算inferences的模型定義以及其他metadata組成。
  • Visualization — 能夠在指標驗證、debugging、分析和超參數調整期間探索和理解資料。

上圖呈現了pre-production pipelines。 Data prepare pipeline可自動執行資料準備任務。 Feature pipeline自動將特徵儲存、提取和複製到online/offline store。 CI/CD/CT pipeline可自動建置、訓練並發佈到staging和peoduction環境。

模型評估

模型訓練完成後,評估其效能和成功指標。 我們可能希望使用不同的方法產生多個模型並評估每個模型的有效性。 也可以評估模型是否"more sensitive than specific, or more specific than sensitive"。 對於multiclass models,分別確定每個類別的錯誤率(error rates)。

我們可以使用歷史資料(offline evaluation)或即時資料(online evaluation)來評估模型。 在離線評估中,使用已保留的資料集的一部分來評估訓練後的模型。 這些保留資料不會用於模型的"訓練或驗證" — 它僅用於評估最終模型中的錯誤。 holdout data annotations必須具有較高的指定標籤正確性,評估才有意義。 分配額外資源來驗證保留資料的正確性。

根據評估結果,可以對資料和(或)演算法進行微調。 當微調資料時,可以應用資料清理、準備和特徵工程的概念。

上圖包括模型效能評估、資料準備和 CI/CD/CT pipeline,用於微調資料和(或)演算法、重新訓練和模型結果評估。

卓越維運支柱 — 最佳實踐

卓越營運支柱包括運作和監控系統以提供業務價值並持續改善支援流程和程序的能力。 本節包括開發模型時要考慮的最佳實踐,包括訓練、調整和模型效能評估。

實踐一: 透過MLOps與CI/CD實行自動化操作

使用IaC和CaC (configuration as code) 自動執行 ML workload作業。 選擇適當的 MLOps 機制來編排 ML 工作流程並與 CI/CD pipeline整合以實現自動化部署。 此方法可確保staging和production部署環境之間的一致性。 跨託管基礎架構地啟用模型的可觀察性和版控。

執行計畫

我們可以使用CloudFormation或CDK:

  • AWS CloudFormation —
    CloudFormation 就是一種template file作為單一單元(stack)一起建立和刪除資源集合,從而可預測地重複建立和預置 AWS 部署。 這可以跨多個 AWS 帳戶和 AWS 區域管理和配置堆疊。
  • AWS CDK —
    CDK作為軟體開發框架用於在代碼中定義雲端基礎架構並透過 AWS CloudFormation 進行預配置。 可以使用熟悉的程式語言在 AWS CDK 中定義雲端資源。

我們可以根據 ML 工作流程選擇以下任一 MLOps 策略:

  • 使用 SageMaker Pipelines 來編排工作流程

使用 SageMaker Pipelines,可以使用 Python SDK 建立 ML 工作流程,然後使用 SageMaker Studio 視覺化和管理工作流程。 SageMaker Pipelines 記錄工作流程的每一步,建立模型組件(例如訓練資料、平台配置、模型參數和學習梯度)的稽核追蹤。

  • 使用Step Functions — 也可以使用適用於 SageMaker 的 Step Functions Data Science SDK 來自動訓練ML模型。 定義工作流程中的所有步驟並設定告警來啟動流程。
  • 使用第三方工具 — 使用與AWS 服務API 整合的第三方部署編排工具(例如Apache Airflow)來自動執行模型訓練和部署。Managed Workflows for Apache Airflow (MWAA) 使用以Python 編寫的有向無環圖(DAG) 來編排工作流程。

實踐二: 建立可靠的打包模式以存取經過批准的public libraries

為資料科學家建立可靠的打包模式,其中包括 (a) 使用提供public libraries存取權限的內部儲存庫,以及 (b) 為通用ML框架建立單獨的核心。 此類常見 ML 框架的範例包括 TensorFlow、PyTorch、Scikit-learn 和 Keras。

執行計畫

  • 使用容器技術 — 使用或引入客製容器並將其儲存在 ECR 中。 使用容器,我們可以訓練ML演算法並快速可靠地部署任何規模的模型。
  • 使用工件儲存庫 — 設定 CodeArtifact 以用作集中式內部工件儲存庫。 這將使我們能夠從內部儲存庫中提取工件並重複使用它們。

安全支柱 — 最佳實踐

安全支柱包括保護資料、系統和資產的能力,以利用雲端技術來提高安全性。 本節包括模型開發期間要考慮的最佳實踐,包括模型訓練、調整和模型效能評估。

實踐一: 保護受治理的ML環境

使用託管服務和最佳實踐來保護ML運作環境,包括:偵測性和預防性護欄(guardrails)、監控、安全性和事故管理。 在託管且安全的開發環境中探索資料。 集中管理開發環境的配置並為使用者提供自助式服務配置。

執行計畫

  • 依單位存取模式劃分 ML workload。 這將允許將所需的存取權限委派給每個群體,例如管理員或資料分析師。
  • 使用護欄(guardrails)和SCP(service control policies)為每種環境類型實施最佳實踐。 限制管理員對基礎設施管理存取權限。
  • 驗證所有敏感資料是否可以透過受限、隔離的環境進行存取。 確保網路隔離、專用資源並檢查服務依賴性。
  • 使用受限的開發環境實現安全的 ML 演算法。 透過遵循組織所需的安全流程來保護模型訓練和託管容器。

實踐二: 保護inter-node cluster中的通訊

對於 TensorFlow 等框架,共享係數等資訊作為inter-node cluster通訊的一部分是很常見的。 此演算法要求交換的資訊在節點之間保持同步。 透過傳輸加密來保護此資訊。

執行計畫

  • 在 SageMaker 中啟用節點間加密 —
    在分散式運算環境中,節點之間傳輸的資料可以穿越大範圍的網路,甚至Internet。 透過對所選的技術進行適當的控制來實現節點間加密。 我們可以讓 SageMaker 自動加密訓練作業的容器間的通訊,以確保資料透過加密通道傳遞。
  • 在 EMR 中啟用傳輸中加密 —
    Hadoop 生態系統中有許多應用程式和執行引擎,提供各種工具來滿足 ML 和分析工作負載的需求。 EMR 具有分散式叢集功能,也是對本機儲存在叢集或 S3 中的資料運行訓練作業的選項。 EMR 建立和管理執行 Hadoop 和 Hadoop 生態系統中其他應用程式的完全配置的彈性 EC2 instance 叢集。 EMR 提供安全配置來設定儲存在 S3 和本機 EBS 上的靜態資料加密。 還可以設定TLS憑證以加密傳輸中的資料。

實踐三: 防範資料中毒威脅

防止data injection和data manipulation來污染訓練資料集。 data injection可能會加入損壞的訓練資料,從而導致不正確的模型和輸出。data manipulation可能會更改現有資料(例如標籤),導致預測模型不準確。 使用安全方法和anomaly detection algorithms識別並解決損壞的資料和不準確的模型。 透過針對已安裝的第三方軟體包中的勒索軟體和惡意代碼提供保護,確保資料集的不變性。

執行計畫

  • 只使用受信任的資料來源作為訓練資料 —
    驗證我們是否有足夠的稽核控制來replay活動並確定變更發生的位置、由誰以及何時發生。 在訓練之前,驗證訓練資料的品質,以訓找強烈的異常值和可能不正確的標籤。
  • 尋找訓練資料中模式和分佈的潛在變化 —
    透過監控資料漂移(data drift),得出對預測變異數的影響。 這些偏差可以作為潛在資料漂移的指標,並且可以針對針對訓練資料的未經授權的存取提供早期告警。
  • 在將結果投入生產之前識別對結果產生負面影響的模型更新 —
    確定重新訓練的模型結果是否與過去的模型迭代不同。 使用過去的測試資料和先前的模型迭代作為基準。
  • 制訂rollback plan —
    使用版本化訓練資料和版本化模型,確保可以在故障情境中恢復到已知的良好工作模型。 使用完全託管的服務來儲存功能,例如 SageMaker Feature Store。
  • 使用低熵分類(low-entropy classification)案例 —
    尋找顯著的、意外的變化。 確定閾值範圍,識別不希望看到的分類,並在重新訓練的模型超出閾值時發出告警。

可靠度支柱 — 最佳實踐

可靠性支柱包括Workload正確一致地執行其預期功能的能力。 本節包括模型開發期間要考慮的最佳實踐,包括模型訓練、調整和模型效能評估。

實踐一:實現具有可追溯性的 CI/CD/CT 自動化

啟用 ML Workload的原始代碼、資料和工件版控,以支援rollback到特定版本。 將持續整合 (CI)、持續交付 (CD) 和持續訓練 (CT) 實踐納入 ML workload操作。 這將實現自動化並增加可追溯性。

執行計畫
使用 SageMaker Pipelines — 手動變更系統可能會花費額外的時間並損害可重複性。 ML Workload的變更應該自動"進行、追蹤和rollback"。 MLOps 是圍繞整合和部署可重複、可稽核變更的最佳實踐的集合。 MLOps 可以提工作效率,同時實現 ML 開發週期 各個方面的自動化。SageMaker Pipelines 是第一個專門建置的 CI、CD 和 CT 服務。 借助 SageMaker Pipelines,大規模創建、自動化和管理端到端 ML 工作流程。

實踐二: 確保訓練和推論(inference)過程中的特徵一致性

使用feature storage確保訓練和推論之間的特徵一致、可擴展且高度可用。 透過保持"訓練和推論"之間的特徵一致性來減少training-serving skew。

執行計畫
使用 SageMaker Feature Store 建立、共用和管理用於 ML 開發的功能。Feature Store是feature和相關metadata的集中存儲,因此可以發現和重複使用feature。 Online store用於低延遲、即時推論。 Offline store用於訓練和批量推論(batch inference)。 Feature store減少了將原始資料轉換為訓練 ML 演算法的特徵所需的重複資料處理和管理工作。 產生的特徵將用於訓練和推論,減少training-serving skew。 Feature store可實現特徵一致性、特徵標準化以及與SageMaker Pipelines 整合的能力。

實踐三: 確保使用相關資料進行模型驗證

制定流程以包含用於"測試和驗證"的真實且具代表性的資料。 一旦模型投入生產,不包含所有可能模式和場景的資料將導致失敗。 檢查"訓練、驗證和測試"資料以及推理資料之間的分佈不匹配。

執行計畫

  • 使用SageMaker Experiments
    模型應該使用代表它們在生產環境中遇到的情況的資料進行測試和驗證。 這些資料可以包括現實世界資料和工程資料。 應該考量訓練資料中的所有場景,以便在將模型部署到生產時會發生錯誤。 使用SageMaker Experiments "組織、追蹤、比較和評估"ML Experiments。
  • 使用SageMaker Model Monitor
    考慮實施一項計劃來定期測試endpoint是否存在模型品質偏差。 及早發現偏差(deviations)可以確定何時採取糾正措施。 SageMaker Model Monitor 持續監控生產環境中的SageMaker ML 模型的品質。 使用Model Monitor,可以設定告警,以便在模型品質出現偏差時收到通知。

實踐四: 設立資料偏差的偵測和緩解

偵測並減輕偏差以避免模型結果不準確。 在訓練開始前的"資料準備階段"建立偏差偵測方法。 模型投入生產後監控、偵測、減輕偏差。 建立反饋循環來追蹤一段時間內的漂移並啟動重新訓練。

執行計畫
使用SageMaker Clarify — SageMaker Clarify 透過偵測潛在偏差並幫助解釋模型如何進行預測來幫助改善ML模型。 SageMaker Clarify 提供的公平性和可解釋性功能進一步幫助建立值得信賴且易於理解的 ML 模型。 Clarify 可協助完成以下任務:

  • 衡量ML生命週期每個階段可能出現的偏差。 這些階段包括資料收集、模型訓練、模型調整和模型監控。
  • 產生針對風險和合規團隊以及外部監管機構的模型治理報告。
  • 提供評估預測的資料、模型和監控的解釋。

效能效率支柱 — 最佳實踐

效能效率支柱著重於有效利用運算資源來滿足需求,並隨著需求變化和技術發展保持效率。 本節包括模型開發期間要考慮的最佳實踐,包括模型訓練、調整和模型效能評估。

實踐一: 優化"訓練與推論"的實例類型(instance types)

確定模型類型和資料速度如何影響訓練和推論實例類型的選擇。 確定支援記憶體密集型訓練或具有高吞吐量和低延遲即時推論的計算密集型訓練的正確實例類型。 模型推論的速度直接受到模型複雜度的影響。 選擇高計算實例可以加快推論速度。 GPU 通常是訓練許多深度學習模型的首選處理器類型。 CPU 通常足以滿足推論workload。

執行計畫
嘗試使用替代實例類型進行訓練和部署 — 確定哪些實例類型最適合我們的 ML 演算法和使用案例。 使用多個實例對大型資料集進行訓練,以充分利用規模優勢。

實踐二: 探索效能改善的替代方案

執行基準測試(benchmarks)以提高ML模型的效能。 ML 中的基準測試涉及對具有不同演算法、功能和架構資源的 ML workload進行評估和比較。 它能夠識別具有最佳效能的組合。基準測試時可以使用的選項包括:

  • 使用更多資料來擴大統計範圍並提高模型的成功指標。
  • 應用特徵工程來提取模型資料中的重要訊號。
  • 選擇替代演算法以最佳地適應資料的具體情況。
  • 結合多個模型的不同優點的整合方法。
  • 調整特定演算法的超參數以校準資料模型。

執行計畫
使用 SageMaker Experiments 來優化演算法和特徵 — 從簡單的架構、明顯的功能和簡單的演算法開始建立基準。 SageMaker 提供開發基準模型的內建演算法。 使用 SageMaker Experiments 組織、追蹤、比較和評估ML experiments。 測試越來越複雜的不同演算法以觀察效能。 將模型組合成一個整體以提高準確性,但要權衡潛在的效率損失。 透過選擇和修改參數來細化特徵以優化模型性能。 使用 SageMaker Hyperparameter Optimization 來自動執行搜索,調整模型的超參數以優化效能。

實踐三:建立模型效能評估pipeline

使用end-to-end performance pipeline擷取與模型效能相關的關鍵指標,以評估模型的成功。 根據使用案例和業務 KPI 選擇特定指標。 範例關鍵指標包括訓練或驗證錯誤以及預測準確度。 特定的模型效能指標包括RMSE(Root Mean Squared Error)、accuracy、precision、recall、F1 score和AUC(area under the curve)。 建立全自動校能測試pipeline系統,每次有更新的模型或資料時啟動評估。

執行計畫
使用SageMaker Pipelines 建立端到端工作流程 — 從工作流程範本開始,為模型訓練和部署建立初始基礎架構。 SageMaker Pipelines 可自動執行 ML 工作流程的不同步驟。 這些步驟包括資料載入、資料轉換、訓練、調整和部署。 借助 SageMaker Pipelines,可以共享和重複使用工作流程來重新建立或優化模型。 在 SageMaker Pipelines 中,SageMaker Model Registry 追蹤模型版本和對應的工件。 這些工件包括在整個模型開發生命週期中收集的元資料和lineage data。 SageMaker Model Registry 也可以使用 CI/CD 實作模型自動部署。

實踐四: 建立特徵統計

建立主要統計資料來衡量影響模型結果的資料變化。 資料變化對模型推論的影響取決於模型對資料特徵的敏感度。 分析模型的特徵重要性和敏感性來選擇要監控的特徵。 監控對推論影響最大的特徵的統計資料。 對資料範圍設定可接受性限制,以便在重要特徵超出訓練資料的統計範圍時發出告警。 重要特徵的顯著變化建議重新訓練模型。

執行計畫
分析和評估資料 — 使用SageMaker Data Wrangler 分析所選則特徵的分佈。 訓練模型後,繪製特徵空間(feature space)中預測突然變化和不變的區域。 使用 SageMaker Model Monitor 建立監控資料的baseline。 對模型決策邊界附近的特徵值變化進行敏感度分析。 分析特徵重要性以了解新資料將如何影響模型的預測。SageMaker Experiments 將有助於組織模型測試。 使用 SageMaker Clarify 檢查資料"偏差和不平衡"。 監控生產推論中使用的資料統計。 如果特徵超出訓練資料的原始分佈,考慮重新訓練模型。

實踐五: 進行效能權衡分析

執行替代權衡分析,以獲得特定使用案例資料和業務需求的最佳效能和準確性。

  • 準確度與複雜性的權衡:
    ML模型越簡單,其預測就越容易解釋。 深度學習預測的表現可能優於線性迴歸或決策樹演算法,但代價是增加了可解釋性和可解釋性的複雜性。
  • 偏差(Bias)與公平性(Fairness)的權衡:
    定義管理模型效能"偏差與公平(bias and fairness)"風險的流程。 商業價值通常與考量了訓練資料中的歷史或抽樣偏差的模型一致。 應進一步考量不準確的模型預測的不同影響。 例如,代表性不足的群體往往更容易受到歷史偏見的影響,這可能會使不公平的做法長期存在。
  • 偏差(Bias)與變異數(Variance)權衡(監督式ML):
    目標是針對特定資料集實現具有最低偏差與變異數權衡的訓練模型。 為了幫助克服偏差和變異錯誤,我們可以使用:
    — Cross validation
    — More data
    — Regularization
    — Simpler models
    — Dimension reduction (Principal Component Analysis)
    — Stop training early
  • Precision與Recall權衡(監督式ML):
    當Precision比recall更重要時,這種分析可能很重要,反之亦然。 例如,當目標是減少誤報(false positives)時,Precision最佳化更為重要。 然而,當目標是減少false negatives時,Recall的最佳化更為重要。 不可能同時擁有High Precision與 High Recall — — 如果一個增加,另一個就會減少。 權衡分析有助於確定分析的最佳選項。

執行計畫
建立替代工作流程以優化業務價值的各個面相 — 複雜的模型可以提供高精確度。 如果業務需求包括低延遲,則可能需要簡化模型並降低複雜性。 確定權衡如何影響推論的準確性和延遲。 使用 SageMaker Experiments 測試這些權衡,以追蹤每種模型類型。 SageMakerClarify 提供了用於評估預測的資料、模型和監控的說明。 它可以測量ML生命週期每個階段的偏差。 提供的解釋將有助於理解公平性如何影響業務使用案例。 複雜的ML模型給予推論的速度可能較慢,並且更難以在邊緣環境中部署。 SageMaker Neo 讓開發人員能夠優化 ML 模型,以在雲端中的 SageMaker 和邊緣支援的裝置上進行推論。

實踐六: 使用transfer learning時偵測效能問題

監視並確保從轉移模型繼承的預測權重產生所需的結果。 這種方法有助於最大限度地減少使用預訓練模型的弱學習和錯誤輸出的風險。

執行計畫
使用SageMaker Debugger — Transfer Learning是一種ML技術,其中針對一項任務預訓練的模型針對新任務進行微調。 使用Transfer Learning方法時,使用SageMaker Debugger 來偵測可能會產生嚴重後果的隱藏問題。 檢查模型預測,看看犯了哪些錯誤。 驗證模型的穩健性,並考慮這種穩健性有多少來自繼承的功能。 驗證模型的輸入和預處理以獲得現實的預期。

成本優化支柱 — 最佳實踐

成本優化支柱包括系統在整個生命週期中的持續細緻化和改進過程。 從第一個PoC的初始設計到production workloads的持續運行,採用本文中的實踐可以構建和運營具有成本意識的系統,從而實現業務成果並最大限度地降低成本,從而使業務最大化它的投資回報。 本節包括模型開發期間要考慮的最佳實踐。

實踐一: 選擇最優的computing instance size

根據用於最大效率和降低成本的 ML 演算法調整訓練實例的大小。 使用debugging功能了解訓練期間要使用的正確資源。 簡單模型可能無法在較大實例上訓練得更快,因為它們可能無法從額外的運算資源中受益。 由於 GPU communication overhead較高,這些模型甚至可能訓練速度較慢。 從較小的實例開始,並根據需要進行擴展。

執行計畫

  • 使用SageMaker Experiments —
    EC2 提供了多種經過最佳化以適應不同用例的實例類型。 ML workload可以使用 CPU 或 GPU 實例。 根據 ML 演算法的需求,從可用的 EC2實例類型中選擇。 對 CPU 和 GPU 實例進行實驗,以了解哪一種可為提供最佳成本配置。 SageMaker 可使用單一實例或 GPU 實例的分散式叢集。 使用 SageMaker Experiments 評估替代選項,並確定可產生最佳結果的規模。 透過按時間和資源細分定價,可以優化 SageMaker 的成本,並且只需支付所需的費用。
  • 使用SageMaker Debugger —
    SageMaker Debugger 自動監控系統資源(例如 GPU、CPU、網路和記憶體)的使用率,並分析訓練作業以收集詳細的 ML 框架指標。 可以透過 SageMaker Studio 直觀地檢查所有資源指標,並在資源利用率不足時採取糾正措施以優化成本。

實踐二: 使用託管建置環境

考慮使用託管notebooks而不是本地或伺服器上託管的。 託管notebooks捆綁了安全性、網路、儲存、運算功能,而不需要花費大量時間和資源在本地進行相同作業。 託管 ML 建置環境還可以很容易決定喜歡的機器類型,因此無需管理任何複雜的 AMI 或Security Group — 這使得入門變得非常容易。 它還可以提供對 GPU 和具有大量 RAM 的大型機器的存取,這在本地設定上可能是很困難的。

執行計畫

  • 使用SageMaker Notebooks —
    SageMaker notebook instance是執行 Jupyter Notebook App的 ML 計算實例。 SageMaker 管理建立實例和相關資源。 在notebook instance中使用 Jupyter Notebook來準備和處理資料、編寫代碼來訓練模型、將模型部署到 SageMaker 託管以及測試或驗證模型。 SageMaker 提供無需設定的託管 Jupyter Notebook,因此可以立即開始處理訓練資料集。 只需在 SageMaker 控制台中點擊幾下,就可以建立完全託管的notebook instance,並預先載入有用的機器學習庫。 只需要新增資料。
  • 使用SageMaker Studio —
    geMaker Studio 提供了一個Web-based 的單一視覺化介面,可以在其中執行所有 ML 開發步驟,從而提高資料科學團隊的工作效率。 SageMaker Studio 提供建置、訓練和部署模型所需的每個步驟的完整存取、控制和可見性。 可以在一個地方快速上傳資料、建立新的notebooks、訓練和調整模型、在步驟之間來回移動以調整實驗、比較結果以及將模型部署到生產中,從而提高工作效率。 所有 ML 開發活動(包括notebook、實驗管理、自動模型建立、偵錯以及模型和資料漂移偵測)都可以使用 SageMaker Studio 執行。
  • 使用SageMaker Canvas —
    ageMaker Canvas 是一種新的視覺化、no code功能,可讓業務分析師建立 ML 模型並產生準確的預測,而無需編寫代碼或不需要 ML 專業知識。 其直覺的使用者介面可瀏覽和存取雲端或本地的不同資料來源,只需點擊按鈕即可組合資料集,訓練準確的模型,然後在新資料可用時產生新的預測。

實踐三: 選擇本地訓練進行小規模實驗

評估在雲端中與本地電腦上訓練 ML 模型的要求。 在使用小量資料試驗不同演算法和配置時,請使用本地電腦選項。 對於大數據,啟動具有一個或多個計算實例的基於雲端的訓練叢集。 根據Workload調整訓練叢集中計算實例的大小。

執行計畫
使用SageMaker — 在嘗試使用小型資料集訓練模型時,請使用 SageMaker notebook local mode。 這將在notebook instance本身上訓練模型,而不是在單獨的託管訓練叢集上。 可以迭代和測試作業,而不必每次都等待新的訓練或託管叢集。 這節省了與建立託管訓練叢集相關的時間和成本。 實驗也可以在notebook電腦之外進行,例如在本機電腦上。 可以在本機上使用 SageMaker SDK 在 AWS 上訓練和部署模型。

實踐四: 選擇最佳的ML框架

組織、追蹤、比較和評估ML實驗和模型版本。 確定實例類型和ML框架的最具成本效益和最佳組合。 ML 框架的範例包括 TensorFlow、PyTorch 和 Scikit-learn。

執行計畫
使用SageMaker Experiments —SageMaker Experiments 可”組織、追蹤、比較和評估”ML實驗。 使用此服務,可以嘗試各種 ML 框架,看看哪一個提供最具成本效益的效能。 AWS Deep Learning AMI 和 AWS Deep Learning Containers 能夠使用多個開源 ML 框架對基礎設施進行訓練。 AWS Deep Learning AMI 預先安裝了流行的深度學習框架和介面,包括 TensorFlow、PyTorch、Apache MXNet、Chainer、Gluon、Horovod 和 Keras。 AMI 或容器可以在已針對 ML 效能進行最佳化的強大基礎架構上啟動。 SageMaker 還允許自帶容器,可以在其中使用選擇的任何框架。

實踐五: 使用自動化ML

建構模型時使用自動資料分析系統。 這些系統試驗並從高效能演算法清單中選擇最佳演算法。 它們會自動測試不同的解決方案和參數設定以實現最佳模型。 自動化系統加快了流程,同時消除了手動實驗和比較。

執行計畫
使用SageMaker Autopilot SageMaker Autopilot 可自動執行AutoML流程的關鍵任務。 Autopilot 會探索資料,選擇與我們的問題類型相關的演算法,並準備資料以促進模型訓練和調整。 Autopilot 會自動將交叉驗證重新採樣流程套用至所有可能演算法。 它測試這些演算法使用未經訓練的數資料進行預測的能力。 它根據效能測試對所有優化模型進行排名。 Autopilot 會找到效能最佳的模型,只需花費通常所需時間的一小部分即可部署模型。

實踐六: 使用託管的訓練功能

ML模型訓練可能是迭代、運算密集且耗時的過程。 不要使用可能在小型執行個體上執行的notebook本身,而是考慮將訓練放到託管的運算資源叢集(包括 CPU 和 GPU)來訓練模型。

執行計畫

  • 使用託管的訓練功能 —
    SageMaker 減少了訓練和調整 ML 模型的時間和成本,而無需管理基礎設施。 透過 SageMaker,使用內建工具訓練和調整 ML 模型,以管理和追蹤訓練實驗、自動選擇最佳超參數、偵錯訓練作業以及監控 GPU、CPU 和網路頻寬等系統資源的利用率。 SageMaker 可以根據訓練作業要求自動擴展或縮減基礎設施,從一個GPU 到數千個GPU,或從TB 到PB 的儲存空間。SageMaker 還提供目前可用的效能最高的ML 運算基礎設施,包括EC2 P4d 實例,它可以與前幾代產品相比,ML 訓練成本降低高達 60%。 而且,由於只需按使用量付費,因此可以更有效地管理培訓練成本。
  • 使用SageMaker Training Compiler
    為了更快地訓練深度學習模型,可以使用SageMaker Training Compiler 透過圖形和核心級優化來更有效地利用 GPU,從而將模型訓練過程加速高達 50%。 此外,可以透過幾行代碼將data parallelism或model parallelism新增至訓練腳本中,SageMaker 分散式訓練庫將自動跨 GPU 實例分割模型和訓練資料集,以更快地完成分散式訓練。
  • 使用SageMaker managed Spot training —
    SageMaker 可以使用EC2 Spot 訓練ML模型。 我們可以指定哪些訓練作業使用 Spot instance,以及指定 SageMaker 等待作業使用 Spot instance執行時間的停止條件。 CloudWatch 中提供訓練運行期間產生的指標和日誌。

實踐七: 使用分散式訓練

在演算法允許的情況下,啟用分散式訓練以縮短訓練時間。 在訓練叢集中使用多個實例。 使用託管服務可協助確保所有訓練執行個體在訓練完成後自動關閉。

執行計畫
使用SageMaker Distributed training libraries — SageMaker 中的Distributed training libraries會自動將大型深度學習模型和訓練資料集跨GPU 執行個體拆分,所需時間僅為手動操作的一小部分。 SageMaker 透過兩種技術實現這些效率:data parallelism與model parallelism。 model parallelism將太大而無法在單一GPU 上容納的模型拆分成較小的部分,然後分佈在多個GPU 上進行訓練,data parallelism將大型資料集拆分以同時進行訓練,以提高訓練速度。

實踐八: 當沒有使用時關掉資源

停止未使用的資源以降低成本。 例如,用於探索小資料樣本的託管 Jupyter 環境可以在沒使用使用時停止。 在可行的情況下,提交工作,停止工作,並在需要時重新啟動。 可以使用相同的方法來停止計算和資料儲存服務。

執行計畫

  • 使用CloudWatch Billing Alarms —
    使用CloudWatch 監控估計的 AWS 費用。 當啟用對 AWS 帳戶的估計費用的監控時,系統會估計費用並將其作為指標資料每天多次傳送到 CloudWatch。 使用此功能可以在資源費用超標金額時接收通知。
  • 使用SageMaker Lifecycle Configuration
    生命週期配置提供了在建立notebook instance或啟動時執行的 shell scripts。 在建立notebook instance時,可以建立新的生命週期配置及其腳本,也可以套用現有的生命週期配置及其腳本。 使用生命週期配置腳本從notebook存取 AWS 服務。 這些腳本可以檢查notebook instance活動並在idle時將其關閉。
  • 使用SageMaker Studio auto shutdown —
    SageMaker Studio 提供了一個統一的、Web-based 的視覺化介面,用於執行所有 ML 開發步驟,從而提高資料科學團隊的工作效率。 可以使用可手動或自動安裝的自動關閉 JupyterLab 擴充功能來偵測和停止idle的 SageMaker Studio notebook。 可以關閉單一資源,包括notebooks、 terminals、 kernels、applications與instances。

實踐九: 用小資料集進行訓練

在小型運算實例或本機系統上用較小的資料集進行實驗。 這種方法能夠以低成本快速迭代。 實驗期結束後,進行擴展以使用單獨計算叢集上可用的完整資料集進行訓練。 根據效能需求選擇合適的訓練資料儲存層。

執行計畫
使用SageMaker notebooks —Notebooks是探索和實驗少量數資料的通用方式。 在本地迭代資料集的小樣本,然後擴展以分散式方式在完整資料集上進行訓練在ML中很常見。SageMaker notebook instance提供託管 Jupyter 環境,可用於探索小資料樣本。

實踐十: 使用warm-start和檢查點超參數調整

在可行的情況下,使用warm start hyperparameter tuning。 Warm-start可以包括使用先前訓練的模型的上層作業或使用transfer learning。 超參數調整作業的warm-start消除了從頭開始調整作業的需要。 基於選定的上層作業或預訓練模型建立新的超參數調整作業。 使用檢查點功能從上次儲存的檢查點重新啟動訓練作業。 重複使用先前的訓練作為先驗知識,或使用檢查點來加速調優過程並降低成本。

執行計畫

  • 使用warm-start hyperparameter tuning
    使用warm-start以一個或多個先前的調整作業作為起點來啟動超參數調整作業。 先前調整作業的結果用於通知在新調整作業中搜尋哪些超參數組合。 超參數調整使用貝Bayesian或random search從指定的範圍中選擇超參數值的組合。
  • 使用 — checkpointing hyperparameter tuning
    使用 SageMaker 中的檢查點在訓練期間儲存 ML 模型的狀態。 檢查點是模型的快照,可以透過 ML 框架的callback functions進行配置。 可以使用已儲存的檢查點從上次儲存的檢查點重新啟動訓練作業。

實踐十一:使用超參數優化技術

使用自動超參數調整(automatic hyperparameter tuning)來執行許多訓練作業並找到模型的最佳版本。 使用指定的演算法和超參數範圍,以及[運用適當的超參數範圍與切合實際並滿足業務要求的指標。

執行計畫
使用SageMaker automatic model tuning
SageMaker automatic model tuning(也稱為hyperparameter tuning)透過在資料集上執行許多訓練作業來找到最佳模型。 它使用指定的演算法和超參數範圍。 然後,它會選擇超參數值,這些值會產生最佳表現的模型(根據選擇的指標進行衡量)。 若要為一種或多種演算法建立新的HPO(hyperparameter optimization) 調整作業,需要定義調整作業的設定。 為每個正在調優的演算法建立訓練作業定義,並為調優作業配置資源。

實踐十二: 設定預算並使用資源標籤來追蹤成本

如果我們需要了解 ML 成本,設定預算並考量標記notebook instances。 標籤的範例包括專案名稱、業務部門和環境(例如開發、測試或生產)。標籤對於成本優化非常有用,並且可以清楚地了錢花在哪裡。

執行計畫

  • 使用 AWS Budgets 追蹤成本 —
    AWS Budgets 可追蹤 SageMaker 成本,包括開發、訓練和託管。 也可以設定告警,並在成本或使用量超出(或預計超出)預算金額時收到通知。 建立預算後,可以在 AWS Budgets 控制台上追蹤進度。
  • 使用 AWS Cost Explorer —
    使用 AWS Cost Explorer 視覺化、了解和管理 AWS 成本和使用情況。
  • 標記資源 —
    考慮標記SageMaker notebook instances和託管的endpoints。 成本分配標籤可以幫助追蹤和分類ML成本。 它可以回答諸如“我可以刪除此資源以節省成本嗎?”之類的問題。

實踐十三: 實現資料和計算的相鄰性

確保用於訓練和開發模型的 Region 與用於資料的 Region 相同。 這種方法有助於最大限度地減少將資料傳輸到計算環境的時間和成本。

執行計畫
保持資料和運算資源緊密連接 — EC2 託管在全球多個地點。 這些位置由Region、AZ、Local Zones、AWS Outposts 和 Wavelength 區域組成。 每個區域都是一個單獨的地理區域。 如果要啟動計算集群,則應在靠近資料的位置啟動集群以獲得最佳效能。 假設資料S3 bucket位於日本東京,哪應該在東京啟動叢集以避免跨區域資料傳輸費用。

實踐十四: 選擇最佳演算法

確定解決ML 問題類型的基本機器學習範例。 基本的ML典範包括:監督式學習、非監督式學習、強化學習。 根據業務需求確定可解釋性和成功指標之間可接受的權衡水準。 運作原型和實驗來探索高效能演算法。 選擇滿足所有業務需求的最佳成本效益演算法。 在業務需求範圍內改善最佳化演算法的執行時間效能,是優化ML成本的一步。

執行計畫

(1)採用優化實踐

  • 從簡單的演算法(例如迴歸)開始,逐漸轉向更複雜的演算法(例如深度學習),以比較模型的準確性。 優化超參數以確定哪種演算法可以為業務用例產生最佳指標。
  • 選擇最佳演算法時,在資料限制、計算效能和維護作業之間進行權衡分析。 例如,深度學習網路可能會產生更準確的結果,但需要比tree-based methods更多的資料。 深度學習方法也更難維護。

(2)使用AWS服務

  • 使用 SageMaker 和一套內建演算法來訓練和部署ML模型。 AWS 提供了最佳化版本的框架,例如 TensorFlow、Chainer、Keras 和 Theano。 這些框架包括跨EC2 instance families的高效能訓練的最佳化。
  • 使用SageMaker Experiments 在測試期間追蹤模型。
  • 使用 SageMaker Autopilot 自動選擇演算法。
  • 在 AWS Marketplace 上尋找預訓練的 ML 模型 — 預訓練的 ML 模型是即用型模型,可以快速部署在SageMaker 上。 透過預先訓練模型,AWS Marketplace 中的解決方案可以處理繁重的工作,幫助團隊更快、以更低的成本交付 ML 支援的功能。

實踐十五: 啟用debugging與logging

確保記錄足夠的日誌和指標來取得runtime和資源消耗。 可以分析收集的日誌和指標,以確定需要改進的領域。 監控計算和資料儲存消耗。 偵測ML代碼,並使用偵錯工具在runtime擷取指標。

執行計畫

  • 使用SageMaker Debugger
    SageMaker Debugger 定期擷取訓練作業的狀態。 它透過監視、記錄和分析資料來提供 ML 訓練過程的可見性,並能夠對訓練期間擷取的資料進行互動式探索。 Debugger具有針對訓練期間偵測到的錯誤發出警報的功能。 例如,它可以自動偵測並提醒常見的錯誤,例如梯度值變得太大或太小。
  • 使用CloudWatch —
    SageMaker 訓練期間產生的日誌將記錄到CloudWatch Logs 中。 使用 AWS KMS Key對 CloudWatch Logs 取得的日誌資料進行加密。

永續性支柱 — 最佳實踐

永續發展支柱著重於環境影響,特別是能源消耗和效率,因為它們是架構師指導採取直接行動以減少資源使用的重要槓桿。 本節包括開發模型時要考量的最佳實踐,包括訓練、調整和模型表現評估。

相關最佳實踐

  • 自訂模型與預訓練模型的權衡分析— 考量是否需要將workload開發為自訂模型。 許多workload可以使用託管的 AWS AI 服務。 使用這些服務意味著我們不需要關聯的資源來收集、儲存和處理資料以及準備、訓練、調整和部署 ML 模型。 如果採用完全託管的AI服務不合適,評估是否可以使用預先存在的資料集、演算法或模型。 AWS Marketplace 提供超過 1,400 種 ML 相關資產可供訂閱。 也可以從預訓練的模型開始微調現有模型,例如 Hugging Face 或 SageMaker JumpStart 上提供的模型。 使用第三方的預訓練模型可以減少資料準備和模型訓練所需的資源。
  • 啟用debugging和logging — SageMaker Debugger 可以識別系統瓶頸、overfitting與saturated activation functions等訓練問題。 它提供了 LowGPUUtilization 或 Overfit 等內建規則來監控workload,並在偵測到問題(例如錯誤、作業無法收斂等)時立即自動停止訓練作業。 SageMaker Debugger 還提供分析器功能來偵測系統資源的利用率不足並協助調整環境規模。 這有助於避免不必要的碳排放。
  • 選擇最佳運算實例大小 — 使用SageMaker Studio 根據需求動態切換執行個體類型(例如,使用低功耗類型進行探索性資料分析,然後切換到GPU 僅對某些神經網路進行原型設計)。 使用可監控 CPU、GPU、記憶體和磁碟使用率等資源的 CloudWatch 指標來調整訓練作業規模。
  • 選擇小規模實驗的本地訓練 並開始使用小資料集進行訓練 — 在development notebook中使用較小的資料集進行實驗。 這種方法可在有限的碳排放下快速迭代。
  • 不使用時停止資源 — 建置模型時,使用生命週期配置腳本自動停止閒置的 SageMaker Notebook instance。 如果使用的是 SageMaker Studio,請安裝自動關閉 Jupyter 擴充功能以偵測並停止閒置資源。 使用 SageMaker 提供的完全託管的訓練流程自動啟動訓練實例並在訓練作業完成後立即關閉它們。 這可以最大限度地減少閒置運算資源,從而限制訓練作業對環境的影響。

實踐一: 定義可持續效能標準

在模型的準確性和環境影響之間進行權衡。 當我們只關注模型的準確性時,我們「忽略了達到報告的準確性所帶來的經濟、環境或社會成本」。 由於模型準確性和複雜性之間的關係充其量只是對數關係,因此更長時間地訓練模型或尋找更好的超參數只會導致效能的小幅提高

執行計畫

  • 建立永續效能標準 — 定義支援永續發展目標的效能標準,同時滿足業務要求,但不超過這些要求。
  • 做出權衡 — 模型效能的可接受下降可以顯著降低模型的可持續性影響。
  • 儘早停止訓練 — 在自動模型調優中,當超參數調優作業根據目標指標衡量沒有顯著改善時,提前停止會停止提前啟動的訓練作業。 同樣,SageMaker Debugger 提供了規則,一旦偵測到問題(例如錯誤、作業無法收斂…),就會自動停止訓練作業。

實踐二: 選擇節能演算法

為了最大限度地減少資源使用,使用產生相同結果的更有效率版本替換演算法。

執行計畫

  • 從簡單的演算法開始建立基準 — 然後以越來越複雜的方式測試不同的演算法,以觀察效能是否有所改善。 如果是這樣,請將效能效益與所需資源的差異進行比較。
  • 嘗試找到演算法的簡化版本 — 這種方法可以使用更少的資源來實現類似的結果。 例如,DistilBERTBERT 的精簡版,參數減少了 40%,運行速度提高了 60%,並保留了 97% 的效能。
  • 壓縮模型大小而不顯著損失準確度 — 使用修剪(Pruning)來刪除對模型貢獻不大的權重。 使用量化來呈現具有low-bit integers的數字,而不會導致準確性的顯著損失。 這些技術可加快推論速度並節省能源,同時對準確性的影響有限
  • 使用 SageMaker Neo — 最佳化 ML 模型以在雲端中的 SageMaker 和邊緣支援的裝置上進行推論。

實踐三: 歸檔或刪除不需要的訓練工件

刪除未使用且不再需要的訓練工件來避免資源浪費。 確定何時可以將訓練工件歸檔到更節能的儲存中或安全地刪除它們。

執行計畫

  • 清理不需要的訓練資源 — 使用 SageMaker Experiments 組織 ML 實驗,以清理不再需要的訓練資源
  • 減少保留的日誌量 — 預設情況下,CloudWatch 會無限期保留日誌。 透過為notebook和訓練日誌設定有限的保留時間,將避免不必要的日誌儲存對環境的影響。

實踐四: 使用有效的模型調整方法

實施有效的策略來優化超參數值,以最大限度地減少完成模型訓練所需的資源。 盡可能避免暴力策略,因為它測試超參數值而不關心使用的資源數量

執行計畫

  • 採用可持續的調整作業策略 — 優先選擇超頻帶(Hyperband)或貝葉斯搜尋(Bayesian search)而不是隨機搜尋(並避免網格搜尋)。 貝葉斯搜尋根據先前的一組試驗對下一組要選擇的參數進行智慧猜測。 為了找到最佳的超參數,它通常需要比隨機搜尋少 10 倍的作業,從而減少 10 倍的運算資源。 SageMaker Automatic Model Tuning支援 Hyperband,這是一種新的搜尋策略,對於解決電腦視覺問題的深度神經網路等大規模模型,它可以比貝葉斯搜尋快三倍的速度找到最佳超參數集。
  • 限制concurrent training jobs的最大數量 — 同時執行超參數調整作業可以快速完成更多工作。 然而,使用貝葉斯優化策略,調整作業只能透過連續幾輪的實驗來改進。 通常,一次執行一項訓練作業可以用最少的計算資源達到最佳結果。
  • 仔細選擇超參數的數量及其範圍 — 透過將搜尋限制為幾個參數和較小的值範圍,可以獲得更好的結果並使用更少的計算資源。 如果知道超參數是對數縮放的(log-scaled),請將其轉換以進一步改善最佳化。

--

--

運用"雲端服務"加速企業的數位轉型願景
運用"雲端服務"加速企業的數位轉型願景

Written by 運用"雲端服務"加速企業的數位轉型願景

我們協助您駕馭名為"雲端運算"的怪獸,馴服它為您所用。諮詢請來信jason.kao@suros.com.tw. https://facebook.com/jason.kao.for.cloud

No responses yet