Coût, latence et arbitrages dans le choix du modèle

Une startup a fait passer 2 millions d'avis clients dans GPT-5 pour les classer en « positif », « négatif » ou « neutre ». Ça a très bien marché. Ça a aussi pris 9 heures et coûté environ 4 000 $. Ils sont passés à un petit modèle rapide. Même travail : 40 minutes, environ 80 $, et une précision en baisse de moins de 1 %.

Toute la leçon tient dans cette histoire. Le plus gros modèle est rarement le bon pour des tâches répétitives à fort volume. Voici comment y réfléchir.

Trois choses que vous arbitrez en permanence

Chaque fois que vous choisissez un modèle, vous équilibrez trois éléments :

• Qualité : la qualité du résultat.
• Latence : le temps d'attente avant la réponse. (La latence, c'est simplement le délai.)
• Coût : ce que vous payez par requête.

Vous pouvez généralement optimiser deux d'entre eux, mais pas les trois. Un gros modèle frontier vous donne la meilleure qualité mais coûte plus cher et tourne plus lentement. Un petit modèle est bon marché et rapide mais peut trébucher sur les tâches difficiles.

Le savoir-faire consiste à ajuster le modèle à la tâche, pas à prendre systématiquement le plus puissant.

Pourquoi les gros modèles sont plus lents et plus chers

Les grands modèles de langage facturent au tokentokenUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète →, un token valant à peu près 3/4 de mot. « Customer service » fait environ 4 tokens.

Les gros modèles ont plus de « paramètres » internes (les réglages ajustés pendant l'entraînement). Plus de paramètres signifie plus de calcul par token, donc plus de coût et plus de délai. Vous payez littéralement pour davantage de calcul sur chaque mot.

Donc un modèle 10 fois plus gros peut coûter 10 à 30 fois plus par token et répondre plusieurs fois plus lentement. Cette différence est invisible sur une requête. Sur 2 millions de requêtes, c'est tout votre budget.

Un exemple concret : la tâche de classification

Rendons la tâche de tri des avis concrète.

Vous avez 2 millions d'avis. Chacun est court (disons 50 tokens en entrée, 1 token en sortie, juste l'étiquette). Vous voulez les taguer positif, négatif ou neutre. C'est de la classification : ranger des éléments dans des catégories fixes.

Voici le prompt que vous enverriez pour chaque avis :

Classify the sentiment of this review as exactly one word:
positive, negative, or neutral.

Review: "Shipping was slow but the product is excellent."

Answer:

C'est une tâche facile. Le sentiment, même les petits modèles le gèrent bien. Vous n'avez pas besoin d'un modèle capable d'écrire de la poésie ou de déboguer du code. Vous avez besoin d'un modèle qui lit trois phrases et sort un mot, vite et pour pas cher.

Faites le calcul

Tarifs approximatifs 2026 (vérifiez toujours les tarifs en cours, ils bougent) :

Pour 2 millions d'avis à ~50 tokens chacun, cela fait 100 millions de tokens en entrée.

• Modèle frontier : à peu près 300 à 1 500 $, et de nombreuses heures.
• Petit modèle : à peu près 10 à 40 $, et une fraction du temps.

Le petit modèle gagne haut la main, à condition que la précision tienne. Et pour une tâche aussi simple, c'est généralement le cas. C'est le point à vérifier, ce qui nous amène aux tests.

Comment décider vraiment : testez, ne devinez pas

Ne supposez jamais que le petit modèle suffit. Mesurez-le. Voici la démarche.

Étape 1 : constituez un petit jeu de test annoté

Annotez vous-même 100 à 200 avis à la main. C'est votre ground truth : les réponses correctes auxquelles vous vous comparez.

Étape 2 : faites tourner les deux modèles sur le jeu de test

from openai import OpenAI
client = OpenAI()

def classify(review, model):
    resp = client.chat.completions.create(
        model=model,
        messages=[{
            "role": "user",
            "content": f"Classify sentiment as one word "
                       f"(positive, negative, neutral): {review}"
        }],
        max_tokens=1,
    )
    return resp.choices[0].message.content.strip().lower()

# Comparer un petit modèle à un grand
for model in ["gpt-5-mini", "gpt-5"]:
    correct = sum(
        classify(r["text"], model) == r["label"]
        for r in test_set
    )
    print(model, correct / len(test_set))

Étape 3 : comparez la précision et décidez

Admettons que le gros modèle obtienne 96 % et le petit 95 %. Cet écart de 1 %, sur une tâche de tri d'avis, ne justifie presque jamais un coût 10 fois supérieur et des traitements plus lents. Partez avec le petit modèle.

Si l'écart était de 96 % contre 78 %, c'est différent. Là, vous garderiez le gros modèle ou vous amélioreriez le prompt du petit.

