KI-Inferenz in Echtzeit im großen Maßstab mit WebSockets und langlebigen Objekten

Im Oktober 2024 sprachen wir über die Speicherung von Milliarden von Protokollen Ihrer KI-Anwendung mit AI Gateway und darüber, wie wir dazu die Entwicklerplattform von Cloudflare nutzten.

Im Oktober 2024 haben wir darüber berichtet, wie Sie mit AI Gateway Milliarden von Protokollen Ihrer KI-Anwendung speichern und wie wir dazu die Entwicklerplattform von Cloudflare nutzen.

Da AI Gateway bereits über 3 Milliarden Protokolle verarbeitet und ein schnelles Wachstum verzeichnet, nimmt die Anzahl der Verbindungen zur Plattform weiterhin stetig zu. Um Entwicklern dabei zu helfen, diese Größenordnung effektiver zu verwalten, wollten wir eine Alternative zur Implementierung von HTTP/2 Keep-Alive anbieten, um dauerhafte HTTP(S)-Verbindungen aufrechtzuerhalten und so den Overhead wiederholter Handshakes und TLS-Verhandlungen bei jeder neuen HTTP-Verbindung zu AI Gateway zu vermeiden . Wir verstehen, dass die Implementierung von HTTP/2 eine Herausforderung darstellen kann, insbesondere wenn viele Bibliotheken und Tools es möglicherweise nicht standardmäßig unterstützen und die meisten modernen Programmiersprachen über gut etablierte WebSocket-Bibliotheken verfügen.

Vor diesem Hintergrund haben wir die Entwicklerplattform von Cloudflare und Durable Objects (ja, wieder!) verwendet, um eine WebSockets-API zu erstellen, die eine einzige, dauerhafte Verbindung herstellt und so eine kontinuierliche Kommunikation ermöglicht.

Über diese API kann über WebSocket auf alle von AI Gateway unterstützten KI-Anbieter zugegriffen werden, sodass Sie eine einzige TCP-Verbindung zwischen Ihrer Client- oder Serveranwendung und dem AI Gateway aufrechterhalten können. Das Beste daran? Auch wenn Ihr ausgewählter Anbieter WebSockets nicht unterstützt, kümmern wir uns für Sie um die Verwaltung der Anfragen an Ihren bevorzugten KI-Anbieter.

Durch die Verbindung über WebSocket mit AI Gateway stellen wir die Anfragen an den Inferenzdienst für Sie unter Verwendung der vom Anbieter unterstützten Protokolle (HTTPS, WebSocket usw.), und Sie können die Verbindung offen halten, um so viele Inferenzanfragen wie Sie auszuführen möchte.

Um Ihre Verbindung zum AI Gateway sicherer zu machen, führen wir auch die Authentifizierung für AI Gateway ein. Die neue WebSockets-API erfordert eine Authentifizierung. Sie müssen lediglich ein Cloudflare-API-Token mit der Berechtigung „AI Gateway: Run“ erstellen und dieses im Header cf-aig-authorization senden.

Im Flussdiagramm oben:

1. Wenn das authentifizierte Gateway aktiviert ist und ein gültiges Token enthalten ist, werden Anfragen erfolgreich weitergeleitet.

2. Wenn Authenticated Gateway aktiviert ist, eine Anfrage jedoch nicht den erforderlichen cf-aig-authorization-Header mit einem gültigen Token enthält, schlägt die Anfrage fehl. Dadurch wird sichergestellt, dass nur verifizierte Anfragen das Gateway passieren.

3. Wenn das authentifizierte Gateway deaktiviert ist, wird der Header „cf-aig-authorization“ vollständig umgangen und alle Token – ob gültig oder ungültig – werden ignoriert.

Wie wir es gebaut haben

Wir haben kürzlich langlebige Objekte (DOs) verwendet, um unsere Protokollierungslösung für AI Gateway zu skalieren, daher war die Verwendung von WebSockets innerhalb derselben DOs eine natürliche Ergänzung.

Wenn unsere Cloudflare-Worker eine neue WebSocket-Verbindung empfangen, implementieren wir die Authentifizierung auf zwei Arten, um die vielfältigen Funktionen von WebSocket-Clients zu unterstützen. Die primäre Methode besteht darin, ein Cloudflare-API-Token über den cf-aig-authorization-Header zu validieren und sicherzustellen, dass das Token für das verbindende Konto und Gateway gültig ist.

Aufgrund von Einschränkungen bei Browser-WebSocket-Implementierungen unterstützen wir jedoch auch die Authentifizierung über den „sec-websocket-protocol“-Header. Browser-WebSocket-Clients erlauben keine benutzerdefinierten Header in ihrer Standard-API, was das Hinzufügen von Authentifizierungstokens in Anfragen erschwert. Obwohl wir nicht empfehlen, API-Schlüssel in einem Browser zu speichern, haben wir uns entschieden, diese Methode hinzuzufügen, um allen WebSocket-Clients mehr Flexibilität zu bieten.

Nach diesem ersten Überprüfungsschritt aktualisieren wir die Verbindung zum dauerhaften Objekt, was bedeutet, dass es nun alle Nachrichten für die Verbindung verarbeitet. Bevor die neue Verbindung vollständig akzeptiert wird, generieren wir eine zufällige UUID, sodass diese Verbindung unter allen vom dauerhaften Objekt empfangenen Nachrichten identifizierbar ist. Während einer offenen Verbindung werden alle über Header übergebenen AI Gateway-Einstellungen – wie z. B. cf-aig-skip-cache (das das Caching umgeht, wenn es auf „true“ gesetzt ist) – gespeichert und auf alle Anfragen in der Sitzung angewendet. Diese Header können jedoch weiterhin auf Anfragebasis überschrieben werden, genau wie heute beim Universal Endpoint.

Wie es funktioniert

Sobald die Verbindung hergestellt ist, beginnt das dauerhafte Objekt, auf eingehende Nachrichten zu warten. Ab diesem Zeitpunkt können Benutzer Nachrichten im AI Gateway-Universalformat über WebSocket senden und so den Übergang Ihrer Anwendung von einem bestehenden HTTP-Setup zu WebSockets-basierter Kommunikation vereinfachen.

Wenn eine neue Nachricht das dauerhafte Objekt erreicht, wird sie mit demselben Code verarbeitet, der den HTTP Universal Endpoint antreibt, wodurch eine nahtlose Wiederverwendung von Code zwischen Workern und dauerhaften Objekten ermöglicht wird – einer der Hauptvorteile des Aufbaus auf Cloudflare.

Bei Nicht-Streaming-Anfragen wird die Antwort in einen JSON-Umschlag verpackt, sodass wir über die KI-Inferenz selbst hinaus zusätzliche Informationen einschließen können, beispielsweise die AI Gateway-Protokoll-ID für diese Anfrage.

Hier ist eine Beispielantwort für die obige Anfrage:

Bei Streaming-Anfragen sendet AI Gateway eine erste Nachricht mit Anforderungsmetadaten, die dem Entwickler mitteilen, dass der Stream startet.

Nach dieser ersten Nachricht werden alle Streaming-Blöcke in Echtzeit an die WebSocket-Verbindung weitergeleitet, sobald sie vom Inferenzanbieter eintreffen. Beachten Sie, dass nur das Feld „eventId“ in den Metadaten für diese Streaming-Blöcke enthalten ist (weitere Informationen zu diesem neuen Feld finden Sie weiter unten).

Dieser Ansatz dient zwei Zwecken:

Das obige ist der detaillierte Inhalt vonKI-Inferenz in Echtzeit im großen Maßstab mit WebSockets und langlebigen Objekten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!