Azure OpenAI 服務的 Azure 架構架構觀點
Azure OpenAI 服務提供對 OpenAI 大型語言模型 （LLM） 的 REST API 存取權，並新增 Azure 網路和安全性功能。 本文提供架構建議，協助您在使用 Azure OpenAI 作為工作負載架構的一部分時做出明智的決策。 本指南是以 Azure 架構完善的架構要素為基礎。
重要
如何使用本指南
每個區段都有一個 設計檢查清單 ，可呈現關注的架構區域，以及當地語系化至技術範圍的設計策略。
此外， 也包含可協助具體化這些策略的技術功能建議 。 建議並不代表 Azure OpenAI 及其相依性可用之所有組態的完整清單。 相反地，他們會列出對應至設計檢視方塊的主要建議。 使用建議來建置概念證明或優化現有的環境。
示範重要建議的基礎架構： 基準 OpenAI 端對端聊天參考架構。
技術範圍
此檢閱僅著重於 Azure OpenAI。
可靠性
可靠性支柱的目的是要藉由 建置足夠的復原能力和從失敗中快速復原的能力，來提供持續的功能。
可靠性設計原則提供適用於個別元件、系統流程和整個系統的高階設計策略。
設計檢查清單
根據 可靠性的設計檢閱檢查清單，啟動您的設計策略。 判斷其與您業務需求的相關性。 擴充策略，以視需要包含更多方法。
復原：根據您的使用案例，選擇隨用隨付或布建輸送量的適當部署選項。 因為保留容量會增加復原能力，請選擇生產解決方案的布建輸送量。 隨用隨付方法非常適合開發/測試環境。
備援：在 Azure OpenAI 部署前面新增適當的閘道。 網關必須能夠承受暫時性失敗，例如節流，也可以路由傳送至多個 Azure OpenAI 實例。 請考慮路由至不同區域中的實例，以建立區域備援。
復原能力：如果您使用布建的輸送量，請考慮同時部署隨用隨付實例來處理溢位。 當布建的輸送量模型節流時，您可以透過網路由呼叫隨用隨付實例。
復原：監視容量使用量，以確保您未超過輸送量限制。 定期檢閱容量使用量，以達成更精確的預測，並協助防止因容量限制而導致服務中斷。
復原：請遵循 使用大型數據文件 進行微調的指引，並從 Azure Blob 存放區匯入數據。 透過多部分表單上傳時，大型檔案 100 MB 或更大，可能會變得不穩定，因為要求是不可部分完成的，而且無法重試或繼續。
復原：定義復原策略，其中包含微調模型和訓練上傳至 Azure OpenAI 之數據的復原計劃。 因為 Azure OpenAI 沒有自動故障轉移，因此您必須設計包含整個服務和所有相依性的策略，例如包含定型數據的記憶體。
建議
| 建議 | 優點 |
|---|---|
| 監視隨用隨付率限制：如果您使用隨用隨付方法，請管理模型部署的費率限制，並監視每分鐘令牌使用量和每分鐘要求 （RPM） 的使用量。 | 這個重要的輸送量資訊會提供所需的資訊，以確保您從配額指派足夠的 TPM，以符合部署的需求。 指派足夠的配額可防止對已部署模型的呼叫進行節流。 |
| 監視布建輸送量的布建受控使用率：如果您使用布建的輸送量付款模型，請監視布建管理的使用率。 | 請務必監視布建管理的使用率，以確保不會超過 100%，以避免對已部署模型的呼叫進行節流。 |
| 啟用動態配額功能：如果您的工作負載預算支援，請在模型部署上啟用動態配額來執行過度布建。 | 只要從 Azure 的觀點來看，動態配額可讓您的部署耗用比平常配額更多的容量。 額外的配額容量可能會防止不想要的節流。 |
| 微調內容篩選：微調內容篩選，以將過於積極的篩選誤判降到最低。 | 內容篩選會根據不透明的風險分析封鎖提示或完成。 請確定已調整內容篩選條件，以允許工作負載的預期使用量。 |
安全性
安全性支柱的目的是為工作負載提供機密性、完整性和可用性保證。
安全性設計準則提供一種高階設計策略，透過將方法套用至圍繞 Azure OpenAI 的技術設計，以實現這些目標。
設計檢查清單
根據安全性的設計檢閱檢查清單來開始您的設計策略，並識別弱點和控制項，以改善安全性態勢勢。 然後，檢閱適用於 Azure OpenAI 的 Azure 安全性基準。 最後，視需要擴充策略以包含更多方法。
保護機密性：如果您將訓練資料上傳至 Azure OpenAI，請使用客戶自控金鑰進行資料加密、實作金鑰輪替策略，以及刪除訓練、驗證和訓練結果資料。 如果您針對訓練資料使用外部資料存放區，請遵循該存放區的安全性最佳做法。 例如，針對 Azure Blob 儲存體，請使用客戶自控金鑰進行加密，並實作金鑰輪替策略。 使用受控識別型存取、使用私人端點實作網路周邊，以及啟用存取記錄。
保護機密性：藉由限制 Azure OpenAI 資源可以存取的輸出 URL，以防範資料外流。
保護完整性：實作存取控制，以驗證和授權使用者對系統的存取，方法是使用最低權限準則，以及使用個別身分識別而非金鑰。
保護完整性：實作越獄風險偵測，以保護您的語言模型部署免受提示插入攻擊。
保護可用性：使用安全性控制措施來防止可能耗盡模型使用量配額的攻擊。 您可以設定控制措施來隔離網路上的服務。 如果必須從網際網路存取服務，請考慮使用閘道來封鎖可疑的濫用，方法是使用路由或節流。
建議
| 建議 | 優點 |
|---|---|
| 安全金鑰：如果您的架構需要 Azure OpenAI 金鑰型驗證，請將這些金鑰儲存在 Azure Key Vault 中，而不是儲存在應用程式程式碼中。 | 透過將祕密儲存在 Key Vault 中，將祕密與程式碼分開，可以降低洩漏祕密的機會。 分開也有助於集中管理祕密，進而減輕了金鑰輪替等責任。 |
| 限制存取：停用公開存取 Azure OpenAI，除非您的工作負載需要此公開存取。 如果您是從 Azure 虛擬網路中的取用者連線，請建立私人端點。 | 控制對 Azure OpenAI 的存取有助於防止來自未經授權使用者的攻擊。 使用私人端點可確保應用程式與平台之間的網路流量保持私人狀態。 |
Microsoft Entra ID:使用 Microsoft Entra ID 進行驗證，以及使用角色型存取控制 (RBAC) 來授權對 Azure OpenAI 的存取。 停用 Azure AI 服務中的本機驗證，並將 disableLocalAuth 設定為 true。 將認知服務 OpenAI 使用者角色授與執行完成或影像生成的身分識別。 將模型自動化管線和臨時資料科學存取權授與認知服務 OpenAI 參與者等角色。 |
使用 Microsoft Entra ID 可以集中身分識別管理元件，並消除 API 金鑰的使用。 搭配 Microsoft Entra ID 使用 RBAC 可確保使用者或群組確切具有執行其工作所需的權限。 無法透過 Azure OpenAI API 金鑰進行這類精細存取控制。 |
| 使用客戶自控金鑰：針對上傳至 Azure OpenAI 的微調模型和訓練資料，使用客戶自控金鑰。 | 使用客戶自控金鑰可讓您更有彈性地建立、輪替、停用和撤銷存取控制。 |
| 防範越獄攻擊：使用 Azure AI 內容安全工作室來偵測越獄風險。 | 偵測越獄嘗試以識別並封鎖嘗試略過 Azure OpenAI 部署安全機制的提示。 |
成本最佳化
成本優化著重於 偵測支出模式、將投資放在重要領域，以及優化其他人 以符合組織預算，同時符合商務需求。
閱讀成本優化設計原則，以瞭解達成這些目標的方法，以及與 Azure OpenAI 相關的技術設計選擇所需的取捨。
設計檢查清單
根據 投資成本優化 的設計檢閱檢查清單，開始您的設計策略。 微調設計，讓工作負載符合其配置的預算。 您的設計應該使用適當的 Azure 功能、監視投資，以及尋找經過一段時間優化的機會。
成本管理：開發成本模型，並考慮提示大小。 瞭解提示輸入和回應大小，以及文字轉譯為令牌的方式，可協助您建立可行的成本模型。
使用量優化：從 Azure OpenAI 的隨用隨付定價開始，直到令牌使用量可預測為止。
速率優化：當您的令牌使用量在一段時間內足夠高且可預測時，請使用 布建的輸送量 定價模型，以取得更佳的成本優化。
使用量優化：當您選擇模型時，請考慮 模型定價 和功能。 針對較不複雜的工作，例如文字產生或完成工作，從成本較低的模型開始。 如需語言翻譯或內容理解等更複雜的工作，請考慮使用更進階的模型。 當您選擇適合文字內嵌、影像產生或轉譯案例等使用案例的模型時，請考慮不同的 模型功能和 令牌使用限制上限。 藉由仔細選取最符合您需求的模型，即可將成本優化，同時仍能達到所需的應用程式效能。
使用優化：使用 API 呼叫所提供的令牌限制條件約束，例如
max_tokens和n，表示要產生的完成次數。使用優化：最大化 Azure OpenAI 價格斷點，例如微調和模型斷點，例如影像產生。 由於微調是每小時收費，因此請使用每小時可用的時間來改善微調結果，同時避免滑入下一個計費週期。 同樣地，產生100個映像的成本與1個影像的成本相同。 將價格斷點最大化至您的優勢。
使用優化：不再取用未使用的微調模型，以避免產生持續裝載費用。
調整使用量：優化提示輸入和響應長度。 較長的提示會藉由耗用更多令牌來提高成本。 不過，缺少足夠內容的提示無法協助模型產生良好的結果。 建立簡潔的提示，為模型提供足夠的內容來產生有用的回應。 也請確定您已將回應長度的限制優化。
成本效益：盡可能將每個呼叫的額外負荷降到最低，進而降低整體成本的 Batch 要求。 請確定您已將批次大小優化。
成本效益：因為模型有不同的微調成本，如果您的解決方案需要微調，請考慮這些成本。
監視和優化：設定可監視模型使用方式的成本追蹤系統。 使用該資訊來協助通知模型選擇和提示大小。
建議
| 建議 | 優點 |
|---|---|
設計用戶端程式代碼來設定限制：您的自定義客戶端應該使用 Azure OpenAI 完成 API 的限制功能，例如每個模型令牌數目上限（max_tokens） 或產生完成次數上限。n 設定限制可確保伺服器不會產生超過用戶端需求。 |
使用 API 功能來限制使用量，以符合用戶端需求的服務耗用量。 這可藉由確保模型不會產生耗用超過必要令牌的超長回應來節省成本。 |
| 監視隨用隨付使用量：如果您使用隨用隨付方法， 請監視 TPM 和 RPM 的使用方式 。 使用該資訊來通知架構設計決策，例如要使用的模型，以及優化提示大小。 | 持續監視 TPM 和 RPM 可提供相關計量，以優化 Azure OpenAI 模型的成本。 您可以將此監視與模型功能和 模型定價 結合，以優化模型使用量。 您也可以使用此監視來優化提示大小。 |
| 監視布建的輸送量使用量：如果您使用 布建的輸送量，請監視 布建管理的使用率 ，以確保您不會使用您所購買的布建輸送量。 | 持續監視布建管理的使用率可讓您瞭解布建輸送量是否使用量過低時所需的資訊。 |
| 成本管理：搭配 OpenAI 使用成本管理功能來監視成本、設定預算來管理成本，以及建立警示來通知專案關係人風險或異常狀況。 | 成本監視、設定預算和設定警示可提供適當的責任流程治理。 |
卓越營運
卓越營運主要著重於開發實務、可觀察性和發行管理的程式。
營運卓越設計原則提供高階設計策略，以達到工作負載作業需求的目標。
設計檢查清單
根據 卓越營運的設計檢閱檢查清單，開始您的設計策略。 此檢查清單會定義與 Azure OpenAI 相關的可觀察性、測試和部署程式。
Azure DevOps 文化特性：確保跨各種環境部署 Azure OpenAI 實例，例如開發、測試和生產環境。 請確定您有環境可在整個開發週期內支持持續學習和實驗。
可檢視性：監視、匯總和可視化適當的計量。
可檢視性：如果 Azure OpenAI 診斷不足以滿足您的需求，請考慮在 Azure OpenAI 前面使用 Azure API 管理 之類的網關，以在允許的情況下記錄傳入提示和傳出回應。 這項資訊可協助您了解傳入提示之模型的有效性。
放心部署：使用基礎結構即程序代碼 （IaC） 來部署 Azure OpenAI、模型部署，以及微調模型所需的其他基礎結構。
放心部署：遵循 大型語言模型作業 （LLMOps） 做法，以操作 Azure OpenAI LLM 的管理，包括部署、微調和提示工程。
自動化效率：如果您使用密鑰型驗證，請實作自動化金鑰輪替策略。
建議
| 建議 | 優點 |
|---|---|
| 啟用和設定 Azure 診斷：啟用和設定 Azure OpenAI 服務的診斷。 | 診斷會收集和分析計量和記錄，協助您監視 Azure OpenAI 的可用性、效能和作業。 |
效能效率
效能效率是維護用戶體驗， 即使藉由管理容量增加負載 也一定。 此策略包括調整資源、識別和優化潛在的瓶頸，以及優化尖峰效能。
效能效率設計原則提供針對預期使用量達成這些容量目標的高階設計策略。
設計檢查清單
根據 效能效率 的設計檢閱檢查清單，根據 Azure OpenAI 工作負載的關鍵效能指標來定義基準，開始您的設計策略。
容量：估計取用者的彈性需求。 識別需要同步回應的高優先順序流量，以及可異步和批處理的低優先順序流量。
容量：根據取用者估計的需求，對令牌取用需求進行基準檢驗。 請考慮使用 Azure OpenAI 基準檢驗工具來 協助您在使用布建的輸送量單位 （PTU） 部署時驗證輸送量。
容量：針對生產工作負載使用布建的輸送量。 布建的輸送量提供指定的模型版本的專用記憶體和計算、保留容量，以及一致的最大延遲。 隨用隨付供應專案可能會遭受 嘈雜的鄰近 問題，例如大量使用區域中增加延遲和節流。 此外，隨用隨付方法不提供保證的容量。
容量：在 Azure OpenAI 部署前新增適當的閘道。 確定閘道可以路由傳送至相同或不同區域中的多個實例。
容量：配置 PTU 以涵蓋您預測的使用方式，並使用 TPM 部署來補充這些 PTU，以處理超過該限制的彈性。 這種方法結合了基底輸送量與彈性輸送量，以提高效率。 如同其他考慮，此方法需要自定義網關實作，才能在達到 PTU 限制時，將要求路由傳送至 TPM 部署。
容量：同步傳送高優先順序要求。 將低優先順序要求排入佇列，並在需求不足時以批次方式傳送要求。
容量：選取符合效能需求的模型，考慮速度與輸出複雜度之間的取捨。 模型效能可能會根據所選的模型類型而有很大的差異。 專為速度而設計的模型提供更快的響應時間，這對需要快速互動的應用程式很有説明。 相反地，更複雜的模型可能會以犧牲回應時間增加為代價來提供高質量的輸出。
達到效能：對於聊天機器人或交談介面等應用程式，請考慮實作串流。 串流可藉由以累加方式將響應傳遞給使用者，以改善用戶體驗，藉此增強 Azure OpenAI 應用程式的感知效能。
達到效能： 決定何時在認可微調之前使用 微調。 雖然微調有良好的使用案例，例如，當引導模型所需的資訊太長或複雜而無法放入提示時，請確定提示工程和擷取增強世代 （RAG） 方法無法運作或更昂貴。
達到效能：請考慮使用每個取用者群組的專用模型部署來提供個別模型使用隔離，以協助防止取用者群組之間的嘈雜鄰居。
建議
Azure OpenAI 的效能效率沒有建議的設定。
Azure 原則
Azure 提供一組與 Azure OpenAI 及其相依性相關的大量內建原則。 您可以透過 Azure 原則 稽核上述一些建議。 請考慮下列原則定義：
這些 Azure 原則 定義也是 Azure OpenAI 的 Azure Advisor 安全性最佳做法建議。
下一步
請考慮下列文章做為資源，示範本文所醒目提示的建議。
- 使用此參考架構作為如何將本文指引套用至工作負載的範例： 基準 OpenAI 端對端聊天參考架構。
- 使用 Azure 機器學習 產品檔建置實作專業知識。