Azure 上 AI 工作負載的應用程式平臺
您必須仔細考慮 AI 工作負載部署的應用程式裝載平臺，以確保您可以最大化效率、作業的安全性和可靠性。
此設計區域涵蓋數種可能與您的 AI 工作負載相關的應用程式類型：
- 探勘資料分析 (EDA)
- 模型定型和微調
- 推斷
本文提供針對每個函式選取最佳平臺以符合您業務需求的指引。 您也可以將一般建議套用至所有這些函式。
建議
以下是本文所提供的建議摘要。
| 建議 | 描述 |
|---|---|
| 重複使用工具。 | 首先，評估您已使用的工具，以瞭解是否可以針對 AI 工作負載重複使用這些工具。 如果他們支援必要的功能，而且可以符合可靠性、安全性、成本和效能的需求，引進新工具可能不值得成本和精力。 |
| 請考慮數據的合規性需求，以及您打算部署的區域。 | 您可能需要限制您部署的區域，或將工作負載的部分彼此隔離，以符合合規性需求。 使用這項資訊進入您的設計階段，可協助您避免稍後需要重新設計。 |
| 最小化建置。 | 請考慮平臺即服務 （PaaS） 或軟體即服務 （SaaS） 解決方案，以將建置您自己的解決方案的作業負擔降到最低，例如修補和其他維護。 將新技術所需的第 2 天負擔降到最低，可簡化採用。 許多 AI 函式很複雜，因此不建議建置您自己的平臺。 |
| 瞭解您的配額和限制。 | 當您設計來使用 PaaS 或 SaaS 解決方案時，請瞭解任何適用的配額或限制。 相應放大以符合高流量需求的能力可能會受到配額或限制的影響，因此您可能需要調整您的設計，以將風險降到最低。 |
| 部署在相同的區域中。 | 嘗試在相同的區域中部署所有相關資源，以減少延遲並簡化設計。 |
| 練習安全部署。 | 一般而言，您應該將 AI 工作負載的 API 視為與您環境中的任何其他 API 相同。 所有 API 都應該放在閘道後面，而且所有程式碼都應該使用與所有其他程式碼資產相同的 安全部署做法 來處理。 |
| 透過實驗建立效能基準。 | 每個 AI 工作負載都不同，您需要的計算量取決於您的使用案例。 藉由進行徹底的基準檢驗，判斷最適合您工作負載的計算數量和類型。 本指南可協助您選擇平臺，但在基準檢驗之後，您只會知道哪些 SKU 適合您的工作負載。 |
EDA 平台的考慮
EDA 是數據科學家在模型化或統計分析之前執行的常見初步功能。 因此，它可以被視為開發階段，這表示可靠性和效能的目標可能明顯低於生產資源的目標，並維持生產力是更重要的因素。
本節提供當您選取 EDA 平台解決方案時要考慮的功能指引。
功能需求
當您評估 EDA 平臺時，請考慮下列問題：
平臺是否支持暫時性使用？
平台應該支持暫時性工作區和計算，這表示您應該能夠在未使用資源時停止必要的資源。 這項功能可協助控制成本。 EDA 作業通常是互動式作業，因此用戶必須能夠在執行作業時啟動 VM 並加以停止。
平臺是否支持計算選擇性？
平臺應視需要啟用 GPU 的隨選取，並提供各種計算選項來協助調整平臺的大小。
平臺是否支援 MLflow？
您的 EDA 平台應該能夠選擇能夠與 MLflow 整合以追蹤實驗的技術。 我們建議 MLflow 作為模型開發、部署和管理通訊協議，因為它提供下列優點：
- 實驗追蹤。 MLflow 可讓您記錄參數、計量和成品來追蹤實驗。 這項功能在 EDA 期間很重要，因此您可以追蹤不同的數據前置處理步驟和特徵工程技術及其對模型效能的影響。
- 再現性。 因為它會記錄實驗的所有詳細數據，所以 MLflow 有助於確保您可以重現結果，這對驗證結果至關重要。
- 數據和模型版本控制。 MLflow 可協助建立版本設定數據集和模型，讓您更輕鬆地管理不同版本的數據轉換和測試模型。
- 共同作業工作。 MLflow 提供集中式平臺，讓數據科學家可以共用其實驗和結果，以利共同作業和知識共用。
非功能需求
也請考慮這些問題：
平臺如何協助控制成本？
平臺應讓數據科學家根據排程需求執行其工作，但應該適當調整大小，以確保符合成本預期。
平台必須遵循哪些安全性需求？
EDA 階段期間使用的數據可能是生產數據，因此您必須遵循生產作法來保護該數據並監視平臺。 為此，您的平台應該支援所有必要的安全性控制，包括：
- 存取和授權。
- 待用加密和傳輸中。
- 區域數據保護需求。
- 強固的監視和警示功能，包括記錄和稽核性。
- 容器映像、數據和程式代碼資產之集中式存放庫的專用網存取。
工具
使用 Azure 機器學習 計算實例搭配小組層級檔案共享作為 EDA 平臺。 其中一個例外狀況是，如果您的小組或組織已經使用適當的裝載平臺，例如 Databricks 中已啟用 GPU 的計算叢集， 例如。 在此情況下，留在該平臺上可能更合適。
注意
除非您需要，否則請勿建置完整的EDA平臺。 GPU 優化的計算成本很高，如果您的使用案例不需要，則不適用。
模型定型和微調平台的考慮
當您移至模型定型和微調時，可能需要高效能 GPU 優化計算，才能進行這些活動所需的計算密集型工作。 可靠性通常不如效能那麼重要，因為大部分的工作都會在幕後進行。 如果高可用性是需求，請評估是否需要將工作負載分散到可用性區域或區域。 當模型更新頻率頻繁時，可靠性會變得更重要，這需要更緊密的排程完成定型。 RTO 應該決定您選擇的可靠性設計。
本節中的指引適用於模型定型和微調。 除非您被迫針對這些函式使用不同的平臺，否則您應該使用單一平臺。
功能需求
當您評估模型定型和微調的平臺時，請考慮下列問題：
平臺是否支持暫時性使用？
就像EDA活動一樣，模型定型和微調通常不會全職執行，因此您應該使用平臺，在未使用時停止，以協助控制成本。 不過，不同於 EDA，模型定型通常是批次程式，因此只有在批次執行且可以在下一次執行之前關閉時，才需要計算。
平臺是否提供協調流程？
由於管理模型定型和微調計算所需的複雜度，我們建議使用協調器。
您環境中的現有技術是否可以成為解決方案的一部分？
如果您現有的數據平臺具有機器學習功能，例如 Azure Databricks，您可以將其用於某些步驟，例如數據轉換和特徵工程、訓練、微調，以及其他 機器學習 中的步驟。 結合技術可協助您將使用數據平台處理功能的成本和複雜度降到最低，而它可能不適合。
非功能需求
也請考慮這個問題：
成本和效能之間的可容忍取捨為何？
鑒於高效能、GPU 優化的計算需求，請確定您廣泛測試和微調定型和微調，以判斷平衡效能與成本的理想 SKU。
工具
我們建議針對模型定型和微調平臺使用 Azure 機器學習，因為它提供協調流程功能來支援批次計算。 有兩個計算選項可以評估：
- 無伺服器計算 非常適合短期、不常執行的作業，可容許嘈雜的鄰近效應。 您可以選擇標準定價或現成定價。 僅建議針對高度中斷的訓練使用現成定價。 請勿使用無伺服器計算進行全職作業。 成本可能會迅速升級。
- 計算叢集 可讓您大幅控制可用的硬體，並針對平行或分散式定型進行調整。
注意
針對基礎模型，您選擇的模型裝載平臺可能會限制微調選項。 例如，針對模型裝載使用 Azure OpenAI 服務，會將微調選項限製為內建的 Azure OpenAI 微調功能。
模型裝載和推斷平台的考慮
模型裝載和推斷函式組成 AI 工作負載服務層。 這些函式是使用您所使用軟體專屬的端點來執行。 模型服務的軟體解決方案，例如 NVIDIA Triton、TorchServe 和 TensorFlow 服務，基本上是 Python SDK，其前面是具有 API 的模型，並新增解決方案特有的功能。 您可以根據您的軟體選擇選擇選擇來選擇裝載平臺，或根據您選擇的裝載平臺來選擇您的軟體。
當您搭配預先封裝的模型使用 SaaS 或 PaaS 解決方案時，例如 Azure OpenAI 中可用的大型語言模型，您很少或沒有機會選取服務的軟體。 相反地，您取用的服務會提供 API。 這可降低建立模型部署程序的彈性，這可提供優點和缺點。 例如，它可以簡化工作負載的開發程式。 另一方面，它可減少應用程式如何呼叫和與模型互動的彈性。
基本上，服務層的 API 是微服務，因此您應該針對環境中其他微服務遵循的相同做法。 它們應該容器化、 從其他服務進行大量 處理，並有自己的生命周期，獨立於其他服務和 API。 不過，請記住，服務層 API 通常需要比傳統 API 更多的 GPU 型計算能力和更大的容器映像。
本節提供當您選取模型裝載和推斷平臺時要考慮的功能指引。
功能需求
當您評估模型裝載和推斷的平臺時，請考慮下列問題：
您的工作負載是否需要批次或在線推斷？
推斷端點會用於批次或在線推斷程式，而推斷方法有助於判斷正確的裝載平臺。 批次推斷最好裝載在支持暫時性使用的平臺上，並允許在不使用時關閉計算。 在線推斷最適合裝載於支援彈性計算使用率的平臺上，該平臺會根據任何指定時間的負載自動調整。
平臺是否支援可追蹤性？
可追蹤性對於維護工作負載中使用的模型完整性至關重要。 請務必瞭解模型的相關信息，例如目前版本、部署模型、部署時，以及模型的數據譜系。
將有意義的標籤套用至容器登錄中的映像，以確保您的模型裝載服務會提取小組可以輕鬆地識別的特定版本。 這種方法可藉由降低生產環境中使用過時或不正確模型的風險，協助數據控管。
您的裝載平臺會是集中式資源嗎？
許多組織會使用不同小組針對自己的工作負載使用的集中式模型裝載平臺。 如果您的主控平臺是集中式的，您應該考慮是否需要支援退款。 這項功能可讓您追蹤小組和工作負載的平臺使用率。
非功能需求
也請考慮這些問題：
平臺的可靠性需求為何？
服務層 API 是生產資源，因此您應該將相同的可靠性需求套用至符合其 關鍵性 評等的其他工作負載流程。 如果其關鍵性需要高可用性，您的裝載平臺應該支援可用性區域或多重區域設計。
平臺需要哪些網路控制措施？
判斷您是否需要專用網或輸出防火牆來為平臺提供保護。
平臺的身分識別和存取安全性需求為何？
判斷端點所需的身分識別和訪問控制。 請考慮您是否需要原生角色型訪問控制 （RBAC） 或身分識別和存取平臺的內建支援，例如，Microsoft Entra ID。
平台支援哪些監視功能？
判斷端點所需的監視功能。 視平臺而定，您可能只能存取記錄和計量，這可能會限制您稽核活動或偵測故障的能力。
平臺的效能需求為何？
推斷延遲是常見的考慮，而不同的平臺有不同的效能配置檔。 使用公用程式模型的無伺服器和 PaaS 服務可能會受到嘈雜的鄰近問題影響，而且通常沒有輸送量保證。 另一方面，相同的平臺可能會提供自我裝載選項，以提供預先購買模型的保證輸送量。 您也可以考慮在 Kubernetes 上自我裝載，以取得更可預測的延遲行為。
請注意可能會影響效能的服務限制和配額，例如適用於 Azure OpenAI 的服務限制和配額。 通常，這些配額和限制會積極設定為符合容量需求，因此，如果您選擇的平臺不提供所需的效能，您可能需要採用策略，將計算需求分散到實例。
進階架構可以結合多個部署，以達到大量工作負載的固定輸送量，以及更有彈性計算的高載功能。
工具
批次推斷
如果您要對位於支援模型裝載的平臺中的數據執行推斷，例如 Databricks，請考慮使用該平台進行推斷。 請務必隔離推斷計算與數據平臺所執行的其他函式。
針對非基礎模型，請考慮下列建議：
請考慮針對下列案例使用 Azure 機器學習 批次端點：
您必須在分散於多個檔案的大型數據集上執行推斷，而且不需要低延遲。
您必須對大型數據集執行長時間執行的批次作業，並可以利用平行處理。
您需要部署管線元件以進行批處理。
如果您需要執行 Spark 作業以進行分散式數據處理，請考慮使用 Azure Synapse Analytics、Databricks 或 機器學習 無伺服器 Spark 計算。
如果這些案例都不適用，建議您 機器學習 批次端點。
在線推斷
將平臺 PaaS 和無伺服器解決方案評估為第一個步驟。 這些服務通常是最容易採用和管理的服務，因為它們可簡化您的設計，並將作業負擔降到最低。 例如，Azure OpenAI 是基礎模型的絕佳選擇。
- 即使您使用 Azure OpenAI 或其他基礎模型裝載解決方案，也請考慮使用 Azure 機器學習 無伺服器 API 來匯總端點存取。
當 PaaS 或無伺服器解決方案不適合時，請考慮使用受控計算叢集 機器學習。 機器學習 所管理的計算支援 A/B 測試、偵錯和強固稽核的流量分割和鏡像。 因為計算是由服務管理，因此當您自行裝載模型時，第 2 天作業會比較容易。 受控計算也提供廣泛的計算組態和調整功能。
如果您選擇在連結至 機器學習 或其他容器型平臺的 Azure Kubernetes Service （AKS） 叢集上自我裝載模型，請確定節點集區與叢集上的其他 API 或任何其他工作負載隔離，以達到可預測的效能並優化安全性。 請避免針對 AI 工作負載函式以外的任何專案使用 GPU 型或 GPU 優化計算，以降低成本。 相反地，透過測試和正確調整計算大小來建立效能基準，以符合您的效能需求，而不需過度布建。
您也可以使用基礎結構即服務 （IaaS） 解決方案來自我裝載模型，例如 Azure 資料科學虛擬機器。
協調流程平台的考慮
協調流程，在 AI 工作負載應用程式平台的內容中，是指 機器學習 和 Azure AI Studio 中的提示流程等工具。 這些工具的設計目的是藉由自動化許多常見的工作流程函式，簡化 AI 應用程式的整個開發週期。
非功能需求
如同雲端資產中所有其他生產工作負載一樣，當您評估協調流程工具時，您需要考慮：
可靠性、安全性和監視。 協調流程工具應遵守生產工作負載的可靠性、安全性和監視標準。
效能： 協調流程工具不需要 GPU 優化或 GPU 型計算，請考慮一般用途 SKU。
成本最佳化。 協調流程工具一律開啟，請考慮彈性計算選項，以將使用率成本降到最低。
工具
偏好現成的解決方案，例如提示流程。 先判斷其功能是否符合您的協調流程需求，再使用 LangChain 或 Semantic Kernel 等工具來查看自定義裝載。
在具有計算實例的 機器學習 或具有自我裝載的 AKS 上，例如提示流程等解決方案的主機端點。