AWS 機器學習架構框架Part 5
佈署
訓練、調整和評估模型後，我們可以將其部署到生產環境中中並針對此部署的模型開始預測作業。 SageMaker Studio 可以將notebook中的代碼轉換為production-ready job，不用去管理底層基礎架構。 透過自動化與手動或自動的品管相結合來控制部署，確保在部署到生產環境之前可以使用依賴系統有效地驗證變更。
上面的佈署架構圖說明了生產中 ML 生命週期的部署階段。 應用程式將request payload傳送到Production Endpoint以對模型進行推論。 模型工件從Model Registry中取得，特徵從Feature Store中檢索，inference code container從容器儲存庫中取得。
上圖列出了生產部署的關鍵組件，包括：
(1)Blue/green, canary, A/B, shadow deployment/testing :
- Blue/green 部署技術提供了兩個相同的生產環境（Blue是現有基礎設施，Green是用於測試的相同基礎設施）。 在Green環境上完成測試後，立刻將應用程式流量將從Blue環境導向到Green環境。 然後Blue/green環境的角色互換。
- 透過canary部署，新版本會部署給一小部分使用者，而其他使用者則繼續使用先前的版本。 一旦新版本OK(經過正式核可流程)，就可以逐步將使用者導向新版本。
- A/B 測試策略支援將變更部署到模型。 將指定部分的流量引導至新模型。 將剩餘流量引導至舊模型。 A/B 測試與金絲雀測試類似，但具有更大的使用者群和更長的時間範圍，通常為幾天甚至幾週。
- 透過shadow deployment/testing，新版本可以與舊版本一起使用。 資料將會在兩個版本中運行。 舊版本用於為生產應用程式提供服務，新版本用於測試和分析。
(2) Inference pipeline —
下圖顯示了自動擷取準備好的資料、執行預測和後續處理以進行即時或批次推論的inference pipeline。
(3)Scheduler pipeline —
部署的模型代表最新的資料模式。 當如下圖所示進行配置時，定期重新訓練可以最大限度地降低資料和Concept drift的風險。 Scheduler可以按照業務定義的時間間隔啟動重新訓練。 在此過程中，Data preparation、CI/CD/CT 和feature pipelines也將處於運作狀態。
卓越營運支柱 — 最佳實踐
卓越營運支柱包括運作和監控系統以提供業務價值並持續改善支援流程和程序的能力。
實踐一: 設定佈署環境指標
量測ML運作指標來確定已部署環境的效能。 這些指標包括記憶體和 CPU/GPU 使用情況、磁碟使用率、ML endpoint invocations與延遲。
執行計畫
- 記錄與效能相關的指標 —
運用監控和可觀察性服務來記錄與效能相關的指標。 這些指標可以包括database transactions、slow queries、I/O latency、HTTP request throughput, service latency和其他關鍵資料。 - 發生事件或事故時分析指標 —
使用監控儀表板和報告來了解和診斷事件或事故的影響。 這些視圖可讓我們深入了解workload的哪些部分未如預期執行。 - 建立KPI來衡量workload效能 —
確定呈現workload是否如預期運作的 KPI。 基於 API 的workload可能會使用整體回應延遲作為整體效能的指標，而電商網站可能會選擇使用下單量作為其 KPI。 - 運用監控產生基於告警的通知 —
監控定義的 KPI 指標，並在測量結果超出預期範圍時自動產生告警。 - 定期審查指標 —
作為日常維護或回應事件或事故，審查收集的指標並確定對於解決問題至關重要的指標。 確定有助於識別、解決或預防問題的任何其他指標。 - 主動式監控和告警 —
使用 KPI 與監控和告警系統結合，主動解決與效能相關的問題。 使用搞警來啟動自動運作以盡可能修復問題。 如果無法自動回應，告警需要升級給能夠回應的人員。 使用系統預測預期 KPI 值，並在 KPI 超出預期值時產生告警並自動停止或rollback deployment。 - 使用CloudWatch —
使用 SageMaker endpoint的CloudWatch 指標來確定記憶體、CPU 使用率和磁碟使用率。 設定 CloudWatch 儀表板以視覺化環境指標並建立 CloudWatch 告警並透過 SNS（電子郵件、SMS、WebHook）啟動通知，以通知執行階段環境中發生的事件。 - 使用 Amazon EventBridge —
考量使用 EventBridge 定義自動化工作流程以自動回應事件。 這些事件可以包括訓練作業狀態變更、endpoint狀態變動以及運算環境容量在超過定義的閾值（例如 CPU 或磁碟使用率）後增加。 - 使用Application Cost Profiler —
使用Application Cost Profiler 報告每個租戶（模型/使用者）的成本。
安全支柱 — 最佳實踐
安全支柱包括保護資料、系統和資產的能力，以利用雲端技術來提高安全性。
實踐一: 防範對抗性和惡意活動
在已部署代碼的內部和外部新增保護，以偵測可能導致錯誤預測的惡意輸入。 透過詳細檢查輸入來自動偵測未經授權的變更。 在將input新增回pool之前修復並驗證input。
執行計畫
- 評估演算法的穩健性 —
評估使用案例並確定錯誤的預測或分類。 使用敏感度分析來評估演算法針對日益擾動的輸入(perturbed inputs)的穩健性，以了解對manipulated inputs的敏感度。 - 從一開始就建立穩健性 —
選擇不同的特徵來提高演算法處理異常值(outliers)的能力。 考慮在整合中使用模型，以增加決策的多樣性和決策點的穩健性。 - 識別重複 —
使用SageMaker Model Monitor 定期運行 SageMaker processing job來分析推理資料，檢測模型的類似重複輸入，以指示對決策邊界可能存在的威脅。 這可以採取模型暴力破解的形式，其中威脅只迭代一組有限的變數來確定影響決策點的因素並得出特徵重要性。 - Lineage tracking—
如果對不受信任或未經驗證的輸入進行重新訓練，請確保在重新訓練替換模型之前將任何模型偏差追溯到資料面並對其進行修剪。 - 使用安全推論 API endpoint—
託管模型，以便模型的使用者可以安全地對其進行推論。 允許使用者使用 API 定義關係、限制對基本模型的存取並提供對模型互動的監控。
可靠度支柱 — 最佳實踐
可靠性支柱包括workload在我們期待它正確一致地執行其預期功能的能力。
實踐一:透過pipeline自動更改endpoint
手動變更管理很容易出包，並且會產生很高的工作成本。 使用自動化pipeline（與變更管理追蹤系統整合）將變更部署到模型端點。 版本化的pipeline inputs和工件可追蹤變更並在變更失敗後自動rollback。
執行計畫
- 使用SageMaker Pipelines —
透過pipeline部署變更是一種可以實現一致性的安全工程方法。 SageMaker Pipelines 是專門建置、易於使用的CI/CD 服務，可以大規模建立、自動化和管理端對端 ML 工作流程。
實踐二: 使用適當的"部署和測試"策略
對可用的相關部署/測試策略（如blue/green, canary, shadow, and A/B testing）進行權衡分析，然後選擇滿足業務需求的策略。實施評估模型效能的指標，以確定何時需要rollback或roll-forward。 在設計rollback或roll-forward架構時，請評估每個模型的以下內容：
- 模型工件儲存在哪裡？
- 模型工件是否有版控？
- 每個版本都包含哪些變更？
- 為已部署的端點部署了哪個版本的模型？
執行計畫
(1)在Sagemaker中佈署/測試 — SageMaker 提供託管部署策略，用於在生產環境中測試模型的新版本。
- 使用SageMaker 的blue/green部署：在更新 SageMaker real-time endpoint時，SageMaker 會自動使用blue/green部署來最大限度地提高endpoint的可用性。blue/green部署中的各種流量轉移模式使我們可以更精細地控制blue和green fleet之間的流量轉移。 有關更多詳細資訊，請參閱 SageMaker 中的blue/green部署。
- 使用 SageMaker 進行canary部署：canary部署選項可將一小部分流量（canary）轉移到geen fleet並在觀察期間對其進行監控。 如果canary在green fleet是成功的，則在停止blue fleet之前，其餘流量將從blue轉移到green fleet。更多在Sagemaker進行canary deployment的詳細資訊請參閱AWS的文件庫。
(2)使用 SageMaker 進行線性部署(Linear deployment)：線性流量轉移可逐漸將流量從舊blue fleet轉移到green fleet。 透過線性流量轉移，可以分多個步驟轉移流量，從而最大程度地減少endpoint中斷的可能性。 此blue/green部署選項可對流量轉移進行最精細的控制。
(3)使用 SageMaker 進行 A/B 測試：在新模型和生產環境的舊模型之間執行 A/B 測試可能是新模型驗證過程中有效的最後一步。 在 A/B 測試中，測試模型的不同變體並比較每個變體的效能。 如果模型的新版本提供比以前存在的版本更好的效能，則使用生產中的新版本來取代模型的舊版本。 有關更多詳細資訊，請查看 SageMaker 文件庫中生產環境的測試模型。
效能效率支柱 — 最佳實踐
效能效率支柱著重於有效利用運算資源來滿足需求，並隨著需求變化和技術發展保持效率。
實踐一: 評估ML部署在雲端與邊緣(edge)的選項
評估ML應用程式是否需要近乎即時的推論結果或需要在沒有網路連線的情況下進行推論。 提供最低的延遲可能需要消除到最近的 API endpoint的昂貴的網路來回。 透過直接在設備本身（邊緣）上運行推論可以減少延遲。 這種要求的常見使用案例是工廠的預測性維護。
執行計畫
優化邊緣模型部署 — 訓練和優化ML模型需要大量運算資源，因此它非常適合雲端。 推論所需的運算能力要少得多，並且通常在新資料可用時即時完成。 當以非常低的延遲獲得推論結果時，請確認我們的 IoT 應用程式可以快速回應本地事件。 評估並選擇滿足業務需求的選項。
- SageMaker Edge 透過最佳化、保護模型並將其部署到邊緣，然後在智慧相機、機器人和其他智慧電子等設備上監控這些模型，從而在邊緣設備上實現ML，從而降低持續營運成本。 在 TensorFlow、MXNet、PyTorch、XGBoost 和 TensorFlow Lite 中訓練模型可以使用 SageMaker Edge 來提高其效能，將其部署在邊緣設備上，並在整個生命週期中監控其運作狀況。 SageMaker Edge Compiler 優化訓練後的模型以在邊緣設備上運行。 SageMaker Edge Agent 可在同一裝置上執行多個模型。 代理程式根據控制的邏輯（例如間隔）收集預測數據，並將其上傳到雲端，以便可以隨著時間的推移定期重新訓練模型。 SageMaker Edge 對模型進行加密簽名，以便可以驗證它們在從雲端轉移到邊緣設備時沒有被篡改。
- SageMaker Neo 讓 ML 模型只需訓練一次，即可在雲端和邊緣的任何位置運行。 SageMaker Neo 由compiler和runtime組成。 編譯 API 讀取從各種框架導出的模型，將其轉換為與框架無關的呈現形式，並產生最佳化的binary code（以更快地運行而不損失準確性）。 Compiler使用ML模型來應用效能最佳化，為雲端實例或邊緣設備上的模型提取最佳可用性能。 然後，每個目標平台的運行時都會載入並執行編譯後的模型。
- SageMaker Neo 優化了ML模型，以在雲端實例和邊緣設備上進行推論。 SageMaker Neo 最佳化經過訓練的模型並將其編譯為可執行檔。 然後，可以將模型部署為 SageMaker endpoint或支援的邊緣設備並開始進行預測。
- AWS IoT Greengrass 使用在雲端中訓練的模型在邊緣裝置上啟用ML推論。 這些模型可以使用 SageMaker、Deep Learning AMI 或 Deep Learning Containers 建構。 這些模型可以先儲存在 Amazon S3 中，然後再部署到邊緣裝置上。
實踐二: 在雲端選擇最佳部署選項
如果模型適合雲端部署，應該根據使用案例中的頻率、延遲和運行時要求確定如何部署它們以獲得最佳效能效率。
執行計畫
- SageMaker real-time inference — 如果需要一個persistent endpoint來讓 ML 模型對隨時可能出現的request進行近乎即時的回應，哪就這個方案。 可以將模型託管在 HTTPS endpoint後面，以便與應用程式整合。 SageMaker real-time endpoint是完全託管的並支援自動擴展。
- SageMaker Serverless Inference — 如果我們收到速率和數量差異很大的尖峰推論請求，哪就用這一個方案。 這是一個專門建立的推論選項，可以輕鬆部署和擴展 ML 模型，而無需管理任何伺服器。 serverless inference非常適合在流量激增之間有空閒期並且可以允許cold start的workload。
- SageMaker Asynchronous Inference- 如果模型請求具有較大的payload sizes（最多1GB）、較長處理時間（最多15 分鐘）和近乎瞬間的延遲要求，請使用SageMaker Asynchronous Inference ，因為它具有更大的負載限制和與 SageMaker real-time相比，超時限制更長。 SageMaker Asynchronous Inference對傳入request進行排隊，並使用內部排隊系統非同步處理它們。
- Amazon SageMaker Batch Transform — 如果不需要 ML 模型的近乎即時回應，並且可以將資料點收集到一個大批次中以進行schedule-based inference，就使用這個方案。 當批次轉換作業啟動時，SageMaker 會初始化運算實例並在它們之間分配推理或預處理workload。 SageMaker Batch Transform 會自動將輸入檔案拆分為小批量（這樣無需擔心大型資料集的OOM-out-of-memory），並在處理整個資料集後關閉運算實例。
成本優化支柱 — 最佳實踐
成本優化支柱包括系統在整個生命週期中的持續細緻化和改進過程。 從第一個PoC的初始設計到Production workload的持續運行，採用本文中的實踐可以構建和運營具有成本意識的系統，從而實現業務成果並最大限度地降低成本，進而使業務最大化ROI。
實踐一: 選擇合適的佈署選項
對於具有穩定流量模式的案例，使用real-time inference來實現低延遲和超高吞吐量。 對於具有大型資料集的案例，使用批次轉換對資料批次進行離線推論。 在邊緣部署模型，以優化、保護、監控和維護智慧相機、機器人、個人電腦和行動裝置等邊緣設備群上的ML模型。
執行計畫
SageMaker 提供廣泛的 ML 基礎架構和模型部署選項，能夠針對任何案例以最佳性價比輕鬆部署 ML 模型。 它是一項完全託管的服務，並與 MLOps 工具整合，因此可以擴展模型部署、降低推論成本、在生產環境中更有效地管理模型並減輕維運負擔。
- 使用 Amazon SageMaker Real-time Inference、Amazon SageMaker Serverless Inference、Amazon SageMaker Asynchronous Inference 和 Amazon SageMaker Batch Transform
- 使用SageMaker multi-model endpoints — 多模型終端節點為部署大量模型提供了可擴展且經濟高效的解決方案。 他們使用能夠託管多個模型的共享服務容器。 與使用單模型端點相比，此方法透過提高端點使用率來降低託管成本。 減少了部署開銷，因為SageMaker 管理記憶體中的載入模型並根據其流量模式對其進行擴展。
- 使用SageMaker multi-container endpoint— SageMaker 多容器終端節點可在單一 SageMaker endpoint上部署使用不同模型或框架的多個容器。 容器可以作為inference pipeline按順序運行，也可以透過使用直接呼叫單獨存取每個容器，以提高endpoint使用率並優化成本。
- 使用 Amazon SageMaker Pipelines
- 使用 Amazon SageMaker Edge
實踐二: 探索具有成本效益的硬體選項
為ML應用提供動力的ML模型變得越來越複雜，導致底層運算基礎設施成本不斷上升。 用於開發和運行 ML 應用程式的基礎設施支出中，高達 90% 通常用於推論。 尋找經濟高效的基礎設施解決方案，以便在生產環境中部署ML應用程式。
執行計畫
- 使用SageMaker Neo —
對於於雲端中的推論，SageMaker Neo 透過在 SageMaker 託管中建立推論優化容器來加速推論並節省成本。 對於邊緣推論，SageMaker Neo 透過針對所選作業系統和處理器硬體自動調整模型，為開發人員節省了漫長的手動調整時間。 - 使用 SageMaker Elastic Inference —
Elastic Inference (EI) 是一項服務，可將適量的 GPU 驅動的推論加速附加到任何 EC2 instance。 透過使用 EI，可以加快throughput並減少從部署為SageMaker 託管模型的深度學習模型取得即時推論的延遲，但成本只是為endpoint使用 GPU 執行個體的一小部分。 除了 CPU 執行個體類型之外，還將available sizes之一的 EI accelerator新增至可部署模型中，然後將模型作為production variant新增至用於部署託管終端節點的配置中。 也可以將 EI accelerator新增至 SageMaker notebook instance，以便在建立模型時測試和評估推論效能。 - 使用 EC2 Inf1 執行個體 — EC2 Inf1 instance在雲端以最低的成本提供高效能的 ML 推論。 與當前世代基於 GPU 的 EC2 執行個體相比，它們的throughput提高了 2.3 倍，每次推論成本降低了 70%。 Inf1 instance是從頭開始建立的，旨在支援ML推論應用程式。 它們配備多達 16 個 AWS Inferentia 晶片，這是由 AWS 設計和製造的高效能ML推論晶片。
實踐三: 調整模型託管instance fleet的規模
使用高效率的運算資源在生產環境中運行模型。 在許多情況下，用於開發和運行 ML 應用程式的基礎設施支出的 90% 都用於推論，因此使用經濟高效的 ML 推論基礎設施至關重要。 選擇正確的託管方式和正確的instance types可能會對 ML 專案的總成本產生重大影響。 為託管模型使用自動縮放（autoscaling），以回應工作負載的變化。
執行計畫
- 使用 SageMaker Inference Recommender — SageMaker Inference Recommender 自動選擇正確的compute instance type、instance count、 container parameters和model optimizations進行推論，以最大限度地提高效能並最大限度地降低成本。 可以使用 SageMaker Studio 中的 SageMaker Inference Recommender、AWS CLI 或 AWS SDK，並在幾分鐘內獲得部署 ML 模型的建議。 然後，可以將模型部署到建議的instance之一，或對選擇的一組instance type執行完全託管的負載測試，而無需擔心測試基礎架構。 可以在 SageMaker Studio 中查看負載測試的結果，並評估延遲、throughput和成本之間的權衡，以選擇最佳的部署配置。
- 將 AutoScaling 與 SageMaker 結合使用 — SageMaker 支援自動擴展功能，該功能可監控worklaod並動態調整容量，以盡可能低的成本保持穩定且可預測的效能。 當workload增加時，Autoscaling會帶來更多instance上線。 當workload減少時，Autoscaling會刪除不必要的instance，幫助降低運算成本。 SageMaker 會自動嘗試跨AZ指派instance。 因此，AWS強烈建議我們為每個Peoduction endpoint部署多個instance以實現高可用性。 如果使用的是 VPC，可以在不同的AZ中至少設定兩個子網，以便SageMaker 可以跨這些AZ運行Instance。
永續性支柱 — 最佳實踐
永續發展支柱著重於環境影響，特別是能源消耗和效率，因為它們是架構師指導採取直接行動以減少資源使用的重要槓桿。
實踐一: 使 SLA 與永續發展目標保持一致
定義支援永續發展目標並同時滿足業務要求的SLA。 定義 SLA 來滿足業務需求，而不是超越它們。 做出權衡，顯著減少環境影響，以換取可接受的服務水準下降。
執行計畫
- 對incoming request進行排隊(Queue)並使用"非同步處理" —
如果使用者可以容忍一定的延遲，請將模型部署在serverless或asynchronous endpoints上，以減少任務之間的閒置資源，並最大限度地減少load spikes的影響。 當沒有要處理的請求時，這些選項會自動將instance或endpoint count調整為零，因此我們只需在endpoint處理request時維護推論基礎架構。 - 調整可用性 — 如果使用者可以在罕見的故障轉移情況下容忍一些延遲，則不要配置額外的容量。 如果發生中斷或instance fail，SageMaker 會自動嘗試跨AZ建立新的instance。 調整可用性是您為實現永續發展目標而有意識地進行權衡的一個例子。
- 調整回應時間 — 當不需要real-time inference時，使用 SageMaker 批次轉換。 與persistent endpoint不同，叢集會在批次轉換作業完成時停用，因此無需持續維護推論基礎架構。
實踐二: 使用高效矽
使用與 ML workload相容的最高效的執行個體類型。
執行計畫
AWS 提供了多種專門建置的運算架構，這些架構經過最佳化以最大限度地減少 ML workload對永續性的影響：
- 對於基於 CPU 的 ML 推論，使用 AWS Graviton3 —
這些處理器在 EC2 中提供最佳的每瓦效能。 與同類 EC2 instance相比，它們消耗的能源最多可減少 60%。 對於 ML workload，Graviton3 處理器的效能比 Graviton2 處理器高出三倍，並且支援 bfloat16。 - 對於深度學習推論，使用 AWS Inferentia —
EC2 Inf2 instance的效能功耗比同類 EC2 instance高出 50%，因為它們和底層 Inferentia2 加速器專為大規模運行 DL 模型而建置。 Inf2 instance可在部署超大型模型時實現永續發展目標。 - 對於訓練時，使用 AWS Trainium —
基於客製化設計的 AWS Trainium 晶片的 EC2 trn1 instance比同類 EC2 可節省高達 50% 的訓練成本。 使用基於 Trainium 的instance cluster時，與同等大小的可比加速 EC2 instance cluster相比，從頭開始訓練 BERT Large 的總能耗大約低 25%。
實踐三: 優化推論模型
透過將模型編譯為最佳化的形式，提高模型的效率，進而使用更少的資源進行推論。
執行計畫
- 使用開源模型編譯器 — 由於更有效地運用運算資源，Treelite（用於決策樹整合）等函式庫可以提高模型的預測throughput。
- 使用第三方工具 — Hugging Face Infinity 等解決方案可以在 GPU 上還可以在 CPU 上加速transformer models並進行推論。
- 使用 SageMaker Neo — SageMaker Neo 讓開發人員能夠優化 ML 模型，以在雲端中的 SageMaker 和邊緣支援的裝置上進行推論。 SageMaker Neo 運行時消耗的資源僅為深度學習框架的十分之一，同時優化模型，執行速度提高了 25 倍，且準確性沒有損失。
實踐四: 在單一個Endpoint後部署多個模型
在單一Endpoint後託管多個模型以提高Endpoint使用率。 與在一個endpoint只佈署一個模型相比相比，共享Endpoint資源更具可持續性且成本更低。
執行計畫
SageMaker 提供了三種將多個模型部署到單一Endpoint的方法：
- 在一個端點後面的一個容器中託管多個模型 — SageMaker MME(multi-model endpoints) 使用單一容器提供服務。 當有大量相似的模型可以透過共用服務容器提供服務並且不需要同時存取所有模型時，此功能非常理想。 這有助於降低推論成本並減少高達 90% 的碳排放。
- 在一個端點後面託管使用不同容器的多個模型— SageMaker MCE(multi-container endpoint) 支援在單一Endpoint上部署最多15 個使用不同模型或框架的容器，並獨立或按順序呼叫它們，以降低成本-延遲推論和省錢。 這些模型可以是完全異質的，並且有自己獨立的服務堆疊。
- 使用 SageMaker inference pipeline— inference pipeline是一種 SageMaker 模型，由部署在單一endpoint後面的容器的線性序列(linear sequence)組成。 可以使用inference來組合preprocessing、predictions、 與post-processing 資料的作業。 一個容器的輸出作為輸入傳遞到下一個容器。 為pipeline模型定義容器時，可以指定容器的運作順序。
