Les modèles de pricing des gateways LLM expliqués : au token, à la requête, BYOK, flat
Quatre modèles de pricing, quatre structures d'incitation — prends celui aligné avec ton usage
Les gateways LLM facturent de quatre façons : markup provider, metered, flat par requête, et OSS self-host. Chaque modèle aligne les incitations différemment. Voilà comment choisir.
La plupart des équipes choisissent une gateway LLM sur les features. C'est le mauvais premier filtre. Le premier filtre devrait être le modèle de pricing, parce que le modèle de pricing détermine ce que la gateway est structurellement incitée à optimiser — et donc ce qu'elle ship, deprecate, et résiste silencieusement dans le temps.
Il y a quatre modèles de pricing sur le marché des gateways LLM. Chacun crée un alignement différent entre toi et ta gateway. Une fois que tu vois le pattern, les différences de features commencent à faire sens.
Modèle 1 : Markup provider (style OpenRouter)
Comment ça marche. Tu envoies tes requêtes à la gateway. La gateway appelle les providers sur son compte. La gateway te facture les tokens à un petit markup au-dessus des tarifs wholesale. Tes clés provider ne sont pas impliquées — en fait, tu n'as même pas besoin de comptes provider.
Ce pour quoi c'est optimisé. Facilité d'onboarding. Une carte, un signup, tu es live. Catalogue de modèles massif parce que la gateway pré-négocie avec chaque provider.
L'incitation. Le revenu de la gateway grossit avec ta dépense en tokens. Chaque token économisé est un token de revenu perdu. Les features qui réduisent ta dépense — routing agressif vers des modèles moins chers, caching avancé, alertes burn-rate — sont des features que la gateway a une désincitation structurelle à bien shipper.
Où ça marche. Prototypage. Side projects. Use cases où la dépense totale est petite et la commodité domine. À quelques centaines de dollars par mois, un markup de 5 % est du bruit.
Où ça casse. À l'échelle. Une fois que ta dépense passe quelques milliers de dollars par mois, le markup compound en un vrai line item. 5 % sur 10K €/mois fait 500 €/mois, récurrents. Et la gateway n'a aucune raison structurelle de t'aider à réduire les autres 10K €.
Modèle 2 : Metered / usage-based (style Vercel AI Gateway)
Comment ça marche. Tu payes le provider pour les tokens directement (BYOK, souvent). La gateway te charge un fee metered — par requête, par token routé, par MB traité — en plus. Parfois il y a un tier gratuit.
Ce pour quoi c'est optimisé. Les plateformes où la gateway est embedded dans un produit plus large. Vercel la bundle avec leur plateforme. Cloudflare la bundle avec leur edge. Le mètre est designé pour scaler gentiment avec ton usage pour ne pas paraître punitif à faible volume.
L'incitation. Plus douce que le markup provider, mais toujours alignée avec la croissance d'usage. La gateway gagne plus d'argent quand ton volume de requêtes monte. Le routing basé sur l'intelligence vers des modèles moins chers réduit quand même leur revenu, bien que moins dramatiquement qu'avec le markup provider.
Où ça marche. Quand le fee metered est petit par rapport à ta dépense provider et tu valorises l'intégration plateforme. Pour les équipes déjà engagées sur Vercel ou Cloudflare, ça fit naturellement.
Où ça casse. À très hauts volumes, où même un petit mètre par requête s'additionne. Et quand le désalignement d'incitation commence à se montrer — la gateway pourrait shipper observability et fallbacks avant de shipper des features qui coupent tes coûts.
Modèle 3 : Abonnement flat par requête (style HiWay)
Comment ça marche. Tu payes les providers directement au wholesale (BYOK). Tu payes la gateway un abonnement mensuel flat basé sur le tier de volume de requêtes — ex. Free à 2 500 req/mois, Build à 15 € pour 100K, Scale à 39 € pour 500K, Business à 249 € pour 5M, enterprise custom. Le même abonnement couvre n'importe quel modèle vers lequel tu route.
Ce pour quoi c'est optimisé. Coût prévisible. Ton coût gateway est un line item connu pour le mois, indépendant de comment tu route le trafic.
L'incitation. Le revenu de la gateway est découplé de ta dépense en tokens. Peu importe si tu route vers Haiku ou Opus — l'abonnement est le même. Les features qui réduisent ta dépense en tokens (routing vers modèles moins chers, caching, alertes burn-rate) ne coûtent rien à la gateway, donc la gateway a une incitation structurelle à bien les shipper.
Où ça marche. Équipes prod avec une dépense non triviale qui se soucient des contrôles de coût et des marges prévisibles. Équipes UE qui veulent aussi BYOK + hosting UE à côté de ce modèle de pricing.
Où ça casse. À volumes quasi-nuls où le Free (2 500 req/mois) suffit et où même le tier Build à 15 €/mois pèse pour un hobby project. Pour ceux-là, le Free ou les APIs provider directes sont plus simples.
Modèle 4 : OSS self-hosted (style LiteLLM)
Comment ça marche. Tu télécharges le soft, tu le deploies toi-même, tu payes le provider directement. La gateway elle-même n'a pas de coût runtime au-delà de l'infra sur laquelle tu la fais tourner.
Ce pour quoi c'est optimisé. Contrôle, coût à l'échelle (si tu as déjà la plateforme), évitement du vendor lock-in.
L'incitation. Aucune — il n'y a pas de vendor à inciter. La roadmap du soft est drivée par les mainteneurs et les contributions communauté. Les features arrivent quand quelqu'un les écrit.
Où ça marche. Équipes avec platform engineers et infra ops existante. Environnements régulés où faire tourner ta propre gateway est la seule option compliant.
Où ça casse. Petites équipes sans capacité platform engineering. Le label "gratuit" planque 4-8 heures/semaine d'ops, on-call, charge d'upgrade. Voir notre post séparé sur l'économie du self-host.
La matrice d'alignement
Voilà la même info en matrice :
| Modèle | Qui paye les tokens | Modèle de revenu gateway | Aligné pour t'aider à économiser ? |
|---|---|---|---|
| Markup provider | Gateway (puis te facture) | % de la dépense tokens | Non — revenu grossit avec la dépense |
| Metered | Toi (BYOK) | Mètre par requête | Partiellement — lié au volume |
| Flat par requête | Toi (BYOK) | Abonnement flat | Oui — revenu indépendant de la dépense |
| OSS self-host | Toi (BYOK) | Aucun | N/A — pas de vendor |
La troisième ligne est celle qui change les choses. Quand le revenu de la gateway est déconnecté de ta dépense en tokens, les features qu'elle ship commencent à avoir l'air différentes. C'est pas magique ; c'est juste de l'alignement d'incitations.
Aucune carte bancaire requise
Le raisonnement break-even
Faisons un break-even réaliste entre les deux options managées — markup provider et flat par requête — à différents niveaux de dépense.
Scénario : 500K requêtes/mois, workload mixte
Suppose que chaque requête a un profil token moyen qui te coûte 0,008 € en tarifs provider wholesale. Dépense wholesale totale : 4 000 €/mois.
Modèle markup provider (5 % markup)
- Tokens wholesale : 4 000 €
- Markup : 200 €
- Total : 4 200 €/mois
Modèle flat par requête (tier Scale à 39 €, qui couvre jusqu'à 500K requêtes)
- Tokens wholesale (BYOK, payés aux providers) : 4 000 €
- Abonnement gateway : 39 €
- Total : 4 039 €/mois
Flat par requête gagne de 161 €/mois à cette échelle — et c'est avant même que le smart routing ne rentre en jeu.
Scale up : 5M requêtes/mois, 40 000 € de dépense provider
- Markup provider (5 %) : 42 000 €/mois
- Flat par requête (tier Business à 249 €, 5M requêtes) : 40 249 €/mois
Flat par requête gagne de 1 751 €/mois. Plus de 21 000 €/an, entièrement depuis l'absence de markup pourcentage.
Ajoute le smart routing au deuxième scénario — route 60 % du trafic vers les modèles tier Haiku au lieu de Sonnet — et ta facture wholesale peut tomber de 40-85 %, compoundant les économies. Sous markup provider, 30 % de cette économie part encore à la gateway en markup. Sous flat par requête, 100 % de l'économie est à toi. Le smart routing est indépendant du volume — il s'applique à chaque requête, que tu en fasses 5K ou 5M par mois.
À quoi ça ressemble en pratique
Trois patterns concrets que je vois quand les équipes changent de modèle de pricing :
Pattern 1 : Équipe markup essaye BYOK + flat par requête à 10M req/mois. Ils tournaient à 8 000 €/mois markup 4 % inclus. Ils passent à flat par requête sur un tier Enterprise custom + BYOK. Leur markup pourcentage disparaît. Leur facture provider reste à 7 700 €/mois au départ. Mais plus important, le flip d'incitation se déclenche — ils commencent à activer le smart routing agressif parce que la gateway les aide activement à router moins cher. Six mois plus tard leur facture tokens est 35 % plus basse. Économie annuelle totale : environ 38 000 €.
Pattern 2 : Équipe self-hosted de 4 ingés passe au managé. Ils "économisaient" sur une gateway en self-hostant LiteLLM, mais passaient 6 heures/semaine d'ingé dessus. Passage à gateway flat par requête sur le tier Business à 249 €/mois. Leur capacité ingé pour le boulot produit monte de ~25 heures/mois. Les features shipent plus vite. L'abonnement se paye sur le premier retard évité — plus le smart routing qui commence à rogner sur la facture provider en plus.
Pattern 3 : Solo founder reste sur markup. Dépense mensuelle totale 80 €. Un modèle markup avec signup instant est le bon choix pour lui. Le markup de 5 % fait 4 €. La friction du setup BYOK + abonnement ne vaut pas les 4 €. Il migrera dans 18 mois si le business grossit.
Les trois décisions sont correctes pour leurs contextes. L'erreur c'est de choisir la mauvaise pour ton contexte, généralement parce que tu as juste regardé les features et pas le modèle de pricing en dessous.
Attention à ces anti-patterns
"On facture un petit pourcentage sur l'usage tokens" + "On a de super features de réduction de coût"
Ces deux trucs sont en tension. Si le revenu de la gateway grossit quand tu dépenses plus, shipper des features qui te font dépenser moins est une contre-incitation. Certaines boîtes les shipent quand même parce que leur brand l'exige ; la plupart les dépriorisent silencieusement.
Structures de tiers qui paraissent généreuses en bas et pressurent en haut
Particulièrement commun dans les modèles metered. Les premières 100K requêtes sont gratuites, les 400K suivantes pas chères, et d'une façon ou d'une autre au-dessus d'1M/mois le coût par requête triple. Regarde toujours la courbe sur tes 12 mois d'usage projeté, pas juste le bucket d'aujourd'hui.
Markup opaque
Certaines gateways ne divulguent pas ouvertement leur markup. Tu les payes, elles payent le provider, tu ne vois jamais le tarif wholesale. Si tu ne peux pas dire quel est le markup, il est probablement plus large que ce que tu devinerais.
Tiers "gratuits à vie" qui piègent tes données
Un tier gratuit qui ne te laisse pas exporter tes logs de requêtes, l'historique des prompts, ou les données d'observability est un moat de lock-in déguisé en générosité. Vérifie toujours les conditions d'export.
Comment choisir ton modèle de pricing
Trois questions :
1. Quelle est ta dépense et à quelle vitesse grossit-elle ? Petite et flat → le markup va bien. Croît vite → BYOK + pricing flat compound en ta faveur.
2. Tu veux des features de réduction de coût ? Si tu veux smart routing, caching, alertes burn-rate — tu veux une gateway dont le revenu ne baisse pas quand ces features marchent. C'est BYOK + flat, ou OSS self-host.
3. Tu as de la capacité platform engineering ? Si oui, OSS self-host est sur la table. Sinon, élimine-le et choisis parmi les options managées.
Réponds à ces trois, et tu auras ta réponse en 30 secondes.
Le takeaway
Les gateways LLM ne diffèrent pas juste sur les features. Elles diffèrent sur la forme des incitations cuites dans leur pricing. Sur 12-24 mois d'usage, cette structure d'incitation compte plus que n'importe quelle feature précise, parce qu'elle détermine quelles features continuent à s'améliorer et lesquelles stalent silencieusement.
Choisis d'abord le modèle de pricing. Les bonnes features suivent.
Prochain : Vercel AI Gateway en production — forces, limites, alternatives.
Cet article t'a servi ?
Commentaires
Sois le premier à commenter.