涉及 Azure OpenAI 服務的工作負載體系結構可以像一個或多個用戶端應用程式直接使用單一 Azure OpenAI 模型部署一樣簡單，但並非所有工作負載都可以如此簡單地設計。 更複雜的場景包括具有多個用戶端的拓撲、多個 Azure OpenAI 部署或多個 Azure OpenAI 執行個體。 在這些情況下，在 Azure OpenAI 前面引進閘道，對於工作負載的設計是可程式化的路由機制很有説明。
多個 Azure OpenAI 執行個體或模型部署可解決工作負載架構中的特定要求。 它們可以分為四種主要拓撲。
- 單一 Azure OpenAI 執行個體中的多個模型部署
- 單一區域和單一訂用帳戶中的多個 Azure OpenAI 執行個體
- 單一區域中跨多個訂閱的多個 Azure OpenAI 執行個體
- 跨多個區域的多個 Azure OpenAI 執行個體
這些拓撲本身不需要使用閘道。 閘道的選擇取決於工作負載是否受益於將其納入架構中。 本文介紹了四種拓樸各自解決的挑戰，以及在每個拓樸中包含閘道的好處和成本。
提示
除非另有說明，以下指南適用於基於 Azure API 管理的閘道或自訂程式碼閘道。 在大多數情況下，架構圖通常表示閘道元件以說明這一點。
單一 Azure OpenAI 執行個體中的多個模型部署
多個模型部署的拓撲詳細資訊
- Azure OpenAI 模式部署：多個
- Azure OpenAI 執行個體：1 個
- 訂閱數：1 個
- 地區：1個
多模型部署的拓樸使用案例
包含單一 Azure OpenAI 執行個體但包含多個並發部署模型的拓樸支援下列使用案例：
公開不同的模型功能，例如
gpt-35-turbo、gpt-4和自訂微調模型。公開不同的模型版本，例如
0613、1106和自訂微調模型，以支援工作負載演進或藍綠部署。公開分配的不同配額每分鐘 30,000 個標記 (TPM)、60,000 TPM) 以支援跨多個用戶端的消耗限制。
引入多模型部署閘道
在此拓撲中引入閘道的主要目的是使用戶端免於在執行個體上的可用部署中自行選擇特定模型執行個體。 閘道允許伺服器端控制將用戶端請求定向到特定模型，而無需重新部署用戶端程式碼或更改用戶端設定。
當您無法控制用戶端程式碼時，閘道尤其有用。 當部署用戶端設定比部署對閘道路由設定的變更更複雜或風險更大時，它也很有用。 您可以根據模型版本的藍綠推出策略來變更用戶端指向的模型，例如推出新的微調模型或從版本 X 升級到相同型號的 X+1。
閘道也可以用作單一 API 入口點，使閘道能夠識別用戶端。 然後，它可以根據該用戶端的身份或 HTTP 請求中的其他資訊來確定使用哪個模型部署來提供提示。 例如，在多租用戶解決方案中，租用戶可能會受到特定傳輸量的限制，且架構的實作是每個租用戶具有特定配額的模型部署。 在這種情況下，閘道負責根據 HTTP 請求中的資訊路由到租用戶模型。
提示
由於 API 金鑰和 Azure 基於角色的存取控制 (RBAC) 應用於 Azure OpenAI 執行個體級別，而不是模型部署級別，因此在此場景中新增閘道可讓你將安全性轉移到閘道。 然後，閘道在並發部署的模型之間提供額外的分段，否則無法透過 Azure OpenAI 的身份和存取管理 (IAM) 或 IP 防火牆進行控制。
在此拓撲中使用閘道允許基於用戶端的使用情況追蹤。 除非用戶端使用不同的 Microsoft Entra 服務主體，否則 Azure OpenAI 的存取記錄將無法區分多個用戶端。 在部署之前設定閘道可讓您的工作負載有機會追蹤各個可用模型部署中每個用戶端的使用情況，以支援退款或展示模型。
多模型部署拓樸的提示
雖然閘道能夠完全更改正在使用的模型，例如
gpt-35-turbo更改為gpt-4，但該更改可能會被視為對用戶端的破壞性更改。 不要讓閘道的新功能分散我們始終為此工作負載執行安全部署實務的注意力。此拓撲通常足夠簡單，可以透過 Azure API 管理策略而不是自訂程式碼解決方案來實作。
為了支援本機 SDK 與已發佈的 Azure OpenAI API 規格一起使用，請保持 API 與 Azure OpenAI API 的相容性。 當您的團隊沒有編寫所有工作負載用戶端的程式碼時，這種情況是一個更大的問題。 在決定為閘道設計 HTTP API 時，請考慮保持 Azure OpenAI HTTP API 相容性的好處。
雖然此拓撲在技術上支援 Azure OpenAI 執行個體的直通用戶端憑證 (存取標記或 API 金鑰)，但請強烈考慮實作憑證終止和重新建立。 這樣用戶端在閘道處取得授權，然後閘道會透過 Azure RBAC 授權給 Azure OpenAI 執行個體。
如果閘道設計為使用直通憑證，請確保用戶端無法繞過閘道或基於用戶端的任何模型限制。
將閘道部署在與 Azure OpenAI 執行個體相同的區域。
將閘道部署到訂閱中獨立於 Azure OpenAI 執行個體的私人資源群組。 將訂閱與後端隔離可以幫助透過關注點分離來推動 APIOps 方法。
將閘道部署到包含 Azure OpenAI 執行個體的 Azure 私人連結私人端點的子網路的虛擬網路。 將網路安全群組 (NSG) 規則套用至此子網，以僅允許閘道存取該私人端點。 應禁止對 Azure OpenAI 執行個體的所有其他資料平面存取。
避免使用閘道進行多模型部署的原因
如果控制用戶端的設定與控制閘道等級的路由一樣簡單或更容易，則閘道所增加的可靠性、安全性、成本、維護和效能影響可能不值得新增架構元件。
此外，某些工作負載情境可以從多模型部署方法遷移到多 Azure OpenAI 執行個體部署方法中受益。 例如，如果您有多個用戶端應使用不同的 RBAC 或存取金鑰來存取其模型，請考慮使用多個 Azure OpenAI 執行個體。 在單一 Azure OpenAI 執行個體中使用多個部署並在閘道層級處理邏輯身分分段是可能的，但當透過使用不同的 Azure OpenAI 執行個體提供實體 RBAC 分段方法時可能會過度。
單一區域和單一訂用帳戶中的多個 Azure OpenAI 執行個體
單一區域和單一訂用帳戶中的多個執行個體的拓撲詳細資訊
- Azure OpenAI 模型部署：一個或多個
- Azure OpenAI 執行個體：多個
- 訂閱數：1 個
- 地區：1個
單一區域和單一訂用帳戶中的多個執行個體的拓撲使用案例
包含單一區域中的多個 Azure OpenAI 執行個體和單一訂用帳戶的拓樸支援以下使用案例：
啟用安全分段邊界，例如每個用戶端的金鑰或 RBAC
為不同客戶提供簡單的退款模式
為 Azure OpenAI 可用性啟用容錯移轉策略，例如影響特定執行個體的平台中斷、網路設定錯誤或意外刪除的部署
啟用 Azure OpenAI 配額可用性的故障轉移策略，例如配對已布建的實例和用於溢出的標準實例
為單一區域和訂閱中的多個執行個體引入閘道
由於多種原因，客戶可能無法存取模型。 這些原因包括 Azure OpenAI 服務中斷、Azure OpenAI 限制請求或與工作負載操作相關的問題 (例如網路設定錯誤或無意中刪除模型部署)。 為了應對這些挑戰，您應該實現重試和熔斷邏輯。
此邏輯可以在閘道的用戶端或伺服器端實現。 在閘道中實現邏輯將邏輯從用戶端抽象化出來，從而沒有重複的程式碼並且可以在單一位置測試邏輯。 無論您是否擁有用戶端程式碼，這種轉變都可以提高工作負載的可靠性。
透過在單一區域和訂閱中使用具有多個 Azure OpenAI 執行個體的閘道，您可以將所有後端視為主動-主動部署，而不僅僅是在主動-被動容錯移轉中使用它們。 您可以在多個 Azure OpenAI 實例之間部署相同的佈建模型，並使用閘道在兩者之間進行負載平衡。
注意
標準配額是訂用帳戶層級，而不是 Azure OpenAI 實例層級。 對相同訂用帳戶中標準實例的負載平衡無法達到額外的輸送量。
布建 Azure OpenAI 時，工作負載小組所具備的其中一個選項是決定是否布建計費和輸送量模型或標準。 透過未使用的布建容量避免浪費的成本優化策略，是在布建布建的實例下稍微低於布建，並同時部署標準實例。 此拓撲的目標是讓用戶端先取用所有可用的預先配置輸送量，然後「高載」到超額的標準部署。 這種形式的計劃容錯移轉受益於本節開頭段落中提到的相同原因：將這種複雜性排除在用戶端程式碼之外。
當涉及閘道時，它處於獨特的位置來擷取有關用戶端正在互動的所有模型部署的詳細資訊。 雖然Azure OpenAI 的每個執行個體都可以擷取自己的遙測資料，但在閘道內這樣做可以讓工作負載團隊將所有使用的模型的遙測資料和錯誤回應發佈到單個存儲，從而使統一的儀表板和警報變得更容易。
關於單一區域中的多個執行個體和訂閱拓撲的提示
當閘道支援容錯移轉方案時，請確保閘道使用 Azure OpenAI 的 HTTP 回應中提供的
Retry-After資訊。 使用該權威資訊來控制您的斷路器實作。 不要連續存取返回429 Too Many Requests。 相反，請斷開該模型執行個體的電路。在閘道中可以嘗試透過先前請求追蹤模型消耗來在節流事件發生之前進行預測，但充滿了邊緣情況。 在大多數情況下，最好不要嘗試預測，而是使用 HTTP 回應代碼來驅動未來的路由決策。
當迴圈配置資源或故障轉移至不同的端點時，包括布建的溢出至標準部署時，請一律確定這些端點使用相同的模型在同一個版本。 例如，不要在版本
gpt-4和版本gpt-35-turbo之間進行容錯移轉，也不要在 和 之間進行負載平衡。 此版本變更可能會導致用戶端出現意外行為。負載平衡和容錯移轉邏輯可以在 Azure API 管理策略中實現。 您也許能夠使用基於程式碼的閘道解決方案提供更複雜的方法，但 API 管理對於此使用案例來說已經足夠了。
將閘道部署在與 Azure OpenAI 執行個體相同的區域。
將閘道部署到訂閱中獨立於 Azure OpenAI 執行個體的私人資源群組。 將閘道與後端隔離可以幫助透過關注點分離來推動 APIOps 方法。
將所有 Azure OpenAI 執行個體私人連結私人端點並置到閘道虛擬網路上的單一子網路。 將 NSG 規則應用於此子網，以僅允許閘道存取這些私人端點。 應禁止對 Azure OpenAI 執行個體的所有其他資料平面存取。
為了簡化閘道路由程式碼中的邏輯，請使用相同的模型部署名稱，以盡量減少 HTTP 路由之間的差異。 例如，模型名稱
gpt4-v1可用於所有負載平衡或溢出實例，無論是標準或布建。
避免在單一區域和訂閱中使用多個執行個體的閘道的原因
閘道本身不會提高針對此特定拓撲的不同用戶端的計費模型的能力。 在此拓撲中，客戶可以被授予對其私人 Azure OpenAI 執行個體的存取權限，這將支援工作負載團隊執行計費或顯示的能力。 此模型支援唯一的身分和網路邊界，因此不需要專門引入閘道來進行分段。
如果您在控制程式碼的區域中有一些用戶端，且用戶端可以輕鬆更新，那麼您必須建置到閘道中的邏輯可以直接新增到程式碼中。 主要當您不擁有用戶端程式碼或複雜度太大而用戶端無法處理時，請考慮使用閘道方法進行容錯移轉或負載平衡。
如果您使用閘道特別用來處理容量限制，請評估數據區容量功能是否足以應付您的工作負載。
單一區域中跨多個訂閱的多個 Azure OpenAI 執行個體
跨多個訂閱的單一區域中的多個 Azure OpenAI 執行個體的拓撲詳細資訊
- Azure OpenAI 模型部署：一個或多個
- Azure OpenAI 執行個體：多個
- 訂閱數：多個
- 地區：1個
跨多個訂閱的單一區域中的多個 Azure OpenAI 執行個體的拓樸使用案例
在單一區域中跨多個訂閱包含多個 Azure OpenAI 執行個體的拓樸支援以下使用案例：
您想要在標準部署中取得更多配額，而且您必須將模型使用限制為單一特定區域。
為單一區域中的多個執行個體和多個訂閱引入閘道
為單一區域和訂閱中的多個執行個體引入閘道中介紹的相同原因也適用於此拓撲。
除了這些原因之外，在此拓撲中新增閘道還支援集中式團隊為其組織提供「Azure OpenAI 即服務」模型。 因為標準部署中的配額是訂用帳戶系結，因此提供使用標準部署的 Azure OpenAI 服務的集中式小組必須跨多個訂用帳戶部署 Azure OpenAI 實例，才能取得所需的配額。 閘道邏輯仍然基本上相同。
有關單一區域中的多個執行個體和多個訂閱拓撲的提示
理想情況下，所有訂閱都應由同一 Microsoft Entra 租用戶支援，以支援 Azure RBAC 和 Azure Policy 的一致性。
將閘道部署在與 Azure OpenAI 執行個體相同的區域。
將閘道部署到獨立於 Azure OpenAI 執行個體的私人訂閱。 這有助於強制解決 Azure OpenAI 執行個體的一致性，並提供 Azure OpenAI 部署及其路由之間的邏輯職責分割。
當跨訂閱路由來自閘道的請求時，請確保私人端點可存取。 您可以使用透過集線器到各自分支中後端的私人端點的傳遞路由。 您可以透過跨訂閱使用私人連結連接，直接在閘道訂閱中公開 Azure OpenAI 服務的私人端點。 如果您的體系結構和組織支援此方法，則首選交叉訂閱私人連結連線。
避免在單一區域和多個訂閱中使用多個執行個體的閘道的原因
避免在單一區域和訂閱中使用多個執行個體的閘道的所有原因都適用於此拓撲。
跨多個區域的多個 Azure OpenAI 執行個體
跨多個區域的多個 Azure OpenAI 執行個體的拓撲詳細資訊
- Azure OpenAI 模式部署：多個
- Azure OpenAI 執行個體：多個
- 訂閱：一個或多個
- 地區：多個
跨多個區域的多個 Azure OpenAI 執行個體的拓樸使用案例
包含分佈在兩個或多個 Azure 區域的多個 Azure OpenAI 執行個體的拓樸支援下列使用案例：
啟用服務可用性的容錯移轉策略，例如使用跨區域對。
實現資料駐留和合規性設計。
啟用混合模型可用性。 某些地區有不同的型號，且該型號可用的配額也不同。
雖然從技術上講，Azure 區域並不不同，但當您在跨部署情況 (例如本地或其他雲端) 中公開 AI 模型時，此拓撲也適用。
為多個區域的多個執行個體引入閘道
對於必須在完全區域中斷中倖存的關鍵業務架構，全球統一閘道有助於消除用戶端程式碼中的容錯移轉邏輯。 此實作要求閘道不受區域中斷的影響。
使用 Azure API 管理 (單區域部署)
在此拓撲中，Azure API 管理專門用於閘道技術。 此處，API 管理部署到單一區域。 從該閘道執行個體，您可以跨區域執行主動-主動負載平衡。 網關中的原則會參考所有 Azure OpenAI 實例。 閘道需要透過跨區域虛擬網路對等互連或私人端點與跨區域的每個後端建立網路視線。 從該閘道到另一個區域中的 Azure OpenAI 執行個體的呼叫會產生更多的網路延遲和出口費用。
閘道必須遵守來自 Azure OpenAI 執行個體的限制和可用性訊號，並從池中刪除故障的後端，直到可以安全地讀取故障或受到限制的 Azure OpenAI 執行個體。 發生故障時，閘道應針對池中的另一個後端執行個體重試目前請求，然後再傳回閘道錯誤。 當沒有後端 Azure OpenAI 執行個體可用時，閘道的運作狀況檢查應發出運作狀況不正常的訊號。
注意
此閘道在您的架構中引入了全域單點區域故障，因為閘道執行個體上的任何服務中斷都會導致所有區域無法存取。 不要將此拓撲用於關鍵業務工作負載或基於用戶端的負載平衡就足夠的情況。
由於此拓撲引進了單一失敗點（閘道），因此此特定架構的公用程序相當有限-讓您免於區域性 Azure OpenAI 端點中斷。
警告
如果任一 Azure OpenAI 區域跨越地緣政治邊界，則此方法不能用於涉及資料主權合規性的場景。
主動-被動變體
此模型也可用於提供主動-被動方法來專門處理 Azure OpenAI 的區域故障。 在此模式下，流量通常會從閘道流向與 API 管理服務位於相同區域的 Azure OpenAI 執行個體。 Azure OpenAI 的這個執行個體將處理所有預期的流量，而不會發生區域故障。 視您慣用的計費模型而定，它可以布建或標準。 如果只是 Azure OpenAI 的區域失敗，閘道可以將流量重新導向至已部署在標準部署中 Azure OpenAI 的另一個區域。
使用 Azure API 管理 (多區域部署)
為了提高先前基於 Azure API 管理的架構的可靠性，API 管理支援將執行個體部署到多個 Azure 區域。 此部署選項透過單一 API 管理執行個體為您提供單一控制平面，但在您選擇的區域中提供複製閘道。 在此拓撲中，您可以將閘道元件部署到包含提供主動-主動閘道體系結構的 Azure OpenAI 執行個體的每個區域。
路由和請求處理邏輯等策略被複製到每個單獨的閘道。 所有策略邏輯都必須在策略中包含條件邏輯，以確保您呼叫與目前閘道位於相同區域中的 Azure OpenAI 執行個體。 有關更多資訊，請參閱將 API 呼叫路由到區域後端服務。 然後，閘道元件通常會透過私人端點僅需要其所在區域中的 Azure OpenAI 執行個體的網路視線。
注意
從流量處理的角度來看，此拓樸不存在全域故障點，但此體系結構部分有單點故障，因為 Azure API 管理控制平面僅位於單一區域。 評估控制平面限制是否可能違反您的業務或關鍵任務標準。
API 管理提供基於最低延遲的開箱即用的全球完全限定網域名稱 (FQDN) 路由。 使用此內建的、基於效能的功能進行主動-主動閘道部署。 此內建功能有助於提高效能並處理區域閘道中斷。 內建的全域路由器還支援災難復原測試，因為可以透過停用各個閘道來模擬區域。 確保用戶端遵守 FQDN 上的生存時間 (TTL)，並具有適當的重試邏輯來處理最近的 DNS 容錯移轉。
如果您需要在此架構中引入 Web 應用程式防火牆，您仍然可以使用內建的 FQDN 路由解決方案作為實現 Web 應用程式防火牆的全域路由器的後端來源。 全域路由器會將容錯移轉責任委託給 API 管理。 或者，您可以使用區域閘道 FQDN 作為後端池成員。 在後一種架構中，使用每個區域閘道上的內建 /status-0123456789abcdef 端點或另一個自訂執行狀況 API 端點來支援區域容錯移轉。 如果不確定，請從單源後端 FQDN 方法開始。
如果您可以將區域視為完全可用或完全不可用，則此架構效果最佳。 這意味著，如果 API 管理閘道或 Azure OpenAI 執行個體無法使用，您希望用戶端流量不再路由到該區域中的 API 管理閘道。 除非做出其他規定，否則如果在 Azure OpenAI 不可用時區域閘道仍然會接受流量，則必須將錯誤傳播到用戶端。 為了避免用戶端錯誤，請參閱主動-主動閘道加上主動-被動 Azure OpenAI 變體中的改進方法。
如果某個區域遇到 API 管理閘道中斷或被標記為運作狀況不佳，則其餘可用性區域域需要吸收來自其他區域 100% 的流量。 這表示您必須過度布建的 Azure OpenAI 實例來處理新的流量高載，或使用 主動-被動方法來故障轉移。 使用 Azure OpenAI 容量計算器進行容量規劃。
確保包含 Azure API 管理的資源群組與 API 管理執行個體本身位於相同位置，以減少相關區域中斷的影響範圍，進而影響您存取閘道資源提供者的能力。
警告
如果任一閘道區域跨越地緣政治邊界，則此方法不能用於涉及資料駐留合規性的場景。
主動-主動閘道加上主動-被動 Azure OpenAI 變體
上一節透過提供主動-主動閘道拓撲來解決閘道的可用性問題。 此拓撲將主動-主動閘道與經濟高效的主動-被動 Azure OpenAI 拓撲結合。 將主動-被動邏輯新增至閘道，以從布建的部署故障轉移至標準 Azure OpenAI 部署，可大幅提升工作負載的可靠性。 此模型仍然允許用戶端使用 API 管理內建 FQDN 路由解決方案進行基於效能的路由。
警告
如果任一區域跨越地緣政治邊界，則這種主動-主動加主動-被動方法不能用於涉及資料駐留合規性的場景。
使用自訂編碼閘道
如果您的個別網關路由規則太複雜，您的小組無法將合理視為 Azure API 管理原則，您必須部署和管理自己的解決方案。 此架構必須是閘道的多區域部署，每個區域都有一個高度可用的縮放單位。 您需要使用 Azure Front Door (Anycast) 或 Azure 流量管理員 (DNS) 來前置這些部署，通常是使用基於延遲的路由和適當的閘道可用性運作狀況檢查。
如果需要 Web 應用程式防火牆和公共 Internet 存取，請使用 Azure Front Door。 如果您不需要 Web 應用程式防火牆且 DNS TTL 就足夠了，請使用流量管理員。 當使用 Azure Front Door (或任何反向代理) 前置閘道執行個體時，請確保閘道無法被繞過。 當您使用 Azure Front Door 並在閘道實作中新增 X_AZURE_FDID HTTP 標頭驗證時，使閘道執行個體僅透過私人端點可用。
將自訂閘道中使用的按區域資源放置在按區域資源群組中。 這樣做可以減少相關區域中斷的影響範圍，從而影響您存取該區域閘道資源的資源提供者的能力。
您也可以考慮將閘道邏輯實作與 Azure API 管理搭配使用，以取得 API 管理的其他優點，例如 TLS、驗證、健康情況檢查或迴圈配置資源負載平衡。 這樣做可以將常見的 API 問題從閘道中的自訂程式碼中轉移出來，並讓您的閘道專門解決 Azure OpenAI 執行個體和模型部署路由問題。
為了滿足資料駐留合規性，請確保每個地緣政治邊界都有其獨立的此架構部署，且用戶端只能到達其授權端點。
避免在多個區域的多個執行個體使用閘道的原因
當需要資料駐留和合規性時，不要跨地緣政治區域實作統一閘道。 這樣做會違反資料駐留要求。 每個區域使用可單獨尋址的閘道，並遵循前面部分之一中的指導。
請勿只為了增加配額而實作統一閘道。 使用 Azure OpenAI 的全域 部署，利用 Azure 的全球基礎結構，以動態方式將要求路由傳送至具有每個要求最佳容量的數據中心。
如果用戶端不希望在區域之間進行容錯移轉，並且您能夠為用戶端提供要使用的特定閘道，則可以使用多個閘道 (每個區域一個)，並遵循前面部分之一中的指導。 不要將其他區域的可用性與包含您的閘道的區域作為單點故障聯繫起來。
如果您的模型和版本並非在閘道公開的所有區域都可用，請勿實作統一閘道。 用戶端需要路由到相同型號和相同型號版本。 對於多區域負載平衡和容錯移轉閘道，您需要選擇在所有涉及的區域中都可用的通用模型和模型版本。 有關更多資訊，請參閱型號可用性。 如果無法在模型和模型版本上實現標準化，則閘道的優勢將受到限制。
一般建議
無論您的工作負載需要哪種拓撲，在建立閘道解決方案時都需要考慮一些橫切建議。
有狀態互動
當用戶端使用 Azure OpenAI 的有狀態功能 (例如 Assistant API) 時，需要設定閘道以在互動期間將用戶端固定到特定後端。 可以透過將執行個體資料儲存在 cookie 中來完成此操作。 在這些案例中，請考慮將 API 回應如 429 傳回至已釘選的用戶端，而不是將它們重新導向至不同的 Azure OpenAI 實例。 這樣做允許用戶端明確地處理突然不可用的情況，而不是將其隱藏並路由到沒有歷史記錄的模型執行個體。
閘道健康檢查
無論拓樸如何，都需要考慮兩個執行狀況檢查角度。
如果您的閘道是圍繞循環或嚴格執行服務可用性容錯移轉而建置的，您需要一種方法來將 Azure OpenAI 執行個體 (或模型) 脫離可用性狀態。 Azure OpenAI 不會提供任何類型的運作狀況檢查端點來預先了解它是否可用於處理要求。 您可以傳送合成轉換，但這會消耗模型容量。 除非您有另一個用於Azure OpenAI 執行個體和模型可用性的可靠訊號源，否則您的閘道可能應該假定Azure OpenAI 執行個體已啟動，然後處理 429、500、503 HTTP 狀態代碼作為訊號，以便為該執行個體或模型的未來請求進行熔斷。 對於限制情況，請務必遵守 Retry-After Azure OpenAI API 回應中找到的 429 標頭中的資料，以取得熔斷邏輯中的回應代碼。 如果使用 Azure API 管理，請使用內建斷路器功能進行評估。
您的客戶或工作負載營運團隊可能希望在您的閘道上公開執行狀況檢查，以供自己的路由或自省目的。 如果您使用 API 管理，預設值 /status-0123456789abcdef 可能不夠詳細，因為它主要針對 API 管理閘道執行個體，而不是您的後端。 考慮新增私人的運作狀況檢查 API，該 API 可以向用戶端或可檢視性系統傳回有關閘道或閘道中特定路由的可用性的有意義的資料。
安全部署實務
您可以使用閘道實作來協調更新模型的藍綠部署。 Azure OpenAI 模型已更新為新模型版本和新模型，並且您可能會有新的微調模型。
在測試預生產中變更的影響後，評估生產用戶端是否應該「切換」到新模型版本或轉移流量。 前面描述的閘道模式允許後端同時部署這兩種模型。 同時部署模型使閘道能夠根據工作負載團隊的增量部署安全部署實務來重定向流量。
即使您不使用藍綠部署，也需要定義工作負載的 APIOps 方法，並將其充分自動化，以適應後端執行個體和模型部署的變更率。
足夠的實作
本文介紹的許多場景透過降低用戶端複雜性和實作可靠的自我保護技術，有助於提高工作負載的潛在服務等級目標 (SLO)。 其他人則透過將存取控制從 Azure OpenAI 移至特定模型來提高工作負載的安全性。 確保閘道的引入最終不會與這些目標背道而馳。 了解由於服務故障或閘道中人為造成的設定問題、複雜的路由邏輯而新增新的單點故障的風險，或向未經授權的用戶端暴露比預期更多的模型的風險。
資料主權
需要從工作負載的資料駐留合規性角度評估各種主動-主動和主動-被動方法。 如果涉及的區域仍在地緣政治邊界內，其中許多模式將適用於您的工作負載架構。 為了支援這種情況，您需要將地緣政治邊界視為孤立的圖章，並在該圖章內專門應用主動-主動或主動-被動處理。+
特別是，任何基於效能的路由都需要嚴格審查資料主權合規性。 在資料主權場景中，您無法為不同地理位置的客戶提供服務並保持合規性。 所有涉及資料駐留的閘道架構必須強制用戶端僅使用其地緣政治區域中的端點。 必須阻止用戶端使用其他閘道端點，且閘道本身不會透過發出跨地緣政治請求來違反用戶端的信任。 實現這種細分的最可靠方法是圍繞每個地緣政治區域完全獨立、高度可用的閘道來建立架構。
在考慮要透過 全域 或 數據區 Azure OpenAI 部署來利用增加的容量時，您必須瞭解這些部署如何影響數據落地。 待用數據會保留在全域和數據區域部署的指定 Azure 地理位置中。 該數據可能會傳輸和處理，以推斷任何 Azure OpenAI 位置進行全域部署，或在數據區部署Microsoft指定數據區內的任何 Azure OpenAI 位置中。
Azure OpenAI 授權
閘道需要對其連線的所有 Azure OpenAI 執行個體進行驗證。 除非您將閘道設計為進行直通身份驗證，否則閘道應使用託管身分作為其憑證。 因此，每個 Azure OpenAI 執行個體都需要為閘道的託管識別碼設定最低權限的 RBAC。 對於主動-主動和容錯移轉體系結構，請確保閘道的身份在所有涉及的 Azure OpenAI 執行個體中具有相同的權限。
Azure 原則
模型部署與 Azure OpenAI 實例之間的一致性在主動-主動和主動-被動情況下都很重要。 使用 Azure Policy 協助強制實作各種 Azure OpenAI 執行個體或模型部署之間的一致性。 如果 Azure OpenAI 的 內建原則 不足以確保它們之間的一致性，請考慮建立或使用社群建立的自訂策略。
閘道備援
雖然不特定於多個後端，但每個區域的閘道實作應始終以備援方式構建，並且在縮放單位內具有高可用性。 選擇具有可用性區域的區域，並確保您的閘道分佈在這些區域中。 部署閘道的多個執行個體，以便將單點故障限制為完全區域中斷，而不是閘道中單一計算執行個體的故障。 針對 Azure API 管理，跨兩個或多個區域部署兩個以上的單位。 對於自訂程式碼實作，請部署至少三個執行個體，並盡力跨可用性區域分佈。
閘道實施
Azure 不提供完整的周全解決方案或參考架構，可用來建置這類閘道，著重於跨多個後端路由傳送流量。 不過，Azure API 管理是慣用的，因為服務會使用內建功能提供 PaaS 型解決方案，例如後端集區、中斷線路原則，以及視需要自定義原則。 請參閱，Azure API 管理中產生的 AI 閘道功能概觀，以評估該服務中針對工作負載的多後端需求可用的功能。
無論您使用 API 管理還是建置自定義解決方案，如 簡介文章所述，您的工作負載小組都必須建置及操作此網關。 以下是涵蓋一些先前提及的使用案例的範例。 當您使用 API 管理或自訂程式碼建置自己的概念證明時，請考慮參考這些範例。
| 實作 | 範例 |
|---|---|
| Azure API 管理 |
使用 Azure API 管理實作 Azure OpenAI 的智慧負載平衡 - 此 GitHub 儲存庫包含範例策略程式碼和部署到訂閱中的說明。 使用 Azure API 管理調整 Azure OpenAI - 此 GitHub 存放庫包含布建和標準溢出的範例原則程式代碼和指示。 GenAI 閘道工具組包含範例 API 管理 原則，以及用於測試原則行為的負載測試設定。 |
| 自訂程式碼 |
使用 Azure 容器應用程式實現 Azure OpenAI 的智慧負載平衡 此 GitHub 儲存庫包含範例 C# 程式碼以及建置容器和部署到訂閱中的說明。 |
適用於 Azure 的 雲端採用架構 也包含實作 Azure API 管理 登陸區域的指引，適用於產生式 AI 案例，包括此多後端案例。 如果您的工作負載存在於應用程式登陸區域中，請務必參閱本指導方針以取得實作考慮和建議。
下一步
為您的工作負載實作閘道所帶來的好處超出了本文所述的戰術性多後端路由好處。 了解閘道可以解決的其他關鍵挑戰。