Poids ouverts, vraie facture

Un token est un morceau de mot, l'unité avec laquelle le travail d'un modèle linguistique est mesuré et facturé. Dans les mesures de septembre de l'AI Gateway de Vercel, plus de sept tokens sur dix ont été traités par des modèles à poids ouverts, c'est-à-dire téléchargeables, inspectables et hébergeables par quiconque en a les moyens. La dépense raconte une autre histoire : ces modèles captent 23 % des dollars, un peu moins d'un sur quatre. C'était un sur vingt en juin, donc la croissance est incontestable, mais les revenus restent en retrait par rapport au volume.

Il ne s'agit pas d'une victoire idéologique, et c'est le point qui m'intéresse. C'est un choix de prix, fait par ceux qui paient les tokens avec la froideur du marchand Lawrence dans Spice and Wolf, la série de romans d'Isuna Hasekura, lorsqu'il pèse les marges et les risques avant d'accepter un accord qui semble trop généreux. S'ils coûtent si peu, on peut se demander pourquoi beaucoup ne les exécutent pas sur leur propre infrastructure. La passerelle ne voit pas ce qui se passe sur les ordinateurs personnels, donc savoir combien le font reste une question ouverte. Ce que nous pouvons essayer de faire, c'est de comprendre ce qui se passe quand on franchit cette étape.

L'itinéraire est le suivant : les chiffres de la passerelle, trois modèles qui interprètent l'ouverture de façons différentes, le test sur une carte de 16 Go, et enfin la vraie facture, avec ses points faibles détaillés un par un.

Ce que mesure réellement Vercel

Le matériel provient du trafic en production, pas d'un sondage. Chaque mois, indique Vercel, des dizaines de trillions de tokens passent par ses systèmes entre applications réelles et environnements de laboratoire. Le calcul inclut les tokens d'entrée, de sortie, de raisonnement, lus depuis la mémoire tampon (cache) et écrits dans celle-ci. La dépense est calculée aux tarifs officiels, sous réserve que les factures réelles peuvent différer en raison d'accords spécifiques. La classification des modèles ouverts suit la liste actuelle de la passerelle, une définition plus large que dans les rapports précédents, comme l'explique la note méthodologique.

Il existe trois limites qu'il convient de déclarer immédiatement. Les clients de Vercel représentent un segment spécifique du marché, et la mesure dans laquelle ils reflètent l'ensemble reste à vérifier. Les tarifs officiels ne tiennent pas compte des remises sur volume et des contrats d'entreprise. Des charges de travail très hétérogènes se retrouvent dans le même agrégat. Malgré tout, cela constitue l'un des rares jeux de données publics qui place tokens et dollars sous le même périmètre, ce qui lui donne une grande valeur.

Le prix caché derrière les chiffres

En divisant la part de dépense par la part de tokens, on obtient un prix moyen implicite. Pour les modèles ouverts, 0,23 divisé par 0,715 donne environ 0,32. Pour les propriétaires, 0,77 divisé par 0,285 donne environ 2,70. Le premier représente 12 % du second. C'est un calcul propre, pas celui de Vercel, qui mélange des modèles et des tâches variés, il doit donc être pris comme un ordre de grandeur et non comme un taux de change exact. Cependant, cela explique le paradoxe : un token ouvert coûte, en moyenne, environ un huitième.

La croissance est asymptotique. Depuis décembre dernier, la dépense pour les modèles fermés de frontière a été multipliée par dix, tandis que pour les modèles ouverts elle a augmenté de plus de soixante-dix fois. Les modèles propriétaires rapportent plus, mais sur une fraction de plus en plus petite du volume total de chaque client.

La donnée qui complique le récit simpliste selon lequel « ouvert égale économique » est Kimi K3. Selon Vercel, les modèles avec des prix au moins quatre fois supérieurs à la moyenne des modèles ouverts ont généré près des deux tiers de l'augmentation des dépenses, et K3 à lui seul presque la moitié, en traitant nettement moins de tokens que DeepSeek. Moonshot, le laboratoire créateur, représente 3,6 % des tokens et 13,2 % des dépenses. En divisant, son token coûte environ 3,7 fois la moyenne de la passerelle, tandis que DeepSeek, avec 58 % des tokens et 6,6 % des dépenses, coûte environ un neuvième (calculs personnels). K3 propose ses poids publiquement sur Hugging Face, avec 2,8 trillions de paramètres totaux dont 104 milliards sont actifs par token. Selon les tarifs publiés, l'API coûte 3 dollars par million de tokens d'entrée et 15 de sortie. Dans un mélange de neuf parts d'entrée pour une de sortie, cela équivaut à 4,20 dollars, contre 2,80 dollars pour Claude Sonnet 5.5. Un modèle ouvert plus cher qu'un fermé : le facteur déterminant n'est peut-être pas l'ouverture des poids, mais la capacité pure.

Il existe également une composante géographique. Près de 70 % de la dépense pour les modèles chinois passe par des fournisseurs basés aux États-Unis, et neuf tokens sur dix de Moonshot sont servis par une infrastructure américaine. Celui qui entraîne le modèle et celui qui perçoit les revenus peuvent être des entités distinctes ; on peut alors se demander qui profite réellement de l'ouverture : celui qui la publie ou celui qui l'héberge ?

Enfin, Jev, de TypeSafe AI. Il a atteint 35,3 % des équipes payantes en deux semaines — un record pour la passerelle —, mais n'a représenté que 0,27 % des dépenses sur cette période, et en septembre 1 % des tokens et 0,15 % des dépenses. Il s'agit d'un modèle de décision, explique Vercel, qui consomme une petite fraction des tokens requis par une requête linguistique conventionnelle. L'adoption ne garantit pas le volume financier.

Trois stratégies et une exception

DeepSeek V4.1 Flash dispose de poids sous licence MIT et d'une architecture d'experts : la fiche du modèle décrit un réseau de base de 552 milliards de paramètres, avec 8 milliards actifs en lecture et 16 milliards en écriture, ainsi qu'une fenêtre de contexte d'un million de tokens. Le dépôt indique environ 763 milliards de paramètres totaux, de sorte qu'aucune carte grand public de 16 Go ne pourra l'exécuter localement. Le tarif officiel est celui mentionné précédemment : 0,15 et 0,60 dollar hors heures de pointe et 0,003 pour les entrées en cache. Vercel mesure la version de septembre, tandis que l'API sert actuellement la révision 1017. Dans ce cas, le prix fait plus de grands titres que les scores aux tests.

Mercury 3, d'Inception, génère le texte en parallèle au lieu de le faire token par token, annonçant des vitesses supérieures à mille tokens par seconde. Selon le communiqué du 19 octobre, la grille officielle est de 0,20 et 0,70 dollar, réduite de moitié pendant le lancement. La page ne précise pas la licence, et les comparaisons avec Luna et Haiku proviennent du fabricant lui-même. Cela montre qu'une plus grande vitesse n'implique pas nécessairement un coût moindre.

MiniMax M3.1 Flash, lancé le même jour, coûte 0,15 en entrée et 0,60 en sortie, avec 0,015 pour le cache. L'entreprise affirme que les poids seront disponibles plus tard, sans fixer de date ni de licence. C'est une promesse d'ouverture avec un calendrier indéfini : on peut se demander si l'étiquette « ouvert » est aussi utilisée comme argument commercial.

L'exception est constituée par les modèles orientés décision comme Jev. Cloudflare vient de présenter une alternative similaire, Clairic, un modèle d'extraction qui répond en une seule étape, sans générer de tokens et en ne facturant que l'entrée. Cloudflare soutient qu'une chaîne basée sur Clairic coûte 49 % de moins et fonctionne plus de trois fois plus vite qu'une chaîne basée sur des modèles linguistiques traditionnels (test interne de l'entreprise). La publication des poids est promise « bientôt ». Si la charge de travail se déplace vers des modèles qui émettent peu de tokens, dans quelle mesure sera-t-il encore utile de mesurer le marché en tokens ?

Peut-être que les poids ouverts ont gagné du terrain surtout là où la tâche est structurée, répétable et vérifiable : extraire, classer, router. Une approche qui nécessite une vérification plus approfondie.

Le banc d'essai

La machine utilisée comprend un processeur Ryzen 7 7700, 32 Go de mémoire DDR5 et une carte graphique Radeon RX 9060 XT de 16 Go. Le modèle évalué est LFM2.5-24B-A2B de Liquid, dans la quantification UD-Q4KXL de 15,4 Go, exécuté via LM Studio. Il dispose de 24 milliards de paramètres totaux et d'environ 2,45 milliards actifs par token, générant toujours un raisonnement préalable à la réponse. Sur dix tests, huit se sont révélés valides avec une note moyenne de 4,3 sur 5. Les deux autres nécessitaient une entrée multimodale (non prise en charge par ce modèle exclusivement textuel) et ont été exclus comme non applicables. Le score indique une capacité pratique, mais n'intervient pas dans le calcul économique.

J'ai mesuré directement une seule vitesse : 44,7 tokens par seconde en génération de sortie. Trois variables supplémentaires sont des estimations, déclarées expressément comme telles.

La vitesse de traitement du texte d'entrée (prefill) est nettement plus rapide que celle de génération, et elle pèse de manière déterminante sur la facture car neuf tokens sur dix en environnement réel correspondent à l'entrée. Je ne l'ai pas mesurée directement. À la place, j'ai analysé trois références indépendantes pour dériver un ratio entre lecture et écriture. Sur une RTX 4060 Ti de 16 Go avec le même modèle, llamabench indique 4 073 tokens par seconde en lecture contre 131 en écriture (16 octobre), soit une proportion d'environ 31:1. Pour ma carte spécifique, un guide cite des benchmarks de la communauté llama.cpp avec 1 420 et 68 t/s sur un modèle de 7B (proportion ~21:1). Un modèle Qwen3.8 de 27B sur une RX 9070 XT avec LM Studio atteint ~638 contre 33 t/s (proportion ~19:1). Appliquées à mes 44,7 t/s de génération, ces données suggèrent une vitesse estimée de prefill de 860 à 1 390 tokens/sec. J'adopte 1 100 t/s comme estimation centrale de référence (plage 900–1 400).

La consommation électrique constitue la deuxième estimation. AMD indique une consommation typique de 160 watts pour la seule carte. En l'absence de wattmètre à la prise, je pose deux scénarios : 160 watts (carte seule) et 250 watts (estimation pour l'ensemble de la machine). Le coût électrique est calculé à 0,3163 euro par kWh, correspondant au tarif de référence de l'ARERA pour les clients protégés en Italie, taxes incluses.

La proportion entre tokens d'entrée et de sortie est la troisième estimation. Elle ne provient pas de ce test ponctuel, mais d'analyses du trafic en production. Une étude sur 6,1 milliards de requêtes observe un ratio de 14,2 pour 1, l'analyse de Requesty indique 19 pour 1, et une étude de données d'OpenRouter enregistre 93,4 % d'entrées dans les tâches de programmation. Pour refléter l'usage en développement et avec des agents, j'adopte una répartition conservatrice de 90 % en entrée et 10 % en sortie (ratio 9:1), en tenant compte du fait que les modèles de raisonnement génèrent un volume de sortie plus élevé.

La comptabilité, ligne par ligne

Considérons un bloc de travail d'un million de tokens : 900 000 tokens d'entrée et 100 000 de sortie. L'environnement local nécessite ~818 secondes pour la phase de lecture (prefill) et 2 237 secondes pour la génération de sortie, soit au total 51 minutes de travail actif. La consommation énergétique totale varie entre 0,136 et 0,212 kWh, ce qui représente entre 4,3 et 6,7 centimes d'euro. Compte tenu des variations de prefill, de consommation et de tarif électrique, la fourchette complète de coût se situe entre 4 et 8 centimes par million de tokens. Les prix sur le cloud reflètent les tarifs officiels standard pour les contextes courts, convertis au taux de 0,8917 euro par dollar (taux de référence de la BCE au 20 octobre).

Les tarifs d'API proviennent des grilles officielles d'Anthropic, d'OpenAI, de DeepInfra et de Liquid. Les requêtes dépassant 100 000 tokens sur Claude Haiku appliquent des tranches supérieures, la durée de contexte court est donc retenue.

La comparaison la plus rigoureuse oppose l'exécution locale aux modèles cloud de taille équivalente : l'environnement local s'avère 2 à 3 fois plus économique que l'hébergement géré pour un nombre de paramètres similaire, une marge qui se réduit avec une consommation électrique plus élevée de la machine. Les comparaisons face aux modèles de frontière (qui montrent des écarts de 10x à 100x) ne tiennent que sur le papier. Comparer un modèle à 2,45B de paramètres actifs à des systèmes de premier plan oppose des catégories fonctionnelles très différentes, et nos tests de qualité ne les placent pas au même niveau.

Euros par million de tokens, répartition 90:10 entrée/sortie, 0,3163 €/kWh. À 0,3557 €/kWh, les coûts locaux augmentent de 12 %. Avec une répartition 95:5 et une lecture à 1 100 t/s, ils descendent à ~0,028 € et 0,044 €.

Les calculs s'inversent si tous les tokens étaient traités à la vitesse d'écriture sans accélération de prefill : l'exécution nécessiterait 6,2 heures, avec un coût de 31 à 49 centimes, dépassant DeepSeek dans le cloud. Cela constitue le constat le plus révélateur du test : l'accélération du traitement d'entrée (prefill) modifie profondément l'équation des coûts.

