Price Per Token (prix par token) – Données de tarification des API LLM

• Permet de comparer clairement les tarifs de différents fournisseurs de LLM (par ex. OpenAI, Anthropic, Google) sur une base équivalente (prix par token)
  • Prend en charge des tableaux et graphiques au format fournisseur, modèle, Input ($/M), Output ($/M)
• Dernière mise à jour des données : 26 juillet 2025
• Fournit des données de référence utiles pour l’analyse du rapport coût/performance avant de choisir un modèle spécifique
• En s’abonnant à la newsletter, il est possible de recevoir régulièrement les dernières informations

[GN⁺]

Réactions sur Hacker News

• (Je travaille chez OpenRouter) Nous avons travaillé avec des fournisseurs qui exposent les prix et les informations sur les modèles via une API pour résoudre ce problème, ce qui nous a permis de garder en permanence les informations de la marketplace à jour. Ça me rappelle l’époque où, il y a un an, on partageait encore ces infos dans des conversations sur Slack. Ces derniers temps, la tarification des tokens est devenue très complexe selon les fournisseurs, avec des facteurs comme la longueur du prompt, le caching, etc. En réalité, le point important n’est pas le prix par token au niveau du modèle, mais au niveau de l’endpoint. Par exemple, il arrive souvent que le prix diffère selon l’endpoint pour un même modèle, entre versions rapides/lentes, thinking/non-thinking, etc. Nous avons investi beaucoup d’efforts pour régler tout cela, et le résultat est actuellement public sur OpenRouter (même si je reconnais que le format n’est pas encore organisé de la manière la plus lisible pour consulter surtout les prix)
  • J’ai essayé tout de suite d’en faire une version plus concise et plus facile à lire, merci vraiment pour tout ce travail, je partage le projet llm-pricing
• Je me demande si les données ne sont pas erronées : le prix par token d’entrée pour Google Gemini 2.5 Flash-Lite est à $0.10, mais ici il semble affiché à $0.40, voir le barème officiel
  • Les données ne sont pas fausses, je pense plutôt que j’ai mal lu ton tableau. (Correction : je crois que ma réponse était erronée, ce n’était pas une bonne réponse)
• Ces informations sont excellentes, mais en pratique, côté UX, il faudrait prendre en compte bien plus d’éléments
  • même pour un même modèle, les prix varient selon le fournisseur
  • chaque fournisseur optimise selon des critères différents, comme la vitesse ou le coût
  • un même modèle peut exister en plusieurs versions quantifiées différentes
  • certains, comme l’API Grok, proposent aussi une tarification batch
  • il y a aussi énormément de conditions supplémentaires à filtrer, comme “thinking/non-thinking”, le multimodal ou non, etc.
  • les scores de benchmark sont eux aussi une variable
    Des sites comme artificialanalysis.ai, qui fournissent un blended cost (coût combiné entrée/sortie), donnent déjà quelques repères, mais en réalité, selon l’usage visé, le modèle de tarification Input/Output peut lui aussi varier en permanence. J’attends avec impatience qu’apparaisse un site avec une très bonne UI de comparaison, j’aimerais vraiment que quelqu’un le construise un jour
  • (Je travaille chez OpenRouter) Ce n’est pas très visible sur le site, mais il existe en fait un outil de comparaison de modèles très simple, par exemple : page de comparaison de modèles OpenRouter
  • Je me demande si on pourrait résoudre ce problème en ajoutant au tableau une colonne “provider”, c’est-à-dire l’endroit où l’appel API est réellement exécuté
  • Créer une comparaison équitable semble très difficile. Le mieux est probablement de montrer clairement les trade-offs entre les différentes conditions et de laisser l’utilisateur juger par lui-même. L’idée d’une plateforme façon token exchange, où les utilisateurs publient leurs besoins et où les entreprises rivalisent pour proposer un service adapté, est aussi intéressante. On peut même imaginer une marketplace où chacun partage sa capacité de calcul, mais il faudrait alors traiter à part les problèmes de fraude sur les performances réelles ou de fuite de données
  • J’aimerais vraiment qu’on arrête de donner autant d’importance aux classements de benchmarks, c’est dommage que l’ambiance pousse à une telle obsession de ces comparaisons
• Avant, c’était extrêmement frustrant de devoir parcourir quantité de pages promotionnelles pour trouver les tarifs des nouveaux modèles. Maintenant, c’est pratique de pouvoir tout voir d’un coup d’œil sur OpenRouter
• Le problème fondamental, c’est que les tokens diffèrent selon le fournisseur et le modèle. Ça va bien au-delà du tokenizer : il existe même d’énormes écarts au sein d’un même fournisseur
  • par exemple, pour une entrée image, gpt-4o-mini consomme 10 fois plus de tokens que gpt-4
  • la sortie de gemini 2.5 pro est normalement facturée au token, mais si on utilise structured output, chaque caractère est alors compté comme un token
  • le prix par token reste une information importante, mais ce dont on a réellement besoin, c’est de savoir combien coûte la même requête/réponse selon le modèle, car tous les tokens ne se valent pas
  • Je compte exécuter chaque jour la même expérience et ajouter son coût comme colonne dans le tableau. Par exemple, on pourrait mesurer le résultat obtenu en envoyant à tous les modèles le même prompt : "résume cet article en 200 mots"
  • J’aimerais bien en savoir plus sur cette histoire selon laquelle, avec structured output sur gemini 2.5 pro, caractère = token ; je ne comprends pas bien la différence
• Le site est hors ligne en ce moment, mais je recommande aussi le calculateur de prix LLM de Simon Willison (llm-prices.com)
• Je me demande quels modèles on peut faire tourner en local avec un budget matériel d’environ $2500 ; si ce n’est pas suffisant, quel budget il faudrait, et s’il existe un bon tutoriel expliquant comment faire tourner tout ça localement
  • Si l’usage de LLM en local t’intéresse, ollama.com est un bon point de départ. On peut grosso modo faire correspondre le nombre de paramètres à la quantité de RAM (en Go) ; par exemple, le modèle Deepseek-r1:7b demande environ 7 Go. Plus la fenêtre de contexte est grande, plus il faut de mémoire. Si tu comptes monter une machine IA avec un budget de $2500, je recommanderais une configuration avec beaucoup de mémoire unifiée, comme de la LPDDR5. Lien de référence : Framework AIMax300
  • J’ai acheté il y a 18 mois un Mac Mini M2Pro 32GB pour $1900, et il fait très bien tourner jusqu’à des modèles locaux 40B quantifiés. Quand les modèles locaux sont insuffisants, j’utilise parfois la combinaison Gemini 2.5 flash/pro avec gemini-cli. Il existe aujourd’hui beaucoup de bonnes options, à la fois en API commerciale et en modèles locaux ; le mieux est probablement d’en choisir une et de se concentrer rapidement sur la mise en place
  • Le meilleur choix, c’est d’acheter deux cartes graphiques 3090 d’occasion autour de $600 pièce ; la 3090 reste imbattable en rapport qualité-prix
  • Kimi et deepseek sont parmi les rares modèles dont l’écart de performance reste faible même face aux principaux fournisseurs cloud
  • Avec les modèles de la famille ollama, il suffit parfois d’un CPU correct pour en faire tourner certains sans problème
• Avant, il fallait forcément aller de site en site pour connaître les tarifs selon les fournisseurs ; OpenRouter est une bonne alternative. Les modèles open y sont aussi listés, ce qui permet de se faire une idée du prix et de la taille réels d’un modèle, ainsi que du niveau actuel de subvention dont il bénéficie
  • L’API OpenRouter propose un endpoint permettant de consulter les modèles et leurs prix (documentation de l’API modèles OpenRouter). Son inconvénient est qu’elle ne fournit qu’une seule information de fournisseur par modèle. Ce n’est pas un problème pour les modèles commerciaux, mais pour les modèles open source, les écarts de prix entre fournisseurs peuvent aller de 5 à 10x ; il faut donc surtout l’utiliser à titre indicatif
• J’aimerais qu’il existe une ressource qui combine les données de prix et les informations générales de benchmark pour montrer quel modèle a le meilleur “rapport performance/prix” (score de benchmark / coût par token)
• Les politiques tarifaires de chaque fournisseur sont bien plus complexes qu’une simple facturation input/output
  • la tarification en heures creuses de DeepSeek
  • la tarification batch d’OpenAI/Anthropic
  • la tarification de Google/Grok selon la taille de la fenêtre de contexte
  • la facturation séparée des tokens thinking/non-thinking chez Qwen
  • la tarification par paliers des tokens d’entrée pour Qwen coder
    À ce sujet, voir aussi : X.com paradite_