Menu Pricing of Large Language Models

Each language version is independently generated for its own context, not a direct translation.

Imaginez que vous possédez un restaurant de génie culinaire (c'est le fournisseur de l'IA, comme OpenAI ou Anthropic). Vous avez des cuisiniers ultra-puissants (les modèles d'IA) qui peuvent préparer n'importe quel plat : des petits déjeuners rapides, des dîners gastronomiques complexes, ou même des banquets pour des milliers de personnes.

Le problème ? Vos clients sont tous différents.

Le client A veut juste un café rapide (une tâche simple).
Le client B veut un menu complet pour 50 personnes (une tâche complexe).
Le client C veut cuisiner 100 plats différents en même temps, mais certains sont très simples et d'autres très difficiles.

Comment fixer le prix ? Si vous vendez tout au kilo, vous perdez de l'argent. Si vous vendez tout à l'assiette, c'est trop compliqué à gérer.

C'est exactement le problème que résout ce papier de recherche. Voici l'explication simple, avec des analogies du quotidien.

1. Le problème : Trop d'informations cachées

Normalement, pour vendre, vous voudriez savoir exactement ce que chaque client veut faire. Mais ici, c'est impossible. Le client ne vous dit pas : "Je vais utiliser l'IA pour écrire 3 emails simples et 1 code complexe." Il achète juste un accès.

C'est comme si vous deviez vendre des tickets de cinéma à des gens qui ne vous disent pas s'ils vont regarder un film de 10 minutes ou un film de 3 heures, ni s'ils vont manger du pop-corn ou non. C'est un cauchemar pour le prix !

2. La découverte magique : Le "Score Global"

Les auteurs du papier (des économistes brillants) ont découvert une astuce incroyable. Grâce à la façon dont les IA fonctionnent (une règle mathématique appelée "homogénéité"), ils ont prouvé qu'on n'a pas besoin de connaître tous les détails du client.

L'analogie du "Score de Faim" :
Peu importe si le client veut manger 100 petits sandwichs ou 5 gros hamburgers, ce qui compte vraiment, c'est sa faim totale.

Le client qui veut 100 sandwichs a une "faim globale" de 100.
Le client qui veut 5 hamburgers a aussi une "faim globale" de 100.

Pour le restaurant, ces deux clients sont identiques. Ils vont consommer la même quantité totale d'ingrédients (de "tokens", comme on dit dans le jargon de l'IA).
Résultat : Au lieu de devoir deviner des milliers de détails sur chaque client, le vendeur peut se contenter d'un seul chiffre : le Score Global du client. Cela transforme un problème impossible en un problème simple.

3. La solution : Le "Menu de Crédits" (Comme un forfait téléphonique)

Une fois qu'on sait que tout le monde se résume à un "Score Global", comment vendre ? Le papier montre que la meilleure stratégie n'est pas de vendre des plats à l'unité, mais de vendre des forfaits de dépenses.

Imaginez trois façons de vendre, qui correspondent à ce qu'on voit aujourd'hui :

Le "Forfait Max" (Maximum Spend) :
- L'analogie : Vous payez 20 € pour un carnet de 100 tickets. Vous pouvez manger ce que vous voulez, mais une fois les 100 tickets épuisés, c'est fini. Plus de repas !
- Dans la vraie vie : C'est ce que fait Quora Poe. Vous payez un abonnement, vous avez des "points". Si vous les utilisez sur un gros modèle (le plat cher), ça va vite. Si vous les utilisez sur un petit modèle, ça dure longtemps. Mais si vous tombez à 0, c'est fini.
Le "Forfait Min" (Minimum Spend) :
- L'analogie : Vous vous engagez à dépenser au moins 50 € par mois. Si vous dépensez plus, pas de problème, vous payez le prix fort pour chaque assiette supplémentaire.
- Dans la vraie vie : C'est ce que fait GitHub Copilot. Vous payez un abonnement, vous avez un certain nombre de "requêtes". Si vous dépassez, vous pouvez continuer à payer à l'unité.
Le "Menu par Niveaux" (Versioning) :
- L'analogie : Le restaurant a trois salles.
  - Salle Standard : Cuisine rapide, plats simples.
  - Salle VIP : Cuisine de luxe, plats complexes.
  - Salle Royale : Le Chef étoilé personnel.
- Dans la vraie vie : C'est ce que fait OpenAI. Le forfait à 20 $vous donne accès aux modèles standards. Le forfait à 200$ vous donne accès au "Chef étoilé" (le modèle le plus intelligent, o1) que les autres ne peuvent pas toucher.

4. La concurrence : Le "Marché Noir" (Open Source)

Le papier imagine aussi une situation où il y a un Grand Restaurant (OpenAI) et des Food Trucks gratuits ou très bon marché (les modèles Open Source).

Les petits clients (ceux qui ont peu de faim) vont directement chez les Food Trucks. Pourquoi payer le Grand Restaurant pour un sandwich ?
Les clients moyens sont coincés. Le Grand Restaurant doit leur offrir juste assez de nourriture pour qu'ils n'aient pas envie d'aller aux Food Trucks en plus. C'est une stratégie de "dissuasion".
Les gros clients (ceux qui ont une faim énorme) sont les seuls à pouvoir se permettre le Grand Restaurant. Le restaurant peut alors leur vendre des plats très chers, car ils n'ont pas le temps d'aller aux Food Trucks.

En résumé

Ce papier explique pourquoi les prix de l'IA sont ce qu'ils sont aujourd'hui :

Ce n'est pas du hasard : Les prix ne sont pas fixés au hasard. Ils sont le résultat d'une optimisation mathématique pour gagner le maximum d'argent tout en vendant à tout le monde.
La simplicité est reine : Même si l'IA est complexe, les fournisseurs la vendent comme un simple "budget de consommation" (des crédits, des tokens).
Tout le monde ne paie pas la même chose : Les petits utilisateurs paient peu (ou utilisent des alternatives gratuites), tandis que les gros utilisateurs paient cher pour avoir accès aux meilleurs outils et aux plus gros volumes.

C'est un peu comme si le monde de l'IA avait enfin trouvé la recette parfaite pour transformer un plat complexe en un menu simple, rentable et adapté à chaque appétit.

Each language version is independently generated for its own context, not a direct translation.

Voici un résumé technique détaillé de l'article « Menu Pricing of Large Language Models » de Dirk Bergemann, Alessandro Bonatti et Alex Smolin.

1. Problématique et Contexte

L'accès aux grands modèles de langage (LLM) est devenu un intrant économique majeur, mais les mécanismes de tarification actuels (abonnements, métrique au token, crédits) semblent empiriques et manquent de fondement théorique. Le problème central de la tarification des LLM est un problème de sélection multidimensionnelle complexe :

Informations privées de haute dimension : Un utilisateur possède une fonction de valeur sur un continuum de tâches différentes ( $w_i$ pour $i \in [0,1]$ ).
Espace d'allocation élevé : L'utilisateur doit allouer un budget de tokens (entrées, sorties, fine-tuning) entre ces tâches.
Aléa moral (Moral Hazard) : Le fournisseur peut mesurer l'usage total des tokens, mais ne peut pas observer ni contracter sur l'allocation spécifique de ces tokens par tâche.

Sans hypothèses simplificatrices, ce problème semble intraitable en raison de la combinaison de l'adverse sélection et de l'aléa moral dans un espace infini.

2. Méthodologie et Cadre Théorique

Les auteurs développent un cadre de conception de mécanismes optimaux reposant sur une hypothèse clé de technologie de production homogène.

Fonction de gain : Le gain d'une tâche $i$ est modélisé par $g(x_i, z) = \Psi(x_i)\Phi(z)$ , où $x_i$ sont les tokens d'inférence et $z$ les tokens de fine-tuning.
Homogénéité : La fonction $\Psi$ est homogène de degré $\sigma \in (0,1)$ . Cela implique que le mélange optimal de classes de tokens (ratio entrée/sortie) est invariant d'échelle et identique pour toutes les tâches. Seule l'échelle d'utilisation varie selon la valeur marginale de la tâche.
Réduction de dimension (Sufficiency Statistic) : Grâce à l'homogénéité, le profil de type multidimensionnel de l'utilisateur ( $w$ ) se résume à un indice scalaire unique, appelé « type agrégé » ( $\theta$ ) :
$\theta(w) \triangleq \left( \int_0^1 w_i^{\frac{1}{1-\sigma}} di \right)^{1-\sigma}$
Cette réduction transforme un problème de sélection multidimensionnelle complexe en un problème de sélection unidimensionnelle classique (à la Mussa et Rosen, 1978).

3. Résultats Principaux

A. Allocation Efficace et Prix Linéaires

Dans un cadre de premier meilleur (information complète) ou sous contraintes de capacité, l'allocation efficace exige que tous les tâches utilisent les tokens d'inférence dans les mêmes proportions.

Corollaire 1 : Sous contraintes de capacité, l'allocation efficace peut être mise en œuvre par des prix linéaires égaux aux coûts marginaux majorés par les coûts d'ombre (shadow costs). Cela rationalise la pratique observée des API (paiement au token sans remises de volume).

B. Mécanisme Optimal pour un Monopoleur (Modèle Unique)

Pour un fournisseur monopolistique vendant un seul modèle :

Réduction du problème : L'utilité indirecte de l'acheteur prend une forme multiplicative : $U = \theta \cdot Q(X, Z)$ , où $Q$ est la qualité agrégée.
Mécanisme Optimal : Le fournisseur propose un menu de contrats de dépenses engagées (committed-spend contracts).
- Les acheteurs paient une redevance fixe pour un budget de tokens.
- Ils allouent librement ce budget entre les classes de tokens (entrées, sorties, fine-tuning) à des prix égaux au coût marginal.
- Les types élevés achètent des budgets plus grands avec des remises de quantité (prix moyen par unité de qualité décroissant).
Implémentations Indirectes : Le mécanisme optimal peut être implémenté de trois manières observées sur le marché :
1. Maximum-spend : Un plafond de dépenses (crédits) avec suspension à épuisement (ex: Poe de Quora).
2. Minimum-spend : Un engagement de dépenses minimales débloquant des prix unitaires réduits (ex: GitHub Copilot avec dépassements).
3. Tarifs à deux composantes : Redevance fixe + prix linéaire au token.

C. Extension aux Modèles Multiples (Versioning)

Lorsque le fournisseur offre plusieurs modèles différenciés (ex: capacités de raisonnement vs rapidité) :

Allocation des tâches : Un acheteur de type donné utilise un seul modèle pour toutes ses tâches, même si les modèles diffèrent par leur élasticité de substitution.
Structure de Menu : Le monopoleur pratique une versioning verticale. Les types plus élevés accèdent à des modèles plus capables (plus coûteux en calcul) et non pas seulement à de plus grands volumes.
Discontinuité : La qualité saute de manière discrète aux seuils de changement de modèle, reflétant la non-convexité de la fonction de coût globale.

D. Concurrence (Leader Propriétaire vs Frange Open-Source)

Dans un scénario où un leader propriétaire fait face à une frange concurrentielle vendant au coût marginal :

Trois régimes d'allocation :
1. Types faibles : N'utilisent que la frange (open-source).
2. Types intermédiaires : Achètent du leader exactement la quantité nécessaire pour dissuader l'achat complémentaire (top-up) auprès de la frange. C'est une distorsion extensive nouvelle.
3. Types élevés : Sont servis comme sous monopole pur (quantité distordue vers le bas).
La concurrence affecte à la fois la marge intensive (quantité vendue) et la marge extensive (qui adopte le modèle propriétaire).

4. Contributions et Signification

Contributions Théoriques :

Tractabilité : Démonstration que l'homogénéité de la fonction de gain permet de résoudre un problème de sélection multidimensionnelle avec aléa moral, en réduisant l'espace des types à un scalaire.
Nouveaux Mécanismes : Caractérisation formelle des mécanismes de « dépenses engagées » (budgets de tokens) comme étant optimaux, reliant la théorie des mécanismes aux pratiques industrielles.
Analyse Concurrentielle : Étude de l'interaction entre un monopoleur et une frange concurrentielle dans un contexte de technologies à ressources partagées.

Signification Empirique et Industrielle :
L'article fournit une justification théorique robuste pour les structures de prix observées chez les principaux fournisseurs (Anthropic, OpenAI, GitHub) :

Anthropic : Illustre le mécanisme de budget de tokens (même modèle, différenciation par la quantité).
OpenAI : Illustre le versioning multi-modèles (accès exclusif aux modèles les plus puissants pour les tiers supérieurs).
GitHub Copilot / Poe : Implémentent les mécanismes indirects (maximum/minimum spend) avec des règles de dépassement ou de cap strict.
APIs : Le prix linéaire au token sans remises de volume correspond à l'allocation efficace sous contraintes de capacité, suggérant que les fournisseurs privilégient l'adoption de marché à l'extraction de rente dans ce segment.

Conclusion :
Ce papier établit que les pratiques de tarification actuelles des LLM ne sont pas arbitraires, mais reflètent des forces économiques fondamentales liées à la nature de la technologie (homogénéité, coûts marginaux, capacité de calcul). Il offre un cadre pour analyser l'évolution future de ce marché, notamment dans un contexte de concurrence accrue et de dynamiques de données.