Gateway applicativo per i contenitori - Gateway di inferenza

I carichi di lavoro di inferenza di intelligenza artificiale non si comportano come le tradizionali applicazioni HTTP senza stato. Le richieste sono spesso specifiche del modello, a esecuzione prolungata, costose da gestire e sensibili ai segnali di runtime, ad esempio la disponibilità dell'acceleratore, la profondità della coda, la priorità delle richieste, il budget del token e la capacità del server modello.

Application Gateway for Containers inference gateway supporta questi carichi di lavoro integrandosi con l'estensione di inferenza dell'API Gateway di Kubernetes, che aggiunge al modello dell'API Gateway risorse compatibili con l'inferenza. Utilizzando l'inference gateway, è possibile esporre server di modelli ospitati autonomamente tramite Application Gateway for Containers con comportamento di instradamento basato sul modello e sul carico.

Il gateway di inferenza è progettato appositamente per gestire modelli di linguaggio di grandi dimensioni e altri carichi di lavoro di inferenza. Instrada le richieste in base ai segnali del server modello anziché al bilanciamento del carico generico, riducendo il tempo al primo token (TTFT), riducendo i timeout sotto carico e migliorando l'efficienza della GPU. Basato sulle funzionalità in ingresso di Gateway applicazione per contenitori, il gateway di inferenza consente anche di abbinare i carichi di lavoro di IA a funzionalità come il web application firewall (WAF) per proteggere il traffico prima che raggiunga i server dei modelli.

Molti runtime di inferenza ospitati autonomamente, tra cui vLLM, espongono API HTTP compatibili con quelle di OpenAI, come /v1/chat/completions, /v1/completions e /v1/models. OpenAI-compatible si riferisce al formato API, non a una restrizione per i modelli ospitati da OpenAI. Se un'altra famiglia di modelli viene esposta tramite un runtime o un proxy che utilizza questo formato, Application Gateway for Containers può usare il campo model nel corpo della richiesta JSON per l'instradamento basato sul corpo della richiesta.

Cosa offre l'estensione Inference di Gateway API

L'estensione Inference di Gateway API trasforma un'implementazione di Gateway API in un gateway di inferenza aggiungendo concetti di backend e di pianificazione specifici per l'inferenza.

L'estensione introduce le risorse e i componenti principali seguenti:

• InferencePool: una risorsa di back-end che rappresenta un gruppo di pod di server di modelli e il selettore di endpoint utilizzato per selezionare un pod per ogni richiesta di inferenza.
• InferenceObjective: una risorsa che rappresenta gli obiettivi di gestione delle richieste, ad esempio priorità, per le richieste che condividono un InferencePool.
• Endpoint Picker (EPP): estensione fornita dal cliente che viene eseguita nel cluster e implementa la pianificazione dell'inferenza. L'EPP riceve i metadati della richiesta, assegna punteggi ai pod del server modello candidato usando plug-in configurabili (ad esempio, profondità della coda, utilizzo della cache KV e affinità di cache del prefisso) e restituisce l'endpoint selezionato. Poiché la selezione degli endpoint viene eseguita nell'EPP, i comportamenti di routing disponibili dipendono dai plug-in del punteggio abilitati dall'EPP.
• Instradamento basato sul corpo (BBR): Un processore di richieste in grado di esaminare un corpo della richiesta compatibile con OpenAI, estrarre il nome del modello e renderlo disponibile al gateway come intestazione X-Gateway-Model-Name per l'instradamento basato sul modello.

Gateway applicazione per contenitori esegue il processore BBR come parte gestita del gateway, quindi non è necessario un livello separato di routing basato sul corpo della richiesta da distribuire, scalare o aggiornare. Si integra con un EPP fornito dal cliente per supportare le decisioni di routing in fase di richiesta. Il gateway di inferenza supporta la Gateway API Inference Extension API, quindi è possibile configurare queste funzionalità tramite risorse standard della Gateway API e i team della piattaforma possono usare un modello API nativo per Kubernetes per il traffico di inferenza anziché introdurre un modello di configurazione Ingress separato.

Come Application Gateway for Containers utilizza le risorse di inferenza

Application Gateway for Containers continua a usare le risorse standard di Gateway API per la configurazione dell'ingresso. Il comportamento di inferenza viene attivato quando un riferimento al backend HTTPRoute punta a un InferencePool anziché a un Kubernetes Service.

