IA, inférence et jetons, quelle aventure !
Bon, les enfants, stop immédiat. J’entends des mots comme « tokens » et « models » balancés comme de l’argot Gen Z dans une vidéo TikTok, et la plupart du temps, c’est complètement faux.
Je l’ai dit, c’est dit.
Il est grand temps d’expliquer comment construire les applications basées sur l’inférence, où créer et utiliser les jetons, et comment les différents éléments s’articulent entre eux. Prenez un café, et entrons directement dans le sujet.
Qu’est-ce qu’un serveur d’inférence ?
Je ne devrais pas avoir à commencer ici, mais je vais le faire. Quand nous parlons d’« inférence », nous expliquons en fait comment un grand modèle de langage (LLM) analyse l’ampleur de ses données. On ne fait pas appel directement à un LLM. Une « API LLM » n’existe pas vraiment, et je vous lancerai un regard sévère si vous l’utilisez.
Les API que vous utilisez pour lancer une inférence passent par, tenez-vous bien, un serveur d'inférence.
Les serveurs d'inférence exécutent les modèles d'IA, comme les serveurs d'applications exécutent Java et bien d'autres langages de développement. Vous ne lancez généralement pas un modèle localement sans passer par un serveur d'inférence. Parmi les options populaires figurent Ollama, vLLM, NVIDIA Triton et HuggingFace Text Generation Interface (TGI).
Comme pour les serveurs d’applications, sur lesquels vous déployez habituellement un package d’application, vous déployez un « package IA » (un modèle) sur un serveur d’inférence. Ce serveur fournit les capacités du modèle IA via une API comportant un nombre minimal de points de terminaison (par exemple, /generate, /completions ou /embeddings en REST ou gRPC), centrés sur des tâches d’inférence comme la génération de texte, la tokenisation ou les embeddings.
Pour interagir avec un serveur d'inférence, vous développez une application. Oui, une application traditionnelle (qui peut très bien être moderne) et elle communiquera avec le serveur d'inférence.
Vous obtenez aussi une application, soit dans un navigateur, soit sur un téléphone, qui utilise généralement une simple API pour communiquer avec l’application que vous avez créée. Et voilà ! Vous créez un flux de messages complet entre le client, l’application, le serveur d’inférence, et retour.
Oui, c’est simplement une nouvelle version de l’application web à trois niveaux, où la couche de données est remplacée par la couche d’inférence. Je sais, c’est vraiment décevant, n’est-ce pas ?
La forme la plus simple d’une application d’IA est une application web à trois niveaux, où le niveau des données est remplacé par un serveur d’inférence.
- Vous recevez une requête JSON, vous pouvez effectuer une génération augmentée par récupération (RAG), puis vous appelez le serveur d'inférence avec JSON. La RAG consiste généralement à créer un vecteur de la requête utilisateur, rechercher un contenu similaire dans un index vectoriel ou de recherche, puis intégrer ces extraits dans l’invite. Tout cela reste du trafic au format JSON. Aucun jeton modèle n’a encore été généré.
- Le serveur d'inférence analyse le JSON, découpe le texte en jetons du modèle, vérifie le contexte et les quotas, groupe les requêtes compatibles, exécute le modèle, puis retransforme les jetons de sortie en texte. Nous renvoyons une réponse JSON au demandeur. En cas de diffusion continue, nous décodons et envoyons les jetons au fur et à mesure. La plupart des API intègrent aussi un bloc d’utilisation indiquant le nombre de jetons en entrée et en sortie.
C’est ce qu’on appelle l’inférence. C’est simplement un nouveau type de charge applicative qui valorise la même rigueur opérationnelle à laquelle vous tenez, désormais incarnée par des jetons, du contexte et des flux plutôt que par des sessions, des cookies et des requêtes.
Alors, où se trouvent les jetons ?
C’est souvent à ce stade que l’on se trompe en utilisant les mots d’une façon qui va à l’encontre de la directive principale en matière de terminologie. Les jetons représentent les unités de mots traitées par un LLM. Un tokenizer les génère formellement sur le serveur d’inférence.
Vous pouvez intégrer un tokeniseur dans votre application pour compter les jetons en amont, ce qui vous aide à prévoir les coûts et à gérer localement les limites de débit. Cependant, le décompte final des jetons se fait dans la pile d'inférence. Les jetons représentent un modèle et non le trafic réseau ; les échanges transportent du texte JSON. Vous verrez les identifiants des jetons uniquement si l’API les renvoie explicitement.
Par défaut, l'infrastructure ne voit pas les jetons. Elle voit du JSON. Les jetons ne circulent pas sur le réseau. Pour que l’infrastructure puisse agir sur les jetons, vous devez les compter à la passerelle avec le même tokenizer ou considérer les comptes que le serveur de modèles fournit. Les jetons sont la monnaie de l’IA, mais ils restent principalement dans la pile d’inférence, sauf si vous choisissez de les exposer.
L’impact de l'inférence sur l’infrastructure
L’inférence n’a rien de mystique. C’est une charge de travail applicative avec de nouveaux paramètres. Le trafic est au format JSON. Les jetons correspondent aux unités du modèle. Les embeddings sont des vecteurs. Confondre ces éléments vous fera concevoir de mauvais contrôles, facturer incorrectement et déboguer une couche inadaptée. Par exemple, baser le routage sur la taille du JSON plutôt que sur le nombre de jetons peut surcharger un modèle avec des requêtes longues.
Si vous voulez que l’infrastructure prenne des décisions basées sur les jetons, montrez-lui comment faire. Installez un tokeniseur à la passerelle ou traitez les comptes que le serveur modèle fournit. Sinon, vos routeurs analyseront le texte, pas les jetons, et prendront des décisions au niveau du texte, alors que vos coûts s’accumulent sur la base des jetons. Assurez-vous que le tokeniseur correspond à celui du modèle (par exemple, celui de GPT-4 diffère de celui de LLaMA) pour garantir des mesures précises. Un tokeniseur qui ne correspond pas peut fausser le calcul des coûts ou des limites.
Considérez la disponibilité comme fonctionnelle et fiable, pas seulement active. Suivez les jetons par seconde, le délai avant le premier jeton et les erreurs de contexte (comme le dépassement des limites de la fenêtre contextuelle ou des résultats incohérents dus à une saturation) comme vous suiviez les requêtes par seconde et les accès au cache. Gérez vos journaux avec rigueur. Le trafic d’inférence ne constitue pas vos données d’entraînement, sauf si vous l’affirmez clairement. Si vous conservez les requêtes et réponses, assurez-vous de les protéger.
Nommez les choses précisément. Mesurez la bonne couche. Fixez des limites là où c’est important, comme des quotas basés sur des jetons à la passerelle pour éviter toute dérive des coûts. Agissez ainsi et l’inférence deviendra aussi saine que le reste de votre stack : prévisible, rentable, et fiable. Les jetons achètent des décisions dans le modèle, non la bande passante de votre réseau. Donnez un nom clair à chaque élément, vous maintiendrez la satisfaction de vos utilisateurs tout en maîtrisant vos factures.