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 server di inferenza sono ospitati in Google Kubernetes Engine (GKE), consulta Networking per l'erogazione del modello di inferenza AI su GKE.

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

  • Un singolo endpoint frontend per tutte le chiamate del modello, indipendentemente da come ospiti i modelli.
  • Funzionalità di gestione delle API.
  • Punto di controllo per le contromisure di AI.
  • Service Extensions punto di inserimento 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 Creare ed eseguire il deployment di modelli di AI generativa e machine learning in un' azienda. Questa architettura funziona con architetture di rete delle applicazioni come Cross-Cloud Network per applicazioni distribuite applicazioni 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 instradare 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 le 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 gli 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 del cliente effettua chiamate all'API OpenAI al bilanciatore del carico. Se il server di inferenza di backend è compatibile con l'API OpenAI, le operazioni funzionano in modo trasparente. Se il server di inferenza non è compatibile con l'API OpenAI, devi implementare un traduttore 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 ulteriore elaborazione a un bilanciatore del carico delle applicazioni. L'architettura in questo design utilizza i seguenti callout:
    • Router basato sul corpo: il router basato sul corpo viene eseguito il deployment in Cloud Run. Legge il nome del modello dal corpo della richiesta dell'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 di Terraform fornito con questa architettura di riferimento include la configurazione del router basato sul corpo.
    • Apigee: un gestore API che fornisce autenticazione API, sicurezza, limitazione di frequenza, monitoraggio delle quote e altri servizi di gestione delle API. Questa architettura utilizza Apigee, ma supporta anche 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 estensione Apigee.
    • Model Armor: un sistema di contromisure di AI che esegue controlli di sicurezza sui prompt di inferenza prima che raggiungano il server di inferenza. Esegue quindi controlli di sicurezza sulle risposte in uscita. Questa architettura utilizza Model Armor per le contromisure di 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 nodo singolo o multi-nodo. Un set di repliche è un gruppo uniforme di repliche del modello preceduto da 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 Gemini Enterprise Agent Platform, 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
Agent Platform Le repliche del modello vengono eseguite in Agent Platform. Pubblica un endpoint di Agent Platform come gruppo di endpoint di rete (NEG) Private Service Connect. Il bilanciatore del carico frontend utilizza i NEG Private Service Connect come backend per ogni modello distinto, con ogni modello strutturato come servizio di backend. Agent Platform esegue lo scale up e il bilanciamento del carico internamente. Agent Platform esegue il bilanciamento del carico ponderato basato sulle metriche e il routing basato sulla cache dei prefissi, 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. Il gateway di inferenza pubblica un endpoint Private Service Connect a cui il bilanciatore del carico frontend accede utilizzando un NEG Private Service Connect. Il gateway di inferenza fornisce il bilanciamento del carico basato sul modello per i backend di inferenza in un cluster GKE. Il gateway di inferenza utilizza la corrispondenza dei prefissi, se applicabile. Se non è presente una corrispondenza dei prefissi, il gateway di inferenza distribuisce le richieste in base alle metriche della GPU o della 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 esegue automaticamente lo scale up del numero di repliche in base al traffico. È limitato alle repliche a nodo singolo.
Ibrido I server di inferenza vengono eseguiti on-premise o su 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. A sua volta, il bilanciatore del carico interno nella rete VPC di routing 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 viene configurato dagli amministratori della struttura esterna.
Internet Server di inferenza accessibili dagli 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 scale up.

Flusso delle richieste

Il sistema instrada le richieste di inferenza nel seguente modo:

  1. Un utente finale invia una richiesta all'API OpenAI all'endpoint Private Service Connect. Questa richiesta contiene quanto segue:
    • Il prompt.
    • Il nome del modello, che deve corrispondere al nome del modello 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 estensioni di servizio legge il nome del modello dal corpo della richiesta e lo scrive in un' X-Gateway-Model-Name intestazione.
  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 di 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 non presenta problemi, Model Armor oscura le informazioni sensibili 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 quelli necessari per 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 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 uniforme 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 Agent Platform e l'altro 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 Google Cloud prodotti:

  • Cloud Load Balancing: un portafoglio di bilanciatori del carico globali e regionali scalabili e ad alte prestazioni.
  • Virtual Private Cloud (VPC): un sistema virtuale che fornisce funzionalità di rete globali e scalabili per i tuoi Google Cloud workload. 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 i 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 cui si accede. 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 da prompt injection, fughe di dati sensibili e contenuti dannosi.

Alternative di progettazione

Questa sezione descrive le alternative ad alcune delle ipotesi di base di questa architettura.

Contromisure di AI

Ti consigliamo di utilizzare Model Armor per le contromisure di AI. Per centralizzare l'amministrazione, ti consigliamo di chiamarlo direttamente dal bilanciatore 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 contromisure di AI diverse dall'endpoint del modello, puoi disattivare Model Armor nel bilanciatore del carico frontend se non ne hai bisogno. Se non vuoi utilizzare Model Armor, puoi utilizzare le estensioni del traffico per eseguire il deployment di altre offerte di contromisure come NVIDIA NeMo Guardrails.

Gestione delle API

L'architettura 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 Service Extensions per eseguire il deployment di un servizio di gestione delle API diverso.

Se il deployment della gestione delle API utilizzando 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 di questo servizio per Apigee, consulta Opzioni di rete Apigee.

Connessione ad altre reti

L'architettura 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 di Cross-Cloud Network.

Note sul layout

Quando crei l'architettura per il tuo workload, tieni presente le best practice e le raccomandazioni del Google Cloud Well-Architected Framework.

Sicurezza, privacy e conformità

  • Per aggiungere protezione dagli attacchi DDoS (Distributed Denial of Service), funzionalità Web Application Firewall (WAF) e ispezione degli indirizzi IP al 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 di Agent Platform, 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 Agent Platform utilizzando l'identità del workload dei servizi (ad esempio come 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.
    • Passaggio dell'identità dell'utente finale (consigliato per un'auditabilità rigorosa): l'applicazione acquisisce il token di accesso OAuth di Google dell'utente finale e lo passa direttamente ad Agent Platform nell'intestazione Authorization: Bearer. Questa implementazione fornisce la registrazione integrata di Cloud Audit Logs delle azioni dell'utente, ma richiede che a ogni utente finale vengano fornite le Google Cloud autorizzazioni IAM (ad esempio roles/aiplatform.user).

Affidabilità

Per proteggerti da guasti regionali, replica il deployment in una seconda regione utilizzando l'Google Cloud archetipo di deployment multiregionale.

Efficienza operativa

  • Per monitorare i flussi di traffico in modo da poter 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: