Clawy / Guides / Tarifer une API d'IA payante

Comment tarifer une API d'IA payante sans perdre d'argent

Si vous revendez ou encapsulez GPT ou Claude à un prix forfaitaire par appel, un seul gros prompt peut vous coûter plus que ce que vous facturez. Voici le calcul et deux façons d'y remédier.

Vous avez encapsulé un LLM, mis derrière un endpoint, et facturez un prix forfaitaire net — disons $0,15 par appel. Clair pour vos clients, facile à raisonner. Le problème : le modèle en dessous ne facture pas par appel. Il facture au token, et les tokens augmentent avec la taille du prompt et de la réponse. Sur une petite requête, vous empochez une grosse marge. Sur une grande, vous pouvez payer plus que ce que vous avez encaissé — et vous ne le remarquerez qu'à l'arrivée de la facture du fournisseur.

Pourquoi le forfait fuit

Les modèles facturés au token comptent séparément l'entrée (le prompt envoyé) et la sortie (ce que le modèle génère). Selon les tarifs officiels de Claude :

Votre coût pour un appel est simplement :

cost = (input_tokens × input_price + output_tokens × output_price) / 1,000,000

Prenez Opus 4.8 à un forfait de $0,15/appel. La sortie seule revient à $25 par million de tokens — donc à peine 6 000 tokens de sortie coûtent $0,15, dévorant tout votre prix avant même d'avoir compté un seul token d'entrée. Laissez un client envoyer un document de 100 000 tokens en contexte et demander une longue réponse, et cet appel peut vous coûter plusieurs fois ce que vous avez facturé. Multipliez par quelques gros utilisateurs et le produit "rentable" tourne à perte.

Trouvez votre seuil de rentabilité avant de lancer

Le chiffre qui compte est le plus grand prompt que vous pouvez servir avant qu'un appel ne coûte plus que ce que vous facturez. À taille de sortie fixe, la taille d'entrée au seuil de rentabilité est :

break_even_input_tokens = (price × 1,000,000 − output_tokens × output_price) / input_price

Pour Opus à $0,15 avec une réponse de 800 tokens : (0.15 × 1,000,000 − 800 × 25) / 5 = 26,000 tokens d'entrée. Au-delà de ~26k tokens de prompt, chaque appel perd de l'argent. Si votre trafic réel le dépasse régulièrement, le forfait est le mauvais modèle — ou votre prix est trop bas.

Solution 1 — plafonner l'entrée et la sortie

Si vous voulez garder le forfait (les clients adorent sa prévisibilité), bornez les deux côtés pour que l'appel dans le pire cas ne dépasse pas votre prix :

• Plafonnez la taille de l'entrée. Rejetez ou tronquez les prompts au-dessus d'une limite de tokens/caractères — et faites-le avant de facturer ou d'appeler le modèle, pour qu'une requête trop grande ne vous coûte rien.
• Plafonnez la sortie (max_tokens). Une valeur par défaut généreuse borne quand même le côté coûteux. À $25/1M, chaque 1 000 tokens de sortie coûtent $0,025.
• Dimensionnez les plafonds avec le calcul ci-dessus. Choisissez des limites où worst-case cost < price avec une marge pour les reprises, les fallbacks et les ratés de cache de prompts (prévoyez ~25–40 % de marge).
• Annoncez les limites. Mettez les plafonds entrée/sortie dans votre schéma d'API pour que les clients s'auto-limitent au lieu de subir des rejets surprises.

C'est exactement ainsi qu'un endpoint à prix fixe reste solvable : le prix est fixe, mais le travail derrière est borné pour qu'il ne plonge jamais dans le rouge.

Solution 2 — tarification à l'usage

L'alternative est d'arrêter de prétendre que les appels sont uniformes et de facturer ce qu'ils consomment réellement : compter les tokens (souvent avec un multiple de marge sur votre coût) ou facturer des prix par paliers selon la taille de la requête. Vous renoncez à la simplicité d'un nombre rond, mais vous ne perdez jamais d'argent sur une grosse requête car le prix suit le coût. L'usage est le bon choix quand les tailles de prompt varient beaucoup ou que vous servez des charges à grand contexte.

N'oubliez pas les coûts cachés

• Reprises & fallbacks. Un appel échoué qui réessaie sur un second modèle peut doubler la dépense de tokens pour une seule requête visible par le client.
• Ratés de cache de prompts. Le cache réduit le coût du préfixe répété de ~90%, mais seulement sur les hits — un invalidateur silencieux (un horodatage dans le system prompt, du JSON non trié) signifie que vous payez le plein tarif à chaque fois.
• Tokens de réflexion / raisonnement. Si vous activez la réflexion étendue/adaptative, ces tokens sont aussi facturés comme sortie.

Quel que soit le modèle choisi, la discipline est la même : connaissez votre coût par appel, votre seuil de rentabilité, et bornez le pire cas avant qu'il n'atteigne un client payant.