Small Language Models : quand les petits modèles suffisent

Pendant longtemps, la course à l'IA Générative s'est résumée à une course à la taille : plus de paramètres, plus de données, plus de GPU. Pourtant, une grande partie des applications en production n'a pas besoin d'un modèle de plusieurs centaines de milliards de paramètres. Classer des tickets, extraire des champs d'un contrat ou router une requête sont des tâches bien délimitées, pour lesquelles un modèle compact peut suffire.

C'est le terrain des Small Language Models (SLM), des modèles de langage dont la taille va de quelques centaines de millions à quelques dizaines de milliards de paramètres. Phi chez Microsoft, Gemma chez Google, Qwen chez Alibaba, Llama 3.2 chez Meta ou encore Mistral Small en sont les exemples les plus connus. Ils s'exécutent sur un seul GPU, parfois sur un CPU ou un smartphone, et coûtent de 10 à 100 fois moins cher par requête qu'un modèle de pointe servi par API.

La frontière entre « petit » et « grand » reste floue et évolue avec le matériel : on parle généralement de SLM en dessous d'une trentaine de milliards de paramètres. Ce qui compte, c'est surtout qu'un SLM tienne dans la mémoire d'une machine que l'on maîtrise. Dans cet article, nous allons voir comment ces modèles sont obtenus, dans quels cas d'usage ils excellent, puis comment arbitrer face à un grand LLM en matière de qualité, de latence, de coût et de confidentialité.

Comment obtient-on un petit modèle performant ?

Un SLM n'est pas simplement un grand modèle que l'on aurait raccourci. Les gains de qualité de ces dernières années viennent de la manière dont ils sont entraînés, avec trois leviers principaux.

La distillation de connaissances

La distillation consiste à entraîner un petit modèle (l'élève) à imiter un grand modèle (le professeur). Au lieu d'apprendre uniquement à prédire le token suivant dans un texte brut, l'élève apprend à reproduire la distribution de probabilités produite par le professeur pour chaque token. Cette distribution contient bien plus d'information qu'un simple token correct : elle indique quelles alternatives étaient plausibles et dans quelles proportions.

Plusieurs familles de modèles reposent sur cette approche. Les modèles Llama 3.2 de 1 et 3 milliards de paramètres ont ainsi été obtenus en combinant l'élagage (pruning) de modèles Llama 3.1 plus grands et la distillation à partir de modèles de 8 et 70 milliards de paramètres. Google a également recours à la distillation pour entraîner les petites versions de Gemma. L'élève ne dépassera pas son professeur, mais il capture une part importante de ses capacités pour une fraction du coût d'inférence.

Les données synthétiques et la curation

Le deuxième levier concerne les données. L'approche popularisée par la famille Phi de Microsoft part d'une intuition simple : un petit modèle apprend mieux avec des données de haute qualité, de type manuel scolaire, qu'avec du texte web non filtré. Une part importante du corpus d'entraînement est donc générée par des modèles plus grands, sous forme d'explications, d'exercices et de raisonnements structurés, puis filtrée selon des critères de qualité.

Ce principe a une conséquence directe : à taille égale, un modèle entraîné sur des données bien choisies surpasse nettement un modèle entraîné sur de gros volumes de données bruitées. C'est aussi pourquoi les SLM récents sont souvent plus performants que des modèles beaucoup plus gros d'il y a deux ou trois ans. Les modèles de raisonnement ont renforcé cette tendance, car leurs chaînes de pensée servent de matière première pour entraîner de petits modèles de raisonnement.

L'entraînement prolongé et la compression

Le troisième levier consiste à entraîner un petit modèle beaucoup plus longtemps que ne le prévoyaient les lois d'échelle classiques. Un modèle de quelques milliards de paramètres peut ainsi voir plus de dix mille milliards de tokens pendant son pré-entraînement. Le coût d'entraînement est payé une seule fois, alors que le coût d'inférence, lui, se répète à chaque requête : investir davantage à l'entraînement pour obtenir un modèle plus petit est donc rentable à grande échelle.

À cela s'ajoute la compression après entraînement. La quantization réduit la précision des poids (de 16 bits à 8 ou 4 bits) et divise l'empreinte mémoire par deux à quatre, avec une perte de qualité souvent modeste sur un modèle compact bien entraîné.

À lire : découvrez notre formation LLM Engineering

Les principales familles de SLM

L'écosystème évolue vite, et les versions se succèdent tous les quelques mois. Le tableau suivant donne des repères sur les familles les plus utilisées, dont il faut vérifier les dernières versions et les licences avant tout choix.

Cette liste n'est pas exhaustive : SmolLM de Hugging Face, Granite d'IBM ou les petits modèles de DeepSeek distillés à partir de R1 complètent le panorama. Les tailles inférieures à 4 milliards de paramètres ciblent plutôt l'embarqué et les tâches simples, alors que la tranche de 7 à 30 milliards de paramètres offre des performances proches des anciens modèles de pointe sur de nombreux usages.

Les cas d'usage où un SLM suffit

Un SLM est rarement le bon choix pour une conversation ouverte sur des sujets très variés. Il excelle en revanche dès que la tâche est étroite, répétitive et bien définie.

• Classification et routage : catégoriser des tickets de support, détecter l'intention d'un message, filtrer du contenu ou router une requête vers le bon modèle. Un SLM de quelques milliards de paramètres, parfois fine-tuné, atteint souvent la précision d'un grand modèle sur ces tâches.
• Extraction d'information : transformer un texte libre (facture, contrat, mail) en JSON conforme à un schéma. Associé à des sorties structurées, un petit modèle produit des résultats fiables et sans coût prohibitif à fort volume.
• Agents spécialisés : dans un système multi-agents, tous les agents n'ont pas besoin du même niveau d'intelligence. Un SLM peut gérer l'appel d'outils (tool calling) sur un périmètre restreint, pendant qu'un modèle plus puissant se charge de la planification.
• Edge et embarqué : traitement sur un smartphone, un poste de travail, un véhicule ou un équipement industriel, avec ou sans connexion réseau. Les données restent sur l'appareil et la latence ne dépend plus du réseau.
• Brique d'un RAG : reformulation de requêtes, génération d'embeddings, reranking ou génération finale à partir de documents fournis dans le contexte. Dans un RAG, la connaissance vient des documents et non des paramètres du modèle, ce qui avantage les petits modèles.

Le fine-tuning joue ici un rôle central. Avec quelques milliers d'exemples annotés, il est possible d'adapter un SLM à un domaine ou à un format de sortie précis grâce à des méthodes économes en ressources comme LoRA. Un fine-tuning bien mené sur un petit modèle dépasse fréquemment un grand modèle généraliste utilisé tel quel, pour une tâche donnée.

Voici un exemple d'extraction avec un SLM exécuté en local via Ollama et sa bibliothèque Python.

import ollama
from pydantic import BaseModel


class Facture(BaseModel):
    """Schéma des champs à extraire d'une facture."""
    fournisseur: str
    montant_ttc: float
    date: str


texte = "Facture n°2024-118 émise le 12/03/2026 par Dupont SARL, total TTC : 1 284,50 EUR."

# Le schéma JSON contraint la sortie du modèle
reponse = ollama.chat(
    model="qwen3:4b",
    messages=[{"role": "user", "content": f"Extrais les informations de cette facture :\n{texte}"}],
    format=Facture.model_json_schema(),
    options={"temperature": 0},
)

facture = Facture.model_validate_json(reponse.message.content)
print(facture)

Ce code envoie le texte à un modèle de 4 milliards de paramètres qui tourne sur la machine locale, force la sortie à respecter le schéma Pydantic et valide le résultat. Aucune donnée ne quitte l'environnement, et le même code fonctionne avec un autre SLM en changeant uniquement le nom du modèle. Pour la prise en main de ces outils, notre article sur Ollama détaille l'installation et l'utilisation.

SLM ou grand LLM : comment choisir ?

Le choix ne se fait pas sur un classement général, mais sur les exigences de chaque tâche. Le tableau suivant résume les principaux critères d'arbitrage.

Ce comparatif conduit à une règle pratique : partir de la tâche, pas du modèle. Il est conseillé de construire un jeu d'évaluation représentatif, puis de tester d'abord le grand modèle pour fixer une référence, avant de descendre progressivement vers des modèles plus petits tant que la qualité reste acceptable. Cette démarche s'appuie sur des métriques adaptées, ou sur un LLM utilisé comme juge lorsque la sortie est du texte libre.

Plusieurs signaux plaident en faveur d'un SLM :

• Volume élevé : lorsque des millions de requêtes sont traitées chaque mois, la différence de coût par requête devient décisive.
• Contraintes de latence : pour de l'autocomplétion, de la voix ou de l'interaction temps réel, quelques centaines de millisecondes de gain changent l'expérience.
• Données sensibles : santé, finance, secteur public ou propriété intellectuelle, où l'envoi de données à un fournisseur externe est impossible ou coûteux à justifier.
• Tâche stable et bien définie : un périmètre qui change peu se prête au fine-tuning et à une évaluation rigoureuse.

À l'inverse, un grand modèle reste préférable lorsque les requêtes sont imprévisibles, que le raisonnement est long ou que la tâche demande de larges connaissances du monde. Pour juger plus finement le coût réel, notre article sur le FinOps des LLM présente les leviers de maîtrise des dépenses.

À découvrir : notre formation LLM Engineering

Les architectures hybrides

Dans la pratique, les équipes les plus matures ne choisissent pas l'un ou l'autre : elles combinent les deux. Un SLM sert de premier niveau, qui traite directement les requêtes simples, tandis que les cas ambigus ou complexes sont escaladés vers un grand modèle. Un routeur (lui-même souvent un petit classifieur) décide du modèle à appeler selon la difficulté estimée de la requête.

Cette architecture réduit fortement la facture tout en conservant la qualité sur les cas difficiles. Elle exige toutefois un suivi précis : taux d'escalade, qualité par segment de requêtes, dérive des données. Pour servir plusieurs modèles de façon efficace sur ses propres GPU, un serveur d'inférence comme vLLM permet de gérer le batching et le débit.

Limites et points de vigilance

Les SLM ne sont pas exempts de défauts, et plusieurs précautions s'imposent avant de les passer en production.

• Robustesse : un petit modèle est plus sensible à la formulation du prompt et aux cas limites. Les consignes doivent être précises et testées sur des entrées variées.
• Hallucinations : avec moins de paramètres, les connaissances factuelles sont moins fiables. Il vaut mieux fournir l'information dans le contexte plutôt que de compter sur la mémoire du modèle.
• Fenêtre de contexte effective : la taille annoncée n'est pas la taille réellement exploitable, et la qualité se dégrade souvent bien avant la limite affichée.
• Maintenance : héberger soi-même un modèle implique de gérer les mises à jour, la supervision, la sécurité et les licences, ce que l'API d'un fournisseur prend en charge à votre place.

Le coût total doit donc inclure le temps des équipes, pas seulement le prix du GPU. Pour un faible volume ou une phase de prototypage, une API reste souvent plus économique. Le basculement vers un SLM devient pertinent lorsque l'usage est stabilisé et mesuré.

Conclusion

Les Small Language Models montrent que la performance d'un modèle ne dépend pas uniquement de sa taille. Grâce à la distillation, aux données synthétiques de qualité et à l'entraînement prolongé, des modèles de quelques milliards de paramètres atteignent aujourd'hui un niveau qui nécessitait il y a peu des modèles dix fois plus gros. Ils s'imposent sur la classification, l'extraction, les agents spécialisés et l'embarqué.

Le bon réflexe consiste à partir du besoin et de l'évaluation, pas de la réputation du modèle : mesurer, descendre en taille tant que la qualité tient, puis combiner petits et grands modèles au sein d'une architecture hybride. Les gains en latence, en coût et en confidentialité sont réels, à condition d'accepter les limites de ces modèles sur le raisonnement complexe et les connaissances générales.

Pour les AI engineers comme pour les décideurs techniques, savoir dimensionner un modèle à la tâche devient une compétence différenciante. Elle conditionne la rentabilité des projets d'IA Générative, et elle se renforce à mesure que les SLM progressent. Les agents IA, qui multiplient les appels aux modèles, en sont l'un des principaux bénéficiaires, comme l'explique notre article sur l'Agentic AI.