Accedere ai modelli foundry e ad altri modelli linguistici tramite un gateway

Questo articolo descrive le sfide principali che si verificano quando si espongono le API del piano dati dei modelli Foundry direttamente ai consumer. Valuta queste sfide rispetto ai cinque pilastri del framework di Azure Well-Architected. L'articolo illustra anche come attenuare questi problemi inserendo un gateway. Le linee guida sono incentrate sul modello architetturale anziché sui dettagli specifici dell'implementazione del gateway.

Microsoft Foundry espone le API HTTP che consentono alle applicazioni di eseguire incorporamenti o completamenti usando modelli di linguaggio. 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 Microsoft Agent Framework, Kernel semantico, LangChain e Foundry Agent Service. Quando il carico si connette a una o più risorse Foundry o istanze del modello Foundry, è necessario decidere se questi client si connettono direttamente o attraverso un gateway API di reverse proxy.

È possibile usare un gateway per risolvere scenari specifici che potrebbero non essere presenti in ogni carico di lavoro. Per altre informazioni, vedere scenari specifici per esempi di utilizzo del gateway.

Sfide principali

Quando non è presente alcun gateway API, è necessario implementare meccanismi di ripetizione dei tentativi, interruttori di circuito e strategie di backoff. Tuttavia, potrebbe non essere possibile modificare il codice client o il codice potrebbe essere limitato a un utilizzo specifico dell'SDK. Più client o più istanze di risorse Foundry e implementazioni di modelli presentano ulteriori sfide, come il coordinamento delle sicure implementazioni e l'osservabilità.

In questa sezione vengono forniti esempi di sfide specifiche che possono verificarsi se l'architettura supporta solo l'accesso diretto ai modelli Foundry dai consumer. Le sfide sono organizzate utilizzando i pilastri del 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à della piattaforma del modello. 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: Il failover tra più risorse Foundry o istanze del modello, in base alla disponibilità del servizio, è una responsabilità del cliente di cui è necessario avere il controllo attraverso la configurazione e la logica personalizzata.

  La scelta del tipo di distribuzione non modifica la disponibilità dell'endpoint a livello di area della risorsa Foundry. Le distribuzioni possono essere globali o Zone dati, standard o provisionate. La logica di failover rimane responsabilità dell'utente indipendentemente dal tipo di distribuzione.

• Scalare orizzontalmente per gestire i picchi: Quando le applicazioni registrano aumenti improvvisi della domanda, è necessario eseguire il failover verso istanze di Foundry Model che dispongono di capacità disponibile. Questo failover ricade sul client e deve essere gestito mediante la configurazione e una logica personalizzata. L'implementazione di tale modifica di configurazione in più client introduce il rischio di distribuzione e può essere difficile da implementare rapidamente. La stessa richiesta si applica ogni volta che è necessario aggiornare la logica client, ad esempio reindirizzando le richieste con priorità bassa a una coda durante periodi di domanda elevata.

• Limitazione: Le API foundry limitano le richieste restituendo un codice di risposta di errore HTTP 429 alle richieste che superano i token al minuto (TPM) o le richieste al minuto (RPM) nel modello standard. Le API Foundry limitano anche le richieste che superano la capacità di provisioning prevista per il modello di fatturazione pre-provisionato. Le implementazioni client sono esclusivamente responsabili della gestione della logica di back-off e ripetizione dei tentativi appropriata.

  La maggior parte dei carichi di lavoro deve risolvere questo problema specifico usando le distribuzioni di aree dati e globali dei modelli. Queste distribuzioni utilizzano la capacità del modello dei data center che dispongono di capacità sufficiente per soddisfare ogni richiesta. L'uso di distribuzioni Global e Data Zone riduce significativamente il throttling del servizio senza l'ulteriore complessità dei gateway personalizzati. Le distribuzioni Global e Data Zone sono esse stesse un'implementazione di gateway.

Problemi di sicurezza

I controlli di sicurezza consentono di proteggere la riservatezza, l'integrità e la disponibilità del carico di lavoro. Senza un gateway, è necessario risolvere tutti i problemi di sicurezza esclusivamente tramite la logica client e le funzionalità Foundry. 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: Foundry espone le API del piano dati, che possono essere protette in uno dei due modi seguenti: chiave API o controllo degli accessi basato sui ruoli di Azure (RBAC). In entrambi i casi, l'autenticazione avviene a livello di risorsa o progetto Foundry, non a livello di distribuzione del singolo modello. Applicare l'accesso con privilegi minimi o isolare l'ambito dell'identità a una distribuzione specifica di un modello diventano più complessi.

• Gestione delle identità - provider di identità: I client che non possono usare le identità presenti nel tenant Microsoft Entra a cui è associata l'istanza della risorsa Foundry devono condividere un'unica chiave API con 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 della posizione client relativa alle istanze delle risorse Foundry, potrebbe essere necessario l'accesso a Internet pubblico ai modelli linguistici.

• Sovranità dei dati: Paesi e aree geografiche specifici hanno requisiti normativi correlati all'archiviazione e all'elaborazione dei dati. 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 include più istanze di risorse Foundry.

  Quando si usano distribuzioni globali o di zona dati, i dati inattivi rimangono nell'area geografica Azure designata. Tuttavia, i dati potrebbero essere trasmessi ed elaborati per l'inferenza in qualsiasi posizione del modello Foundry.

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 requisiti importanti per qualsiasi carico di lavoro. Senza un gateway, monitorare l'utilizzo delle risorse di cui è stato effettuato il provisioning o attribuire i costi per cliente dipende interamente da ciò che è possibile aggregare dalla telemetria di Foundry.

• Rilevamento dei costi: La possibilità di fornire una prospettiva finanziaria sull'utilizzo di Foundry è limitata ai dati aggregati dai dati di telemetria di Foundry. 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 del throughput con provisioning: Per evitare di pagare throughput con provisioning non utilizzato, bisogna affidarsi ai client affinché si coordinino per sfruttare fino in fondo le distribuzioni di modelli con provisioning prima di passare alle distribuzioni standard.

Sfide di eccellenza operativa

Senza un gateway, la visibilità sul comportamento del sistema, la possibilità di controllare le modifiche e le procedure di distribuzione sono tutte vincolate da ciò che ogni singolo client espone.

• Controllo quota: I client ricevono codici di risposta HTTP 429 direttamente da Foundry quando le API HTTP sono limitate. È necessario garantire che sia disponibile una quota sufficiente per l’uso legittimo e che i client problematici non consumino più del dovuto. 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 Foundry 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 Foundry. Per gli approcci di distribuzione avanzati, ad esempio blu-verde o canary, è necessario gestire la logica sul lato client.

Problemi di efficienza delle prestazioni

Senza un gateway, il carico di lavoro impone ai client la responsabilità di comportarsi bene individualmente e di interagire equamente con altri client rispetto alla capacità limitata condivisa.

• Ottimizzazione delle prestazioni - Traffico prioritario: La definizione delle priorità delle richieste client con priorità alta rispetto alle richieste con priorità bassa richiede 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. Ad esempio, i client possono assicurarsi che max_tokens e best_of siano impostati su valori approvati. Senza un gateway, devi fidarti dei client affinché agiscano in modo da preservare la capacità dell’istanza del modello Foundry.

• Ridurre al minimo la latenza: La latenza di rete è in genere un piccolo componente del flusso generale della richiesta di richiesta e del completamento. Tuttavia, può essere utile garantire che i client vengano instradati verso un endpoint di rete e un modello vicini a loro. Senza un gateway, i client devono selezionare automaticamente quali endpoint di distribuzione del modello usare e quali credenziali sono necessarie per tale API del piano dati Foundry specifico.

Solution

Scaricare un file di Visio di questa architettura.

Per affrontare le criticità legate all'esposizione diretta ai consumatori delle API del piano dati di Foundry Models, è possibile introdurre un gateway di reverse proxy per disaccoppiare l'applicazione intelligente da Foundry. Il pattern Gateway Offloading sottrae ai client la responsabilità, la complessità e l'osservabilità. Offre l'opportunità di aumentare Foundry fornendo altre funzionalità che non sono integrate. Tali funzionalità includono:

• Potenziale implementazione autenticazione federata.

• Possibilità di controllare la pressione sui modelli attraverso la limitazione della velocità.

• Monitoraggio trasversale e intermodello.

• Possibilità di introdurre l'aggregazione del gateway e il routing avanzato del gateway a più servizi, ad esempio il routing di messaggi con priorità bassa a una coda per il livellamento del carico basato sulla coda o per calcolare le risorse per gestire le attività.

• Bilanciamento del carico che usa il monitoraggio degli endpoint di stato per instradare solo verso gli endpoint sani interrompendo il circuito in distribuzioni di modelli indisponibili o sovraccariche.

• Strategie di memorizzazione nella cache per migliorare le prestazioni e l'ottimizzazione dei costi.

Per alcuni scenari specifici sono disponibili altre indicazioni che indirizzano direttamente un gateway API e Foundry. Questi scenari sono elencati nella sezione Passaggi successivi.

Considerazioni

Queste considerazioni implementano i pilastri di Well-Architected Framework, ovvero un set di set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Decidere di aggiungere un gateway nell’ambito della progettazione dell'applicazione, come descritto nelle linee guida del Well-Architected Framework AI workloads on Azure. In qualità di architetto, è necessario decidere se includere questo componente.

Quando si introduce un nuovo componente nell'architettura, è necessario valutare i compromessi introdotti di recente. Quando si inserisce un gateway API tra i client e il piano dati Foundry, 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.

Reliability

L'affidabilità garantisce che l'applicazione possa soddisfare 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 può derivare dalla disponibilità del servizio della piattaforma gateway, dalle interruzioni a causa di distribuzioni di codice o configurazione o persino da endpoint API critici configurati in modo errato nel gateway. 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 includendo il gateway nell'analisi delle modalità di guasto del carico di lavoro durante l'implementazione.

• La soluzione potrebbe richiedere funzionalità di routing globali se l'architettura richiede istanze di risorse Foundry in più aree per aumentare la disponibilità degli endpoint Foundry, ad esempio la possibilità di continuare a gestire le richieste durante un'interruzione a livello di area. Questo requisito aggiunge complessità della topologia, inclusi nomi di dominio completi aggiuntivi, certificati TLS e infrastruttura di routing globale da gestire.

Sicurezza

La sicurezza fornisce protezioni contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

• L'aggiunta di un gateway espande la superficie di attacco del carico di lavoro. Ogni nuova risorsa Azure richiede la propria configurazione di gestione delle identità e degli accessi (IAM), la protezione avanzata e la manutenzione continua della sicurezza.

• Il gateway può fungere da transizione di limiti di rete tra lo spazio di rete client e lo spazio di rete foundry privato. Anche se il gateway rende privato un endpoint Foundry con connessione Internet precedente usando collegamento privato di Azure, il gateway diventa il nuovo punto di ingresso e deve essere adeguatamente protetto.

• Un gateway è in una posizione unica per vedere i dati delle richieste non elaborati e le risposte formulate dal modello linguistico, che potrebbero includere dati riservati provenienti da entrambe le fonti. La conformità dei dati e l'ambito normativo ora riguardano questo altro componente.

• Un gateway può ampliare l'ambito dell'autorizzazione e dell'autenticazione dei client oltre a Microsoft Entra ID e all'autenticazione tramite chiave API, e potenzialmente attraverso più fornitori di identità (IdP).

• La sovranità dei dati deve essere inserita nelle implementazioni in più aree. Assicurati che le capacità di elaborazione del gateway e la logica di instradamento soddisfino i requisiti di sovranità imposti al tuo carico di lavoro.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui 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 comportano costi di runtime che aumentano man mano che si aggiungono funzionalità di affidabilità, sicurezza e prestazioni. L'introduzione della gestione apiOps aumenta anche i costi operativi. Valutare i costi rispetto al valore restituito dal gateway. L'obiettivo è un compromesso netto positivo in cui le funzionalità del gateway giustificano l'investimento di implementazione e manutenzione. In alcuni scenari, è possibile compensare i costi addebitando l'utilizzo ai consumatori.

Per gestire i costi durante lo sviluppo e il test di un gateway, è consigliabile usare un endpoint simulato per i modelli Foundry. Ad esempio, usare la soluzione nel repository GitHub del simulatore API di Azure OpenAI.

Implementare strategie di memorizzazione nella cache nel gateway per ottimizzare i costi. La memorizzazione nella cache consente di ridurre il numero di chiamate effettuate a Foundry, che consente di risparmiare sui costi, in particolare per i dati a cui si accede di frequente o le richieste comuni. Tuttavia, è necessario progettare attentamente le strategie di memorizzazione nella cache per assicurarsi che non vengano usati dati non aggiornati o interferiscano con i requisiti di aggiornamento del carico di lavoro.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per ulteriori informazioni, vedere Lista di controllo per la revisione del design per l'Eccellenza Operativa.

• La soluzione di monitoraggio del carico di lavoro deve includere il gateway. In alcuni casi, i client potrebbero anche dover monitorare il gateway. È necessario includere le risorse di calcolo e le operazioni del gateway nella modellazione dello stato di integrità del carico di lavoro.

• Le procedure di distribuzione sicure devono affrontare la distribuzione dell'infrastruttura del gateway API e il codice o la configurazione del routing del gateway. La soluzione di automazione dell'infrastruttura e dell'infrastruttura come codice (IaC) deve stabilire come trattare il gateway come una risorsa di lunga durata all'interno del carico di lavoro.

• È necessario compilare o estendere l'approccio APIOps per coprire le API esposte nel gateway.

• Alcune funzionalità del gateway si sovrappongono alle funzionalità già integrate in Azure ai Services di intelligenza artificiale o alla distribuzione del carico della zona dati Foundry.

Efficienza prestazionale

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

• Il servizio gateway potrebbe introdurre un collo di bottiglia nel throughput. 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.

• Il servizio gateway deve eseguire processi per ogni richiesta e introduce una latenza aggiuntiva per ogni chiamata API. Ottimizzare la logica di routing per mantenere le richieste veloci e affidabili.

