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

Questo articolo descrive le sfide principali tra i cinque pilastri di Azure Well-Architected Framework che si verificano quando il carico di lavoro consente ai consumer di accedere direttamente alle API del piano dati Foundry Models. Spiega come l'introduzione di un gateway può aiutare a risolvere queste sfide, introducendo anche nuove considerazioni. L'attenzione è sul modello architetturale, non sui dettagli di 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 Linee guida per scenari specifici, che includono un esempio di utilizzo del gateway.

Sfide principali

Senza un gateway API o la possibilità di aggiungere logica alle API Foundry, il client deve gestire la logica del client 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 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 problemi di architettura chiave specifici che possono verificarsi se l'architettura supporta solo l'accesso diretto ai modelli Foundry dai consumer. Le sfide sono organizzate usando i pilastri 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à 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.

  Indipendentemente dal fatto che si usi Globale, standard o con provisioning, oppure zona dati, standard o con provisioning, non influisce sulla disponibilità delle risorse Foundry dal punto di vista della disponibilità regionale dell'endpoint. Si ha comunque la responsabilità di implementare manualmente la logica di failover.

• Aumentare il numero di istanze per gestire i picchi: Passare automaticamente alle istanze del modello Foundry con capacità disponibile quando la capacità originale è satura è un'altra responsabilità del client che deve essere controllata tramite configurazione e logica personalizzata. L'aggiornamento di più configurazioni client per le nuove istanze del modello Foundry 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 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 distribuzioni globali e di zone dati di modelli. Queste distribuzioni utilizzano la capacità dei modelli nei data center, che hanno una capacità sufficiente per gestire ogni richiesta. L'uso di distribuzioni globali e di zone dati riduce significativamente la limitazione del servizio senza la complessità aggiuntiva dei gateway personalizzati. Le distribuzioni globali e delle zone di dati sono di per 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à 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 identità - ambito di autenticazione: Le API del piano dati esposte da Foundry possono essere protette in uno dei due modi seguenti: chiave API o controllo degli accessi in base al ruolo 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, che introduce complessità per fornire accesso con privilegi minimi e segmentazione delle identità per modelli di distribuzione specifici.

• Identity management - Identity providers: Client che non possono usare identità che si trovano nel tenant Microsoft Entra che esegue il backup dell'istanza della risorsa Foundry 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 della posizione client relativa alle istanze delle risorse Foundry, potrebbe essere necessario l'accesso a Internet pubblico ai modelli linguistici.

• Sovranità dei dati: La sovranità dei dati nel contesto di Foundry è costituita dai requisiti normativi relativi all'archiviazione e all'elaborazione dei dati in un paese o 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 include più istanze di risorse Foundry.

  È necessario tenere presente che, quando si utilizzano distribuzioni di modelli global o area dati Foundry, 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, il tracciamento dei costi erogati o per singolo cliente può essere realizzato in modo autoritativo esclusivamente mediante l'aggregazione della 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 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 preconfigurati prima di passare a 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 quota: I client ricevono codici di risposta 429 direttamente da Foundry 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 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, la logica deve essere gestita 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: 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. Ad esempio, i client possono assicurarsi che max_tokens e best_of siano impostati su valori approvati. Senza un gateway, è necessario affidarsi ai client affinché agiscano nel miglior interesse di preservare la capacità del tuo modello Foundry.

• Ridurre al minimo la latenza: Sebbene la latenza di rete sia in genere un piccolo componente del flusso complessivo delle richieste e dei completamenti, assicurarsi che i client vengano indirizzati a un endpoint di rete e a un modello vicino a loro potrebbe essere vantaggioso. Senza un gateway, i client devono selezionare automaticamente gli endpoint di distribuzione del modello da usare e quali credenziali sono necessarie per tale API del piano dati Foundry specifico.

Soluzione

Per risolvere le numerose sfide elencate in Sfide chiave, è possibile inserire un gateway proxy inverso per separare l'applicazione intelligente da Foundry. Questo scaricamento del gateway consente di spostare responsabilità, complessità e osservabilità lontano dai client software e dà l'opportunità di potenziare Foundry fornendo altre funzionalità che non sono integrate. Alcuni esempi sono:

• 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 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

La decisione di aggiungere un gateway e quale tecnologia usare viene presa come parte della progettazione Application descritta nelle linee guida per i carichi di lavoro di AI su Azure del Framework di Azure Well-Architected. In qualità di architetto, è necessario decidere di includere o escludere questo componente.

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 Foundry per risolvere qualsiasi delle sfide principali, 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 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. Questa situazione può complicare ulteriormente la topologia tramite la gestione di nomi di dominio completi aggiuntivi, certificati TLS e altri componenti di routing globali.

Sicurezza

Quando si valuta il modo in cui un gateway API offre vantaggi all'architettura, utilizzare la lista di controllo di revisione della progettazione per la sicurezza per valutare la progettazione. È necessario affrontare le considerazioni di sicurezza seguenti:

• La superficie del carico di lavoro viene aumentata con l'aggiunta del gateway. Questa superficie di attacco porta a considerazioni aggiuntive nella gestione delle identità e degli accessi (IAM) delle risorse Azure, a una maggiore intensificazione delle misure di rafforzamento e molto altro.

• 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, ora 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 sono ora estesi a 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. Assicuratevi che la logica di calcolo e di routing del gateway rispetti i requisiti di sovranità applicati al vostro carico di lavoro.

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 tra il carico di lavoro e gli utenti, potrebbe essere possibile ricaricare l'utilizzo.

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.

Le strategie di memorizzazione nella cache possono essere implementate 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, le strategie di memorizzazione nella cache devono essere progettate attentamente per garantire che non vengano usati dati non aggiornati o interferiscano con i requisiti di aggiornamento del carico di lavoro.

Eccellenza operativa

Quando si considera come il gateway API offra vantaggi all'architettura, utilizzare il Design review checklist for Operational Excellence per valutare il progetto. È necessario affrontare le considerazioni di eccellenza operativa seguenti:

• Il gateway stesso deve essere monitorato dalla soluzione di monitoraggio del carico di lavoro e potenzialmente dai client. Ciò significa che il calcolo e le operazioni 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 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.

• È possibile duplicare le funzionalità disponibili tramite soluzioni quali la risorsa di servizi di intelligenza artificiale Azure o la funzionalità di distribuzione del carico della zona dati Foundry.

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 affrontare le considerazioni seguenti sull'efficienza delle prestazioni:

• 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'approvvigionamento o ridurre la capacità quando la domanda è bassa, ad esempio durante i giorni lavorativi.

• 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. 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.

• Il servizio gateway può 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 della 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 possono essere implementate nel gateway per migliorare le prestazioni e l'ottimizzazione dei costi.

Opzioni di implementazione

Foundry offre la possibilità di enable an AI Gateway, 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 viene usato per estendersi su più risorse. I team del carico di lavoro possono anche implementare il proprio gateway usando un'istanza autonoma Gestione API di Azure o una soluzione gateway personalizzata.

Usare Gestione API di Azure

Foundry ha integrazione integrata con Gestione API di Azure come gateway di intelligenza artificiale. È possibile sfruttare Gestione API integrata con Foundry o usare Gestione API come gateway autonomo.

Gestione API di Azure è 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. È 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 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, Creare metriche per l'utilizzo di token di modelli linguistici di grandi dimensioni, Applicare la sicurezza del contenuto o memorizzare nella cache le risposte e i propri criteri personalizzati. Il repository GitHub del kit gateway GenAI contiene diversi criteri di gestione API personalizzati, insieme a una configurazione di test di carico per verificare il comportamento di tali criteri.

Usare la guida al servizio Well-Architected Framework per Gestione API durante la progettazione di una soluzione che coinvolge Gestione API di Azure.

L'uso di Gestione API di Azure per l'implementazione del gateway è in genere l'approccio preferito per la creazione e l'uso di un gateway Foundry. È 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 di applicazioni Azure 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.

Le distribuzioni di codice personalizzate possono anche essere gestite tramite API Management quando viene utilizzato esclusivamente per le sue capacità principali di gateway API HTTP tra i client e il codice personalizzato. In questo modo, le interfacce di codice personalizzate vengono eseguite esclusivamente con le API HTTP Foundry 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

Passaggi successivi

Informazioni su uno scenario specifico in cui la distribuzione di un gateway tra un'applicazione intelligente e le distribuzioni di Azure Foundry 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
• Implementare il logging e il monitoraggio per i modelli di Azure OpenAI

Risorse correlate

• Gateway API in Gestione API di Azure
• Area di destinazione di Gestione API GitHub che copre gli scenari di intelligenza artificiale generativi
• API Management Gateway Toolkit
• Simulatore di API OpenAI
• Zona di atterraggio dell'hub gateway AI