Le prix des tokens devient de plus en plus élevé
(ethanding.substack.com)- Contrairement à l’idée que le coût des tokens des LLM baisse d’un facteur 10 chaque année, les services d’abonnement IA voient leur rentabilité se dégrader de plus en plus
- La demande pour les derniers modèles de LLM se concentre toujours sur les modèles SOTA (State-of-the-art), si bien que la baisse de prix des modèles « anciens » ne se traduit pas réellement par une réduction des coûts
- À mesure que les performances des modèles augmentent, le volume de tokens utilisés croît de façon exponentielle, ce qui compense la baisse du prix unitaire et fait au contraire exploser les coûts globaux
- Les expérimentations d’offres d’abonnement illimitées (ex. : Claude Code à 200 $/mois) sont elles aussi intenables à cause de l’explosion de consommation des gros utilisateurs
- En dehors d’une facturation à l’usage, il n’existe pas de modèle durable à long terme, mais son adoption concrète reste difficile à cause de la concurrence entre startups et de la résistance des consommateurs
- Sans transition vers un modèle de revenus durable, la plupart des startups finiront par faire face à un risque de faillite
Abonnements IA : pourquoi les pertes augmentent malgré la baisse du prix unitaire des tokens
L’illusion de la baisse des prix des LLM
- Les fondateurs ont cru au playbook des VC : « le prix unitaire des tokens va baisser d’un facteur 10, il suffit de tenir un peu et l’on passera à une structure à forte marge », et ont donc lancé au départ des abonnements au prix coûtant, voire à perte
- En pratique, le prix unitaire des tokens de modèles anciens comme GPT-3.5 a bien chuté de plus de 10x, mais la demande des utilisateurs et du marché se porte toujours sur les modèles les plus récents et les plus performants (SOTA)
- En réalité, après 18 mois, les marges ne se sont pas améliorées et se sont même dégradées
- Les baisses de prix des anciens modèles ne se ressentent que pour des produits déjà hors de l’attention du marché, comme un « journal d’hier »
Le prix et la structure de la demande pour les modèles les plus récents
- GPT-4, Claude 3 Opus et autres modèles récents sont toujours lancés à des prix élevés comparables, et même si les anciens modèles deviennent très bon marché, leur usage réel reste marginal
- Les utilisateurs ne veulent que le « meilleur niveau de performance » ; les « anciens modèles bon marché » ne valent guère mieux, sur ce marché, que de vieilles voitures d’occasion
- Ce que l’on cherche réellement avec l’IA, ce sont les meilleurs résultats ; il est donc rare que les utilisateurs choisissent volontairement un ancien modèle pour économiser
- Au final, pour rester compétitif sur le marché, il faut toujours proposer le modèle le plus récent et le plus cher, ce qui maintient durablement les coûts
- C’est comme si, même si le prix des voitures d’occasion des années 1990 baissait, les consommateurs continuaient malgré tout à acheter des voitures neuves
L’explosion de l’usage des tokens
- À mesure que les performances des modèles progressent, le nombre de tokens consommés par une seule tâche augmente de façon exponentielle
- Une tâche qui se terminait autrefois avec 1 000 tokens peut désormais en consommer 100 000
- Autrefois, une question d’une phrase appelait une réponse d’une phrase ; aujourd’hui, avec des recherches complexes, des boucles et de l’orchestration, l’IA peut fonctionner en continu pendant 10 à 20 minutes et consommer d’énormes volumes de tokens
- En demandant à l’IA des recherches et analyses plus poussées, on arrive à des scénarios du type « 20 minutes par exécution, 24 heures sur 24 », ce qui fait bondir la consommation quotidienne moyenne par utilisateur
- Par exemple, même une seule utilisation quotidienne d’une fonction de « deep research » coûtant 1 $ n’est déjà pas rentable avec un abonnement à 20 $
- La baisse du prix unitaire est annulée par l’augmentation de la consommation totale de tokens, au point qu’un forfait à 20 $/mois ne peut même plus absorber une tâche à 1 $ par jour
L’échec des forfaits illimités
- Des offres comme Claude Code à 200 $/mois en illimité, l’optimisation automatique des tokens ou l’utilisation du PC de l’utilisateur ont été testées comme différentes mesures de réduction des coûts
- Mais certains power users ont approché les 10 milliards de tokens par mois (soit l’équivalent de 12 500 exemplaires de Guerre et Paix), car ils ont utilisé l’automatisation, les tâches répétitives et les boucles pour faire exploser leur consommation
- « L’usage de l’IA s’est dissocié du temps humain, et les API tournent 24 h/24 avec une explosion des tokens »
- Malgré l’innovation technique, l’offre a finalement été revue en arrière
- Conclusion : le modèle d’abonnement illimité est désormais impossible ; l’équation économique ne tient tout simplement plus
Le dilemme auquel toute l’industrie est confrontée
- S’obstiner dans le modèle par abonnement accroît le risque de dégradation de la rentabilité et d’effondrement
- Les entreprises d’IA savent toutes que seule la facturation à l’usage (usage-based pricing) est une réponse viable, mais l’arrivée d’un concurrent sur abonnement fait peser un risque élevé de fuite des utilisateurs
- Cette structure de « dilemme du prisonnier » pousse tout le monde dans une course aux subventions pour power users
- Cursor, Replit et d’autres adoptent eux aussi une logique de « croissance d’abord, rentabilité plus tard », mais devront tôt ou tard affronter ce problème de rentabilité, avec des restructurations inévitables à la clé
Trois pistes de solution réalistes
- 1. La facturation à l’usage
- En adoptant dès le départ un modèle économique honnête, il devient possible de concevoir une structure de revenus qui ne passe pas sous le coût de revient. À long terme, c’est le seul modèle réellement durable
- En revanche, les consommateurs rejettent fortement les tarifs au compteur, ce qui limite les chances de succès grand public
- 2. Cibler le marché entreprise avec de forts coûts de changement
- En s’adressant à des clients enterprise avec des coûts de changement élevés (ex. : grands groupes, institutions financières), une fois l’entrée réalisée, il devient presque impossible de résilier, et les marges sont élevées
- Les domaines des systèmes of record (SOR, CRM/ERP/EHR, etc.) en sont l’exemple type (ex. : déploiement chez Goldman Sachs pour 40 000 ingénieurs)
- 3. Créer de la valeur via l’intégration verticale (Vertical Integration)
- Comme Replit, on peut proposer l’inférence LLM elle-même comme un « produit d’appel » déficitaire, puis générer des revenus grâce aux services construits au-dessus : hosting, base de données, déploiement, monitoring, etc.
- L’objectif est de faire croître l’usage de l’IA pour l’amener vers le marché de l’infrastructure
- À l’avenir, le prix unitaire des tokens continuera sans doute de baisser, mais les attentes des utilisateurs et leur niveau d’usage augmenteront eux aussi de façon exponentielle
- Les entreprises qui s’en tiennent uniquement à une stratégie abonnement + croissance risquent au final d’avoir droit à des « funérailles à coût élevé »
Résumé
- L’optimisme du type « l’an prochain les tokens seront 10 fois moins chers » ne suffit pas à faire tenir un business
- Les utilisateurs exigent toujours davantage, en qualité comme en volume d’usage
- La formule progrès des modèles = explosion de l’usage = hausse des coûts est désormais bien réelle ; un business IA durable devra donc basculer vers une nouvelle structure fondée sur la facturation à l’usage, les grands contrats enterprise ou l’intégration verticale
- Pour assurer la continuité de l’activité, une nouvelle approche structurelle comme la stratégie de « néo-cloud » devient nécessaire
4 commentaires
Avec la difficulté du caching et l’automatisation via MCP, un usage illimité pourrait réellement aller jusqu’à un usage illimité au sens littéral… Comme chez les opérateurs sans forfait data illimité, on pourrait avoir quelque chose comme ~300 usages par jour, ~2 000 usages par jour, etc. J’ai aussi l’impression qu’on va se diriger vers une tarification du type des anciens SMS.
Comme sur Internet, où la quantité est en elle-même illimitée (même s’il existe parfois une tarification à l’usage), il me semblerait préférable d’adopter un modèle où l’on limite la vitesse. Pour l’implémentation, de toute façon, comme il existe déjà des traitements par lots, il est possible de dissocier les ressources de calcul de celles qui parviennent à l’utilisateur. Au final, si le fournisseur peut aussi y gagner en prévisibilité, et que l’utilisateur peut bénéficier d’un tarif raisonnable et d’une vitesse garantie, n’est-ce pas gagnant-gagnant ? Pour certains gros utilisateurs, il faudrait sans doute passer par des contrats distincts afin de leur allouer des ressources dédiées.
Commentaires sur Hacker News
D’après ce qui est cité dans l’article, les consommateurs n’aiment pas la facturation à l’usage et préfèrent souvent surpayer un forfait illimité plutôt que de recevoir une facture surprise d’un montant élevé. Mais en réalité, c’est plus complexe. Sur Amazon, il arrive souvent qu’au moment où l’on pense avoir prévu les coûts, une grosse facture tombe soudainement. La raison, c’est qu’il n’existe pas de moyen de définir un paramètre du type « arrête automatiquement si ça dépasse X dollars par mois ». Ce genre de structure en « surprise net 30 » donne toujours l’impression d’un coût prévisible, mais finit par produire des frais inattendus. En revanche, la facturation à l’usage pourrait être une bonne approche si l’utilisateur pouvait voir clairement sa consommation et définir un plafond pour éviter de dépasser son budget. Du point de vue des entreprises d’IA, il suffirait d’aider les utilisateurs à gérer leur budget avec, par exemple, un histogramme « tokens utilisés / total de tokens », la consommation de tokens par réponse, ou une estimation du nombre de réponses restantes avant dépassement. L’important, c’est de ne jamais provoquer de facturation surprise. Pourtant, les entreprises préfèrent cacher ces informations en tokens et en dollars, un peu comme les sites de jeux d’argent qui évitent de relier directement leurs « corporate bucks » à l’USD
Je pense que la facturation à l’usage convient bien aux services B2B d’infrastructure (AWS, etc.). À mesure qu’une entreprise grandit, son utilisation de l’infrastructure et ses coûts augmentent proportionnellement, donc cela reste prévisible, et une fois l’infrastructure en place, il y a peu de choses à surveiller. En revanche, dans le cas de l’IA utilisée comme outil de travail, la facturation à l’usage est un obstacle majeur. Dans ce contexte, elle peut carrément décourager l’usage du produit, car elle impose une fatigue permanente à devoir évaluer le rapport coût/bénéfice à chaque utilisation. Si c’est utilisé au travail, il faut même parfois obtenir une validation managériale à répétition. Un outil censé améliorer la productivité ne devrait pas créer ce genre de barrière. La quasi-totalité des gens ne vont pas se poser 250 fois la question « est-ce que cette action vaut 3 dollars ? ». Avec la facturation à l’usage, ils finissent simplement par ne pas utiliser l’outil
Ce qui me dérange, c’est que les entreprises essaient de cacher la conversion entre tokens et dollars. Je teste en ce moment l’essai de l’agent Copilot de GitHub, et la tarification est vraiment opaque. On ne voit que l’expression « premium requests » partout, et dans mon tableau de bord je n’ai aucun moyen de consulter en temps réel mon utilisation ni mes limites. Dans l’interface, si on clique sur la mention des premium requests, on arrive sur la documentation, mais rien n’indique clairement les plafonds réels ou le tableau de bord tarifaire
Chez Amazon (AWS), le problème est encore plus grave. Contrairement à l’attrait du « c’est moins cher » chez AWS, le changement n’a de sens que si cela revient réellement moins cher que l’alternative. Pourtant, beaucoup d’entreprises ne consacrent pas de temps développeur à changer leur infrastructure. Le coût d’opportunité est élevé, et comme il y a des risques liés aux revenus, au temps de développement, à la concurrence, etc., si le retour sur investissement n’est pas vraiment important, cela est perçu comme du temps de développement gaspillé. Si, au final, l’infrastructure devient en réalité plus chère que l’alternative, alors il ne reste qu’à absorber la perte, puisque le temps développeur a déjà été dépensé. Pour l’instant, avec la tarification basée sur les tokens, cette charge de changement et de coût d’opportunité ne se fait pas encore autant sentir, car on peut facilement revenir à l’ancienne méthode. Mais je m’attends à ce que cette structure évolue à l’avenir
La structure tarifaire d’Amazon me paraît très floue et compliquée. Par exemple, il arrive qu’on n’ait aucun moyen de comprendre pourquoi les coûts de base de données montent et descendent sans arrêt
Pour des processus bien définis, la facturation à l’usage est vraiment utile. Ce que j’aime chez AWS, c’est qu’elle permet d’aligner les coûts sur l’activité réelle. Avant, c’était difficile, et cela créait beaucoup de politique interne. Il arrivait qu’un commercial aille directement convaincre un dirigeant de la nécessité d’un équipement, et qu’on se retrouve à récupérer du matériel réseau dont on ne voulait absolument pas. Mais du point de vue de l’utilisateur, ce type de gestion fine des coûts n’est pas souhaitable, parce qu’on finit par être évalué en permanence sur toutes sortes d’indicateurs qui n’ont pas de lien direct avec la productivité. Quand j’étais stagiaire dans les années 90, il fallait subir toute une bureaucratie pour faire approuver un simple appel longue distance. La personne qui validait devait juger si 20 minutes de conversation étaient justifiées, et si on dépassait la limite, je devais payer la différence. Ce n’était pas amusant. Pour une IA destinée aux utilisateurs, le bon modèle est un tarif fixe. Si ma productivité augmente de 20 % et que j’utilise ChatGPT Pro à 200 $ par mois, cela représente 16 k$ de valeur par an. C’est un investissement extrêmement bon marché
Les affirmations de l’article ne me semblent pas logiques. J’ai du mal à être d’accord avec l’idée que « dès qu’un nouveau modèle sort, 99 % de la demande bascule immédiatement ». En réalité, Sonnet 4 est plus utilisé qu’Opus 4, et beaucoup d’utilisateurs choisissent des modèles moins performants mais moins chers et plus ordinaires. Selon les cas, l’utilisabilité, la vitesse, l’habitude et d’autres facteurs font que plusieurs modèles non-SOTA coexistent dans les usages. Classement des modèles : https://openrouter.ai/rankings L’article présente aussi le passage d’Opus à Sonnet, puis à Haiku quand la charge devient trop lourde, comme une forme d’autoscaling, mais je ne pense pas que ce comportement soit réellement intégré aux poids du modèle. Globalement, les problèmes tarifaires décrits dans le texte me semblent rejouer ce qu’on a déjà vu à l’époque de l’hébergement cloud : beaucoup d’utilisateurs préfèrent la commodité d’un abonnement mensuel même si les performances sont moindres, tandis qu’une partie des utilisateurs d’API (gros utilisateurs/entreprises) passe par la facturation à l’usage, et cette structure est déjà suffisamment rentable ; la plupart des startups IA sont B2B, pas B2C
L’idée selon laquelle « Claude Code proposait à l’origine un illimité à 200 $/mois avant de faire marche arrière » est inexacte. Le nom même du plan était 20x, et il y avait dès le départ des limites claires, comme une fenêtre de 5 heures par session et une limite mensuelle de 50 sessions (même si ce n’était pas strictement appliqué). Personnellement, je l’utilise et j’ai rarement eu le sentiment que ce n’était pas suffisant ; au contraire, je trouve encore aujourd’hui que la limite est élevée. Donc dire la vérité n’affaiblit en rien l’argument
Le vrai problème, en pratique, c’est qu’aujourd’hui on tape sur un moustique avec un canon, faute de distinguer les usages entre modèles. Tous les problèmes n’ont pas besoin d’un modèle généraliste haut de gamme. À l’avenir, les services que nous utilisons vont probablement évoluer vers des offres « bundle » avec plusieurs modèles, ce qui produira des courbes d’usage bien plus efficaces
Aucun modèle, à ce jour, n’est encore assez fiable pour qu’on lui confie totalement les tâches importantes. Même les meilleurs modèles se comportent parfois de manière absurde. Mon cerveau sait toujours traiter le travail lui-même, sans que j’aie besoin de réfléchir à la délégation ; donc je ne délègue à l’IA que s’il y a un bénéfice vraiment évident. Je préfère d’abord m’appuyer sur ce que je sais bien faire. Les entreprises d’IA font la promotion de la performance maximale, mais pour les utilisateurs, l’indicateur important, c’est le « pire moment » de l’IA. C’est pour cela qu’il y a toujours une demande pour le SOTA. L’IA est évaluée sur son pire moment : peu importe à quel point elle est bonne, une seule erreur peut être fatale, exactement comme un humain peut être licencié pour sa pire erreur. Ce n’est pas la performance parfaite en environnement de labo qui compte, c’est ce qui se passe quand ça casse en usage réel. Le texte montre bien cet aspect
Pour l’instant, les tâches les plus difficiles ne sont toujours pas résolues, et il n’existe pas tant de travaux que ça pour lesquels on peut accepter des réponses à faible précision. Cela peut convenir à certains pipelines texte, mais pour presque tous les usages orientés utilisateur, une qualité élevée reste nécessaire
C’est un point que beaucoup négligent. Les modèles GPU 7b ou 32b fonctionnent déjà très bien sur beaucoup de tâches, et ils tournent même sur du matériel ancien. On est encore dans une phase de hype où la performance globale des LLM monte partout, mais avec le temps, l’amélioration des très gros modèles va probablement se tasser et des choix plus réalistes vont commencer à s’imposer
Cela vaut la peine de tester plusieurs modèles. Le système de chatbot très simple que j’ai construit récemment utilise cinq modèles différents selon les situations. Alterner et combiner les modèles change énormément les coûts, l’expérience utilisateur et la qualité
S’il existait une option où Claude Opus guiderait Sonnet, je l’utiliserais pour presque toutes les conversations. Le faire manuellement est fastidieux et casse le flux, donc au final je continue simplement à utiliser Opus. Grâce au traitement en parallèle, le coût d’entrée me semble faible, donc même avec un prompt plus gros, je ne pense pas que ce soit très pénalisant
J’aimerais qu’une entreprise d’IA construise un système capable de déléguer les tâches simples à un modèle plus « bête ». Les tâches complexes exigent un modèle de niveau Opus, mais elles contiennent en réalité énormément de sous-parties qui pourraient être gérées par du 3.5 Sonnet. Opus pourrait faire la distinction entre le simple et le difficile, puis distribuer les parties faciles à plusieurs instances de 3.5 Sonnet. Cela me paraît tellement évident que je suppose que tout le monde est déjà en train de le construire
Claude Code utilise effectivement automatiquement Sonnet et Haiku. À la fin d’une session, il affiche différentes statistiques, notamment sur les tokens et le coût. J’imagine qu’il doit aussi exister un moyen de consulter ces informations pendant la session
Par exemple, pourquoi ne pas faire en sorte que le prompt renvoie, pour chaque sous-tâche, un « niveau de modèle recommandé » de 1 à 10 ?
Depuis un ou deux ans, je paie directement l’API et j’utilise des frontends open source (LibreChat, etc.) pour accéder à différents modèles. Pour un usage occasionnel, cela me convient très bien : il me suffisait de recharger environ 10 $ tous les quelques mois. Comme j’utilise bien moins de tokens que ce qu’incluent la plupart des forfaits, j’ai jugé cette solution bien plus économique. Mais depuis que j’ai commencé à essayer divers outils comme Claude Code, mes tokens s’épuisent visiblement beaucoup plus vite. Hier, j’ai brûlé 5 $ de tokens en 15 minutes. Je savais que les outils de code fonctionnaient très différemment d’un simple échange de questions avec un LLM, mais je ne pensais pas que l’écart serait à ce point énorme. Ce qui m’étonne encore plus, c’est que cette forte consommation de tokens se voit mal en pratique, car elle est cachée dans l’augmentation progressive du contexte ou dans l’orchestration des outils
Ce phénomène vient du fait que Claude Code utilise un contexte bien plus large qu’à l’ordinaire et effectue beaucoup de traitements itératifs
Avec 20 $ d’API Deepseek, j’ai tenu presque un an sans problème (le fait que ce soit une entreprise chinoise m’est égal). C’est lent, mais j’ai même l’impression que la qualité est meilleure que celle des modèles Deepseek auto-hébergés, d’après mon expérience. Je n’utilise pas de fonctionnalités de type agent
Je conteste l’affirmation selon laquelle « 99 % de la demande va toujours vers les modèles de pointe ». La véritable frontière n’est pas seulement la « capacité », mais aussi le « rapport capacité/prix ». Les modèles les plus haut de gamme ne captent pas 99 % des parts, c’est même l’inverse. D’après les statistiques d’OpenRouter, Claude Opus 4 représente environ 1 % de part d’usage, alors que le plus populaire est Sonnet 4, utilisé par 18 % des abonnés. Et en dehors de cela, les Gemini Flash 2.0 et 2.5, moins chers, sont aussi très utilisés. Ils coûtent encore moins que Sonnet 4
À San Francisco, pourquoi n’utilise-t-on ni majuscules ni ponctuation ? Et pourquoi les gens de la Silicon Valley sont-ils obsédés par une fausse croissance exponentielle ? À mes yeux, il est plus évident que les progrès de l’IA ne sont pas réellement exponentiels en eux-mêmes, mais reflètent surtout l’énorme augmentation des ressources investies par rapport à il y a quelques années
Je me demande si ce style d’écriture particulier ne sert pas justement à montrer que le texte n’a pas été écrit par un LLM
Je n’arrive pas à supporter l’évolution naturelle de la langue ? /blague Peut-être qu’il faut simplement vivre à l’ancienne
Si on va dans le Tenderloin ou sur Mission Street à San Francisco, est-ce qu’on peut vraiment se faire tirer dessus juste parce qu’on n’utilise pas de majuscules ni de ponctuation ? (blague)
Le texte passe à côté du jeu des chaises musicales dans la phase de conquête du terrain. Comme avec Uber, on peut utiliser du capital-risque pour prendre des parts de marché, accepter des pertes pendant des années, puis, une fois installé dans l’esprit des clients, rester difficile à déloger même si des concurrents plus récents et moins chers arrivent ensuite. L’entreprise finit par trouver une place stable, et même après l’introduction en bourse, elle peut conserver une action solide, sinon exceptionnelle
Le texte donne l’impression que personne ne paie de tarification à l’usage, alors qu’en réalité les clients API, c’est-à-dire presque tous les clients entreprise, paient déjà tous à l’usage aujourd’hui
« Je me demande pourquoi, à San Francisco, ils n’utilisent ni majuscules ni ponctuation »
En allant lire le texte, on voit que c’est vraiment le cas. Ce qui est curieux, c’est que certaines phrases ont un point final et d’autres non, donc c’est mélangé ; quelle pourrait en être la raison ? Est-ce que quelqu’un le saurait, par hasard ? Ça m’intrigue 🤔