Les modèles de raisonnement consomment entre 10 et 20 fois plus de tokens que les modèles standard pour traiter un même problème. Quand les agents IA enchainent des tâches et utilisent des outils de façon autonome, ce chiffre grimpe encore. Pour les DSI et les directeurs techniques, le problème n’est plus de savoir si adopter l’IA générative — mais comment éviter que la facture d’inférence ne devienne incontrôlable.

Pendant des années, la stratégie par défaut consistait à consommer des tokens via des APIs cloud à la demande. Cette approche reste valable pour de nombreux cas d’usage. Mais à mesure que les volumes augmentent, les modèles de raisonnement se généralisent et les agents prennent de l’autonomie, de nombreuses organisations s’orientent vers un contrôle direct de l’infrastructure d’inférence : hébergement de modèles en interne, routage des requêtes vers les points d’accès les plus rentables, optimisation de la latence et des coûts par charge de travail.

Pourquoi les tokens coûtent soudain beaucoup plus cher

La facturation des LLM repose sur les tokens : fragments de texte traités en entrée (input) et générés en sortie (output). Les modèles de raisonnement — ceux qui développent une chaîne de pensée avant de répondre — génèrent une grande quantité de tokens intermédiaires non visibles. Ce raisonnement interne est généralement facturé au tarif des tokens de sortie, ce qui représente une hausse de coût significative par rapport à un appel classique.

Les agents amplifient ce phénomène. Un agent qui exécute une tâche multi-étapes réalise plusieurs appels au modèle, appelle des outils, passe les résultats en contexte et itère jusqu’à atteindre l’objectif. Chaque cycle consomme des tokens. Sur des flux d’automatisation complexes — analyse de contrats, génération de code, supervision de processus — le volume total peut dépasser de loin ce qu’anticipaient les budgets initiaux. La contrainte d’infrastructure IA va bien au-delà des GPU : elle touche l’inférence, le réseau et les coûts opérationnels.

Le parcours Metal to Agents de Red Hat

Red Hat définit sa réponse comme un parcours « Metal to Agents » : une stack ouverte intégrée bout en bout, où chaque couche — des accélérateurs matériels jusqu’aux agents — est connectée et conçue avec la sécurité comme priorité de conception. L’infrastructure doit être compatible avec un écosystème hétérogène de matériel : processeurs NVIDIA, AMD, Intel et silicium personnalisé des fournisseurs cloud.

Au centre de cette stack se trouve l’inférence. Red Hat travaille sur vLLM, un serveur d’inférence open source à haute performance, et sur llm-d, un projet d’inférence distribuée. Selon la société, ces travaux ont permis de réduire de 10 fois le temps pour obtenir le premier token (TTFT, time to first token) et de tripler la qualité des réponses dans des applications réelles. Ce n’est pas seulement une question de performance : une latence plus faible réduit le temps de calcul GPU et, in fine, le coût par requête.

Gouvernance des agents et MCP Services

La multiplication des agents dans l’entreprise soulève un problème de gouvernance concret. Des équipes différentes déploient des outils différents, chaque agent a ses propres permissions et accès, et la traçabilité des actions reste souvent floue. Pour Red Hat, la réponse passe par trois exigences : attribuer à chaque agent une identité vérifiée, gérer son cycle de vie avec contrôle de version, et s’appuyer sur des normes émergentes pour la connectivité entre agents, outils et données.

MCP Services (Model Context Protocol) est l’un des standards qui s’impose pour cette connectivité. Il définit comment un agent peut découvrir les outils disponibles, appeler des fonctions et recevoir des résultats structurés. En termes de sécurité, la gestion des identités d’agents IA — comme ce que propose Idira de Palo Alto Networks — devient complémentaire de ces standards de connectivité : savoir où va un agent et ce qu’il fait sont deux questions différentes.

BNP Paribas et la NASA : deux cas concrets

BNP Paribas a généré près de 600 millions de dollars de valeur en industrialisant mille cas d’usage de l’IA sur une plateforme unifiée. L’un des changements les plus significatifs : la mise à disposition de GPU, un processus qui prenait plusieurs semaines, est passée à quelques minutes. Pour une banque traitant des volumes massifs de données, cette accélération change la vitesse à laquelle les équipes peuvent tester et déployer de nouveaux modèles.

Le Marshall Space Flight Center de la NASA a migré des milliers de charges de travail héritées vers des environnements conteneurisés. Le résultat : des déploiements qui prenaient plusieurs jours se règlent maintenant en quelques minutes dans des opérations critiques. Au-delà de la performance, c’est aussi une question de maîtrise : migrer vers des conteneurs donne aux équipes un contrôle plus précis sur les versions, les dépendances et la sécurité des applications.

Ce que cela implique pour les DSI

La transition vers un contrôle direct de l’inférence n’est pas triviale. Héberger des modèles en interne exige des GPU, une équipe capable de gérer les serveurs d’inférence, un suivi des performances et un plan de mise à jour quand de nouveaux modèles sortent. Ce n’est pas toujours la bonne décision — surtout pour des cas d’usage à faible volume ou des modèles généralistes où les fournisseurs cloud gardent un avantage d’échelle.

La stratégie pragmatique combine les deux : APIs cloud pour les charges généralistes, inférence interne pour les cas d’usage à fort volume ou impliquant des données sensibles, et routage intelligent selon le coût par requête, la latence acceptable et les exigences de confidentialité. Ce choix d’architecture est désormais une décision stratégique qui appartient aux directions techniques, pas aux seules équipes IA.

Questions fréquentes

Pourquoi les modèles de raisonnement consomment-ils plus de tokens ?

Les modèles de raisonnement génèrent une chaîne de pensée intermédiaire avant de répondre. Ces tokens intermédiaires sont généralement facturés au tarif des tokens de sortie. Sur un problème complexe, la consommation totale peut être 10 à 20 fois supérieure à celle d’un modèle standard.

Qu’est-ce que vLLM et llm-d ?

vLLM est un serveur d’inférence open source haute performance pour les LLM. llm-d est un projet Red Hat d’inférence distribuée. Les deux visent à réduire la latence et le coût par requête en optimisant l’utilisation des GPU.

Que signifie MCP Services dans ce contexte ?

MCP (Model Context Protocol) est un standard émergent pour la connectivité entre agents IA, outils et sources de données. Il définit comment un agent peut découvrir les outils disponibles et appeler des fonctions de façon structurée.

Quand vaut-il mieux héberger ses propres modèles ?

L’hébergement interne est pertinent pour les cas à fort volume (l’échelle améliore la rentabilité), les données sensibles qui ne peuvent pas transiter par des APIs externes, et les modèles spécialisés pour des tâches métier précises. Pour des cas généralistes à faible fréquence, les APIs cloud restent souvent plus économiques.