Enfin, le cache de contexte modifie l'équilibre. Les chiffres précédents dans le cloud supposent zéro succès en cache, alors que dans des flux de travail répétitifs une grande partie de l'entrée peut être lue avec des remises importantes : 0,003 dollar pour DeepSeek, 0,10 pour Sonnet 5.5. En supposant un taux de succès en cache de 80 % (sans inclure les coûts d'écriture en cache), le coût effectif descend à ~0,08 euro pour DeepSeek, 1,30 euro pour Sonnet et 6,20 euros pour Fable. Dans ces conditions, l'hébergement local à 250W et DeepSeek dans le cloud atteignent une parité économique presque absolue. La fréquence réelle d'utilisation du cache dans les environnements de production demeure une question ouverte.

Coûts cachés au-delà du token

La comptabilité précédente ne reflète que la consommation électrique. L'investissement en matériel (carte graphique et machine) s'élève à ~1 300 euros : amortis sur trois ans, la dépréciation équivaut à ~36 euros par mois. En fonctionnant en continu à 100 % de sa capacité, la machine peut traiter ~860 millions de tokens par mois, ce qui ajoute 0,04 euro de dépréciation par million de tokens. Avec un niveau d'utilisation de 10 %, l'amortissement ajoute 0,42 euro par million de tokens. Avec une utilisation de 1 %, il dépasse 4,00 euros par million. Le coût réel de l'hébergement local dépend de manière critique du taux d'utilisation.

S'y ajoute le temps, non pas de travail direct de l'opérateur, mais de disponibilité de la machine : 51 minutes par million de tokens implique de maintenir la machine occupée, la latence par requête individuelle nécessite des dizaines de secondes et la supervision humaine reste nécessaire. S'y ajoutent les coûts de maintenance : mettre à jour les pilotes et logiciels, chercher de nouvelles quantifications et gérer l'obsolescence du modèle.

Les licences ouvertes comportent également des conditions. Liquid n'accorde l'usage commercial gratuit qu'aux entités dont le chiffre d'affaires annuel est inférieur à 10 millions de dollars. La licence de Kimi K3 exige des accords commerciaux spécifiques pour les fournisseurs d'hébergement dépassant 20 millions, selon des analyses publiées, avec les termes complets sur son dépôt. DeepSeek opère sous licence MIT. L'étiquette « ouvert » recouvre de multiples réalités ; il convient d'examiner la licence avant le tarif.

Cent milliards de paramètres dans le téléphone

Cristiano Amon, PDG de Qualcomm, a déclaré dans une interview rapportée par The Next Web que plusieurs entreprises de pointe en IA prévoient d'exécuter des modèles d'au moins 100B de paramètres localement sur smartphone d'ici 2028. Il n'a pas précisé de noms, et la mesure dans laquelle l'industrie progressera dans cette direction reste à vérifier. Un calcul approximatif indique qu'à 4 bits par paramètre, un modèle de 100B nécessite ~50 Go de stockage rien que pour les poids. La mémoire RAM, la bande passante, la dissipation thermique et la batterie représentent des limites physiques réelles sur les appareils mobiles.

Si un tel scénario se concrétisait, le coût marginal par token pour l'utilisateur s'approcherait de zéro, transférant la facture au prix d'achat du matériel. Le facteur limitant serait alors l'économie de l'appareil plutôt que la taille du modèle.

Questions ouvertes

Cette analyse constitue une approche illustrative plutôt qu'un verdict définitif. La passerelle de Vercel reflète une fraction du marché, pas l'ensemble du secteur. Un token d'extraction et un de raisonnement n'apportent pas la même valeur. J'ai évalué un seul modèle sur un seul GPU à travers huit tests valides ; il ne s'agit pas d'un classement général. Les tarifs d'API publics omettent les volumes réduits, les accords personnalisés et l'impact du cache. Les vitesses de prefill et la consommation électrique sont des estimations modélisées. Enfin, ma vitesse de génération de 44,7 t/s s'est révélée inférieure aux 131 t/s rapportés par d'autres sources pour un matériel de 16 Go similaire, une variation potentiellement liée à la longueur du contexte ou à la gestion de la mémoire VRAM.

Des interrogations clés subsistent : le prix par token restera-t-il la métrique déterminante, ou le coût par tâche accomplie avec succès s'imposera-t-il ? Qui capture la valeur réelle des poids ouverts : celui qui les publie, celui qui les héberge ou celui qui les utilise ? Et si les modèles de 100B migrent sur les appareils des utilisateurs, qui assumera le coût énergétique et le temps de traitement ?

Dans la nouvelle d'Ursula K. Le Guin sur Omelas, la prospérité d'une ville dépend d'un coût caché que personne ne veut examiner. Avec les modèles à poids ouverts, le dilemme est moins sombre, mais la question fondamentale demeure : qui paie la facture et où est-elle rédigée ?