Vous souhaitez intégrer un Large Language Model dans une application ? Vous disposez de deux approches stratégiquement opposées.
La première est d’utiliser un modèle Open Source. Votre structure de coûts est dans ce cas liée à l’expertise technique et aux ressources matérielles requises pour exploiter vous-même le modèle de langage.
La seconde est de faire appel à un modèle fourni par un des acteurs du marché comme OpenAI, MistralAI, Anthropic… Il suffit alors d’interroger depuis votre application le modèle via l’API (Application Programming Interface) exposée par le fournisseur. La facturation est liée au modèle et à l’usage en fonction de métriques que nous allons détailler.
Quelles sont les métriques de facturation ?
L’usage d’un LLM est généralement facturé au token, à l’image de la grille fournie par exemple sur le site de MistralAI.
Ce tableau soulève plusieurs questions légitimes :
- Qu’est-ce qu’un token ?
- Cette notion dépend-elle du modèle de langage ?
- Quelle est la différence entre “completion” et “embeddings” ?
- Comment expliquer les différences de prix ?
- Comment comparer les prix de fournisseurs différents ?
Qu’est-ce qu’un token ?
Principes
Les modèles de langage ne manipulent pas directement un texte brut, mais sa représentation sous forme de nombres.
Attribuer un nombre à chaque mot d’une langue est une approche possible, mais qui souffre d’un double inconvénient : d’une part le nombre de mots d’une langue est très important ; d’autre part, des mots sémantiquement proches (comme maison et maisonnette) ont des représentations distinctes alors qu’elles devraient conserver une forme de similarité.
C’est la raison pour laquelle les modèles actuels utilisent des fractions de mots ou tokens, comme des legos, pour décomposer les mots : un mot fréquent est en général conservé en tant que token alors qu’un mot préfixé, suffixé ou plus rare, est décomposé en plusieurs tokens.
Les tokens constituent ainsi le dictionnaire du modèle de langage, dont l’avantage est d’être figé et beaucoup restreint que le nombre de mots d’une langue.
La transformation d’un texte en fractions de mots, elles-mêmes représentées par des nombres, est réalisée par un tokenizer : on parle de tokenisation.
Afin d’illustrer le concept, considérons la phrase :
Voici quelques éléments pédagogiques sur la tokenization…
Les modèles d’OpenAI décomposent cette séquence sous la forme :
'Vo', 'ici', ' quelques', ' él', 'éments', ' p', 'éd', 'agog', 'iques', ' sur', ' la', ' token', 'ization', '...'
Chacun de ces 14 tokens est alors associé à un nombre :
28615, 3457, 45889, 33013, 98942, 281, 15433, 55180, 8467, 1765, 1208, 4037, 2065, 1131
Ce sont ces nombres qui seront ensuite traités par le modèle de langage.
Le zoo des tokenizers
La subtilité est que les modèles de langage ne reposent pas sur un tokenizer “universel”, mais sur leur propre tokenizer.
Les modèles d’embeddings de VoyageAI utilisent par exemple le même tokenizer que le modèle de langage Llama 2, qui est distinct de celui des modèles d’OpenAI.
La phrase prise en exemple sera ainsi décomposée non pas en 14 mais en 15 tokens :
'Vo', 'ici', 'quelques', 'él', 'é', 'ments', '_p', 'éd', 'agog', 'iques', '_sur', '_la', '_token', 'ization', '…'
La divergence provient ici de la manière de décomposer le mot éléments.
Si le réflexe est de comparer les fournisseurs en fonction de leur coût au token, le constat précédent montre qu’il ne s’agit que d’une approximation puisqu’un même texte sera associé à un nombre de tokens différent en fonction des modèles ! Nous reviendrons sur ce point dans la suite du blog.
La nature des modèles
Modèles d’embeddings et modèles génératifs
Les modèles d’embeddings sont entraînés pour produire « l’empreinte sémantique” d’un texte court. Il s’agit d’un vecteur de nombres, l’embedding, de dimension fixe dépendant du modèle. La variable est la taille du texte en entrée, quantifiée en tokens. Conceptuellement, la similarité de deux contenus textuels se traduit par la proximité de leur représentation vectorielle. Les embeddings peuvent être utilisés par exemple pour effectuer des regroupements de textes (clustering) ou récupérer les fragments de documentation les plus pertinents par rapport à une question (voir l’article sur le RAG).
La dénomination “Chat Completion” fait référence aux modèles génératifs : les instructions sont passées en entrée par le biais d’un prompt qui est interprété pour générer en sortie une réponse. Les cas d’usage, largement démocratisés par ChatGPT, sont multiples : réponse à une question ouverte, réponse à une question en fonction d’un contexte (cf. RAG), résumé d’un texte, traduction, production de code informatique… Les entrées / sorties sont de tailles variables, mesurées en tokens, comme mentionné dans l’exemple de facturation de MistralAI (input vs. output).
Différences de coûts
Les modèles d’embeddings impliquent par nature des traitements moins complexes que les modèles génératifs. Il en résulte un coût au token beaucoup moins élevé (de 2 à 240 fois moins cher dans notre exemple). C’est précisément ce qui permet le traitement de larges corpus : les documents sont découpés en passages de taille réduite qui sont ensuite représentés sémantiquement par leur embedding.
Si les modèles génératifs sont plus chers, il existe de fortes disparités de coûts en fonction de leur performance au sens large. Les modèles les plus économiques sont destinés à des tâches de génération de texte basique ou de classification. Les plus évolués ont des capacités développées de transformation de textes, de production de code ou de raisonnement. À noter que pour un même modèle, la politique commerciale traduit généralement le fait que la génération par prédiction est plus contraignante que l’interprétation du prompt.
Éléments de benchmark
L’ambiguïté du token
Le nombre de tokens n’est pas une caractéristique intrinsèque d’un texte puisqu’il dépend du modèle de langage. Nous avons vu en effet qu’il variait en fonction du tokenizer utilisé.
La comparaison des modèles à partir de leur prix au token fournit un ordre de grandeur. L’estimation précise des coûts nécessiterait, dans un contexte donné, le décompte pour chaque modèle du nombre de tokens en jeu et l’application de la grille tarifaire associée.
La notion de token est donc moins facilement appréhendable et calculable que le nombre de mots ou de caractères d’un texte. C’est pourquoi nous proposons ici une normalisation basée sur un coût au caractère.
L’estimation fournie repose sur l’emploi de textes généralistes en langues française et anglaise. L’objectif est d’analyser l’impact de la langue et de proposer une métrique commune d’estimation des coûts. Bien entendu, les métriques sont sensibles à la nature des textes soumis / générés et ne reflètent pas nécessairement le cas de corpus spécifiques ou de champs lexicaux spécialisés.
Méthodologie
Évaluation des embeddings
Nous avons constitué deux corpus en français et en anglais issus de pages Wikipédia. Afin d’obtenir un vocabulaire représentatif et varié, les thématiques suivantes ont été intégrées : philosophie, histoire, géographie, mathématiques, physique, religion, art, médecine, droit, cuisine, écologie, technologie, sport, informatique, littérature, journalisme.
Évaluation des modèles génératifs
Le parti pris a été d’élaborer un jeu de questions dans les deux langues sur les thématiques précédentes. Le prompt consiste à soumettre la question au modèle en lui demandant de générer librement une réponse.
Remarque pratique
Les modèles génératifs sont plus ou moins prolixes. Pour caricaturer, vous obtiendrez le même coût si un modèle deux fois plus cher fournit une réponse “deux fois plus courte”. Il est courant de définir une taille maximale de réponse, ce qui permet de fixer un majorant du coût.
Résultats
Evaluation des embeddings
Le tableau suivant synthétise la comparaison brute des tarifs par million de tokens :
| Fournisseur | Modèle | 1M tokens ($) | Facteur |
| OpenAI | text-embedding-3-small | 0,02 | 1 |
| OpenAI | text-embedding-ada-002 | 0,1 | 5 |
| MistralAI | mistral-embed | 0,1 | 5 |
| VoyageAI | voyage-2 | 0,1 | 5 |
| VoyageAI | voyage-large-2 | 0,12 | 6 |
| OpenAI | text-embedding-3-large | 0,13 | 6,5 |
L’estimation du ratio par modèle et par langue du nombre de caractères par token est la suivante :
| Langue | Fournisseur | Caractères par token |
Français | OpenAI | 3,72 |
| MistraAI | 3,35 | |
| VoyageAI | 3,50 | |
Anglais | OpenAI | 4,68 |
| MistraAI | 4,17 | |
| VoyageAI | 4,15 |
Il en résulte une estimation du coût par caractère :
Fournisseur | Modèle | 100M caractères ($) | Facteur | ||
| Français | Anglais | Français | Anglais | ||
| OpenAI | text-embedding-3-small | 0,54 | 0,43 | 1 | 1 |
| OpenAI | text-embedding-ada-002 | 2,69 | 2,14 | 5 | 5 |
| MistralAI | mistral-embed | 2,99 | 2,4 | 5,56 | 5,61 |
| VoyageAI | voyage-2 | 2,85 | 2,41 | 5,31 | 5,64 |
| VoyageAI | voyage-large-2 | 3,42 | 2,89 | 6,37 | 6,76 |
| OpenAI | text-embedding-3-large | 3,49 | 2,78 | 6,50 | 6,50 |
Commentaires
- Biais de la langue : pour un même nombre de caractères, le coût des embeddings sur un texte en français est plus élevé que pour un texte en anglais.
- Impact de la tokenization : les tokenizers de MistralAI et VoyageAI génèrent statistiquement 5 à 10% plus de tokens que le tokenizer d’OpenAI en Français et 10 à 15% plus de tokens en Anglais.
Valeurs relatives / valeurs absolues
On observe jusqu’à un facteur 6,5 entre les coûts des modèles d’embeddings. Il n’est pas inutile de ramener les prix à des cas d’usage concrets.
Considérons qu’une page écrite en français contienne 2500 caractères. Avec un ratio approximatif de 3,5 caractères par token, on obtient un ordre de grandeur de 750 tokens par page. Avec un modèle de facturation de 0,1$ par million de tokens, il est possible pour 1$ de créer des embeddings sur plus de 13 000 pages.
Concernant les embeddings, le prix n’est donc pas le facteur déterminant. Le choix du modèle repose avant tout sur sa performance pour une tâche et un contexte de langue donnés.
Evaluation des modèles génératifs
Grille des tarifs par un million de tokens :
Fournisseur | Modèle | 1M tokens ($) | Facteur | ||
| input | output | input | output | ||
MistralAI | open-mistral-7b | 0,25 | 0,25 | 1 | 1 |
| open-mixtral-8x7b | 0,7 | 0,7 | 2,8 | 2,8 | |
| mistral-small-latest | 2 | 6 | 8 | 24 | |
| mistral-medium-latest | 2,7 | 8,1 | 10,8 | 32,4 | |
| mistral-large-latest | 8 | 24 | 32 | 96 | |
OpenAI | gpt-3.5-turbo-0125 | 0,5 | 1,5 | 2 | 6 |
| gpt-4 | 30 | 60 | 120 | 240 | |
| gpt-4-32k | 60 | 120 | 240 | 480 | |
Anthropic | claude 2.1 | 8 | 24 | 32 | 96 |
| claude haiku | 0,25 | 1,25 | 1 | 5 | |
| claude sonnet | 3 | 15 | 12 | 60 | |
| claude opus | 15 | 75 | 60 | 300 | |
Dans notre cas d’usage de questions / réponses, l’estimation du nombre de caractères par token en fonction de la langue est la suivante :
| Fournisseur | Modèle | Caractères par token | |||
| Français | Anglais | ||||
| Input | Output | Input | Output | ||
MistralAI | open-mistral-7b | 2,7 | 3,6 | 3,5 | 4,9 |
| open-mixtral-8x7b | 2,7 | 3,4 | 3,5 | 4,7 | |
| mistral-small-latest | 2,9 | 3,4 | 3,8 | 4,6 | |
| mistral-medium-latest | 2,9 | 3,6 | 3,4 | 4,5 | |
| mistral-large-latest | 2,9 | 3,4 | 3,8 | 4,6 | |
OpenAI | gpt-3.5-turbo-0125 | 2,7 | 3,9 | 3,3 | 5,6 |
| gpt-4 | 2,7 | 3,9 | 3,4 | 5,6 | |
| gpt-4-32k | 2,7 | 3,9 | 3,4 | 5,6 | |
Anthropic | claude 2.1 | 2,5 | 3,4 | 3,1 | 5,2 |
| claude haiku | 2,4 | 3,4 | 3,2 | 4,9 | |
| claude sonnet | 2,4 | 3,4 | 3,2 | 4,9 | |
| claude opus | 2,4 | 3,4 | 3,2 | 4,9 | |
On en déduit une version “normalisée” du coût par caractère :
Fournisseur | Modèle | 10M caractères ($) | |||
| Français | Anglais | ||||
| input | output | input | output | ||
MistralAI | open-mistral-7b | 0,9 | 0,7 | 0,7 | 0,5 |
| open-mixtral-8x7b | 2,6 | 2,0 | 2,0 | 1,5 | |
| mistral-small-latest | 6,8 | 17,5 | 5,2 | 13,1 | |
| mistral-medium-latest | 9,5 | 22,4 | 8,0 | 17,9 | |
| mistral-large-latest | 27,3 | 70,8 | 20,9 | 51,7 | |
OpenAI | gpt-3.5-turbo-0125 | 1,9 | 3,9 | 1,5 | 2,7 |
| gpt-4 | 111,2 | 155,5 | 89,2 | 108,1 | |
| gpt-4-32k | 222,5 | 311 | 178,5 | 216,2 | |
Anthropic | claude 2.1 | 32,6 | 71,3 | 25,8 | 46,5 |
| claude haiku | 1,1 | 3,7 | 0,8 | 2,5 | |
| claude sonnet | 12,6 | 44,0 | 9,3 | 30,4 | |
| claude opus | 63,1 | 219,9 | 46,3 | 151,8 | |
Ou encore en termes de ratio entre modèles :
Fournisseur | Modèle | Facteur (base caractère) | |||
| Français | Anglais | ||||
| input | output | input | output | ||
MistralAI | open-mistral-7b | 1 | 1 | 1 | 1 |
| open-mixtral-8x7b | 2,9 | 2,9 | 2,9 | 3 | |
| mistral-small-latest | 7,6 | 25,0 | 7,4 | 26,2 | |
| mistral-medium-latest | 10,6 | 32,0 | 11,4 | 35,8 | |
| mistral-large-latest | 30,3 | 101,1 | 29,9 | 103,4 | |
OpenAI | gpt-3.5-turbo-0125 | 2,1 | 5,6 | 2,1 | 5,4 |
| gpt-4 | 123,6 | 222,1 | 127,4 | 216,2 | |
| gpt-4-32k | 247,2 | 444,3 | 255,5 | 432,4 | |
Anthropic | claude 2.1 | 36,2 | 101,9 | 36,9 | 93 |
| claude haiku | 1,2 | 5,3 | 1,1 | 5 | |
| claude sonnet | 14,6 | 62,9 | 13,3 | 60,8 | |
| claude opus | 70,1 | 314,1 | 66,1 | 303,6 | |
Commentaires
- Biais de la langue : on retrouve sans surprise l’impact de la langue, l’Anglais étant plus économe en tokens que le Français.
- Impact de la tokenization : les modèles d’OpenAI requièrent statistiquement moins de tokens que les autres modèles.
Valeurs relatives / valeurs absolues
On observe jusqu’à un facteur 444 entre les prix des modèles.
Il est donc nécessaire de bien qualifier votre cas d’usage pour déterminer le modèle le plus performant économiquement. Il est par exemple inutile de choisir le modèle le plus “puissant” d’un fournisseur (et par suite le plus cher) pour effectuer les tâches les plus simples.
Bien entendu, l’asymétrie du prix en entrée et en sortie est d’autant plus sensible que vous sollicitez la partie générative. Une tâche de classification sera peu sensible au surcoût en sortie, contrairement à une tâche de traduction.
Conclusion
La compréhension des modèles de facturation des LLM est essentielle pour estimer les coûts associés à un projet.
Nous avons vu que la notion de token, unité de base de la facturation, dépend intrinsèquement du modèle de langage. Une approche pragmatique consiste à raisonner en coût par caractère, ce qui fournit un ordre de grandeur plus intuitif, même s’il ne dispense pas d’une analyse plus fine dans un contexte applicatif et linguistique donné.
Les modèles d’embeddings présentent un coût à l’usage très faible. La problématique est ici de choisir le modèle le plus adapté à la tâche, la langue et éventuellement le domaine.
A contrario, le choix d’un modèle génératif est plus délicat car les écarts de coûts sont significatifs. Le réflexe est souvent de sélectionner le modèle actuel le plus puissant, mais il est essentiel d’analyser les besoins réels pour faire le bon choix.
Vous vous demandez quels sont les LLM les plus adaptés à vos usages ? Comment trouver le meilleur compromis coût / performance ? Notre équipe se tient à votre disposition pour analyser vos cas d’usage et vous recommander l’approche la plus pertinente.
