SLMs vs LLMs : quel choix pour une application réelle ?

Le débat entre SLMs et LLMs est souvent mal posé. Il est fréquemment résumé à une opposition trop simple:

• les grands modèles seraient plus intelligents
• les petits modèles seraient plus rapides

Cette lecture est insuffisante pour prendre une décision d'architecture. Dans une application réelle, le choix d'un modèle de langage est un arbitrage entre qualité, coût, latence, gouvernance des données et complexité d'exploitation.

La vraie question n'est donc pas: quel modèle est le plus impressionnant ?

La vraie question est: quel modèle est suffisant pour le problème à résoudre ?

Que recouvrent vraiment SLM et LLM

Les termes varient selon les acteurs, mais l'idée générale reste stable.

SLM

Un Small Language Model est un modèle plus compact, souvent mieux adapté à:

• des usages cibles
• des environnements contraints
• une inférence locale ou edge
• des flux à faible latence

LLM

Un Large Language Model vise des capacités plus générales:

• plus de couverture de connaissances
• meilleure capacité de raisonnement dans certains cas
• plus de souplesse sur des tâches très variées

En contrepartie, il implique souvent:

• plus de coût
• plus de latence
• plus de consommation GPU ou API
• plus de travail de cadrage pour un usage fiable

Ce qu'un architecte doit regarder en premier

Quand on intègre un modèle dans une application, quatre critères dominent.

1. La nature exacte de la tâche

Tous les usages n'ont pas besoin d'un grand modèle.

Exemples où un SLM peut suffire:

• classification de tickets
• extraction de champs
• routage de demandes
• reformulation simple
• étiquetage de contenu

Exemples où un LLM peut être plus pertinent:

• synthèse longue et nuancée
• génération de contenu plus ouvert
• raisonnement multi-étapes
• tool calling complexe
• assistance à l'analyse sur contexte riche

Si le problème est étroit et bien borne, un SLM peut offrir un meilleur rapport valeur / coût.

2. La latence acceptable

Dans un workflow interactif, la latence change complètement l'expérience.

Un chatbot interne peut tolérer quelques secondes. Un autocomplete de code, beaucoup moins. Un routage automatique dans une API temps réel encore moins.

Les petits modèles sont souvent plus intéressants quand:

• la réponse doit être quasi immediate
• le volume de requêtes est élevé
• le coût unitaire doit rester très bas

3. Le coût d'exploitation

Le coût ne se limite pas au prix API ou au besoin GPU.

Il faut prendre en compte:

• le trafic moyen
• les pics de charge
• la longueur du contexte
• le nombre d'appels par workflow
• le taux de retry
• l'eventuelle supervision humaine

Un modèle trop gros pour le besoin peut rendre un cas d'usage non rentable, même s'il fonctionne bien techniquement.

4. La gouvernance des données

Si les données sont sensibles ou si l'environnement impose des contraintes fortes, les SLMs prennent parfois un avantage important, surtout lorsqu'ils peuvent tourner localement ou dans un périmètre mieux maîtrisé.

Le choix de modèle devient alors aussi un sujet de:

• conformité
• localisation des données
• auditabilité
• maîtrise du risque fournisseur

Le piège du benchmark générique

Comparer SLMs et LLMs sur des benchmarks publics est utile, mais insuffisant.

Ces scores ne disent pas:

• si le modèle est bon sur tes données
• s'il respecte ton format de sortie
• s'il tient la charge
• s'il reste stable dans ton workflow
• s'il est économiquement tenable

En AI engineering, un modèle médiocre sur benchmark peut être excellent dans un cas d'usage étroit. À l'inverse, un modèle top niveau peut être inutilement cher pour une tâche répétitive et simple.

Une stratégie souvent plus intelligente : la hiérarchie de modèles

Dans beaucoup de systèmes, il n'est pas nécessaire de choisir un seul modèle pour tout.

Une architecture plus mature consiste à utiliser:

• un SLM pour le tri, la classification ou le prétraitement
• un LLM pour les cas complexes ou ambigus

Exemple:

1. un petit modèle classe une demande client
2. si le score de confiance est élevé, le workflow continue
3. sinon, un modèle plus capable prend le relais

Cette stratégie permet de contrôler le coût sans sacrifier la qualité là où elle compte vraiment.

Les SLMs ne sont pas seulement des "petits LLMs"

Une erreur fréquente consiste à voir les SLMs comme une version dégradée des grands modèles. Ce n'est pas toujours juste.

Un petit modèle bien choisi peut être meilleur sur un usage cible si:

• il a été spécialisé
• il tourne plus près des données
• il offre une latence beaucoup plus faible
• son comportement est plus stable dans un cadre étroit

En pratique, beaucoup de workflows applicatifs n'ont pas besoin d'un raisonnement ouvert sur tout le web. Ils ont besoin d'une sortie propre, rapide et prévisible.

Quand un LLM reste le bon choix

Les grands modèles gardent un avantage net dans plusieurs cas:

• conversations ouvertes avec contexte riche
• syntheses complexes
• génération multi-contrainte
• raisonnement à plusieurs étapes
• orchestration de tool calling plus riche

Ils sont aussi utiles quand le coût d'une erreur est plus élevé que le coût d'inférence.

Exemple:

• assistance à l'analyse technique
• support expert
• exploration documentaire avancée

Dans ces cas, payer plus cher pour une meilleure capacité peut être une décision rationnelle.

Les questions à poser avant de choisir

Avant d'arrêter ton choix entre SLM et LLM, pose ces questions:

• quel est le niveau minimal de qualité nécessaire ?
• quelle latence maximale est acceptable ?
• quel budget par requête est soutenable ?
• les données peuvent-elles sortir du périmètre contrôlé ?
• la tâche est-elle générale ou très contrainte ?
• faut-il privilégier la rapidité, la finesse ou la robustesse ?

Ces questions donnent une base de décision beaucoup plus utile qu'une simple comparaison de taille de modèle.

Évaluer sur ton propre workflow

Le choix doit être valide par une évaluation locale, sur des exemples proches de la production.

Il faut tester:

• la qualité de sortie
• la régularité
• le taux d'erreur
• la latence
• le coût
• la facilité d'intégration

Une évaluation minimale avec un jeu de cas représentatifs vaut plus qu'un long débat théorique sur les modèles.

Une grille de décision simple

Tu peux raisonner ainsi:

• si la tâche est simple, répétitive, structurée: commencer par un SLM
• si la tâche est ambiguë, riche en contexte, exigeante: envisager un LLM
• si le volume est très grand: privilégier un SLM ou une architecture hybride
• si la criticité est forte: évaluer les deux sur des jeux de cas réels

Cette approche limite les choix idéologiques.

Conclusion

Le choix entre SLMs et LLMs n'est pas un débat abstrait sur la puissance des modèles. C'est un sujet de design applicatif et de compromis d'exploitation.

Un bon système n'utilise pas le modèle le plus grand possible. Il utilise le modèle le plus adapté à la tâche, au niveau de service attendu et aux contraintes du produit.