Vernetzung für die Bereitstellung von KI-Inferenzmodellen auf allen Back-Ends

Last reviewed 2026-05-20 UTC

Dieses Dokument enthält eine Referenzarchitektur zum Erstellen eines einheitlichen Frontends für mehrere KI-Modelle, die lokal oder von einem beliebigen Anbieter gehostet werden, einschließlich Drittanbietern und Google Cloud. Wenn alle Ihre Inferenzserver in der Google Kubernetes Engine (GKE) gehostet werden, lesen Sie den Artikel Netzwerke für die Bereitstellung von KI-Inferenzmodellen in GKE.

Diese Architektur soll es Ihren Entwicklern ermöglichen, Modelle auszuwählen, ohne für jedes Modell einzelne IP-Adressen angeben zu müssen. Stattdessen senden Entwickler OpenAI API Anfragen, die den Namen des Modells enthalten, an den Frontend-Endpunkt. Das System in der Architektur leitet die Anfragen an das Backend weiter, das das angegebene Modell hostet. Der Frontend-Load-Balancer in der Architektur bietet die folgenden zentralen Verwaltungsfunktionen:

  • Ein einziger Frontend-Endpunkt für alle Modellaufrufe, unabhängig davon, wie Sie die Modelle hosten.
  • Funktionen für die API-Verwaltung.
  • Checkpoint für KI-Schutzmaßnahmen.
  • Service Extensions Einfügungspunkt für zukünftige Erweiterbarkeit.

Dieses Dokument richtet sich an Netzwerkadministratoren und Administratoren von generativen KI-Anwendungen, die neue oder vorhandene generative KI-Modelle hinter einem einzigen Inferenzendpunkt platzieren möchten. Dieses Dokument bietet keine Anleitung zum Entwerfen einer Anwendung oder zum Bereitstellen eines einzelnen generativen KI-Modells. Eine Anleitung zum Bereitstellen eines Modells finden Sie unter Modelle für generative KI und maschinelles Lernen in einem Unternehmen erstellen und bereitstellen. Diese Architektur funktioniert mit Anwendungsnetzwerkarchitekturen wie dem Cross-Cloud Network für verteilte Anwendungen und mit anderen Designs.

Architektur

Das folgende Diagramm zeigt eine Architektur mit einem Endpunkt in einem Verbrauchernetzwerk, der auf ein regionales internes Application Load Balancer-Frontend verweist. Dieser Load-Balancer verwendet den Namen des angegebenen Modells, um Anfragen an Modellreplikatsätze weiterzuleiten, die lokal oder von einem beliebigen Anbieter gehostet werden. Der Frontend-Load-Balancer bietet konsolidierte Dienste für alle gehosteten Modelle.

Allgemeiner Überblick über die Vernetzung für KI-Inferenz.

Die Architektur im Diagramm umfasst die folgenden Komponenten:

  • Private Service Connect-Inferenzendpunkt: Ein einheitlicher Endpunkt für alle gehosteten Modelle. Der Endnutzer sendet Inferenzanfragen an die IP-Adresse des Endpunkts. Das Diagramm zeigt einen Private Service Connect-Endpunkt in einem einzelnen Virtual Private Cloud-Netzwerk (VPC) des Verbrauchers. Sie können Endpunkte in mehreren VPC-Netzwerken oder in einem VPC-Netzwerk für freigegebene Dienste hosten.
  • Regionaler interner Application Load Balancer: In dieser Architektur ist der Frontend-Load Balancer ein regionaler interner Application Load Balancer. Der Frontend-Load-Balancer leitet den Traffic basierend auf dem in der Anfrage angegebenen Modellnamen an Replikatpools weiter. In dieser Architektur führt die Kundenanwendung OpenAI API-Aufrufe an den Load-Balancer aus. Wenn der Backend-Inferenzserver mit der OpenAI API kompatibel ist, funktioniert alles transparent. Wenn der Inferenzserver nicht kompatibel ist mit der OpenAI API, müssen Sie mit Service Extensions einen API-Übersetzer implementieren. Diese Referenzarchitektur enthält keine Implementierung eines API-Übersetzers.
  • Service Extensions Callouts: Sie können Callouts verwenden, um einem Application Load Balancer zusätzliche Verarbeitung hinzuzufügen. Die Architektur in diesem Design verwendet die folgenden Callouts:
    • Textkörperbasierter Router: Der textkörperbasierte Router wird in Cloud Run bereitgestellt. Er liest den Modellnamen aus dem Textkörper der OpenAI API-Anfrage und schreibt ihn in ein X-Gateway-Model-Name-Feld im Header. Die URL-Zuordnung des Load-Balancers verwendet das Feld, um die Anfrage an den entsprechenden Backend-Dienst weiterzuleiten. Die Terraform-Bereitstellung, die mit dieser Referenzarchitektur bereitgestellt wird, enthält die Konfiguration des textkörperbasierten Routers.
    • Apigee: Ein API-Manager, der API-Authentifizierung, Sicherheit, Ratenbegrenzung, Kontingentverfolgung und andere API-Verwaltungsdienste bietet. Diese Architektur verwendet Apigee, unterstützt aber auch andere Optionen. Um Apigee vom Load-Balancer aufzurufen, verwenden die Architektur und die Terraform-Bereitstellung eine Service Extensions traffic extension, um den Apigee-Erweiterungsprozessor aufzurufen.
    • Model Armor: Ein KI-Schutzsystem , das Sicherheitsprüfungen für Inferenzprompts durchführt, bevor sie den Inferenzserver erreichen. Anschließend werden Sicherheitsprüfungen für die ausgehenden Antworten durchgeführt. Diese Architektur verwendet Model Armor für KI-Schutzmaßnahmen, unterstützt aber auch andere Optionen wie NVIDIA NeMo Guardrails. Die Terraform-Bereitstellung, die mit dieser Referenzarchitektur bereitgestellt wird, enthält eine grundlegende Model Armor-Konfiguration.
  • Backend-Dienste: Der Load-Balancer leitet Anfragen basierend auf dem Namen des Modells in der Anfrage an Backend-Dienste weiter. Der Backend-Dienst enthält eine Netzwerk-Endpunktgruppe (NEG).
  • Modellreplikatsätze: Ein Modell replikat ist eine Kopie eines Inferenzservers, der auf einer oder mehreren GPUs oder TPUs bereitgestellt wird. Ein Modellreplikat kann einen oder mehrere Knoten umfassen. Ein Replikatset ist eine einheitliche Gruppe von Modellreplikaten, die von einem Load-Balancer verwaltet wird. In der Architektur sind Modellreplikate in einem Google Kubernetes Engine-Cluster (GKE) hinter einem GKE Inference Gateway, in Vertex AI, in Cloud Run, in einem lokalen oder anderen Cloud-Rechenzentrum und hinter einem Endpunkt im Internet enthalten.

Konfigurationen für Modellreplikatsätze

In der Architektur leitet der Frontend-Load-Balancer den Traffic basierend auf dem Modellnamen an einen bestimmten Backend-Dienst weiter. Die Inferenzserver für das angegebene Modell können in einer der in der folgenden Tabelle beschriebenen Konfigurationen gehostet werden.

Replikatsettyp Beschreibung Load-Balancing für Replikate
Vertex AI Die Modellreplikate werden in Vertex AI ausgeführt. Sie veröffentlichen einen Vertex AI-Endpunkt als Private Service Connect-Netzwerk-Endpunktgruppe (NEG). Der Frontend-Load-Balancer verwendet Private Service Connect-NEGs als Back-Ends für jedes einzelne Modell, wobei jedes Modell als Backend-Dienst strukturiert ist. Vertex AI skaliert und verteilt die Last intern. Vertex AI führt gewichtetes Load-Balancing basierend auf Messwerten und Routing basierend auf dem Präfixcache durch, wodurch die Ressourcennutzung optimiert und die Inferenz beschleunigt wird. Weitere Informationen finden Sie unter Modell auf einem Endpunkt bereitstellen.
GKE Inferenzserver werden als Pods in einem GKE-Cluster im VPC-Netzwerk des GKE-Replikatsets ausgeführt. Mehrere Modellreplikate in GKE bilden zusammen ein einziges Backend hinter einem Inference Gateway. Das Inference Gateway veröffentlicht einen Private Service Connect-Endpunkt, auf den der Frontend-Load-Balancer über eine Private Service Connect-NEG zugreift. Das Inference Gateway bietet modellbezogenes Load-Balancing für Inferenz-Back-Ends in einem GKE-Cluster. Das Inference Gateway verwendet gegebenenfalls den Präfixabgleich. Wenn es keine Präfixübereinstimmung gibt, verteilt das Inference Gateway Anfragen basierend auf GPU- oder TPU-Messwerten. Diese Konfiguration unterstützt das horizontale Pod-Autoscaling.
Cloud Run Inferenzserver werden in Cloud Run ausgeführt. Cloud Run veröffentlicht einen Endpunkt, auf den der Frontend-Load Balancer über eine serverlose NEG zugreift. Cloud Run skaliert die Anzahl der Replikate automatisch basierend auf dem Traffic. Es ist auf Replikate mit einem einzelnen Knoten beschränkt.
Hybrid Inferenzserver werden lokal oder in einer anderen Cloud ausgeführt. Sie konfigurieren einen regionalen internen Proxy-Network Load Balancer in einem Routing-VPC-Netzwerk. Dieser Load-Balancer veröffentlicht einen Private Service Connect-Endpunkt, auf den der Frontend-Load-Balancer über eine Private Service Connect-NEG zugreift. Der interne Load-Balancer im Routing-VPC-Netzwerk hat wiederum ein Hybrid-NEG-Backend, das auf die IP-Adresse eines lokalen oder anderen Cloud-Load-Balancers vor den lokalen Inferenzservern verweist. Der Load-Balancing-Mechanismus des externen Load-Balancers wird von den Administratoren der externen Einrichtung konfiguriert.
Internet Inferenzserver, auf die über öffentliche Internet-IP-Adressen zugegriffen werden kann. Der Frontend-Load-Balancer hat ein Internet-NEG -Backend, das auf die IP-Adresse eines im Internet gehosteten Modells verweist. Der Anbieter verwalteter Dienste übernimmt die Skalierung.

Anfrageablauf

Das System leitet Inferenzanfragen so weiter:

  1. Ein Endnutzer sendet eine OpenAI API-Anfrage an den Private Service Connect-Endpunkt. Diese Anfrage enthält Folgendes:
    • Der Prompt.
    • Der Modellname, der mit dem Modellnamen eines der gehosteten Inferenzserver übereinstimmen muss.
  2. Der Private Service Connect-Endpunkt leitet die Anfrage an den internen Application Load Balancer des Frontends weiter.
  3. Der Load-Balancer leitet die Anfrage an Service Extensions weiter.
  4. Der Code für das textkörperbasierte Routing der Service Extensions liest den Modellnamen aus dem Anfragetext und schreibt ihn in einen X-Gateway-Model-Name Header.
  5. Der Load-Balancer verwendet das Service Extensions-Traffic-Callout, um die Anfrage an das API-Verwaltungssystem für alle erforderlichen API-Verwaltungsdienste zu senden.
  6. Der Load-Balancer verwendet ein Service Extensions-Traffic-Callout, um den Prompt zur Überprüfung an Model Armor zu senden.
    • Wenn der Prompt vertrauliche Informationen enthält, die nicht unkenntlich gemacht werden können, wird er blockiert und Model Armor gibt eine Antwort zurück, die angibt, dass ein Richtlinienverstoß gefunden wurde.
    • Wenn der Prompt vertrauliche Informationen enthält, die unkenntlich gemacht werden können, oder wenn der Prompt keine Probleme aufweist, macht Model Armor alle vertraulichen Informationen unkenntlich und leitet den Prompt weiter.
  7. Wenn die Anfrage von Model Armor zugelassen wird, ruft der Load-Balancer die URL-Zuordnung auf und leitet die Anfrage basierend auf dem benutzerdefinierten Header für den Modellnamen an einen Backend-Dienst weiter. Bei Bedarf schreibt die URL-Zuordnung die URL und den Pfad der Anfrage so um, dass sie den Anforderungen des Backends entsprechen.
  8. Der Backend-Dienst leitet die Anfrage an den zugehörigen Load-Balancer für das Replikatset weiter.
  9. Der Load-Balancer für den jeweiligen Inferenzdienst weist die Anfrage einem seiner Replikate zu.
  10. Das Replikat verarbeitet die Anfrage und sendet eine Antwort zurück.
  11. Der regionale interne Application Load Balancer des Frontends sendet die Antwort zur Überprüfung an Model Armor.
  12. Der Application Load Balancer sendet die Antwort zurück an den Private Service Connect-Endpunkt und weiter an den Endnutzer.

Das folgende Diagramm zeigt eine Routingansicht einer Beispielbereitstellung:

Ablauf von Prompts zum Erstellen von Beispielreplikatsätzen.

In diesem Beispiel werden Prompts je nach dem vom Nutzer ausgewählten Modell verarbeitet:

  • Gemma: Alle Prompts werden an das Replikatset weitergeleitet, das das Gemma-Modell hostet.
  • Llama: Das System verteilt diese Prompts gleichmäßig auf zwei Replikat sets, die beide das Llama-Modell hosten. Diese beiden Replikatsets müssen nicht auf dieselbe Weise gehostet werden. Ein Replikatset kann beispielsweise in Vertex AI und das andere in GKE gehostet werden.
  • LoRA-1-gemma oder LoRA-2-gemma: Das System sendet alle Prompts an dasselbe Replikatset, das beide Modelle verarbeiten kann.

Verwendete Produkte

In der Referenzarchitektur in diesem Dokument werden die folgenden Google Cloud Produkte verwendet:

  • Cloud Load Balancing: Ein Portfolio von leistungsstarken, skalierbaren, globalen und regionalen Load-Balancern.
  • Virtual Private Cloud (VPC): Ein virtuelles System, das globale, skalierbare Netzwerkfunktionen für Ihre Google Cloud Arbeitslasten bietet. VPC umfasst VPC-Netzwerk-Peering, Private Service Connect, Zugriff auf private Dienste und freigegebene VPC.
  • Private Service Connect: Eine Funktion, mit der Nutzer privat aus ihrem VPC-Netzwerk auf verwaltete Dienste zugreifen können.
  • Cloud Run: Eine serverlose Computing-Plattform, mit der Sie Container direkt auf der skalierbaren Infrastruktur von Google ausführen können.
  • Apigee: Ein API-Verwaltungstool, mit dem Sie detailliert steuern können, wie auf Ihre APIs zugegriffen und wie sie verwendet werden. Es bietet Sicherheit, Ratenbegrenzung, Kontingentdurchsetzung und Analysen.
  • Model Armor: Ein Dienst, der Ihre Ressourcen für generative und agentische KI vor Prompt Injection, sensiblen Datenlecks und schädlichen Inhalten schützt.

Designalternativen

In diesem Abschnitt werden Alternativen zu einigen der grundlegenden Annahmen dieser Architektur beschrieben.

KI-Schutzmaßnahmen

Wir empfehlen, Model Armor für KI-Schutzmaßnahmen zu verwenden. Um die Verwaltung zu zentralisieren, empfehlen wir, es wie in dieser Architektur direkt vom Load-Balancer aufzurufen. Sie können Model Armor auch auf folgende alternative Arten implementieren:

  • Model Armor über eine API-Verwaltungsrichtlinie aufrufen.
  • Model Armor nur auf dem Replikat bereitstellen.

Wenn Sie KI-Schutzmaßnahmen außerhalb des Modellendpunkts implementieren, können Sie Model Armor auf dem Frontend-Load-Balancer deaktivieren, wenn Sie es nicht benötigen. Wenn Sie Model Armor nicht verwenden möchten, können Sie mit Diensterweiterungen andere Schutzangebote wie NVIDIA NeMo Guardrails bereitstellen.

API-Verwaltung

Die Architektur in diesem Dokument verwendet Apigee für die API-Verwaltung, das über eine Diensterweiterung für den Load-Balancer bereitgestellt wird. Wenn Apigee Ihre Anforderungen nicht erfüllt, können Sie mit Service Extensions einen anderen API-Verwaltungsdienst bereitstellen.

Wenn die Bereitstellung der API-Verwaltung mit Diensterweiterungen Ihre Anforderungen nicht erfüllt, müssen Sie möglicherweise ein clientseitiges Netzwerk und ein API-seitiges Netzwerk bereitstellen. In diesem Szenario fungiert der API-Verwaltungsdienst als Brücke zwischen den beiden Netzwerken. Informationen zum Bereitstellen dieser Lösung für Apigee finden Sie unter Apigee-Netzwerk optionen.

Verbindung zu anderen Netzwerken herstellen

Die Architektur in diesem Dokument verwendet ein einzelnes VPC-Netzwerk des Verbrauchers. Sie können den Private Service Connect-Endpunkt jedoch für viele andere Netzwerke freigeben, indem Sie in einer Cross-Cloud Network Bereitstellung ein VPC-Netzwerk für den Dienstzugriff verwenden.

Designaspekte

Beachten Sie beim Erstellen der Architektur für Ihre Arbeitslast die Best Practices und Empfehlungen im Google Cloud Well-Architected Framework.

Sicherheit, Datenschutz und Compliance

  • Wenn Sie Ihrer Bereitstellung Schutz vor verteilten Denial-of-Service-(DDoS)-Angriffen, Web Application Firewall (WAF)-Funktionen und IP-Adressprüfung hinzufügen möchten, fügen Sie Cloud Armor Ihrem regionalen internen Application Load Balancer des Frontends hinzu.
  • Wenn Sie allen Back-Ends eine gemeinsame Authentifizierungsebene hinzufügen möchten, implementieren Sie Identity-Aware Proxy (IAP), um die Identität zu bestätigen und Autorisierungsrichtlinien durchzusetzen.
  • Wenn Sie Traffic von einer Webanwendung an ein Vertex AI Modell weiterleiten, müssen Sie ein Identitätsmodell für die Authentifizierungauswählen:
    • Dienstkontoidentität (empfohlen für allgemeine Webanwendungen): Die Anwendung authentifiziert den Endnutzer über IAP, ruft Vertex AI aber mit der Workload Identity des Dienstes auf (z. B. wie Cloud Run, GKE oder mit einer Identität eines Drittanbieters). Bei dieser Implementierung wird Identity and Access Management (IAM) vom Endnutzer abstrahiert. Es ist jedoch eine Protokollierung auf Anwendungsebene erforderlich, um nachzuverfolgen, welcher Nutzer welchen Prompt generiert hat.
    • Passthrough der Endnutzeridentität (empfohlen für strenge Auditierbarkeit): Die Anwendung erfasst das Google OAuth-Zugriffstoken des Endnutzers und übergibt es direkt an Vertex AI im Header Authorization: Bearer. Diese Implementierung bietet eine integrierte Cloud-Audit-Logs-Protokollierung von Nutzer aktionen. Jeder Endnutzer muss jedoch mit Google Cloud IAM-Berechtigungen (z. B. roles/aiplatform.user) bereitgestellt werden.

Zuverlässigkeit

Um sich vor regionalen Ausfällen zu schützen, replizieren Sie Ihre Bereitstellung mit dem Google Cloud multiregionalen Bereitstellungsarchetyp in eine zweite Region.

Operative Effizienz

  • Wenn Sie Trafficflüsse überwachen möchten, um Probleme schnell zu erkennen und zu beheben, verwenden Sie Cloud Logging Logs für Ihren regionalen internen Application Load Balancer.
  • Um die Suche nach den von Ihrer Organisation unterstützten Modellen zu erleichtern, implementieren Sie eine Liste, die abgefragt werden kann, um verfügbare Modelle zurückzugeben. Sie können beispielsweise eine Liste auf einem Server erstellen, der auf den API-Aufruf „Modelle auflisten “ antwortet.

Leistungsoptimierung

Bereitstellung

Wenn Sie eine Beispielimplementierung dieser Architektur bereitstellen möchten, verwenden Sie das Codebeispiel für die Bereitstellung von KI-Inferenzmodellen in Netzwerken, das in GitHub verfügbar ist.

Informationen zum Bereitstellen von KI-Modellen finden Sie in den folgenden Ressourcen:

Nächste Schritte

Beitragende

Autor: Victor Moreno | Product Manager, Cloud Networking

Weitere Beitragende: