Qu'est-ce qu'un small language model (SLM) ?

Un modèle de la classe 1B à 15B paramètres environ, conçu pour la profondeur et la répétition sur une tâche ciblée plutôt que pour le raisonnement large. Fine-tunable, peu coûteux à servir, et assez compact pour tourner on-prem ou sur du matériel modeste. À traiter comme une classe de déploiement distincte, pas comme un modèle généraliste réduit.

Les SLMs sont-ils moins bons que les LLMs ?

Seulement sur le raisonnement large et ouvert, où un frontier model est plus fort. Sur une tâche ciblée pour laquelle il est fine-tuné, un small model est souvent plus rapide, bien moins cher et parfois plus précis qu'un modèle généraliste géant. Il échange la généralité contre une faible latence, la confidentialité on-prem et un faible coût. Meilleur ou moins bon est le mauvais prisme : c'est un outil différent pour un travail différent.

Quand faire tourner un modèle on-device ?

Quand la confidentialité n'est pas négociable ou que le traitement doit tourner hors ligne. Un modèle on-device garde les données sur le laptop ou le téléphone, supprime tout coût par appel et n'a pas besoin de réseau. La contrepartie est la capacité : il convient aux tâches ciblées et bien définies, classification, assistants locaux, extraction on-device. Pour le raisonnement large, rester sur un tier cloud.

Reasoning model ou instruct model ?

Les instruct models exécutent une requête directement ; les reasoning models consacrent du calcul supplémentaire à l'inférence pour planifier d'abord, échangeant un coût et une latence plus élevés contre un raisonnement multi-étapes plus solide. Les reasoning models planifient, les instruct models exécutent. C'est un type de modèle, orthogonal au tier : on peut avoir une variante instruct ou reasoning au sein du même barreau de capacité.

Qu'est-ce que le Mixture-of-Experts (MoE) ?

Une architecture où un router n'active qu'un sous-ensemble épars des paramètres du modèle par token, au lieu de la totalité comme le fait un modèle dense. Le résultat : la capacité d'un grand modèle au coût de calcul d'un modèle bien plus petit. Comme reasoning vs instruct, c'est un levier intra-tier : il déplace le point coût/latence, pas le tier lui-même.

← Stack

Les tiers de modèles

Frontier, workhorse, small, edge : une échelle de capacité, et aligner le barreau sur la tâche est le levier.

Vue d'ensemble

Les modèles ne forment pas un marché unique : c'est une échelle. En haut se trouvent les frontier models, les plus puissants, les meilleurs sur les raisonnements les plus difficiles, et les plus coûteux et les plus lents par appel. En dessous vient le tier workhorse, les modèles de taille intermédiaire qui assurent l'essentiel du travail en production à une fraction du coût frontier : c'est là que vivent les tâches du quotidien. Plus bas encore, les small language models, la classe de 1B à 15B paramètres environ, que l'on peut fine-tuner et faire tourner on-prem ou sur du matériel modeste. Tout en bas, le tier edge : un modèle quantifié qui s'exécute sur un laptop ou un téléphone, entièrement hors ligne, sans coût par appel. Chaque barreau échange de la capacité brute contre un coût plus bas, une latence réduite, et la possibilité de garder les données au plus près.

L'erreur classique est de lire cette échelle comme une descente en qualité vers le bas de gamme, les small models étant le lot de consolation des équipes qui n'ont pas les moyens. C'est faux. Un small language model est une classe de déploiement à part, pas un grand modèle raté : il échange la généralité pour une faible latence, la confidentialité on-device ou on-prem, et un coût nettement inférieur sur des volumes importants à la structure prévisible. Il s'impose quand les données ne peuvent pas quitter le périmètre, ce qui est le cas en santé réglementée, en finance et dans le droit, et il l'emporte sur les tâches répétitives et bien délimitées où un small model fine-tuné est plus rapide et souvent plus précis qu'un modèle généraliste géant. Conçu pour la profondeur et la répétition, pas pour la largeur.

Le levier est le suivant : le tier se choisit par tâche, pas par entreprise. Un même produit peut appeler un frontier model pour l'unique étape de raisonnement difficile, un workhorse pour la génération courante, et un small model pour la classification à grande échelle, le tout dans le même flux. L'écart de coût entre frontier et small est de l'ordre de 10 à 20 fois : l'économie réalisée en envoyant chaque tâche au barreau le moins cher qui peut la traiter est substantielle. Décider quel barreau par requête, c'est exactement ce qu'automatise le routing de modèles, et ce mécanisme a sa propre page : choosing-a-model détaille la logique de routing. Ici, on cartographie l'échelle elle-même.

Architecture

Lire l'échelle de haut en bas. En descendant du frontier vers l'edge, la capacité se resserre du raisonnement large vers une tâche ciblée, le coût et la latence tendent vers zéro, et le lieu d'exécution passe du cloud vers votre propre périmètre puis vers l'appareil en main. Aucun barreau n'est la bonne réponse en soi : la bonne réponse est le barreau le plus bas qui passe la barre fixée par la tâche. Le type de modèle (instruct, reasoning, dense ou Mixture-of-Experts) déplace le coût et la latence à l'intérieur d'un barreau, mais est orthogonal au tier lui-même.

L'échelle de capacité : frontier → workhorse → small → edge, et le gradient de capacité, de coût et de lieu d'exécution sur chaque barreau.

Concepts clés

Frontier model: Le tier le plus puissant : les modèles les plus grands et les plus performants en raisonnement qu'un labo met sur le marché, au coût et à la latence les plus élevés par appel. À réserver aux étapes qui en ont réellement besoin, pas au travail courant.
Workhorse model: Le tier intermédiaire qui prend en charge la plupart des tâches en production à une fraction du coût frontier. Le choix raisonné par défaut : suffisamment capable pour la génération, la synthèse et l'usage d'outils au quotidien, sans payer le barreau du haut.
Small language model (SLM): Un modèle de la classe 1B à 15B paramètres environ, conçu pour la profondeur et la répétition sur une tâche ciblée plutôt que pour le raisonnement large. Fine-tunable, peu coûteux à servir, exécutable on-prem ou sur du matériel modeste. Une classe de déploiement, pas un grand modèle raté.
Edge / on-device: Exécuter un modèle directement sur un laptop ou un téléphone, hors ligne, sans appel API et sans coût par requête. Rendu possible par la quantization qui réduit l'empreinte mémoire du modèle ; maximise la confidentialité car les données ne quittent jamais l'appareil.
Quantization: Stocker les poids d'un modèle à une précision numérique plus faible (par exemple 4 bits au lieu de 16 bits) pour réduire la mémoire et accélérer l'inférence. Un small model en 4 bits peut tomber à environ un quart de son empreinte en pleine précision tout en conservant l'essentiel de sa qualité, ce qui lui permet de tourner sur l'edge.
Reasoning model: Un modèle qui consacre du calcul supplémentaire au moment de l'inférence pour planifier avant de répondre, échangeant un coût et une latence plus élevés contre un raisonnement multi-étapes plus solide. À distinguer d'un instruct model qui exécute une requête directement : les reasoning models planifient, les instruct models exécutent.
Mixture-of-Experts (MoE): Une architecture où un router n'active qu'un sous-ensemble épars des paramètres du modèle par token, au lieu de la totalité comme le fait un modèle dense. Elle offre la capacité d'un grand modèle au coût de calcul d'un modèle beaucoup plus petit, déplaçant le point coût/latence à l'intérieur d'un tier.
Distillation: Entraîner un modèle plus petit à imiter un modèle plus grand, en transférant une grande partie de son comportement dans un package moins coûteux à faire tourner. Un procédé courant pour que les small language models héritent d'une bonne qualité sur la tâche sans la taille ni le coût du modèle enseignant.

Quand l'utiliser

Cas adaptés

Frontier quand la tâche requiert réellement le raisonnement le plus difficile : un plan multi-étapes délicat, des instructions ambiguës, ou une étape ponctuelle où une mauvaise réponse coûte cher. Y recourir délibérément, pour l'étape qui en a besoin, pas par défaut pour l'ensemble du flux.
Workhorse pour le travail courant en production : rédaction, synthèse, extraction, appels d'outils de routine. Il passe la barre sur la plupart des tâches à une fraction du coût frontier, c'est pourquoi il doit être votre défaut et frontier l'exception.
Small (SLM) pour les tâches à fort volume, ciblées et répétitives : classification, routing, tagging, extraction structurée à grande échelle, notamment quand les données doivent rester on-prem. Fine-tuné sur votre tâche, il est plus rapide, moins cher et souvent plus précis qu'un modèle généraliste géant.
Edge / on-device quand la confidentialité n'est pas négociable ou que le traitement doit tourner hors ligne : un modèle sur laptop ou téléphone garde les données sur l'appareil, supprime tout coût par appel et fonctionne sans réseau. Le bon choix pour les usages critiques en confidentialité et les environnements déconnectés.

Anti-patterns

Utiliser un frontier model par défaut pour des tâches triviales à fort volume. Envoyer de la classification ou du tagging à grande échelle au barreau du haut brûle environ 10 à 20 fois le coût sans gain de qualité exploitable. Redescendre le volume vers le barreau le moins cher qui passe la barre.
Écarter les small language models comme des jouets. Ce sont une classe de déploiement conçue pour la profondeur et la répétition : sur une tâche ciblée et fine-tunée, un small model bat régulièrement un modèle généraliste géant sur la vitesse et le coût, parfois sur la précision. Les évaluer sur des benchmarks larges et ouverts, c'est passer à côté.
Ignorer l'edge pour les cas critiques en confidentialité ou hors ligne. Si les données ne peuvent pas quitter l'appareil ou si le réseau peut être absent, un tier API est le mauvais outil quelle que soit sa puissance : un modèle on-device quantifié est le seul barreau qui satisfait la contrainte.
Choisir un seul tier pour tout le produit. Le tier se décide par tâche, pas à l'échelle de l'entreprise. Un seul flux peut mélanger les barreaux frontier, workhorse et small ; verrouiller tout sur un seul barreau conduit soit à surpayer sur les tâches simples, soit à sous-performer sur les tâches difficiles.

Exemples de code

Choisir un tier par tâche

# A tiny sketch: pick the cheapest tier that clears the task's bar.
# The real routing logic lives in the choosing-a-model page; this is
# just the shape of the decision.

def pick_tier(task: str) -> str:
    if task in {"classify", "route", "tag", "extract"}:
        return "small"      # high-volume, narrow: SLM
    if task in {"draft", "summarise", "answer"}:
        return "workhorse"  # everyday production default
    if task in {"hard_reasoning", "plan"}:
        return "frontier"   # reserve the top rung
    return "workhorse"

# Same task, very different cost: frontier vs small runs ~10-20x apart.

La décision se prend par tâche, pas par application. Envoyer chaque requête au barreau le moins cher qui peut la traiter : c'est tout le levier de coût, et ce que le routing automatise.

Faire tourner un small model sur l'edge

# A quantized small model, on your own laptop, fully offline.
# Ollama pulls a 4-bit build that fits in a couple of GB of memory.
ollama run gemma3:4b "Classify this ticket: billing, bug, or feature?"

# No API call, no per-request cost, data never leaves the machine.
# Tens of tokens per second on a recent laptop. This is the edge tier.

Le barreau edge en une commande : un small model quantifié sur matériel local, hors ligne, zéro coût par appel. La contrepartie est la capacité, ce qui explique précisément pourquoi il convient aux tâches ciblées.

Comparatif

vs Frontier

Capacité, coût, latence, lieu d'exécution

