Přístup k Azure OpenAI a dalším velkým jazykovým modelům (LLM) prostřednictvím brány

Služba Azure OpenAI zveřejňuje rozhraní HTTP API, která umožňují aplikacím provádět vkládání nebo dokončování pomocí jazykových modelů OpenAI. Inteligentní aplikace volají tato rozhraní API HTTP přímo z klientů nebo orchestrátorů. Mezi příklady klientů patří kód uživatelského rozhraní chatu a vlastní kanály zpracování dat. Mezi příklady orchestrátorů patří LangChain, Sémantické jádro a Azure Machine Učení tok výzvy. Když se vaše úloha připojí k jedné nebo více instancím Azure OpenAI, musíte se rozhodnout, jestli se tito příjemci připojují přímo nebo přes bránu rozhraní API reverzního proxy serveru.

V této příručce se seznámíte s klíčovými výzvami v pěti pilířích rozhraní Azure Well-Architected Framework , se kterými se setkáte, pokud návrh úloh zahrnuje přímý přístup od vašich uživatelů k rozhraním API roviny dat Azure OpenAI. Pak se dozvíte, jak zavedení brány do vaší architektury může pomoct vyřešit tyto výzvy s přímým přístupem a zároveň zavést nové výzvy. Tento článek popisuje model architektury, ale ne způsob implementace brány.

Vzhledem k tomu, že bránu je možné použít k řešení konkrétních scénářů, které nemusí existovat v každé úloze, podívejte se na pokyny ke konkrétním scénářům, které se podrobněji podíváme na konkrétní případ použití brány.

Klíčové výzvy

Bez brány rozhraní API nebo schopnosti přidat logiku do rozhraní API HTTP Azure OpenAI musí klient zpracovat logiku klienta rozhraní API, která zahrnuje mechanismy opakování nebo jističe. Tato situace může být náročná ve scénářích, ve kterých přímo neřídíte kód klienta nebo když je kód omezen na konkrétní využití sady SDK. Několik klientů nebo více instancí Azure OpenAI a nasazení představuje další výzvy, jako je koordinace bezpečných nasazení a pozorovatelnosti.

Tato část obsahuje příklady konkrétních klíčových výzev architektury, se kterými se můžete setkat, pokud vaše architektura podporuje pouze přímý přístup k Azure OpenAI od uživatelů. Výzvy jsou uspořádané pomocí pilířů architektury Azure Well-Architected Framework.

Problémy se spolehlivostí

Spolehlivost úlohy závisí na několika faktorech, včetně její kapacity pro samozáchozí a samoobslužné obnovení, které se často implementují prostřednictvím mechanismů replikace a převzetí služeb při selhání. Bez brány se všechny obavy o spolehlivost musí řešit výhradně pomocí logiky klienta a funkcí služby Azure OpenAI. Spolehlivost úloh je ohrožena, pokud v některé z těchto dvou ploch není k dispozici dostatek kontroly spolehlivosti.

• Redundance: Převzetí služeb při selhání mezi několika instancemi Azure OpenAI na základě dostupnosti služeb je klientská odpovědnost, kterou potřebujete řídit prostřednictvím konfigurace a vlastní logiky.

• Horizontální navýšení kapacity pro zpracování špiček: Převzetí služeb při selhání instancí Azure OpenAI s kapacitou při omezování je další zodpovědností klienta, kterou potřebujete řídit prostřednictvím konfigurace a vlastní logiky. Aktualizace více konfigurací klientů pro nové instance Azure OpenAI představuje větší riziko a má obavy o aktuálnost. Totéž platí pro aktualizaci kódu klienta tak, aby implementovaly změny logiky, jako je například směrování požadavků s nízkou prioritou do fronty během období vysoké poptávky.

• Vyrovnávání zatížení nebo omezování: Rozhraní API Azure OpenAI omezují požadavky vrácením kódu odpovědi na chybu HTTP 429 do požadavků, které v modelu s průběžnými platbami překračují token za minutu (TPM) nebo žádosti za minutu (RPM). Rozhraní API Azure OpenAI také omezují požadavky, které překračují kapacitu zřízených jednotek propustnosti (PTU) pro předem zřízený fakturační model. Zpracování vhodné zpětného vypnutí a logiky opakování je ponecháno výhradně na implementacích klientů.

Výzvy zabezpečení

Kontrolní mechanismy zabezpečení musí pomoct chránit důvěrnost, integritu a dostupnost úloh. Bez brány musí být všechny aspekty zabezpečení řešeny výhradně v logice klienta a funkcích služby Azure OpenAI. Požadavky na úlohy můžou vyžadovat více než to, co je k dispozici pro segmentaci klientů, řízení klienta nebo funkce zabezpečení služeb pro přímou komunikaci.

• Správa identit – obor ověřování: Rozhraní API roviny dat vystavená službou Azure OpenAI je možné zabezpečit jedním ze dvou způsobů: klíč rozhraní API nebo řízení přístupu na základě role (RBAC). V obou případech se ověřování děje na úrovni instance Azure OpenAI, nikoli na úrovni individuálního nasazení, což představuje složitost pro poskytování nejméně privilegovaného přístupu a segmentace identit pro konkrétní modely nasazení.

• Správa identit – zprostředkovatelé identit: Klienti, kteří nemůžou používat identity umístěné v tenantovi Microsoft Entra, který zálohuje instanci Azure OpenAI, musí sdílet jeden klíč rozhraní API s úplným přístupem. Klíče rozhraní API mají omezení užitečnosti zabezpečení a jsou problematické, pokud je zapojeno více klientů a všechny sdílejí stejnou identitu.

• Zabezpečení sítě: V závislosti na umístění klienta vzhledem k vašim instancím Azure OpenAI může být nutný veřejný přístup k internetu k jazykovým modelům.

• Suverenita dat: Suverenita dat v kontextu Azure OpenAI odkazuje na právní a zákonné požadavky související s ukládáním a zpracováním dat v rámci geografické hranice konkrétní země nebo oblasti. Vaše úloha musí zajistit regionální spřažení, aby klienti mohli dodržovat zákony o rezidenci dat a suverenitě. Tento proces zahrnuje několik nasazení Azure OpenAI.

Výzvy optimalizace nákladů

Úlohy jsou přínosné v případech, kdy architektury minimalizují plýtvání a maximalizují nástroj. Modelování a monitorování silných nákladů je důležitým požadavkem pro každou úlohu. Bez brány je možné využití PTU nebo sledování nákladů na klienta autoritativně dosáhnout výhradně z agregace telemetrie využití instancí Azure OpenAI.

• Sledování nákladů: Možnost poskytnout finanční perspektivu využití Azure OpenAI je omezená na data agregovaná z telemetrie využití instancí Azure OpenAI. Pokud je potřeba provést vrácení poplatků nebo zobrazení zpět, musíte přiřazovat telemetrii využití s různými klienty v různých odděleních nebo dokonce zákazníky pro scénáře s více tenanty.

• Využití zřízené propustnosti: Vaše úloha se chce vyhnout plýtvání tím, že plně využívá zřízenou propustnost, za kterou jste zaplatili. To znamená, že klienti musí být důvěryhodní a koordinovaní, aby bylo možné použít nasazení modelu založeného na PTU, než přetéknou do všech nasazení modelu založených na spotřebě.

Výzvy efektivity provozu

Bez brány, pozorovatelnosti, řízení změn a vývojových procesů jsou omezené na to, co poskytuje přímá komunikace mezi klientem.

• Řízení kvót: Klienti obdrží kódy odpovědí 429 přímo z Azure OpenAI, když jsou omezena rozhraní API HTTP. Operátoři úloh zodpovídají za zajištění toho, aby byla dostatečná kvóta k dispozici pro legitimní využití a že se klienti nevyužívají nadměrně. Když se vaše úloha skládá z několika nasazení modelu, může být obtížné vizualizovat využití kvót a dostupnost kvót.

• Monitorování a pozorovatelnost: Výchozí metriky Azure OpenAI jsou dostupné prostřednictvím služby Azure Monitor. Je ale latence s dostupností dat a neposkytuje monitorování v reálném čase.

• Sejf postupy nasazení: Váš proces LLMOps vyžaduje koordinaci mezi klienty a modely nasazenými v Azure OpenAI. U pokročilých přístupů k nasazení, jako je modrá zelená nebo kanárka, je potřeba logiku zpracovat na straně klienta.

Problémy s efektivitou výkonu

Bez brány nese vaše úloha odpovědnost za to, aby se klienti chovali individuálně dobře a chovali se spravedlivě s ostatními klienty s omezenou kapacitou.

• Optimalizace výkonu – prioritní provoz: Stanovení priorit požadavků klientů tak, aby klienti s vysokou prioritou měli přednostní přístup k klientům s nízkou prioritou, museli by vyžadovat rozsáhlou a pravděpodobně nepřiměřenou koordinaci mezi klienty. Některé úlohy můžou těžit z toho, že se požadavky s nízkou prioritou zařadí do fronty, když je využití modelu nízké.

• Optimalizace výkonu – dodržování předpisů klientů: Ke sdílení kapacity je potřeba, aby se klienti dobře chovali. Příkladem je to, že klienti zajistí, že max_tokens jsou a best_of jsou nastaveny na schválené hodnoty. Bez brány musíte klientům důvěřovat, aby jednali v nejlepším zájmu zachování kapacity instance Azure OpenAI.

• Minimalizace latence: I když latence sítě je obvykle malou součástí celkového toku žádostí o výzvu a dokončení, může být užitečné zajistit směrování klientů do koncového bodu sítě a modelu blízko k nim. Bez brány by klienti museli sami vybrat, které koncové body nasazení modelu se mají použít a jaké přihlašovací údaje jsou nezbytné pro konkrétní rozhraní API roviny dat Azure OpenAI.

Řešení

Obrázek 1: Koncepční architektura přístupu k Azure OpenAI prostřednictvím brány

Pokud chcete vyřešit řadu problémů uvedených v klíčových výzvách, můžete vložit bránu reverzního proxy serveru, která oddělí inteligentní aplikaci od Azure OpenAI. Toto snižování zátěže brány umožňuje posunout odpovědnost, složitost a pozorovatelnost od klientů a poskytuje příležitost rozšířit Azure OpenAI tím, že poskytuje další možnosti, které nejsou integrované. Zde je několik příkladů:

• Je možné implementovat federované ověřování.

• Schopnost řídit tlak na modely prostřednictvím omezování rychlosti.

• Křížové a křížové monitorování.

• Schopnost zavést agregaci brány a pokročilé směrování do více služeb, jako je směrování zpráv s nízkou prioritou do fronty pro vyrovnávání zatížení na základě fronty nebo výpočty pro provádění úloh.

• Vyrovnávání zatížení, které používá monitorování koncových bodů stavu ke směrování pouze do koncových bodů stavu, a to přerušením okruhu při nedostupných nebo přetížených nasazeních modelu.

Některé konkrétní scénáře mají k dispozici další pokyny, které přímo řeší bránu rozhraní API a instance Azure OpenAI. Tyto scénáře jsou uvedené v části Další kroky .

Důležité informace

Když do architektury zavedete novou komponentu, musíte vyhodnotit nově zavedené kompromisy. Když mezi klienty a rovinu dat Azure OpenAI vložíte bránu rozhraní API, která řeší všechny klíčové výzvy, představíte do své architektury nové aspekty. Pečlivě vyhodnoťte, jestli dopad úlohy na tyto aspekty architektury zdůvodňuje přidanou hodnotu nebo nástroj brány.

Spolehlivost

Spolehlivost zajišťuje, že vaše aplikace splňuje závazky, které jste udělali pro vaše zákazníky. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro spolehlivost.

• Řešení brány může zavést jediný bod selhání. Toto selhání může mít původ ve službě dostupnosti platformy brány, přerušení kvůli nasazení kódu nebo konfigurace nebo dokonce chybně nakonfigurovaným kritickým koncovým bodům rozhraní API ve vaší bráně. Ujistěte se, že navrhujete implementaci tak, aby splňovala požadavky vaší úlohy na dostupnost. Zvažte možnosti odolnosti a odolnosti proti chybám v implementaci zahrnutím brány do analýzy režimu selhání úlohy.

• Pokud vaše architektura vyžaduje instance Azure OpenAI ve více oblastech, může vaše řešení vyžadovat možnosti globálního směrování. Tato situace může dále komplikovat topologii prostřednictvím správy extra kvalifikovaných názvů domén, certifikátů TLS a dalších globálních komponent směrování.

Zabezpečení

Při zvažování toho, jak brána rozhraní API využívá vaši architekturu, použijte kontrolní seznam pro kontrolu návrhu pro zabezpečení k vyhodnocení návrhu. Potřebujete řešit aspekty zabezpečení, například následující:

• Plocha úlohy se zvyšuje přidáním brány. Tato oblast přináší další aspekty správy identit a přístupu (IAM) prostředků Azure, zvýšení úsilí o posílení zabezpečení a další.

• Brána může fungovat jako přechod hranice sítě mezi klientským síťovým prostorem a privátním síťovým prostorem Azure OpenAI. I když brána zpřístupňuje dříve internetový koncový bod Azure OpenAI privátní prostřednictvím použití služby Azure Private Link, stane se teď novým vstupním bodem a musí být odpovídajícím způsobem zabezpečený.

• Brána je v jedinečné pozici pro zobrazení nezpracovaných dat požadavků a formulovaných odpovědí z jazykového modelu, která by mohla zahrnovat důvěrná data z některého zdroje. Dodržování předpisů a regulační rozsah dat se teď rozšiřuje na tuto další komponentu.

• Brána může rozšířit rozsah autorizace klienta a ověřování nad rámec ověřování pomocí rozhraní Microsoft Entra ID a klíče rozhraní API a potenciálně napříč několika zprostředkovateli identity (IdP).

• Suverenita dat musí být při implementaci ve více oblastech zahrnuta do implementace. Ujistěte se, že výpočetní logika a logika směrování brány dodržuje požadavky na suverenitu, které jsou nastavené na vaši úlohu.

Optimalizace nákladů

Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro optimalizaci nákladů.

Všechny implementované brány rozhraní API mají náklady na běh, které je potřeba rozpočtovat a počítat. Tyto náklady se obvykle zvyšují díky přidaným funkcím, které řeší spolehlivost, zabezpečení a výkon samotné brány spolu s provozními náklady zavedenými s přidanou správou APIOps. Tyto přidané náklady je potřeba měřit s novou hodnotou doručenou ze systému pomocí brány. Chcete dosáhnout bodu, kdy nové funkce zavedené pomocí brány převáží náklady na implementaci a údržbu brány. V závislosti na vztahu vaší úlohy k jejím uživatelům možná budete moct účtovat využití zpět.

Efektivita provozu

Při zvažování výhod brány rozhraní API pro vaši architekturu použijte kontrolní seznam pro kontrolu návrhu pro efektivitu provozu k vyhodnocení návrhu. Potřebujete řešit aspekty efektivity provozu, například tyto:

• Samotná brána musí být monitorována monitorovacím řešením vaší úlohy a potenciálně klienty. To znamená, že výpočetní prostředky a operace brány musí být zahrnuty do modelování stavu úlohy.

• Vaše postupy bezpečného nasazení teď musí řešit nasazení infrastruktury brány rozhraní API a kódu nebo konfigurace směrování brány. Řešení automatizace infrastruktury a infrastruktury jako kódu (IaC) musí zvážit, jak bránu považovat za dlouhodobý prostředek v úloze.

• Pokud chcete pokrýt rozhraní API vystavená v bráně, musíte vytvořit nebo rozšířit přístup APIOps.

Efektivita výkonu

Při zvažování toho, jak brána rozhraní API využívá vaši architekturu, použijte kontrolní seznam pro kontrolu výkonu a vyhodnoťte svůj návrh pomocí kontrolního seznamu pro kontrolu výkonu . Je potřeba řešit aspekty efektivity výkonu, například tyto:

• Služba brány může zavádět kritické body propustnosti. Ujistěte se, že brána má odpovídající výkon pro zvládnutí úplného souběžného zatížení a může se snadno škálovat v souladu s vašimi očekáváními růstu. Zajištění elasticity v řešení, aby brána mohl snížit nabídku nebo snížit kapacitu, když je poptávka nízká, například s využitím obchodního dne.

• Služba brány musí provádět každou žádost a zavádí přidanou latenci pro volání rozhraní API. Logiku směrování byste měli optimalizovat, aby požadavky fungovaly dobře.

• Ve většině případů by brána měla být geograficky blízko uživatelů i instancí Azure OpenAI, aby se snížila latence. Zatímco latence sítě je obvykle malé procento času při celkových voláních rozhraní API do jazykových modelů, může to být konkurenční faktor pro vaši úlohu.

• Vyhodnoťte dopad brány na funkce Azure OpenAI, jako jsou odpovědi na streamování nebo připnutí instance pro stavové interakce, jako je rozhraní API asistentů.

Možnosti implementace

Azure nenabízí řešení na klíč navržené speciálně pro proxy rozhraní HTTP API Azure OpenAI ani jiná rozhraní API pro odvozování vlastních jazykových modelů. Váš tým úloh má ale stále několik možností, jak implementovat, například bránu v Azure.

Použití Azure API Managementu

Azure API Management je služba spravovaná platformou, která je navržená tak, aby přesměrovávala požadavky na průřezy pro rozhraní API založená na protokolu HTTP. Je řízená konfigurací a podporuje přizpůsobení prostřednictvím systému zásad zpracování příchozích a odchozích požadavků. Podporuje vysoce dostupné, zónově redundantní a dokonce i repliky ve více oblastech pomocí jedné řídicí roviny.

Většina logiky směrování brány a zpracování požadavků se musí implementovat v systému zásad služby API Management. Můžete kombinovat předdefinované zásady, jako je omezení využití tokenu rozhraní API Azure OpenAI nebo generování metrik pro spotřebu tokenů Azure OpenAI a vlastních zásad. Některé příklady vlastních zásad a scénářů najdete v komunitním úložišti sady nástrojů brány API Management na GitHubu.

Při návrhu řešení, které zahrnuje Azure API Management, použijte příručku pro dobře navrženou službu API Management .

Použití služby Azure API Management pro implementaci brány je obecně upřednostňovaným přístupem k vytváření a provozování brány Azure OpenAI. Preferuje se, protože služba je nabídka paaS (platforma jako služba) s bohatými integrovanými funkcemi, vysokou dostupností a možnostmi sítě. Má také robustní přístupy APIOps ke správě rozhraní API pro dokončování.

Použití vlastního kódu

Vlastní přístup ke kódu vyžaduje, aby tým pro vývoj softwaru vytvořil vlastní kódované řešení a nasadil ho do aplikační platformy Azure podle svého výběru. Vytvoření samoobslužného řešení pro zpracování logiky brány může být vhodné pro týmy úloh, které mají zkušenosti se správou síťového a směrovacího kódu.

Úloha může obvykle používat výpočetní prostředky, které znáte, například hostování kódu brány ve službě Aplikace Azure Service, Azure Container Apps nebo Azure Kubernetes Service.

Nasazení vlastního kódu je také možné předcházet službě API Management, když se služba API Management používá výhradně pro základní funkce brány rozhraní HTTP API mezi vašimi klienty a vlastním kódem. Tímto způsobem vaše vlastní rozhraní kódu výhradně s rozhraními API HTTP Azure OpenAI na základě nezbytné obchodní logiky.

Použití technologie brány jiné společnosti než Microsoft, což je produkt nebo služba, která není nativně poskytována v Azure, se dá považovat za součást tohoto přístupu.

Příklad architektury

Obrázek 2: Příklad architektury přístupu k Azure OpenAI prostřednictvím brány založené na službě Azure API Management

Další kroky

Seznamte se s konkrétním scénářem, ve kterém se k řešení požadavků na úlohy používá nasazení brány mezi inteligentní aplikací a nasazeními Azure OpenAI:

• Vyrovnávání zatížení nebo převzetí služeb při selhání mezi několika back-endovými instancemi

Naučte se implementovat protokolování a monitorování pro modely Azure OpenAI.

Související prostředky

• Služba Azure OpenAI
• Brána rozhraní API ve službě Azure API Management
• Akcelerátor cílové zóny služby API Management pokrývající scénáře generování AI
• Sada nástrojů brány SLUŽBY API Management