Questa pagina spiega i concetti e le funzionalità chiave di Google Kubernetes Engine (GKE) Inference Gateway, un'estensione di GKE Gateway per la pubblicazione ottimizzata di applicazioni di AI generativa.
Questa pagina presuppone che tu conosca quanto segue:
- Orchestrazione di AI/ML su GKE.
- Terminologia dell'AI generativa.
- Concetti di networking GKE, inclusi i servizi e l'API GKE Gateway.
- Bilanciamento del carico in Trusted Cloud, in particolare come i bilanciatori del carico interagiscono con GKE.
Questa pagina è rivolta ai seguenti utenti tipo:
- Ingegneri del machine learning (ML), amministratori e operatori della piattaforma e specialisti di dati e AI interessati a utilizzare le funzionalità di orchestrazione dei container Kubernetes per la gestione dei carichi di lavoro di AI/ML.
- Architetti cloud e specialisti di networking che interagiscono con il networking Kubernetes.
Panoramica
GKE Inference Gateway è un'estensione di GKE Gateway che fornisce routing e bilanciamento del carico ottimizzati per la gestione dei carichi di lavoro di intelligenza artificiale (AI) generativa. Semplifica il deployment, la gestione e l'osservabilità dei carichi di lavoro di inferenza AI.
Funzionalità e vantaggi
GKE Inference Gateway fornisce le seguenti funzionalità chiave per gestire in modo efficiente i modelli di AI generativa per le applicazioni di AI generativa su GKE:
- Bilanciamento del carico ottimizzato per l'inferenza: distribuisce le richieste per
ottimizzare le prestazioni di serving del modello di AI. Utilizza metriche dei server dei modelli, come
KVCache Utilization
equeue length of pending requests
, per utilizzare gli acceleratori (come GPU e TPU) in modo più efficiente per i carichi di lavoro di AI generativa. - Distribuzione del modello sottoposto a fine-tuning LoRA dinamico: supporta la distribuzione di modelli sottoposti a fine-tuning LoRA dinamico su un acceleratore comune. In questo modo si riduce il numero di GPU e TPU necessarie per pubblicare i modelli eseguendo il multiplexing di più modelli LoRA sottoposti a fine tuning su un modello di base e un acceleratore comuni.
- Scalabilità automatica ottimizzata per l'inferenza: GKE Horizontal Pod Autoscaler (HPA) utilizza le metriche del server del modello per la scalabilità automatica, il che contribuisce a garantire un utilizzo efficiente delle risorse di calcolo e prestazioni di inferenza ottimizzate.
- Routing basato sul modello: esegue il routing delle richieste di inferenza in base ai nomi dei modelli
definiti nelle specifiche
OpenAI API
all'interno del cluster GKE. Puoi definire criteri di routing del gateway, come la suddivisione del traffico e il mirroring delle richieste, per gestire diverse versioni del modello e semplificare i rollout dei modelli. Ad esempio, puoi indirizzare le richieste per un nome di modello specifico a diversi oggettiInferencePool
, ognuno dei quali serve una versione diversa del modello. - Pubblicazione specifica per modello
Criticality
: consente di specificare la pubblicazioneCriticality
dei modelli di AI. Dai la priorità alle richieste sensibili alla latenza rispetto ai job di inferenza batch tolleranti alla latenza. Ad esempio, puoi dare la priorità alle richieste delle applicazioni sensibili alla latenza ed eliminare le attività meno sensibili al fattore tempo quando le risorse sono limitate. - Sicurezza dell'AI integrata: si integra con Trusted Cloud Model Armor, un servizio che applica controlli di sicurezza dell'AI a prompt e risposte al gateway. Model Armor fornisce log di richieste, risposte ed elaborazione per analisi e ottimizzazione retrospettive. Le interfacce aperte di GKE Inference Gateway consentono a fornitori e sviluppatori di terze parti di integrare servizi personalizzati nel processo di richiesta di inferenza.
- Osservabilità dell'inferenza: fornisce metriche di osservabilità per le richieste di inferenza, come tasso di richieste, latenza, errori e saturazione. Monitora le prestazioni e il comportamento dei tuoi servizi di inferenza.
Comprendere i concetti chiave
GKE Inference Gateway migliora il GKE
Gateway esistente che utilizza
oggetti
GatewayClass
. GKE Inference Gateway introduce le seguenti nuove
definizioni di risorse personalizzate (CRD) dell'API Gateway, in linea con l'estensione dell'API Gateway Kubernetes OSS per
l'inferenza:
- Oggetto
InferencePool
: rappresenta un gruppo di pod (container) che condividono la stessa configurazione di calcolo, lo stesso tipo di acceleratore, lo stesso modello linguistico di base e lo stesso server di modelli. che raggruppa e gestisce logicamente le risorse di servizio del modello di AI. Un singolo oggettoInferencePool
può estendersi su più pod in diversi nodi GKE e offre scalabilità e alta disponibilità. - Oggetto
InferenceModel
: specifica il nome del modello di pubblicazione daInferencePool
in base alla specificaOpenAI API
. L'oggettoInferenceModel
specifica anche le proprietà di pubblicazione del modello, ad esempioCriticality
del modello di AI. GKE Inference Gateway dà la precedenza ai workload classificati comeCritical
. In questo modo puoi eseguire il multiplexing di carichi di lavoro AI sensibili alla latenza e tolleranti alla latenza su un cluster GKE. Puoi anche configurare l'oggettoInferenceModel
per pubblicare modelli ottimizzati con LoRA. - Oggetto
TargetModel
: specifica il nome del modello di destinazione e l'oggettoInferencePool
che pubblica il modello. In questo modo puoi definire i criteri di routing del gateway, come la suddivisione del traffico e il mirroring delle richieste, e semplificare l'implementazione delle versioni del modello.
Il seguente diagramma illustra GKE Inference Gateway e la sua integrazione con la sicurezza dell'AI, l'osservabilità e la pubblicazione di modelli all'interno di un cluster GKE.

Il seguente diagramma illustra il modello di risorse incentrato su due nuove figure basate sull'inferenza e sulle risorse che gestiscono.

Come funziona GKE Inference Gateway
GKE Inference Gateway utilizza le estensioni dell'API Gateway e la logica di routing specifica del modello per gestire le richieste dei client a un modello di AI. I passaggi seguenti descrivono il flusso della richiesta.
Come funziona il flusso di richieste
GKE Inference Gateway instrada le richieste client dalla richiesta iniziale a un'istanza del modello. Questa sezione descrive come GKE Inference Gateway gestisce le richieste. Questo flusso di richieste è comune a tutti i client.
- Il client invia una richiesta, formattata come descritto nella specifica dell'API OpenAI, al modello in esecuzione in GKE.
- GKE Inference Gateway elabora la richiesta utilizzando le seguenti
estensioni di inferenza:
- Estensione di routing basata sul corpo: estrae l'identificatore del modello dal corpo della richiesta del client e lo invia a GKE Inference Gateway.
GKE Inference Gateway utilizza quindi questo identificatore per instradare la richiesta in base alle regole definite nell'oggetto
HTTPRoute
dell'API Gateway. Il routing del corpo della richiesta è simile al routing basato sul percorso dell'URL. La differenza è che il routing del corpo della richiesta utilizza i dati del corpo della richiesta. - Estensione di sicurezza: utilizza Model Armor o soluzioni di terze parti supportate per applicare norme di sicurezza specifiche del modello che includono filtraggio dei contenuti, rilevamento delle minacce, sanificazione e logging. L'estensione di sicurezza applica queste norme ai percorsi di elaborazione sia delle richieste sia delle risposte. Ciò consente all'estensione di sicurezza di sanificare e registrare sia le richieste che le risposte.
- Estensione di selezione degli endpoint: monitora le metriche chiave dei server dei modelli
all'interno di
InferencePool
. Monitora l'utilizzo della cache chiave-valore (KV-cache), la lunghezza della coda delle richieste in attesa e gli adattatori LoRA attivi su ogni server di modelli. Poi instrada la richiesta alla replica del modello ottimale in base a queste metriche per ridurre al minimo la latenza e massimizzare la velocità effettiva per l'inferenza dell'AI.
- Estensione di routing basata sul corpo: estrae l'identificatore del modello dal corpo della richiesta del client e lo invia a GKE Inference Gateway.
GKE Inference Gateway utilizza quindi questo identificatore per instradare la richiesta in base alle regole definite nell'oggetto
- GKE Inference Gateway indirizza la richiesta alla replica del modello restituita dall'estensione di selezione dell'endpoint.
Il seguente diagramma illustra il flusso di richieste da un client a un'istanza del modello tramite GKE Inference Gateway.

Come funziona la distribuzione del traffico
GKE Inference Gateway distribuisce dinamicamente le richieste di inferenza ai server dei modelli all'interno dell'oggetto InferencePool
. Ciò consente di ottimizzare l'utilizzo delle risorse
e mantenere le prestazioni in condizioni di carico variabili.
GKE Inference Gateway utilizza i seguenti due meccanismi per gestire la distribuzione del traffico:
Selezione dell'endpoint: seleziona dinamicamente il server di modelli più adatto per gestire una richiesta di inferenza. Monitora il carico e la disponibilità del server, quindi prende decisioni di routing.
Accodamento e eliminazione: gestisce il flusso di richieste e impedisce il sovraccarico di traffico. GKE Inference Gateway memorizza le richieste in arrivo in una coda, assegna la priorità alle richieste in base a criteri definiti ed elimina le richieste quando il sistema è sovraccarico.
GKE Inference Gateway supporta i seguenti livelli di Criticality
:
Critical
: queste workload hanno la priorità. Il sistema garantisce che queste richieste vengano gestite anche in presenza di vincoli di risorse.Standard
: questi workload vengono gestiti quando le risorse sono disponibili. Se le risorse sono limitate, queste richieste vengono eliminate.Sheddable
: questi workload vengono gestiti in modo opportunistico. Se le risorse sono scarse, queste richieste vengono eliminate per proteggere i carichi di lavoroCritical
.
Quando il sistema è sotto pressione delle risorse, le richieste Standard
e Sheddable
vengono immediatamente eliminate con un codice di errore 429
per salvaguardare i carichi di lavoro Critical
.
Inferenza dei flussi di dati
GKE Inference Gateway supporta l'inferenza in streaming per applicazioni come chatbot e traduzione in tempo reale che richiedono aggiornamenti continui o quasi in tempo reale. L'inferenza in streaming fornisce risposte in blocchi o segmenti incrementali, anziché come un unico output completo. Se si verifica un errore durante una risposta di streaming, lo stream termina e il client riceve un messaggio di errore. GKE Inference Gateway non riprova le risposte in streaming.
Esplorare esempi di applicazioni
Questa sezione fornisce esempi per affrontare vari scenari di applicazione dell'AI generativa utilizzando GKE Inference Gateway.
Esempio 1: pubblicare più modelli di AI generativa su un cluster GKE
Un'azienda vuole eseguire il deployment di più modelli linguistici di grandi dimensioni (LLM) per gestire carichi di lavoro diversi. Ad esempio, potrebbero voler eseguire il deployment di un modello Gemma3
per un'interfaccia chatbot e di un modello Deepseek
per un'applicazione di consigli. L'azienda deve garantire un rendimento di pubblicazione ottimale per questi LLM.
Utilizzando GKE Inference Gateway, puoi eseguire il deployment di questi LLM sul tuo cluster GKE con la configurazione dell'acceleratore che preferisci in un InferencePool
. Puoi quindi indirizzare le richieste in base al nome del modello (ad esempio
chatbot
e recommender
) e alla proprietà Criticality
.
Il seguente diagramma illustra in che modo GKE Inference Gateway
instrada le richieste a modelli diversi in base al nome del modello e a Criticality
.

Esempio 2: pubblicare adattatori LoRA su un acceleratore condiviso
Un'azienda vuole utilizzare LLM per l'analisi dei documenti e si concentra su segmenti di pubblico in più lingue, come inglese e spagnolo. Hanno modelli ottimizzati per ogni lingua, ma devono utilizzare in modo efficiente la capacità di GPU e TPU. Puoi utilizzare GKE Inference Gateway per eseguire il deployment di adattatori LoRA dinamici ottimizzati per ogni lingua (ad esempio english-bot
e spanish-bot
) su un modello di base comune (ad esempio llm-base
) e un acceleratore. In questo modo puoi ridurre il numero di acceleratori richiesti raggruppando più modelli su un acceleratore comune.
Il seguente diagramma illustra come GKE Inference Gateway gestisce più adattatori LoRA su un acceleratore condiviso.
