Questo documento fornisce un'architettura di riferimento per creare un servizio di inferenza multimodello utilizzando Google Kubernetes Engine (GKE). Nell'architettura, i pool di inferenza ospitati da GKE vengono posizionati dietro un gateway di inferenza GKE. Questa architettura offre i seguenti vantaggi:
- Un'unica interfaccia per tutte le tue richieste di inferenza.
- Routing intelligente per ogni richiesta al modello e al server di inferenza che può gestirla nel modo più efficiente.
- Autorizzazione, sicurezza e altri servizi centralizzati.
Questo documento è rivolto agli architetti di rete responsabili di unificare il deployment dei server di inferenza eseguiti in GKE. Se tutti i tuoi server di inferenza non sono ospitati in GKE, consulta Networking per la pubblicazione di modelli di inferenza AI su tutti i backend. Questo documento non fornisce indicazioni su come progettare un'applicazione o eseguire il deployment di un singolo modello di AI generativa. Per indicazioni su come eseguire il deployment di un modello, consulta Crea ed esegui il deployment di modelli di AI generativa e machine learning in un'azienda.
Questa architettura funziona con le architetture di rete delle applicazioni Cross-Cloud Network per applicazioni distribuite e altri progetti.
Architettura
Il seguente diagramma mostra un'architettura che contiene un gateway di inferenza davanti ai server di inferenza ospitati da GKE. Il gateway fornisce servizi consolidati per tutti i modelli ospitati.
L'architettura nel diagramma include i seguenti componenti:
- Endpoint di inferenza Private Service Connect: un endpoint unificato per tutti i modelli ospitati. L'utente finale invia richieste di inferenza all'indirizzo IP dell'endpoint. Il diagramma mostra un endpoint Private Service Connect in una singola rete Virtual Private Cloud (VPC) consumer. Puoi ospitare endpoint in diverse reti VPC o in una rete VPC di servizi condivisi.
- Inference Gateway: Inference Gateway migliora GKE Gateway per ottimizzare il modo in cui GKE gestisce le applicazioni e i workload di AI generativa. Instrada il traffico ai pool di inferenza delle repliche del modello in base al nome del modello. Il gateway utilizza la corrispondenza dei prefissi per instradare il traffico
all'interno del pool di repliche. Se non esiste una corrispondenza del prefisso, il processore di inferenza del gateway utilizza le metriche Prometheus della GPU o della TPU per scegliere la replica meno caricata all'interno del pool.
Il processore di inferenza gestisce anche la memorizzazione nella cache dei prefissi. In questa architettura, l'applicazione rivolta ai clienti effettua chiamate all'API
OpenAI per accedere ai modelli tramite il gateway. Il gateway viene implementato in base a un bilanciatore del carico delle applicazioni interno regionale (
gke-l7-rilb), quindi non è accessibile direttamente da internet.- Gestione API: un gestore API fornisce autenticazione, sicurezza, limitazione di frequenza, monitoraggio della quota e altri servizi di gestione API. Questa architettura utilizza Apigee, ma supporta anche altre opzioni. Per chiamare Apigee dal bilanciamento del carico, l'architettura e il deployment Terraform utilizzano un'estensione del traffico Service Extensions per chiamare il processore di estensione Apigee.
- Model Armor: Un sistema di salvaguardie dell'AI che esegue controlli di sicurezza sui prompt di inferenza prima che raggiungano il server di inferenza. Dopodiché, esegue controlli di sicurezza sulle risposte in uscita. Questa architettura utilizza Model Armor per le barriere protettive dell'AI, ma supporta anche altre opzioni come NVIDIA Nemo Guardrails. Il deployment di Terraform fornito con questa architettura di riferimento include una configurazione di base di Model Armor.
- Pool di inferenza: un pool di inferenza contiene repliche dello stesso modello.
Quando il gateway riceve una richiesta, utilizza una
ricerca
HTTPRouteper selezionare un pool di inferenza in base all'identificatore del modello. I pool hanno una dimensione iniziale, ma possono essere configurati per la scalabilità automatica. - Set di repliche del modello: una replica del modello è una copia di un server di inferenza di cui è stato eseguito il deployment su una o più GPU o TPU. Una replica del modello può essere a un singolo nodo o a più nodi. Un set di repliche è un gruppo uniforme di repliche del modello che si trova davanti a un bilanciatore del carico. Se il set di repliche è multinodo, le GPU si connettono tra loro tramite una rete VPC RDMA di backend. La rete fornisce una rete inter-GPU lossless a bassa latenza con allineamento ai rail.
Flusso di richiesta
Il sistema instrada le richieste di inferenza nel seguente modo:
- Un utente finale invia una richiesta dell'API OpenAI all'endpoint Private Service Connect. Questa richiesta contiene quanto segue:
- Il prompt.
- Il nome del modello, che deve corrispondere a quello di uno dei server di inferenza ospitati.
- L'endpoint Private Service Connect inoltra la richiesta alla versione regionale del bilanciatore del carico delle applicazioni interno di Inference Gateway.
- Il gateway estrae il nome del modello dal corpo della richiesta e lo inserisce nell'intestazione della richiesta utilizzando il routing basato sul corpo.
- Il gateway inoltra la richiesta al sistema di gestione API per i servizi di gestione API necessari.
- Il gateway invia il prompt a Model Armor per lo screening.
- Se il prompt contiene informazioni sensibili che non possono essere oscurate, il prompt viene bloccato e Model Armor restituisce una risposta per indicare che è stata rilevata una violazione delle norme.
- Se il prompt contiene informazioni sensibili che possono essere oscurate o se il prompt non presenta alcun problema, Model Armor oscura qualsiasi informazione sensibile e inoltra il prompt.
- Il gateway consulta
HTTPRouteper un elenco di pool di inferenza che corrispondono al modello della richiesta. Da questo elenco, il gateway ne sceglie uno in base a una priorità. - Il gateway consulta la cache dei prefissi e il carico corrente per tutte le repliche nel pool, quindi utilizza queste informazioni per scegliere una replica.
- La replica elabora la richiesta e la invia di nuovo al gateway.
- Il gateway invia la risposta a Model Armor per l'approvazione o il rifiuto.
- Il gateway invia la risposta all'endpoint Private Service Connect e all'utente finale.
Il seguente diagramma mostra una visualizzazione del routing di un deployment di esempio.
In questo esempio, i prompt vengono gestiti a seconda del modello selezionato dall'utente:
- Llama: il sistema bilancia il carico di questi prompt con un rapporto 90/10 tra due set di repliche che ospitano entrambi il modello Llama. Questi due set di repliche non devono essere ospitati nello stesso modo. Ad esempio, un set di repliche potrebbe essere ospitato in Vertex AI e l'altro set di repliche potrebbe essere ospitato in GKE.
- LoRA-1-gemma o LoRA-2-gemma: il sistema invia tutti i prompt allo stesso set di repliche, che può gestire entrambi i modelli.
In tutti i casi, il gateway utilizza una combinazione di corrispondenza del prefisso e bilanciamento del carico per scegliere una replica nel pool pertinente.
Prodotti utilizzati
Questa architettura di riferimento utilizza i seguenti prodotti: Google Cloud
- Google Kubernetes Engine (GKE): un servizio Kubernetes che puoi utilizzare per eseguire il deployment e gestire applicazioni containerizzate su larga scala utilizzando l'infrastruttura di Google.
- GKE Inference Gateway: un'estensione di Google Kubernetes Engine Gateway che fornisce routing e bilanciamento del carico ottimizzati per la gestione dei carichi di lavoro di AI generativa. Semplifica l'implementazione, la gestione e l'osservabilità dei carichi di lavoro di inferenza AI.
- Virtual Private Cloud (VPC): un sistema virtuale che fornisce funzionalità di rete globali e scalabili per i tuoi Google Cloud carichi di lavoro. VPC include il peering di rete VPC, Private Service Connect, l'accesso privato ai servizi e VPC condiviso.
- Private Service Connect: una funzionalità che consente ai consumer di accedere ai servizi gestiti privatamente dall'interno della propria rete VPC.
- Cloud Run: una piattaforma di computing serverless che ti consente di eseguire container direttamente sull'infrastruttura scalabile di Google.
- Apigee: uno strumento di gestione delle API che ti offre un controllo granulare su come le tue API vengono utilizzate e a quali risorse accedono. Fornisce sicurezza, limitazione di frequenza, applicazione delle quote e analisi.
- Model Armor: un servizio che fornisce protezione per le risorse di AI generativa e agentica contro prompt injection, fughe di dati sensibili e contenuti dannosi.
Alternative di progettazione
Questa sezione descrive le alternative ad alcuni dei presupposti di base di questa architettura.
Contromisure AI
Ti consigliamo di utilizzare Model Armor per le protezioni dell'AI. Per centralizzare l'amministrazione, ti consigliamo di chiamarlo direttamente dal bilanciamento del carico, come in questa architettura. Puoi anche implementare Model Armor in questi modi alternativi:
- Utilizza un criterio di gestione delle API per chiamare Model Armor.
- Esegui il deployment di Model Armor solo nella replica.
Se implementi misure di protezione dell'AI diverse dall'endpoint del modello, puoi disattivare Model Armor nel bilanciatore del carico frontend se non ti serve. Se non vuoi utilizzare Model Armor, puoi utilizzare le estensioni del traffico per implementare altre offerte di misure di protezione come NVIDIA NeMo Guardrails.
Gestione delle API
L'architettura descritta in questo documento utilizza Apigee per la gestione delle API, che viene implementata utilizzando un'estensione di servizio del bilanciatore del carico. Se Apigee non soddisfa le tue esigenze, puoi utilizzare le Service Extensions per eseguire il deployment di un servizio di gestione delle API diverso.
Se il deployment della gestione API utilizzando le Service Extensions non soddisfa le tue esigenze, potresti dover eseguire il deployment di una rete rivolta ai client e di una rete rivolta alle API. In questo scenario, il servizio di gestione API funge da ponte tra le due reti. Per informazioni su come eseguire il deployment per Apigee, consulta Opzioni di networking di Apigee.
Connessione ad altre reti
L'architettura descritta in questo documento utilizza una singola rete VPC consumer. Tuttavia, puoi condividere l'endpoint Private Service Connect con molte altre reti utilizzando una rete VPC di accesso ai servizi in un deployment Cross-Cloud Network.
Considerazioni sulla progettazione
Quando crei l'architettura per il tuo carico di lavoro, tieni presente le best practice e i consigli del Google Cloud Well-Architected Framework.
Sicurezza, privacy e conformità
Per aggiungere la protezione dagli attacchi DDoS (Distributed Denial-of-Service), la funzionalità WAF (Web Application Firewall) e l'ispezione degli indirizzi IP al tuo deployment, aggiungi Google Cloud Armor al bilanciatore del carico delle applicazioni interno regionale frontend.
Affidabilità
Per proteggerti da errori a livello regionale, replica il deployment in una seconda regione utilizzando l'archetipo di deployment multiregionale.Google Cloud
Ottimizzazione dei costi
Per i suggerimenti sull'ottimizzazione dei costi di GKE, consulta Best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE.
Efficienza operativa
Monitora il rendimento delle richieste di inferenza di Inference Gateway utilizzando la dashboard di Inference Gateway. La dashboard mostra errori e metriche come tasso di richieste, latenza e saturazione. Utilizza i risultati della dashboard per ottimizzare la tua implementazione.
Ottimizzazione delle prestazioni
Segui i consigli riportati nella panoramica delle best practice per l'inferenza su GKE.
Deployment
Per eseguire il deployment di un'implementazione di esempio di questa architettura, utilizza l'esempio di codice Networking for AI Inference Model Serving disponibile su GitHub.
Passaggi successivi
- Per informazioni su come aggiungere la Retrieval Augmented Generation (RAG) al tuo deployment, consulta Connettività privata per applicazioni di AI generativa con funzionalità RAG.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora Cloud Architecture Center.
Collaboratori
Autore: Victor Moreno | Product Manager, Cloud Networking
Altri collaboratori:
- Mark Schlagenhauf | Technical Writer, Networking
- James Duncan | Solutions Product Manager
- Ammett Williams | Developer Relations Engineer