Capacité maximale et meilleur sur le raisonnement difficile, mais coût et latence les plus élevés par appel, cloud uniquement. À utiliser délibérément pour les étapes qui en ont besoin, pas par défaut. Le mauvais barreau pour les tâches triviales à fort volume.

vs Workhorse

Capacité, coût, latence, lieu d'exécution

Suffisamment capable pour la plupart des tâches en production à une fraction du coût frontier, avec une latence modérée, servi depuis le cloud. Le tier par défaut raisonné : rédaction, synthèse, extraction et usage d'outils au quotidien ont leur place ici.

vs Small / SLM

Capacité, coût, latence, lieu d'exécution

Ciblé plutôt que généraliste, mais faible latence et coût nettement inférieur, fine-tunable, exécutable on-prem pour que les données restent dans votre périmètre. S'impose sur les tâches répétitives à fort volume et dans les environnements réglementés. Une classe à part entière, pas un lot de consolation.

vs Edge

Capacité, coût, latence, lieu d'exécution

Un small model quantifié sur laptop ou téléphone : capacité la plus faible, mais hors ligne, zéro coût par appel, et confidentialité maximale car les données ne quittent jamais l'appareil. Le seul barreau adapté aux usages critiques en confidentialité ou aux environnements déconnectés.

vs Deploying models

Un axe distinct : le lieu d'exécution

Le tier (cette page) indique la capacité du modèle ; le déploiement indique où il tourne : API du labo, inférence managée ou auto-hébergé. Les deux axes sont orthogonaux : un small model peut tourner sur une API managée, un frontier model uniquement derrière l'API d'un labo. Choisir le tier ici, puis le déploiement sur sa propre page.

Ressources

FAQ

Qu'est-ce qu'un small language model (SLM) ?: Un modèle de la classe 1B à 15B paramètres environ, conçu pour la profondeur et la répétition sur une tâche ciblée plutôt que pour le raisonnement large. Fine-tunable, peu coûteux à servir, et assez compact pour tourner on-prem ou sur du matériel modeste. À traiter comme une classe de déploiement distincte, pas comme un modèle généraliste réduit.
Les SLMs sont-ils moins bons que les LLMs ?: Seulement sur le raisonnement large et ouvert, où un frontier model est plus fort. Sur une tâche ciblée pour laquelle il est fine-tuné, un small model est souvent plus rapide, bien moins cher et parfois plus précis qu'un modèle généraliste géant. Il échange la généralité contre une faible latence, la confidentialité on-prem et un faible coût. Meilleur ou moins bon est le mauvais prisme : c'est un outil différent pour un travail différent.
Quand faire tourner un modèle on-device ?: Quand la confidentialité n'est pas négociable ou que le traitement doit tourner hors ligne. Un modèle on-device garde les données sur le laptop ou le téléphone, supprime tout coût par appel et n'a pas besoin de réseau. La contrepartie est la capacité : il convient aux tâches ciblées et bien définies, classification, assistants locaux, extraction on-device. Pour le raisonnement large, rester sur un tier cloud.
Reasoning model ou instruct model ?: Les instruct models exécutent une requête directement ; les reasoning models consacrent du calcul supplémentaire à l'inférence pour planifier d'abord, échangeant un coût et une latence plus élevés contre un raisonnement multi-étapes plus solide. Les reasoning models planifient, les instruct models exécutent. C'est un type de modèle, orthogonal au tier : on peut avoir une variante instruct ou reasoning au sein du même barreau de capacité.
Qu'est-ce que le Mixture-of-Experts (MoE) ?: Une architecture où un router n'active qu'un sous-ensemble épars des paramètres du modèle par token, au lieu de la totalité comme le fait un modèle dense. Le résultat : la capacité d'un grand modèle au coût de calcul d'un modèle bien plus petit. Comme reasoning vs instruct, c'est un levier intra-tier : il déplace le point coût/latence, pas le tier lui-même.