Une excellente introduction gratuite à cette façon d'évaluer les modèles est le guide Evals d'OpenAI, qui détaille la construction de jeux de test et la notation des sorties.

Des approches malines qui battent le « choisissez-en un »

Vous n'êtes pas obligé de vous engager sur un seul modèle. Certains des meilleurs montages les combinent.

Approche 1 : la cascade (le pas cher d'abord, le cher sur les cas difficiles)

Faites tout passer par le petit modèle. Quand il n'est pas sûr, escaladez vers le gros.

Beaucoup de modèles peuvent renvoyer un signal de confiance, ou vous pouvez en demander un. Si la confiance est faible, envoyez cet élément unique au modèle frontier. Si 90 % des avis sont faciles, vous payez le tarif gros modèle sur seulement 10 % du travail.

Approche 2 : le mode batch pour les tâches non urgentes

Si vous n'avez pas besoin de réponses instantanées, utilisez le traitement par batch. Vous soumettez un gros paquet de requêtes et récupérez les résultats dans une fenêtre donnée (souvent 24 heures) pour environ moitié prix.

OpenAI, Anthropic et Google proposent tous des APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → batch. Pour nos 2 millions d'avis, où personne n'attend en temps réel, le mode batch est parfait : la latence n'a pas d'importance, donc vous l'échangez contre du coût.

Approche 3 : ajustez la latence à l'humain en face

• Un chatbot en direct où une personne attend : la latence compte beaucoup. Prenez un modèle rapide.
• Un rapport nocturne qui tourne pendant que tout le monde dort : la latence compte à peine. Optimisez le coût ou la qualité.

Demandez-vous : « Est-ce qu'un humain fixe un indicateur de chargement ? » Si non, vous avez de la marge pour économiser.

Erreurs fréquentes

Prendre le plus gros modèle par défaut « pour être tranquille ». C'est l'habitude la plus coûteuse des projets IA. Ici, la tranquillité coûte de l'argent réel et ajoute du délai sans aucun gain de qualité sur les tâches faciles.

Tester sur trois exemples et considérer que c'est bouclé. Trois avis ne vous apprennent rien. Il vous faut un jeu de test assez grand pour être fiable, 100+ pour une tâche simple.

Ignorer la longueur de sortie. Les tokens en sortie coûtent souvent plus cher que ceux en entrée. Un modèle qui digresse coûte plus qu'un modèle qui répond en un mot. Pour la classification, plafonnez : max_tokens=1 force une réponse courte et fait économiser.

Oublier que les prompts peuvent sauver les petits modèles. Souvent un petit modèle échoue non parce qu'il est faible, mais parce que le prompt est vague. Ajouter un exemple clair (ce qu'on appelle un exemple few-shot) peut combler l'écart :

Example:
Review: "Arrived broken and support ignored me."
Answer: negative

Now classify:
Review: "Works fine, nothing special."
Answer:

Cet unique exemple peut faire gagner plusieurs points de précision à un petit modèle, souvent assez pour éviter de payer pour un plus gros.

Une checklist de décision simple

Avant de choisir un modèle, demandez-vous :

1. Quelle est vraiment la difficulté de la tâche ? Trier et extraire, c'est facile. L'écriture nuancée et le raisonnement multi-étapes, c'est difficile.
2. Combien de requêtes ? Un cas isolé : la qualité l'emporte. Des millions : le coût et la vitesse dominent.
3. Y a-t-il un humain qui attend ? Oui : priorisez la latence. Non : passez en batch.
4. Quel est le plancher de précision ? Fixez le score minimum acceptable avant de tester, pour ne pas rationaliser après coup.
5. Ai-je réellement mesuré ? Si vous n'avez pas fait tourner un jeu de test, vous devinez.

Appliquez ces questions à la tâche des avis et la réponse est évidente : tâche facile, énorme volume, personne n'attend, le petit modèle passe la barre de précision. Prenez le petit, en mode batch, avec max_tokens=1.

Points clés à retenir

• Ajustez le modèle à la tâche, pas à votre ego. Pour du travail facile et à fort volume comme la classification, un petit modèle rapide bat généralement un modèle frontier sur le coût et la vitesse, avec une perte de qualité quasi nulle.
• Testez toujours sur un jeu annoté de 100+ exemples avant de vous engager. Comparez la précision directement et fixez votre plancher acceptable à l'avance.
• Utilisez le mode batch quand aucun humain n'attend pour réduire les coûts d'environ moitié, et plafonnez la longueur de sortie pour ne pas payer des digressions.
• Pensez aux cascades (modèle pas cher d'abord, escalade des cas difficiles) pour obtenir la qualité d'un gros modèle sur les quelques éléments qui en ont besoin, sans payer pour tous les autres.
• Améliorez le prompt avant de changer de modèle. Un seul exemple few-shot comble souvent l'écart et vous évite complètement la montée en gamme.