Aller au contenu principal

Module 1 — Pourquoi la taille n'est pas toujours la bonne réponse

Le cours sur les grands modèles de langage s'est achevé sur une évidence commode : quand on doute, on prend le plus gros modèle disponible en API et il fait presque toujours l'affaire. C'est vrai, et c'est cher. Ce cours part de la question opposée : sur quelles tâches un modèle de 1 à 4 milliards de paramètres suffit-il ? La réponse n'est pas idéologique, elle se mesure.

Une distinction qui change tout : tâche ouverte, tâche étroite​

Une tâche ouverte exige au modèle un vocabulaire large, du raisonnement multi-étapes, une culture générale et une capacité à répondre à des demandes non anticipées. Écrire un mémoire, résumer un rapport financier de vingt pages, débattre d'une décision produit : tâches ouvertes. Un grand modèle y garde une avance nette.

Une tâche étroite demande une compétence délimitée, exercée sur des entrées qui se ressemblent. Classer un ticket d'assistance dans une des dix catégories métier, en extraire la référence produit, décider s'il faut escalader : tâche étroite. Le vocabulaire tient sur deux pages, le format d'entrée est stable, la sortie est structurée. C'est le terrain naturel du petit modèle — d'autant plus après un affinage sur quelques centaines d'exemples annotés.

Notre fil rouge est précisément une tâche étroite : l'agent de support reçoit un ticket, l'assistant sur son poste doit proposer une catégorie, un résumé en trois lignes et une action recommandée. Rien de génératif audacieux. Un modèle de 3 milliards de paramètres correctement instruit y égale un modèle de 70 milliards à un ou deux points près, pour un coût d'inférence divisé par un facteur 30 à 100.

Les quatre variables qui décident​

Quatre variables suffisent en général à trancher entre petit et grand modèle. Elles sont indépendantes et il faut les mesurer, pas les deviner.

Coût par requête. Sur un grand modèle hébergé, comptez de 0,2 à 5 centimes par requête selon le fournisseur et la longueur des consignes et de la sortie. Sur un petit modèle exécuté localement, le coût marginal d'une requête est nul, le coût est celui du matériel amorti sur la durée. À 100 000 requêtes par mois, l'écart devient une ligne dans le budget.

Latence. Un petit modèle de 3 milliards en 4 bits sur un GPU d'entrée de gamme répond en 200 à 500 ms avec un temps au premier jeton sous les 100 ms. Une API de grand modèle ajoute au minimum 300 à 800 ms de trajet réseau, plus la file d'attente du fournisseur, plus la génération. Pour un assistant qui répond pendant que l'agent lit son ticket, la différence est perceptible.

Confidentialité. Un petit modèle local ne fait sortir aucune donnée du poste. Aucune obligation contractuelle avec le fournisseur, aucun risque de fuite par les journaux du fournisseur, aucune dépendance à un contrat de sous-traitance. Ce point revient au module 9, mais il pèse déjà dans la décision.

Qualité. Sur la tâche étroite, un petit modèle bien choisi et affiné atteint 92 à 96 % du score du grand modèle, parfois davantage. Sur la tâche ouverte, l'écart grimpe vite à 15 ou 20 points. La règle n'est donc pas « petit c'est mieux », c'est « mesurer petit contre grand sur ma tâche à moi ».

Le protocole de comparaison qui décide honnêtement​

Une comparaison honnête suppose un jeu d'évaluation fixe, préparé avant tout choix. Pour notre fil rouge, nous constituons 200 tickets réels anonymisés, chacun avec une catégorie et un résumé de référence rédigés par un expert humain. Ces 200 exemples ne servent jamais à l'affinage ; ils sont le seul juge.

Nous mesurons ensuite quatre grandeurs : exactitude de la classification, similarité du résumé à la référence, temps de réponse au 95ᵉ centile, et coût par 1 000 requêtes. Un tableau à quatre colonnes, deux lignes (petit et grand), et la décision s'éclaire. Nous rejouons cette mesure dans les modules 6 et 10 après quantification et affinage : c'est là que le petit modèle rattrape son retard initial.

Piège fréquent

Beaucoup d'équipes comparent un grand modèle bien instruit à un petit modèle brut, sans affinage ni consignes travaillées. Le grand gagne, on conclut trop tôt. La comparaison qui compte se fait après un investissement équivalent d'ingénierie sur chaque candidat.

En résumé​

  • Une tâche étroite — vocabulaire stable, sortie structurée — est le terrain naturel du petit modèle ; la tâche ouverte reste la chasse gardée du grand.
  • Quatre variables tranchent : coût par requête, latence, confidentialité, qualité mesurée, dans cet ordre pour la plupart des projets métier.
  • Un modèle de 3 milliards en 4 bits sur GPU d'entrée de gamme répond en 200 à 500 ms, pour un coût marginal nul ; l'écart avec une API se compte en dizaines ou centaines pour 100 000 requêtes.
  • La décision se prend sur un jeu d'évaluation fixe de 200 exemples annotés, jamais utilisés pour l'affinage, mesurés dans les mêmes conditions.

Module suivant : le panorama des familles ouvertes de petits modèles, avec leurs licences, leurs langues et ce que dit une fiche de modèle qu'il faut savoir lire.