GKE Inference Gateway mit llm-d

Auf dieser Seite werden die wichtigsten Konzepte und Funktionen des GKE Inference Gateway (Google Kubernetes Engine) erläutert. Das GKE Inference Gateway ist eine Erweiterung des GKE Gateway, mit der die Bereitstellung generativer KI-Anwendungen optimiert wird.

Auf dieser Seite wird davon ausgegangen, dass Sie mit den folgenden Themen vertraut sind:

• KI‑/ML-Orchestrierung in der GKE
• Terminologie für generative KI
• GKE-Netzwerkkonzepte, einschließlich Dienste, und der GKE Gateway API
• Load-Balancing in GKE Cloud de Confiance, insbesondere die Interaktion von Load Balancern mit GKE

Diese Seite richtet sich an die folgenden Personen:

• Machine-Learning-Entwickler (ML), Plattformadministratoren und ‑operatoren sowie Daten- und KI-Spezialisten, die Kubernetes-Container-Orchestrierungsfunktionen zum Bereitstellen von KI‑/ML-Arbeitslasten verwenden möchten.
• Cloud-Architekten und Netzwerkspezialisten, die mit Kubernetes-Netzwerken arbeiten.

Übersicht

Das GKE Inference Gateway ist eine Erweiterung des GKE Gateway, die optimiertes Routing und Load-Balancing für die Bereitstellung generativer KI-Arbeitslasten bietet. Es vereinfacht die Bereitstellung, Verwaltung und Beobachtbarkeit von KI-Inferenzarbeitslasten. Das GKE Inference Gateway ist ohne zusätzliche Kosten verfügbar. Sie zahlen nur für die zugrunde liegenden Cloud de Confiance by S3NS Ressourcen die verwendet werden.

Informationen zum Auswählen der optimalen Load-Balancing-Strategie für Ihre KI‑/ML-Arbeitslasten finden Sie unter Load-Balancing-Strategie für KI-Inferenz in GKE auswählen.

Funktionen und Vorteile

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

• Unterstützte Messwerte:
  • KV cache hits: Die Anzahl der erfolgreichen Suchvorgänge im Schlüssel/Wert-Cache (KV-Cache).
  • GPU- oder TPU-Auslastung: Der Prozentsatz der Zeit, in der die GPU oder TPU aktiv verarbeitet wird.
  • Länge der Anfragewarteschlange: Die Anzahl der Anfragen, die auf die Verarbeitung warten.
• Optimiertes Load-Balancing für die Inferenz: Verteilt Anfragen, um die Modellbereitstellungsleistung von KI-Modellen zu optimieren. Es verwendet Messwerte von Modellservern wie KV cache hits und die queue length of pending requests, um Beschleuniger (z. B. GPUs und TPUs) für generative KI-Arbeitslasten effizienter zu nutzen. Dies ermöglicht Prefix-Cache Aware Routing, eine wichtige Funktion, die Anfragen mit gemeinsamem Kontext, die durch die Analyse des Anfragetexts identifiziert werden, an dieselbe Modellreplikat sendet, indem Cache-Treffer maximiert werden. Dieser Ansatz reduziert redundante Berechnungen erheblich und verbessert die Zeit bis zum ersten Token (Time-to-First-Token, TTFT). Dadurch ist er sehr effektiv für konversationelle KI, Retrieval-Augmented Generation (RAG) und andere vorlagenbasierte generative KI-Arbeitslasten.
• Bereitstellung dynamischer LoRA-Modelle: Unterstützt die Bereitstellung dynamischer LoRA Modelle auf einem gemeinsamen Beschleuniger. Dadurch wird die Anzahl der GPUs und TPUs reduziert, die zum Bereitstellen von Modellen erforderlich sind, indem mehrere LoRA-Modelle auf einem gemeinsamen Basismodell und Beschleuniger gemultiplext werden.
• Optimiertes Autoscaling für die Inferenz: Der GKE Horizontal Pod Autoscaler (HPA) verwendet Messwerte des Modellservers für das Autoscaling, so wird eine effiziente Nutzung der Rechenressourcen und eine optimierte Inferenz leistung gewährleistet.
• Modellbasiertes Routing: Leitet Inferenzanfragen basierend auf den Modellnamen weiter, die in den OpenAI API Spezifikationen in Ihrem GKE-Cluster definiert sind. Sie können Gateway-Routingrichtlinien wie Trafficaufteilung und Anfragespiegelung definieren, um verschiedene Modellversionen zu verwalten und Modell-Roll-outs zu vereinfachen. Sie können beispielsweise Anfragen für einen bestimmten Modellnamen an verschiedene InferencePool-Objekte weiterleiten, die jeweils eine andere Version des Modells bereitstellen. Weitere Informationen zum Konfigurieren finden Sie unter Textkörperbasiertes Routing konfigurieren.
• Integrierte KI-Sicherheit und Inhaltsfilterung: Das GKE Inference Gateway ist in Cloud de Confiance Model Armor integriert, um KI-Sicherheitsprüfungen und Inhaltsfilterung auf Prompts und Antworten am Gateway anzuwenden. Sie können auch NVIDIA NeMo Guardrails verwenden. Model Armor stellt Logs von Anfragen, Antworten und Verarbeitung für die nachträgliche Analyse und Optimierung bereit. Die offenen Schnittstellen des GKE Inference Gateway ermöglichen es Drittanbietern und Entwicklern, benutzerdefinierte Dienste in den Inferenzanfrageprozess zu integrieren.
• Modellspezifische Bereitstellung Priority: Ermöglicht die Angabe der Bereitstellung Priority von KI-Modellen. Priorisieren Sie latenzempfindliche Anfragen gegenüber latenzunempfindlichen Batch-Inferenzjobs. Sie können beispielsweise Anfragen von latenzempfindlichen Anwendungen priorisieren und weniger zeitkritische Aufgaben verwerfen, wenn die Ressourcen begrenzt sind.
• Routing basierend auf der vorhergesagten Latenz: Leitet Inferenzanfragen mithilfe eines XGBoost-Modells weiter, das kontinuierlich mit Live-Traffic trainiert wird, und optimiert so die Ziele für die Zeit bis zum ersten Token (Time-to-First-Token, TTFT) und die Zeit pro Ausgabetoken (Time-per-Output-Token, TPOT) pro Anfrage. Bei Arbeitslasten mit hoher Varianz genauer als statische Heuristiken. Weitere Informationen finden Sie unter Routing basierend auf der vorhergesagten Latenz mit dem GKE Inference Gateway verwenden.
• Beobachtbarkeit der Inferenz: Bietet Messwerte zur Beobachtbarkeit für Inferenzanfragen, z. B. Anforderungsrate, Latenz, Fehler und Auslastung. Sie können die Leistung und das Verhalten Ihrer Inferenzdienste über Cloud Monitoring und Cloud Logging überwachen und dabei spezielle vorgefertigte Dashboards für detaillierte Einblicke nutzen. Weitere Informationen finden Sie unter GKE Inference Gateway-Dashboard ansehen.
• CORS-Konfiguration: Unterstützt Cross-Origin Resource Sharing (CORS) für HTTPRoute Ressourcen. CORS ermöglicht Webanwendungen, die in verschiedenen Domains ausgeführt werden, den sicheren Zugriff auf Ihre Inferenzendpunkte. CORS wird für Single-Cluster-Gateways unterstützt.
• Erweiterte API-Verwaltung mit Apigee: Ist in Apigee integriert, um Ihr Inferenzgateway um Funktionen wie API-Sicherheit, Ratenbegrenzung und Kontingente zu erweitern. Eine detaillierte Anleitung finden Sie unter Apigee für die Authentifizierung und API Verwaltung konfigurieren.
• Erweiterbarkeit: Basiert auf einer erweiterbaren Open-Source-Kubernetes Gateway API Inference Extension, die einen vom Nutzer verwalteten llm-d Endpoint Picker (EPP)-Algorithmus unterstützt, der von llm-d unterstützt wird. Der llm-d Endpoint Picker (EPP) -Algorithmus, der von llm-d unterstützt wird, bietet die grundlegende Routingintelligenz für diese Erweiterung.
• Unterstützung für mehrere Ports: Unterstützt Modellserver, die mehrere Ports bereitstellen. Dies ist für erweiterte Bereitstellungsszenarien wie Data Parallel Attention unerlässlich.
• Limits für Netzwerk-Endpunktgruppen (NEGs): Es gilt ein Limit von 50 NEGs pro Cloud de Confiance by S3NS Backend-Dienst. Bei Verwendung eines InferencePool mit mehreren Ports wird für jeden Port in jeder Zone eine eigene NEG erstellt. Ein InferencePool mit acht Ports in einem typischen regionalen Cluster (drei Zonen) generiert beispielsweise 24 NEGs. Daher kann ein Multi-Cluster-Gateway einen solchen InferencePool nur aus maximal zwei Clustern aggregieren (zwei Cluster × 24 NEGs = 48 NEGs), bevor das Limit von 50 NEGs erreicht wird.

Schlüsselkonzepte

Das GKE Inference Gateway erweitert das vorhandene GKE Gateway, das GatewayClass Objekte verwendet. Das GKE Inference Gateway führt die folgenden neuen Gateway API Custom Resource Definitions (CRDs) ein, die mit der OSS Kubernetes Gateway API-Erweiterung für Inferenz übereinstimmen:

• InferencePool-Objekt: Stellt eine Gruppe von Pods (Containern) dar, die dieselbe Rechenkonfiguration, denselben Beschleunigertyp, dasselbe Language Model und denselben Modellserver verwenden. So werden Ihre Ressourcen für die Bereitstellung von KI-Modellen logisch gruppiert und verwaltet. Ein einzelnes InferencePool-Objekt kann mehrere Pods auf verschiedenen GKE-Knoten umfassen und bietet Skalierbarkeit und hohe Verfügbarkeit. Sie können bis zu acht targetPorts in einer InferencePool-Ressource angeben, um Modellserver zu unterstützen, die mehrere Ports erfordern.
• InferenceObjective-Objekt: Gibt den Namen des Bereitstellungsmodells aus dem InferencePool gemäß der OpenAI API Spezifikation an. Das InferenceObjective-Objekt gibt auch die Bereitstellungseigenschaften des Modells an, z. B. die Priority des KI-Modells. Das GKE Inference Gateway bevorzugt Arbeitslasten mit einem höheren Prioritätswert. So können Sie latenzkritische und latenzunempfindliche KI-Arbeitslasten in einem GKE-Cluster multiplexen. Sie können das InferenceObjective-Objekt auch so konfigurieren, dass LoRA-Modelle bereitgestellt werden.

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

Das folgende Diagramm veranschaulicht das Ressourcenmodell, das sich auf zwei neue inferenzorientierte Personas und die von ihnen verwalteten Ressourcen konzentriert.

llm-d-Router

Der llm-d-Router ist die intelligente Komponente für das Anfragerouting, die das Inference Gateway verwendet, um Endpunktentscheidungen pro Anfrage zu treffen. Er besteht aus zwei Unterkomponenten:

Gateway-Modus

Das GKE Inference Gateway ist der llm-d Router im Gateway-Modus. Im Gateway-Modus ist der Proxy ein formelles Kubernetes Gateway, das unabhängig vom EPP-Dienst bereitgestellt und verwaltet wird. Das Gateway ruft den EPP über ext-proc auf, um Routingentscheidungen zu treffen, und leitet die Anfrage dann direkt an den ausgewählten Modellserver-Pod weiter.

Diese Trennung des Gateways (Datenebene) vom EPP (Routingintelligenz) ermöglicht Folgendes:

• Gemeinsame Infrastruktur: Ein einzelnes GKE Gateway stellt mehrere InferencePools neben Standard-Kubernetes-Diensten bereit.
• Erweiterte Trafficverwaltung: HTTPRoute Richtlinien unterstützen gewichtete Aufteilung, schrittweise Roll-outs und Anfragespiegelung.
• Unabhängige Skalierung: Der EPP-Dienst wird unabhängig vom Gateway skaliert.
• Cloudnative Integration: Funktioniert mit dem verwalteten Gateway-Controller von GKE, Cloud Load Balancing und vorhandenen Tools zur Beobachtbarkeit.

Funktionsweise des GKE Inference Gateways

Das GKE Inference Gateway verwendet Gateway API-Erweiterungen und modellspezifische Routinglogik, um Clientanfragen an ein KI-Modell zu verarbeiten. Die folgenden Schritte beschreiben den Anfrageablauf.

Funktionsweise des Anfrageablaufs

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 Anfrageablauf ist für alle Clients gleich.

1. Der Client sendet eine Anfrage, die gemäß der OpenAI API-Spezifikation formatiert ist, an das in GKE ausgeführte Modell.

2. Das GKE Inference Gateway verarbeitet die Anfrage mit den folgenden Inferenz-Erweiterungen:

   1. Erweiterung für textkörperbasiertes Routing: Extrahiert die Modellkennung aus dem Anfragetext des Clients und sendet sie an das GKE Inference Gateway. Das 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 des Anfragetexts ähnelt dem Routing basierend auf dem URL-Pfad. Der Unterschied besteht darin, dass beim Routing des Anfragetexts Daten aus dem Anfragetext verwendet werden.
   2. Sicherheitsextension: Verwendet Model Armor, NVIDIA NeMo Guardrails, oder unterstützte Drittanbieterlösungen, um modellspezifische Sicherheits richtlinien zu erzwingen, einschließlich Inhaltsfilterung, Bedrohungserkennung, Bereinigung und Logging. Die Sicherheitsextension wendet diese Richtlinien sowohl auf die Anfrage- als auch auf die Antwortverarbeitungspfade an.
   3. llm-d Endpoint Picker (EPP): Überwacht wichtige Messwerte von Modellservern im InferencePool und leitet die Anfrage an die optimale Modellreplikat weiter. Weitere Informationen finden Sie unter llm-d-Router.

3. Das GKE Inference Gateway leitet die Anfrage an die Modellreplikat weiter, die von der Endpunktauswahl-Erweiterung zurückgegeben wurde.

Das folgende Diagramm veranschaulicht den Anfrageablauf von einem Client zu einer Modellinstanz über das GKE Inference Gateway.

Funktionsweise der Trafficverteilung

Das GKE Inference Gateway verteilt Inferenzanfragen dynamisch an Modellserver im InferencePool-Objekt. So wird die Ressourcennutzung optimiert und die Leistung unter verschiedenen Lastbedingungen aufrechterhalten. Das GKE Inference Gateway verwendet die folgenden beiden Mechanismen, um die Trafficverteilung zu verwalten:

• Endpunktauswahl: Wählt dynamisch den am besten geeigneten Modellserver für die Verarbeitung einer Inferenzanfrage aus. Es überwacht die Serverlast und ‑verfügbarkeit und trifft dann optimale Routingentscheidungen, indem es für jeden Server einen score berechnet, der eine Reihe von Optimierungsheuristiken kombiniert:

  • Präfix-Cache-basiertes Routing: Das GKE Inference Gateway verfolgt die verfügbaren Präfix-Cache-Indizes auf jedem Modellserver und gibt einem Server mit einer längeren Präfix-Cache-Übereinstimmung eine höhere Punktzahl.
  • Lastbasiertes Routing: Das GKE Inference Gateway überwacht die Serverlast (KV-Cache-Auslastung und Tiefe der Warteschlange für ausstehende Anfragen) und gibt einem Server mit geringerer Last eine höhere Punktzahl.
  • LoRA-basiertes Routing: Wenn die dynamische LoRA-Bereitstellung aktiviert ist, überwacht das GKE Inference Gateway die aktiven LoRA-Adapter pro Server und gibt einem Server mit dem angeforderten aktiven LoRA-Adapter oder zusätzlichem Platz zum dynamischen Laden des angeforderten LoRA-Adapters eine höhere Punktzahl. Ein Server mit der höchsten Gesamtpunktzahl aller oben genannten wird ausgewählt.

• Warteschlangen und Verwerfen: Verwaltet den Anfragenfluss und verhindert eine Überlastung des Traffics. Das GKE Inference Gateway speichert eingehende Anfragen in einer Warteschlange und priorisiert Anfragen basierend auf der definierten Priorität.

Das GKE Inference Gateway verwendet ein numerisches Priority-System, auch bekannt als Criticality, um den Anfragenfluss zu verwalten und Überlastungen zu vermeiden. Diese Priority ist ein optionales ganzzahliges Feld, das vom Nutzer für jedes InferenceObjective definiert wird. Ein höherer Wert bedeutet eine wichtigere Anfrage. Wenn das System überlastet ist, werden Anfragen mit einer Priority von weniger als 0 als weniger wichtig betrachtet und zuerst verworfen. Es wird ein 429-Fehler zurückgegeben, um kritischere Arbeitslasten zu schützen. Standardmäßig ist die Priority auf 0 gesetzt. Anfragen werden nur aufgrund der Priorität verworfen, wenn ihre Priority explizit auf einen Wert kleiner als 0 gesetzt ist. Mit diesem System können Sie latenzempfindlichen Online-Inferenz-Traffic gegenüber weniger zeitkritischen Batchjobs priorisieren.

Das GKE Inference Gateway unterstützt Streaming-Inferenz für Anwendungen wie Chatbots und Live-Übersetzung, die kontinuierliche oder nahezu Echtzeit-Updates erfordern. Bei der Streaming-Inferenz werden Antworten in inkrementellen Blöcken oder Segmenten anstelle einer einzelnen, vollständigen Ausgabe geliefert. Wenn bei einer Streaming-Antwort ein Fehler auftritt, wird der Stream beendet und der Client erhält eine Fehlermeldung. Das GKE Inference Gateway versucht nicht, Streaming-Antworten noch einmal zu senden.

Anwendungsbeispiele

In diesem Abschnitt finden Sie Beispiele für die Verwendung des GKE Inference Gateway in verschiedenen Szenarien für generative KI-Anwendungen.

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 verarbeiten. Beispielsweise möchte es ein Gemma3-Modell für eine Chatbot-Oberfläche und ein DeepSeek-Modell für eine Empfehlungsanwendung bereitstellen. Das Unternehmen muss eine optimale Bereitstellungsleistung für diese LLMs gewährleisten.

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

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

Dieses Diagramm veranschaulicht, wie eine Anfrage an einen GenAI-Dienst unter example.com/completions vom GKE Inference Gateway verarbeitet wird. Die Anfrage erreicht zuerst ein Gateway im Namespace Infra. Dieses Gateway leitet die Anfrage an eine HTTPRoute im Namespace GenAI Inference weiter, die für die Verarbeitung von Anfragen für Chatbot- und Sentimentmodelle konfiguriert ist. Für das Chatbot-Modell teilt die HTTPRoute den Traffic auf: 90% werden an einen InferencePool weitergeleitet, in dem die aktuelle Modellversion ausgeführt wird (ausgewählt durch {pool: gemma}), und 10% an einen Pool mit einer neueren Version ({pool: gemma-new}), in der Regel für Canary-Tests. Beide Pools sind mit einem InferenceObjective verknüpft, das Anfragen für das Chatbot-Modell eine Priority von 10 zuweist, sodass diese Anfragen als wichtig behandelt werden.

Beispiel 2: LoRA-Adapter auf einem gemeinsamen Beschleuniger bereitstellen

Ein Unternehmen möchte LLMs für die Dokumentanalyse bereitstellen und konzentriert sich auf Zielgruppen in mehreren Sprachen, z. B. Englisch und Spanisch. Es hat Modelle für jede Sprache optimiert, muss aber seine GPU- und TPU-Kapazität effizient nutzen. Mit dem GKE Inference Gateway können Sie dynamische LoRA-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 veranschaulicht, wie das GKE Inference Gateway mehrere LoRA-Adapter auf einem gemeinsamen Beschleuniger bereitstellt.

Nächste Schritte

• GKE Inference Gateway bereitstellen
• GKE Inference Gateway-Konfiguration anpassen
• LLM mit dem GKE Inference Gateway bereitstellen
• Routing basierend auf der vorhergesagten Latenz mit dem GKE Inference Gateway verwenden(Vorschau)