Azure OpenAI 服務 會公開 HTTP API，讓應用程式使用 OpenAI 的語言模型來執行內嵌或完成。 智慧型手機應用程式會直接從客戶端或協調器呼叫這些 HTTP API。 用戶端的範例包括聊天 UI 程式代碼和自定義數據處理管線。 協調器的範例包括 LangChain、Semantic Kernel 和 Azure 機器學習 提示流程。 當您的工作負載連線到一或多個 Azure OpenAI 實例時，您必須決定這些取用者是直接連線還是透過反向 Proxy API 閘道。
使用本指南來瞭解您在工作負載設計中包含從取用者直接存取 Azure OpenAI 數據平面 API 時 所遇到的 Azure 架構 架構五大要素的主要挑戰。 接著，瞭解如何將閘道引入您的架構，以協助解決這些直接存取挑戰，同時引進新的挑戰。 本文說明架構模式，但不會說明如何實作網關。
因為閘道可用來解決每個工作負載中可能不存在的特定案例，請參閱請務必查看 特定案例指引，以更深入地查看閘道的特定使用案例。
關鍵挑戰
若沒有 API 閘道或將邏輯新增至 Azure OpenAI HTTP API 的能力，客戶端必須處理 API 用戶端邏輯，其中包括重試機制或斷路器。 在您不直接控制用戶端程序代碼的案例中，或當程式代碼限製為特定 SDK 使用狀況時，這種情況可能會很困難。 多個用戶端或多個 Azure OpenAI 實例和部署提出了進一步的挑戰，例如協調安全部署和可檢視性。
本節提供當您的架構僅支援從取用者直接存取 Azure OpenAI 時，您可能會面臨的特定主要架構挑戰範例。 挑戰是使用 Azure 架構完善的架構要素來組織。
可靠性挑戰
工作負載的可靠性取決於數個因素，包括其自我保留和自我復原的能力，這些容量通常是透過復寫和故障轉移機制實作。 如果沒有閘道，則必須使用用戶端邏輯和 Azure OpenAI 服務功能，以獨佔方式解決所有可靠性考慮。 當這兩個介面中沒有足夠的可靠性控制可用時，工作負載可靠性就會遭到入侵。
備援： 根據服務可用性在多個 Azure OpenAI 實例之間故障轉移是您需要透過設定和自定義邏輯來控制的客戶端責任。
相應放大以處理尖峰： 節流時故障轉移至具有容量的 Azure OpenAI 實例是您需要透過設定和自定義邏輯控制的另一個客戶端責任。 更新新 Azure OpenAI 實例的多個用戶端組態會帶來更大的風險，而且有時程表的問題。 更新用戶端程式代碼以實作邏輯變更也是如此，例如在高需求期間將低優先順序要求導向佇列。
負載平衡或節流： Azure OpenAI API 會藉由將 HTTP 429 錯誤響應碼傳回給超過隨用隨付模型中令牌每分鐘（TPM）或每分鐘要求的要求，以節流要求。 Azure OpenAI API 也會節流超過預先布建計費模型的布建輸送量單位 （PTU） 容量的要求。 處理適當的輪詢和重試邏輯會完全留給客戶端實作。
安全性挑戰
安全性控制必須協助保護工作負載機密性、完整性和可用性。 如果沒有閘道，所有安全性考慮都必須在客戶端邏輯和 Azure OpenAI 服務功能中以獨佔方式解決。 工作負載需求可能比用戶端分割、用戶端控制或服務安全性功能所需的需求更多，以進行直接通訊。
身分識別管理 - 驗證範圍： Azure OpenAI 公開的數據平面 API 可透過下列兩種方式之一加以保護：API 密鑰或 Azure 角色型存取控制（RBAC）。 在這兩種情況下，驗證都會發生在 Azure OpenAI 實例層級，而不是個別的部署層級，這會為特定部署模型提供最低特殊許可權存取和身分識別分割帶來複雜性。
身分識別管理 - 身分識別提供者： 無法使用位於 Azure OpenAI 實例的 Microsoft Entra 租使用者中的身分識別，必須共用單一完整存取 API 密鑰。 API 金鑰具有安全性有用性限制，且涉及多個用戶端且全都共用相同的身分識別時，就會有問題。
網路安全性： 視 Azure OpenAI 實例的用戶端位置而定，可能需要公用因特網存取語言模型。
數據主權： Azure OpenAI 內容中的數據主權是指特定國家或地區地理界限內儲存和處理數據的相關法律和法規需求。 您的工作負載必須確保區域親和性，讓客戶端能夠遵守數據落地和主權法律。 此程序牽涉到多個 Azure OpenAI 部署。
成本優化挑戰
當架構將浪費降至最低並最大化公用程式時，工作負載會受益。 強式成本模型化和監視是任何工作負載的重要需求。 若沒有閘道，可以透過匯總 Azure OpenAI 實例使用量遙測，以授權方式達成 PTU 或個別用戶端成本追蹤。
成本追蹤： 能夠針對 Azure OpenAI 使用量提供財務觀點，僅限於從 Azure OpenAI 實例使用量遙測匯總的數據。 需要進行退款或回報時，您必須針對多租使用者案例，將使用量遙測歸因於不同部門或甚至是客戶的各種用戶端。
布建的輸送量使用率： 您的工作負載想要完全利用您支付的布建輸送量來避免浪費。 這表示客戶端必須受到信任和協調，才能使用以 PTU 為基礎的模型部署，再溢出至任何以耗用量為基礎的模型部署。
卓越營運挑戰
如果沒有閘道，可檢視性、變更控制及開發程式僅限於直接客戶端對伺服器通訊所提供的專案。
配額控制： 當 HTTP API 受到節流時，用戶端會直接從 Azure OpenAI 接收 429 回應碼。 工作負載操作員負責確保有足夠的配額可供合法使用，且行為不當的用戶端不會過度取用。 當您的工作負載包含多個模型部署時，瞭解配額使用量和配額可用性可能會難以可視化。
監視和可觀察性： Azure OpenAI 預設計量可透過 Azure 監視器取得。 不過，數據的可用性會有延遲，但不會提供即時監視。
安全部署做法： 您的 GenAIOps 程式需要在用戶端與 Azure OpenAI 中部署的模型之間進行協調。 針對進階部署方法，例如藍綠或 Canary，必須在用戶端上處理邏輯。
效能效率挑戰
若沒有閘道，您的工作負載會對客戶端負責個別運作良好，並與其他用戶端一起以有限的容量運作。
效能優化 - 優先順序流量： 將用戶端要求設為優先順序，讓高優先順序用戶端具有優先存取權，而低優先順序用戶端需要大量且可能不合理的用戶端對客戶端協調。 某些工作負載可能受益於在模型使用率偏低時，排入佇列以執行低優先順序的要求。
效能優化 - 客戶端合規性： 若要共用容量，客戶端必須表現良好。 其中一個範例是當客戶端確保
max_tokens和best_of設定為已核准的值時。 如果沒有閘道，您必須信任用戶端，以符合保留 Azure OpenAI 實例容量的最佳利益。將延遲降到最低： 雖然網路等待時間通常是整體提示和完成要求流程的一小部分，但確保用戶端已路由傳送至網路端點，且接近它們的模型可能很有説明。 若沒有閘道，客戶端必須自行選取要使用的模型部署端點，以及該特定 Azure OpenAI 數據平面 API 所需的認證。
解決方案
圖 1：透過閘道存取 Azure OpenAI 的概念架構
若要解決主要挑戰中列出的許多挑戰，您可以插入反向 Proxy 閘道，以將智慧型手機應用程式與 Azure OpenAI 分離。 此 閘道卸除 可讓您將責任、複雜度和可檢視性移離用戶端，並讓您有機會藉由提供未內建的其他功能來增強 Azure OpenAI。 一些範例包括：
可能實 作同盟驗證。
能夠透過 速率限制來控制模型的壓力。
跨領域和跨模型監視。
使用 健康情況端點監視 的負載平衡，藉由 在無法使用或多載的模型部署上中斷 線路，以路由傳送至健康情況端點。
某些特定案例有更多指引可供直接尋址 API 閘道和 Azure OpenAI 實例。 這些案例列在後續 步驟 一節中。
考量
當您將新的元件引入架構時，您需要評估新引進的取捨。 當您在用戶端與 Azure OpenAI 數據平面之間插入 API 閘道以解決任何 關鍵挑戰時，您會在架構中匯入新的考慮。 請仔細評估這些架構考慮中的工作負載影響是否合理地證明閘道的附加價值或公用程式。
可靠性
可靠性可確保您的應用程式符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性的設計檢閱檢查清單。
閘道解決方案可能會造成單一失敗點。 此失敗可能源自閘道平臺的服務可用性、因程式代碼或設定部署而中斷，或甚至是閘道中設定錯誤的重要 API 端點。 請確定您設計實作以符合工作負載的可用性需求。 請考慮在實作中的復原和容錯功能，方法是在工作負載的失敗模式分析中包含閘道。
如果您的架構需要多個區域中的 Azure OpenAI 實例，您的解決方案可能需要全域路由功能。 這種情況可透過管理額外的完整功能變數名稱、TLS 憑證和更多全域路由元件，進一步使拓撲複雜化。
重要
如果這樣做會危及工作負載符合服務等級目標（SLO）同意的能力，請勿實作閘道。
安全性
考慮 API 閘道對架構的優點時，請使用 安全性 的設計檢閱檢查清單來評估您的設計。 您需要解決安全性考慮，例如：
隨著新增閘道，工作負載介面區也會增加。 該介面區會針對 Azure 資源帶來額外的身分識別和存取管理（IAM）考慮、增加強化工作等等。
閘道可作為用戶端網路空間與私人 Azure OpenAI 網路空間之間的網路界限轉換。 雖然閘道透過使用 Azure Private Link 將先前面向因特網的 Azure OpenAI 端點變成私人，但它現在已成為新的進入點，而且必須受到充分保護。
網關處於唯一的位置，可查看原始要求數據和來自語言模型的已制定回應，其中可能包含來自任一來源的機密數據。 數據合規性和法規範圍現在已延伸至這個其他元件。
閘道可以延伸用戶端授權和驗證的範圍，超越Microsoft Entra ID 和 API 金鑰驗證的範圍，而且可能跨多個識別提供者 （IdP）。
數據主權必須在多區域實作中納入實作。 請確定您的閘道計算和路由邏輯遵守您工作負載上放置的主權需求。
重要
如果這樣做會讓您的工作負載無法保護本身或其用戶數據的機密性、完整性或可用性，請勿實作網關。
成本最佳化
成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化的設計檢閱檢查清單。
所有實作的 API 閘道都有需要預算和考慮的運行時間成本。 這些成本通常會隨著新增功能而增加，以解決閘道本身的可靠性、安全性和效能，以及新增 APIOps 管理引進的營運成本。 這些新增的成本必須根據透過閘道從系統傳遞的新值來測量。 您想要達到使用閘道引進的新功能超過實作和維護閘道的成本。 視工作負載與其用戶的關係而定，您可能能夠退款使用量。
若要協助在開發和測試閘道時管理成本，請考慮使用 Azure OpenAI 的模擬端點。 例如，使用 Azure OpenAI API 模擬器 GitHub 存放庫中的解決方案。
卓越營運
考慮 API 閘道對您的架構的優點時，請使用 Operational Excellence 的設計檢閱檢查清單來評估您的設計。 您需要解決營運卓越考慮，如下所示：
閘道本身必須由工作負載的監視解決方案和客戶端監視。 這表示閘道計算和作業必須包含在工作負載的健康 情況模型化中。
您的安全部署做法現在必須解決 API 閘道基礎結構的部署，以及閘道路由的程式代碼或組態。 基礎結構自動化和基礎結構即程序代碼 （IaC） 解決方案必須考慮如何將閘道視為工作負載中的長期資源。
您必須建置或擴充 APIOps 方法，以涵蓋閘道中公開的 API。
效能效率
考慮 API 閘道對架構的優點時，請使用 效能效率 的設計檢閱檢查清單來評估您的設計。 您需要解決效能效率考慮，如下所示：
閘道服務可能會造成輸送量瓶頸。 請確定閘道有足夠的效能來處理完整並行負載，並可以輕鬆地根據您的成長預期進行調整。 確保解決方案中的彈性，讓閘道可在需求不足時減少供應量或相應減少，例如使用工作日。
閘道服務已處理它必須針對每個要求執行，並導入每個 API 調用的新增延遲。 您應該將路由邏輯優化，以讓要求執行良好。
在大部分情況下，網關應該位於使用者和 Azure OpenAI 實例附近，以減少延遲。 雖然網路等待時間在對語言模型的整體 API 呼叫中通常是一小部分的時間，但它可能是工作負載的競爭因素。
評估閘道對 Azure OpenAI 功能的影響，例如串流回應或實例釘選以進行具狀態互動，例如 Assistants API。
重要
如果這樣做會使達成談判的效能目標不可能或太損害其他取捨，請勿實作網關。
實作選項
Azure 不提供專為 Proxy Azure OpenAI 的 HTTP API 或其他自定義語言模型推斷 API 而設計的周全解決方案。 但是您的工作負載小組仍有數個選項可實作，例如 Azure 中的閘道。
使用 Azure API 管理
Azure API 管理 是一項平臺管理的服務，其設計目的是卸除 HTTP 型 API 的跨領域考慮。 它是由組態驅動，可透過其輸入和輸出要求處理原則系統進行自定義。 它支援高可用性、區域備援，甚至是使用單一控制平面的多區域複本。
大部分的網關路由和要求處理邏輯都必須在原則系統中實作 API 管理。 您可以結合 內建原則，例如 限制 Azure OpenAI API 令牌使用量 或 發出計量以取用 Azure OpenAI 令牌，以及您自己的自定義原則。 GenAI 閘道工具組 GitHub 存放庫包含數位自訂 API 管理 原則，以及用於測試原則行為的負載測試設定。
設計涉及 Azure API 管理 的解決方案時，請使用適用於 API 管理 的架構架構服務指南。 如果您的工作負載存在於應用程式登陸區域中，請檢閱在實作 Azure API 管理 登陸區域的 azure 雲端採用架構 中提供的指引。
針對閘道實作使用 Azure API 管理 通常是建置及操作 Azure OpenAI 閘道的慣用方法。 因為服務是具有豐富內建功能、高可用性和網路選項的平臺即服務（PaaS）供應專案，因此是慣用的。 它也具有健全的 APIOps 方法來管理完成 API。
使用自訂程序代碼
自定義程式碼方法需要軟體開發小組建立自定義自動程式化解決方案，並將該解決方案部署到他們所選擇的 Azure 應用程式平臺。 建置可處理閘道邏輯的自我管理解決方案，非常適合負責管理網路和路由程式代碼的工作負載小組。
工作負載通常可以使用他們熟悉的計算，例如在 Azure App 服務、Azure Container Apps 或 Azure Kubernetes Service 上裝載網關程序代碼。
當用戶端與自定義程式代碼之間的核心 HTTP API 閘道功能獨佔使用 API 管理 時，自定義程式代碼部署也可以使用 API 管理。 如此一來，您的自定義程式代碼會根據必要的商業規則，與 Azure OpenAI HTTP API 獨佔介面。
使用非Microsoft閘道技術，這是 Azure 原生提供的產品或服務，可視為此方法的一部分。
範例架構
圖 2：透過 Azure API 管理 型閘道存取 Azure OpenAI 的範例架構
下一步
瞭解在智慧型手機應用程式與 Azure OpenAI 部署之間部署閘道以因應工作負載需求的特定案例：
瞭解如何實作 Azure OpenAI 模型的記錄和監視。
相關資源
- Azure OpenAI 服務
- Azure API 管理中的 API 閘道
- API 管理 登陸區域涵蓋產生的 AI 案例的 GitHub 存放庫
- API 管理 閘道工具組
- OpenAI API 模擬器