Industrialisation des passerelles LLM : architecture, compromis et dures leçons — Kanish Manuja, Twilio
AAI Engineer
Computing/SoftwareManagementInternet Technology
Transcript
00:00:00Je suis Ganesh Manuja. Je suis ingénieur principal chez Twilio. Commençons par un rapide alevage de main.
00:00:20Qui ici a déjà vu le message : un problème est survenu, veuillez réessayer ?
00:00:27Eh bien, nous avons quelques chanceux et d'autres qui ont bien mangé à midi.
00:00:33Derrière ce message simple se cache en fait un système très complexe qui vous l'affiche alors même que les fournisseurs de modèles sont en panne.
00:00:45Et c'est ce que nous allons industrialiser aujourd'hui ou discuter d'industrialiser.
00:00:50Alors, qu'est-ce qu'une passerelle LLM ?
00:00:52Une passerelle LLM est un point d'entrée ou un middleware entre vos applications et les fournisseurs de modèles en arrière-plan.
00:00:58Elle gère plein de choses : le routage, l'authentification, les secours, les limites de taux, tout type de gouvernance imaginable.
00:01:08Au cœur même de la passerelle se trouve un arbitrage entre quatre éléments.
00:01:13Il s'agit de la disponibilité, de la latence, des garde-fous et des coûts.
00:01:18En cas de dégradation, vous ne pouvez pas maximiser les quatre.
00:01:22Vous devez choisir ce que vous voulez.
00:01:25Grâce à cette présentation, si vous utilisez une passerelle LLM, j'aimerais vous aider à faire ce choix pour votre cas d'usage.
00:01:35Et si vous concevez une passerelle, je veux que vous conceviez ou fournissiez ces leviers à vos appelants et clients pour qu'ils soient satisfaits.
00:01:46Commençons par la disponibilité.
00:01:50Si vous n'avez qu'un seul fournisseur de modèles, son plafond devient votre plafond.
00:01:56Sa panne devient votre panne.
00:02:03En génie logiciel classique, la façon de gérer une dépendance peu fiable est de faire des nouvelles tentatives.
00:02:11Des nouvelles tentatives avec des retards exponentiels et des variations aléatoires.
00:02:15Et quand tout cela échoue, vous avez un disjoncteur qui s'active après un nombre suffisant d'échecs, et vous arrêtez d'appeler ce maudit service.
00:02:24Ce n'est pas suffisant pour les LLM.
00:02:26Les LLM sont très différents de vos API rapides et bon marché sur lesquelles vous relancez des requêtes.
00:02:32Relancer une API LLM consomme très rapidement votre budget de latence.
00:02:38De plus, déclencher un disjoncteur alors que vous avez un autre fournisseur de modèles parfaitement fonctionnel vers qui router n'a pas de sens.
00:02:47Vous devriez utiliser le deuxième fournisseur.
00:02:48Et troisièmement, comme je l'ai dit, les appels sont lents et coûteux.
00:02:53Par conséquent, les nouvelles tentatives aveugles ne font que multiplier vos coûts et vos latences de queue.
00:02:58Quelle est donc la meilleure idée ici ?
00:03:02Il s'agit en fait d'un mécanisme de secours par requête.
00:03:05Cela signifie que vous pouvez essayer le fournisseur de modèles A, puis, en séquence, essayer le fournisseur B si votre requête vers A échoue.
00:03:14Une autre option à envisager est d'envoyer des requêtes aux deux fournisseurs en parallèle, mais seulement si vous êtes extrêmement obsédé par la latence, car cela va tout simplement doubler vos coûts.
00:03:26Certains schémas de disjonction similaires s'appliquent également ici aux LLM.
00:03:32Si vous savez que votre fournisseur principal échoue depuis un certain temps, il est inutile de réessayer immédiatement.
00:03:40Vous le retirez de l'équilibreur de charge ou de votre chemin de requêtes, vous le placez en période de refroidissement, puis, après quelques minutes, vous essayez de le réintégrer.
00:03:51Un choix intéressant à faire ici est de déterminer où sont enregistrés vos compteurs d'échecs.
00:03:59Vous pouvez décider de stocker les compteurs d'échecs en mémoire sur les instances qui traitent votre trafic, ou d'utiliser des informations partagées à l'échelle de l'ensemble du parc.
00:04:12Il y a des compromis.
00:04:14Si vous voulez des basculements rapides, une approche à l'échelle du parc est utile.
00:04:19Et avec des compteurs d'état locaux par instance, le problème auquel vous faites face est que chaque fois que vous modifiez la taille de votre déploiement, votre configuration et vos attentes changent.
00:04:30C'est donc un point à prendre en compte.
00:04:34Ce diagramme épuré ne montrait pas vraiment certains des autres pièges dont je vais parler.
00:04:39Les mécanismes de secours ne sont pas transparents.
00:04:41Bien que l'industrie converge vers un format compatible avec l'API OpenAI, je dirais qu'il subsiste des nuances.
00:04:49Vous devez donc vraiment tester vos solutions de secours en profondeur.
00:04:52Elles peuvent présenter des différences dans vos schémas d'appel d'outils, vos limites de jetons, vos motifs d'arrêt et j'en passe.
00:04:58Ainsi, avec les passerelles LLM, vous pouvez disposer d'une couche de normalisation qui garantit des basculements inter-fournisseurs fluides.
00:05:08Un autre point important est le streaming.
00:05:15En gros, personne ne veut attendre 30 secondes pour voir un mur de texte apparaître devant soi.
00:05:22Il existe donc des cas d'usage où le streaming est absolument indispensable.
00:05:26Mais cela a un coût.
00:05:27Vous sacrifiez vos leviers d'action.
00:05:29Vous ne pouvez pas -- une fois que vous avez choisi de travailler avec le fournisseur A, vous devez continuer avec lui.
00:05:36Vous ne pouvez pas changer de fournisseur au milieu d'un flux.
00:05:39Tout ce qui a été envoyé au client est définitif.
00:05:42Et c'est de là que vient ce message : un problème est survenu.
00:05:46C'est celui que vous voyez.
00:05:48Ce n'est pas par fainéantise.
00:05:49C'est voulu par conception.
00:05:52Et c'est l'un des compromis.
00:05:54J'aimerais souligner un autre point où j'ai vu des équipes trébucher encore et encore.
00:06:00Elles provisionnent et testent très bien leurs fournisseurs principaux.
00:06:05Mais le second fournisseur, le fournisseur de secours, ne bénéficie pas nécessairement du même niveau d'attention.
00:06:11Je soutiendrais que vos débits, votre capacité ou votre marge de manœuvre devraient être encore plus élevés pour le second fournisseur ou le fournisseur de secours.
00:06:21Car c'est votre dernière ligne de défense.
00:06:23Si celui-ci tombe en panne, votre application tombe en panne.
00:06:29Discutons des latences.
00:06:31Les pannes de disponibilité sautent immédiatement aux yeux.
00:06:34Elles échouent.
00:06:36Vous recevez une alerte.
00:06:37Vous êtes bipé.
00:06:38Mais les latences élevées peuvent être insidieuses.
00:06:42Et elles méritent plus d'attention, je dirais, que le simple réglage de vos services pour la disponibilité.
00:06:49Un point à souligner.
00:06:54Une passerelle peut exécuter des charges de travail mixtes.
00:06:58Vous pouvez avoir des requêtes d'intégration qui prennent moins d'une seconde.
00:07:04Vous pouvez avoir des requêtes de classification qui prennent moins d'une seconde.
00:07:07Vous avez des requêtes de discussion prenant trois secondes.
00:07:10Et des requêtes de raisonnement prenant beaucoup de temps.
00:07:13Petite question à main levée.
00:07:15Levez la main si vous mesurez la latence globale de l'ensemble de votre service.
00:07:20Eh bien, c'était une question piège.
00:07:23Désolé.
00:07:24Vous ne devriez pas.
00:07:25Ça n'a pas de sens.
00:07:26C'est faux.
00:07:27Vous devriez suivre le P99 par modèle et par route, et non une valeur globale à l'échelle de la passerelle.
00:07:32Une valeur globale à l'échelle de la passerelle n'a aucun sens, surtout si vous exécutez des charges de travail mixtes.
00:07:36Et j'espère que vous ne le faites pas, pour ceux qui ont levé la main.
00:07:40Autre chose que je ne saurais trop souligner : configurez des délais d'attente par classe de modèle et par route.
00:07:49C'est la cause racine numéro un de vos pannes silencieuses.
00:07:54Si vous n'avez pas de délai d'attente, votre passerelle croit que votre requête est traitée avec succès alors que ce n'est pas le cas.
00:08:00Je vous laisse sur ce message concernant spécifiquement les latences.
00:08:05La normale d'un modèle de raisonnement correspond en fait à la panne d'un modèle de discussion.
00:08:09Vous devez donc impérativement suivre la latence par route.
00:08:13Bien, voici le sujet le plus délicat ou la diapositive qui m'a causé le plus de frayeurs : les modèles de raisonnement et de routage.
00:08:24C'est là que la latence est véritablement imprévisible.
00:08:29Les modèles de raisonnement ne vous donnent pas... ils sont hautement non déterministes, bien plus que vos modèles classiques.
00:08:40Dans de nombreux cas, vous ne pouvez pas régler la température à zéro.
00:08:43Et une même invite peut prendre de deux à 60 secondes.
00:08:48Nous l'avons constaté en production, où le P99 est soudainement monté à 60 secondes sans raison valable.
00:08:53Bien qu'il n'y ait pas de solution magique, je vous recommande de commencer au moins par fixer le niveau de raisonnement par route.
00:09:03Quant aux modèles de routage, ils cachent cette abstraction derrière vous.
00:09:08Par exemple, ils choisissent les modèles à exécuter.
00:09:11Je vous recommande fortement de rendre vos requêtes aussi déterministes que possible au sein d'un système non déterministe.
00:09:23Une autre idée consiste à couvrir la queue de distribution.
00:09:26Vous pouvez lancer une autre requête si votre requête principale a déjà consommé, disons, le P90 de votre budget de latence.
00:09:37Cela permet de protéger efficacement la queue P99 pour vos services.
00:09:44Très bien, c'est l'un de mes sujets préférés.
00:09:47Pour assurer la sécurité de votre modèle, vous devez mettre en place des garde-fous.
00:09:53Ces garde-fous sont nécessaires pour empêcher les attaques par injection de requêtes, maintenir les filtres de données personnelles, intégrer des filtres de toxicité et empêcher les LLM d'insulter vos clients.
00:10:08Toutes ces bonnes choses.
00:10:11Mais tout comme un fournisseur de modèles, il y a aussi des compromis.
00:10:15Les garde-fous sont similaires à n'importe quel autre service.
00:10:18Ils peuvent tomber en panne.
00:10:19Ils peuvent être peu fiables.
00:10:21Et c'est là que vous devez choisir.
00:10:24Optez-vous pour un échec ouvert ou un échec fermé ?
00:10:27Quand je dis échec ouvert, vous pouvez tout de même servir la requête même si vos garde-fous sont inactifs.
00:10:32En mode échec fermé, vous bloquez la requête et signalez que vous n'êtes pas disponible.
00:10:36C'est le compromis entre la disponibilité et la sécurité, dans une certaine mesure.
00:10:41Bien qu'il n'y ait pas de réponse universelle, cela dépend vraiment de votre cas d'usage.
00:10:45Vous pouvez décider, par exemple, pour un filtre de toxicité, s'il n'est pas opérationnel, de quand même traiter la requête.
00:10:53Le choix par défaut doit donc être le pire scénario avec lequel vous pouvez vivre.
00:11:02Il y a plusieurs choses que vous pouvez faire pour améliorer le comportement de vos systèmes face à des garde-fous inopérants et pour gérer l'instabilité de ces derniers.
00:11:17La première est le budget temporel.
00:11:20Votre requête ne devrait jamais être limitée par le temps d'exécution des garde-fous.
00:11:25Ce doit toujours être le LLM qui dicte le rythme.
00:11:29Assurez-vous donc de définir des temps d'attente et que ces garde-fous s'exécutent avec un budget de temps spécifique.
00:11:38Autre point important : le recours de secours.
00:11:40Vous le savez probablement, et je l'ai mentionné, nous discutons toujours de solutions de repli concernant les fournisseurs de modèles.
00:11:47Mais les garde-fous sont aussi des services critiques, pour lesquels vous pouvez envisager des solutions de repli, des fournisseurs secondaires, des vérifications secondaires, et mettre en cache les décisions pour maintenir votre service disponible lorsqu'un fournisseur de garde-fous est en panne.
00:12:03Un autre choix intéressant qui se pose en matière de garde-fous est leur emplacement.
00:12:10En général, vous pouvez placer les garde-fous de trois manières.
00:12:15Vous pouvez utiliser un pré-crochet qui s'exécute, où le garde-fous s'applique directement sur l'entrée.
00:12:19C'est probablement le plus sûr, mais cela ajoute de la latence séquentielle à vos requêtes.
00:12:26Une autre option est en parallèle.
00:12:29C'est l'une de mes méthodes préférées, mais attention, le streaming ne fonctionne pas très bien ici avec le mode parallèle.
00:12:35Donc, si vous produisez des sorties structurées, veuillez ne pas utiliser le streaming.
00:12:40Essayez de réduire les latences et exécutez ces garde-fous de manière concurrente pour vos sorties structurées.
00:12:46Une autre option est le post-crochet.
00:12:48Ceux-ci sont parfaits pour surveiller les sorties, auditer vos résultats, et ainsi de suite.
00:12:58Jusqu'à présent, j'ai donc abordé tout ce qui peut mal tourner en ce qui concerne nos dépendances.
00:13:06Nous n'avons pas mentionné que nous ajoutons en fait une autre dépendance dans le chemin de la requête elle-même, à savoir la passerelle LLM centrale.
00:13:15Il y a des situations qui nous ont causé des problèmes et dont nous avons tiré des leçons que je souhaite partager avec vous si vous travaillez sur une passerelle LLM ou si vous en utilisez une.
00:13:25La première concerne les limites partagées.
00:13:28Assurez-vous que vos clés API sont séparées par route, par cas d'usage, de la manière la plus granulaire possible que vous puissiez imaginer.
00:13:40Avoir un locataire bruyant peut être l'un des plus grands problèmes ici.
00:13:47Autre point : le délestage de charge.
00:13:50C'est une fonctionnalité que vous devriez intégrer dans vos procédures et exercices de crise pour vous assurer que la passerelle que vous utilisez le prend en charge.
00:13:59Car lorsqu'on subit une tempête de nouvelles tentatives, il devient très difficile de simplement étendre l'infrastructure.
00:14:03On ne peut pas simplement étendre des services soumis à une tempête de nouvelles tentatives.
00:14:07Et tous ces serveurs web disposent d'une file d'attente interne configurable.
00:14:13Assurez-vous qu'elles sont limitées et qu'elles ne peuvent pas accepter un nombre infini de requêtes.
00:14:19Et si vous souhaitez une logique personnalisée, vous pouvez même mettre en place une priorisation du trafic pour veiller à ce que vos cas d'usage les plus importants soient bien servis sous charge.
00:14:29La dernière chose dont je veux parler est l'idée même d'une passerelle centrale.
00:14:38C'est un point de défaillance unique.
00:14:40Donc, si vous envisagez d'avoir une passerelle centrale pour toute votre entreprise pour plusieurs LLM, je vous conseillerais de reconsidérer la question et d'examiner vos motivations.
00:14:52Ce que j'ai remarqué, c'est que dans la plupart des cas, ce n'est pas d'une passerelle centrale dont ils ont besoin.
00:14:57Ils veulent une gouvernance centralisée.
00:15:00Et il existe une voie pour décentraliser la passerelle tout en centralisant la gouvernance.
00:15:07N'essayez donc pas de centraliser votre trafic, mais vous pouvez utiliser des plugins ou du code personnalisé pour centraliser votre gouvernance.
00:15:17La gouvernance peut prendre la forme d'un suivi des coûts, de la gestion des limites de débit, ainsi que d'autres solutions possibles.
00:15:24Explorez ces options avant de vous lancer dans la création d'une passerelle unique pour toute l'entreprise.
00:15:30Elle peut être gérée par une seule équipe, mais je ne recommanderais pas de la déployer sous forme d'une instance unique pour toute l'entreprise, même si elle est distribuée.
00:15:43Ceci étant dit, je souhaite terminer cette intervention sur une note personnelle.
00:15:47C'est l'anniversaire de mon fils aujourd'hui, et je suis ici à parler de coupe-circuits à des étrangers.
00:15:54Le minimum que vous puissiez faire pour moi est d'aller prévenir un incident pour moi et pour vos clients.
00:16:02Merci.
00:16:03Si vous avez des questions, oui.
00:16:06.