Inférence d'IA en temps réel à grande échelle avec WebSockets et objets durables

En octobre 2024, nous avons parlé du stockage de milliards de journaux de votre application d'IA à l'aide d'AI Gateway, et de la manière dont nous avons utilisé la plateforme de développement de Cloudflare pour ce faire.

En octobre 2024, nous avons expliqué comment stocker des milliards de journaux de votre application d'IA à l'aide d'AI Gateway, et comment nous avons utilisé la plateforme de développement de Cloudflare pour ce faire.

Alors qu'AI Gateway traite déjà plus de 3 milliards de logs et connaît une croissance rapide, le nombre de connexions à la plateforme continue d'augmenter régulièrement. Pour aider les développeurs à gérer cette échelle plus efficacement, nous souhaitions proposer une alternative à la mise en œuvre de HTTP/2 keep-alive pour maintenir des connexions HTTP(S) persistantes, évitant ainsi la surcharge des poignées de main répétées et des négociations TLS à chaque nouvelle connexion HTTP à AI Gateway. . Nous comprenons que la mise en œuvre de HTTP/2 peut présenter des défis, en particulier lorsque de nombreuses bibliothèques et outils ne le prennent pas en charge par défaut et que la plupart des langages de programmation modernes disposent de bibliothèques WebSocket bien établies.

Dans cet esprit, nous avons utilisé la plateforme de développement et les objets durables de Cloudflare (oui, encore une fois !) pour créer une API WebSockets qui établit une connexion unique et persistante, permettant une communication continue.

Grâce à cette API, tous les fournisseurs d'IA pris en charge par AI Gateway sont accessibles via WebSocket, vous permettant de maintenir une connexion TCP unique entre votre application client ou serveur et AI Gateway. La meilleure partie ? Même si le fournisseur que vous avez choisi ne prend pas en charge les WebSockets, nous nous en occupons pour vous, en gérant les demandes adressées à votre fournisseur d'IA préféré.

En vous connectant via WebSocket à AI Gateway, nous effectuons les requêtes au service d'inférence pour vous en utilisant les protocoles pris en charge par le fournisseur (HTTPS, WebSocket, etc.), et vous pouvez garder la connexion ouverte pour exécuter autant de requêtes d'inférence que vous le souhaitez. voudrais.

Pour rendre votre connexion à AI Gateway plus sécurisée, nous introduisons également l'authentification pour AI Gateway. La nouvelle API WebSockets nécessitera une authentification. Tout ce que vous avez à faire est de créer un jeton API Cloudflare avec l'autorisation « AI Gateway : Run » et de l'envoyer dans l'en-tête cf-aig-authorization.

Dans l'organigramme ci-dessus :

1. Lorsque la passerelle authentifiée est activée et qu'un jeton valide est inclus, les demandes seront transmises avec succès.

2. Si la passerelle authentifiée est activée, mais qu'une demande ne contient pas l'en-tête cf-aig-authorization requis avec un jeton valide, la demande échouera. Cela garantit que seules les demandes vérifiées transitent par la passerelle.

3. Lorsque la passerelle authentifiée est désactivée, l'en-tête cf-aig-authorization est entièrement contourné et tout jeton, qu'il soit valide ou invalide, est ignoré.

Comment nous l'avons construit

Nous avons récemment utilisé des objets durables (DO) pour faire évoluer notre solution de journalisation pour AI Gateway, donc utiliser des WebSockets au sein des mêmes DO était une solution naturelle.

Lorsqu'une nouvelle connexion WebSocket est reçue par nos Cloudflare Workers, nous mettons en œuvre l'authentification de deux manières pour prendre en charge les diverses capacités des clients WebSocket. La méthode principale consiste à valider un jeton API Cloudflare via l'en-tête cf-aig-authorization, garantissant que le jeton est valide pour le compte et la passerelle de connexion.

Cependant, en raison des limitations des implémentations WebSocket du navigateur, nous prenons également en charge l'authentification via l'en-tête « sec-websocket-protocol ». Les clients WebSocket du navigateur n'autorisent pas les en-têtes personnalisés dans leur API standard, ce qui complique l'ajout de jetons d'authentification dans les requêtes. Bien que nous ne vous recommandons pas de stocker les clés API dans un navigateur, nous avons décidé d'ajouter cette méthode pour ajouter plus de flexibilité à tous les clients WebSocket.

Après cette étape de vérification initiale, nous mettons à niveau la connexion vers l'Objet Durable, ce qui signifie qu'il gérera désormais tous les messages de la connexion. Avant que la nouvelle connexion ne soit pleinement acceptée, nous générons un UUID aléatoire, afin que cette connexion soit identifiable parmi tous les messages reçus par l'Objet Durable. Lors d'une connexion ouverte, tous les paramètres AI Gateway transmis via les en-têtes, tels que cf-aig-skip-cache (qui contourne la mise en cache lorsqu'il est défini sur true), sont stockés et appliqués à toutes les requêtes de la session. Cependant, ces en-têtes peuvent toujours être remplacés pour chaque requête, tout comme avec Universal Endpoint aujourd'hui.

Comment ça marche

Une fois la connexion établie, l'objet Durable commence à écouter les messages entrants. À partir de ce moment, les utilisateurs peuvent envoyer des messages au format universel AI Gateway via WebSocket, simplifiant ainsi la transition de votre application d'une configuration HTTP existante vers une communication basée sur WebSockets.

Lorsqu'un nouveau message atteint l'objet Durable, il est traité à l'aide du même code qui alimente le point de terminaison universel HTTP, permettant une réutilisation transparente du code entre les Workers et les objets durables — l'un des principaux avantages de la construction sur Cloudflare.

Pour les demandes sans streaming, la réponse est enveloppée dans une enveloppe JSON, ce qui nous permet d'inclure des informations supplémentaires au-delà de l'inférence AI elle-même, telles que l'ID du journal AI Gateway pour cette demande.

Voici un exemple de réponse à la demande ci-dessus :

Pour les demandes de streaming, AI Gateway envoie un message initial avec les métadonnées de la demande indiquant au développeur que le flux démarre.

Après ce message initial, tous les morceaux de streaming sont relayés en temps réel vers la connexion WebSocket dès qu'ils arrivent du fournisseur d'inférence. Notez que seul le champ eventId est inclus dans les métadonnées de ces morceaux de streaming (plus d'informations sur ce qu'est ce nouveau champ ci-dessous).

Cette approche répond à deux objectifs :

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!