Bon, les enfants, on arrête tout tout de suite. J’entends des termes comme « tokens » et « modèles » employés à tort et à travers, comme de l’argot de la génération Z dans une vidéo TikTok, et la plupart du temps, c’est complètement faux.
J’ai dit ce que j’ai dit.
Il est (plus que) temps d’expliquer comment sont conçues les applications basées sur l’inférence, où les jetons sont créés et consommés, et comment les différentes pièces du puzzle s’imbriquent. Alors, prenez un café et entrons sans plus attendre dans le vif du sujet.
Qu’est-ce qu’un serveur d’inférence ?
Je ne devrais pas avoir à commencer par là, mais je vais quand même le faire. Quand on parle d’« inférence », on fait en réalité référence à la manière dont un grand modèle de langage (LLM) raisonne à partir de son immense volume de données. On n’appelle pas directement un LLM. Une « API de LLM », ça n’existe pas vraiment, et si vous employez cette expression, je vous lancerai « le regard désapprobateur d’une mère ».
Les API utilisées pour lancer l’inférence passent par… roulement de tambour… un serveur d’inférence.
Les serveurs d’inférence sont des environnements d’exécution pour les modèles d’IA, tout comme les serveurs d’applications le sont pour Java et de nombreux autres langages de développement. En règle générale, on n’exécute pas un modèle localement sans serveur d’inférence. Parmi les solutions les plus répandues figurent Ollama, vLLM, NVIDIA Triton et HuggingFace Text Generation Interface (TGI).
À présent, de la même manière que vous déployez généralement un package applicatif sur un serveur d’applications, vous déployez un « package d’IA » (un modèle) sur un serveur d’inférence. Ce serveur permet d’exposer les capacités du modèle d’IA via une API comportant un nombre minimal de points de terminaison (par exemple, /generate, /completions ou /embeddings en REST ou gRPC), dédiés aux tâches d’inférence du modèle telles que la génération de texte, la tokenisation ou la création d’embeddings.
Pour interagir avec un serveur d’inférence, vous développez une application. Oui, une application traditionnelle (qui peut être moderne, car bien sûr, c’est tout à fait possible), et c’est elle qui communiquera avec le serveur d’inférence.
Les utilisateurs disposent eux aussi d’une application, dans un navigateur ou sur un téléphone, qui utilise généralement une API tout ce qu’il y a de plus classique pour communiquer avec l’application que vous avez créée. Et voilà ! Vous disposez d’un flux de messages complet, du client à l’application, puis au serveur d’inférence, et inversement.
Oui, il ne s’agit en réalité que d’une nouvelle version de l’application web à trois niveaux, dans laquelle la couche de données est remplacée par la couche d’inférence. Je sais, c’est terriblement décevant, n’est-ce pas ?
La forme la plus simple d’une application d’IA est une application web à trois niveaux dans laquelle la couche de données est remplacée par un serveur d’inférence.
- Reçoit une requête JSON, effectue éventuellement une génération augmentée par récupération (RAG), puis appelle le serveur d’inférence avec du JSON. La RAG consiste généralement à créer un plongement de la requête de l’utilisateur, à rechercher du contenu similaire dans un index vectoriel ou de recherche, puis à intégrer ces extraits dans le prompt. Tout cela reste du trafic au format JSON. Aucun token de modèle n’a encore été créé.
- Le serveur d’inférence analyse le JSON et convertit le texte en tokens du modèle, vérifie le contexte et les quotas, regroupe les requêtes compatibles en lots, exécute le modèle, puis reconvertit les tokens de sortie en texte. Il renvoie une réponse JSON à l’appelant. En cas de diffusion en continu, les tokens sont décodés et envoyés au fur et à mesure de leur génération. La plupart des API incluent également un bloc d’utilisation indiquant le nombre de tokens d’entrée et de sortie.
Voilà ce qu’est l’inférence. Il s’agit simplement d’un nouveau type de charge de travail applicative qui récompense la même rigueur opérationnelle que nous avons toujours valorisée, désormais exprimée en jetons, en contexte et en flux plutôt qu’en sessions, en cookies et en requêtes.
Mais où sont donc les jetons ?
C’est généralement là que les gens s’emmêlent les pinceaux et emploient des mots d’une manière qui enfreint la Directive première de la terminologie. Les tokens sont des unités de mots traitées par un LLM. Ils sont officiellement générés par un tokenizer sur le serveur d’inférence.
Vous pouvez intégrer un tokeniseur à votre application afin de compter les tokens à l’avance pour estimer les coûts et appliquer des limites de débit locales, mais le décompte définitif des tokens s’effectue dans la pile d’inférence. Les tokens sont une représentation propre au modèle, pas du trafic réseau ; les données transmises sont du texte JSON. Vous ne verrez les identifiants des tokens que si l’API les renvoie explicitement.
Par défaut, l’infrastructure ne voit pas les tokens. Elle voit du JSON. Les tokens ne transitent pas sur le réseau. Si vous souhaitez que l’infrastructure agisse en fonction des tokens, vous devez les compter au niveau de la passerelle avec le même tokeniseur, ou utiliser les décomptes émis par le serveur de modèles. Les tokens sont la monnaie de l’IA, mais ils restent principalement au sein de la pile d’inférence, sauf si vous les rendez accessibles.
L’incidence de l’inférence sur l’infrastructure
L’inférence n’a rien de mystique. Il s’agit d’une charge de travail applicative avec de nouveaux paramètres. Le trafic est au format JSON. Les jetons sont les unités du modèle. Les plongements sont des vecteurs. Si vous confondez ces notions, vous concevrez des mécanismes de contrôle inadaptés, facturerez le mauvais élément et chercherez les erreurs dans la mauvaise couche. Par exemple, un routage fondé sur la taille du JSON plutôt que sur le nombre de jetons pourrait surcharger un modèle avec des requêtes à contexte long.
Si vous voulez que l’infrastructure agisse en fonction des jetons, apprenez-lui à le faire. Placez un tokeniseur au niveau de la passerelle ou utilisez les décomptes émis par le serveur de modèles. Sinon, vos routeurs voient du texte, pas des jetons, et prendront des décisions au niveau du texte, tandis que votre facturation s’effectuera au niveau des jetons. Notez que les tokeniseurs doivent correspondre à ceux du modèle (par exemple, le tokeniseur de GPT-4 diffère de celui de LLaMA) afin de garantir des décomptes précis. Des tokeniseurs incompatibles pourraient entraîner des erreurs dans le calcul des coûts ou des limites.
Considérez qu’un service est disponible lorsqu’il est utilisable et fonctionne correctement, et pas seulement lorsqu’il est opérationnel. Suivez le nombre de jetons par seconde, le délai avant le premier jeton et les erreurs liées au contexte (comme le dépassement des limites de la fenêtre de contexte ou les réponses incohérentes dues à un contexte saturé), de la même manière que vous suiviez auparavant le nombre de requêtes par seconde et les accès au cache. Prenez la journalisation au sérieux. Le trafic d’inférence ne constitue pas des données d’entraînement, sauf si vous en décidez autrement. Si vous conservez les prompts et les réponses, protégez-les.
Nommez les choses correctement. Mesurez au bon niveau. Placez les limites là où elles comptent, par exemple en appliquant des quotas basés sur les jetons au niveau de la passerelle afin d’éviter les dépassements de coûts. Ainsi, l’inférence se comportera comme le reste de votre infrastructure : elle sera prévisible, abordable et sans surprise, dans le meilleur sens du terme. Les jetons servent à acheter des décisions au sein du modèle, pas de la bande passante sur votre réseau. Appelez les choses par leur nom, et vous préserverez la satisfaction de vos utilisateurs tout en limitant le montant de vos factures.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
Votre prochain SRE pourrait être une machine
Le contrôle se concentre au niveau de l’intention : les prompts, les jetons et le routage. Le défi architectural consiste à définir où l’IA peut agir, quand elle doit s’en remettre à l’humain et comment revenir en arrière.
Le secret pour faire passer l’IA à l’échelle réside dans la capacité à surmonter la loi de Conway
L’IA ne passera pas à l’échelle toute seule. Sans un plan de contrôle unifié qui décloisonne les outils et les responsabilités, l’inférence devient la couche la plus fragile et la plus exigeante en matière de coordination.
L’identité est la clé d’accès à l’IA agentique
À mesure que l’IA agentique fait passer les machines du statut d’outils à celui d’acteurs, l’identité devient le principal levier de contrôle : qui peut agir, au nom de qui et dans quel périmètre — avec une application en ligne au moment de l’inférence.
L’inférence est désormais le centre de gravité opérationnel
Les opérations multimodèles et l’automatisation pilotée par API déplacent le contrôle vers les couches intervenant au moment de l’inférence — prompts, jetons et paramètres de contrôle, routage et modération — où les coûts, les risques et les performances doivent être maîtrisés.
L’IA, l’inférence et les jetons, rien que ça !
Les applications d’IA s’exécutent sur des serveurs d’inférence, dont la charge dépend des jetons, et non du trafic. Découvrez pourquoi il est essentiel de comprendre les jetons et les données JSON pour concevoir une infrastructure plus intelligente.