Les coûts d'inférence de l'IA, pas l'entraînement, redéfinissent l'économie du service des modèles

Le coût d'un run d'entraînement d'un modèle de pointe est un chiffre que les journalistes adorent citer — des centaines de millions de dollars, des dizaines de milliers de GPU, des mois de temps réel. C'est aussi, pour la plupart des entreprises d'IA, le mauvais chiffre à surveiller. L'entraînement a lieu une fois (ou quelques fois par an, pour une mise à jour). L'inférence, elle, se produit à chaque requête de chaque utilisateur, pour toujours, et elle évolue avec le succès : plus un produit réussit, plus il coûte cher à faire fonctionner. Cela inverse un pan de l'économie qui a prévalu pendant la majeure partie de l'histoire du logiciel, où le coût marginal pour servir un utilisateur supplémentaire était proche de zéro.

C'est pourquoi l'inférence, et non l'entraînement, est le poste qui redéfinit réellement la façon dont les entreprises d'IA construisent leurs produits en 2026. Les entreprises qui l'emportent en matière d'économie unitaire ne sont pas forcément celles qui ont le meilleur modèle — ce sont celles qui ont le plus réduit le coût de réponse à une seule requête, grâce à un ensemble de techniques désormais suffisamment matures pour devenir une pratique standard plutôt qu'une curiosité de recherche.

L'arithmétique qui rend l'inférence coûteuse

Une passe avant (forward pass) d'un transformer coûte environ 2 × nombre de paramètres × tokens traités en opérations à virgule flottante. L'entraînement coûte environ trois fois cela par token, car il exécute aussi une passe arrière (backward pass) et une mise à jour du gradient — mais l'entraînement porte sur un nombre fixe et borné de tokens. L'inférence n'a pas cette limite ; elle évolue avec chaque requête de chaque utilisateur, indéfiniment. Un modèle servant un milliard de requêtes par jour consomme plus de calcul cumulé en quelques semaines que son entraînement n'en a consommé en plusieurs mois, une fois qu'un produit a un usage réel.

La longueur du contexte aggrave encore la situation. Le cache clé-valeur (KV cache) qu'un transformer conserve pendant la génération croît avec la longueur de séquence × le nombre de couches × le nombre de têtes d'attention × la dimension de chaque tête × la taille du lot. Faire passer les fenêtres de contexte de 8K à 128K ou plus — ce que les produits font désormais couramment — fait croître d'autant la mémoire requise par requête simultanée, ce qui plafonne le nombre de requêtes qu'un GPU donné peut servir à la fois. Ce plafond est ce qui fixe réellement le coût par requête, plus que les FLOPs bruts.

Les techniques qui réduisent réellement les coûts

La quantification est le levier le plus direct : exécuter l'inférence en FP8 ou INT8 plutôt qu'en FP16/BF16 réduit environ de moitié les besoins en bande passante mémoire et peut doubler, voire plus, le débit sur le même matériel, avec une perte de précision soigneusement maîtrisée. L'INT4 va plus loin pour les modèles où cette perte de précision est tolérable.

Les architectures Mixture-of-Experts (MoE) changent ce que signifie la "taille du modèle" en termes de coût. DeepSeek-V3 compte 671 milliards de paramètres au total mais n'en active qu'environ 37 milliards par token — on paie le calcul pour le sous-ensemble actif, pas pour le modèle complet. C'est la principale raison pour laquelle les modèles MoE peuvent offrir des capacités de niveau de pointe pour une fraction du coût d'inférence d'un modèle dense comptant un nombre total de paramètres équivalent.

Les variantes d'attention s'attaquent directement au problème du KV-cache. L'attention par requêtes groupées (grouped-query attention, GQA), utilisée dans Llama 3 et de nombreux modèles actuels, partage les projections clé/valeur entre des groupes de têtes d'attention plutôt que d'attribuer à chaque tête sa propre projection, réduisant la taille du KV-cache de plusieurs fois avec une perte de qualité minimale. L'attention latente multi-têtes (MLA) de DeepSeek compresse encore davantage le cache, en projetant clés et valeurs dans un espace latent plus petit avant leur mise en cache.

