Google API Gateway streamt Agentenantworten in der Vorschau

Google API Gateway fügt Streaming in der öffentlichen Vorschau hinzu

In der Entwicklerankündigung von Google vom 22. Oktober heißt es, dass die Streaming-Unterstützung in API Gateway als öffentliche Vorschau verfügbar ist. Ein Streaming-Endpunkt kann jetzt hinter Gateway-Richtlinien sitzen und inkrementelle Ereignisse an einen Client senden. In der Ankündigung geht es speziell um das verwaltete Produkt Google Cloud API Gateway. Es heißt nicht, dass das bestehende Gateway eines Entwicklers automatisch sein Verhalten ändert, und es verspricht auch keine allgemeine Verfügbarkeit zu einem festen Datum. Beim Vorschaustart wird Streaming aktiviert, wenn ein neues Gateway erstellt wird. Bestehende Gateways können nicht vor Ort durch eine Einstellung konvertiert werden. Diese Grenze zur Erstellungszeit bestimmt, wie ein Team die Einführung inszenieren und wie sie rückgängig gemacht werden kann.

Warum die inkrementelle Bereitstellung den Gateway-Pfad ändert

Viele API-Gateways basieren auf einer Anfrage, gefolgt von einer vollständigen Antwort. Generative Modelle geben stattdessen Ausgaben aus, während sie erzeugt werden, und Agenten können Zwischenschritte melden. Wenn das Gateway den gesamten Körper puffert, verliert die Anwendung frühes Feedback, selbst wenn das Backend korrekt streamt. Laut Google unterstützt die Vorschau Server-Sent Events, das gängige Muster für die Modellausgabe an Browser und Client-SDKs. Die Quelle geht auch auf langlebigeren Agenten- und Remote-MCP-Verkehr ein. Das technische Ziel besteht darin, die Durchsetzung und Weiterleitung von Richtlinien aufrechtzuerhalten und gleichzeitig zu ermöglichen, dass die Ereigniszustellung beginnt, bevor das Backend fertig ist. Die vom Benutzer tatsächlich wahrgenommene Latenz hängt immer noch vom Modell, Netzwerk, Client-Rendering und der Gateway-Konfiguration ab.

Laut Google kann ein Gateway, das seine Modell-Routing-Funktion nutzt, von Gemini-, Claude- und OpenAI-gpt-oss-Modellen streamen, die über seinen Modellgarten verfügbar sind. Das Modellrouting macht einen einzelnen OpenAI-kompatiblen Endpunkt verfügbar und wählt in einer Anfrage ein Backend aus dem Modellfeld aus. Das ist ein nützlicher Kontrollpunkt für Authentifizierung, Quote und Kostenpolitik, aber ein einheitlicher Endpunkt macht die Modelle hinsichtlich Verhalten, Kontextbeschränkungen oder Datenbegriffen nicht austauschbar. Ein Test sollte aufzeichnen, welches Modell eine Anfrage tatsächlich bedient hat, ob Nutzung und Fehler korrekt zugeordnet wurden und ob eine Client-Trennung Arbeit im Upstream freigibt. Der Blog beschreibt das Produktverhalten; In diesem Artikel wird die Streaming-Implementierung eines Anbieters nicht unabhängig getestet.

Die öffentliche Vorschau weist explizite Lücken auf

Google listet benutzerdefinierte Domänen über serverlose NEGs und einen externen Application Load Balancer, die Aktivierung der Cloud-Konsole und Terraform-Unterstützung als beim ersten Vorschaustart nicht verfügbar und für den Vorschauzeitraum geplant auf. Ein Operator, der einen dieser Pfade benötigt, sollte ihn nicht aus dem generischen API-Gateway-Namen ableiten. Für die Vorschau ist bei der Gateway-Erstellung ein Opt-In-Flag erforderlich. In dem Beitrag heißt es, dass eine allgemeine Verfügbarkeit geplant sei, um Streaming ohne Opt-in zum normalen Verhalten zu machen, aber das sei ein Zukunftsplan, nicht der heutige Stand. Ein Team sollte sein vorhandenes Nicht-Streaming-Gateway funktionsfähig halten, während es ein separates Test-Gateway erstellt, und dann den Datenverkehr erst dann fördern, wenn die fehlenden Verwaltungsfunktionen und das Client-Verhalten akzeptabel sind.

Kennzahlen müssen anders interpretiert werden

Google warnt davor, dass Metriken zur Anforderungslatenz für einen Stream die Lebensdauer der Verbindung messen, nicht die Zeit bis zum ersten Byte. Eine Streaming-Anfrage sieht bei dieser Metrik möglicherweise gerade deshalb langsamer aus, weil der Benutzer über einen längeren Zeitraum inkrementelle Ausgaben erhält. Das ist kein Grund, die Latenz zu ignorieren; Dies ist ein Grund, das erste Ereignis, den Abschluss, die Leerlauflücken und das Verbindungsabbruchverhalten separat zu messen. Ein Agent-Client kann verbunden bleiben, während er auf ein Tool wartet oder Fortschritte liefert. Das Timeout, das Kontingent und die Abrechnungsbehandlung des Gateways sollten anhand dieses Musters überprüft werden. Andernfalls kann ein Upgrade die wahrgenommene Reaktionsfähigkeit verbessern, während Dashboards fehlerfreie Streams fälschlicherweise als langsame Transaktionen kennzeichnen.

Das Gateway bietet auch eine Richtlinien-Eingangstür für teure KI-Endpunkte. Authentifizierung pro Verbraucher, Ratenbegrenzungen und Routing können dringlicher sein, wenn eine Antwort viele Sekunden lang offen bleibt. Die Vorschauquelle bietet keine pauschale Kostenreduzierung oder Leistungsgarantie. Jeder Geschäftsfall muss Gateway-Gebühren, Upstream-Modellnutzung, Wiederholungsversuche und verschwendete Erzeugung nach einer Verbindungsunterbrechung berücksichtigen. Ein Server, der ein SSE-Ereignis ausgibt, ein Client, der es jedoch puffert, hat nicht den beabsichtigten Nutzen gebracht. Das Testen muss durchgängig erfolgen und die eigentliche Client-Bibliothek und ein Backend verwenden, das mehrere beobachtbare Ereignisse ausgibt.

Ein kleiner Integrationstest

Erstellen Sie ein neues vorschaufähiges Gateway in einer verfügbaren Umgebung und verweisen Sie es auf ein vorhandenes SSE-Test-Backend. Stellen Sie sicher, dass jedes Ereignis einen Client erreicht, bevor das nächste gesendet wird, dass Authentifizierungs- und Kontingentregeln weiterhin gelten und dass ein absichtlicher Clientabbruch die Upstream-Arbeit wie erwartet abschließt. Erfassen Sie die Latenz beim ersten Ereignis, die Gesamtdauer, Fehlercodes und die Nutzungszuordnung. Wiederholen Sie dies mit einer modellgerouteten Anfrage nur, wenn diese Produktfunktion im Umfang enthalten ist, und testen Sie fehlerhafte Ereignisse und ein langsames Backend. Vergleichen Sie abschließend die Konfiguration mit den angekündigten Vorschau-Ausschlüssen, bevor Sie die Migration planen. Bei diesen Schritten handelt es sich um eine vorgeschlagene Überprüfung und nicht um einen Anspruch darauf, dass die Vorschau von dieser Veröffentlichung akzeptiert wurde.

Die Entwicklung ist nützlich für Agentenschnittstellen, die Fortschritt und gestreamte Modellausgabe hinter einer API-Richtliniengrenze benötigen. Es handelt sich immer noch um eine öffentliche Vorschau mit Opt-in zum Zeitpunkt der Erstellung und fehlenden Verwaltungspfaden. Das Ausgabedatum vom 25. Oktober markiert den Zeitpunkt, an dem diese Analyse erstellt wurde; Der ursprüngliche Beitrag von Google ist vom 22. Oktober. Ein Team sollte die Upstream-Ankündigung und die aktuelle Produktdokumentation als Autorität für seine eigene Einführung nutzen, anstatt den Digest als Live-Funktionsstatusdienst zu behandeln.