Auf dieser Seite werden die wichtigsten Konzepte und Funktionen von GKE Inference Gateway erläutert, einer Erweiterung des GKE Gateway für die optimierte Bereitstellung von Anwendungen mit generativer KI.
Auf dieser Seite wird davon ausgegangen, dass Sie mit Folgendem vertraut sind:
- KI‑/ML-Orchestrierung in GKE
- Terminologie für generative KI
- GKE-Netzwerkkonzepte, einschließlich Dienste und der GKE Gateway API
- Load-Balancing in Google Cloud, insbesondere die Interaktion von Load-Balancern mit GKE
Diese Seite richtet sich an folgende Nutzer:
- Entwickler für maschinelles Lernen (ML), Plattformadministratoren und ‑operatoren sowie Daten- und KI-Spezialisten, die daran interessiert sind, Kubernetes-Container-Orchestrierungsfunktionen für die Bereitstellung von KI‑/ML-Arbeitslasten zu nutzen.
- Cloud-Architekten und Netzwerkspezialisten, die mit Kubernetes-Netzwerken interagieren.
Übersicht
Das GKE Inference Gateway ist eine Erweiterung des GKE Gateway, das optimiertes Routing und Load Balancing für die Bereitstellung von Arbeitslasten mit generativer künstlicher Intelligenz (KI) bietet. Das ADK vereinfacht die Bereitstellung, Verwaltung und Beobachtbarkeit von KI-Inferenz-Arbeitslasten.
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.
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:
- 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 Daten verarbeitet.
- Länge der Anfragewarteschlange: Die Anzahl der Anfragen, die auf die Verarbeitung warten.
- Optimiertes Load Balancing für die Inferenz: Anfragen werden verteilt, um die Leistung der KI-Modellbereitstellung zu optimieren. Dabei werden Messwerte von Modellservern wie
KV cache hitsundqueue length of pending requestsverwendet, 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, mit der Anfragen mit gemeinsamem Kontext, die durch Analyse des Anfragetexts identifiziert werden, an dasselbe Modellreplikat gesendet werden, um Cache-Treffer zu maximieren. Dieser Ansatz reduziert redundante Berechnungen erheblich und verbessert die Time-to-First-Token. Er ist daher sehr effektiv für konversationelle KI, Retrieval-Augmented Generation (RAG) und andere vorlagenbasierte generative KI-Arbeitslasten. - Bereitstellung dynamischer, mit LoRA optimierter Modelle: Unterstützt die Bereitstellung dynamischer, mit LoRA optimierter Modelle auf einem gemeinsamen Beschleuniger. Dadurch wird die Anzahl der GPUs und TPUs reduziert, die für die Bereitstellung von Modellen erforderlich sind, da mehrere LoRA-abgestimmte Modelle auf einem gemeinsamen Basismodell und Beschleuniger gemultiplext werden.
- Optimierte automatische Skalierung für die Inferenz: Der horizontale Pod-Autoscaler (HPA) von GKE verwendet Messwerte des Modellservers für die automatische Skalierung. So wird eine effiziente Nutzung der Rechenressourcen und eine optimierte Inferenzleistung 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 Traffic-Splitting und Anfragen-Mirroring definieren, um verschiedene Modellversionen zu verwalten und die Einführung von Modellen 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 zur Konfiguration finden Sie unter Body-Based Routing konfigurieren. - Integrierte KI-Sicherheits- und Inhaltsfilterung: GKE Inference Gateway ist in Google Cloud Model Armor eingebunden, 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 der Verarbeitung für die nachträgliche Analyse und Optimierung bereit. Die offenen Schnittstellen von GKE Inference Gateway ermöglichen es Drittanbietern und Entwicklern, benutzerdefinierte Dienste in den Prozess für Inferenzanfragen zu integrieren.
- Modellspezifische Bereitstellung
Priority: Hiermit können Sie die BereitstellungPriorityvon KI-Modellen angeben. Priorisieren Sie latenzempfindliche Anfragen gegenüber latenzunempfindlichen Batchinferenzjobs. Sie können beispielsweise Anfragen von latenzsensiblen Anwendungen priorisieren und weniger zeitkritische Aufgaben verwerfen, wenn die Ressourcen begrenzt sind. - Vorhersagebasierte Latenzoptimierung: Inferenzanfragen werden mithilfe eines XGBoost-Modells weitergeleitet, das kontinuierlich mit Live-Traffic trainiert wird. Dabei werden die Ziele „Zeit bis zum ersten Token“ (Time-to-First-Token, TTFT) und „Zeit pro Ausgabetoken“ (Time-per-Output-Token, TPOT) für jede Anfrage optimiert. Bei Arbeitslasten mit hoher Varianz genauer als statische Heuristiken. Weitere Informationen finden Sie unter „Vorhersagebasierte Latenzrouten mit dem GKE Inference Gateway verwenden“.
- Inference Observability (Beobachtbarkeit von Inferenz): bietet Messwerte zur Beobachtbarkeit für Inferenzanfragen, z. B. Anforderungsrate, Latenz, Fehler und Sättigung. Sie können die Leistung und das Verhalten Ihrer Inferenzdienste mit Cloud Monitoring und Cloud Logging überwachen. Dazu stehen spezielle vordefinierte Dashboards zur Verfügung, die detaillierte Informationen liefern. Weitere Informationen finden Sie unter GKE Inference Gateway-Dashboard ansehen.
- Erweiterte API-Verwaltung mit Apigee: Wird in Apigee integriert, um Ihr Inferenz-Gateway mit Funktionen wie API-Sicherheit, Ratenbegrenzung und Kontingenten zu erweitern. Eine ausführliche Anleitung finden Sie unter Apigee für Authentifizierung und API-Verwaltung konfigurieren.
- Erweiterbarkeit: Die Lösung basiert auf einer erweiterbaren Open-Source-Kubernetes-Gateway-API-Inference-Erweiterung, die einen vom Nutzer verwalteten llm-d-Endpunkt-Picker-Algorithmus (EPP) unterstützt, der von llm-d unterstützt wird. Der llm-d Endpoint Picker (EPP)-Algorithmus, der auf llm-d basiert, bietet die grundlegende Routing-Intelligenz für diese Erweiterung.
- Unterstützung mehrerer 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 proGoogle Cloud Backend-Dienst. Wenn Sie einen InferencePool mit mehreren Ports verwenden, 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 ein solches InferencePool nur aus maximal zwei Clustern aggregieren (zwei Cluster × 24 NEGs = 48 NEGs), bevor das Limit von 50 NEGs erreicht wird.
Schlüsselkonzepte
GKE Inference Gateway erweitert das vorhandene GKE Gateway, das GatewayClass-Objekte verwendet. Mit GKE Inference Gateway werden die folgenden neuen benutzerdefinierten Gateway API-Ressourcendefinitionen (CRDs) eingeführt, die an die OSS Kubernetes Gateway API-Erweiterung für Inference angeglichen sind:
- InferencePool-Objekt: Stellt eine Gruppe von Pods (Containern) dar, die dieselbe Compute-Konfiguration, denselben Beschleunigertyp, dasselbe Basissprachmodell und denselben Modellserver verwenden. So werden Ihre Ressourcen für die KI-Modellbereitstellung logisch gruppiert und verwaltet. Ein einzelnes InferencePool-Objekt kann sich über mehrere Pods auf verschiedenen GKE-Knoten erstrecken und bietet Skalierbarkeit und Hochverfügbarkeit. Sie können bis zu acht
targetPortsin einer InferencePool-Ressource angeben, um Modellserver zu unterstützen, die mehrere Ports erfordern. - InferenceObjective-Objekt: Gibt den Namen des Serving-Modells aus dem InferencePool gemäß der
OpenAI API-Spezifikation an. Das InferenceObjective-Objekt gibt auch die Bereitstellungseigenschaften des Modells an, z. B. diePrioritydes KI-Modells. Das GKE Inference Gateway bevorzugt Arbeitslasten mit einem höheren Prioritätswert. So können Sie latenzkritische und latenzunempfindliche KI-Arbeitslasten auf einem GKE-Cluster ausführen. Sie können das InferenceObjective-Objekt auch so konfigurieren, dass LoRA-abgestimmte Modelle bereitgestellt werden.
Das folgende Diagramm zeigt das GKE Inference Gateway und seine Integration in KI-Sicherheit, Observability und Modellbereitstellung in einem GKE-Cluster.
Das folgende Diagramm veranschaulicht das Ressourcenmodell, das sich auf zwei neue auf Inferenz ausgerichtete Rollen und die von ihnen verwalteten Ressourcen konzentriert.
llm-d Router
Der llm-d-Router ist die intelligente Komponente für das Anforderungsrouting, die das Inference Gateway verwendet, um Endpunktentscheidungen pro Anfrage zu treffen. Sie besteht aus zwei Unterkomponenten:
| Unterkomponente | Beschreibung |
|---|---|
| L7-Proxy | Ein beliebiger konformer L7-Proxy auf Branchenniveau (in der Regel Envoy), der die Datenebene verarbeitet: Verbindungsverwaltung, TLS-Terminierung und Weiterleitung von Anfragen. Im GKE Inference Gateway (Gateway-Modus) ist der Proxy das GKE Gateway. |
| `llm-d Endpoint Picker (EPP)` | Ein spezialisierter Dienst, den der Proxy für jede Anfrage über das ext-proc-Protokoll konsultiert. Das EPP enthält die Routing-Informationen. Dabei werden Echtzeitsignale von Modellservern (KV-Cache-Nutzung, Warteschlangenlänge, Präfix-Cache-Status und LoRA-Adapteraffinität) verwendet, um den optimalen Modellserver-Pod für jede Anfrage auszuwählen. |
Gateway-Modus
Das GKE Inference Gateway ist das llm-d Router, das im Gateway-Modus ausgeführt wird. Im Gateway-Modus ist der Proxy ein formelles Kubernetes-Gateway, das separat vom EPP-Dienst bereitgestellt und verwaltet wird. Das Gateway ruft das EPP über ext-proc auf, um Routingentscheidungen zu treffen, und leitet die Anfrage dann direkt an den ausgewählten Modellserver-Pod weiter.
Durch diese Trennung des Gateways (Datenebene) vom EPP (Routing-Intelligenz) wird Folgendes ermöglicht:
- Gemeinsame Infrastruktur: Ein einzelnes GKE Gateway bedient mehrere InferencePools zusammen mit Standard-Kubernetes-Diensten.
- Erweiterte Trafficverwaltung:
HTTPRoute-Richtlinien unterstützen gewichtete Aufteilung, schrittweise Einführung und Anfragespiegelung. - Unabhängige Skalierung: Der EPP-Dienst wird unabhängig vom Gateway skaliert.
- Cloud-native Integration: Funktioniert mit dem verwalteten Gateway-Controller von GKE, Cloud Load Balancing und vorhandenen Observability-Tools.
Funktionsweise des GKE Inference Gateways
Das GKE Inference Gateway verwendet Gateway API-Erweiterungen und modellspezifische Routing-Logik, um Clientanfragen an ein KI-Modell zu verarbeiten. Im Folgenden 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 Anfrageablauf ist für alle Clients üblich.
- Der Client sendet eine Anfrage, die wie in der OpenAI API-Spezifikation beschrieben formatiert ist, an das Modell, das in GKE ausgeführt wird.
GKE Inference Gateway verarbeitet die Anfrage mit den folgenden Inference-Erweiterungen:
- Erweiterung für Body-basiertes Routing: Extrahiert die Modellkennung aus dem Textkörper der Clientanfrage und sendet sie an das GKE Inference Gateway.
Das GKE Inference Gateway verwendet diese Kennung dann, um die Anfrage basierend auf den im Gateway API-Objekt
HTTPRoutedefinierten Regeln weiterzuleiten. 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. - Sicherheitserweiterung: Erzwingt die Einhaltung modellspezifischer Sicherheitsrichtlinien mithilfe von Model Armor, NVIDIA NeMo Guardrails> oder unterstützten Drittanbieterlösungen. Dazu gehören Inhaltsfilterung, Bedrohungserkennung, Bereinigung und Protokollierung. Die Sicherheitserweiterung wendet diese Richtlinien sowohl auf Anfrage- als auch auf Antwortverarbeitungspfade an.
- llm-d Endpoint Picker (EPP): überwacht wichtige Messwerte von Modellservern im InferencePool und leitet die Anfrage an das optimale Modellreplikat weiter. Weitere Informationen finden Sie unter llm-d Router.
- Erweiterung für Body-basiertes Routing: Extrahiert die Modellkennung aus dem Textkörper der Clientanfrage und sendet sie an das GKE Inference Gateway.
Das GKE Inference Gateway verwendet diese Kennung dann, um die Anfrage basierend auf den im Gateway API-Objekt
Das GKE Inference Gateway leitet die Anfrage an die Modellreplik weiter, die von der Erweiterung zur Endpunktauswahl zurückgegeben wird.
Das folgende Diagramm veranschaulicht den Anfragefluss von einem Client zu einer Modellinstanz über das GKE Inference Gateway.
So funktioniert die Trafficverteilung
Das GKE Inference Gateway verteilt Inferenzanfragen dynamisch an Modellserver innerhalb des InferencePool-Objekts. So lässt sich die Ressourcennutzung optimieren und die Leistung bei unterschiedlichen Lastbedingungen aufrechterhalten. GKE Inference Gateway verwendet die folgenden beiden Mechanismen, um die Traffic-Verteilung zu verwalten:
Endpunktauswahl: wählt dynamisch den am besten geeigneten Modellserver für die Verarbeitung einer Inferenzanfrage aus. Es wird die Serverlast und ‑verfügbarkeit überwacht und dann werden optimale Routing-Entscheidungen getroffen, indem für jeden Server ein
scoreberechnet wird, in dem eine Reihe von Optimierungsheuristiken kombiniert werden:- Präfix-Cache-basiertes Routing: Das GKE Inference Gateway verfolgt die verfügbaren Präfix-Cache-Indizes auf jedem Modellserver und weist einem Server mit einer längeren Präfix-Cache-Übereinstimmung einen höheren Wert zu.
- Lastabhängiges Routing: Das GKE Inference Gateway überwacht die Serverlast (KV-Cache-Nutzung und Tiefe der Warteschlange für ausstehende Anfragen) und weist einem Server mit geringerer Last einen höheren Wert zu.
- LoRA-basiertes Routing: Wenn das dynamische LoRA-Serving aktiviert ist, überwacht GKE Inference Gateway aktive LoRA-Adapter pro Server und weist einem Server mit dem angeforderten aktiven LoRA-Adapter oder zusätzlichem Spielraum zum dynamischen Laden des angeforderten LoRA-Adapters einen höheren Wert zu. Es wird ein Server mit der höchsten Gesamtpunktzahl aller vorherigen ausgewählt.
Warteschlangen und Ablegen: 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 Anfragedurchsatz zu verwalten und eine Überlastung zu verhindern. Priority ist ein optionales Ganzzahlfeld, 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 einem Priority unter 0 als weniger wichtig eingestuft und zuerst verworfen. Dabei wird ein 429-Fehler zurückgegeben, um wichtigere Arbeitslasten zu schützen. Priority ist standardmäßig auf 0 gesetzt. Anfragen werden nur aufgrund der Priorität verworfen, wenn ihr Priority explizit auf einen Wert unter 0 festgelegt ist. Mit diesem System können Sie latenzempfindlichen Online-Inferenz-Traffic gegenüber weniger zeitkritischen Batchjobs priorisieren.
GKE Inference Gateway unterstützt Streaming-Inferenz für Anwendungen wie Chatbots und Live-Übersetzung, die kontinuierliche oder nahezu in Echtzeit stattfindende Aktualisierungen erfordern. Beim Streaming von Inferenzen werden Antworten in inkrementellen Chunks oder Segmenten anstelle einer einzelnen, vollständigen Ausgabe geliefert. Wenn während einer Streaming-Antwort ein Fehler auftritt, wird der Stream beendet und der Client erhält eine Fehlermeldung. GKE Inference Gateway versucht nicht, Streaming-Antworten noch einmal zu senden.
Anwendungsbeispiele ansehen
In diesem Abschnitt finden Sie Beispiele für die Verwendung von 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 bedienen. Sie möchten beispielsweise ein Gemma3-Modell für eine Chatbot-Oberfläche und ein DeepSeek-Modell für eine Empfehlungsanwendung bereitstellen. Das Unternehmen muss für diese LLMs eine optimale Bereitstellungsleistung sicherstellen.
Mit GKE Inference Gateway können Sie diese LLMs mit der von Ihnen 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 der Eigenschaft Priority weiterleiten.
Das folgende Diagramm zeigt, wie das GKE Inference Gateway Anfragen basierend auf dem Modellnamen und Priority an verschiedene Modelle weiterleitet.
In diesem Diagramm wird veranschaulicht, wie eine Anfrage an einen GenAI-Dienst auf example.com/completions vom GKE Inference Gateway verarbeitet wird. Die Anfrage erreicht zuerst einen Gateway im Namespace Infra. Dieser Gateway leitet die Anfrage an einen HTTPRoute im GenAI Inference-Namespace weiter, der für die Verarbeitung von Anfragen für Chatbot- und Sentimentmodelle konfiguriert ist. Beim Chatbot-Modell wird der Traffic durch HTTPRoute aufgeteilt: 90% werden an einen InferencePool mit der aktuellen Modellversion (ausgewählt durch {pool: gemma}) weitergeleitet 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. So werden diese Anfragen als prioritär behandelt.
Beispiel 2: LoRA-Adapter auf einem gemeinsam genutzten 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. 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 LoRA-Adapter für jede Sprache (z. B. english-bot und spanish-bot) für ein gemeinsames Basismodell (z. B. llm-base) und einen gemeinsamen Beschleuniger bereitstellen. So können Sie die Anzahl der erforderlichen Beschleuniger reduzieren, indem Sie mehrere Modelle auf einem gemeinsamen Beschleuniger unterbringen.
Das folgende Diagramm veranschaulicht, wie das GKE Inference Gateway mehrere LoRA-Adapter auf einem gemeinsam genutzten Beschleuniger bereitstellt.
Nächste Schritte
- GKE Inference Gateway bereitstellen
- GKE Inference Gateway-Konfiguration anpassen
- LLM mit GKE Inference Gateway bereitstellen
- Vorhersagebasierte Latenz für das Routing mit dem GKE Inference Gateway verwenden(Vorschau)