[Traduction] Étude complète sur les petits modèles de langage (SLM)

Étude complète sur les petits modèles de langage (SLM) (Small Language Models: Survey, Measurements, and Insights)

Présentation de l’article

Les progrès récents des modèles de langage se divisent en deux grandes tendances. La première concerne les grands modèles de langage (LLM, Large Language Model), exploités dans de vastes datacenters à l’aide de millions de GPU. Ces modèles prennent en charge des tâches linguistiques avancées et visent à résoudre, grâce à l’intelligence artificielle, des problèmes complexes comme ceux de la science. Cependant, ces LLM exigent des coûts élevés et des ressources de calcul considérables, ce qui les rend peu réalistes à déployer sur des appareils personnels.

À l’inverse, les petits modèles de langage (SLM, Small Language Model) sont conçus pour être déployés sur des appareils aux ressources limitées, comme les smartphones, les tablettes ou les objets connectés. Leur objectif est de rendre l’IA accessible à tous en proposant une intelligence artificielle à la fois pratique et économique. Cet article constitue la première étude d’ensemble consacrée aux SLM, en analysant les petits modèles de langage publiés ces dernières années sous l’angle des innovations techniques, des performances et du coût d’exécution sur appareil.

Architecture, jeux de données et entraînement des petits modèles de langage (SLM)

Vue d’ensemble des petits modèles de langage (SLM, Small Language Model)

Les SLM sont plus compacts que les modèles de langage à très grand nombre de paramètres, mais ils ont néanmoins démontré leurs performances dans diverses tâches, comme le raisonnement de bon sens, la résolution de problèmes mathématiques et l’apprentissage en contexte. Ils montrent ainsi le potentiel d’une IA directement exécutable sur l’appareil.

Cette étude examine les SLM dont le nombre explose depuis la fin de l’année 2023, et a retenu 59 modèles selon les critères suivants afin d’en étudier les performances et les coûts :

• La taille des SLM est définie ici comme comprise entre 100M et 5B de paramètres, et seuls les modèles à poids ouverts pouvant être évalués sont pris en compte.

• Pour garantir de bonnes performances et un déploiement réel, seuls les modèles reposant sur une architecture Transformer decoder-only sont inclus. Autrement dit, les modèles basés sur des architectures comme RWKV et Mamba n’ont pas été retenus.

• Cette étude se concentrant sur les connaissances fondamentales acquises lors du pré-entraînement, elle ne retient que les modèles de base (Base Model), à l’exclusion des modèles disponibles uniquement en version ajustée par instruction (Instruct Fine-tuned), comme Microsoft Phi et StabilityAI StableLM.

• Par ailleurs, les modèles dérivés issus du fine-tuning de modèles préentraînés sont également exclus.

La liste des modèles sélectionnés selon ces critères est la suivante :

Architecture des modèles SLM (Model Architecture)

L’architecture des SLM repose sur le Transformer, avec plusieurs variantes. Le cœur de l’architecture Transformer est constitué de la multi-head attention (MHA) et du réseau feed-forward (FFN). La MHA permet de se concentrer sur différentes parties des données d’entrée, ce qui améliore l’efficacité du traitement parallèle. Dans les modèles récents, diverses expérimentations portent sur les mécanismes d’attention, les FFN et les fonctions d’activation :

1. Mécanismes d’attention (Attention Mechanisms):

   • Multi-Head Attention (MHA) : mécanisme central du Transformer, qui permet de prêter simultanément attention à plusieurs parties des données d’entrée.
   • Group-Query Attention (GQA) : approche qui regroupe plusieurs valeurs de requête afin de réduire la complexité de calcul de l’attention.
   • Multi-Query Attention (MQA) : méthode qui réduit la complexité de calcul en autorisant des projections différentes des clés et des valeurs pour chaque requête.

2. Réseau feed-forward (Feed-Forward Network, FFN):

   • FFN standard (Standard FFN) : structure réseau simple composée de deux couches.
   • FFN à portes (Gated FFN) : structure améliorant les performances grâce à l’ajout d’une couche de gate.

3. Ratio d’expansion dimensionnelle du réseau feed-forward (The intermediate ratio of the FFN) : il s’agit du ratio entre la taille de la couche cachée (hidden layer) et la dimension d’entrée, souvent utilisé pour exprimer le facteur d’expansion. Plus ce ratio est élevé, plus le FFN peut apprendre des motifs complexes, mais plus le coût de calcul augmente. Dans un FFN standard, ce ratio est généralement d’environ 4, tandis que dans un Gated FFN il se situe entre 2 et 8.

4. Fonctions d’activation (Activation Functions) : dans les SLM, on utilise principalement ReLU (Rectified Linear Unit), GELU (Gaussian Error Linear Uni), $GELU_{tanh}$ et SiLU (Sigmoid Linear Unit). En 2022, ReLU dominait ; en 2023, GELU et ses variantes étaient les plus utilisées ; et depuis 2024, SiLU est devenue la fonction d’activation la plus largement adoptée.

5. Normalisation de couche (Layer Normalization) : pour la normalisation de couche, LayerNorm et RMSNorm sont utilisés. RMSNorm est de plus en plus adopté, car il contribue à améliorer la stabilité de l’entraînement.

6. Taille du vocabulaire (Vocabulary Size) : la taille du vocabulaire désigne le nombre de tokens uniques qu’un SLM peut reconnaître. Les SLM récents ont le plus souvent un vocabulaire de plus de 50 000 entrées, et il a été constaté qu’une taille de vocabulaire plus importante améliore les performances.

Pour les 59 modèles sélectionnés plus haut, l’évolution dans le temps de la distribution de ces six variantes est résumée comme suit :

L’examen de ces architectures a permis d’identifier plusieurs innovations d’architecture de modèle (Model Architecture Innovations) :

1. Partage des paramètres (Parameter Sharing)

   • Le partage des paramètres est une technique utilisée dans les grands modèles de langage (LLM) pour réutiliser le même ensemble de poids dans plusieurs couches ou composants du réseau. Cette approche permet de réduire fortement le nombre de paramètres du modèle, tout en maintenant les performances, et conduit ainsi à un entraînement et une inférence plus efficaces.
   • Partage Embedding-lm_head (Embedding-lm_head sharing) : le partage des poids des embeddings avec la couche finale lm_head est la technique de partage de poids la plus courante. Il s’agit d’un partage de la couche d’embedding des mots, sans aucun lien avec RoPE (Rotary Position Encoding). Des modèles comme Gemma et Qwen ont tous recours à cette technique.
   • Partage couche par couche de l’attention/du FFN (Layer-wise Attention/FFN sharing) : cette méthode réutilise le même ensemble de poids sur plusieurs couches du modèle. On l’observe fréquemment dans les SLM/LLM où toutes les couches Transformer partagent les mêmes paramètres. Par exemple, MobiLLaMA partage les poids du FFN sur tous les blocs Transformer, tandis que MobileLLM partage les poids de l’Attention et du FFN entre deux blocs Transformer adjacents.

2. Mise à l’échelle des paramètres par couche (Layer-wise Parameter Scaling)

   • Cette technique a été proposée et utilisée dans OpenELM. Les SLM classiques emploient la même configuration pour chaque couche Transformer du modèle, ce qui entraîne une allocation uniforme des paramètres entre les couches. À la différence de ces modèles, chaque couche Transformer d’OpenELM possède une configuration différente (par exemple, le nombre de têtes et les dimensions du FFN), ce qui permet d’utiliser des nombres de paramètres variables selon les couches du modèle. OpenELM peut ainsi mieux exploiter le budget de paramètres disponible (available parameter budget) pour atteindre une précision plus élevée.

3. Compensation de non-linéarité (Nonlinearity Compensation)

   • PanGu-$\pi$ analyse les modèles de langage récents afin de résoudre le problème de collapse des features (feature collapse problem). Ce problème, qui apparaît dans l’apprentissage de représentations de grande dimension comme dans les LLM, désigne le phénomène par lequel le modèle apprend des features identiques ou très similaires pour des entrées variées. Pour y remédier, PanGu-$\pi$ compense la non-linéarité de fonctions d’activation comme GELU ou ReLU, et met à l’échelle l’amplitude des sorties de couche afin de maintenir une variation de sortie constante.

> #### Principaux enseignements : la structure des modèles SLM fait ressortir deux observations majeures :
> 1. En août 2024, l’architecture SLM typique adopte GQA (Group-Query Attention), un FFN gated (Gated FFN) avec fonction d’activation SiLU, un taux d’expansion du FFN (Intermediate Ratio of FFN) compris entre 2 et 8, RMSNorm, ainsi qu’une taille de vocabulaire (Vocabulary Size) supérieure à 50 000. Toutefois, ces choix reposent principalement sur des constats empiriques et n’ont pas fait l’objet d’une validation rigoureuse et publique.
> 2. Les innovations concernant l’architecture Transformer dans les SLM restent limitées. À l’exception de la technique de partage Embedding-lm_head, aucun autre procédé ne montre de preuve solide de supériorité par rapport à l’architecture Transformer classique (Vanilla Transformer). En outre, ces approches ne sont ni largement adoptées ni véritablement étudiées par plusieurs groupes de recherche ou entreprises, ce qui nécessitera des vérifications ultérieures.

Jeu de données d’entraînement (Training Dataset)

Les performances des SLM dépendent fortement du jeu de données utilisé pour l’entraînement. Cette étude a examiné 12 jeux de données publics utilisés par les modèles SLM :

Nom	Nombre de tokens	Domaine principal	Description et usage
The Pile	825B	science, articles académiques, texte web, documents juridiques	Jeu de données combinant plusieurs petits ensembles de données et couvrant de nombreux domaines, utilisé pour améliorer la compréhension générale du modèle.
FineWeb-Edu	1.3T/5.4T	textes éducatifs, manuels, supports pédagogiques	Grand jeu de données constitué de textes éducatifs filtrés à partir de FineWeb, utilisé pour améliorer les performances du modèle sur les tâches liées à l’apprentissage et au domaine éducatif.
StarCoder	35B	code Python	Jeu de données contenant du code en langage de programmation Python, utilisé pour entraîner les modèles sur la génération de code et les tâches liées à la programmation.
Cosmopedia	25B	texte synthétique, supports pédagogiques	Jeu de données composé de texte synthétique, incluant des manuels, billets de blog, histoires et articles WikiHow, afin d’aider le modèle à apprendre divers styles d’écriture et contextes.
RefinedWeb	5T	documents web, articles de presse, blogs, documentation technique	Jeu de données issu d’un filtrage rigoureux de données web de haute qualité extraites de CommonCrawl, utilisé pour apprendre des connaissances de domaine variées dans les tâches de traitement du langage naturel.
RedPajama	1.2T	données web, actualités, réseaux sociaux	Contient un vaste volume de données textuelles extraites d’instantanés de CommonCrawl, utilisé pour l’entraînement de modèles fondés sur du texte web.
Dolma	-	texte anglais dédupliqué	Corpus anglais dédupliqué à l’aide de l’algorithme MinHash, utilisé pour optimiser les performances du modèle grâce à des données nettoyées des textes redondants.
WuDaoCorpora	4T	texte chinois	Grand corpus fondé sur des données en chinois, comprenant 3T de tokens de données d’entraînement et 1.08T de caractères chinois, utilisé pour l’entraînement de modèles de langue chinois.
RoBERTa CCNewsV2	-	articles de presse	Version mise à jour du jeu de données d’actualités de CommonCrawl, utilisée pour les tâches de traitement du langage naturel fondées sur des données d’actualité récentes.
PushShift Reddit	-	données de réseaux sociaux (posts Reddit)	Données collectées via une plateforme de collecte, d’analyse et de stockage de données Reddit, utilisées pour l’étude des interactions sur les réseaux sociaux et l’entraînement de modèles de langage conversationnels.
DCLM-baseline	1.35T	texte web	Corpus standardisé extrait de Common Crawl, utilisé comme jeu de données pour les modèles de langue préentraînés et adapté à diverses tâches d’évaluation.
CulturaX	6.3T	texte multilingue	Vaste jeu de données textuelles multilingues couvrant 167 langues, utilisé comme ressource textuelle à grande échelle pour l’entraînement de modèles multilingues.

En observant la tendance d’utilisation des jeux de données de préentraînement par les SLM étudiés entre 2022 et 2024, on constate ce qui suit :

En 2022 et 2023, le jeu de données de préentraînement le plus largement utilisé était The Pile, mais davantage de jeux de données ont récemment été proposés, élargissant les possibilités de choix. En 2024, The Pile n’est plus utilisé pour le préentraînement des SLM, tandis que des jeux de données comme RefinedWeb ou RedPajama sont de plus en plus largement employés. Cela montre que les efforts de recherche et d’ingénierie pour construire de meilleurs jeux de données de préentraînement sont particulièrement actifs.

Nous avons ensuite examiné les performances des SLM selon le jeu de données de préentraînement utilisé. Les SLM lancés au cours des trois dernières années ont été répartis en 4 groupes selon leur taille en paramètres (<1B / 1B-1.4B / 1.5-2B / 2.5B-3B), puis classés, au sein de chaque groupe, selon leur précision moyenne (moyenne de deux types de précision : raisonnement/compréhension de sens commun et résolution de problèmes). Les résultats sont les suivants :

Ces résultats montrent que deux jeux de données récents, DCLM(DataComp-LM) et FineWeb-Edu, affichent de meilleures performances que les autres. Leur point commun est d’adopter un filtrage des données fondé sur des modèles.

Par ailleurs, bien que les capacités de codage ne constituent pas la tâche principale des SLM déployés sur appareil, de nombreux jeux de données de préentraînement, comme StarCoder, incluent des données de code. Cela tient peut-être à la conviction répandue selon laquelle les données de code peuvent aider à améliorer les capacités de raisonnement du modèle.

Nous avons ensuite examiné le nombre de tokens utilisés pour le préentraînement et la taille du modèle, ainsi que le nombre de tokens utilisés pour le préentraînement et la précision moyenne.

Tout d’abord, selon la loi de Chinchilla (Chinchilla Law), qui étudie la relation entre la taille du modèle et la quantité de données d’entraînement utilisée (nombre de tokens), le ratio optimal entre le nombre de paramètres du modèle et le nombre de tokens d’entraînement devrait être d’environ 20. Par exemple, pour un modèle 1B, un jeu de données d’entraînement d’environ 20B tokens serait nécessaire.

Les résultats d’une analyse statistique de la taille des SLM lancés entre 2022 et 2024 et du nombre de tokens utilisés pour leur entraînement (figure ci-dessous, partie gauche (a)) montrent qu’en général, plus le modèle est grand, plus le nombre de tokens utilisés pour l’entraînement est élevé, et que les modèles les plus récents tendent à utiliser davantage de tokens d’entraînement. Point notable : quels que soient leur taille, les SLM sont entraînés sur un volume de tokens bien supérieur à celui recommandé par la loi de Chinchilla (généralement plus de 1.5T).

L’analyse du nombre de tokens utilisés par les SLM pour le préentraînement et de leur précision moyenne (figure ci-dessous, partie droite (b)) montre qu’il existe généralement une corrélation positive entre ces deux indicateurs, particulièrement marquée lorsque le nombre de tokens d’entraînement est inférieur à 700B. En revanche, lorsque les tokens d’entraînement dépassent 1T, la corrélation devient plus faible, car la qualité des données d’entraînement devient plus importante que leur quantité.

> #### Points clés : deux observations majeures ressortent des jeux de données d’entraînement des SLM :
> - La qualité des données d’entraînement est essentielle pour les performances des SLM, et elle suscite une attention croissante dans les recherches récentes sur les SLM. En général, son impact sur les SLM est plus important que celui de la quantité de données ou de l’architecture du modèle. Une tendance notable dans les travaux sur les jeux de données est l’utilisation de filtrage fondé sur des modèles, avec FineWeb-Edu (1.3T/5.4T) et DCLM-baseline (4T) comme principaux exemples. Les SLM entraînés sur ces deux jeux de données ont montré des performances compétitives par rapport à ceux entraînés sur des jeux de données privés.
> - Les SLM récents sont entraînés sur de très grands volumes de tokens (généralement 1.5T ou plus), indépendamment de la taille du modèle. Dans certains cas, des volumes plus faibles sont aussi utilisés. (Ex. Qwen2-0.5B a utilisé 12T tokens, tandis que Qwen2-1.5B n’en a utilisé que 7T.) Cela signifie qu’ils sont considérablement « surentraînés » (over-training) par rapport à la loi de Chinchilla ; ce surentraînement est utilisé pour déployer des SLM plus performants en investissant davantage de temps d’entraînement.

Algorithmes d’entraînement (Training Algorithm)

Il existe divers algorithmes pour l’entraînement des SLM. Parmi les principaux, on trouve la stratégie Maximal Update Parameterization (μP), la distillation de connaissances (Knowledge Distillation) et le pré-entraînement en deux étapes (Two Stage Pre-training).

1. Maximal Update Parameterization (μP) : cette méthode contrôle l’initialisation du modèle, le taux d’apprentissage par couche (layer-wise learning rate), l’amplitude des activations (activation magnitude), etc., afin de garantir un entraînement stable quelle que soit la largeur des couches du modèle (model's layer width). En plus d’améliorer la stabilité de l’entraînement, elle améliore la transférabilité (transferability) des hyperparamètres d’entraînement des petits modèles vers les grands modèles, ce qui permet notamment d’utiliser le même taux d’apprentissage (learning rate). Cerebras-GPT entraîne ses modèles avec cette technique.

2. Distillation de connaissances (Knowledge Distillation) : concept largement utilisé dans les grands modèles de langage (LLM), elle consiste à extraire des connaissances utiles d’un grand modèle enseignant complexe pour les transmettre à un modèle élève plus petit et plus efficace. Ces techniques de distillation de connaissances (KD) fonctionnent en minimisant l’écart entre les sorties des deux modèles ; l’essentiel est que le modèle élève apprenne de façon approximative le comportement et les prédictions du modèle enseignant. LaMini-GPT et Gemma-2 utilisent cette technique.

3. Pré-entraînement en deux étapes (Two Stage Pre-training) : comme son nom l’indique, il s’agit d’une stratégie d’entraînement en deux phases distinctes. D’abord, lors de la phase de pré-entraînement (Pretraining Phase), le modèle est entraîné sur de grandes quantités de données de faible qualité. Cette étape nécessite davantage de ressources de calcul. Ensuite, lors de la phase d’affinage (Annealing Phase), des données SFT (Supervised Fine-Tuning) de haute qualité, centrées sur des tâches spécifiques, sont mélangées aux données de pré-entraînement. MiniCPM utilise cette technique.

Capacités des SLM (Capabilities)

Jeux de données et métriques d’évaluation des SLM (Evaluation Datasets and Metrics)

Cette étude a organisé 12 jeux de données destinés à évaluer les performances des SLM en trois catégories : raisonnement de bon sens (Commonsense Reasoning), résolution de problèmes (Problem-Solving) et raisonnement mathématique (Mathematics) :

Nom	Type	Description et usage
HellaSwag	Raisonnement de bon sens	Teste la compréhension narrative et évalue la complétion possible de phrases.
TruthfulQA	Raisonnement de bon sens	Jeu de données qui évalue si le modèle évite de fournir des informations fausses.
Winogrande	Raisonnement de bon sens	Jeu de données qui évalue la capacité de raisonnement de bon sens à travers la résolution d’ambiguïtés pronominales.
CommonsenseQA	Raisonnement de bon sens	Propose des problèmes de raisonnement de bon sens sous forme de questions à choix multiples nécessitant des connaissances du quotidien.
PIQA	Raisonnement de bon sens	Jeu de données évaluant le raisonnement physique de bon sens et les interactions entre objets.
OpenBookQA	Raisonnement de bon sens	Contient des questions scientifiques ouvertes à résoudre en combinant connaissances scientifiques et bon sens.
BoolQ	Raisonnement de bon sens	Évalue les capacités de raisonnement de bon sens et factuel via des questions oui/non.
ARC Easy	Résolution de problèmes	Jeu de données contenant des questions scientifiques simples testant les connaissances générales et le raisonnement.
ARC Challenge	Résolution de problèmes	Propose des questions scientifiques complexes nécessitant une intégration des connaissances.
MMLU	Résolution de problèmes	Jeu de données évaluant la capacité de résolution de problèmes dans diverses disciplines académiques.
GSM8K	Raisonnement mathématique	Jeu de données évaluant le raisonnement mathématique de niveau école primaire.
Minerva Math	Raisonnement mathématique	Évalue les capacités avancées de raisonnement mathématique sur divers sujets.

Lors de l’évaluation, la principale métrique utilisée est l’exactitude (Accuracy), calculée comme le ratio entre le nombre de prédictions correctes et le nombre total d’exemples dans le jeu d’évaluation. Dans les domaines du raisonnement de bon sens, de la résolution de problèmes et des tâches mathématiques, on évalue si la bonne réponse a été choisie ou à quel point la solution fournie est exacte.

Performances globales des SLM (Overall Capabilities)

Des expériences ont été menées sur une sélection de SLM pour les trois tâches de raisonnement de bon sens, résolution de problèmes et mathématiques, et l’évolution a été analysée comme dans la figure ci-dessous. Globalement, une amélioration significative des performances a été observée, avec des gains respectifs de 10.4 %, 13.5 % et 13.5 % selon les tâches. À titre de comparaison, le modèle open source de grand langage LLaMA n’a progressé que de 7.5 % en moyenne sur la même période :

En particulier, la famille Phi de Microsoft, entraînée sur des jeux de données privés, a affiché de meilleures performances que tous les autres modèles, atteignant un niveau comparable à celui de LLaMA 3.1 récent en 7B (67.6 % en raisonnement de bon sens, 72.4 % en résolution de problèmes). Bien qu’un certain écart subsiste encore en mathématiques, l’écart entre SLM et LLM se réduit rapidement dans le domaine du raisonnement général. Bien qu’il existe des exceptions comme Qwen2, on observe généralement une tendance selon laquelle les performances augmentent avec la taille du modèle.

Certains SLM pionniers sont entraînés sur des jeux de données privés, mais l’écart entre modèles open source et modèles privés se réduit progressivement dans les tâches de raisonnement de bon sens. Par exemple, SmolLM et DCLM-1B affichent d’excellentes performances dans ce domaine grâce à des jeux de données de haute qualité comme DCLM et FineWeb-Edu (64.2 % et 63.8 % respectivement). En revanche, pour les tâches exigeant un raisonnement complexe ou logique, en particulier en mathématiques, un écart important demeure en raison du manque de jeux de données de haute qualité.

Principaux enseignements : 4 observations majeures sur l’évolution des SLM :

• De 2022 à 2024, les SLM ont connu des gains de performance significatifs sur diverses tâches de langage. Globalement, ils affichent des progrès notables et dépassent les améliorations de LLaMA-7B (versions 1/2/3/3.1). Ces résultats laissent espérer qu’ils pourront résoudre diverses tâches aval sur des appareils on-device.
• La famille de modèles Phi affiche de manière constante des performances de pointe (state-of-the-art) sur la plupart des tâches. Phi-3-mini a atteint, en septembre 2024, une précision comparable à celle de Llama-3.1-8B. Cette performance semble provenir du soin apporté par Microsoft à l’ingénierie des données, mais elle pourrait aussi être liée à un tuning instructionnel sur certains jeux de données et à un possible surapprentissage.
• En général, plus la taille du modèle est grande, meilleures sont les performances, même s’il existe des exceptions comme Qwen2-1.5B. Ces exceptions montrent que des modèles plus petits peuvent exceller sur certaines tâches spécifiques.
• Dans le domaine du raisonnement de bon sens, les performances des SLM entraînés sur des jeux de données open source réduisent l’écart avec les SLM propriétaires. Toutefois, un écart important subsiste encore sur les tâches nécessitant un raisonnement complexe ou logique, ce qui souligne le besoin de jeux de données axés sur le raisonnement mathématique.

Capacités d’apprentissage en contexte (In-Context Learning Capabilities)

L’apprentissage en contexte (In-Context Learning, ICL) est une capacité importante des SLM, qui leur permet d’effectuer de nouvelles tâches à partir du contexte d’entrée fourni. Des expériences sur les capacités d’apprentissage en contexte (ICL) ont été menées sur 8 tâches, incluant le raisonnement de bon sens et la résolution de problèmes, à l’aide de divers modèles et de leurs variantes en taille 2B. En général, les SLM ont pu tirer un avantage significatif sur l’ensemble des tâches. Toutefois, sur des jeux de données simples comme HellaSwag et PIQA, ils ont montré de manière exceptionnelle des performances similaires, quel que soit le nombre d’exemples ICL (ICL shots). En dehors de ces cas, l’apprentissage en contexte avec en moyenne 5 exemples (5-shots) améliore les performances zero-shot de 2,1 % sur l’ensemble des tâches.

Le modèle Gemma2, en particulier, a montré la plus forte progression avec un gain de précision de 4,8 %. À l’inverse, le modèle LaMini a présenté une baisse de performance supérieure à 2 %. Les auteurs émettent l’hypothèse que LaMini est surajusté à son jeu de données d’entraînement, si bien que la fourniture d’exemples supplémentaires peut introduire du bruit.

De manière générale, il a été confirmé que plus la taille d’un SLM augmente, plus ses performances en apprentissage en contexte (ICL capability) s’améliorent.

Principaux enseignements : 2 observations majeures sur les capacités d’apprentissage en contexte des SLM :

• En général, la plupart des SLM disposent d’un certain niveau de capacité d’apprentissage en contexte. Toutefois, cette capacité varie selon le type de tâche : la plupart des SLM progressent fortement sur la tâche Arc Challenge, mais les gains sont minimes sur HellaSwag ou PIQA.
• Plus la taille du modèle SLM est grande, plus sa capacité d’apprentissage en contexte tend à être forte par rapport aux petits modèles. Certains SLM de plus petite taille, comme LaMini, montrent même une dégradation des performances lorsqu’on utilise l’apprentissage en contexte.

Coût d’exécution (Runtime Cost) des SLM

Le coût d’exécution (Runtime Cost) des SLM inclut la latence et l’empreinte mémoire lors de l’exécution du modèle sur un appareil réel. Cette étude évalue les performances runtime des SLM et analyse les résultats d’expériences sur différents matériels. Elle explique également l’impact de l’architecture des modèles et de la quantization sur les performances, et traite de la manière dont les SLM peuvent être optimisés pour des environnements en temps réel.

Pour mesurer le coût d’exécution, deux types d’appareils edge ont été utilisés. Il s’agit de Jetson Orin, couramment utilisé sur des appareils edge comme les drones ou les petits robots, et des smartphones, largement utilisés au quotidien, avec les configurations suivantes :

Nom de l’appareil	Type de matériel	Spécifications
Jetson Orin NX 16GB	GPU	1024-core NVIDIA Ampere architecture GPU with 32 tensor cores, 16G DRAM
MEIZU 18Pro	CPU	Snapdragon 888, 8G RAM

Par ailleurs, comme les méthodes de mesure du nombre officiel de paramètres diffèrent selon les modèles, les auteurs ont utilisé les valeurs de paramètres obtenues depuis llama.cpp. Les mesures ont été séparées entre l’étape de prefill et l’étape de decode au moment de l’inférence et, sauf indication contraire, la longueur du prompt a été fixée à 50 et la longueur de génération de tokens à 50. En outre, pour éviter la baisse de performance due à la surchauffe (thermal throttling), les tests ont été effectués à 10 secondes d’intervalle, et une quantization 4-bit a été appliquée pour mesurer les modèles plus volumineux.

• Mesure de la latence : selon la taille du modèle, le temps de génération du premier token (prefill) ainsi que le temps de génération de chaque token suivant (decode) sont mesurés.
• Mesure de l’empreinte mémoire : l’utilisation du cache KV et des buffers mémoire est mesurée afin d’analyser la quantité de mémoire occupée par le modèle.

Vue d’ensemble du coût d’exécution (Overview)

Voici un aperçu de la latence d’inférence et de l’empreinte mémoire des SLM étudiés dans cette recherche :

• Inference Latency (latence d’inférence) : la latence d’inférence des SLM se divise en trois plages selon la taille du modèle : 0.1-1B, 1-2B et 2-3B. Au sein de ces plages, les modèles présentent des latences similaires. Plus précisément, l’architecture du modèle a aussi un impact important sur la latence. Par exemple, Qwen2-0.5B affiche un temps du premier token 1,46 fois plus long que d’autres modèles de même taille, tandis que Qwen1.5-0.5B présente au contraire des performances similaires à OpenELM-1.1B, un modèle pourtant plus grand.

  • Étape de prefill : phase où le prompt d’entrée est traité et où le cache KV est généré, avec traitement parallèle de plusieurs tokens.
  • Étape de decode : phase où le token suivant est prédit à partir de chaque token généré, nécessitant davantage de ressources mémoire.

• Memory Footprint (empreinte mémoire) : l’empreinte mémoire des SLM varie selon la taille du modèle et la longueur de contexte (context length). En particulier, des modèles comme Bloom-560M et Gemma-2B utilisent davantage de mémoire en raison d’une très grande taille de vocabulaire (256 000). À l’inverse, la série OpenELM économise l’usage mémoire en réduisant la taille du cache KV grâce à GQA (Group-Query Attention).

> #### Principaux enseignements : il y a 3 observations majeures concernant le coût d’exécution des SLM :
> - Outre la taille du modèle, son architecture influence aussi la latence. Par exemple, Qwen1.5-0.5B a 25,4 % de paramètres de plus que Qwen2-0.5B, mais s’exécute 31,9 % plus vite sur Jetson Orin. Cela signifie qu’au moment de développer un SLM, il faut l’adapter au matériel sur lequel il sera déployé.
> - L’impact de l’architecture du modèle sur la vitesse d’inférence est plus marqué pendant la phase de prefill que pendant la phase de decode. Cela s’explique par une densité de calcul plus élevée dans la phase de prefill, tandis que la phase de décodage dépend principalement de la mémoire (memory-bound). Les différences d’architecture ont plus facilement un effet dans les scénarios limités par le calcul (compute-bound). Par exemple, un modèle plus large et moins profond bénéficie d’un parallélisme de calcul plus élevé.
> - La consommation mémoire à l’exécution est généralement corrélée de façon linéaire à la taille du modèle. Toutefois, certains modèles avec un vocabulaire plus grand consomment davantage de mémoire que d’autres modèles de taille comparable. Par exemple, la famille Bloom a une taille de vocabulaire de 250 880, soit environ 5 à 8 fois plus que la plupart des autres modèles.

Impact de la quantification et du matériel (Impact of Quantization and Hardware)

Nous avons d’abord mesuré la latence du modèle Phi-1.5 avant quantification (FP16) et avec cinq méthodes de quantification (Q8_0, Q6_K, Q5_K, Q4_K_M, Q3_K), afin d’évaluer l’impact de la quantification sur le coût d’exécution des SLM :

Sur les appareils mobiles, la prise en charge des opérations int8 peut être limitée, mais il reste possible de réduire efficacement la surcharge des accès mémoire. Cela vient de la compression des données induite par la plus faible précision, qui améliore en conséquence l’utilisation du cache. Chaque méthode quantifie en n bits ; Qn_K et Qn_K_M utilisent une méthode k-quant pour quantifier en n bits des modèles avec un nombre intermédiaire de paramètres, tandis que Qn_0 désigne une quantification symétrique.

Effet de la quantification pendant la phase de prefill : lorsque la longueur du prompt est courte, la quantification réduit la latence d’au moins 25 %. Cependant, à mesure que la longueur du prompt augmente, cet effet diminue ; lorsque la longueur du prompt approche 50, les méthodes de quantification Q6_K et Q3_K affichent une latence similaire, voire supérieure, à celle du modèle FP16 non quantifié. Les méthodes Q8_0, Q4_K_M et Q5_K apportent des gains de performance stables, et Q4_K_M offre en particulier les meilleurs résultats, avec une réduction moyenne de latence de 50 %.

Effet de la quantification pendant la phase de decode : les gains de performance sont plus réguliers, avec une latence réduite jusqu’à 75 % et au minimum de 17 %. Comme pour la phase de prefill, la méthode Q4_K_M est la plus efficace, tandis que Q6_K est la moins performante.

> #### Principaux enseignements : il y a 2 observations majeures concernant l’impact de la quantification sur le coût d’exécution des SLM :
> - Les bénéfices de la quantification sont plus importants dans la phase de decode que dans la phase de prefill. Sur les appareils mobiles, la quantification réduit surtout la surcharge des accès mémoire. Comme la phase de decode est davantage affectée par la bande passante mémoire, elle bénéficie plus de la quantification que la phase de prefill, qui est davantage influencée par le calcul.
> - Plus la précision de quantification est régulière, meilleures sont les performances. La quantification en 3 bits offre un taux de compression plus élevé que la quantification en 4 bits, mais la quantification en 4 bits fournit de meilleures performances à la fois dans les phases de prefill et de decode. Les performances inférieures de la quantification en 3 bits s’expliquent par une prise en charge limitée des optimisations matérielles en raison d’une largeur de bit irrégulière (irregular bit-width), ainsi que par une surcharge supplémentaire liée à l’alignement et au padding des données. Ainsi, bien que son taux de compression soit plus faible, la quantification en 4 bits est plus efficace ; de la même manière, les quantifications en 5 bits et 6 bits, bien qu’elles offrent une compression plus élevée, présentent une latence d’inférence similaire ou supérieure à celle de la quantification en 8 bits.

Ensuite, nous avons testé le modèle Bloom-1B1 sur Jetson Orin NX 16GB (avec GPU) et Meizu 18 Pro (avec CPU) afin de mesurer l’impact du matériel sur le coût d’exécution des SLM :

Dans la phase de prefill, lorsque la longueur du prompt est courte, Jetson Orin est 10 à 20 fois plus rapide que le Meizu 18 Pro. De plus, à mesure que la longueur du prompt augmente, l’avantage de performance de Jetson devient encore plus net. Quand le prompt s’allonge, le temps nécessaire pour générer le premier token augmente linéairement sur les deux appareils, mais Jetson conserve des performances stables même avec des prompts plus longs.

Dans la phase de decode, à mesure que le nombre de tokens générés augmente, la latence par token du Meizu 18 Pro augmente fortement. En particulier, elle grimpe rapidement entre le premier et le dixième token, puis se stabilise. Cette forte hausse de latence sur le Meizu 18 Pro est due à l’augmentation de la température : le DVFS (Dynamic Voltage and Frequency Scaling) ou le thermal throttling ajustent la consommation électrique et la fréquence, ce qui réduit l’efficacité du calcul. À l’inverse, Jetson présente peu de variations de latence jusqu’à la génération de 30 tokens grâce à un système de refroidissement plus efficace, et ce n’est qu’ensuite qu’une augmentation de la latence est observée.

> #### Principaux enseignements : il y a 2 observations majeures concernant l’impact du matériel sur le coût d’exécution des SLM :
> - Alors que la phase de decode génère les tokens séquentiellement un par un, la phase de prefill permet de traiter en parallèle les tokens du prompt ; elle est donc nettement plus rapide sur GPU.
> - Sur les longues tâches d’inférence, Jetson offre une meilleure stabilité des performances qu’un smartphone. Cela s’explique par une dissipation thermique plus facile grâce à une architecture matérielle relativement plus simple.

Décomposition de la latence et de la mémoire (Latency and Memory Breakdown)

En affinant l’analyse de la latence, nous avons étudié, pour les modèles Qwen1.5-0.5B et Qwen2-0.5B, la part de chaque couche (layer) et de chaque opération dans la latence totale :

Les modèles Qwen1.5-0.5B et Qwen2-0.5B ont une taille comparable, mais présentent des différences de latence. Une analyse détaillée de cette latence a permis de mesurer la répartition du temps consacré à chaque couche (Embedding, Attention, FFN, LM_Head).

Dans la phase de prefill, pour le modèle Qwen1.5, la couche d’attention représente une part plus importante que la couche FFN. Cela vient du fait que l’augmentation de la taille du cache KV exige davantage de calculs dans la couche d’attention. En revanche, dans le modèle Qwen2, la couche FFN représente une part plus importante que la couche d’attention. Cela s’explique par le fait que la couche FFN du modèle Qwen2 est plus large.

Dans la phase de decode, la part des opérations d’attention devient encore plus importante dans le modèle Qwen1.5. En effet, les tokens générés interagissent avec les tokens générés précédemment, ce qui demande davantage de calculs ; cette tendance devient encore plus marquée à mesure que la taille du cache KV augmente. Dans le modèle Qwen2, la couche FFN reste celle qui prend le plus de temps, car sa largeur de calcul plus importante allonge sa durée d’exécution.

Si l’on analyse les opérateurs, on constate que, dans les deux modèles, l’opération de multiplication matrice-vecteur (matrix-vector multiplication, mul_mat_vec_q) représente à elle seule plus de 80 % du temps total de calcul. En particulier, dans le modèle Qwen2-0.5B, la couche FFN étant plus large, l’opération mul_mat_vec_q occupe une part encore plus importante.

Par ailleurs, l’analyse de l’utilisation de la mémoire (Memory) montre ce qui suit :

L’analyse souligne que, au-delà de la taille du modèle, la taille du vocabulaire (vocabulary size) a elle aussi un impact majeur sur l’utilisation mémoire. Plus le vocabulaire utilisé par le modèle est grand, plus la mémoire tampon de calcul (Compute Buffer) utilisée dans la couche de sortie est importante. Par exemple, le modèle Bloom-560M a une taille de vocabulaire de 250 880, ce qui porte la taille de son Compute Buffer à 492 Mo, soit une consommation mémoire 3,5 fois supérieure à celle d’OpenELM-1.1B, dont le vocabulaire est de 32 000.

Par ailleurs, les modèles qui utilisent le GQA (Group-Query Attention) ont un KV Cache plus petit que ceux qui utilisent le MHA (Multi-Head Attention). Par exemple, la taille du KV cache du modèle OpenELM-3B est de 164 Mo, soit environ 3,9 fois moins que celle du modèle StableLM-zephyr-3B.

Lorsque la longueur de contexte (context length) augmente, le Compute Buffer et le KV Cache deviennent les principaux facteurs déterminants de l’utilisation mémoire du modèle. Dans la série de modèles Qwen2, lorsque la longueur de contexte atteint 131 072, le Compute Buffer et le KV Cache représentent entre 83 % et 87 % de l’utilisation mémoire totale. À l’inverse, pour le modèle Qwen1.5, avec une longueur de contexte maximale de 32 768, ces deux éléments représentent entre 85 % et 90 % de la mémoire totale.

Cette analyse permet de comprendre clairement l’impact de la taille du vocabulaire (Vocabulary Size) et de la longueur de contexte (Context Length) sur l’utilisation mémoire des SLM : plus le vocabulaire est grand et plus le contexte est long, plus la consommation mémoire augmente rapidement.

Conclusion et pistes de recherche futures

Jusqu’ici, une étude complète et des mesures de performance ont été réalisées sur des petits modèles de langage (SLM) allant de 100M à 5B, en évaluant notamment leurs performances et leurs coûts d’exécution. Cela permet d’analyser les résultats actuels et les limites des SLM, tout en proposant plusieurs thèmes de recherche qui nécessiteront des travaux futurs :

• Co-conception et co-optimisation de l’architecture des SLM et des processeurs matériels (Co-design and co-optimizations of SLM architecture and device processors.) : les performances des SLM peuvent varier fortement, même à taille de modèle identique, selon la configuration de leur architecture. Par exemple, le ratio profondeur/largeur d’un Transformer, le type d’attention ou encore la fonction d’activation ont une influence très importante sur la vitesse d’exécution. Il est particulièrement important de trouver des méthodes pour quantifier les SLM afin qu’ils puissent s’exécuter efficacement sur des processeurs optimisés pour les opérations entières, comme les NPU (Neural Processing Unit). Pour atteindre les meilleurs compromis entre précision et vitesse, une conception et une optimisation adaptées à un matériel donné sont essentielles, et l’une des pistes possibles consiste à rechercher une architecture optimisée pour la vitesse avant le pré-entraînement.

• Construction de jeux de données synthétiques de haute qualité (Constructing high-quality synthetic dataset) : les jeux de données de pré-entraînement récemment publiés, comme DCLM et FineWeb-Edu, ont nettement amélioré les performances des SLM. Leur innovation clé consiste à utiliser des modèles pré-entraînés pour filtrer des données de haute qualité à partir de corpus massifs. La recherche sur les données synthétiques n’en est encore qu’à ses débuts et offre de nombreuses possibilités. Il est urgent de mettre en place des processus normalisés de gestion des données synthétiques, couvrant la déduplication, le filtrage, le mélange et l’évaluation.

• Extension de la loi de Chinchilla en tenant compte du déploiement sur appareil (A deployment-aware Chinchilla law for model scaling) : selon la loi de Chinchilla, l’optimisation des performances d’un modèle nécessite un équilibre entre la taille du modèle et la taille des données d’entraînement (nombre de tokens), d’environ 1:20. Mais les SLM doivent s’adapter à des capacités limitées en mémoire et en calcul sur les appareils, ce qui les conduit à utiliser des volumes de données d’entraînement bien plus importants. Cette approche est efficace jusqu’à un certain point, mais comme on ne peut pas augmenter indéfiniment la quantité de données d’entraînement, la recherche d’une méthode optimale de montée en échelle des données reste un problème ouvert. Il faut également prendre en compte non seulement la taille des données ainsi que les coûts d’entraînement et d’inférence, mais aussi le cycle de vie des SLM et leurs bénéfices économiques. L’application de la sparsité, par exemple via des architectures MoE (Mixture-of-Experts), rend encore le problème plus complexe.

• Apprentissage continu on-device pour la personnalisation (Continual on-device learning for personalization) : une fois déployés sur l’appareil, les SLM peuvent exploiter les données locales (On-Device Data) pour offrir de meilleures performances ou une personnalisation plus poussée, sans risque de fuite de données. Une première approche consiste à utiliser la technique RAG (Retrieval-Augmented Generation) pour injecter des données personnelles dans le prompt. Cette méthode augmente toutefois le temps de génération des embeddings textuels et le temps de traitement du prompt, tout en imposant de conserver durablement sur l’appareil les données nécessaires à la personnalisation. Une seconde approche consiste à effectuer un fine-tuning du SLM, afin d’intégrer les connaissances nécessaires à la personnalisation dans les poids du modèle, puis à supprimer les données après l’ajustement. Cependant, le fine-tuning on-device consomme beaucoup de mémoire et d’énergie, ce qui peut poser de graves problèmes de ressources. Des pistes de recherche existent, comme l’application d’une optimisation d’ordre zéro (zeroth-order optimization) pour éviter de stocker les activations en mémoire, tout en tirant parti des accélérateurs matériels à l’étape d’inférence.

• Collaboration entre SLM et LLM sur appareil et dans le cloud (Device-cloud SLM-LLM collaboration) : bien que les capacités des SLM progressent rapidement, l’écart avec les grands modèles de langage (LLM) exécutés dans le cloud demeure. Pour y remédier, la collaboration entre l’appareil et le cloud deviendra un sujet de recherche important. Intuitivement, le SLM pourrait traiter sur l’appareil les tâches simples qu’il sait résoudre, tandis que le LLM dans le cloud jouerait un rôle de relais pour les tâches complexes. Mais cela suppose un module décisionnel capable de distinguer ce que le SLM peut traiter de ce qu’il ne peut pas traiter, et des recherches supplémentaires seront nécessaires pour trouver la bonne forme de collaboration entre appareil et cloud.

• La question de l’équité dans l’évaluation des performances des SLM (Benchmarking SLMs fairly) : les SLM souffrent notamment de problèmes de surapprentissage sur des benchmarks largement utilisés comme GSM8k. De plus, comme beaucoup de SLM sont entraînés sur des jeux de données non publics, il est difficile de comparer leurs performances de manière équitable. Les SLM s’exécutent principalement on-device et sont donc amenés à accomplir des tâches différentes de celles réalisées dans le cloud. Les SLM déployés sur smartphone ont tendance à traiter des tâches sensibles aux données utilisateur, et comme ces tâches spécialisées (ad-hoc task) ne figurent pas dans les benchmarks existants, elles risquent d’être exclues d’éléments d’évaluation importants.

• SLM parcimonieux (Sparse SLMs) : il existe actuellement très peu de travaux appliquant la sparsité aux SLM. Cela s’explique par le fait que, comparés aux LLM, les SLM devraient présenter un niveau de sparsité relativement plus faible, ce qui peut limiter les gains en vitesse ou les économies mémoire associés à cette approche. En outre, les architectures fondées sur la sparsité, comme les MoE (Mixture-of-Experts), peuvent réduire l’usage mémoire au prix d’une complexité de calcul accrue, ce qui peut les rendre peu adaptées aux appareils soumis à de fortes contraintes mémoire. Il serait possible d’étendre davantage les SLM en exploitant le stockage externe des smartphones (par exemple la mémoire flash) pour y conserver des poids fixes (Cold Weights) et les charger à la demande, mais cette approche nécessite des recherches supplémentaires, notamment sur les problèmes de latence d’E/S et sur le maintien de la compatibilité avec des accélérateurs matériels hétérogènes.

Article de recherche complet sur les petits modèles de langage : Small Language Models: Survey, Measurements, and Insights

https://arxiv.org/abs/2409.15790

Site du projet

https://ubiquitouslearning.github.io/TinyLLMLeaderBoard/#/slm

Dépôt GitHub

https://github.com/UbiquitousLearning/SLM_Survey

---

Cet article est basé sur un texte rédigé à l’aide d’un modèle GPT ; il peut donc contenir des reformulations qui diffèrent du contenu ou de l’intention du texte original. Si le sujet vous intéresse, veuillez également consulter la source originale ! Si vous remarquez en lisant des passages maladroits ou incorrects, merci de nous le signaler en commentaire. 🤗

⚠️Publicité⚠️ : avez-vous trouvé utile cet article compilé par le groupe d’utilisateurs PyTorch Corée🇰🇷 ? Si vous vous inscrivez comme membre, nous vous enverrons les principaux articles par e-mail💌 ! (Le réglage par défaut est Weekly, mais vous pouvez aussi passer à Daily.)