Cost-per-Task plutôt que scores de benchmark : la méthode de 30 minutes qui décide vraiment de votre changement de modèle

TL;DR : Les tableaux de benchmarks comparent les modèles sur des tâches tierces. Mais vos décisions se prennent sur vos tâches. Avec cinq vraies tâches, deux séries de mesures et un mini-tableau par catégorie de tokens, vous obtenez votre propre calcul du Cost-per-Task en 30 minutes. Ainsi, vous ne changez de modèle que s'il est plus performant en euros et en secondes, et pas seulement en termes de points.

Pourquoi le tableau de benchmarks seul suffit rarement

Les scores publics comme GPQA ou MMLU sont utiles pour une première présélection. Mais pour justifier le remplacement d'un modèle en production, il leur manque trois éléments : ils ne connaissent pas la longueur de vos prompts, ils ignorent la "taxe de contexte" lors des sessions longues, et ils ne disent absolument rien sur le rapport qualité-prix par tâche réelle.

Sur le papier, un modèle peut avoir 3 points d'avance, mais s'avérer plus cher ou plus lent dans votre stack technique — par exemple, parce qu'il nécessite plus de tokens de sortie (output tokens) par réponse ou parce qu'il gère moins bien votre cache. D'où la règle d'or : vos propres mesures, vos propres calculs.

La méthode des 30 minutes en 5 étapes

Sélectionner cinq vraies tâches : prenez les cinq dernières requêtes en production de votre workflow, pas des exemples issus de tutoriels.
Mêmes prompts, les deux modèles : testez chaque tâche une fois avec l'ancien modèle, une fois avec le nouveau, en gardant les mêmes paramètres (température, max tokens).
Noter quatre valeurs par exécution : tokens d'entrée (input), tokens de sortie (output), temps en secondes, et si la réponse est correcte (oui/non).
Calculer le Cost-per-Task : divisez le nombre de tokens par 1 000 000, multipliez par le prix du token correspondant, puis additionnez le tout pour chaque tâche.
Comparer après 5 tâches : calculez les médianes — et non les moyennes, pour éviter que d'éventuelles valeurs aberrantes ne faussent le tableau.

Le protocole tient dans un seul tableau. Vous n'avez besoin de rien de plus.

Exemple de calcul avec des prix réels

Le modèle Hy-4 Preview (Tencent, 770B au total / 49B paramètres actifs, licence Apache 2.0) coûte via son API 0,834 USD par million de tokens d'entrée et 2,001 USD par million de tokens de sortie. Voici ce que donne une tâche de support client typique avec 8 000 tokens en entrée et 2 000 en sortie :

Modèle	Input	Output	Cost-per-Task
Hy-4 Preview	8 000 × 0,834 $/M = 0,0067 $	2 000 × 2,001 $/M = 0,0040 $	≈ 0,011 $
Modèle Frontier (Référence)	8 000 × 1,25 $/M = 0,0100 $	2 000 × 10 $/M = 0,0200 $	≈ 0,030 $

Pour 2 000 tâches par mois, nous arrivons à environ 22 USD contre 60 USD. Le changement est rentable à condition que le fond des réponses aux cinq tâches soit au moins d'aussi bonne qualité — mesuré sur votre propre corpus, et non sur un leaderboard.

Si vous effectuez des mesures en local, appliquez la même logique avec le temps matériel au lieu des prix des tokens : Qwen3.8-27B en GGUF nécessite une empreinte mémoire d'environ 11,8 Go et tourne à environ 40 tokens/s sur une RTX 5060 Ti — il s'agit également d'un chiffre de "Cost-per-Task", mais exprimé en secondes plutôt qu'en dollars.

Un protocole prêt à copier

task_01:
  prompt_hash: a1b2c3
  model_old: {input: 8000, output: 2000, seconds: 6.4, correct: true}
  model_new: {input: 8000, output: 1700, seconds: 4.1, correct: true}
  cost_old: 0.030
  cost_new: 0.010
