Quels small language models choisir sur Hugging Face ?

Les small language models à surveiller sont ceux sous 7 milliards de paramètres capables de bien raisonner, coder ou fonctionner localement. Je vous aide à lire les benchmarks, comprendre les familles de modèles et choisir entre Gemma 3, Phi-4-mini, Qwen3 ou DeepSeek-R1-Distill.

Pourquoi ces modèles comptent maintenant ?

Les small language models comptent maintenant parce qu’ils offrent un compromis devenu sérieux entre performance, coût, vitesse et exécution locale.

Un small language model, ou SLM, est un modèle de langage de moins de 7 milliards de paramètres. Un paramètre est un poids appris pendant l’entraînement, c’est-à-dire une valeur numérique que le modèle ajuste pour prédire le texte, comprendre une consigne ou produire une réponse. Dans cet article, je me limite aux modèles disponibles ou observables sur Hugging Face, notamment Gemma 3 4B, Phi-4-mini 3.8B, Qwen3-0.6B et DeepSeek-R1-Distill-Qwen-1.5B.

Pour une entreprise ou un développeur, l’intérêt est très concret. Ces modèles peuvent tourner en local sur un GPU consommateur, parfois sur laptop, voire sur smartphone selon la quantification et le niveau d’optimisation. La quantification consiste à réduire la précision numérique des poids pour diminuer la mémoire nécessaire et accélérer l’inférence, c’est-à-dire la phase où le modèle génère une réponse.

• Les coûts d’inférence baissent, car il faut moins de mémoire, moins de calcul et parfois aucune API externe.
• La confidentialité progresse, car les données peuvent rester sur votre machine ou dans votre infrastructure.
• La latence diminue, surtout quand l’appel réseau à un modèle distant disparaît.
• La spécialisation devient plus accessible, avec un fine-tuning ou une adaptation légère sur un cas métier précis.

Cette progression vient surtout de trois moteurs récents. Le premier est la meilleure qualité des données d’entraînement, grâce au filtrage, à la déduplication et à des corpus plus ciblés. Le deuxième est la distillation depuis de grands modèles enseignants : un modèle plus petit apprend à reproduire certaines capacités d’un modèle plus puissant, notamment en raisonnement. Le troisième concerne les architectures, avec des approches comme le Mixture-of-Experts, l’attention hybride ou les longues fenêtres de contexte. Le Mixture-of-Experts signifie que plusieurs sous-réseaux spécialisés existent, mais que seuls certains sont activés pour chaque token, c’est-à-dire chaque fragment de texte traité, ce qui réduit le calcul effectif.

Gemma 3 4B	Mis en avant pour ses résultats élevés sur GSM8K, un benchmark de problèmes mathématiques.
Phi-4-mini 3.8B	Intéressant pour ARC-C, un benchmark de raisonnement scientifique et de compréhension.
Qwen3-0.6B	Remarquable pour le multilingue malgré sa petite taille.
DeepSeek-R1-Distill-Qwen-1.5B	Utile pour observer la distillation orientée raisonnement.

Avant de choisir un modèle, il faut savoir lire les benchmarks, car un bon score général ne garantit pas une bonne performance sur votre cas d’usage.

Comment lire les benchmarks ?

Lire les benchmarks consiste à relier chaque score à une compétence précise, pas à chercher le plus gros chiffre global.

Un small language model, ou petit modèle de langage, peut être très bon en code et moyen en raisonnement mathématique. Il peut aussi briller dans un test académique et échouer sur vos données internes. Le bon réflexe consiste donc à lire chaque benchmark comme un signal spécialisé.

Benchmark	Ce que ça mesure	À surveiller
MMLU-Pro	Des connaissances et du raisonnement sur 57 sujets académiques, dans une version plus difficile que MMLU.	Un score supérieur à 50 est notable pour un modèle de moins de 5B, c’est-à-dire moins de 5 milliards de paramètres.
GSM8K	Des problèmes mathématiques en plusieurs étapes, introduits par Cobbe et al. en 2021.	Le score dépend fortement de la méthode de raisonnement demandée au modèle.
HumanEval	La génération de code Python validée par des tests, benchmark proposé par Chen et al. en 2021 chez OpenAI.	Plus de 60 % est impressionnant pour un modèle de moins de 5B, mais cela ne garantit pas du code maintenable.
ARC-C	Des questions scientifiques de type examen, issues du AI2 Reasoning Challenge de Clark et al. en 2018.	Le benchmark teste surtout le raisonnement scientifique court, pas la capacité à gérer un long contexte métier.

MMLU-Pro sert à estimer la culture générale structurée et le raisonnement académique. GSM8K teste plutôt la capacité à enchaîner plusieurs étapes logiques sur des calculs simples. HumanEval mesure si le modèle produit du code Python qui passe des tests unitaires, c’est-à-dire des vérifications automatiques du résultat. ARC-C, pour ARC Challenge, cible des questions scientifiques plus difficiles que la version facile du même benchmark.

Ces seuils donnent des repères utiles, mais ils ne remplacent jamais un test métier. Un assistant qui résume des tickets support, classe des factures ou génère du SQL doit être testé sur vos vrais exemples, avec vos contraintes de latence, de coût et de sécurité.

Les benchmarks ont aussi des limites connues. Les données peuvent être proches de celles vues pendant l’entraînement. Les prompts, c’est-à-dire les consignes données au modèle, varient selon les évaluations. La quantification, qui réduit la précision des poids pour accélérer l’inférence, n’est pas toujours prise en compte. La performance en laboratoire peut donc diverger de la production.

Avant de déployer, il faut vérifier les model cards Hugging Face, les détails d’évaluation et les rapports techniques officiels. Une fois les benchmarks compris, il faut distinguer les familles de modèles, car un modèle base, instruct ou reasoning ne répond pas au même besoin.

Quel type de modèle choisir ?

Le bon type de modèle dépend de votre usage principal : compléter du texte, suivre des consignes, raisonner ou produire du code.

Un modèle base est un modèle pré-entraîné qui prédit la suite d’un texte. Il sert surtout de fondation pour du fine-tuning, c’est-à-dire un réentraînement ciblé sur vos données ou vos formats de réponse.

Un modèle instruct est ajusté pour répondre à des consignes humaines. C’est souvent le meilleur choix pour un assistant interne, un workflow automatisé, une extraction de données ou une tâche business où vous attendez une réponse claire, structurée et exploitable.

Un modèle thinking ou reasoning est optimisé pour produire un raisonnement plus structuré. Il devient intéressant sur les mathématiques, la logique, l’extraction complexe ou la planification, surtout quand la réponse demande plusieurs étapes.

La distillation ajoute une option utile. Avec un modèle comme DeepSeek-R1-Distill-Qwen-1.5B, un petit modèle apprend à imiter certaines capacités d’un modèle enseignant plus grand. L’intérêt est simple : obtenir des comportements de raisonnement dans une empreinte mémoire et un coût d’inférence plus faibles.

Quelques repères aident à trier sans se perdre dans les fiches Hugging Face. Gemma 3 4B vise un bon équilibre général, avec un intérêt particulier à regarder sur GSM8K, un benchmark de problèmes mathématiques niveau école. Phi-4-mini 3.8B se regarde plutôt sur des tâches de raisonnement scientifique comme ARC-C, la version “Challenge” du benchmark AI2 Reasoning Challenge. Qwen3-0.6B devient pertinent quand le multilingue, la faible mémoire et l’exécution locale comptent plus que la puissance brute. DeepSeek-R1-Distill-Qwen-1.5B sert surtout à expérimenter le raisonnement distillé dans un format léger.

Usage	Famille à privilégier	Benchmark à regarder en priorité
Chatbot interne	Instruct	MT-Bench ou jeu de conversations interne annoté
Extraction de données	Instruct	F1 sur un jeu métier annoté, avec validation JSON si nécessaire
Génération de code	Instruct spécialisé code	HumanEval ou MBPP
Raisonnement mathématique	Thinking ou reasoning	GSM8K
Usage embarqué ou local très léger	Instruct compact ou base fine-tuné	Latence, mémoire RAM, tokens par seconde et qualité sur vos prompts

Un choix sérieux ne se fait donc pas uniquement au nombre de paramètres. Il faut croiser la famille du modèle, le benchmark adapté, le coût d’inférence, la qualité réelle des réponses et vos contraintes de confidentialité.

Comment les tester sur Hugging Face ?

Le plus simple est de tester d’abord le modèle sur sa page Hugging Face, puis de l’exécuter avec Transformers ou une API d’inférence selon vos contraintes. La page du modèle donne déjà beaucoup d’informations utiles avant d’écrire une ligne de code.

Je procède toujours dans cet ordre, parce que cela évite de perdre du temps sur un modèle inadapté dès le départ :

• Lire la model card. C’est la fiche technique du modèle : usage prévu, limites, données d’entraînement quand elles sont documentées, exemples de prompts.
• Vérifier la licence. Certains modèles autorisent l’usage commercial, d’autres non, ou imposent des conditions spécifiques.
• Identifier le type de modèle. Un modèle causal sert à générer du texte token par token, alors qu’un modèle d’embedding sert plutôt à rechercher ou comparer des textes.
• Regarder les benchmarks cités. Ils donnent un signal, mais ne remplacent jamais un test sur votre cas réel.
• Tester quelques prompts proches de votre besoin. Il faut mesurer la qualité, le temps de réponse et la régularité des sorties avant d’intégrer.

Voici un test local simple avec Transformers pour un modèle causal compatible Hugging Face :

from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

model_id = "org/model-name"

tokenizer = AutoTokenizer.from_pretrained(model_id)

model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype="auto",
    device_map="auto"
)

prompt = "Résume ce texte en deux phrases : Hugging Face permet de partager et tester des modèles IA."

inputs = tokenizer(prompt, return_tensors="pt").to(model.device)

with torch.no_grad():
    outputs = model.generate(
        **inputs,
        max_new_tokens=80,
        do_sample=False
    )

response = tokenizer.decode(outputs[0], skip_special_tokens=True)
print(response)

Certains modèles nécessitent une configuration chat_template, c’est-à-dire un format de conversation attendu par le modèle, ou des dépendances spécifiques indiquées dans leur model card.

Pour un test encore plus rapide, le pipeline text-generation suffit souvent :

from transformers import pipeline

model_id = "org/model-name"

generator = pipeline(
    "text-generation",
    model=model_id,
    torch_dtype="auto",
    device_map="auto"
)

result = generator(
    "Donne trois critères pour choisir un small language model.",
    max_new_tokens=80,
    do_sample=False
)

print(result[0]["generated_text"])

La quantification peut réduire la mémoire utilisée en stockant les poids du modèle avec moins de précision, par exemple en 8 bits ou 4 bits. Il faut toutefois vérifier la qualité après quantification, car certaines tâches deviennent plus fragiles.

Critère	Ce qu’il faut observer
Exactitude	Les réponses sont-elles factuellement correctes ?
Stabilité	Le modèle répond-il de manière cohérente à prompts proches ?
Consignes	Respecte-t-il le format, la langue et les contraintes demandées ?
Hallucinations	Invente-t-il des faits, des sources ou des chiffres ?
Latence et coût	Le temps de réponse et l’infrastructure restent-ils acceptables ?
Contexte	La longueur de contexte couvre-t-elle vos documents ou conversations ?
Licence et données	L’usage prévu, la confidentialité et la sécurité sont-ils compatibles ?

Tester un modèle est indispensable, mais le vrai choix se fait ensuite avec un cadre de décision adapté au besoin business.

Quelle méthode pour décider ?

Décider correctement revient à partir du cas d’usage, puis à éliminer les modèles qui ne respectent pas vos contraintes de qualité, coût, licence et déploiement.

Le piège consiste à choisir un modèle parce qu’il est populaire sur Hugging Face ou parce qu’il a beaucoup de paramètres. Un paramètre est une valeur apprise pendant l’entraînement du modèle. Plus il y en a, plus le modèle peut être expressif, mais plus il coûte cher à exécuter en mémoire, en calcul et en latence.

Je garde une méthode simple en 6 étapes :

• Définir la tâche exacte : classification, extraction, résumé, reformulation, question-réponse, génération de code ou agent conversationnel.
• Choisir les benchmarks pertinents : MMLU pour des connaissances générales, HumanEval pour le code, GSM8K pour le raisonnement mathématique, ou mieux, un benchmark interne si vous en avez un.
• Sélectionner 3 à 5 modèles candidats sous 7B, c’est-à-dire moins de 7 milliards de paramètres, pour rester dans une logique “small language model”.
• Tester ces modèles sur un jeu d’exemples internes représentatif de vos vrais cas d’usage.
• Mesurer la qualité, la latence et le coût par requête, sans oublier les erreurs critiques.
• Valider la licence, la confidentialité des données et les contraintes de sécurité avant toute mise en production.

Un point mérite d’être clair. Un modèle de 0.6B peut suffire pour des tâches simples, cadrées et multilingues, par exemple classer des tickets support ou extraire des champs dans un texte court. Un modèle autour de 4B sera souvent plus adapté si vous attendez des réponses plus riches, un meilleur suivi d’instructions ou un peu de raisonnement. Le nombre de paramètres n’est donc pas une stratégie. C’est seulement une contrainte technique.

Le protocole d’évaluation peut rester léger. Prenez 30 à 100 exemples réels, notez les réponses humaines sur une échelle stable, par exemple de 1 à 5, comparez chaque modèle à un modèle de référence, puis suivez séparément les erreurs critiques : hallucination, fuite d’information, mauvaise langue, refus injustifié, format invalide. Les résultats doivent être produits sur vos données, pas déduits d’un classement public.

Critère	Question à se poser
Qualité	Le modèle répond-il correctement sur vos exemples réels ?
Coût	Combien coûte une requête en calcul, hébergement et maintenance ?
Confidentialité	Les données peuvent-elles rester dans votre infrastructure ?
Facilité d’intégration	Le modèle fonctionne-t-il avec vos outils, API et contraintes matérielles ?
Licence	La licence autorise-t-elle votre usage commercial ou interne ?
Latence	Le temps de réponse est-il acceptable pour l’utilisateur final ?
Spécialisation	Le modèle est-il adapté à votre domaine, votre langue et votre format de sortie ?

Les small language models ne remplacent pas tous les grands modèles, mais ils deviennent une option rationnelle dès que le besoin est cadré.

Alors, quel petit modèle mérite vos tests ?

Les small language models ne sont plus seulement des versions dégradées de grands modèles. Sous la barre des 7 milliards de paramètres, certains deviennent utiles pour raisonner, coder, répondre en multilingue ou fonctionner localement. La bonne approche consiste à comparer les familles de modèles, lire les benchmarks adaptés, puis tester sur vos propres exemples. Gemma 3 4B, Phi-4-mini 3.8B, Qwen3-0.6B et DeepSeek-R1-Distill-Qwen-1.5B donnent de bonnes pistes de départ. Le bénéfice pour vous : réduire les coûts, garder plus de contrôle et choisir un modèle vraiment adapté à votre usage.

FAQ

• Qu’est-ce qu’un small language model ?
  Un small language model est un modèle de langage de taille réduite, généralement inférieur à 7 milliards de paramètres dans le périmètre traité ici. Il sert à générer, résumer, classer ou raisonner sur du texte avec une empreinte plus légère qu’un grand modèle.
• Pourquoi utiliser un petit modèle plutôt qu’un grand modèle ?
  Un petit modèle peut coûter moins cher à exécuter, répondre plus vite et fonctionner localement selon le matériel disponible. Il est intéressant quand la tâche est bien cadrée, quand la confidentialité compte ou quand un grand modèle serait surdimensionné.
• Quels benchmarks regarder en priorité ?
  MMLU-Pro aide à évaluer les connaissances et le raisonnement général sur 57 sujets, GSM8K les mathématiques en plusieurs étapes, HumanEval le code Python et ARC-C le raisonnement scientifique. Le bon benchmark dépend toujours de votre usage réel.
• Quelle différence entre base, instruct et reasoning ?
  Un modèle base prédit la suite d’un texte et sert souvent de fondation. Un modèle instruct est entraîné à suivre des consignes. Un modèle reasoning ou thinking est optimisé pour mieux traiter les tâches nécessitant un raisonnement structuré.
• Peut-on utiliser ces modèles en production ?
  Oui, à condition de vérifier la licence, la qualité sur vos propres données, la latence, la sécurité et la stabilité des réponses. Le bon réflexe consiste à tester plusieurs modèles candidats avant toute intégration dans un workflow business.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA, le SEO et le GEO. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer, tester ou intégrer des modèles IA dans vos workflows business, vous pouvez me contacter.