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 mit Google Kubernetes Engine (GKE) beschrieben. In der Architektur befinden sich in GKE gehostete Inferenzpools hinter einem GKE Inference Gateway. Diese Architektur bietet folgende Vorteile:

  • Eine einzige Schnittstelle für alle Ihre Inferenzanfragen.
  • Intelligentes Routing jeder 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 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 wie Cross-Cloud Network für verteilte Anwendungen und anderen Designs.

Architektur

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

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

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 Nutzer-VPC-Netzwerk (Virtual Private Cloud). 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 in GKE zu optimieren. Traffic wird anhand des Modellnamens an Inferenzpools von Modellreplikaten weitergeleitet. Das Gateway verwendet den Präfixabgleich, um Traffic innerhalb des Replikatpools weiterzuleiten. Wenn es keine Präfixübereinstimmung gibt, verwendet der Gateway-Inferenzprozessor GPU- oder TPU-Prometheus-Messwerte, um das am wenigsten ausgelastete Replikat im Pool auszuwählen. Der Inferenzprozessor übernimmt 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 auf Grundlage eines regionalen internen Application Load Balancers (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 über den Load Balancer aufzurufen, verwenden die Architektur und die Terraform-Bereitstellung eine Service Extensions-Trafficerweiterung, um den Apigee Extension-Prozessor aufzurufen.
    • Model Armor: Ein KI-Schutzsystem, das Sicherheitsprüfungen für Inferenz-Prompts 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-Guardrails, 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.
  • Inference-Pools: Ein Inference-Pool enthält Replikate desselben Modells. Wenn das Gateway einen Prompt empfängt, wird anhand einer HTTPRoute-Suche ein Inferenzpool basierend auf der Modellkennung ausgewählt. Pools haben eine Anfangsgröße, können aber für das Autoscaling konfiguriert werden.
  • Modellreplikatsätze: Ein Modellreplikat 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 bereitgestellt wird. Wenn das Replikatset mehrere Knoten umfasst, werden die GPUs über ein Backend-RDMA-VPC-Netzwerk miteinander verbunden. Das Netzwerk bietet eine schienenorientierte, verlustfreie Inter-GPU-Vernetzung mit niedriger Latenz.

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 die regionale interne Application Load Balancer-Version des Inference Gateway weiter.
  3. Das Gateway extrahiert den Modellnamen aus dem Anfragetext und fügt ihn mithilfe von textkörperbasiertem Routing in den Anfrageheader ein.
  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 sensible Informationen enthält, die nicht geschwärzt werden können, wird er blockiert und Model Armor gibt eine Antwort zurück, die darauf hinweist, dass ein Richtlinienverstoß festgestellt wurde.
    • Wenn der Prompt vertrauliche Informationen enthält, die entfernt werden können, oder wenn der Prompt überhaupt keine Probleme aufweist, werden alle vertraulichen Informationen entfernt und der Prompt wird weitergeleitet.
  6. Das Gateway ruft HTTPRoute auf, um eine Liste der Inference Pools abzurufen, die dem Modell der Anfrage entsprechen. Das Gateway wählt aus dieser Liste eine Option basierend auf einer Priorität aus.
  7. Das Gateway fragt den Präfix-Cache 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 dann an den Endnutzer.

Das folgende Diagramm zeigt eine Routingansicht einer Beispielbereitstellung.

Ablauf von Prompts zum Erstellen von Stichproben von Replikatsets.

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

  • Llama: Das System führt für diese Prompts ein Load-Balancing im Verhältnis 90/10 zwischen zwei Replikatgruppen durch, die beide das Llama-Modell hosten. Diese beiden Replikatsätze müssen nicht auf dieselbe Weise gehostet werden. Ein Replikatsatz könnte beispielsweise in der Gemini Enterprise Agent Platform und der andere in GKE gehostet werden.
  • LoRA-1-gemma oder LoRA-2-gemma: Das System sendet alle Prompts an denselben Replikasatz, der beide Modelle verarbeiten kann.

In allen Fällen verwendet das Gateway eine Kombination aus Präfixabgleich und geringster Last, um ein Replikat im entsprechenden Pool auszuwählen.

Verwendete Produkte

In dieser Referenzarchitektur werden die folgenden Google CloudProdukte 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 Gateway, die optimiertes Routing und Load-Balancing für die Bereitstellung von generativen KI-Arbeitslasten bietet. Es vereinfacht die Bereitstellung, Verwaltung und Beobachtbarkeit von KI-Inferenz-Arbeitslasten.
  • 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 ist 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 genau festlegen können, wie auf Ihre APIs zugegriffen und wie sie verwendet werden. Sie bietet Sicherheit, Ratenbegrenzung, Kontingenterzwingung und Analysen.
  • Model Armor: Ein Dienst, der Ihre Ressourcen für generative und agentenbasierte KI vor Prompt Injections, Lecks sensibler Daten 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, sie direkt vom Load-Balancer aufzurufen, wie in dieser Architektur. Sie können Model Armor auch auf folgende alternative Arten implementieren:

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

Wenn Sie KI-Schutzmaßnahmen an anderer Stelle 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 Traffic-Erweiterungen verwenden, um andere Guardrail-Angebote wie NVIDIA NeMo Guardrails bereitzustellen.

API-Verwaltung

Die Architektur in diesem Dokument verwendet Apigee für die API-Verwaltung, die mit einer Load-Balancer-Diensterweiterung bereitgestellt wird. Wenn Apigee nicht Ihren Anforderungen entspricht, können Sie mit Service Extensions einen anderen API-Verwaltungsdienst bereitstellen.

Wenn die Bereitstellung der API-Verwaltung mit Dienst-Extensions nicht Ihren Anforderungen entspricht, 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-Netzwerkoptionen.

Verbindung zu anderen Netzwerken herstellen

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

Designaspekte

Berücksichtigen 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 DDoS-Schutz (Distributed Denial of Service), WAF-Funktionen (Web Application Firewall) und IP-Adressenprüfung hinzufügen möchten, fügen Sie Ihrem regionalen internen Application Load Balancer für das Frontend Google Cloud Armor hinzu.

Zuverlässigkeit

Um sich vor regionalen Ausfällen zu schützen, replizieren Sie Ihre Bereitstellung in einer zweiten Region mit dem Google Cloud Archetyp für multiregionale Bereitstellungen.

Kostenoptimierung

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

Operative Effizienz

Sie können die Leistung Ihrer Inference Gateway-Anfragen mit dem Inference Gateway-Dashboard überwachen. Das Dashboard zeigt Fehler und Messwerte wie Anforderungsrate, Latenz und Sättigung an. Mithilfe der Ergebnisse im Dashboard können Sie Ihre Bereitstellung optimieren.

Leistungsoptimierung

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

Bereitstellung

Wenn Sie eine Beispielimplementierung dieser Architektur bereitstellen möchten, verwenden Sie das Codebeispiel Networking for AI Inference Model Serving, das auf GitHub verfügbar ist.

Nächste Schritte

Beitragende

Autor: Victor Moreno | Product Manager, Cloud Networking

Weitere Beitragende: