共用方式為

Azure 上 AI 工作負載的設計原則

  • 發行項

本文概述 Azure 上 AI 工作負載的核心原則，並著重於架構的 AI 層面。 務必綜合考慮所有 Azure Well-Architected Framework 的支柱，包括它們的取捨。 將每個要素套用至工作負載的功能和非功能需求。

可靠性

在 Azure 中執行的 AI 工作負載必須考慮許多與其他工作負載類別相同的可靠性需求。 模型定型、裝載和推斷的特定考慮特別重要，主要在此原則中加以解決。 這裡概述的作法除了雲端應用程式的標準設計最佳做法之外，也應該據以整合。

請檢閱 可靠性設計原則，以充分了解這裡所述的概念。

設計原則 考量
減輕單一失敗點。 依賴重要元件的單一實例可能會導致重大問題。 若要避免問題，請將備援建置到所有重要元件中。 使用具有內建容錯和高可用性功能的平臺。 部署多個實例或節點以實作備援。
進行失敗模式分析。

利用已知的設計模式。		 定期分析系統元件中潛在的失敗模式，並針對這些失敗建置復原能力。 使用已知的設計模式來隔離系統的各個部分，並防止串連失敗。 例如，Bulkhead隔板模式可以幫助隔離故障。 重試機制和斷路器可以處理暫時性錯誤，例如節流要求。
在相依元件之間平衡可靠性目標。 請確定推斷端點或模型，以及數據存放區在可靠性方面都一致。 即使發生非預期的狀況，應用程式元件仍必須維持可用狀態，例如並行使用者的激增。 工作負載應具有在發生故障時轉移至備份系統的能力。 如果某個元件失敗，它會影響另一個元件的可靠性。

同樣地，由於服務層 API 是重要的生產資源，因此應該遵守與其他高關鍵性工作負載流程相同的可靠性標準。 如果這些 API 需要高可用性，裝載平台必須支援可用性區域或多重區域設計，以確保持續作業和復原能力。
作業可靠性的設計。 確保更新頻繁且及時，以維護模型回應的可靠性。 決定是否要使用最近的數據，或稍微舊的數據是否足夠。 將 up-to日期資訊的需求與更新頻率的實際性進行平衡。 因為頻率和可靠性的需求，自動化線上訓練。 透過成本效益分析來證明離線訓練的合理性，並使用更便宜的資源來執行。
設計可靠的用戶體驗。 使用負載測試來評估工作負載如何處理壓力，並設計使用者介面來管理使用者對回應時間的期望。 實作UI元素，告知用戶潛在的等候時間，並採用異步雲端設計原則來解決插播、延遲或失敗。

安全性

模型通常會使用敏感性生產數據來產生相關結果。 因此，您必須在架構的所有層級使用健全的安全性措施。 在生命週期早期實作安全的應用程式設計、加密待用數據和傳輸中的數據，並遵循業界合規性標準。 定期安全性評估對於識別和減輕弱點至關重要。 進階威脅偵測機制可確保對潛在威脅的提示回應。

安全性原則 是 AI 解決方案的基礎，可保護數據完整性、設計完整性和使用者隱私權。 身為工作負載擁有者，您必須負責建置信任和保護敏感性資訊，以確保安全用戶體驗。

設計原則 考量
贏得使用者信任。 使用自定義程式代碼、適當的工具和有效的安全性控制，在生命週期的每個階段整合內容安全性。

拿掉所有資料儲存點中不需要的個人和機密資訊，例如匯總的數據存放區、搜尋索引、快取和應用程式。 在整個架構中一致地維護此層級的安全性。

請確定徹底的內容審查會雙向地審核數據，並篩選出不適當和冒犯性的內容。
根據工作負載的敏感度需求，保護待用數據、傳輸中和使用中數據。 至少，在架構中使用的所有數據存放區上，使用平臺層級加密搭配Microsoft管理或客戶管理的密鑰。 視需要較高層級的加密，並視需要使用雙重加密來評估位置。

確定所有流量都使用 HTTPS 進行加密。 決定每個躍點的 TLS 終止點。

模型本身必須受到保護，以防止攻擊者擷取定型期間所使用的敏感性資訊。 此保護需要最高層級的安全性措施。 請考慮使用允許推斷加密數據的同型加密。
投資強固的存取管理，以保留存取系統的身分識別（使用者和系統）。 針對控件和數據平面實作角色型訪問控制或屬性型訪問控制。

維護適當的身分識別分割以保護隱私權。 只允許使用者存取他們有權檢視的內容。
透過分割來保護設計的完整性。 提供專用網功能，以存取容器映像、數據和程式代碼資產的集中式存放庫。

當與其他工作負載共用基礎結構時會產生分段，例如在 Azure Kubernetes Service 中托管推斷伺服器時，應將節點集區與其他 API 或任何其他工作負載隔離。
進行安全性測試。 開發詳細的測試計劃，其中包含每當系統導入變更時，偵測不道德行為的測試。

將 AI 元件整合到您現有的安全性測試中。 例如，將推斷端點併入您的例程測試與其他公用端點。

請考慮對即時系統進行測試，例如滲透測試或紅色小組練習，以有效識別並解決潛在的弱點。
強制執行嚴格的使用者存取和 API 設計，以減少受攻擊面。 需要驗證所有推斷端點，包括系統對系統呼叫。 避免匿名端點。

偏好以客戶端彈性為代價限制的 API 設計。

取捨。 提供最高安全性在成本和準確性上需要取捨，因為分析、檢查或記錄加密數據的能力有限。 在高度安全的環境中，內容安全性檢查和實現可解釋性也可能是一項挑戰。

下列設計區域提供上述原則和考慮的詳細數據：

成本最佳化

成本優化支柱旨在將投資最大化，但不一定降低成本。 每個架構選擇都有直接或間接的財務影響。 瞭解與各種選項相關的成本，包括組建與購買決策、技術選擇、計費模型、授權、訓練和營運費用。 最大化您在所選層的投資，並持續重新評估計費模型。 持續評估與架構、商務需求、流程和小組結構變更相關聯的成本。

請檢閱 成本優化原則，並著重於速率和使用量優化。

設計原則 考量
執行完整的成本模型化練習，以判斷成本驅動因素。 請考慮資料與應用程式平臺的主要因素：
- 數據量。 估計您要編製索引和處理的數據量。 較大的磁碟區可能會增加記憶體和處理成本。
- 查詢數目。 預測查詢的頻率和複雜度。 較高的查詢磁碟區可能會提高成本，特別是如果它們需要大量的計算資源。
- 輸送量。 評估預期的輸送量，這會影響您需要的效能層級。 更高的輸送量需求可能會導致更高的成本。
- 相依性成本。 相依性可能會隱藏成本。 例如，當您計算索引的成本時，請包含技能集的成本，這是數據處理的一部分，但超出索引範圍。
支付您想要使用的內容。 選擇符合您需求的技術解決方案，而不會產生不必要的費用。 如果不需要進階功能，請考慮更經濟的選項和開放原始碼工具。

考慮使用頻率。 偏好協調流程工具的彈性計算選項，以將使用率成本降到最低，因為它們一律 。 全職作業應避免使用無伺服器計算，以免成本可能增加。

不要在未使用完整容量時支付更高的層級費用。 請確定您選擇的階層符合生產使用模式，以將支出優化。 針對一般工作使用標準定價，並針對高度中斷的訓練使用標準定價。 僅針對 AI 工作負載函式使用 GPU 型計算來降低成本。

全面測試和評估您的模型訓練和調整，以找出效能與成本均衡的最佳產品版本。
使用您支付的費用。 將浪費降至最低。 密切監視使用率計量。 如果資源未關閉、相應減少或未使用時解除分配，AI 工作負載可能很昂貴，而且成本可能會快速呈報。

將系統優化一 次寫入，讀取許多 以避免在數據記憶體上超支。 定型數據不需要生產資料庫的立即回應性。

執行 Azure OpenAI 服務推斷端點的壓力測試可能會很昂貴，因為每次呼叫都會產生費用。 若要降低成本，請在測試環境中使用未使用的 Azure OpenAI PTU，或改為模擬推斷端點。

探勘數據分析（EDA）、模型定型和微調等活動通常不會全職執行。 偏好選擇一個可以在未使用時停止的平台。 例如，EDA 作業通常是互動式的，因此用戶必須能夠在執行作業時啟動 VM 並加以停止。

在營運團隊上設定成本責任。 它們應透過主動監視和管理資源使用率，確保成本保持在預期參數內。
將營運成本優化。 在線訓練的成本可能很高，因為它的頻繁性質。 自動化此程式有助於維護一致性，並將人為錯誤的成本降到最低。 盡可能使用稍微舊的數據來定型和延遲更新，以進一步降低費用，而不會大幅影響模型精確度。

針對離線訓練，請評估您是否可以使用更便宜的資源，例如離線硬體。

一般而言，從功能存放區刪除數據，以減少功能雜亂和儲存成本。

取捨：成本優化和效能效率。 平衡成本與資料庫管理中的效能牽涉到考慮取捨。 有效率的索引設計可加速查詢，但可能會因為元數據管理和索引大小而增加成本。 同樣地，分割大型數據表可以改善查詢效能，並減少記憶體負載，但會產生額外的成本。 相反地，避免過度編製索引的技術可以降低成本，但如果未正確管理，可能會影響效能。

取捨：成本優化和營運卓越。 模型定型的兩個主要方法中有取捨。 在開發環境中使用完整生產數據進行訓練可以降低計算成本，方法是將模型訓練一次，並僅提升人工產物。 需要嚴格的安全性措施，以處理較低環境中的生產數據。 此過程可能相當複雜，且資源密集。 相反地，在每個環境中訓練模型，透過徹底的程式代碼檢閱和測試可增強穩定性和可靠性，但計算成本會因為這些執行而增加。

卓越營運

卓越營運的主要目標是在開發生命週期中有效率地提供功能。 您必須建立可重複的程式，以支援實驗的設計方法，併產生結果，以改善模型效能。 卓越營運也在於觀察模型的持續精確度、實作有效的監視做法和治理，以將風險降到最低，以及開發適應模型漂移的變更管理程式。

雖然所有 卓越營運原則 適用於 AI 工作負載，但將自動化和監視排定優先順序作為基礎作業策略。

設計原則 考量
在整個應用程式開發、數據處理和 AI 模型管理生命週期中，培養持續學習和實驗思維。 工作負載作業應該以產業證明的方法為基礎，例如DevOps、DataOps、MLOps和 GenAIOps。

作業、應用程式開發和數據小組之間的早期共同作業，對於建立可接受的模型效能相互了解至關重要。 作業小組提供質量訊號和可採取動作的警示。 應用程式和數據小組可協助有效率地診斷和解決問題。
選擇可將作業負擔降到最低的技術。 當您選擇平台解決方案時，宜優先考慮平台即服務（PaaS）而非自行托管的選項，以簡化設計、自動化工作流程協調，並使日常運營變得更加便捷。
建置支援警示功能的自動化監視系統，並包含記錄和稽核性。 由於 AI 的不具決定性本質，因此在生命週期早期建立質量測量非常重要。 與數據科學家合作，以定義品質指標，並在綜合儀錶板中將持續的見解可視化。

透過工具追蹤實驗，以擷取程式代碼版本、環境、參數、執行和結果等詳細數據。

使用足夠的資訊實作可採取動作的警示，讓操作員快速回應。
自動偵測和降低模型衰變。 使用自動化測試來評估一段時間的漂移。 確定您的監視系統會在回應開始偏離預期結果時傳送警示，並定期開始執行。 使用可自動探索和更新新模型的工具。

視需要調整數據處理和模型定型邏輯，以適應新的使用案例。
練習安全部署。 選擇並存部署或就地更新，以將停機時間降到最低。 在部署前實作徹底的測試，以確保模型已正確設定並符合目標、使用者期望和質量標準。 不論部署策略為何，一律規劃緊急作業。
持續評估生產環境中用戶體驗。 讓使用工作負載的使用者提供他們使用經驗的意見反饋，並同意在相關記錄中共用部分或所有交談內容，以進行疑難排解。 請考慮哪些用戶互動是可行的、符合規範的、安全的，以及值得擷取的。 請仔細使用數據，以真實用戶互動來評估工作負載的效能表現。

下列設計區域提供上述原則和考慮的詳細數據：

效能效率

AI 模型效能評估的目標是要判斷模型如何有效地完成其預定的工作。 評估牽涉到評估各種計量，例如精確度、精確度和公平性。 支援模型的平臺和應用程式元件效能非常重要。

模型效能也會受到實驗追蹤和數據處理等作業效率的影響。 套用 效能效率原則，以協助根據可接受的品質列測量效能，這是偵測退化或衰變的關鍵。 若要維護工作負載，包括 AI 元件，則需要持續監視和評估的自動化程式。

設計原則 考量
建立效能基準。 在不同的架構區域進行嚴格的效能測試，並設定可接受的目標。 這項持續評估應該是作業程式的一部分，而不只是一次性測試。

基準檢驗適用於預測效能。 從基準開始瞭解初始模型效能，並持續重新評估，以確保其符合預期。
評估資源需要符合效能目標。 瞭解負載特性，以選擇正確的平臺和正確大小資源。 將此數據納入容量規劃，以便大規模運作。

例如，使用負載測試來判斷最佳的計算平臺和產品版本。 模型定型和微調通常需要高效能 GPU 優化的計算。 一般用途的產品版本適用於協調流程工具。

同樣地，選擇可有效率地處理數據擷取、管理並行寫入，以及維護個別寫入效能且不會降低的數據平臺。

不同的推斷伺服器具有影響運行時間模型效能的各種效能特性。 選取符合基準預期的伺服器。
收集和分析效能計量，並找出瓶頸。

從資料管道評估遙測，以確保讀寫作業的吞吐量和效能目標得以實現。
針對搜尋索引，請考慮查詢延遲、輸送量和結果精確度等計量。 隨著數據量增加，錯誤率不應該上升。

分析來自程式代碼元件的遙測，例如協調器，其會從服務呼叫收集數據。 分析該數據，以協助您瞭解在本機處理與網路呼叫上花費的時間，並找出其他元件的潛在延遲。

使用參與計量來評估UI體驗，以判斷使用者是否積极參與或感到沮喪。 頁面上增加的時間可能表示其中一個。 語音或視訊回應等多模式功能可能會經歷顯著的延遲，這會導致回應時間更長。
使用來自生產的質量測量來持續改善效能評定。 需要自動收集和分析效能計量、警示和模型重新定型，以維持模型效力。

取捨。 當您考慮平臺功能時，請務必平衡成本和效能。 例如，GPU 版本昂貴，因此請持續監控，以避免使用量過低及調整資源至合適的規模。 調整後，測試資源使用率，以確保平台資源的成本、其操作及根據標準預期的效能之間的平衡。 如需成本優化策略，請參閱 優化元件成本的建議。

下列設計區域提供上述原則和考慮的詳細數據：

後續步驟

設計區域：應用程式設計