• Nella maggior parte dei casi, il gateway deve essere geograficamente vicino sia agli utenti che alle istanze delle risorse Foundry per ridurre la latenza. La latenza di rete è in genere una piccola percentuale di tempo nelle chiamate API complessive ai modelli linguistici, ma potrebbe essere un fattore competitivo per il carico di lavoro.

• Il servizio gateway potrebbe influire sulle funzionalità foundry che dipendono da connessioni persistenti o dal comportamento con stato. Ad esempio, le risposte di streaming richiedono al gateway di supportare connessioni di lunga durata senza timeout prematuri o buffering. Le interazioni con stato, ad esempio l'API Risposte, richiedono al gateway di mantenere l'affinità di sessione in modo che le richieste successive dalla stessa sessione vengano instradate alla stessa istanza back-end. Assicurarsi che l'implementazione del gateway supporti queste funzionalità quando il carico di lavoro si basa su di essi.

• Valutare le strategie di memorizzazione nella cache che è possibile implementare nel gateway per migliorare le prestazioni e l'ottimizzazione dei costi.

Opzioni di implementazione

Foundry offre la possibilità di configurare un gateway di intelligenza artificiale, supportato da Gestione API di Azure e integrato in modo nativo nel portale foundry. Questo gateway è progettato per supportare l'ingresso a una singola risorsa Foundry e non si estende su più risorse. I team del carico di lavoro possono anche implementare il proprio gateway usando un'istanza autonoma di Gestione API o una soluzione gateway personalizzata.

Usare Gestione API di Azure

Foundry ha un'integrazione predefinita con Gestione API come gateway di intelligenza artificiale. È possibile usare Gestione API integrata con Foundry o usare Gestione API come gateway autonomo.

Gestione API è un servizio gestito dalla piattaforma progettato per l'offload di problematiche trasversali per le API basate su HTTP. La gestione delle API include funzionalità di gateway AI. Gestione API è basata sulla configurazione e supporta la personalizzazione tramite il sistema di criteri di elaborazione delle richieste in ingresso e in uscita. Supporta repliche ad alta disponibilità, con ridondanza della zona e persino in più aree, tramite un unico piano di controllo.

La maggior parte del routing del gateway, la sicurezza, la memorizzazione nella cache e la logica di gestione delle richieste deve essere implementata nel sistema dei criteri di Gestione API. È possibile combinare criteri predefiniti specifici per l'intelligenza artificiale, ad esempio limitare l'utilizzo di token API del modello linguistico di grandi dimensioni, generare metriche per l'utilizzo di token del modello linguistico di grandi dimensioni, applicare la sicurezza del contenuto o memorizzare nella cache le risposte e modificare i propri criteri personalizzati. Il repository GitHub dei laboratori di AI Gateway contiene diversi criteri personalizzati di API Management, oltre a strumenti per testare il comportamento dei criteri.

Quando si progetta una soluzione che coinvolge Gestione API, usare le procedure consigliate per l'architettura.

L'uso di Gestione API per l'implementazione del gateway è in genere l'approccio preferito per la creazione e l'uso di un gateway Foundry. È preferibile perché il servizio è una piattaforma distribuita come servizio (PaaS) che offre funzionalità predefinite avanzate, disponibilità elevata e opzioni di rete. Offre anche solidi approcci APIOps per gestire le 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 autogestita per la gestione della logica del gateway può essere adatta ai team responsabili del carico di lavoro esperti nella gestione del codice di routing e rete.

Il carico di lavoro può in genere usare le risorse di calcolo con cui hanno familiarità, ad esempio l'hosting del codice del gateway in Servizio app di Azure, App contenitore di Azure o Servizio Azure Kubernetes (AKS).

Le distribuzioni di codice personalizzato possono anche essere poste dietro API Management quando questo viene usato esclusivamente per le sue funzionalità di base di gateway API HTTP tra i client e il codice personalizzato. In questo approccio, le interfacce di codice personalizzate si basano esclusivamente sulle API HTTP Foundry in base alla logica di business necessaria.

L'uso della tecnologia gateway non Microsoft può essere considerato come parte di questo approccio.

Architettura di esempio

Scaricare un file di Visio di questa architettura.

Passaggi successivi

Gli articoli seguenti illustrano scenari specifici in cui la distribuzione di un gateway tra un'applicazione intelligente e le distribuzioni di Azure Foundry soddisfa i requisiti del carico di lavoro:

• Usare un gateway davanti a più distribuzioni o istanze di modelli
• Fornire l'autenticazione personalizzata ai modelli Foundry tramite un gateway
• Implementare il monitoraggio avanzato per i modelli Foundry tramite un gateway

Risorse correlate

• API Gateway in Gestione delle API di Azure
• Zona di destinazione di Gestione API
• Laboratori di AI Gateway per la gestione API
• Simulatore API di Azure OpenAI
• Zona di atterraggio dell'hub gateway AI