Si vous n'avez jamais utilisé qu'un seul fournisseur LLM, le prix affiché sur la page tarifaire de ce fournisseur vous semble probablement être le prix. Ce n'est pas le cas. C'est le prix de détail, et comme la plupart des prix de détail, il intègre beaucoup de marge et de structure. Les agrégateurs gagnent leur vie en s'attaquant précisément à cette structure.
Pourquoi les prix directs affichés sont élevés
La tarification directe comporte des coûts qui n'ont rien à voir avec l'exécution du modèle. Lorsque vous achetez directement auprès d'un fournisseur, vous payez aussi pour :
•Des engagements minimaux. Certains fournisseurs exigent un solde prépayé ou une dépense engagée avant de vous accorder leur meilleur tarif. Les petites équipes atteignent rarement ces paliers.
•Un fournisseur, un contrat. Chaque fournisseur a sa propre inscription, sa propre facturation, sa propre devise. Gérer trois fournisseurs signifie trois factures et trois moyens de paiement.
•Aucune concurrence au sein de votre propre facture. Lorsque vous êtes lié à un seul fournisseur, ce fournisseur n'a aucune raison de vous accorder une remise. Vous payez son tarif ou vous partez.
•Des limites de débit fixées pour leur protection, pas pour votre confort.
Les agrégateurs existent parce qu'ils peuvent acheter de la capacité en amont en volume et répercuter une partie de la remise. Ils vous permettent aussi de déplacer vos dépenses entre fournisseurs, ce qui constitue le véritable levier : si le modèle A devient moins cher le mois prochain, vous basculez votre trafic sans changer de fournisseur.
Le calcul, avec des chiffres ronds
Je vais utiliser des chiffres volontairement simples pour que la logique soit claire. Les prix réels changent constamment, mais l'arithmétique reste la même.
Supposons qu'un fournisseur affiche un modèle à 2,50 $ par million de tokens en entrée et 10,00 $ par million de tokens en sortie. Une charge de travail typique, par exemple un outil de synthèse de tickets support traitant 10 millions de tokens en entrée et 4 millions de tokens en sortie par mois, coûterait :
Direct : (10M x 2,50 $) + (4M x 10,00 $) = 25 $ + 40 $ = 65,00 $ / moisUn agrégateur ayant négocié des tarifs de volume pourrait proposer le même modèle à environ un quart du prix affiché, soit 0,60 $ par million en entrée et 2,40 $ par million en sortie :
Agrégé : (10M x 0,60 $) + (4M x 2,40 $) = 6,00 $ + 9,60 $ = 15,60 $ / moisCela représente environ 49 $ économisés par mois sur une seule charge de travail modeste, soit une réduction d'environ 76 %, avant même de toucher à quoi que ce soit d'autre. Multipliez les nombres de tokens par un ordre de grandeur et les économies absolues suivent la même échelle.
Le point clé n'est pas ces chiffres précis. Le point est que l'écart entre le « prix affiché » et le « prix de volume » est réel, et le rôle d'un agrégateur est de se situer dans cet écart et de vous en reverser une partie.
Les autres coûts cachés dans les petites lignes
Le prix par token est ce qui attire l'œil, mais ce n'est pas toute la facture. Trois choses prennent les gens au dépourvu :
La tarification des hits de cache. Certains modèles appliquent une remise aux tokens qui touchent un cache de prompt. Si un fournisseur facture plein tarif les entrées mises en cache et qu'un autre les facture à 10 % de ce prix, une charge de travail avec des prompts répétitifs peut voir son coût varier considérablement, même à prix affiché identique. Renseignez-vous avant de vous engager.
Les frictions de devise et de paiement. Acheter auprès d'un fournisseur dont la facturation est dans une devise ou une région que votre carte n'apprécie pas ajoute des frais de conversion et des maux de tête liés aux échecs de paiement. Une facture unique d'agrégateur dans votre propre devise élimine ce problème.
Les limites de débit comme coût caché. Un modèle bon marché que vous ne pouvez appeler que 10 fois par minute n'est pas bon marché ; vous devrez construire une logique de retry et de mise en file d'attente pour compenser, et c'est du temps d'ingénierie. Les limites de débit ont leur place dans la comparaison des prix, même si elles ne figurent pas sur la page tarifaire.
Un estimateur de coût rapide
Estimer les dépenses avant de construire est simple une fois que vous avez les chiffres. Voici un petit script Python dans cet esprit :
def monthly_cost(input_tokens, output_tokens, in_price, out_price):
# prices are per million tokens
return (input_tokens / 1e6) * in_price + (output_tokens / 1e6) * out_price
# Direct list price
direct = monthly_cost(10_000_000, 4_000_000, 2.50, 10.00)
# Aggregator price (example values)
aggregated = monthly_cost(10_000_000, 4_000_000, 0.60, 2.40)
print(f"Direct: ${direct:.2f}")
print(f"Aggregated: ${aggregated:.2f}")
print(f"Saved: ${direct - aggregated:.2f}")Passez vos vrais nombres de tokens dans ce script avec vos vrais prix. C'est le seul chiffre qui compte.
Là où les agrégateurs ne vous font pas économiser d'argent
Je me dois d'être franc sur les limites. Un agrégateur est un revendeur. Certains modèles ne sont pas du tout disponibles via des revendeurs, et pour certains modèles de niche, la marge d'un agrégateur peut être pire que l'achat direct. Les économies sont les plus importantes sur les modèles généralistes populaires où des remises de volume existent. Pour un modèle exotique que vous appelez rarement, la différence est négligeable.
De plus, un prix moins cher ne vaut rien si la fiabilité de l'agrégateur est mauvaise. Une économie de 30 % qui vous achète un endpoint instable coûte plus de 30 % une fois que vous tenez compte des retries, des tickets de support et de votre propre temps. Prix et fiabilité forment une seule décision, pas deux.
SiCore TokenWorks est une version simple de ce modèle : compatible OpenAI, à l'usage, avec un catalogue de modèles populaires de DeepSeek, Qwen, ERNIE, Doubao, Spark et Pangu aux côtés de GPT-4o, Claude et Gemini, affichés bien en dessous des tarifs officiels par token.