Le décodage spéculatif ajoute un petit modèle "brouillon" rapide qui propose plusieurs tokens à l'avance, que le modèle complet vérifie ensuite en parallèle plutôt que de générer un token à la fois. Lorsque le modèle brouillon devine correctement — ce qui arrive assez souvent sur du texte courant — cela réduit la latence et le temps GPU par token de sortie d'environ la moitié aux deux tiers, sans aucune perte de qualité de sortie (le grand modèle garde le dernier mot sur chaque token).

Du côté de l'infrastructure de service, le batching continu et la gestion paginée du KV-cache — la technique que vLLM a popularisée sous le nom de PagedAttention — permettent à un serveur de regrouper bien plus de requêtes simultanées dans la même mémoire GPU, en gérant l'allocation du cache comme un système de mémoire virtuelle plutôt qu'en réservant un bloc fixe dans le pire des cas pour chaque requête. C'est un gain purement lié à l'infrastructure : même modèle, même matériel, un débit nettement supérieur.

Le routage : ne dépenser le modèle coûteux qu'en cas de besoin

Une stratégie distincte renonce à optimiser l'inférence d'un seul modèle et optimise plutôt le choix du modèle qui répond à chaque requête. Une couche de routage envoie les requêtes simples et à forte confiance vers un modèle bon marché et rapide, et n'escalade vers un modèle de pointe coûteux que les requêtes réellement difficiles. Les produits construits ainsi rapportent un coût moyen par requête bien inférieur à ce que coûterait le passage de chaque requête par le modèle haut de gamme, car la plupart des requêtes réelles n'ont pas besoin du raisonnement d'un modèle de pointe — elles ont besoin d'une réponse correcte et rapide.

Les difficultés financières de Character.AI — qui a déposé le bilan sous le régime du Chapter 11 le 13 octobre 2026 — constituent une étude de cas utile sur ce qui se passe lorsque ce problème n'est pas résolu. Un produit de chat génère un volume d'inférence énorme par utilisateur (conversations longues, fréquentes et en aller-retour), et si le coût d'inférence par message n'est pas réduit agressivement par rapport à ce que paient les utilisateurs ou à ce que génère la publicité, l'économie unitaire ne tient simplement pas, quelle que soit la taille de la base d'utilisateurs.

Matériel d'inférence spécialisé

Les GPU à usage général restent le choix par défaut, mais le silicium d'inférence dédié — le LPU de Groq, le moteur à l'échelle de la wafer de Cerebras, l'architecture dataflow de SambaNova — échange la flexibilité d'entraînement contre une latence et un coût par token plus faibles sur des charges de travail purement d'inférence. Cela compte surtout pour les applications à fort volume et sensibles à la latence (assistants vocaux, outils de codage en temps réel), où économiser des millisecondes et des centimes par requête à grande échelle l'emporte sur la flexibilité d'un accélérateur généraliste.

Conclusions pratiques

Si vous construisez un produit au-dessus d'une API de LLM, suivez le coût pour 1 000 tokens de sortie comme métrique centrale de votre économie unitaire, pas le coût par requête — la dérive progressive de la longueur de contexte est le tueur silencieux des marges. Fixez un budget strict de longueur de contexte par fonctionnalité plutôt que de le laisser croître sans contrôle. Utilisez par défaut un modèle bon marché et rapide, et n'escaladez vers un modèle coûteux qu'en cas d'incertitude détectée ou de demande explicite de l'utilisateur pour un raisonnement plus poussé. Et si vous évaluez des fournisseurs d'API, interrogez-les directement sur leur stratégie de quantification, de MoE et de cache — un fournisseur exécutant une inférence FP8 MoE avec un batching conscient du KV-cache peut être nettement moins cher qu'un autre qui ne le fait pas, pour exactement la même qualité de modèle nominale.