Netzwerkfunktionen für die Bereitstellung von KI-Inferenzmodellen in GKE

Last reviewed 2026-05-20 UTC

In diesem Dokument wird eine Referenzarchitektur zum Erstellen eines Inferenzdienstes mit mehreren Modellen mithilfe von Google Kubernetes Engine (GKE) beschrieben. In der Architektur, werden in GKE gehostete Inferenzpools hinter einem GKE Inference Gateway platziert. Diese Architektur bietet die folgenden Vorteile:

  • Eine einzige Schnittstelle für alle Ihre Inferenzanfragen.
  • Intelligentes Routing für jede Anfrage an das Modell und den Inferenzserver, der sie am effizientesten verarbeiten kann.
  • Zentrale Autorisierung, Sicherheit und andere Dienste.

Dieses Dokument richtet sich an Netzwerkarchitekten, die für die Vereinheitlichung der Bereitstellung von Inferenzservern verantwortlich sind, die in GKE ausgeführt werden. Wenn nicht alle Ihre Inferenzserver in GKE gehostet werden, lesen Sie den Artikel Netzwerk für die Bereitstellung von KI-Inferenzmodellen auf allen Back-Ends. 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 Cross-Cloud Network für verteilte Anwendungen und anderen Designs.

Architektur

Das folgende Diagramm zeigt eine Architektur mit einem Inference Gateway vor in GKE gehosteten Inferenzservern. Das Gateway bietet konsolidierte Dienste für alle gehosteten Modelle.

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

Die Architektur im Diagramm enthält 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 Nutzers. Sie können Endpunkte in mehreren VPC-Netzwerken oder in einem VPC-Netzwerk für freigegebene Dienste hosten.
  • Inference Gateway: Das Inference Gateway erweitert das GKE Gateway , um die Bereitstellung generativer KI-Anwendungen und Arbeitslasten durch GKE zu optimieren. Es leitet Traffic basierend auf dem Modellnamen an Inferenzpools von Modellreplikaten weiter. Das Gateway verwendet die Präfixübereinstimmung, um Traffic innerhalb des Replikatpools weiterzuleiten. Wenn keine Präfixübereinstimmung vorhanden ist, wählt der Gateway-Inferenzprozessor mithilfe von GPU- oder TPU-Prometheus-Messwerten das am wenigsten ausgelastete Replikat im Pool aus. Der Inferenzprozessor verarbeitet auch das Präfix-Caching. In dieser Architektur ruft die kundenorientierte Anwendung die OpenAI API auf, um über das Gateway auf die Modelle zuzugreifen. Das Gateway wird basierend auf einem regionalen internen Application Load Balancer (gke-l7-rilb) bereitgestellt und ist daher nicht direkt über das Internet zugänglich.
    • API-Verwaltung: Ein API-Manager bietet API-Authentifizierung, Sicherheit, Ratenbegrenzung, Kontingentverfolgung und andere API-Verwaltungsdienste. In dieser Architektur wird Apigee verwendet, aber die Architektur unterstützt auch andere Optionen. Um Apigee vom Load Balancer aufzurufen, verwenden die Architektur und die Terraform-Bereitstellung eine Service Extensions Trafficerweiterung, um den Apigee-Erweiterung Prozessor aufzurufen.
    • Model Armor: Ein KI-Schutzsystem, das Sicherheitsprüfungen für Inferenzprompts durchführt, bevor sie an den Inferenzserver gesendet werden. Anschließend werden Sicherheitsprüfungen für die ausgehenden Antworten durchgeführt. In dieser Architektur wird Model Armor für KI-Schutzmaßnahmen verwendet, aber es werden auch andere Optionen wie NVIDIA Nemo Guardrails unterstützt. Die Terraform-Bereitstellung, die mit dieser Referenzarchitektur bereitgestellt wird, enthält eine grundlegende Model Armor-Konfiguration.
  • Inferenzpools: Ein Inferenzpool enthält Replikate desselben Modells. Wenn das Gateway einen Prompt empfängt, wird mit einer HTTPRoute Suche ein Inferenzpool basierend auf der Modell-ID ausgewählt. Pools haben eine Anfangsgröße, können aber für das Autoscaling konfiguriert werden.
  • 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, vor der ein Load Balancer platziert ist. Wenn das Replikatset mehrere Knoten umfasst, werden die GPUs über ein Backend-RDMA-VPC-Netzwerk miteinander verbunden. Das Netzwerk bietet eine auf die Schiene ausgerichtete verlustfreie Low-Latency-Netzwerkverbindung zwischen GPUs.

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:
    • Den Prompt.
    • Den Modellnamen, der mit dem Modellnamen eines der gehosteten Inferenzserver übereinstimmen muss.
  2. Der Private Service Connect-Endpunkt leitet die Anfrage an die regionale interne Application Load Balancer-Version des Inference Gateway weiter.
  3. Das Gateway extrahiert den Modellnamen aus dem Anfragetext und fügt ihn in den Anfrageheader mithilfe des textbasierten Routingsein.
  4. Das Gateway leitet die Anfrage an das API-Verwaltungssystem für die erforderlichen API-Verwaltungsdienste weiter.
  5. Das Gateway sendet den Prompt zur Überprüfung an Model Armor.
    • 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.
  6. Das Gateway fragt HTTPRoute nach einer Liste von Inferenzpools ab, die dem Modell der Anfrage entsprechen. Aus dieser Liste wählt das Gateway einen Pool basierend auf einer Priorität aus.
  7. Das Gateway fragt den Präfixcache und die aktuelle Last für alle Replikate im Pool ab und wählt dann anhand dieser Informationen ein Replikat aus.
  8. Das Replikat verarbeitet die Anfrage und sendet sie zurück an das Gateway.
  9. Das Gateway sendet die Antwort zur Genehmigung oder Ablehnung an Model Armor.
  10. Das Gateway 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:

  • Llama: Das System verteilt diese Prompts im Verhältnis 90:10 auf zwei Replikatsets, 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.

