Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Wenn in einer Enterprise-Umgebung mehrere Teams gleichzeitig generative KI-Modelle aufrufen, führt eine zentralisierte Proxy-Struktur aufgrund von Tausenden von Ein- und Ausgabetokens sowie langen Sitzungen schnell zur Erschöpfung der Threads. Um netzwerkübergreifende VPC-Latenzen von 15 bis 40 Millisekunden und das Problem der "Noisy Neighbors" zwischen Mandanten zu beseitigen, müssen der Laufzeit-Traffic-Pfad und die zentrale Richtlinien-Steuerungsebene physisch getrennt werden.
Ein einzelnes zentrales Gateway wird in Umgebungen mit hohem Traffic-Aufkommen zum Ursprung von Engpässen. Durch die Einführung einer Zwei-Tier-Topologie wird die Traffic-Übertragung auf datenspezifische Datenebenen isoliert, während die Steuerungsebene zentral gehalten wird.
In einer Kubernetes-Umgebung wird die Envoy AI Gateway 1.0-Spezifikation deklarativ angewendet. In den Namespaces der jeweiligen Geschäftsdomänen werden Gateway-Ressourcen erstellt, um HTTPS-Traffic zu terminieren, und BackendSecurityPolicy wird angebunden, um API-Authentifizierungsschlüssel aus einem zentralen Sicherheits-Vault zu synchronisieren. AIServiceBackend- und AIGatewayRoute-Ressourcen werden definiert, um Modellparameter im Anfragetext auszulesen und das Routing zu verzweigen.
Selbst wenn im zentralen Richtlinienserver oder im unternehmensweiten Netzwerk-Backbone ein Ausfall auftritt, verarbeitet jede Domäne den Inferenz-Traffic ohne Unterbrechung mit den zuletzt synchronisierten Richtlinien im Cache. Die Nachrichtengrößeneinstellung des Controllers wird auf mindestens 25 Megabyte erweitert und das Polling-Intervall stabilisiert, um CPU-Spikes durch häufiges Neuladen zu unterdrücken.
Wenn die gesamte Bearbeitungszeit als einzelne Metrik erfasst wird, vermischen sich die Inferenzzeiten von großen und kleinen Modellen, wodurch Leistungseinbußen verschleiert werden. Um bei springenden P99-Metriken zu unterscheiden, ob es sich um eine Überlastung der GPU-Prefill-Queue eines externen Anbieters oder um Sperrwartezeiten (Lock Waiting Times) innerhalb des Gateways handelt, muss der Lebenszyklus in der Middleware-Schicht getrennt gemessen werden.
Schreiben Sie eine Middleware direkt, die Prometheus-Histogramm-Metriken in der Gateway-Pipeline erfasst. Erfassen Sie die Einstiegszeit des Clients mit einer ASGI-Middleware und speichern Sie die Mandanten-ID sowie den Route-Domain-Header in den Statuswerten. Protokollieren Sie die interne Middleware-Wartezeit (Queuing Delay) im Histogram-Objekt und erfassen Sie diese in Buckets zwischen 0,001 und 2,5 Sekunden. Erkennen Sie im Prozess des Pipings des Upstream-Client-Streams den Zeitpunkt, zu dem das erste Token-Byte empfangen wird, um die reine TTFT-Latenz des Anbieters als unabhängiges Histogramm zu beobachten.
Gemäß den Infrastruktur-Governance-Praktiken von Uber führte die parallele Anordnung dieser internen Middleware-Queue-P99-Latenz und der reinen TTFT-Latenz pro Backend-Anbieter im Grafana-Dashboard zu einer Verkürzung der Antwortverarbeitungszeit der Pipeline zur Generierung von Kundendienstzusammenfassungen um 6 Sekunden.
Die meisten LLM-Inferenzserver flushen den HTTP 200 OK-Statuscode sofort und stoppen dann die Übertragung von Payloads für einige Sekunden, während der KV-Cache geladen wird. Um zu verhindern, dass Benutzer auf einen eingefrorenen Bildschirm blicken, muss eine Laufzeit-Engine betrieben werden, die eine Verzögerung beim Empfang des ersten Token-Bytes in Echtzeit erkennt und auf ein alternatives Modell umschaltet.
Die Laufzeit-Fallback-Routing-Implementierung kombiniert eine asynchrone Event-Loop mit Stream-Steuerungslogik. Es wird ein Konfigurations-Dictionary definiert, das Endpunkte und Authentifizierungsheader für den primären und sekundären Anbieter enthält, und der Timeout-Schwellenwert wird auf 2,0 Sekunden festgelegt. Der Stream des primären Anbieters wird mit einem asynchronen Iterator aufgerufen, und die Funktion asyncio.wait_for wird verwendet, um zu überprüfen, ob das erste Token innerhalb des angegebenen Schwellenwerts eintrifft. Treten Timeouts auf, wird der primäre Stream sofort abgebrochen, um Sockets und Ressourcen freizugeben, und der Traffic wird ohne Verlust eines einzigen Token-Bytes an den Downstream-Client sofort auf den Stream des sekundären Anbieters umgeschaltet.
Benchmark-Daten zum adaptiven Hedging zeigen, dass beim Betrieb einer Transportschicht, die bei Latenzen Backup-Anfragen auslöst, die P99-Tail-Latenz von 64,3 Millisekunden auf 17,0 Millisekunden sank, was einer Latenzverkürzung von 73,6 Prozent entspricht. Dadurch wird die vom Benutzer wahrgenommene Ausfallzeit selbst bei Teilausfällen des primären Anbieters perfekt abgefedert.
