Les entreprises affinent de minuscules LLM sur une seule tâche plutôt que d'appeler les API des modèles phares

Confier à un modèle de langage phare, via API, la tâche « classer cette demande dans l'une des dix catégories », c'est un peu comme embaucher un prix Nobel pour répondre aux appels répétitifs d'un centre d'appels. Habr ouvre sur cette analogie son analyse d'une pratique de plus en plus courante dans l'IA d'entreprise : entraîner un minuscule modèle sur une tâche étroite et renoncer au géant généraliste. Il s'agit de modèles de 0,5–3 Md de paramètres, contre des centaines de milliards pour les modèles phares. Après quantification, un tel modèle occupe de quelques centaines de mégaoctets à quelques gigaoctets et tourne sur une carte graphique peu coûteuse, parfois même sur un processeur classique.

Mise en garde importante : le fragment de l'article dont nous disposons ne contient aucun benchmark propre. Les chiffres ci-dessous sont donc des ordres de grandeur typiques de ce genre de projets, et non les résultats d'une entreprise précise.

Pourquoi un modèle phare est ici superflu

Un modèle généraliste sait écrire du code, raisonner et tenir une conversation. Classer des demandes ou vérifier une structure JSON ne requiert aucune de ces capacités. Pourtant, on les paie à chaque requête : en argent, en latence et en dépendance à un fournisseur externe. Avec des millions d'appels identiques par jour, la facture croît de façon linéaire, et l'écart de prix entre un grand et un petit modèle devient un poste budgétaire à part entière.

Une tâche étroite a un espace de réponses fermé. Lorsqu'il faut choisir l'une des dix catégories ou confirmer qu'une réponse respecte un schéma, le modèle n'a pas besoin de tout savoir. Il lui suffit d'apprendre correctement la distribution de ces données précises. Une architecture compacte y suffit, comme les familles Llama 3.2 (1B et 3B), Qwen2.5 (à partir de 0,5B), Gemma ou Phi.

Comment cela se passe en pratique

Le parcours type est le suivant. L'équipe fait d'abord passer une partie des données réelles dans un modèle puissant pour obtenir une annotation de référence, que des humains vérifient. Elle affine ensuite le petit modèle sur ce jeu de données, le plus souvent avec LoRA ou QLoRA : seul un petit ensemble de poids d'adaptateurs est mis à jour. Une seule carte et quelques heures suffisent. Cette méthode s'appelle la distillation de connaissances : le grand modèle joue le rôle d'enseignant, le petit reprend son comportement sur un périmètre restreint.

Voici les caractéristiques pratiques qui motivent cette approche :

• taille : 0,5–3 milliards de paramètres au lieu de centaines de milliards ;
• mémoire : de quelques centaines de mégaoctets à quelques gigaoctets après quantification en 4–8 bits ;
• matériel : une seule carte graphique peu coûteuse ou un CPU ;
• latence : quelques dizaines de millisecondes pour une réponse courte, sans appel réseau vers l'extérieur ;
• données : elles restent dans le périmètre de l'entreprise, ce qui compte pour les données personnelles et les enregistrements d'appels ;
• coût : la dépense par requête dépend du matériel de l'entreprise, et non de la grille tarifaire d'un fournisseur.

Où se cachent les pièges

Le principal poste de dépenses se déplace de l'inférence vers les données. Un jeu de données annoté de qualité coûte du temps d'experts, et le résultat dépend directement de sa propreté. Un petit modèle généralise mal hors de sa tâche : si une nouvelle catégorie de demandes apparaît ou si le format change, il faudra réaffiner le modèle. Il faut aussi un suivi de la dérive des données, un jeu de test et un processus de réentraînement, faute de quoi la maintenance absorbe les économies.

Il existe aussi des cas limites. Les formulations ambiguës et les classes rares sont moins bien traitées par un petit modèle que par un modèle phare. Les équipes matures construisent donc une cascade : le petit modèle traite le flux principal, tandis que les cas douteux, à faible niveau de confiance, sont renvoyés vers le grand modèle.

Par où commencer

Passez en revue vos appels à des LLM et repérez ceux dont la réponse tient dans un ensemble fixe de classes ou dans un schéma. Ce sont les meilleurs candidats. Rassemblez quelques milliers d'exemples à l'annotation vérifiée, mesurez la précision du modèle phare sur un échantillon de test mis de côté et prenez-la comme barre de référence.

Affinez ensuite le petit modèle et comparez la qualité, la latence et le coût par requête. Si l'écart de précision reste acceptable, basculez le flux sur le petit modèle et gardez le modèle phare comme filet de sécurité pour les réponses incertaines. Mieux vaut commencer par le scénario le plus massif et le plus ennuyeux : c'est là que le gain apparaît le plus vite.