In allen Fällen wählt das Gateway mithilfe einer Kombination aus Präfixübereinstimmung und geringster Last ein Replikat im entsprechenden Pool aus.

Verwendete Produkte

In dieser Referenzarchitektur werden die folgenden Google Cloud Produkte verwendet:

  • Google Kubernetes Engine (GKE): Ein Kubernetes-Dienst, mit dem Sie Containeranwendungen in großem Maßstab mithilfe der Infrastruktur von Google bereitstellen und betreiben können.
  • GKE Inference Gateway: Eine Erweiterung des Google Kubernetes Engine-Gateways, die optimiertes Routing und Load Balancing für die Bereitstellung generativer KI-Arbeitslasten bietet. Es vereinfacht die Bereitstellung, Verwaltung und Beobachtbarkeit von KI-Inferenzarbeitslasten.
  • 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, Kontingenterzwingung und Analysen.
  • Model Armor: Ein Dienst, der Ihre generativen und agentischen KI Ressourcen vor Prompt Injections, 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:

  • Verwenden Sie eine API-Verwaltungsrichtlinie, um Model Armor aufzurufen.
  • Stellen Sie Model Armor nur auf dem Replikat bereit.

Wenn Sie KI-Schutzmaßnahmen an einem anderen Ort als am Modellendpunkt implementieren, können Sie Model Armor am Frontend-Load-Balancer deaktivieren, wenn Sie es nicht benötigen. Wenn Sie Model Armor nicht verwenden möchten, können Sie Trafficerweiterungen verwenden, um andere Schutzangebote wie NVIDIA NeMo Guardrails bereitzustellen.

API-Verwaltung

Die Architektur in diesem Dokument verwendet Apigee für die API-Verwaltung, die mit einer Load Balancer-Serviceerweiterung 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 Service Extensions 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 Nutzers. 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 die Überprüfung von IP-Adressen hinzufügen möchten, fügen Sie Ihrem regionalen internen Application Load Balancer im Frontend Google Cloud Armor hinzu.

Zuverlässigkeit

Um sich vor regionalen Ausfällen zu schützen, replizieren Sie Ihre Bereitstellung mithilfe des Google Cloud multiregionalen Bereitstellungs archetyps in eine zweite Region.

Kostenoptimierung

Empfehlungen zur Kostenoptimierung für GKE finden Sie unter Best Practices zum Ausführen kostenoptimierter Kubernetes-Anwendungen in GKE.

Operative Effizienz

Überwachen Sie die Leistung Ihrer Inference Gateway-Inferenz anfragen mit dem Inference Gateway Dashboard. Das Dashboard zeigt Fehler und Messwerte wie Anforderungsrate, Latenz und Sättigung an. Verwenden Sie die Ergebnisse im Dashboard, um Ihre Bereitstellung zu optimieren.

Leistungsoptimierung

Folgen Sie den Empfehlungen unter Übersicht über Best Practices für die Inferenz in GKE.

Bereitstellung

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

Nächste Schritte

Beitragende

Autor: Victor Moreno | Product Manager, Cloud Networking

Weitere Beitragende: