Il servizio OpenAI di Azure espone le API HTTP che consentono alle applicazioni di eseguire incorporamenti o completamenti usando i modelli linguistici di OpenAI. Le applicazioni intelligenti chiamano queste API HTTP direttamente dai client o dagli agenti di orchestrazione. Esempi di client includono il codice dell'interfaccia utente della chat e le pipeline di elaborazione dati personalizzate. Esempi di agenti di orchestrazione includono LangChain, Semantic Kernel e flusso di prompt in Azure AI Foundry. Quando il carico di lavoro si connette a una o più istanze di Azure OpenAI, è necessario decidere se questi consumer si connettono direttamente o tramite un gateway API proxy inverso.
Usare questa guida per informazioni sulle sfide principali tra i cinque pilastri di Azure Well-Architected Framework che si verificano se la progettazione del carico di lavoro include l'accesso diretto dai consumer alle API del piano dati OpenAI di Azure. Si apprenderà quindi come introdurre un gateway nell'architettura può aiutare a risolvere questi problemi di accesso diretto, introducendo nuove sfide. Questo articolo descrive il modello di architettura, ma non come implementare il gateway.
Poiché un gateway può essere usato per risolvere scenari specifici che potrebbero non essere presenti in ogni carico di lavoro, vedere vedere Linee guida per scenari specifici, che esaminano in modo più approfondito il caso d'uso specifico di un gateway.
Sfide principali
Senza un gateway API o la possibilità di aggiungere logica alle API HTTP openAI di Azure, il client deve gestire la logica client dell'API, che include meccanismi di ripetizione dei tentativi o interruttori di circuito. Questa situazione può essere complessa negli scenari in cui non si controlla direttamente il codice client o quando il codice è limitato a un utilizzo specifico dell'SDK. Più client o più istanze di Azure OpenAI e distribuzioni presentano ulteriori sfide, ad esempio il coordinamento delle distribuzioni sicure e l'osservabilità.
Questa sezione fornisce esempi di problemi di architettura chiave specifici che possono verificarsi se l'architettura supporta solo l'accesso diretto ad Azure OpenAI dai consumer. Le sfide sono organizzate usando i pilastri di Azure Well-Architected Framework.
Problemi di affidabilità
L'affidabilità del carico di lavoro dipende da diversi fattori, tra cui la capacità per l'auto-conservazione e il ripristino automatico, che vengono spesso implementati tramite meccanismi di replica e failover. Senza un gateway, tutti i problemi di affidabilità devono essere risolti esclusivamente usando la logica client e le funzionalità del servizio Azure OpenAI. L'affidabilità del carico di lavoro viene compromessa quando non è disponibile un controllo di affidabilità sufficiente in una di queste due superfici.
bilanciamento del carico o ridondanza: failover tra più istanze di Azure OpenAI in base alla disponibilità del servizio è responsabilità del client che è necessario controllare tramite la configurazione e la logica personalizzata.
global, standard o con provisioning e zona dati, standard o con provisioning, non influiscono sulla disponibilità del servizio Azure OpenAI dal punto di vista della disponibilità dell'endpoint a livello di area. Si ha comunque la responsabilità di implementare manualmente la logica di failover.
Aumentare il numero di istanze per gestire i picchi: il failover nelle istanze OpenAI di Azure con capacità quando è limitata è un'altra responsabilità del client che è necessario controllare tramite la configurazione e la logica personalizzata. L'aggiornamento di più configurazioni client per le nuove istanze OpenAI di Azure presenta un rischio maggiore e presenta problemi di tempestività. Lo stesso vale per l'aggiornamento del codice client per implementare le modifiche nella logica, ad esempio indirizzare le richieste con priorità bassa a una coda durante periodi di domanda elevati.
Limitazione: LE API OpenAI di Azure limitano le richieste restituendo un codice di risposta di errore HTTP 429 alle richieste che superano il token -Per-Minute (TPM) o le richieste -Per-Minute (RPM) nel modello standard. Le API OpenAI di Azure limitano anche le richieste che superano la capacità di provisioning per il modello di fatturazione con provisioning preliminare. La gestione del back-off e della logica di ripetizione dei tentativi appropriata viene lasciata esclusivamente alle implementazioni client.
La maggior parte dei carichi di lavoro deve risolvere questo problema specifico usando globale e zona dati distribuzioni di Azure OpenAI. Queste distribuzioni per usare la capacità del modello dai data center con la capacità sufficiente per ogni richiesta. L'uso di distribuzioni globali e di zone dati ridurrà significativamente la limitazione del servizio senza aggiungere complessità ai gateway personalizzati. Le distribuzioni globali e delle zone dati sono in sé un'implementazione del gateway.
Problemi di sicurezza
I controlli di sicurezza devono contribuire a proteggere la riservatezza, l'integrità e la disponibilità del carico di lavoro. Senza un gateway, tutti i problemi di sicurezza devono essere risolti esclusivamente nella logica client e nelle funzionalità del servizio Azure OpenAI. I requisiti del carico di lavoro possono richiedere più di quanto sia disponibile per la segmentazione client, il controllo client o le funzionalità di sicurezza dei servizi per la comunicazione diretta.
Gestione delle identità - Ambito di autenticazione: le API del piano dati esposte da Azure OpenAI possono essere protette in due modi: chiave API o controllo degli accessi in base al ruolo di Azure. In entrambi i casi, l'autenticazione avviene a livello di istanza di Azure OpenAI, non a livello di distribuzione individuale, che introduce complessità per fornire l'accesso con privilegi minimi e la segmentazione delle identità per modelli di distribuzione specifici.
Gestione delle identità - Provider di identità: i client che non possono usare identità che si trovano nel tenant di Microsoft Entra che esegue il supporto dell'istanza di Azure OpenAI devono condividere una singola chiave API di accesso completo. Le chiavi API presentano limitazioni di utilità per la sicurezza e sono problematiche quando più client sono coinvolti e condividono tutte la stessa identità.
Sicurezza di rete: a seconda del percorso client rispetto alle istanze di Azure OpenAI, potrebbe essere necessario l'accesso a Internet pubblico ai modelli linguistici.
Sovranità dei dati: la sovranità dei dati nel contesto di Azure OpenAI si riferisce ai requisiti legali e normativi correlati all'archiviazione e all'elaborazione dei dati entro i limiti geografici di un paese o di un'area geografica specifica. Il carico di lavoro deve garantire l'affinità a livello di area in modo che i client possano rispettare le leggi di residenza e sovranità dei dati. Questo processo prevede più distribuzioni OpenAI di Azure.
È necessario tenere presente che quando si usa globale o zona dati distribuzioni di Azure OpenAI, i dati inattivi rimangono nell'area geografica di Azure designata, ma i dati possono essere trasmessi ed elaborati per l'inferenza in qualsiasi posizione OpenAI di Azure.
Problemi di ottimizzazione dei costi
I carichi di lavoro traggono vantaggio quando le architetture riducono al minimo gli sprechi e ottimizzano l'utilità. La modellazione e il monitoraggio dei costi elevati sono un requisito importante per qualsiasi carico di lavoro. Senza un gateway, l'utilizzo del provisioning o del rilevamento dei costi per client può essere ottenuto in modo autorevole esclusivamente dall'aggregazione dei dati di telemetria di utilizzo dell'istanza OpenAI di Azure.
Rilevamento dei costi: la possibilità di fornire una prospettiva finanziaria sull'utilizzo di Azure OpenAI è limitata ai dati aggregati dai dati di telemetria dell'utilizzo delle istanze OpenAI di Azure. Quando è necessario eseguire chargeback o showback, è necessario attribuire i dati di telemetria di utilizzo con vari client in reparti diversi o persino clienti per scenari multi-tenant.
Utilizzo della velocità effettiva con provisioning: il carico di lavoro vuole evitare sprechi usando completamente la velocità effettiva di cui è stato effettuato il provisioning. Ciò significa che i client devono essere attendibili e coordinati per usare le distribuzioni di modelli di cui è stato effettuato il provisioning prima di eseguire la distribuzione in qualsiasi distribuzione di modelli standard.
Sfide di eccellenza operativa
Senza un gateway, l'osservabilità, il controllo delle modifiche e i processi di sviluppo sono limitati a ciò che viene fornito dalla comunicazione diretta da client a server.
Controllo della quota: i client ricevono codici di risposta 429 direttamente da Azure OpenAI quando le API HTTP sono limitate. Gli operatori del carico di lavoro sono responsabili di garantire che sia disponibile una quota sufficiente per l'utilizzo legittimo e che i client che si comportano in modo errato non consumano in eccesso. Quando il carico di lavoro è costituito da più distribuzioni di modelli o più zone dati, la comprensione dell'utilizzo delle quote e della disponibilità della quota può essere difficile da visualizzare.
Monitoraggio e osservabilità: le metriche predefinite di Azure OpenAI sono disponibili tramite Monitoraggio di Azure. Tuttavia, esiste una latenza con la disponibilità dei dati e non fornisce il monitoraggio in tempo reale.
Procedure di distribuzione sicure: il processo GenAIOps richiede il coordinamento tra i client e i modelli distribuiti in Azure OpenAI. Per gli approcci di distribuzione avanzati, ad esempio blu-verde o canary, la logica deve essere gestita sul lato client.
Problemi di efficienza delle prestazioni
Senza un gateway, il carico di lavoro mette la responsabilità sui client di essere individualmente ben comportati e di comportarsi in modo equo con altri client rispetto a capacità limitata.
Ottimizzazione delle prestazioni - Traffico prioritario: definizione delle priorità delle richieste client in modo che i client con priorità alta abbiano accesso preferenziale rispetto ai client con priorità bassa richiederebbero un coordinamento esteso e probabilmente irragionevole da client a client. Alcuni carichi di lavoro possono trarre vantaggio dalla presenza di richieste con priorità bassa in coda per l'esecuzione quando l'utilizzo del modello è basso.
Ottimizzazione delle prestazioni - Conformità client: per condividere la capacità, i client devono essere ben comportati. Un esempio è quando i client assicurano che
max_tokens
ebest_of
siano impostati su valori approvati. Senza un gateway, è necessario considerare attendibili i client per agire nel miglior interesse per mantenere la capacità dell'istanza di Azure OpenAI.Ridurre al minimo la latenza: anche se la latenza di rete è in genere un piccolo componente del flusso complessivo delle richieste di richiesta e completamento, assicurarsi che i client vengano indirizzati a un endpoint di rete e che il modello vicino a essi possa essere utile. Senza un gateway, i client devono selezionare automaticamente gli endpoint di distribuzione del modello da usare e quali credenziali sono necessarie per l'API del piano dati OpenAI di Azure specifica.
Soluzione
Figura 1: Architettura concettuale dell'accesso ad Azure OpenAI tramite un gateway
Per risolvere le numerose sfide elencate in Sfide principali, è possibile inserire un gateway proxy inverso per separare l'applicazione intelligente da Azure OpenAI. Questo offload del gateway consente di spostare responsabilità, complessità e osservabilità lontano dai client e offre l'opportunità di aumentare Azure OpenAI fornendo altre funzionalità che non sono integrate. Alcuni esempi sono:
Potenziale implementazione dell'autenticazione federata.
Possibilità di controllare la pressione sui modelli attraverso la limitazione della velocità.
Monitoraggio incrociato e cross-model.
Possibilità di introdurre l'aggregazione del gateway e il routing avanzato a più servizi, ad esempio il routing di messaggi con priorità bassa a una coda per il livellamento del carico basato su coda o il calcolo per eseguire attività.
Bilanciamento del carico che usa monitoraggio degli endpoint di integrità per instradare solo gli endpoint integri di interruzione del circuito in distribuzioni di modelli non disponibili o di overload.
Per alcuni scenari specifici sono disponibili altre indicazioni che indirizzano direttamente un gateway API e le istanze openAI di Azure. Questi scenari sono elencati nella sezione Passaggi successivi.
Considerazioni
Quando si introduce un nuovo componente nell'architettura, è necessario valutare i compromessi appena introdotti. Quando si inserisce un gateway API tra i client e il piano dati OpenAI di Azure per risolvere eventuali problemi chiave, si introducono nuove considerazioni nell'architettura. Valutare attentamente se l'impatto del carico di lavoro in queste considerazioni sull'architettura giustifica il valore aggiunto o l'utilità del gateway.
Affidabilità
L'affidabilità garantisce che l'applicazione soddisfi gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.
La soluzione gateway può introdurre un singolo punto di errore. Questo errore potrebbe avere l'origine nella disponibilità del servizio della piattaforma gateway, interruzioni a causa di distribuzioni di codice o configurazione o persino endpoint API critici configurati in modo errato nel gateway. Assicurarsi di progettare l'implementazione per soddisfare i requisiti di disponibilità del carico di lavoro. Prendere in considerazione la resilienza e le funzionalità di tolleranza di errore nell'implementazione includendo il gateway nell'analisi della modalità di errore del carico di lavoro.
La soluzione potrebbe richiedere funzionalità di routing globale se l'architettura richiede istanze OpenAI di Azure in più aree per aumentare la disponibilità degli endpoint OpenAI di Azure, ad esempio la possibilità di continuare a gestire le richieste in caso di interruzione a livello di area. Questa situazione può complicare ulteriormente la topologia tramite la gestione di nomi di dominio completi aggiuntivi, certificati TLS e altri componenti di routing globali.
Importante
Non implementare un gateway in questo caso metterebbe a repentaglio la capacità del carico di lavoro di soddisfare gli obiettivi a livello di servizio concordati.
Sicurezza
Quando si valuta il modo in cui un gateway API offre vantaggi all'architettura, usare l'elenco di controllo Di revisione della progettazione per la sicurezza per valutare la progettazione. È necessario affrontare le considerazioni sulla sicurezza, ad esempio le seguenti:
La superficie del carico di lavoro viene aumentata con l'aggiunta del gateway. Questa area di attacco offre considerazioni aggiuntive sulla gestione delle identità e degli accessi (IAM) delle risorse di Azure, sull'aumento delle attività di protezione avanzata e altro ancora.
Il gateway può fungere da transizione di limiti di rete tra lo spazio di rete client e lo spazio di rete OpenAI privato di Azure. Anche se il gateway rende privato un endpoint OpenAI di Azure con connessione Internet precedente tramite l'uso di collegamento privato di Azure, ora diventa il nuovo punto di ingresso e deve essere adeguatamente protetto.
Un gateway è in una posizione univoca per visualizzare i dati delle richieste non elaborati e formulare risposte dal modello linguistico, che potrebbe includere dati riservati da entrambe le origini. La conformità dei dati e l'ambito normativo sono ora estesi a questo altro componente.
Un gateway può estendere l'ambito dell'autorizzazione e dell'autenticazione client oltre l'autenticazione dell'ID e della chiave API di Microsoft Entra e potenzialmente tra più provider di identità (IdP).
La sovranità dei dati deve essere considerata nell'implementazione in implementazioni in più aree. Assicurarsi che la logica di calcolo e routing del gateway rispetti i requisiti di sovranità inseriti nel carico di lavoro.
Importante
Non implementare un gateway in questo caso, lasciare che il carico di lavoro non sia in grado di proteggere la riservatezza, l'integrità o la disponibilità dei propri dati o dei relativi utenti.
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.
Tutti i gateway API implementati hanno costi di runtime che devono essere preventivati e considerati. Questi costi aumentano in genere con funzionalità aggiunte per soddisfare l'affidabilità, la sicurezza e le prestazioni del gateway stesso insieme ai costi operativi introdotti con la gestione APIOps aggiunta. Questi costi aggiunti devono essere misurati rispetto al nuovo valore fornito dal sistema con il gateway. Si vuole raggiungere un punto in cui le nuove funzionalità introdotte usando un gateway superano i costi per implementare e gestire il gateway. A seconda della relazione del carico di lavoro con i relativi utenti, potrebbe essere possibile eseguire il chargeback dell'utilizzo.
Per gestire i costi durante lo sviluppo e il test di un gateway, è consigliabile usare un endpoint simulato per Azure OpenAI. Ad esempio, usare la soluzione nel repository GitHub del simulatore api OpenAI di Azure.
Eccellenza operativa
Quando si valuta il modo in cui un gateway API offre vantaggi all'architettura, usare l'elenco di controllo di revisione della progettazione per l'eccellenza operativa per valutare la progettazione. È necessario affrontare considerazioni sull'eccellenza operativa, ad esempio le seguenti:
Il gateway stesso deve essere monitorato dalla soluzione di monitoraggio del carico di lavoro e potenzialmente dai client. Ciò significa che le operazioni e il calcolo del gateway devono essere inclusi nella modellazione dell'integrità del carico di lavoro.
Le procedure di distribuzione sicure devono ora gestire la distribuzione dell'infrastruttura del gateway API e il codice o la configurazione del routing del gateway. La soluzione di automazione e infrastruttura come codice (IaC) dell'infrastruttura deve considerare come considerare il gateway come risorsa di lunga durata nel carico di lavoro.
È necessario compilare o estendere l'approccio APIOps per coprire le API esposte nel gateway.
È possibile duplicare le funzionalità disponibili tramite soluzioni come la risorsa del servizio azure per intelligenza artificiale o la funzionalità di distribuzione del carico della zona dati OpenAI di Azure.
Efficienza delle prestazioni
Quando si valuta il modo in cui un gateway API offre vantaggi all'architettura, usare l'elenco di controllo di revisione della progettazione per l'efficienza delle prestazioni per valutare la progettazione. È necessario tenere conto delle considerazioni sull'efficienza delle prestazioni, ad esempio le seguenti:
Il servizio gateway può introdurre un collo di bottiglia della velocità effettiva. Assicurarsi che il gateway abbia prestazioni adeguate per gestire il carico simultaneo completo e possa essere facilmente ridimensionato in linea con le aspettative di crescita. Garantire elasticità nella soluzione in modo che il gateway possa ridurre l'offerta o ridurre le prestazioni quando la domanda è bassa, ad esempio con l'utilizzo del giorno lavorativo.
Il servizio gateway lo ha elaborato deve eseguire per ogni richiesta e introduce una latenza aggiunta per ogni chiamata API. È consigliabile ottimizzare la logica di routing per mantenere le richieste migliori.
Nella maggior parte dei casi, il gateway deve essere geograficamente vicino agli utenti e alle istanze di Azure OpenAI per ridurre la latenza. Anche se la latenza di rete è in genere una piccola percentuale di tempo nelle chiamate API complessive ai modelli linguistici, potrebbe essere un fattore competitivo per il carico di lavoro.
Valutare l'impatto del gateway sulle funzionalità OpenAI di Azure, ad esempio le risposte di streaming o l'aggiunta di istanze per le interazioni con stato, ad esempio l'API Assistants.
Importante
Non implementare un gateway se ciò rende impossibile o troppo compromesso il raggiungimento di obiettivi di prestazioni negoziati.
Opzioni di implementazione
Azure non offre una soluzione chiavi in volta progettata specificamente per il proxy dell'API HTTP di Azure OpenAI o di altre API di inferenza del modello linguistico personalizzato per coprire tutti questi scenari. Sono tuttavia disponibili ancora diverse opzioni per il team del carico di lavoro da implementare, ad esempio un gateway in Azure.
Usare Gestione API di Azure
Azure Gestione API è un servizio gestito dalla piattaforma progettato per l'offload di problematiche trasversali per le API basate su HTTP. È basata sulla configurazione e supporta la personalizzazione tramite il sistema dei criteri di elaborazione delle richieste in ingresso e in uscita. Supporta repliche a disponibilità elevata, con ridondanza della zona e persino in più aree usando un singolo piano di controllo.
La maggior parte della logica di gestione delle richieste e del routing del gateway deve essere implementata nel sistema dei criteri di Gestione API. È possibile combinare criteri predefiniti specifici di Azure OpenAI, ad esempio Limitare l'utilizzo dei token dell'API OpenAI di Azure o Generare metriche per l'utilizzo di token OpenAI di Azuree criteri personalizzati. Il repository GitHub del toolkit del gateway GenAI contiene diversi criteri di Gestione API personalizzati insieme a una configurazione di test di carico per testare il comportamento dei criteri.
Usare la Guida al servizio Well-Architected Framework per Gestione API durante la progettazione di una soluzione che coinvolge Azure Gestione API. Se il carico di lavoro esiste come parte di una zona di destinazione dell'applicazione, esaminare le indicazioni disponibili in Cloud Adoption Framework per Azure per implementare una zona di destinazione di Azure Gestione API.
L'uso di Azure Gestione API per l'implementazione del gateway è in genere l'approccio preferito per la creazione e l'uso di un gateway OpenAI di Azure. È preferibile perché il servizio è un'offerta PaaS (Platform as a Service) con funzionalità predefinite avanzate, disponibilità elevata e opzioni di rete. Offre anche approcci APIOps affidabili per la gestione delle API di completamento.
Uso di codice personalizzato
L'approccio del codice personalizzato richiede a un team di sviluppo software di creare una soluzione personalizzata codificata e di distribuire tale soluzione in una piattaforma applicativa di Azure di propria scelta. La creazione di una soluzione autogestito per gestire la logica del gateway può essere adatta ai team del carico di lavoro esperti nella gestione del codice di rete e routing.
Il carico di lavoro può in genere usare le risorse di calcolo con cui hanno familiarità, ad esempio l'hosting del codice del gateway nel servizio app Azure, nelle app contenitore di Azure o servizio Azure Kubernetes.
Le distribuzioni di codice personalizzate possono anche essere front-end con Gestione API quando Gestione API viene usato esclusivamente per le funzionalità principali del gateway API HTTP tra i client e il codice personalizzato. In questo modo, le interfacce di codice personalizzate vengono create esclusivamente con le API HTTP OpenAI di Azure in base alla logica di business necessaria.
L'uso della tecnologia gateway non Microsoft, che è un prodotto o un servizio non fornito in modo nativo da Azure, può essere considerato come parte di questo approccio.
Architettura di esempio
Figura 2: Architettura di esempio di accesso ad Azure OpenAI tramite un gateway basato su Gestione API di Azure
Passaggi successivi
Informazioni su uno scenario specifico in cui la distribuzione di un gateway tra un'applicazione intelligente e le distribuzioni OpenAI di Azure viene usata per soddisfare i requisiti del carico di lavoro:
- Bilanciamento del carico o failover tra più istanze back-end
- Autenticazione e autorizzazione personalizzate per le applicazioni client
Informazioni su come implementare la registrazione e il monitoraggio per i modelli OpenAI di Azure.
Risorse correlate
- Servizio OpenAI di Azure
- Gateway API in Gestione API di Azure
- Gestione API zona di destinazione Repository GitHub che copre scenari di intelligenza artificiale generativi
- toolkit del gateway Gestione API
- Simulatore di API OpenAI