Application Gateway für Container – Inference-Gateway

KI-Ableitungsworkloads verhalten sich nicht wie herkömmliche zustandslose HTTP-Anwendungen. Anfragen sind häufig modellspezifisch, langlaufend, in der Bearbeitung kostspielig und empfindlich gegenüber Laufzeitsignalen wie der Verfügbarkeit von Beschleunigern, der Warteschlangentiefe, der Priorität der Anfrage, dem Tokenbudget und der Kapazität des Modellservers.

Application Gateway for Containers Inference Gateway unterstützt diese Workloads durch die Integration mit der Kubernetes-Gateway API Inference Extension, die dem Gateway-API-Modell inferenzspezifische Ressourcen hinzufügt. Mithilfe des Inference-Gateways können Sie selbstgehostete Modellserver über Application Gateway für Container mit modell- und lastabhängigem Routingverhalten verfügbar machen.

Das Ableitungsgateway ist speziell für die Bereitstellung großer Sprachmodelle (LLMs) und anderer Ableitungsworkloads konzipiert. Sie leitet Anforderungen basierend auf Modellserversignalen und nicht auf generischem Lastenausgleich weiter, wodurch die Zeit bis zum ersten Token (TTFT) verringert wird, Timeouts unter Last reduziert und die GPU-Effizienz verbessert wird. Basierend auf den Ingress-Funktionen von Application Gateway for Containers können Sie mit dem Inferenzgateway KI-Workloads auch mit Funktionen wie der Webanwendungsfirewall (WAF) kombinieren, um den Datenverkehr abzusichern, bevor er Ihre Modellserver erreicht.

Viele selbstgehostete Inferenz-Laufzeitumgebungen, einschließlich vLLM, stellen OpenAI-kompatible HTTP-APIs wie /v1/chat/completions, /v1/completions und /v1/models bereit. OpenAI-kompatibel bezieht sich auf das API-Format und nicht auf eine Beschränkung auf von OpenAI gehostete Modelle. Wenn eine andere Modellfamilie über eine Laufzeit oder einen Proxy bereitgestellt wird, die bzw. der dieses Format verwendet, kann Application Gateway for Containers das model-Feld im JSON-Anforderungstext für Body-basiertes Routing verwenden.

Was die Gateway-API-Ableitungserweiterung bereitstellt

Die Gateway-API-Inference-Erweiterung macht eine Gateway-API-Implementierung zu einem Inferenz-Gateway, indem sie inferencespezifische Backends und Scheduling-Konzepte hinzufügt.

Die Erweiterung führt diese primären Ressourcen und Komponenten ein:

• InferencePool: Eine Back-End-Ressource, die eine Gruppe von Modellserver-Pods und die Endpunktauswahl darstellt, die zum Auswählen eines Pods für jede Rückschlussanforderung verwendet wird.
• InferenceObjective: Eine Ressource, die anforderungsbasierte Ziele darstellt, z. B. Priorität, für Anforderungen, die einen InferencePool teilen.
• Endpoint Picker (EPP): Eine vom Kunden bereitgestellte Erweiterung, die in Ihrem Cluster ausgeführt wird und eine Ableitungsplanung implementiert. Der EPP empfängt Anforderungsmetadaten, bewertet infrage kommende Modellserver-Pods mithilfe konfigurierbarer Plug-Ins (z. B. Warteschlangentiefe, KV-Cache-Auslastung und Präfix-Cache-Affinität) und gibt den ausgewählten Endpunkt zurück. Da die Endpunktauswahl in der EPP stattfindet, hängen die verfügbaren Routing-Verhaltensweisen von den Scorer-Plugins ab, die Ihre EPP aktiviert.
• Body-based routing (BBR):Ein Anforderungsprozessor, der einen OpenAI-kompatiblen Anforderungstext prüfen, den Modellnamen extrahieren und dem Gateway als X-Gateway-Model-Name Header für modellfähiges Routing zur Verfügung stellen kann.

Application Gateway für Container führt den BBR-Prozessor als verwalteten Teil des Gateways aus, sodass keine separate textkörperbasierte Routingebene bereitgestellt, skaliert oder gepatcht werden muss. Es lässt sich in ein vom Kunden bereitgestelltes EPP integrieren, um Routing-Entscheidungen zum Zeitpunkt der Anfrage zu unterstützen. Das Inference-Gateway unterstützt die Inference Extension API der Gateway API, sodass Sie diese Funktionen über Standardressourcen der Gateway API konfigurieren können und Plattformteams für den Inferenz-Datenverkehr ein Kubernetes-natives API-Modell verwenden können, anstatt ein separates Ingress-Konfigurationsmodell einzuführen.

So verwendet Anwendungsgateway für Container Ableitungsressourcen

Das Anwendungsgateway für Container verwendet weiterhin standardmäßige Gateway-API-Ressourcen für die Eingangskonfiguration. Das Inferenzverhalten wird aktiviert, wenn eine HTTPRoute Backend-Referenz auf ein InferencePool statt auf ein Kubernetes-Service verweist.

Für Routen, die nicht für Inferenz vorgesehen sind, behält Application Gateway for Containers das bisherige Verhalten der Gateway-API bei. Routen, die an Kubernetes-Backends Service gerichtet sind, rufen keine Inferenzprozessoren auf und erhalten kein inferenzspezifisches Routingverhalten.

Für Inferenzrouten gleicht die Kontrollebene die Gateway-API und die Inferenzressourcen ab und programmiert die Datenebene so, dass:

• Das HTTPRoute wählt das InferencePool Backend aus.
• Der InferencePool wählt die Modellserver-Pods aus, die zum Pool gehören.
• Die dem Pool zugeordnete EPP wird für die Endpunktauswahl aufgerufen.
• Der ausgewählte Modellserverendpunkt empfängt die Anforderung.
• Optionales modellfähiges Routing verwendet den von BBR extrahierten Anforderungsmodellnamen.

Anforderungsfluss

Eine typische Rückschlussanforderung folgt diesem Pfad. Die nummerierten Schritte sind den Beschriftungen im folgenden Diagramm zugeordnet:

1. Clientanforderung: Ein Client sendet eine openAI-kompatible Anforderung an das Application Gateway für Container-Frontend, und der Gatewaylistener akzeptiert sie.
2. Body-based routing (BBR):Bei modellfähigen Routen prüft der verwaltete BBR-Prozessor den Anforderungstext, extrahiert den Modellnamen und fügt den X-Gateway-Model-Name Header ein. Der HTTPRoute kann dann nach diesem Wert abgleichen, um den entsprechenden InferencePool auszuwählen.
3. Endpunktauswahl: Wenn die übereinstimmenden Routen auf ein InferencePoolZiel ausgerichtet sind, ruft das Anwendungsgateway für Container die EPP auf, die die Anforderungs- und Modellserver-Telemetrie auswertet und den ausgewählten Endpunkt zurückgibt.
4. Route zum InferencePool: Application Gateway for Containers leitet die Anforderung an den ausgewählten Modellserver-Pod weiter, und die Antwort des Modellservers wird über das Gateway an den Client zurückgegeben.

Routingfunktionen

Das Ableitungsgateway unterstützt diese Routingmuster für selbst gehostete KI-Workloads. Die Endpunktauswahl wird im EPP ausgeführt, sodass das last- und cacheabhängige Verhalten von den Scorer-Plug-Ins abhängt, die Ihr EPP aktiviert.

• Modellabhängiges Routing: Leiten Sie Anforderungen basierend auf dem Modellnamen in OpenAI-kompatiblen Anforderungstextkörpern weiter, die der verwaltete BBR-Prozessor extrahiert.
• Aufteilen von Datenverkehr und Rollouts: Verwenden Sie standardmäßige HTTPRoute gewichtete backendRefs, um den Datenverkehr für Canary- oder Blau-Grün-Modellrollouts auf InferencePool Back-Ends aufzuteilen.
• Last- und cachebewusste Endpunktauswahl: EPP bewertet Endpunkte anhand von Telemetriedaten des Modellservers, wie etwa Warteschlangentiefe und Auslastung des KV-Caches. Wenn der EPP die präfix-cacheabhängige Bewertung aktiviert, werden Anforderungen, die ein Prompt-Präfix gemeinsam nutzen, an dasselbe Replikat weitergeleitet, um Cachetreffer zu erhöhen und die TTFT zu verringern.
• Anforderungsprioritäts- und Überladungsschutz: Verwenden Sie InferenceObjective Ressourcen und den Anforderungsheader x-gateway-inference-objective , um die Dienstpriorität zuzuweisen. Wenn Modellserver ausgelastet sind, weist die EPP zunächst Anfragen mit niedrigerer Priorität ab, um latenzkritischen Datenverkehr zu schützen.
• Robuste Endpunktauswahl: Konfigurieren des EVP-Fehlerverhaltens mit FailOpen oder FailClose, je nachdem, ob Verfügbarkeit oder strenge Endpunktauswahl für einen Pool wichtiger ist.
• Gateway-API-Kompatibilität: Verwenden Sie weiterhin Gateway-, HTTPRoute-, ReferenceGrant- und Standard-Gateway-API-Statusbedingungen für die Eingangskonfiguration.

Sichere Ableitung

Behalten Sie Modellserver hinter dem verwalteten Gateway privat, und wenden Sie die Sicherheitsfunktionen der Plattform auf den Ableitungsverkehr an.

• Web Application Firewall (WAF): Das Inferenzgateway arbeitet nativ mit der vorhandenen WAF-Funktion in Application Gateway for Containers zusammen und wendet an OWASP ausgerichtete Schutzmaßnahmen auf den KI-Datenverkehr an, bevor Anfragen Ihre Modellserver erreichen.
• Schutz für teure Back-Ends: Da die Richtlinie am verwalteten Edge erzwungen wird, können falsch formatierte oder missbräuchliche Anforderungen überprüft und blockiert werden, bevor sie knappe GPU-Kapazität verbrauchen.

Beispielszenarien

Die folgenden Szenarien zeigen häufig verwendete Methoden für die Verwendung des Rückschlussgateways:

• Bereitstellen und Rollout von Modellversionen: Leiten Sie OpenAI-kompatible Anforderungen nach Modellnamen an ein InferencePool weiter, und verwenden Sie dann gewichtete HTTPRoute backendRefs, um einen Prozentsatz des Datenverkehrs für Canary-Tests auf eine neue Modellversion zu verlagern, bevor Sie den Rollout abschließen.
• Priorisieren sie latenzkritischen Datenverkehr: Definieren Sie InferenceObjective Ressourcen für Workloads mit hoher Priorität und workloads mit niedriger Priorität in einem freigegebenen Pool. Interaktive Chatanforderungen weisen das Ziel mit hoher Priorität auf, während Batchaufträge eine niedrigere Priorität verwenden, die bei Sättigung des Pools zuerst verworfen wird.

InferencePool im Vergleich zu Service

Ein Kubernetes Service bleibt die richtige Back-End-Abstraktion für standardanwendungsdatenverkehr. Verwenden Sie ein InferencePool, wenn das Backend aus einer Gruppe von Modellserver-Pods besteht, die eine inferenzspezifische Endpunktauswahl benötigen.

Ein InferencePool enthält einen Pod-Selektor, Zielportinformationen und einen Verweis auf die Endpunktauswahl. Die EVP ist für die Auswahl des Endpunkts für eine Anforderung verantwortlich. Einer einzelnen EVP ist ein einzelner Pool zugeordnet.

Fehlerverhalten

Inference-Routing ist ein Verhalten zur Anforderungszeit, daher ist der Fehlermodus der Endpunktauswahl von Bedeutung.

InferencePool Referenzen der Endpunktauswahl unterstützen diese Fehlermodi:

• FailOpen: Wenn die EPP nicht verfügbar ist oder nicht reagiert, kann das Gateway mit der standardmäßigen Endpunktauswahl innerhalb des Pools fortfahren. Diese Option behält die Verfügbarkeit bei, kann aber die Routingqualität verringern.
• FailClose: Wenn die EVP nicht verfügbar ist oder nicht antwortet, lehnt das Gateway die Anforderung ab. Diese Auswahl verhindert, dass Datenverkehr ohne die erforderliche Endpunktauswahlentscheidung gesendet wird.

Für modellfähiges Routing, das von der Analyse des Anforderungstexts abhängt, bevorzugt das Anwendungsgateway für Container die Korrektheit. Wenn der Modellname nicht für eine Route extrahiert werden kann, die BBR erfordert, wird die Anforderung abgelehnt, anstatt im Hintergrund an das falsche Modell-Back-End weitergeleitet zu werden.

Überlegungen zur Verwendung

Berücksichtigen Sie bei der Planung von Inferenzworkloads hinter dem Application Gateway for Containers die folgenden Punkte:

• EPP-Kapazität: Das EPP befindet sich auf dem Anfragepfad für InferencePool Backends. Dimensionieren und überwachen Sie sie wie eine kritische Anwendungskomponente.
• Modellserver-Telemetrie: Die EPP benötigt neue Modellservermetriken, um qualitativ hochwertige Routingentscheidungen zu treffen. Vergewissern Sie sich, dass Ihr Modellserver die von Ihrer EPP-Konfiguration erwarteten Metriken unterstützt.
• GPU-Kapazität und -Planung: Modellserver-Pods erfordern häufig GPU-Knotenpools, Geräte-Plug-Ins und Modelldownloadanmeldeinformationen.
• Autoskalierung: Skalieren Sie Modellserver-Pods anhand von Inferenzsignalen wie Warteschlangentiefe und Auslastung des KV-Caches mithilfe des Horizontal Pod Autoscaler oder von KEDA. Die automatische Skalierung fügt Kapazität hinzu, wenn die Nachfrage steigt, während der EPP um Replikate herumleitet, die bereits gesättigt sind.
• Gestreamte Antworten: Viele Chat-Completion-Workloads verwenden Server-Sent Events. Überprüfen Sie das Streamingverhalten beim Testen der End-to-End-Latenz- und Timeouteinstellungen.
• Observability: Überwachen des Gateway- und HTTPRoute-Status, InferencePool-Status, EPP-Integrität, Modellserverbereitschaft und Modellservermetriken wie aktive Anforderungen und Warteschlangentiefe.

Einschränkungen

Das Rückschlussgateway konzentriert sich auf selbst gehostete Inference-Workloads, die auf Kubernetes ausgeführt werden. Das direkte Routing an öffentliche oder verwaltete Modellanbieterendpunkte liegt außerhalb des Umfangs dieser Integration.

Die Gateway-API-Ableitungserweiterung entwickelt sich unabhängig vom Anwendungsgateway für Container. Verwenden Sie API-Versionen und -Manifeste, die den auf Ihrem Cluster installierten Rückschlusserweiterungs-CRDs entsprechen.

Nächste Schritte

• Konfigurieren des Inference-Gateways von Application Gateway für Container
• Application Gateway for Containers Komponenten
• Dokumentation zur Gateway-API-Inference-Erweiterung