在生產環境中部署機器學習模型
本文說明使用 Azure 機器學習 在生產環境中部署機器學習模型的最佳做法。 在生產環境中部署機器學習模型對於使用 AI 增強其作業的組織而言非常重要。 這可以是複雜的程式,但本文可協助您了解這些步驟。
架構考量
選擇正確的部署方法。 每個部署方法都有優點和缺點。 請務必選擇最符合您組織需求的選擇。 有兩個主要的部署方法:
即時(在線)推斷會在收到輸入數據時處理,通常是低延遲需求。 對於需要立即回應的應用程式而言,低延遲很重要,例如詐騙偵測、語音辨識或建議系統。 即時推斷比批次推斷更複雜且昂貴,因為它需要更快速且更可靠的基礎結構。 即時推斷的基礎計算通常會持續執行,以更快速地服務要求。
批次 (離線)推斷會一次處理大量輸入數據,而不是即時個別處理每個輸入數據點。 批次推斷非常適合需要有效率處理但響應時間並不重要的大型數據量案例。 例如,您可以使用批次推斷來處理大型影像數據集,而機器學習模型會一次對所有影像進行預測。 批次推斷比即時推斷成本更低且更有效率。 批次推斷的基礎計算通常只會在批次作業期間執行。
機器學習 會使用端點即時和批次案例來部署模型。 端點會提供整合介面,以叫用和管理跨計算類型的模型部署。 受控在線端點會提供、調整、保護及監視您的機器學習模型以進行推斷。
如需詳細資訊,請參閱本文 中的<部署方法>一節。
確保一致性。 請務必一致地跨環境部署模型,例如開發、預備和生產環境。 使用容器化或虛擬化技術,例如 機器學習 環境,以提供一致性並封裝您的環境。
監視效能。 在模型部署到生產環境之後,您應該追蹤計量,例如精確度、延遲和輸送量,並設定警示,以在效能低於可接受的層級時通知您。 使用 Application Insights 和 受控端點 的內建監視功能來檢視計量並建立警示。
實作安全性措施。 保護您的數據和系統。 您可以設定驗證和訪問控制、加密傳輸中的數據和待用數據、使用網路安全性,以及監視可疑活動。
建立更新計劃。 當新的數據和新的演算法可供使用時,機器學習模型需要更新。 在生產環境中部署模型之前,請務必先建立測試及驗證更新模型的程式。 藍/綠部署是更新生產環境中機器學習模型的常見策略。 使用藍色/綠色部署,您可以將模型更新至新的環境、測試模型,然後在驗證模型之後切換至新模型。 藍/綠部署可確保更新模型的潛在問題不會影響您的客戶。 如需詳細資訊,請參閱 原生藍/綠部署。
部署方法
請考慮下列問題來評估您的模型、比較兩個部署方法,然後選取適合您模型的方法:
- 產生預測的頻率為何?
- 您需要結果多久?
- 預測會立即儲存或使用嗎?
- 是否應該個別、以小批次或大型批次產生預測?
- 模型是否預期延遲?
- 模型需要執行多少計算能力?
- 維護模型是否有操作含意和成本?
- 如何觸發預測? 它是以事件為基礎或已排程的嗎?
請參閱下列判定樹,以判斷哪一個部署模型最適合您的使用案例:
批次推斷
批次推斷是一個簡單的程式,可讓模型以時間間隔或根據觸發程序執行。 使用批次推斷,商務應用程式可以儲存預測。
請考慮下列批次推斷的最佳做法:
使用 API 執行批次作業。 使用 批次端點 建立永久性 HTTPS 端點,以觸發排程或事件型數據管線的批次評分作業。 API 可以與任何支援 REST API 叫用的數據協調流程平臺整合。 如需詳細資訊,請參閱本節中的 Batch 整合項目符號點和 部署在批次端點中評分的模型。
計算選項。 批次推斷程式通常不會持續執行,因此自動啟動、停止及調整可處理一系列工作負載的可重複使用叢集會很有説明。 不同的模型通常需要不同的環境。 您的解決方案需要部署特定環境,並在推斷完成時將其移除。 自動化讓計算可供下一個模型使用。 若要降低成本,請針對計算節點使用 低優先順序的虛擬機 。
重要
計算節點的大小很重要。 如果節點太小,批次推斷作業需要較長的時間。 如果節點太大,則作業成本更高。 測試及監視計算節點,以判斷模型的正確大小。
請考慮延展性需求。 為了改善效能,機器學習 支援啟用可調整處理的功能。 在批次端點部署期間,機器學習 定義計算節點數目和最大並行參數。 您可以覆寫每個作業的參數,以提供客戶的運行時間彈性和現用的平行處理原則。 這些功能適用於表格式和檔案型推斷。
批次推斷挑戰。 批次推斷是一種更簡單的方式,可用來在生產環境中使用和部署模型,但它確實會呈現自己的一組挑戰。
根據推斷執行的頻率,產生的預測在存取時可能無關緊要。
部署至許多區域並設計高可用性解決方案並不是批次推斷案例中的重要考慮,因為模型並未在區域部署。 但數據存放區可能需要以高可用性策略部署在許多位置。 部署應遵循應用程式高可用性設計和策略。
批次推斷期間產生的數據可能會部分失敗。 例如,如果排程的管線觸發批次推斷作業而管線失敗,則批次推斷作業所產生的數據可能不完整。 部分重新啟動是批次推斷的常見問題。 其中一個解決方案是針對數據使用暫存區域,而且只會在批次推斷作業順利完成之後,將數據移至最終目的地。 另一個解決方案是維護已處理之每個檔案的記錄或交易,並將該記錄與輸入檔案清單進行比較,以避免重複。 此方法會將邏輯併入評分腳本中。 此解決方案較為複雜,但如果批次推斷作業失敗,您可以自定義失敗邏輯。
安全性需求。 使用驗證和授權來控制對批次端點的存取,以提高安全性。
批次整合。 機器學習 批次端點使用開啟的 API。 批次推斷可以與其他 Azure 服務整合,例如 Azure Data Factory、Azure Databricks 和 Azure Synapse Analytics,以形成較大數據管線的一部分。 例如,您可以使用:
- Data Factory 用來協調批次推斷程式。
- Azure Databricks 準備數據以進行批次推斷。
- 機器學習 執行批次推斷程式。
- Azure Synapse Analytics 以儲存後續的預測。
Batch 端點支持授權Microsoft Entra ID。 對 API 的要求需要適當的驗證。 Azure 服務,例如 Data Factory,支援使用服務主體或受控識別來針對批次端點進行驗證。 如需詳細資訊,請參閱 從 Data Factory 執行批次端點。
若要選擇批次輸入和輸出處理的最佳方法,請務必了解數據如何經過數據管線的階段。 您可以使用 SDK 直接透過批次端點評分腳本存取 Azure 資料服務,但使用 機器學習 已註冊的數據存放區更為簡單、安全且可稽核。 針對第三方數據源,請使用數據處理引擎,例如 Data Factory、Azure Databricks 或 Azure Synapse Analytics,準備數據以進行批次推斷,並套用推斷後處理。
MLflow。 在模型開發期間,使用開放原始碼架構 MLflow。 機器學習 支援您使用 MLflow 建立和記錄的模型無程式碼部署。 當您 將 MLflow 模型部署到批次端點時,您不需要指出評分腳本或環境。
即時推斷
即時推斷是一種方法,可讓您隨時觸發模型推斷,並提供立即回應。 使用此方法分析串流資料或互動式應用程式數據。
請考慮下列即時推斷的最佳做法:
計算選項。 實作即時推斷的最佳方式是將在線端點中的模型部署到受控在線端點或 Kubernetes 在線端點。 受控在線端點會使用 Azure 中的 CPU 或 GPU 機器,立即部署您的機器學習模型。 此方法可調整且完全受控。 Kubernetes 在線端點會部署模型,並在您完全設定和管理的 Kubernetes 叢集上提供在線端點。 開始使用 Azure Kubernetes Service 的 AI 工具鏈操作員附加元件來部署開放原始碼大型語言模型 (LLM),以推斷叢集。 如需詳細資訊,請參閱 受控在線端點與 Kubernetes 在線端點。
多區域部署和高可用性。 區域部署和高可用性架構是即時推斷案例的範例,因為延遲和模型效能非常重要。 若要減少多區域部署中的延遲,請盡可能接近取用點找出模型。 針對模型和支援基礎結構,請遵循企業的高可用性和災害復原原則和策略。
即時推斷挑戰。
- 由於延遲和效能需求,即時推斷更為複雜。 簡單的即時系統會透過 HTTP 要求接收輸入,並傳回預測。 但複雜系統可能需要以 100 毫秒或更少時間回應。 在此期間,它會擷取數據、執行特徵工程、執行推斷、驗證及儲存模型結果、執行商業規則,並將結果傳回至系統或應用程式。
- 將功能工程卸除至低延遲數據存放區、快取服務或專用功能存放區。 功能存放區是集中式存放庫,可讓數據科學家尋找及共用功能。 功能存放區可確保用來計算特徵值的相同程式代碼也用於模型定型和推斷。
安全性需求。 為了增強安全性,請使用驗證和授權來控制對在線端點的存取。
即時整合。 使用不同語言的 SDK,並使用 REST API 叫用端點,將即時推斷與其他 Azure 服務整合。 您可以將線上端點叫用為應用程式程式碼的一部分。
MLflow。 在模型開發期間,使用開放原始碼架構 MLflow。 機器學習 支援您使用 MLflow 建立和記錄的模型無程式碼部署。 當您 將 MLflow 模型部署到在線端點時,不需要指出評分腳本或環境。
安全推出。 將分階段式更新部署到機器學習模型,以確保模型如預期般執行。 使用 機器學習 安全推出策略,將模型部署至端點、對模型執行測試,並逐漸增加新模型的流量。 利用鏡像流量,將一百分比的即時流量鏡像到新的模型,以進行額外的驗證。 流量鏡像也稱為陰影,不會變更傳回給客戶端的結果。 所有要求仍會流向原始模型。 如需詳細資訊,請參閱 在線端點的安全推出。
其他考量
當您在生產環境中部署機器學習模型時,請記住這些考慮。
ONNX
若要優化機器學習模型的推斷,請使用 開放式類神經網路交換 (ONNX) 。 當您優化模型時,完全利用硬體功能可能會是一項挑戰,特別是當您使用不同的平臺時(例如雲端/邊緣或 CPU/GPU)。 您可以定型新的模型,或將現有的模型從另一種格式轉換成 ONNX。
多模型案例
單一模型可能不會擷取真實世界問題的複雜本質。 例如,超市具有不同區域之間的人口統計、品牌、SKU 和其他功能,因此建立單一銷售預測模型會面臨挑戰。 同樣地,區域變化可能會對智慧型手機預測性維護模型構成挑戰。 使用許多模型來擷取區域數據或存放區層級關聯性,以提供比單一模型更高的精確度。 多模型方法假設有足夠的數據可供此層級的數據粒度使用。
多模型案例有三個階段:數據源、數據科學和許多模型。
資料來源。 在數據源階段中,請務必只將數據分割成幾個元素。 例如,請勿將產品標識碼或條碼納入主要分割區,因為它會產生太多區段,而且可能會抑制有意義的模型。 品牌、SKU 或地區設定更適合元素。 請務必藉由移除可能會扭曲數據分佈的異常來簡化數據。
數據科學。 在數據科學階段中,數個實驗會平行執行至每個數據區段。 多模型實驗是一個反覆的程式,可評估模型以判斷最佳模型。
許多模型。 模型登錄中會註冊每個區段或類別的最佳模型。 將有意義的名稱指派給模型,使其更容易探索以進行推斷。 必要時使用標記,將模型分組為特定類別。
許多模型的批次推斷
對於許多模型,在批次推斷期間,預測會依週期性排程進行,而且可以處理同時執行的大量數據。 不同於單一模型案例,多模型推斷會同時發生。
許多批次推斷模型會針對單一受控端點使用多個部署。 特定模型的批次推斷會在 REST 或 SDK 呼叫期間叫用部署名稱。 如需詳細資訊,請參閱 將多個模型部署到一個部署。
許多模型的即時推斷
您可以將多個模型部署到單一受控在線端點,您可以透過 REST API 或 SDK 叫用。 當您建立部署時,請將多個模型註冊為 Azure 上的單一「已註冊模型」。 將多個模型包含在相同的目錄中,並將該目錄當做單一模型的路徑傳遞。 模型會載入索引鍵在其名稱上的字典中。 收到 REST 要求時,會從 JSON 承載擷取所需的模型,而相關的模型會為承載評分。
使用這項技術在多模型部署中載入的模型必須共用相同的 Python 版本,而且沒有衝突的相依性。 即使它們沒有完全具有相同的相依性,也必須同時匯入其連結庫。
如需範例,請參閱 使用自定義容器建立多模型部署。
下一步
意見反映
https://aka.ms/ContentUserFeedback。
即將推出:我們會在 2024 年淘汰 GitHub 問題,並以全新的意見反應系統取代並作為內容意見反應的渠道。 如需更多資訊,請參閱:提交及檢視以下的意見反映: