Pourquoi l'IA agentique nécessite une pile d'inférence ouverte

« ÀÀ l'heure actuelle, tous les laboratoires d'IA perdent de l'argent à servir votre entreprise. Elles le savent. Et elles le font intentionnellement. »

C'était la première ligne d'un article que j'ai reçu la même semaine où trois chiffres ont permis de comprendre pourquoi l'inférence ouverte n'est plus facultative.

Au cours d'un week-end, un développeur a créé une application de notes simple à l'aide d'un agent de programmation Open Source avec une clé d'API directe. Une page, une fonctionnalité. Coût : US$50. Le lendemain, un abonnement de US$20/mois a fourni 50 fois plus de tokens.

Un ingénieur de notre équipe d'inférence a consommé 300 millions de tokens via des modèles de type Open Weight en deux jours, effectuant le même travail qui aurait coûté des milliers de dollars avec des API propriétaires.

Les deux premiers chiffres révèlent l'ampleur de la subvention. Le troisième révèle la solution. Et ce sont les agents qui nous obligent à trouver cette solution.

Le modèle de tarification est en transition

Les fournisseurs de modèles frontier ont accompli quelque chose de remarquable. Ils ont rendu l'IA de classe mondiale accessible à des millions de développeurs à des tarifs qui auraient été impensables il y a deux ans. Cette accessibilité a entraîné une adoption massive. Elle a également créé une structure économique qui n'est peut-être pas viable aux taux actuels.

Le site Web Is AI profitable yet? suit la situation financière générale du secteur de l'IA. Actuellement, les entreprises d'IA dépensent environ 195 % de leur chiffre d'affaires. Un contributeur à la discussion a calculé que, en équivalent dollar de 2024, les dépenses totales en capital pour l'IA sur 10 ans ont représenté environ trois fois le coût de l'intégralité du système d'autoroutes Interstates des États-Unis. Ces types d'investissements finiront par se refléter dans le prix des services.

Les signes de cette transition apparaissent déjà. Selon certains rapports, de grandes entreprises reconsidèrent les licences d'outils de programmation d'IA alors que la facturation basée sur les tokens remplace les abonnements à forfait, avec des coûts par ingénieur atteignant US$500 à US$2 000 par mois. Les nouveaux modèles de pointe offrent des améliorations modestes lors des tests de performance tout en consommant 10 à 25 % de tokens supplémentaires par tâche. L'approvisionnement en GPU est déjà bloqué pour les trois à quatre prochaines années, et plusieurs fournisseurs de cloud GPU n'ont déjà plus de capacités disponibles.

Rien de tout cela n'est une critique à l'égard des fournisseurs. Ils façonnent l'avenir et proposent des tarifs très compétitifs pour accélérer l'adoption. Les coûts unitaires par token continueront probablement de baisser, et Gartner prévoit une réduction de 90 % d'ici 2030. Mais comme l'indique la même analyse, les charges de travail agentiques consomment tellement plus de tokens par tâche que les dépenses totales d'inférence des entreprises devraient augmenter malgré la baisse du coût unitaire. Goldman Sachs prévoit une multiplication par 24 de la consommation de tokens d'ici 2030. Les entreprises qui planifient pour les trois à cinq prochaines années doivent se préparer à une hausse des coûts agrégés, et non à une baisse. Les modèles Open Source exécutés sur une infrastructure autogérée constituent la soupape de sécurité qui aidera à maintenir l'accessibilité de l'IA à mesure que la consommation augmentera.

Figure 1 : Le paradoxe du coût de l'inférence agentique Les coûts par token diminuent de 90 % (Gartner), mais la consommation totale est multipliée par 24 (Goldman Sachs), ce qui entraîne des dépenses globales d'entreprise plus élevées malgré des unités moins coûteuses.

Les agents ont changé la donne

La tarification par abonnement a été conçue pour des humains écrivant à une vitesse humaine. Les agents génèrent des ordres de grandeur supplémentaires d'appels d'API, et aucun modèle de tarification actuel n'a été conçu pour cela.

Un contributeur d'OpenClaw a consommé US$1,3 million de tokens d'API OpenAI en un seul mois. Cela représente 603 milliards de tokens pour 7,6 millions de requêtes provenant d'environ 100 instances Codex gérées par trois personnes. En une seule journée, ce compte a enregistré US$19 985,84 de dépenses.

Jensen Huang a déclaré que la consommation de tokens par les agents a été multipliée par environ 1 000 par rapport à l'utilisation des modèles traditionnels. Dans le podcast Latent Space, Marc Andreessen a déclaré que son entourage dépense US$1 000 par jour en tokens Claude pour exécuter des agents, avec une demande latente de US$5 000 à US$10 000 par jour et par agent personnel entièrement déployé. Même avec un prix dix fois inférieur, cela représente toujours US$100 par jour. « C'est encore bien au-delà de ce que les gens peuvent payer. »

Certains fournisseurs ont déjà dû restreindre l'utilisation de frameworks d'agents tiers dans le cadre d'abonnements à forfait, car les besoins en calcul dépassaient ce que le modèle de tarification pouvait supporter. La tarification à forfait et les charges de travail des agents autonomes sont structurellement incompatibles.

Le coût n'est qu'une partie du problème. Les charges de travail agentiques présentent des exigences techniques auxquelles les API propriétaires n'ont jamais été conçues pour répondre.

Fragmentation des API Le paysage des API agentiques comporte plusieurs normes concurrentes. Chat Completions (format sans état d'origine d'OpenAI), Responses API (nouveau format avec état d'OpenAI avec outils intégrés et intégration du Model Context Protocol), Messages API (format d'Anthropic) et Interactions API (protocole agentique de Google). Chacune gère les appels d'outils, la gestion d'état et le raisonnement différemment. Chaque harnais en choisit une différente.

Chaque famille de modèles encapsule également le même appel d'outil dans des balises complètement différentes. L'envoi de get_weather(city="Seattle") à cinq modèles produit cinq formats différents : Llama utilise la syntaxe Python avec <|python_tag|>, Mistral utilise [TOOL_CALLS] avec des tableaux JSON, Gemma utilise les balises et Hermes utilise XML. Le moteur d'inférence a besoin d'un analyseur distinct pour chaque famille de modèles.

Appels d'outils Avec une API propriétaire, vous obtenez l'analyseur fourni par le fournisseur. Vous ne pouvez pas le personnaliser. Vous ne pouvez pas corriger un modèle qui génère une syntaxe Python au lieu de son format d'entraînement. Vous n'êtes qu'un passager.

Routage des modèles L'exécution d'un seul agent génère des sous-tâches hétérogènes : certaines nécessitent un raisonnement approfondi, d'autres une classification rapide et d'autres encore la génération de code. L'acheminement de ces tâches vers différents modèles nécessite un contrôle sur la couche de service. Avec l'API d'un fournisseur unique, chaque tâche est envoyée au même modèle au même prix.

Ingénierie du contexte La gestion des éléments qui atteignent le modèle sur plusieurs cycles constitue l'optimisation offrant le plus d'effet de levier. Un pipeline de contexte bien réglé peut réduire l'utilisation des tokens de 60 à 80 % tout en améliorant la qualité des résultats. Cependant, une ingénierie du contexte efficace nécessite d'accéder au comportement du modèle au niveau de l'inférence, car vous devez mesurer les points auxquels le modèle prête réellement attention, identifier les tokens de contexte qui contribuent à la qualité des résultats et ajuster les stratégies de résumé et de recherche en fonction des schémas d'attention réels plutôt que de simples suppositions.

Coupe-circuits Sans contrôle sur la couche d'inférence, vous ne pouvez pas mettre en œuvre de budgets par agent, de détection d'anomalies ou d'arrêt automatique au niveau du serveur de modèles. Ayant déjà été victime d'une boucle incontrôlée, je peux vous dire que le fournisseur ne vous sauvera pas.

Les économistes appellent ce phénomène le paradoxe de Jevons. William Stanley Jevons a remarqué ce schéma en 1865. À mesure que les moteurs à charbon devenaient plus efficaces, la consommation totale de charbon augmentait. Les tokens d'IA suivent la même trajectoire. Chaque gain d'efficacité ouvre de nouveaux cas d'utilisation qui consomment davantage que l'économie réalisée. Les entreprises qui parviennent à optimiser le résultat par token utiliseront plus d'IA, et non moins.

Les modèles ouverts sont prêts pour le travail agentique

Comme mentionné plus haut, notre équipe d'inférence a traité 300 millions de tokens à l'aide de modèles à pondération ouverte en deux jours. Nemotron 3 Super, Gemma 4 et Qwen 3.6, tous exécutés sur la pile d'inférence Red Hat AI. Le résultat était suffisamment probant pour les révisions de pull requests, les premières implémentations et les recherches ciblées, déchargeant ainsi le travail qui serait autrement confié à des modèles de pointe et accumulerait des coûts de tokens.

L'écart de coût n'est pas marginal. Les tests de performance sur les GPU Blackwell grand public montrent qu'un GPU de US$500 exécutant des modèles à pondération ouverte peut traiter 30 millions de tokens par jour. À ce volume, le coût du matériel est amorti en trois mois par rapport à ce que coûterait la même charge de travail via des fournisseurs d'API d'entrée de gamme à environ US$0,20 par million de tokens. Par rapport aux tarifs des API de pointe, la période de retour sur investissement tombe à quelques jours.

Un chercheur a créé un agent de programmation qui a obtenu un score de 87 % lors des tests de performance à l'aide d'un modèle qui n'active que 4 milliards de paramètres par token. Les agents utilisant des modèles à 14 milliards de paramètres ont obtenu un score de 75 %. La différence ne résidait pas dans le modèle, mais dans les outils composés et une boucle de rétroaction des erreurs. C'est le harnais qui a fait le plus gros du travail, et non la taille du modèle.

Pour que les modèles ouverts fonctionnent bien dans des scénarios agentiques, une réelle ingénierie est nécessaire, et c'est précisément ce que permet l'Open Source. Une démonstration récente de Gemma 4 exécutée avec OpenCode et Claude Code montre à quoi cela ressemble en pratique, avec des ajustements personnalisés des modèles de discussion, le réglage de l'analyseur d'appels d'outils pour chaque famille de modèles et le formatage des invites sur plusieurs normes d'API. Le modèle à 4 milliards de paramètres nécessitait un traitement différent de la version quantifiée à 26 milliards de paramètres, qui elle-même nécessitait un traitement différent du modèle à 31 milliards de paramètres.

C'est ce type de travail qui comble l'écart entre les performances des tests de performance et les performances agentiques réelles. Il s'agit de traduire entre les API de Chat Completion, de Messages et de Responses, et d'analyser les sorties du modèle avec une logique floue, car les modèles omettent parfois leurs tokens de début d'appel d'outil ou génèrent une syntaxe inattendue influencée par les invites système du harnais.

Ce travail se fait en amont dans vLLM, dans les modèles de discussion des fournisseurs de modèles et dans les rapports de bogues des harnais. Et cela ne peut se faire que de manière ouverte. Avec un serveur d'inférence propriétaire, vous ne pouvez pas soumettre de correction de modèle de discussion, régler un analyseur d'appel d'outil, ni même observer pourquoi les résultats de votre agent échouent. Avec l'Open Source, chaque correction profite à tous les utilisateurs et chaque mise à niveau de l'analyseur est permanente. Ce travail d'intégration en amont, qui consiste à rendre les modèles à pondération ouverte fiables pour les charges de travail agentiques sur l'ensemble de la pile de service, est au cœur des priorités de Red Hat AI.

La pile d'inférence agentique

Huit couches doivent fonctionner ensemble pour permettre l'inférence agentique à l'échelle de l'entreprise. Chaque couche interagit avec toutes les autres.

Figure 2  : La pile d'inférence agentique, de l'agent et du harnais au sommet, à la traduction d'API, la passerelle, les garde-fous, le service désagrégé, la configuration du serveur de modèles, le moteur d'inférence et enfin le matériel à la base. Les bordures rouges mettent en évidence les deux couches où s'effectue l'essentiel du travail de compatibilité agentique. La limite en pointillés du sandbox englobe la couche de l'agent, là où l'exécution du code et les contrôles de sécurité sont les plus stricts.

L'assemblage de ces couches à partir de projets Open Source individuels est possible, mais coûteux sur le plan opérationnel. L'intérêt d'une plateforme d'inférence autogérée telle que Red Hat AI est qu'elle est intégrée dans une pile testée et prise en charge qui s'exécute sur votre infrastructure. Ainsi, vos données ne quittent jamais votre périmètre de sécurité et vous contrôlez le cycle de mise à niveau, la sélection des modèles et la politique de routage.

La couche d'API agentique

Le problème de la diversité des API est réel. Les harnais utilisent les API Chat Completions, Responses, Messages ou Interactions, et le serveur de modèles sous-jacent ne les prend pas nécessairement toutes en charge. La couche d'API agentique se situe entre le harnais et l'infrastructure pour aider à combler cet écart. Des projets comme OGX (anciennement Llama Stack) fournissent des implémentations ouvertes des API agentiques elles-mêmes : Chat Completions, Responses API, Messages API et Interactions API, ainsi que des capacités supplémentaires telles que les magasins de vecteurs, la gestion de fichiers et l'exécution d'outils, le tout reposant sur la couche de service de modèles que vous utilisez.

À ce stade, aucune norme d'API unique n'est destinée à l'emporter, malgré l'avantage du premier arrivant pour certaines API. L'important est de disposer d'implémentations Open Source pour chacune d'elles, afin de pouvoir faire correspondre n'importe quel harnais à n'importe quel modèle, dès que vous en avez besoin. Lorsque la couche de traduction est ouverte, elle préserve l'intégralité du contrat d'appel d'outil, et vous pouvez voir exactement ce qui arrive à votre requête. Lorsqu'un fournisseur propriétaire gère la traduction, vous ne saurez jamais ce qui est perdu.

llm-d : Mise à l'échelle de l'inférence agentique

Une instance unique de vLLM fonctionne pour un ingénieur exécutant des agents, mais pas pour une centaine d'ingénieurs sollicitant simultanément les mêmes modèles. llm-d est la couche de service désagrégée qui divise l'inférence en phases distinctes de pré-remplissage (prefill) et de décodage (decode), leur permettant d'évoluer indépendamment sur différents matériels. Pour les charges de travail agentiques, où de nombreuses requêtes courtes s'entremêlent avec de longues chaînes de raisonnement, cette architecture est de plus en plus indispensable.

Garde-fous et sandboxing

La sécurité du contenu fait également partie de cette pile et doit être adaptée aux agents. Les frameworks de garde-fous fonctionnant comme des proxys doivent préserver l'intégralité du contrat de l'API agentique, y compris les définitions d'outils, le choix des outils et les paramètres de raisonnement, sous peine de dégrader silencieusement le comportement des agents.

Des garde-fous agentiques efficaces nécessitent également d'accéder à des données au niveau de l'inférence que le simple filtrage de texte ne peut fournir, telles que les traces de raisonnement pour évaluer si la chaîne de pensée (chain-of-thought) contient des étapes non sécurisées, les paramètres d'appel d'outils pour valider la conformité des arguments, les probabilités logarithmiques au niveau des tokens (logprobs) pour détecter les risques d'hallucination, et les métadonnées de génération pour les journaux d'audit. C'est une autre raison pour laquelle la couche d'inférence doit être ouverte. Les garde-fous qui ne voient que le texte entrant et sortant sont insuffisants pour les charges de travail agentiques. 

Si votre proxy de garde-fous est une boîte noire qui supprime les paramètres d'appel d'outils, vous ne pourrez pas diagnostiquer la cause de l'échec de vos agents. Les garde-fous Open Source (tels que le point de terminaison NVIDIA NeMo Guardrails /v1/guardrails/checks sans proxy) appliquent la sécurité du contenu sans rompre le contrat de l'API agentique.

Le sandboxing est un autre facteur. Les agents exécutent du code, écrivent des fichiers et appellent des outils. La défense en profondeur nécessite une isolation par couches, incluant le confinement au niveau des conteneurs, les politiques réseau, les restrictions du système de fichiers et l'application au moment de l'exécution. Placer un agent dans un conteneur ne suffit pas. La limite du bac à sable dans le diagramme de la pile englobe l'agent et le harnais, car c'est là que l'exécution de code arbitraire peut se produire et que les contrôles de sécurité doivent être les plus stricts.

Pourquoi l'Open Source l'emporte

Vous ne pouvez pas tester une pile de huit couches sans voir ce que fait la moitié d'entre elles. Vous ne pouvez pas déboguer des appels d'outils défaillants si vous ne voyez pas l'analyseur. Vous ne pouvez pas garantir la sécurité si le proxy de garde-fous supprime silencieusement les paramètres dont les agents ont besoin. La pile est trop couplée pour qu'une seule couche soit opaque. Intégrer et sécuriser ces couches ensemble pour éviter aux entreprises de devoir assembler la pile elles-mêmes est le problème que Red Hat AI a été conçu pour résoudre.

Au-delà de l'argument technique, l'inférence ouverte est inévitable pour des raisons structurelles qui dépassent le simple coût.

Figure 3 : Inférence ouverte vs API propriétaires pour les charges de travail agentiques Les API propriétaires l'emportent sur la facilité de configuration et la qualité des modèles de pointe. L'inférence ouverte l'emporte sur les sept capacités dont dépendent les charges de travail agentiques en production : routage des modèles, débogage des appels d'outils, personnalisation du domaine, budgets par agent, résidence des données, indépendance vis-à-vis des fournisseurs et garde-fous au niveau de l'inférence.

Le partage des connaissances accélère les progrès dans tout le domaine. L'Open Source apporte deux choses : des logiciels libres et des connaissances libres. DeepSeek R1 l'a clairement démontré. Les capacités de raisonnement ont existé dans les modèles propriétaires pendant des mois avant que la communauté plus large ne puisse les reproduire. Une fois que DeepSeek a publié le code et l'article, tous les grands laboratoires disposaient de capacités de raisonnement en l'espace de trois mois. L'effet de diffusion des connaissances a plus de valeur que le modèle lui-même. Appliqué à l'inférence agentique, chaque correction d'analyseur d'appel d'outil, chaque amélioration de modèle de discussion et chaque correctif de harnais devient une infrastructure partagée qui profite à tout l'écosystème.

La confiance exige de la transparence. Toutes les organisations ne sont pas prêtes à acheminer l'intégralité de leurs données et de leurs workflows via une poignée de fournisseurs de modèles cloud. Pour certaines, c'est une question de conformité stricte. Les secteurs de la santé et de la finance font face à des exigences réglementaires rigides concernant la confidentialité et la résidence des données. Pour d'autres, c'est un choix stratégique pour éviter la dépendance vis-à-vis d'un fournisseur (vendor lock-in) et conserver la pleine propriété de leur propriété intellectuelle.

L'Open Source donne aux organisations la possibilité d'exécuter des modèles selon leurs propres conditions, dans leur périmètre de sécurité, avec une visibilité totale sur le fonctionnement du système. Pour les secteurs réglementés, les gouvernements et les charges de travail sensibles, c'est une exigence. La réglementation évolue dans le même sens : les obligations de transparence du Règlement sur l'IA de l'UE (EU AI Act), applicables à partir d'août 2026, exigent une documentation technique couvrant l'architecture des modèles, les procédures d'entraînement et les caractéristiques de performance. Les modèles Open Source qui publient déjà ces informations peuvent bénéficier d'exemptions dont les modèles fermés ne disposent pas.

La personnalisation nécessite des pondérations possédées en propre. Avec une API fermée, chaque organisation utilise le même modèle. Lorsque vous possédez les pondérations sur votre propre infrastructure, vous pouvez effectuer un affinement (fine-tuning) pour votre domaine, vos outils internes et vos conventions de code sans envoyer de données propriétaires à l'extérieur. Les organisations de santé s'adaptent à la terminologie clinique et aux formats de dossiers médicaux. Les équipes juridiques adaptent les modèles aux langages et structures de contrats propres à chaque juridiction. Les institutions financières s'appuient sur leurs propres modèles de risque et cadres de conformité. Pour les charges de travail agentiques, c'est ce qui fait la différence entre un agent polyvalent et un agent qui comprend déjà le fonctionnement de vos systèmes.

L'Open Source crée une force d'attraction pour l'écosystème. Lorsque les fournisseurs de matériel investissent dans des logiciels d'inférence Open Source, des modèles plus accessibles favorisent une adoption plus large du matériel. Les investissements dans les optimisations de vLLM (l'environnement d'exécution d'inférence) et les améliorations de la pile de service Open Source renforcent les capacités de chaque GPU pour les charges de travail agentiques et permettent la réutilisation du matériel. Il en résulte un cycle vertueux où les améliorations logicielles Open Source s'accumulent dans tout l'écosystème.

La phase suivante favorise les modèles distribués. Le schéma émergent est celui d'un système « centré sur le contexte partagé », avec de nombreux modèles travaillant sur des graphes de connaissances et des magasins de contexte communs. Cela déplace l'attention d'un modèle unique massif vers un écosystème de modèles spécialisés coordonnés par un harnais intelligent. Vous n'avez pas nécessairement besoin d'un modèle capable de tout faire. Le plus souvent, vous aurez besoin de nombreux modèles spécialisés, chacun excellant dans son domaine, collaborant au sein d'un système composé. Cette architecture est intrinsèquement plus ouverte et distribuée.

Les architectures d'agents émergentes telles que Pi et OpenClaw, entre autres, sont déjà conçues de cette manière. Leur conception est minimale, incluant souvent un grand modèle de langage (LLM), un shell bash, un système de fichiers, des fichiers d'état markdown et une boucle cron. L'état réside dans les fichiers, pas dans les pondérations, vous pouvez donc changer de LLM sans perdre la mémoire de l'agent. Ces agents fonctionnent avec n'importe quel modèle, fermé ou ouvert. Mais lorsque toute la pile est ouverte, des pondérations des modèles à l'infrastructure de service, chaque avantage structurel s'additionne : vous affinez pour votre domaine, vous effectuez le routage vers des modèles que vous contrôlez, vous observez avec des outils qui vous appartiennent et vous changez n'importe quelle couche sans perturber le reste. C'est ce qui fait de l'inférence ouverte une fondation naturelle pour l'IA agentique et de Red Hat AI la plateforme pour l'alimenter. 

Comment se préparer

Trois choses à faire dès maintenant, avant l'arrivée des nouveaux tarifs.

Figure 4 : Trois actions pour se préparer à l'inférence agentique ouverte, chacune avec des outils spécifiques de la pile Red Hat AI. La chronologie montre une progression de 12 mois, de la portabilité de l'API vers une infrastructure agentique entièrement autogérée.

Concevez des solutions indépendantes du harnais. La manière dont vous concevez votre harnais et vos agents agentiques compte autant, sinon plus, que le modèle utilisé. Si vos agents sont codés en dur pour l'API d'un seul fournisseur, vous vous retrouvez prisonnier avant même l'arrivée des changements de tarification. Vous devriez concevoir pour la portabilité des modèles et des API. C'est ici que des projets comme OGX, disponibles via Red Hat AI, interviennent en fournissant la couche de traduction ouverte entre les API Chat Completions, Responses, Messages et Interactions, afin que vos agents restent portables quel que soit le modèle ou le fournisseur sous-jacent.

Auto-hébergez le volume sur une infrastructure gérée. Un seul GPU exécutant un modèle Gemma 4 ou Qwen quantifié peut déjà gérer les révisions de pull requests, la documentation et la synthèse de code. Utilisez les abonnements API pour les charges de travail qui nécessitent réellement un raisonnement de pointe, ou là où les modèles de pointe conservent un net avantage de qualité, et auto-hébergez le reste sur une infrastructure que vous contrôlez. Une plateforme d'inférence autogérée gère la complexité opérationnelle du service de modèles, de la mise à l'échelle, du routage et de l'observabilité pour que votre équipe puisse se concentrer sur la création d'agents plutôt que sur la maintenance de la pile. 

À mesure que les modèles Open Source continuent de combler l'écart avec les capacités de pointe, les charges de travail que vous pourrez auto-héberger ne feront que croître. Le fait de commencer dès maintenant permet de renforcer la préparation opérationnelle dont vous aurez besoin lorsque les modèles ouverts couvriront toute la pile. Les recherches sur le routage des modèles montrent que le fait de diriger la majorité des requêtes vers des modèles plus petits ou auto-hébergés, et de ne transmettre que les tâches complexes aux API de pointe, peut réduire les coûts de 60 à 85 % avec une perte de qualité minimale.

Testez de bout en bout sur l'ensemble de la pile agentique. Un modèle qui réussit les tests de performance peut encore échouer si le harnais lui envoie des invites incorrectes, si l'analyseur d'outils lit mal les résultats ou si la passerelle achemine mal les tâches. La bonne approche consiste à tester des triplets modèle-harnais-configuration.

Intégrez également la budgétisation des tokens dans votre processus. Limites par agent. Attribution par fonctionnalité. Détection d'anomalies. MLflow Tracing, qui fait déjà partie de la pile Red Hat AI, capture les requêtes, les étapes de raisonnement, les appels d'outils et les coûts des tokens avec une compatibilité totale OpenTelemetry. Il est préférable de mettre en place les alertes budgétaires avant d'en avoir besoin.

Concevoir pour la suite

Le matériel se déprécie normalement. Les GPU pour l'inférence ouverte font le contraire. Les puces ne changent pas, mais le logiciel qui les exécute continue de s'améliorer. De meilleurs noyaux de traitement par lots et d'attention dans vLLM permettent de traiter plus de tokens par seconde avec le même silicium. Les percées en matière de quantification permettent de faire tenir dans 20 Go des modèles qui en nécessitaient autrefois 80, avec une qualité comparable. Le service désagrégé divise les charges de travail afin qu'un même cluster puisse gérer davantage d'agents simultanés. Un GPU d'entreprise acheté il y a trois ans produit aujourd'hui des inférences plus utiles qu'au moment de son installation, car la pile Open Source s'est améliorée autour de lui.

Cette capitalisation est le fil conducteur de tout cet argumentaire. Les analyseurs d'appels d'outils ouverts s'améliorent pour tout le monde. Les modèles de discussion ouverts règlent la compatibilité une fois pour toutes. Les garde-fous ouverts qui préservent le contrat de l'API agentique protègent chaque déploiement, et pas seulement les clients d'un seul fournisseur. Le service désagrégé ouvert évolue sur le matériel que vous possédez déjà.

C'est à cela que sert une plateforme d'IA Open Source. Il ne s'agit pas seulement de mettre à disposition des modèles, mais de posséder toute la pile d'inférence agentique sur sa propre infrastructure, depuis la couche d'API traduisant entre le harnais et le modèle, jusqu'au moteur de service et au matériel sous-jacent, ce que nous appelons « du matériel aux agents » (metal to agents). Vos données restent dans votre périmètre de sécurité. Vos modèles s'exécutent là où vous le décidez. Vos coûts sont prévisibles car vous contrôlez chaque couche. Chaque couche est ouverte. Chaque couche est débogable. Chaque amélioration est partagée.

Les modèles sont suffisamment performants (et s'améliorent de jour en jour). La pile prend forme. Les aspects économiques sont clairs. La question n'est pas de savoir si l'inférence agentique ouverte aura lieu (c'est déjà le cas), mais si vous serez prêt quand la facture arrivera.