Usare un gateway davanti a più distribuzioni o istanze openAI di Azure

Le architetture dei carichi di lavoro che coinvolgono il servizio OpenAI di Azure possono essere semplici come una o più applicazioni client che usano direttamente una singola distribuzione del modello OpenAI di Azure, ma non tutti i carichi di lavoro possono essere progettati con tale semplicità. Gli scenari più complessi includono topologie con più client, più distribuzioni OpenAI di Azure o più istanze di Azure OpenAI. In queste situazioni, l'introduzione di un gateway davanti ad Azure OpenAI può essere utile per la progettazione del carico di lavoro.

Più istanze di Azure OpenAI o distribuzioni di modelli risolve requisiti specifici in un'architettura del carico di lavoro. Possono essere classificati in quattro topologie chiave.

• Più distribuzioni di modelli in una singola istanza di Azure OpenAI
• Più istanze di Azure OpenAI in una singola area e in una singola sottoscrizione
• Più istanze di Azure OpenAI in una singola area tra più sottoscrizioni
• Più istanze openAI di Azure in più aree

Queste topologie autonomamente non richiedono l'uso di un gateway. La scelta di un gateway dipende dal fatto che il carico di lavoro trae vantaggio dall'inclusione nell'architettura. Questo articolo descrive le sfide affrontate da ognuna delle quattro topologie e i vantaggi e i costi di inclusione di un gateway in ogni topologia.

Più distribuzioni di modelli in una singola istanza di Azure OpenAI

Dettagli della topologia per più distribuzioni di modelli

• Distribuzioni di modelli OpenAI di Azure: più
• Istanze di Azure OpenAI: una
• Sottoscrizioni: una
• Aree: una

Casi d'uso della topologia per più distribuzioni di modelli

Una topologia che include una singola istanza di Azure OpenAI ma contiene più di un modello distribuito contemporaneamente supporta i casi d'uso seguenti:

• Esporre diverse funzionalità del modello, ad esempio gpt-35-turbo, gpt-4e modelli personalizzati ottimizzati.

• Esporre versioni del modello diverse, ad esempio 0613, 1106e modelli personalizzati ottimizzati per supportare l'evoluzione del carico di lavoro o le distribuzioni blu-verde.

• Esporre quote diverse assegnate (30.000 token al minuto (TPM), 60.000 TPM, per supportare la limitazione del consumo tra più client.

Introdurre un gateway per più distribuzioni di modelli

L'introduzione di un gateway in questa topologia è destinata principalmente all'astrazione dei client dalla selezione automatica di un'istanza del modello specifica tra le distribuzioni disponibili nell'istanza. Un gateway consente al controllo lato server di indirizzare una richiesta client a un modello specifico senza dover ridistribuire il codice client o modificare la configurazione client.

Un gateway è particolarmente utile quando non si controlla il codice client. È utile anche quando si distribuisce la configurazione client è più complesso o rischioso rispetto alla distribuzione delle modifiche in una configurazione di routing del gateway. È possibile modificare il modello a cui punta un client in base a una strategia di implementazione blu-verde delle versioni del modello, ad esempio l'implementazione di un nuovo modello ottimizzato o il passaggio dalla versione X alla X+1 dello stesso modello.

Il gateway può anche essere usato come singolo punto api di ingresso che consente al gateway di identificare il client. Può quindi determinare quale distribuzione del modello viene usata per gestire il prompt in base all'identità del client o ad altre informazioni nella richiesta HTTP. Ad esempio, in una soluzione multi-tenant, i tenant potrebbero essere limitati a velocità effettiva specifica e l'implementazione dell'architettura è una distribuzione del modello per tenant con quote specifiche. In questo caso, il routing al modello del tenant sarà responsabilità del gateway in base alle informazioni nella richiesta HTTP.

L'uso di un gateway in questa topologia consente il rilevamento dell'utilizzo basato su client. A meno che i client non usino entità servizio Microsoft Entra distinte, i log di accesso per Azure OpenAI non sarebbero in grado di distinguere più client. La presenza di un gateway davanti alla distribuzione offre al carico di lavoro l'opportunità di tenere traccia dell'utilizzo per client in varie distribuzioni di modelli disponibili per supportare il chargeback o i modelli di showback.

Suggerimenti per la topologia di più distribuzioni di modelli

• Anche se il gateway è in grado di modificare completamente il modello usato, ad esempio gpt-35-turbo in gpt-4, tale modifica potrebbe essere considerata una modifica che causa un'interruzione nel client. Non consentire alle nuove funzionalità funzionali del gateway di distrarre dall'esecuzione sempre di procedure di distribuzione sicure per questo carico di lavoro.

• Questa topologia è in genere abbastanza semplice da implementare tramite i criteri di Azure Gestione API anziché una soluzione di codice personalizzata.

• Per supportare l'uso di SDK nativi con le specifiche delle API OpenAI di Azure pubblicate, mantenere la compatibilità delle API con l'API OpenAI di Azure. Questa situazione è un problema più importante quando il team non crea tutto il codice dei client del carico di lavoro. Quando si decide di progettare l'API HTTP per il gateway, prendere in considerazione i vantaggi della gestione della compatibilità dell'API HTTP OpenAI di Azure.

• Sebbene questa topologia supporti tecnicamente le credenziali client pass-through (token di accesso o chiave API) per l'istanza di Azure OpenAI, è consigliabile implementare la terminazione delle credenziali e ristabilire la necessità di implementare la terminazione delle credenziali. In questo modo il client è autorizzato nel gateway e quindi il gateway viene autorizzato tramite il controllo degli accessi in base al ruolo di Azure all'istanza di Azure OpenAI.

• Se il gateway è progettato per usare le credenziali pass-through, assicurarsi che i client non possano ignorare il gateway o le restrizioni del modello in base al client.

• Distribuire il gateway nella stessa area dell'istanza di Azure OpenAI.

• Distribuire il gateway in un gruppo di risorse dedicato nella sottoscrizione separata dall'istanza di Azure OpenAI. L'isolamento della sottoscrizione dai back-end può aiutare a favorire un approccio APIOps attraverso separazioni di preoccupazione.

• Distribuire il gateway in una rete virtuale che contiene una subnet per l'istanza di Azure OpenAI collegamento privato di Azure endpoint privato. Applicare regole del gruppo di sicurezza di rete (NSG) a tale subnet per consentire solo l'accesso del gateway a tale endpoint privato. È consigliabile non consentire l'accesso a tutti gli altri piani dati alle istanze di Azure OpenAI.

Motivi per evitare un gateway per più distribuzioni di modelli

Se il controllo della configurazione dei client è semplice o più semplice rispetto al controllo del routing a livello di gateway, l'aggiunta di affidabilità, sicurezza, costi, manutenzione e impatto sulle prestazioni del gateway potrebbe non essere utile per il componente architetturale aggiunto.

Inoltre, alcuni scenari di carico di lavoro possono trarre vantaggio dalla migrazione da un approccio di distribuzione a più modelli a un approccio di distribuzione di istanze OpenAI di Azure multiple. Si consideri, ad esempio, più istanze di Azure OpenAI se si dispone di più client che devono usare chiavi di controllo degli accessi in base al ruolo o chiavi di accesso diverse per accedere al modello. L'uso di più distribuzioni in una singola istanza di Azure OpenAI e la gestione della segmentazione di identità logica a livello di gateway è possibile, ma potrebbe essere eccessivo quando è disponibile un approccio di segmentazione del controllo degli accessi in base al ruolo fisico usando istanze OpenAI di Azure distinte.

Più istanze di Azure OpenAI in una singola area e in una singola sottoscrizione

Dettagli della topologia per più istanze in una singola area e in una singola sottoscrizione

• Distribuzioni di modelli OpenAI di Azure: una o più
• Istanze di Azure OpenAI: più istanze
• Sottoscrizioni: una
• Aree: una

La topologia utilizza i casi per più istanze in una singola area e in una singola sottoscrizione

Una topologia che include più istanze di Azure OpenAI in una singola area e una singola sottoscrizione supporta i casi d'uso seguenti:

• Abilita i limiti di segmentazione della sicurezza, ad esempio chiave o controllo degli accessi in base al ruolo per client

• Abilita un modello di chargeback semplice per client diversi

• Abilita una strategia di failover per la disponibilità di Azure OpenAI, ad esempio un'interruzione della piattaforma che influisce su un'istanza specifica, una configurazione errata della rete o una distribuzione eliminata accidentalmente

• Abilita una strategia di failover per la disponibilità della quota OpenAI di Azure, ad esempio l'associazione di un'istanza basata su PTU e un'istanza basata sul consumo per lo spillover

Introdurre un gateway per più istanze in una singola area e sottoscrizione

Un modello potrebbe non essere accessibile a un client per diversi motivi. Questi motivi includono interruzioni del servizio OpenAI di Azure, richieste di limitazione di Azure OpenAI o problemi correlati a operazioni del carico di lavoro come la configurazione errata della rete o un'eliminazione accidentale di una distribuzione del modello. Per risolvere questi problemi, è necessario implementare la logica di ripetizione dei tentativi e di interruzione del circuito.

Questa logica può essere implementata nei client o sul lato server in un gateway. L'implementazione della logica in un gateway astrae la logica dai client, con conseguente assenza di codice ripetuto e un'unica posizione per testare la logica. Indipendentemente dal fatto che il codice client sia proprietario o meno, questo passaggio può aumentare l'affidabilità del carico di lavoro.

L'uso di un gateway con più istanze di Azure OpenAI in una singola area e sottoscrizione consente di gestire tutti i back-end come distribuzioni attive-attive e non solo di usarle in failover attivi-passivi. È possibile distribuire lo stesso modello basato su PTU in più istanze di Azure OpenAI e usare il gateway per bilanciare il carico tra di essi.

Un'opzione del team del carico di lavoro è disponibile quando si effettua il provisioning di Azure OpenAI è decidere se il modello di fatturazione e velocità effettiva è basato su PTU o basato sul consumo. Una strategia di ottimizzazione dei costi per evitare sprechi tramite PTU inutilizzato consiste nel effettuare leggermente il provisioning dell'istanza PTU e distribuire anche un'istanza basata sul consumo insieme a essa. L'obiettivo di questa topologia consiste nel fare in modo che i client utilizzano prima tutte le PTU disponibili e quindi "burst" nella distribuzione basata sul consumo per le eccedenze. Questa forma di failover pianificato trae vantaggio dallo stesso motivo indicato nel paragrafo di apertura di questa sezione: mantenere questa complessità fuori dal codice client.

Quando un gateway è coinvolto, si trova in una posizione univoca per acquisire i dettagli su tutte le distribuzioni di modelli con cui interagiscono i client. Anche se ogni istanza di Azure OpenAI può acquisire i propri dati di telemetria, questa operazione all'interno del gateway consente al team del carico di lavoro di pubblicare i dati di telemetria e le risposte agli errori in tutti i modelli usati in un singolo archivio, rendendo più semplice l'invio di dashboard e avvisi unificati.

Suggerimenti per più istanze in una singola area e topologia di sottoscrizione

• Assicurarsi che il gateway stia usando le Retry-After informazioni disponibili nella risposta HTTP di Azure OpenAI quando si supportano gli scenari di failover nel gateway. Usare queste informazioni autorevoli per controllare l'implementazione dell'interruttore. Non raggiungere continuamente un endpoint che restituisce un oggetto 429 Too Many Requests. Interrompere invece il circuito per l'istanza del modello.

• Il tentativo di stimare gli eventi di limitazione prima che si verifichino monitorando l'utilizzo del modello tramite le richieste precedenti è possibile nel gateway, ma viene sottoposto a casi limite. Nella maggior parte dei casi, è consigliabile non tentare di prevedere, ma usare i codici di risposta HTTP per prendere decisioni future sul routing.

• Quando si esegue il round robining o il failover in un endpoint diverso, inclusa la distribuzione di PTU in consumo, assicurarsi sempre che tali endpoint usino lo stesso modello alla stessa versione. Ad esempio, non eseguire il failover da gpt-4 a gpt-35-turbo o dalla versione X alla versione X+1 o bilanciare il carico tra di essi. Questa modifica della versione può causare un comportamento imprevisto nei client.

• Il bilanciamento del carico e la logica di failover sono implementabili all'interno dei criteri di Azure Gestione API. Potrebbe essere possibile fornire un approccio più sofisticato usando una soluzione gateway basata su codice, ma Gestione API è sufficiente per questo caso d'uso.

• Distribuire il gateway nella stessa area dell'istanza di Azure OpenAI.

• Distribuire il gateway in un gruppo di risorse dedicato nella sottoscrizione separata dale 'istanze di Azure OpenAI. L'isolamento del gateway dai back-end può aiutare a favorire un approccio APIOps attraverso separazioni di preoccupazione.

• Raggruppare tutte le istanze di Azure OpenAI collegamento privato endpoint privati in una singola subnet nella rete virtuale del gateway. Applicare regole del gruppo di sicurezza di rete a tale subnet per consentire solo l'accesso del gateway a tali endpoint privati. È consigliabile non consentire l'accesso a tutti gli altri piani dati alle istanze di Azure OpenAI.

• Per semplificare la logica nel codice di routing del gateway, usare lo stesso nome di distribuzione del modello per ridurre al minimo la differenza tra le route HTTP. Ad esempio, il nome gpt4-v1 del modello può essere usato in tutte le istanze con carico bilanciato o di spillover, indipendentemente dal fatto che sia basato sul consumo o su PTU.

Motivi per evitare un gateway per più istanze in una singola area e sottoscrizione

Un gateway stesso non migliora la possibilità di eseguire il chargeback dei modelli su client diversi per questa topologia specifica. In questa topologia è possibile concedere ai client l'accesso alle proprie istanze OpenAI di Azure dedicate, che supportano la capacità del team del carico di lavoro di eseguire chargeback o showback. Questo modello supporta l'identità univoca e i perimetri di rete, quindi non è necessario introdurre un gateway specificamente per la segmentazione.

Se sono presenti alcuni client nell'area in cui si controlla il codice e i client sono facilmente aggiornabili, la logica che si deve compilare nel gateway potrebbe essere aggiunta direttamente nel codice. Prendere in considerazione l'uso dell'approccio gateway per il failover o il bilanciamento del carico principalmente quando non si è proprietari del codice client o la complessità è eccessiva per i client da gestire.

Più istanze di Azure OpenAI in una singola area tra più sottoscrizioni

Dettagli della topologia per più istanze di Azure OpenAI in una singola area in più sottoscrizioni

• Distribuzioni di modelli OpenAI di Azure: una o più
• Istanze di Azure OpenAI: più istanze
• Sottoscrizioni: multiple
• Aree: una

La topologia usa i casi per più istanze di Azure OpenAI in una singola area in più sottoscrizioni

Una topologia che include più istanze di Azure OpenAI in una singola area tramite più sottoscrizioni supporta i casi d'uso seguenti:

• Include tutti i casi d'uso elencati per più istanze di Azure OpenAI in una singola area e una singola sottoscrizione.

• Consente di ottenere quote più basate sul consumo, poiché il limite della sottoscrizione è un fattore disponibile per il modello di consumo. È possibile usare questa quota aggiuntiva per supportare un consumo simultaneo elevato.

Introdurre un gateway per più istanze in una singola area e sottoscrizioni multiple

Gli stessi motivi illustrati in Introdurre un gateway per più istanze in una singola area e una sottoscrizione si applicano a questa topologia.

Oltre a questi motivi, l'aggiunta di un gateway in questa topologia supporta anche un team centralizzato che fornisce un modello "Azure OpenAI as a Service" per l'organizzazione. Poiché una quota basata sul consumo è associata alla sottoscrizione, un team centralizzato che fornisce i servizi OpenAI di Azure che usano il modello basato sul consumo deve distribuire istanze openAI di Azure tra più sottoscrizioni per ottenere la quota necessaria. La logica del gateway rimane ancora in gran parte la stessa.

Suggerimenti per più istanze in una singola area e in una topologia di più sottoscrizioni

• Idealmente, le sottoscrizioni devono essere tutte supportate con lo stesso tenant di Microsoft Entra per supportare la coerenza nel controllo degli accessi in base al ruolo di Azure e Criteri di Azure.

• Distribuire il gateway nella stessa area dell'istanza di Azure OpenAI.

• Distribuire il gateway in una sottoscrizione dedicata separata dalle istanze di Azure OpenAI. Ciò consente di applicare una coerenza nell'affrontare le istanze di Azure OpenAI e offre una segmentazione logica dei compiti tra le distribuzioni OpenAI di Azure e il relativo routing.

• Quando si instradano le richieste dal gateway tra sottoscrizioni, assicurarsi che gli endpoint privati siano raggiungibili. È possibile usare il routing transitivo tramite un hub a endpoint privati per i back-end nei rispettivi spoke. È possibile esporre endpoint privati per i servizi OpenAI di Azure direttamente nella sottoscrizione del gateway usando collegamento privato connessioni tra sottoscrizioni. Le connessioni tra sottoscrizioni collegamento privato sono preferibili se l'architettura e l'organizzazione supportano questo approccio.

Motivi per evitare un gateway per più istanze in una singola area e sottoscrizioni multiple

Tutti i motivi per evitare un gateway per più istanze in una singola area e sottoscrizione si applicano a questa topologia.

Più istanze openAI di Azure in più aree

Dettagli della topologia per più istanze openAI di Azure in più aree

• Distribuzioni di modelli OpenAI di Azure: più
• Istanze di Azure OpenAI: più istanze
• Sottoscrizioni: una o più sottoscrizioni
• Aree geografiche: multiple

La topologia usa i casi per più istanze openAI di Azure in più aree

Una topologia che include più istanze openAI di Azure distribuite in due o più aree di Azure supporta i casi d'uso seguenti:

• Include tutti i casi d'uso elencati per più istanze di Azure OpenAI in una singola area tramite più sottoscrizioni.

• Abilita una strategia di failover per la disponibilità del servizio, ad esempio l'uso di coppie tra aree.

• Consente di progettare la residenza e la conformità dei dati.

• Abilita la disponibilità del modello misto. Alcune aree hanno modelli diversi e quote diverse disponibili per i modelli.

Anche se tecnicamente non diverse aree di Azure, questa topologia è applicabile anche quando si dispone di un modello di intelligenza artificiale esposto in una situazione incrociata, ad esempio in locale o in un altro cloud.

Introdurre un gateway per più istanze in più aree

Per le architetture business critical che devono sopravvivere a un'interruzione completa a livello di area, un gateway unificato globale consente di eliminare la logica di failover dal codice client. Questa implementazione richiede che il gateway non sia interessato da un'interruzione a livello di area.

Il load-balacing tra aree non è tipico, ma può essere usato in modo strategico per combinare le quote disponibili nelle distribuzioni basate sul consumo tra aree. Questo scenario non richiede che il gateway rimanga influenzato da un'interruzione a livello di area, ma è consigliabile per garantire la massima affidabilità del carico di lavoro.

Usare Gestione API di Azure (distribuzione in una singola area)

In questa topologia, Azure Gestione API viene usato in modo specifico per la tecnologia del gateway. In questo caso, Gestione API viene distribuito in una singola area. Da tale istanza del gateway si esegue il bilanciamento del carico attivo-attivo tra aree. I criteri nel gateway fanno riferimento a tutte le istanze di Azure OpenAI. Il gateway richiede la linea di rete per ogni back-end tra aree, tramite peering reti virtuali tra aree o endpoint privati. Le chiamate da questo gateway a un'istanza OpenAI di Azure in un'altra area comportano più addebiti per latenza di rete e in uscita.

Il gateway deve rispettare i segnali di limitazione e disponibilità dalle istanze di Azure OpenAI e rimuovere i back-end con errori dal pool fino a quando non è possibile leggere in modo sicuro l'istanza di Azure OpenAI con errori o limitata. Il gateway deve ritentare la richiesta corrente su un'altra istanza back-end nel pool in caso di errore, prima di eseguire il fallback per restituire un errore del gateway. Il controllo di integrità del gateway deve segnalare un errore quando non sono disponibili istanze OpenAI di Azure back-end.

Poiché questa topologia introduce un singolo punto di errore (il gateway), l'utilità di questa architettura specifica è piuttosto limitata. Questo modello si presta bene alla fatturazione basata sul consumo in Azure OpenAI quando si stima l'allocazione PTU potrebbe rivelarsi troppo complessa.

Variante attiva-passiva

Questo modello può essere usato anche per fornire un approccio attivo-passivo per gestire in modo specifico l'errore a livello di area solo di Azure OpenAI. In questa modalità, il traffico in genere passa dal gateway all'istanza di Azure OpenAI nella stessa area del servizio Gestione API. L'istanza di Azure OpenAI gestirà tutto il flusso di traffico previsto senza errori a livello di area. Può essere basato su PTU o basato sul consumo, a seconda del modello di fatturazione preferito. In caso di errore a livello di area di Azure OpenAI, il gateway può reindirizzare il traffico a un'altra area con Azure OpenAI già distribuito in modalità a consumo.

Usare Gestione API di Azure (distribuzione in più aree)

Per migliorare l'affidabilità dell'architettura precedente basata su Azure Gestione API, Gestione API supporta la distribuzione di un'istanza in più aree di Azure. Questa opzione di distribuzione offre un singolo piano di controllo, tramite una singola istanza di Gestione API, ma fornisce gateway replicati nelle aree desiderate. In questa topologia si distribuiscono i componenti del gateway in ogni area contenente istanze di Azure OpenAI che forniscono un'architettura del gateway attivo-attivo.

I criteri, ad esempio il routing e la logica di gestione delle richieste, vengono replicati in ogni singolo gateway. Tutta la logica dei criteri deve avere logica condizionale nei criteri per assicurarsi di chiamare le istanze OpenAI di Azure nella stessa area del gateway corrente. Per altre informazioni, vedere Instradare le chiamate API ai servizi back-end a livello di area. Il componente gateway richiede quindi una linea di rete solo per le istanze OpenAI di Azure nella propria area, in genere tramite endpoint privati.

Gestione API offre un routing completo completo (FQDN) globale basato sulla latenza più bassa. Usare questa funzionalità predefinita basata sulle prestazioni per le distribuzioni di gateway active-active. Questa funzionalità predefinita consente di gestire le prestazioni e gestire un'interruzione del gateway a livello di area. Il router globale predefinito supporta anche i test di ripristino di emergenza perché le aree possono essere simulate tramite la disabilitazione di singoli gateway. Assicurarsi che i client rispettino la durata (TTL) nel nome di dominio completo e abbiano la logica di ripetizione dei tentativi appropriata per gestire un failover DNS recente.

Se è necessario introdurre un web application firewall in questa architettura, è comunque possibile usare la soluzione di routing FQDN predefinita come origine back-end per il router globale che implementa un web application firewall. Il router globale delega la responsabilità del failover a Gestione API. In alternativa, è possibile usare i nomi di dominio completi del gateway a livello di area come membri del pool back-end. In quest'ultima architettura usare l'endpoint predefinito in /status-0123456789abcdef ogni gateway a livello di area o in un altro endpoint dell'API di integrità personalizzato per supportare il failover a livello di area. Se non si è certi, iniziare con l'approccio FQDN back-end di origine singola.

Questa architettura funziona meglio se è possibile considerare le aree come completamente disponibili o completamente non disponibili. Ciò significa che se il gateway Gestione API o l'istanza di Azure OpenAI non è disponibile, si vuole che il traffico client non venga più instradato al gateway Gestione API in tale area. A meno che non venga eseguito un altro provisioning, se il gateway a livello di area accetta ancora il traffico mentre Azure OpenAI non è disponibile, l'errore deve essere propagato al client. Per evitare l'errore del client, vedere un approccio migliorato nella variante active-active-passive di Azure OpenAI.

Se si verifica un'interruzione del gateway Gestione API o viene contrassegnata come non integra, le aree rimanenti disponibili devono assorbire il 100% del traffico da quelle altre aree. Ciò significa che è necessario eseguire il provisioning eccessivo delle istanze di Azure OpenAI basate su PTU per gestire il nuovo burst di traffico o usare un approccio attivo-passivo per il failover. Usare il calcolatore della capacità OpenAI di Azure per la pianificazione della capacità.

Assicurarsi che il gruppo di risorse che contiene Azure Gestione API sia la stessa posizione dell'istanza Gestione API stessa per ridurre il raggio di esplosione di un'interruzione a livello di area correlata che influisce sulla possibilità di accedere al provider di risorse per i gateway.

Variante active-active-passive di Azure OpenAI

La sezione precedente descrive la disponibilità del gateway fornendo una topologia del gateway attivo-attivo. Questa topologia combina il gateway attivo-attivo con una topologia OpenAI di Azure attiva-passiva conveniente. L'aggiunta di logica attiva-passiva al gateway per eseguire il failover a una distribuzione OpenAI di Azure basata sul consumo da una distribuzione basata su PTU può aumentare significativamente l'affidabilità del carico di lavoro. Questo modello consente comunque ai client di usare la soluzione di routing FQDN predefinita Gestione API per il routing basato sulle prestazioni.

Usare un gateway codificato personalizzato

Se le regole di routing per gateway sono troppo complesse per il team per considerare ragionevoli come criteri di Gestione API, è necessario distribuire e gestire la propria soluzione. Questa architettura deve essere una distribuzione in più aree del gateway, con un'unità di scala a disponibilità elevata per area. È necessario far fronte a tali distribuzioni con Frontdoor di Azure (Anycast) o Gestione traffico di Azure (DNS), in genere usando il routing basato sulla latenza e i controlli di integrità appropriati della disponibilità del gateway.

Usare Frontdoor di Azure se è necessario un web application firewall e l'accesso a Internet pubblico. Usare Gestione traffico se non è necessario un web application firewall e la durata (TTL DNS) è sufficiente. Quando si esegue il front-end delle istanze del gateway con Frontdoor di Azure (o qualsiasi proxy inverso), assicurarsi che il gateway non possa essere ignorato. Rendere disponibili le istanze del gateway solo tramite endpoint privato quando si usa Frontdoor di Azure e si aggiunge la convalida dell'intestazione HTTP nell'implementazione del X_AZURE_FDID gateway.

Posizionare le risorse per area usate nel gateway personalizzato in gruppi di risorse per area. In questo modo si riduce il raggio di un'interruzione a livello di area correlata che influisce sulla possibilità di accedere al provider di risorse per le risorse del gateway in tale area.

È anche possibile prendere in considerazione l'implementazione della logica del gateway con Gestione API, per gli altri vantaggi di Gestione API, ad esempio TLS, autenticazione, controllo integrità o bilanciamento del carico round robin. In questo modo si spostano i problemi comuni relativi all'API dal codice personalizzato nel gateway e consente al gateway di gestire in modo specifico l'istanza di Azure OpenAI e il routing della distribuzione del modello.

Per la conformità alla residenza dei dati, assicurarsi che ogni limite geopolitico abbia una propria distribuzione isolata di questa architettura e che i client possano raggiungere solo l'endpoint autorizzato.

Motivi per evitare un gateway per più istanze in più aree

Non implementare un gateway unificato tra aree geopolitiche quando è necessaria la residenza e la conformità dei dati. In questo modo si violano i requisiti di residenza dei dati. Usare gateway indirizzabili singolarmente per area e seguire le indicazioni riportate in una delle sezioni precedenti.

Se non è previsto che i client eseguano il failover tra aree e si abbia la possibilità di concedere ai client un gateway specifico da usare, usare invece più gateway, uno per area e seguire le indicazioni riportate in una delle sezioni precedenti. Non associare la disponibilità di altre aree all'area contenente il gateway come singolo punto di errore.

Non implementare un gateway unificato se il modello e la versione non sono disponibili in tutte le aree esposte dal gateway. I client devono essere indirizzati allo stesso modello e alla stessa versione del modello. Per i gateway di failover e con bilanciamento del carico in più aree, è necessario selezionare un modello comune e una versione del modello disponibile in tutte le aree interessate. Per altre informazioni, vedere Disponibilità del modello. Se non è possibile standardizzare il modello e la versione del modello, il vantaggio del gateway è limitato.

Raccomandazioni generali

Indipendentemente dalla topologia necessaria per il carico di lavoro, esistono alcune raccomandazioni trasversali da considerare per la creazione della soluzione gateway.

Interazioni con stato

Quando i client usano le funzionalità con stato di Azure OpenAI, ad esempio l'API Assistants, è necessario configurare il gateway per aggiungere un client a un back-end specifico durante tale interazione. Questa operazione può essere eseguita archiviando i dati dell'istanza in un cookie. In questi scenari, valutare la possibilità di restituire una risposta dell'API OpenAI di Azure come a 429 un client aggiunto anziché reindirizzarle a un'istanza di Azure OpenAI diversa. In questo modo il client può gestire in modo esplicito l'indisponibilità improvvisa anziché nasconderla e essere indirizzata a un'istanza del modello senza cronologia.

Controlli di integrità del gateway

Esistono due prospettive di controllo dell'integrità da considerare, indipendentemente dalla topologia.

Se il gateway è basato sul round robining o l'esecuzione rigorosa del failover di disponibilità del servizio, si vuole un modo per eliminare lo stato di disponibilità di un'istanza o un modello di Azure OpenAI. Azure OpenAI non fornisce alcun tipo di endpoint di controllo integrità per sapere in modo preliminare se è disponibile per gestire le richieste. È possibile inviare transizioni sintetiche attraverso, ma che utilizza la capacità del modello. A meno che non si disponga di un'altra origine segnale affidabile per l'istanza e la disponibilità del modello di Azure OpenAI, il gateway probabilmente deve presupporre che l'istanza di Azure OpenAI sia attiva e quindi gestire 429, 500, 503 i codici di stato HTTP come segnale di interruzione del circuito per le richieste future su tale istanza o modello per un certo periodo di tempo. Per le situazioni di limitazione, rispettare sempre i dati nell'intestazione disponibile nelle risposte dell'API Retry-After OpenAI di Azure per 429 i codici di risposta nella logica di interruzione del circuito. Se si usa Azure Gestione API, valutare l'uso della funzionalità di interruttore incorporata.

I client o il team operativo del carico di lavoro potrebbero voler avere un controllo di integrità esposto nel gateway per scopi di routing o introspezione. Se si usa Gestione API, il valore predefinito potrebbe non essere sufficientemente dettagliato /status-0123456789abcdef perché riguarda principalmente l'istanza del gateway Gestione API, non i back-end. Prendere in considerazione l'aggiunta di un'API di controllo dell'integrità dedicata che può restituire dati significativi ai client o ai sistemi di osservabilità sulla disponibilità del gateway o route specifiche nel gateway.

Procedure di distribuzione sicure

È possibile usare le implementazioni del gateway per orchestrare le distribuzioni blu-verde dei modelli aggiornati. I modelli OpenAI di Azure vengono aggiornati con nuove versioni del modello e nuovi modelli e potrebbero essere disponibili nuovi modelli ottimizzati.

Dopo aver testato gli effetti di una modifica nella preproduzione, valutare se i client di produzione devono essere "tagliati" alla nuova versione del modello o spostare invece il traffico. Il modello di gateway descritto in precedenza consente al back-end di distribuire simultaneamente entrambi i modelli. La distribuzione di modelli contemporaneamente consente al gateway di reindirizzare il traffico in base alla procedura di distribuzione sicura del team del carico di lavoro dell'implementazione incrementale.

Anche se non si usano distribuzioni blu-verde, l'approccio APIOps del carico di lavoro deve essere definito e sufficientemente automatizzato con la frequenza di modifica delle distribuzioni di istanze e modelli back-end.

Implementazione sufficiente

Molti degli scenari introdotti in questo articolo consentono di aumentare il potenziale obiettivo del livello di servizio (SLO) del carico di lavoro riducendo la complessità dei client e implementando tecniche di auto-conservazione affidabili. Altri migliorano la sicurezza del carico di lavoro spostando i controlli di accesso a modelli specifici da Azure OpenAI. Assicurarsi che l'introduzione del gateway non finirà contro questi obiettivi. Comprendere i rischi di aggiungere un nuovo singolo punto di errore tramite errori del servizio o problemi di configurazione causati dall'utente nel gateway, logica di routing complessa o rischi di esporre più modelli a client non autorizzati di quanto previsto.

Sovranità dei dati

I vari approcci attivi-attivi e attivi-passivi devono essere valutati dal punto di vista della conformità alla residenza dei dati per il carico di lavoro. Molti di questi modelli sono applicabili per l'architettura del carico di lavoro se le aree coinvolte rimangono entro il limite geopolitico. Per supportare questo scenario, è necessario considerare i limiti geopolitici come francobolli isolati e applicare la gestione attiva-attiva o attiva-passiva esclusivamente all'interno di tale timbro.

In particolare, qualsiasi routing basato sulle prestazioni deve essere attentamente esaminato per la conformità alla sovranità dei dati. Negli scenari di sovranità dei dati non è possibile gestire i client con un'altra area geografica e rimanere conformi. Tutte le architetture di gateway che implicano la residenza dei dati devono imporre che i client usino solo gli endpoint nella propria area geopolitica. I client devono essere bloccati dall'uso di altri endpoint gateway e il gateway stesso non viola l'attendibilità del client effettuando una richiesta geopolitica incrociata. Il modo più affidabile per implementare questa segmentazione consiste nel creare l'architettura intorno a un gateway completamente indipendente e a disponibilità elevata per ogni area geopolitica.

Autorizzazione di Azure OpenAI

Il gateway deve eseguire l'autenticazione con tutte le istanze openAI di Azure con cui si interfaccia. A meno che il gateway non sia stato progettato per eseguire l'autenticazione pass-through, il gateway deve usare un'identità gestita per le credenziali. Ogni istanza di Azure OpenAI deve quindi configurare il controllo degli accessi in base al ruolo con privilegi minimi per le identità gestite dei gateway. Per le architetture attive e di failover, assicurarsi che l'identità del gateway disponga di autorizzazioni equivalenti in tutte le istanze di Azure OpenAI coinvolte.

Criteri di Azure

La coerenza tra le distribuzioni di modelli e le istanze di Azure OpenAI è importante nelle situazioni attive-attive o attive-passive. Usare Criteri di Azure per applicare la coerenza tra le varie istanze o distribuzioni di modelli di Azure OpenAI. Se i criteri predefiniti per Azure OpenAI non sono sufficienti per garantire la coerenza tra di essi, è consigliabile creare o usare criteri personalizzati creati dalla community.

Ridondanza di Gateway

Anche se non è specifico di più back-end, l'implementazione del gateway di ogni area deve essere sempre compilata con ridondanza ed essere a disponibilità elevata all'interno dell'unità di scala. Scegliere le aree con zone di disponibilità e assicurarsi che il gateway sia distribuito tra di essi. Distribuire più istanze del gateway in modo che un singolo punto di errore sia limitato a un'interruzione completa a livello di area e non all'errore di una singola istanza di calcolo nel gateway. Per Gestione API, distribuire due o più unità tra due o più zone. Per le implementazioni di codice personalizzate, distribuire almeno tre istanze con una distribuzione ottimale tra zone di disponibilità.

Implementazioni del gateway

Azure non offre una soluzione chiavi in volta o un'architettura di riferimento per la compilazione di tale gateway. Come indicato nell'articolo introduttivo, il team del carico di lavoro deve compilare e gestire questo gateway. Di seguito sono riportati alcuni esempi di implementazioni di esempio supportate dalla community relative ad alcuni dei casi d'uso indicati in precedenza. È consigliabile fare riferimento a questi esempi di GitHub quando si compila un modello di verifica personalizzato.

Implementazione	Esempio
Gestione API di Azure	Bilanciamento del carico intelligente per Azure OpenAI con Azure Gestione API: questo repository GitHub contiene codice di criteri di esempio e istruzioni per la distribuzione nella sottoscrizione. Ridimensionamento di Azure OpenAI con Azure Gestione API: questo repository GitHub contiene codice di criteri di esempio e istruzioni per PTU e spillover sul consumo. Il toolkit del gateway GenAI contiene criteri di esempio Gestione API insieme a una configurazione di test di carico per testare il comportamento dei criteri.
Codice personalizzato	Bilanciamento del carico intelligente per Azure OpenAI con App Azure Container Questo repository GitHub contiene codice C# di esempio e istruzioni per compilare il contenitore e distribuirlo nella sottoscrizione.

Passaggi successivi

La presenza di un'implementazione del gateway per il carico di lavoro offre vantaggi oltre al vantaggio di routing di più back-end tattico descritto in questo articolo. Informazioni sulle altre sfide chiave che un gateway può risolvere.

Risorse correlate

• Servizio OpenAI di Azure
• Gateway API in Gestione API di Azure