Applications d'IA : conseils d'architecture avancés (AKA AAAA !)

Surprendre! Il s'agit d'un article de blog bonus pour la série AI for Web Devs que j'ai récemment terminée. Si vous n'avez pas encore lu cette série, je vous encourage à Vérifiez-le .

Cet article examinera l'architecture du projet existante et les moyens de l'améliorer à la fois pour les développeurs d'applications et pour l'utilisateur final.

Je vais aborder quelques concepts généraux et utiliser des produits Akamai spécifiques dans mes exemples.

Architecture des applications de base

L'application existante est assez basique. Un utilisateur soumet deux adversaires, puis l'application renvoie une réponse générée par l'IA indiquant qui gagnerait dans un combat.

L'architecture est également simple :

1. Le client envoie une requête à un serveur.

   
   

2. Le serveur crée une invite et la transmet à OpenAI.

   
   

3. OpenAI renvoie une réponse en continu au serveur.

   
   

4. Le serveur effectue les ajustements nécessaires et transmet la réponse en streaming au client.

J'ai utilisé les services de cloud computing d'Akamai (anciennement Linode ), mais ce serait vraiment la même chose pour n’importe quel service d’hébergement.

🤵 ressemble à un serveur dans un restaurant chic, et 👁️‍🗨️ est « un œil », ou IA. mdr

Techniquement, cela fonctionne bien, mais il existe quelques problèmes, en particulier lorsque les utilisateurs font des demandes en double. Il pourrait être plus rapide et plus rentable de stocker les réponses sur notre serveur et d'accéder à OpenAI uniquement pour les demandes uniques.

Cela suppose que nous n'avons pas besoin que chaque requête soit non déterministe (la même entrée produit une sortie différente). Supposons qu'il soit acceptable que la même entrée produise la même sortie. Après tout, une prédiction quant à savoir qui gagnerait dans un combat ne changerait probablement pas.

Ajouter une architecture de base de données

Si nous voulons stocker les réponses d'OpenAI, un endroit pratique pour les placer est dans une sorte de base de données qui permet une recherche rapide et facile à l'aide des deux adversaires. De cette façon, lorsqu'une requête est faite, nous pouvons d'abord vérifier la base de données :

1. Le client envoie une requête à un serveur.

   
   

2. Le serveur recherche une entrée existante dans la base de données qui correspond à l'entrée de l'utilisateur.

   
   

3. Si un enregistrement précédent existe, le serveur répond avec ces données et la demande est terminée. Ignorez les étapes suivantes.

   
   

4. Dans le cas contraire, le serveur suit la troisième étape du flux précédent.

   
   

5. Avant de fermer la réponse, le serveur stocke les résultats OpenAI dans la base de données.

Les lignes pointillées représentent les requêtes facultatives, et le 💽 ressemble en quelque sorte à un disque dur.

Avec cette configuration, toutes les demandes en double seront traitées par la base de données. En rendant certaines requêtes OpenAI facultatives, nous pouvons potentiellement réduire la latence des utilisateurs et économiser de l'argent en réduisant le nombre de requêtes API.

C'est un bon début, surtout si le serveur et la base de données existent dans la même région. Cela entraînerait des temps de réponse beaucoup plus rapides que d'aller sur les serveurs d'OpenAI.

Cependant, à mesure que notre application devient plus populaire, nous pourrions commencer à attirer des utilisateurs du monde entier. Des recherches plus rapides dans la base de données sont une bonne chose, mais que se passe-t-il si le goulot d'étranglement est la latence due au temps passé en vol ?

Nous pouvons répondre à cette préoccupation en rapprochant les choses de l’utilisateur.

Intégrez Edge Compute

Si vous n'êtes pas déjà familier avec le terme « bord », cette partie peut prêter à confusion, mais je vais essayer de l'expliquer simplement. Edge fait référence au contenu aussi proche que possible de l’utilisateur. Pour certaines personnes, cela peut signifier des appareils IoT ou des tours de téléphonie mobile, mais dans le cas du Web, l'exemple canonique est un Réseau de diffusion de contenu (CDN) .

Je vous épargne les détails, mais un CDN est un réseau d'ordinateurs distribués à l'échelle mondiale qui peuvent répondre aux demandes des utilisateurs depuis le nœud le plus proche du réseau ( quelque chose sur lequel j'ai écrit dans le passé ). Alors qu'ils étaient traditionnellement conçus pour les actifs statiques, ces dernières années, ils ont commencé à prendre en charge le calcul de pointe ( aussi quelque chose sur lequel j'ai écrit dans le passé ).

Avec le calcul de pointe, nous pouvons déplacer une grande partie de notre logique backend très près de l'utilisateur, et cela ne s'arrête pas au calcul. La plupart des fournisseurs de calcul Edge proposent également une sorte de magasin clé-valeur finalement cohérent dans les mêmes nœuds Edge.

Quel impact cela pourrait-il avoir sur notre candidature ?

1. Le client envoie une demande à notre backend.

   
   

2. Le réseau de calcul périphérique achemine la demande vers le nœud périphérique le plus proche.

   
   

3. Le nœud Edge recherche une entrée existante dans le magasin clé-valeur qui correspond à l'entrée de l'utilisateur.

   
   

4. Si un enregistrement précédent existe, le nœud périphérique répond avec ces données et la demande est terminée. Ignorez les étapes suivantes.

   
   

5. Sinon, le nœud périphérique transmet la requête au serveur d'origine, qui la transmet à OpenAI et yadda yadda yadda.

   
   

6. Avant de fermer la réponse, le serveur stocke les résultats OpenAI dans le magasin clé-valeur Edge.

Le nœud périphérique est la boîte bleue et est représenté par 🔪 car il a un bord, EdgeWorker est le produit de calcul périphérique d'Akamai représenté par 🧑‍🏭 et EdgeKV est le magasin de valeurs-clés d'Akamai représenté par 🔑🤑🏪. La zone périphérique est plus proche du client que du serveur d'origine dans le cloud pour représenter la distance physique.

Le serveur d'origine n'est peut-être pas strictement nécessaire ici, mais je pense qu'il est plus probable qu'il soit là. Pour des raisons de flux de données, de calcul et de logique, cette architecture est essentiellement la même que l'architecture précédente. La principale différence est que les résultats précédemment stockés existent désormais très près des utilisateurs et peuvent être renvoyés presque immédiatement.

(Remarque : bien que les données soient mises en cache en périphérie, la réponse est toujours construite dynamiquement. Si vous n'avez pas besoin de réponses dynamiques, il peut être plus simple d'utiliser un CDN devant le serveur d'origine et de définir les en-têtes HTTP corrects sur cache la réponse. Il y a beaucoup de nuances ici, et je pourrais en dire plus mais… eh bien, je suis fatigué et je n'ai pas vraiment envie. N'hésitez pas à nous contacter si vous avez des questions.)

Maintenant on cuisine ! Toutes les demandes en double recevront une réponse presque immédiate, tout en nous épargnant des requêtes API inutiles.

Cela règle l'architecture des réponses textuelles, mais nous avons également des images générées par l'IA.

Cacher ces images

La dernière chose que nous considérerons aujourd’hui, ce sont les images. Lorsqu’il s’agit d’images, nous devons penser à la livraison et au stockage. Je suis sûr que les gens d'OpenAI ont leurs propres solutions, mais certaines organisations souhaitent posséder l'intégralité de l'infrastructure pour des raisons de sécurité, de conformité ou de fiabilité. Certains peuvent même exécuter leurs propres services de génération d’images au lieu d’utiliser OpenAI.

Dans le flux de travail actuel, l’utilisateur fait une demande qui parvient finalement à OpenAI. OpenAI génère l'image mais ne la renvoie pas. Au lieu de cela, ils renvoient une réponse JSON avec l'URL de l'image, hébergée sur l'infrastructure d'OpenAI.

Avec cette réponse, une balise <img> peut être ajoutée à la page à l'aide de l'URL, ce qui lance une autre demande pour l'image réelle.

Si nous voulons héberger l’image sur notre propre infrastructure, nous avons besoin d’un endroit pour la stocker. Nous pourrions écrire les images sur le disque du serveur d'origine, mais cela pourrait rapidement utiliser l'espace disque et nous devrions mettre à niveau nos serveurs, ce qui peut être coûteux.

Stockage d'objets est une solution beaucoup moins chère ( J'ai aussi écrit à ce sujet ). Au lieu d'utiliser l'URL OpenAI pour l'image, nous pourrions la télécharger sur notre propre instance de stockage d'objets et utiliser cette URL à la place.

Cela résout la question du stockage, mais les compartiments de stockage d'objets sont généralement déployés dans une seule région. Cela fait écho au problème que nous avons rencontré avec le stockage du texte dans une base de données. Une seule région peut être éloignée des utilisateurs, ce qui peut entraîner une latence importante.

Ayant déjà introduit l'avantage, il serait assez trivial d'ajouter des fonctionnalités CDN uniquement pour les actifs statiques (franchement, chaque site devrait avoir un CDN). Une fois configuré, le CDN extraira les images du stockage d'objets lors de la demande initiale et les mettra en cache pour toute demande future des visiteurs de la même région.

Voici à quoi ressemblerait notre flux d'images :

1. Un client envoie une demande pour générer une image basée sur ses adversaires.

   
   

2. Edge Computing vérifie si les données d'image pour cette requête existent déjà. Si c'est le cas, il renvoie l'URL.

   
   

3. L'image est ajoutée à la page avec l'URL et le navigateur demande l'image.

   
   

4. Si l'image a été préalablement mise en cache dans le CDN, le navigateur la charge presque immédiatement. C'est la fin du flux.

   
   

5. Si l'image n'a pas été précédemment mise en cache, le CDN extraira l'image de l'emplacement de stockage d'objets, en mettra une copie en cache pour les demandes futures et renverra l'image au client. C'est une autre fin du flux.

   
   

6. Si les données d'image ne se trouvent pas dans le magasin clé-valeur Edge, la demande de génération de l'image est transmise au serveur puis à OpenAI, qui génère l'image et renvoie les informations d'URL. Le serveur démarre une tâche pour enregistrer l'image dans le compartiment de stockage d'objets, stocke les données d'image dans le magasin clé-valeur Edge et renvoie les données d'image au calcul Edge.

   
   

7. Avec les nouvelles données d'image, le client crée l'image qui crée une nouvelle demande et continue à partir de l'étape cinq ci-dessus.

Le réseau de livraison de contenu est désigné par un camion de livraison (🚚) et un signal réseau (📶), et le stockage d'objets est désigné par des chaussettes dans une boîte (🧦📦) ou des objets stockés. Cette légende n'est probablement pas nécessaire, car je pense qu'elle est claire, mais je suis trop fier de mon jeu d'emoji et j'ai besoin d'une validation. Merci de m'avoir fait plaisir. Continuer.

Cette dernière architecture est certes un peu plus complexe, mais si votre application doit gérer un trafic important, elle mérite d'être envisagée.

Voilà

C'est parti ! Avec tous ces changements en place, nous avons créé du texte et des images générés par l'IA pour les demandes uniques et avons servi le contenu mis en cache depuis la périphérie pour les demandes en double. Le résultat est des temps de réponse plus rapides et une bien meilleure expérience utilisateur (en plus de moins d’appels API).

J'ai volontairement conservé ces diagrammes d'architecture applicables à diverses bases de données, calculs de pointe, stockage d'objets et fournisseurs de CDN. J'aime que mon contenu soit largement applicable. Mais il convient de mentionner que l’intégration de la périphérie ne se limite pas à la performance. Il existe de nombreuses fonctionnalités de sécurité vraiment intéressantes que vous pouvez également activer.

Par exemple, sur le réseau d'Akamai, vous pouvez avoir accès à des éléments tels que pare-feu d'applications Web (WAF) , protection contre le déni de service distribué (DDoS) , détection intelligente des robots , et plus. Cependant, tout cela dépasse le cadre de l’article d’aujourd’hui.

Donc, pour l'instant, je vous laisse avec un grand « merci » pour votre lecture. J'espère que tu as appris quelque chose. Et comme toujours, n'hésitez pas à nous contacter à tout moment pour nous faire part de vos commentaires, questions ou préoccupations.

Merci beaucoup d'avoir lu. Si vous avez aimé cet article et souhaitez me soutenir, la meilleure façon de le faire est de Partagez-le , Inscrivez-vous à ma newsletter , et Suis moi sur Twitter .

Publié initialement le austingil.com .