Networking per l'erogazione del modello di inferenza AI su tutti i backend

Last reviewed 2026-05-20 UTC

Questo documento fornisce un'architettura di riferimento per creare un frontend unificato per più modelli di AI ospitati on-premise o da qualsiasi provider, inclusi terze parti e Google Cloud. Se tutti i tuoi server di inferenza sono ospitati in Google Kubernetes Engine (GKE), consulta Networking per l'erogazione di modelli di inferenza AI su GKE.

Questa architettura è progettata per consentire agli sviluppatori di selezionare i modelli senza dover specificare singoli indirizzi IP per ciascun modello. Gli sviluppatori inviano invece richieste all'API OpenAI che includono il nome del modello all'endpoint frontend. Il sistema nell'architettura indirizza le richieste al backend che ospita il modello specificato. Il bilanciatore del carico frontend nell'architettura fornisce le seguenti funzioni amministrative centralizzate:

  • Un unico endpoint frontend per tutte le chiamate ai modelli, indipendentemente da come li ospiti.
  • Funzionalità di gestione delle API.
  • Punto di controllo per le contromisure dell'AI.
  • Punto di inserimento delle estensioni di servizio per la futura estensibilità.

Questo documento è destinato agli amministratori di rete e agli amministratori di applicazioni di AI generativa che vogliono inserire modelli di AI generativa nuovi o esistenti dietro un singolo endpoint di inferenza. 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'impresa. Questa architettura funziona con architetture di rete delle applicazioni come Cross-Cloud Network per applicazioni distribuite e con altri design.

Architettura

Il seguente diagramma mostra un'architettura con un endpoint in una rete consumer che punta a un frontend del bilanciatore del carico delle applicazioni interno regionale. Questo bilanciatore del carico utilizza il nome del modello specificato per indirizzare le richieste ai set di repliche del modello ospitati on-premise o da qualsiasi provider. Il bilanciatore del carico frontend fornisce servizi consolidati per tutti i modelli ospitati.

Panoramica generale del networking per l'inferenza dell'AI.

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.
  • Bilanciatore del carico delle applicazioni interno regionale: in questa architettura, il bilanciatore del carico frontend è un bilanciatore del carico delle applicazioni interno regionale. Il bilanciatore del carico frontend instrada il traffico ai pool di repliche in base al nome del modello specificato nella richiesta. In questa architettura, l'applicazione cliente effettua chiamate all'API OpenAI al bilanciatore del carico. Se il server di inferenza di backend è compatibile con l'API OpenAI, tutto funziona in modo trasparente. Se il server di inferenza non è compatibile con l'API OpenAI, devi implementare un traduttore di API utilizzando Service Extensions. Questa architettura di riferimento non include l'implementazione di un traduttore API.
  • Callout di Service Extensions: puoi utilizzare i callout per aggiungere un'elaborazione aggiuntiva a un bilanciatore del carico delle applicazioni. L'architettura di questo progetto utilizza le seguenti annotazioni:
    • Router basato sul corpo: Il router basato sul corpo viene implementato in Cloud Run. Legge il nome del modello dal corpo della richiesta API OpenAI e lo scrive in un campo X-Gateway-Model-Name nell'intestazione. La mappa URL del bilanciatore del carico utilizza il campo per inoltrare la richiesta al servizio di backend appropriato. Il deployment Terraform fornito con questa architettura di riferimento include la configurazione del router basata sul corpo.
    • Apigee: un gestore API che fornisce autenticazione, sicurezza, limitazione di frequenza, monitoraggio delle quote e altri servizi di gestione delle API. Questa architettura utilizza Apigee, ma supporta altre opzioni. Per chiamare Apigee dal bilanciatore del carico, l'architettura e il deployment di Terraform utilizzano un'estensione del traffico di Service Extensions per chiamare il processore di estensioni Apigee.
    • Model Armor: un sistema di protezione 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.
  • Servizi di backend: il bilanciatore del carico instrada le richieste ai servizi di backend in base al nome del modello nella richiesta. Il servizio di backend contiene un gruppo di endpoint di rete (NEG).
  • 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. Nell'architettura, le repliche del modello sono contenute in un cluster Google Kubernetes Engine (GKE) dietro un GKE Inference Gateway, in Vertex AI, in Cloud Run, in un data center on-premise o di un altro cloud e dietro un endpoint su internet.

Configurazioni del set di repliche del modello

Nell'architettura, il bilanciatore del carico frontend indirizza il traffico a un particolare servizio di backend in base al nome del modello. I server di inferenza per il modello specificato possono essere ospitati in una delle configurazioni descritte nella tabella seguente.

Tipo di set di repliche Descrizione Bilanciamento del carico delle repliche
Vertex AI Le repliche del modello vengono eseguite in Vertex AI. Pubblichi un endpoint Vertex AI come gruppo di endpoint di rete (NEG) Private Service Connect. Il bilanciatore del carico frontend utilizza i NEG di Private Service Connect come backend per ogni modello distinto, con ogni modello strutturato come servizio di backend. Vertex AI esegue lo scale e il bilanciamento del carico internamente. Vertex AI esegue il bilanciamento del carico ponderato basato sulle metriche e il routing basato sulla cache dei prefissi, il che ottimizza l'utilizzo delle risorse e accelera l'inferenza. Per saperne di più, consulta Eseguire il deployment di un modello in un endpoint.
GKE I server di inferenza vengono eseguiti come pod in un cluster GKE nella rete VPC del set di repliche GKE. Più repliche del modello all'interno di GKE formano collettivamente un singolo backend dietro un gateway di inferenza. Inference Gateway pubblica un endpoint Private Service Connect a cui il bilanciatore del carico frontend accede utilizzando un NEG Private Service Connect. Inference Gateway fornisce un bilanciamento del carico basato sul modello per i backend di inferenza in un cluster GKE. L'Inference Gateway utilizza la corrispondenza dei prefissi quando applicabile. Se non esiste una corrispondenza del prefisso, il gateway di inferenza distribuisce le richieste in base alle metriche GPU o TPU. Questa configurazione supporta la scalabilità automatica orizzontale dei pod.
Cloud Run I server di inferenza vengono eseguiti in Cloud Run. Cloud Run pubblica un endpoint a cui il bilanciatore del carico frontend accede utilizzando un NEG serverless. Cloud Run scala automaticamente il numero di repliche in base al traffico. È limitato alle repliche a nodo singolo.
Ibrido I server di inferenza vengono eseguiti on-premise o in un altro cloud. Configura un bilanciatore del carico di rete proxy interno regionale in una rete VPC di routing. Questo bilanciatore del carico pubblica un endpoint Private Service Connect a cui il bilanciatore del carico frontend accede utilizzando un NEG Private Service Connect. Il bilanciatore del carico interno nella rete VPC di routing a sua volta ha un backend NEG ibrido che punta all'indirizzo IP di un bilanciatore del carico on-premise o di un altro cloud davanti ai server di inferenza on-premise. Il meccanismo di bilanciamento del carico del bilanciatore del carico esterno è configurato dagli amministratori della struttura esterna.
Internet Server di inferenza accessibili da indirizzi IP internet pubblici. Il bilanciatore del carico frontend ha un backend NEG internet che punta all'indirizzo IP di un modello ospitato su internet. Il fornitore di servizi gestiti gestisce lo scaling.

Flusso di richiesta

Il sistema instrada le richieste di inferenza nel seguente modo:

  1. 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.
  2. L'endpoint Private Service Connect inoltra la richiesta al bilanciatore del carico delle applicazioni interno frontend.
  3. Il bilanciatore del carico inoltra la richiesta a Service Extensions.
  4. Il codice di routing basato sul corpo delle Service Extensions legge il nome del modello dal corpo della richiesta e lo scrive in un'intestazione X-Gateway-Model-Name.
  5. Il bilanciatore del carico utilizza il callout dell'estensione del traffico di Service Extensions per inviare la richiesta al sistema di gestione delle API per tutti i servizi di gestione delle API necessari.
  6. Il bilanciatore del carico utilizza un callout dell'estensione del traffico Service Extensions per inviare 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.
  7. Se la richiesta è consentita da Model Armor, il bilanciatore del carico consulta la mappa URL e inoltra la richiesta a un servizio di backend in base all'intestazione personalizzata del nome del modello. Se necessario, la mappa URL riscrive l'URL e il percorso della richiesta in modo che corrispondano a ciò che richiede il backend.
  8. Il servizio di backend inoltra la richiesta al bilanciatore del carico del set di repliche associato.
  9. Il bilanciatore del carico per il servizio di inferenza specifico assegna la richiesta a una delle sue repliche.
  10. La replica elabora la richiesta e invia una risposta.
  11. Il bilanciatore del carico delle applicazioni interno regionale di frontend invia la risposta a Model Armor per lo screening.
  12. Il bilanciatore del carico delle applicazioni 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:

Flusso di prompt per campionare i set di repliche.

In questo esempio, i prompt vengono gestiti a seconda del modello selezionato dall'utente:

  • Gemma: tutti i prompt vengono indirizzati al set di repliche che ospita il modello Gemma.
  • Llama: il sistema bilancia il carico di questi prompt in modo equo 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.

Prodotti utilizzati

L'architettura di riferimento in questo documento utilizza i seguenti prodotti Google Cloud :

  • Cloud Load Balancing: un portafoglio di bilanciatori del carico scalabili, globali e regionali ad alte prestazioni.
  • 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 tue 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 barriere di protezione dell'AI. Per centralizzare l'amministrazione, ti consigliamo di chiamarlo direttamente dal load balancer, 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 le misure di protezione dell'AI in un punto diverso dall'endpoint del modello, puoi disattivare Model Armor nel bilanciamento del carico frontend se non ti serve. Se non vuoi utilizzare Model Armor, puoi utilizzare le estensioni del traffico per implementare altre offerte di guardrail come NVIDIA NeMo Guardrails.

Gestione delle API

L'architettura descritta in questo documento utilizza Apigee per la gestione delle API, di cui viene eseguito il deployment utilizzando un'estensione di servizio del bilanciatore del carico. Se Apigee non soddisfa le tue esigenze, puoi utilizzare le estensioni di servizio per eseguire il deployment di un servizio di gestione 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 delle API funge da ponte tra le due reti. Per informazioni su come eseguire il deployment per Apigee, vedi Opzioni di rete 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 protezione dagli attacchi DDoS (Distributed Denial-of-Service), funzionalità WAF (Web Application Firewall) e ispezione degli indirizzi IP al tuo deployment, aggiungi Cloud Armor al bilanciatore del carico delle applicazioni interno regionale frontend.
  • Per aggiungere un livello di autenticazione comune a tutti i backend, implementa Identity-Aware Proxy (IAP) per verificare l'identità e applicare i criteri di autorizzazione.
  • Quando indirizzi il traffico da un'applicazione web a un modello Vertex AI, devi scegliere un modello di identità per l'autenticazione:
    • Identità del service account (consigliata per le app web generali): l'applicazione autentica l'utente finale tramite IAP, ma chiama Vertex AI utilizzando l'identità del workload dei servizi (ad esempio Cloud Run, GKE o utilizzando un'identità di terze parti). Questa implementazione astrae Identity and Access Management (IAM) dall'utente finale, ma richiede la registrazione a livello di applicazione per monitorare quale utente ha generato quale prompt.
    • Trasmissione dell'identità dell'utente finale (consigliata per un'auditabilità rigorosa): l'applicazione acquisisce il token di accesso OAuth di Google dell'utente finale e lo trasmette direttamente a Vertex AI nell'intestazione Authorization: Bearer. Questa implementazione fornisce la registrazione integrata di Cloud Audit Logs delle azioni utente, ma richiede che ogni utente finale venga sottoposto al provisioning con le autorizzazioni IAM Google Cloud(ad esempio roles/aiplatform.user).

Affidabilità

Per proteggerti da errori a livello regionale, replica il deployment in una seconda regione utilizzando l'archetipo di deployment multiregionale.Google Cloud

Efficienza operativa

  • Per monitorare i flussi di traffico in modo da identificare e risolvere rapidamente i problemi, utilizza i log di Cloud Logging per il bilanciatore del carico delle applicazioni interno regionale.
  • Per facilitare l'individuazione dei modelli supportati dalla tua organizzazione, implementa un elenco su cui è possibile eseguire query per restituire i modelli disponibili. Ad esempio, puoi creare un elenco su un server che risponde alla chiamata API list models.

Ottimizzazione delle prestazioni

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.

Per informazioni su come eseguire il deployment dei modelli di AI, consulta le seguenti risorse:

Passaggi successivi

Collaboratori

Autore: Victor Moreno | Product Manager, Cloud Networking

Altri collaboratori: