GKE Inference Gateway

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

---

Auf dieser Seite wird das GKE-Inference Gateway (Google Kubernetes Engine) vorgestellt, eine Erweiterung des GKE-Gateways für die optimierte Bereitstellung generativer KI-Anwendungen. Dort werden die wichtigsten Konzepte, Funktionen und die Funktionsweise des GKE Inference Gateways erläutert.

Diese Seite richtet sich an folgende Personas:

• Entwickler von maschinellem Lernen (ML), Plattformadministratoren und ‑betreiber sowie Daten- und KI-Spezialisten, die Kubernetes-Container-Orchestrierungsfunktionen für die Bereitstellung von KI-/ML-Arbeitslasten nutzen möchten.
• Cloud-Architekten und Netzwerkspezialisten, die mit Kubernetes-Netzwerken arbeiten

Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Themen vertraut:

• KI‑/ML-Orchestrierung in der GKE
• Glossar zu generativer KI
• GKE-Netzwerkkonzepte, einschließlich Diensten und der GKE Gateway API
• Load Balancing inGoogle Cloud, insbesondere die Interaktion von Load Balancern mit GKE.

Übersicht

Das GKE Inference Gateway ist eine Erweiterung des GKE-Gateways, das optimiertes Routing und Load Balancing für die Bereitstellung von generativen KI-Arbeitslasten (Künstliche Intelligenz) bietet. Sie vereinfacht die Bereitstellung, Verwaltung und Beobachtbarkeit von KI-Inferenzarbeitslasten.

Features und Vorteile

Das GKE Inference Gateway bietet die folgenden wichtigen Funktionen, um generative KI-Modelle für generative KI-Anwendungen in GKE effizient bereitzustellen:

• Optimiertes Load Balancing für Inferenzen: Anfragen werden verteilt, um die Leistung der Bereitstellung von KI-Modellen zu optimieren. Dabei werden Messwerte von Modellservern wie KVCache Utilization und queue length of pending requests verwendet, um Beschleuniger wie GPUs und TPUs effizienter für generative KI-Arbeitslasten zu nutzen.
• Bereitstellung optimierter LoRA-Modelle: Unterstützt die Bereitstellung optimierter LoRA-Modelle auf einem gemeinsamen Accelerator. Dadurch wird die Anzahl der GPUs und TPUs reduziert, die für die Bereitstellung von Modellen erforderlich sind, da mehrere optimierte LoRA-Modelle auf einem gemeinsamen Basismodell und Beschleuniger multiplext werden.
• Optimiertes Autoscaling für die Inferenz: Der horizontale Pod-Autoscaler (HPA) von GKE verwendet Modellservermesswerte für das automatische Skalieren. So wird eine effiziente Nutzung der Rechenressourcen und eine optimierte Inferenzleistung sichergestellt.
• Modellorientiertes Routing: Leitet Inferenzanfragen anhand der Modellnamen weiter, die in den OpenAI API-Spezifikationen in Ihrem GKE-Cluster definiert sind. Sie können Gateway-Routingrichtlinien wie Traffic Splitting und Anfragespiegelung definieren, um verschiedene Modellversionen zu verwalten und das Modell-Roll-out zu vereinfachen. So können Sie Anfragen für einen bestimmten Modellnamen beispielsweise an verschiedene InferencePool-Objekte weiterleiten, die jeweils eine andere Version des Modells bereitstellen.
• Modellspezifische BereitstellungCriticality: Hier können Sie die BereitstellungCriticality von KI-Modellen angeben. Priorisieren Sie latenzabhängige Anfragen gegenüber latenztoleranten Batch-Inferenzjobs. So können Sie beispielsweise Anfragen von latenzempfindlichen Anwendungen priorisieren und weniger zeitkritische Aufgaben bei knappen Ressourcen fallen lassen.
• Integrierte KI-Sicherheit: Bietet eine Einbindung in Google Cloud Model Armor, einen Dienst, der Prompts und Antworten am Gateway auf KI-Sicherheit prüft. Model Armor bietet Protokolle zu Anfragen, Antworten und Verarbeitung für die retrospektive Analyse und Optimierung. Über die offenen Schnittstellen des GKE Inference Gateway können Drittanbieter und Entwickler benutzerdefinierte Dienste in den Prozess für Inferenzanfragen einbinden.
• Beobachtbarkeit von Inferenzen: Bietet Messwerte zur Beobachtbarkeit von Inferenzanfragen, z. B. Anfragerate, Latenz, Fehler und Sättigung. Leistung und Verhalten Ihrer Inferenzdienste im Blick behalten

Schlüsselkonzepte

GKE Inference Gateway erweitert das vorhandene GKE Gateway, das GatewayClass-Objekte verwendet. Das GKE Inference Gateway führt die folgenden neuen benutzerdefinierten Gateway API-Ressourcendefinitionen (CRDs) ein, die der OSS Kubernetes Gateway API-Erweiterung für die Inferenz entsprechen:

• InferencePool-Objekt: Stellt eine Gruppe von Pods (Containern) dar, die dieselbe Compute-Konfiguration, denselben Beschleunigertyp, dasselbe Basissprachmodell und denselben Modellserver verwenden. So werden die Ressourcen für die Bereitstellung Ihres KI-Modells logisch gruppiert und verwaltet. Ein einzelnes InferencePool-Objekt kann mehrere Pods auf verschiedenen GKE-Knoten umfassen und bietet Skalierbarkeit und Hochverfügbarkeit.
• InferenceModel-Objekt: Gibt den Namen des Auslieferungsmodells aus dem InferencePool gemäß der OpenAI API-Spezifikation an. Im InferenceModel-Objekt werden auch die Auslieferungseigenschaften des Modells angegeben, z. B. die Criticality des KI-Modells. Das GKE-Inference-Gateway bevorzugt Arbeitslasten, die als Critical klassifiziert sind. So können Sie latenzkritische und latenztolerante KI-Arbeitslasten in einem GKE-Cluster multiplexen. Sie können das InferenceModel-Objekt auch so konfigurieren, dass optimierte LoRA-Modelle ausgeliefert werden.
• TargetModel-Objekt: Gibt den Namen des Zielmodells und das InferencePool-Objekt an, das das Modell bereitstellt. So können Sie Gateway-Routing-Richtlinien wie Traffic-Aufteilung und Anfragen-Mirroring definieren und die Einführung von Modellversionen vereinfachen.

Das folgende Diagramm zeigt das GKE Inference Gateway und seine Integration mit KI-Sicherheit, Beobachtbarkeit und Modellbereitstellung in einem GKE-Cluster.

Das folgende Diagramm zeigt das Ressourcenmodell, das sich auf zwei neue Personas mit Schwerpunkt auf Inferenzen und die von ihnen verwalteten Ressourcen konzentriert.

Funktionsweise von GKE Inference Gateway

Das GKE Inference Gateway verwendet Gateway API-Erweiterungen und modellspezifische Routinglogik, um Clientanfragen an ein KI-Modell zu verarbeiten. In den folgenden Schritten wird der Anfrageablauf beschrieben.

So funktioniert der Anfrageablauf

Das GKE Inference Gateway leitet Clientanfragen von der ursprünglichen Anfrage an eine Modellinstanz weiter. In diesem Abschnitt wird beschrieben, wie das GKE Inference Gateway Anfragen verarbeitet. Dieser Ablauf ist für alle Kunden gleich.

1. Der Client sendet eine Anfrage, die wie in der OpenAI API-Spezifikation beschrieben formatiert ist, an das Modell, das in GKE ausgeführt wird.
2. Das GKE-Inference-Gateway verarbeitet die Anfrage mit den folgenden Inferenzerweiterungen:
   1. Body-based Routing Extension: Hier wird die Modell-ID aus dem Clientanfrage-Body extrahiert und an das GKE Inference Gateway gesendet. GKE Inference Gateway verwendet diese Kennung dann, um die Anfrage basierend auf Regeln weiterzuleiten, die im HTTPRoute-Objekt der Gateway API definiert sind. Das Routing über den Anfragetext ähnelt dem Routing basierend auf dem URL-Pfad. Der Unterschied besteht darin, dass beim Routing des Anfragetexts Daten aus dem Anfragetext verwendet werden.
   2. Sicherheitserweiterung: Hier werden Model Armor oder unterstützte Lösungen von Drittanbietern verwendet, um modellspezifische Sicherheitsrichtlinien durchzusetzen, die Inhaltsfilterung, Bedrohungserkennung, Bereinigung und Protokollierung umfassen. Die Sicherheitserweiterung wendet diese Richtlinien sowohl auf Anfrage- als auch auf Antwortverarbeitungspfade an. So kann die Sicherheitserweiterung sowohl Anfragen als auch Antworten bereinigen und protokollieren.
   3. Erweiterung „Endpunktauswahl“: Überwacht wichtige Messwerte von Modellservern innerhalb der InferencePool. Es wird die Auslastung des Schlüssel/Wert-Caches (KV-Cache), die Warteschlangenlänge ausstehender Anfragen und die aktiven LoRA-Adapter auf jedem Modellserver erfasst. Anhand dieser Messwerte wird die Anfrage an das optimale Modellreplikat weitergeleitet, um die Latenz zu minimieren und den Durchsatz für die KI-Inferenz zu maximieren.
3. Das GKE Inference Gateway leitet die Anfrage an das Modellreplikat weiter, das von der Erweiterung „Endpunktauswahl“ zurückgegeben wird.

Das folgende Diagramm veranschaulicht den Anfragefluss von einem Client über das GKE Inference Gateway an eine Modellinstanz.

Funktionsweise der Trafficverteilung

Das GKE-Inferenz-Gateway verteilt Inferenzanfragen dynamisch an Modellserver innerhalb des InferencePool-Objekts. So wird die Ressourcennutzung optimiert und die Leistung bei unterschiedlichen Lastbedingungen aufrechterhalten. GKE Inference Gateway verwendet die folgenden beiden Mechanismen, um die Trafficverteilung zu verwalten:

• Endpunktauswahl: Der am besten geeignete Modellserver für die Verarbeitung einer Inferenzanfrage wird dynamisch ausgewählt. Er überwacht die Serverlast und -verfügbarkeit und trifft dann Routingentscheidungen.

• Warteschlangen und Aussetzung: Hiermit wird der Anfragefluss verwaltet und eine Verkehrsüberlastung verhindert. Das GKE Inference Gateway speichert eingehende Anfragen in einer Warteschlange, priorisiert sie anhand definierter Kriterien und verwirft sie, wenn das System überlastet ist.

Das GKE-Inference-Gateway unterstützt die folgenden Criticality-Ebenen:

• Critical: Diese Arbeitslasten werden priorisiert. Das System sorgt dafür, dass diese Anfragen auch bei Ressourceneinschränkungen verarbeitet werden.
• Standard: Diese Arbeitslasten werden ausgeführt, wenn Ressourcen verfügbar sind. Wenn die Ressourcen begrenzt sind, werden diese Anfragen verworfen.
• Sheddable: Diese Arbeitslasten werden opportunistisch ausgeführt. Wenn Ressourcen knapp sind, werden diese Anfragen abgelehnt, um Critical-Arbeitslasten zu schützen.

Wenn das System unter Ressourcendruck steht, werden Standard- und Sheddable-Anfragen sofort mit dem Fehlercode 429 abgelehnt, um Critical-Arbeitslasten zu schützen.

Streaming-Inferenz

GKE Inference Gateway unterstützt die Streaming-Inferenz für Anwendungen wie Chatbots und Liveübersetzungen, die kontinuierliche oder nahezu Echtzeit-Aktualisierungen erfordern. Bei der Streaming-Inferenz werden Antworten in inkrementellen Teilen oder Segmenten statt als einzelne vollständige Ausgabe geliefert. Wenn während einer Streamingantwort ein Fehler auftritt, wird der Stream beendet und der Client erhält eine Fehlermeldung. GKE Inference Gateway versucht nicht, Streamingantworten noch einmal zu senden.

Anwendungsbeispiele ansehen

In diesem Abschnitt finden Sie Beispiele für verschiedene Anwendungsfälle für generative KI, die mit dem GKE Inference Gateway umgesetzt werden können.

Beispiel 1: Mehrere generative KI-Modelle in einem GKE-Cluster bereitstellen

Ein Unternehmen möchte mehrere Large Language Models (LLMs) bereitstellen, um verschiedene Arbeitslasten zu bedienen. Beispielsweise kann er ein Gemma3-Modell für eine Chatbot-Benutzeroberfläche und ein Deepseek-Modell für eine Empfehlungsanwendung bereitstellen. Das Unternehmen muss für diese LLMs eine optimale Auslieferungsleistung sicherstellen.

Mit dem GKE Inference Gateway können Sie diese LLMs mit der ausgewählten Beschleunigerkonfiguration in einem InferencePool in Ihrem GKE-Cluster bereitstellen. Anschließend können Sie Anfragen basierend auf dem Modellnamen (z. B. chatbot und recommender) und dem Attribut Criticality weiterleiten.

Das folgende Diagramm zeigt, wie das GKE Inference Gateway Anfragen basierend auf dem Modellnamen und Criticality an verschiedene Modelle weiterleitet.

Beispiel 2: LoRA-Adapter auf einem freigegebenen Beschleuniger bereitstellen

Ein Unternehmen möchte LLMs für die Dokumentenanalyse verwenden und konzentriert sich auf Zielgruppen in mehreren Sprachen, z. B. Englisch und Spanisch. Sie haben Modelle für jede Sprache optimiert, müssen aber ihre GPU- und TPU-Kapazität effizient nutzen. Mit dem GKE Inference Gateway können Sie dynamische, für LoRA optimierte Adapter für jede Sprache (z. B. english-bot und spanish-bot) auf einem gemeinsamen Basismodell (z. B. llm-base) und Beschleuniger bereitstellen. So können Sie die Anzahl der erforderlichen Beschleuniger reduzieren, indem Sie mehrere Modelle auf einem gemeinsamen Beschleuniger dicht packen.

Das folgende Diagramm zeigt, wie das GKE Inference Gateway mehrere LoRA-Adapter auf einem freigegebenen Accelerator bedient.

Nächste Schritte

• GKE Inference Gateway bereitstellen
• Konfiguration des GKE Inference Gateways anpassen
• LLM mit GKE Inference Gateway bereitstellen