Per le route non di inferenza, Application Gateway for Containers mantiene il comportamento esistente di Gateway API. Le route destinate ai back-end Kubernetes Service non chiamano processori di inferenza e non ricevono un comportamento di routing specifico per l'inferenza.

Per le route di inferenza, il control plane riconcilia le risorse della Gateway API e quelle di inferenza e configura il data plane in modo che:

• Il HTTPRoute seleziona il backend InferencePool.
• InferencePool seleziona i pod del server dei modelli che appartengono al pool.
• L'EPP associato al pool viene richiamato per la selezione dell'endpoint.
• L'endpoint server del modello selezionato riceve la richiesta.
• Il routing facoltativo compatibile con il modello usa il nome del modello di richiesta estratto da BBR.

Flusso di richiesta

Una tipica richiesta di inferenza segue questo percorso. I passaggi numerati corrispondono alle etichette nel diagramma seguente:

1. Richiesta client: un client invia una richiesta compatibile con OpenAI al front-end del gateway applicazione per contenitori e il listener del gateway lo accetta.
2. Routing basato sul corpo (BBR): per le route compatibili con il modello, il processore BBR gestito controlla il corpo della richiesta, estrae il nome del modello e inserisce l'intestazione X-Gateway-Model-Name . Il HTTPRoute può quindi trovare una corrispondenza in base a quel valore per selezionare il InferencePool appropriato.
3. Selezione dell'endpoint: quando la route corrispondente ha come destinazione un InferencePool, Application Gateway for Containers richiama l'EPP, che valuta la richiesta e la telemetria del server del modello e restituisce l'endpoint selezionato.
4. Instradamento verso InferencePool: Application Gateway for Containers inoltra la richiesta al pod del server di modelli selezionato e la risposta del server di modelli viene restituita al client tramite il gateway.

Funzionalità di routing

Il gateway d'inferenza supporta questi schemi di instradamento per i carichi di lavoro di IA ospitati autonomamente. La selezione degli endpoint viene eseguita nell'EPP, quindi i comportamenti basati sul carico e sulla cache dipendono dai plug-in di valutazione che il tuo EPP abilita.

• Instradamento basato sul modello: Instrada le richieste in base al nome del modello nei corpi delle richieste compatibili con OpenAI, che il processore BBR gestito estrae.
• Suddivisione del traffico e implementazioni: usare lo standard HTTPRoute ponderato backendRefs per suddividere il traffico tra InferencePool back-end per le implementazioni di modelli canary o blu-verde.
• Selezione dell'endpoint compatibile con il carico e compatibile con la cache: l'EPP assegna punteggi agli endpoint usando i dati di telemetria del server modello, ad esempio la profondità della coda e l'utilizzo della cache KV. Quando EPP abilita il calcolo del punteggio basato sulla prefix cache, le richieste che condividono un prefisso del prompt vengono inoltrate alla stessa replica per aumentare i cache hit e ridurre il TTFT.
• Priorità delle richieste e protezione dal sovraccarico: usa le risorse InferenceObjective e l'intestazione di richiesta x-gateway-inference-objective per assegnare la priorità di elaborazione. Quando i server modello sono saturi, EPP elimina prima le richieste con priorità inferiore per proteggere il traffico critico per latenza.
• Selezione dell'endpoint resiliente: configurare il comportamento degli errori EPP con FailOpen o FailClose, a seconda che la disponibilità o la selezione rigorosa degli endpoint sia più importante per un pool.
• Compatibilità con l'API Gateway: continuare a utilizzare Gateway, HTTPRoute, ReferenceGrant e le condizioni di stato standard dell'API Gateway per la configurazione dell'ingresso.

Inferenza sicura

Mantieni privati i server del modello dietro il gateway gestito e applica le funzionalità di sicurezza della piattaforma al traffico di inferenza.

• Web application firewall (WAF): il gateway di inferenza si integra nativamente con la funzionalità WAF esistente in Application Gateway for Containers, applicando protezioni in linea con OWASP al traffico AI prima che le richieste raggiungano i server del modello.
• Protezione per backend ad alto costo: poiché le policy vengono applicate all’edge gestito, le richieste malformate o abusive possono essere ispezionate e bloccate prima di consumare la preziosa capacità GPU.

Scenari di esempio

Gli scenari seguenti illustrano i modi comuni per usare il gateway di inferenza:

• Pubblicare e implementare versioni del modello: instradare le richieste compatibili con OpenAI verso un InferencePool in base al nome del modello, quindi usare backendRefs ponderati HTTPRoute per deviare una percentuale del traffico verso una nuova versione del modello per test canary prima di completare la distribuzione.
• Classificare in ordine di priorità il traffico critico per latenza: definire le InferenceObjective risorse per carichi di lavoro con priorità alta e bassa in un pool condiviso. Le richieste di chat interattive hanno priorità alta, mentre i processi batch usano una priorità inferiore, che viene sacrificata per prima quando il pool è saturo.

InferencePool confrontato con il servizio

Un Kubernetes Service rimane la giusta astrazione di backend per il traffico applicativo standard. Usare un InferencePool quando il back-end è un gruppo di pod di server dei modelli che richiedono la selezione di un endpoint specifico per l'inferenza.

Un InferencePool include un selettore di pod, informazioni sulla porta di destinazione e un riferimento al selettore di endpoint. L'EPP è responsabile della selezione dell'endpoint per una richiesta. Un singolo EPP è associato a un singolo pool.

Comportamento in caso di guasto

Il routing dell'inferenza è un comportamento che si verifica al momento della richiesta, quindi la modalità di errore del selettore di endpoint è importante.

InferencePool I riferimenti al selettore di endpoint supportano queste modalità di errore:

• FailOpen: se l'EPP non è disponibile o non risponde, il gateway può continuare con la selezione standard dell'endpoint per il pool. Questa scelta mantiene la disponibilità, ma potrebbe ridurre la qualità del routing.
• FailClose: se EPP non è disponibile o non risponde, il gateway rifiuta la richiesta. Questa scelta impedisce l'invio del traffico senza la decisione di selezione dell'endpoint necessaria.

Per il routing basato sul modello che dipende dall'analisi del corpo della richiesta, Application Gateway for Containers privilegia la correttezza. Se il nome del modello non può essere estratto per una route che richiede BBR, la richiesta viene rifiutata invece di essere instradata automaticamente al back-end del modello errato.

Considerazioni operative

Pianifica le considerazioni seguenti quando esegui carichi di lavoro di inferenza dietro Application Gateway for Containers:

• Capacità EPP: l'EPP si trova nel percorso di richiesta per i back-endInferencePool. Ridimensionarlo e monitorarlo come un componente critico dell'applicazione.
• Telemetria del server modello: EPP necessita di nuove metriche del server del modello per prendere decisioni di routing di alta qualità. Verificare che il server modello supporti le metriche previste dalla configurazione EPP.
• Capacità e pianificazione GPU: i pod del server modello spesso richiedono pool di nodi GPU, plug-in del dispositivo e credenziali di download del modello.
• Scalabilità automatica: dimensiona automaticamente i pod del server del modello in base a segnali di inferenza, come la lunghezza della coda e l'utilizzo della cache KV, usando l'Horizontal Pod Autoscaler o KEDA. La scalabilità automatica aggiunge capacità man mano che aumenta la domanda, mentre il processo EPP instrada le repliche già sature.
• Risposte in streaming: molti scenari di completamento della chat usano eventi inviati dal server. Verificare il comportamento dello streaming quando si testano la latenza end-to-end e le impostazioni di timeout.
• Osservabilità: monitorare lo stato del gateway e HTTPRoute, lo stato di InferencePool, l'integrità EPP, l'idoneità del server modello e le metriche del server del modello, ad esempio richieste attive e profondità della coda.

Limitations

Il gateway di inferenza si concentra sui carichi di lavoro di inferenza autogestiti eseguiti su Kubernetes. Il routing diretto agli endpoint del provider di modelli pubblici o gestiti non rientra nell'ambito di questa integrazione.

L'estensione Gateway API Inference si evolve in modo indipendente da Application Gateway for Containers. Usare le versioni API e i manifest corrispondenti ai CRD dell'estensione di inferenza installati sul cluster.

Passaggi successivi

• Configurare il gateway di inferenza di Application Gateway for Containers
• Componenti del gateway applicazione per contenitori
• Documentazione dell'estensione di inferenza di Gateway API