task_02: ...
# Calculer les médianes à la fin, pas les moyennes

Erreurs fréquentes

Séries trop courtes : en dessous de cinq tâches, la variance est plus grande que la différence entre les modèles. Il faut mesurer, pas deviner.
Paramètres modifiés : si vous touchez à la température pour le nouveau modèle, vous évaluez le modèle et non le changement dans des conditions identiques.
Oubli de la taxe de contexte : les sessions longues gonflent le nombre de tokens d'entrée. C'est précisément pour cela qu'il faut compter par tâche, et non faire une estimation globale par modèle.
Ne comparer que les dollars : pour les workflows critiques en termes de latence, la colonne des secondes est souvent le facteur décisif.

FAQ

De combien de tâches ai-je besoin pour une estimation fiable du Cost-per-Task ? Cinq tâches constituent le strict minimum, dix offrent plus de confort. La raison est simple : le nombre de tokens varie fortement selon le type de tâche, et la médiane sur cinq exécutions lisse bien mieux ces variations qu'une moyenne sur deux. Si aucun schéma cohérent n'émerge après cinq tâches, c'est que votre sélection était trop hétérogène — il faut alors séparer vos tests en deux séries (ex: classification courte vs. résumé long).

Que faire si le nouveau modèle génère un nombre différent de tokens pour le même prompt ? C'est normal et cela fait partie de la mesure : notez séparément les tokens d'entrée et de sortie pour chaque modèle. Le calcul du Cost-per-Task l'absorbe automatiquement, car les deux valeurs sont incluses dans la somme finale. En revanche, vous ne devez comparer le temps en secondes qu'à longueur de prompt équivalente, sinon vous mélangez les effets de latence et les spécificités du modèle.

La méthode fonctionne-t-elle aussi pour les modèles locaux (self-hosted) ? Oui. Au lieu de calculer en dollars par token, vous calculez en secondes par tâche par rapport à une fenêtre matérielle fixe. Une exécution locale avec une empreinte de 11,8 Go tournant à 40 tokens/s est directement comparable au temps de réponse d'une API, car les deux aboutissent à la même unité (secondes par tâche). L'avantage majeur : le comportement de votre cache et la taxe de contexte sont mesurés en conditions réelles.

Comment dois-je gérer le cache — dois-je le désactiver ? Non, au contraire : effectuez vos mesures dans le même mode que celui utilisé en production. Le Prompt Caching fait partie intégrante du profil de coûts de votre infrastructure. Notez simplement dans le tableau de votre protocole si le cache était "chaud" (warm) ou "froid" (cold), afin de comparer des pommes avec des pommes. Un seul démarrage à froid par modèle suffit comme valeur de référence.

Quand est-il pertinent de refaire ces mesures par la suite ? À chaque mise à jour majeure (major release) du nouveau modèle ou lors d'une modification de sa grille tarifaire — ces deux événements étant rares, vous mesurerez au maximum une fois par trimestre. Entre-temps, la première mesure suffit, car les prix des tokens et l'architecture des modèles ne fluctuent pas tous les jours. Toutefois, si la longueur de vos prompts évolue de manière drastique en production, vous devrez refaire une série de tests pour actualiser votre courbe de Cost-per-Task.

Sources

Tencent Hy-4 Preview (données du modèle et prix) : https://www.youtube.com/watch?v=Dmlszfz2LjM
Deltafin — Layer-Streaming pour 2,8T Kimi K3 sur NVMe de PC portable : https://github.com/argonautlabsai/deltafin
Mesures Qwen3.8-27B GGUF (Empreinte mémoire, tok/s) : Kontext-Studios-Daily-Intel-Run #175
Tarification API Google Gemini (Prix de référence) : https://ai.google.dev/gemini-api/docs/pricing

Cost-per-Task plutôt que scores de benchmark : la méthode de 30 minutes qui décide vraiment de votre changement de modèle