MobileLLM : optimisation de modèles de langage de moins d’un milliard de paramètres pour des cas d’usage sur appareil

 (github.com/facebookresearch)
3 points par GN⁺ 2024-07-11 | 1 commentaires | Partager sur WhatsApp
  • Le dépôt MobileLLM fournit le code d’entraînement de l’article ICML 2024 « MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases » et traite de conceptions visant à améliorer la qualité de modèles de langage de moins d’un milliard de paramètres
  • La conception du modèle intègre SwiGLU, une structure profonde et fine, le partage des embeddings et la grouped-query attention pour constituer MobileLLM
  • MobileLLM-125M/350M a obtenu une hausse de précision de 2,7 %/4,3 % par rapport aux modèles SoTA 125M/350M existants sur des tâches de raisonnement de bon sens en zero-shot, et la version mise à jour montre aussi des résultats SoTA en 600M/1B/1.5B
  • Le code d’entraînement requiert Python 3.9 et PyTorch 2.0 ou supérieur, et pretrain.sh démarre avec torchrun sur un nœud 1x8 GPU ; si l’on augmente le nombre de nœuds ou la taille de batch, il faut augmenter le taux d’apprentissage de façon linéaire
  • Pour un entraînement sur 1T de tokens, le coût est d’environ 3 jours pour 125M, 6 jours pour 350M, 8 jours pour 600M, 12 jours pour 1B et 18 jours pour 1.5B sur 32 GPU NVIDIA A100 80G

Objectif de MobileLLM et périmètre de publication

  • MobileLLM est un dépôt contenant le code d’entraînement pour optimiser des modèles de langage de moins d’un milliard de paramètres pour des cas d’usage sur appareil
  • L’article de référence est MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases, publié à l’ICML 2024
  • L’objectif principal est de prendre en compte de manière globale plusieurs éléments de conception afin de créer des LLM de haute qualité avec moins d’un milliard de paramètres

Éléments de conception du modèle

  • MobileLLM intègre les éléments de conception suivants
    • Fonction d’activation SwiGLU
    • Architecture profonde et fine

    • Partage des embeddings

      • grouped-query attention
      • La version mise à jour indique que cette philosophie de conception s’étend aussi à des modèles plus grands, avec des résultats SoTA sur MobileLLM-600M/1B/1.5B

Publication et annonces sur les modèles suivants

  • Le 30 octobre 2024, les modèles MobileLLM ont été publiés sur HuggingFace
  • En septembre 2025, le travail de suivi MobileLLM-R1 a été publié
    • Avec environ 2T de tokens de préentraînement et moins de 5T de tokens au total, il égale ou dépasse les résultats de Qwen3-0.6B entraîné sur 36T de tokens sur MATH, GSM8K, MMLU et LiveCodeBench
    • Le code, les modèles, les données et la recette d’entraînement sont publiés
    • Une collection HuggingFace est proposée
  • En novembre 2025, MobileLLM-R1.5 a été publié
    • MobileLLM-R1.5-950M surpasse DeepSeek-R1-Distill-Qwen-1.5B sur tous les benchmarks de mathématiques et de code évalués
    • Le nombre de paramètres est plus faible, avec 0.95B contre 1.5B
  • En janvier 2026, MobileLLM-R1 a été accepté à l’ICLR 2026

Exécution et configuration de l’entraînement

  • Les prérequis sont Python 3.9, PyTorch 2.0 ou supérieur et pip install -r requirement.txt
  • Le prétraitement des données consiste à répartir un jeu de données tokenisé, ou à tokeniser son propre jeu de données puis à le distribuer selon le nombre total de nœuds d’entraînement
    • Chaque nœud est composé de 1x8 GPU
    • La structure des données place les fichiers xxx.jsonl sous basepath/1, basepath/2, ..., basepath/#nodes
    • Chaque ligne jsonl est une paire clé-valeur de données tokenisées sous la forme {"token_ids": [1,2,3,4,...]}
    • Le code d’entraînement est compatible avec la méthode de prétraitement de données de LLM360/amber-data-prep
  • pretrain.sh est un script qui lance l’entraînement avec torchrun dans une configuration 1x8 nœud
    • Il est possible d’adapter --nnodes et d’autres paramètres pour des configurations multi-nœuds comme Slurm ou TorchX
    • Le taux d’apprentissage du script est calibré pour 1x8 nœud et une taille de batch de 32
    • Si l’on augmente le nombre de nœuds ou la taille de batch, il faut augmenter linéairement le taux d’apprentissage
  • La procédure d’exécution consiste à définir --train_data_local_path dans pretrain.sh vers les données prétraitées, à définir --input_model_filename vers ./configs/{model_size}/, puis à exécuter bash pretrain.sh
  • L’évaluation Wiki s’exécute en téléchargeant le modèle, en mettant à jour le chemin du checkpoint dans eval.sh, puis en lançant bash eval.sh

Coût d’entraînement

  • Pour entraîner MobileLLM sur 1T de tokens, le temps nécessaire sur 32 GPU NVIDIA A100 80G est le suivant
    • 125M : environ 3 jours
    • 350M : environ 6 jours
    • 600M : environ 8 jours
    • 1B : environ 12 jours
    • 1.5B : environ 18 jours

Résultats en raisonnement de bon sens zero-shot

  • MobileLLM-125M obtient 46.3 en moyenne sur arc_easy, arc_challenge, boolq, piqa, siqa, hellaswag, obqa et winogrande
    • OPT-125M obtient 42.6, GPT-neo-125M 42.9 et Pythia-160M 42.5
    • MobileLLM-LS-125M obtient 47.0 en moyenne
  • MobileLLM-350M obtient 51.3 en moyenne
    • OPT-350M obtient 43.9 et Pythia-410M 46.6
    • MobileLLM-LS-350M obtient 52.1 en moyenne
  • MobileLLM-600M obtient 54.3 en moyenne
    • Qwen1.5-500M obtient 48.8, BLOOM-560M 44.2 et MobiLlama-800M 50.7
  • MobileLLM-1B obtient 57.3 en moyenne
    • Pythia-1B obtient 48.7, MobiLlama-1B 55.2, Falcon-1B 56.3, BLOOM-1.1B 46.9 et TinyLlama-1.1B 54.2
  • MobileLLM-1.5B obtient 59.4 en moyenne
    • GPT-neo-1.3B obtient 50.6, OPT-1.3B 52.3, BLOOM-1.7B 49.6 et Qwen1.5-1.8B 56.5
    • GPT-neo-2.7B obtient 52.8, OPT-2.7B 55.1, Pythia-2.8B 55.8 et BLOOM-3B 52.3

Projets liés et licence

  • Le code repose en partie sur le dépôt HuggingFace Transformers, qui utilise la licence Apache
  • Les projets liés suivants sont mentionnés
    • SpinQuant: LLM Quantization with Learned Rotations, ICLR 2025 — Paper, Code
    • LLM-QAT: Data-Free Quantization Aware Training for Large Language Models — Paper, Code
  • Comme étape suivante, MobileLLM-R1 et les modèles MobileLLM-R1.5 sont présentés
  • MobileLLM utilise actuellement la licence FAIR NC

À lire aussi

1 commentaires

 
GN⁺ 2024-07-11
Avis sur Hacker News

  • Les petits modèles se sont un peu améliorés, mais ils semblent encore insuffisants pour les mêmes usages que les modèles en ligne. Cela dit, le progrès incrémental en soi est appréciable.
    Le modèle à 1,5 milliard de paramètres ressemble à un saut assez important, et il bat aussi les modèles plus grands avec une large marge. Je ne sais pas pourquoi ils ne l’ont pas fait plus grand. Un modèle plus efficace qui tienne sur du matériel du niveau d’un Raspberry Pi pourrait changer la donne. De mémoire, TinyLlama 7B tourne tout juste

    • Des modèles de langage plus petits pourraient aussi être utiles comme partie d’un système de reconnaissance vocale. Dans des situations ambiguës ou bruitées, un modèle de langage peut aider à réduire le champ des mots qui ont été prononcés
    • Imaginez qu’un tel modèle soit intégré à l’app Instagram et utilisé pour le ciblage publicitaire via des calculs sur l’appareil de l’utilisateur. Facebook pourrait alors consulter beaucoup plus de données, à moindre coût et avec un risque juridique bien plus faible.
      Pour cet usage, comparer un petit modèle à un modèle cloud n’est pas vraiment équitable. Même une légère hausse de précision d’un petit modèle peut être significative et se traduire directement en revenus
    • Je ne suis pas sûr que le Raspberry Pi soit la bonne cible pour la prochaine étape des LLM locaux, et le déploiement web via des moteurs comme WebLLM mérite aussi d’être envisagé https://github.com/mlc-ai/web-llm
      Même si un modèle 7B “tourne bien” sur Raspberry Pi, personnellement je le trouve un peu gros à télécharger et exécuter dans une interface web. En revanche, un bon modèle 125M peut tourner dans une page web, et le temps de téléchargement comme le coût en bande passante vers un navigateur local restent raisonnables
    • Llama-3-8b tourne bien sur Raspberry Pi

  • Faut-il vraiment que ce soit uniquement sur des appareils mobiles ? C’est un cas d’usage de niche, mais si cela ne consomme pas trop de ressources, ça pourrait servir dans les jeux pour rendre les dialogues des PNJ plus intéressants.
    Mieux encore, ce serait bien de pouvoir les ajuster d’une manière ou d’une autre afin que les dialogues influencent le comportement ou les actions des PNJ

    • Ces dialogues seraient-ils vraiment intéressants ? On pourrait augmenter leur volume, mais je me demande s’il y aurait une base capable d’intéresser le joueur. Par exemple, des villageois pourraient parler du paysage local ou de leurs relations avec d’autres PNJ, mais les choses qu’ils décrivent pourraient ne pas exister réellement dans le jeu. Personnellement, si un PNJ commence à inventer des choses qui n’existent pas, je trouverais ça bizarre.
      On peut imaginer entraîner un LLM sur les données du jeu pour que les PNJ décrivent le monde réel du jeu. Mais je ne sais pas à partir de quelle échelle cela deviendrait moins cher que de simplement faire écrire les répliques par des humains. À l’échelle d’Ubisoft, c’est peut-être possible. À ma connaissance, Ubisoft a aussi exploré l’écriture par IA, mais surtout pour des usages très répétitifs et quasiment assimilables à du bruit, comme les cris pendant les combats
    • Ce serait intéressant que les PNJ aient davantage d’histoires de fond et des comportements plus complexes. Cela dit, comme n’importe quoi pourrait influencer leur comportement, les tests deviendraient probablement presque impossibles

  • Quelles apps permettent aujourd’hui de faire tourner ce genre de modèle sur iPhone ? Je ne connais que MLC, mais il n’y a que trois vieux modèles dedans

  • Je me demande jusqu’où on peut pousser l’approche consistant à faire des modèles plus profonds et plus étroits. À un moment donné, si tout le FFN tient dans le cache L2, j’imagine qu’il pourrait y avoir une zone où les performances bondissent nettement

    • D’autres travaux de Meta FAIR suggèrent qu’au contraire, pour augmenter les performances tout en conservant la précision, il faut élaguer les couches profondes https://arxiv.org/html/2403.17887v1
      Dans ce cas, il devrait exister une limite, pour les petits réseaux, au-delà de laquelle cette approche fonctionne. Sinon, les résultats se contredisent. Ou bien cela pourrait vouloir dire que ces nouveaux modèles peuvent encore être largement améliorés
    • Cela me rappelle les résultats de l’article de Google sur EfficientT5 https://arxiv.org/abs/2109.10686. Ils appellent cela “DeepNarrow”

  • Je rate peut-être quelque chose, mais est-ce que quelque chose comme la distillation de connaissances n’aiderait pas ici ?

    • L’article dit qu’ils l’ont essayé : https://arxiv.org/abs/2402.14905
      Lien profond HTML vers la section pertinente : https://ar5iv.labs.arxiv.org/html/2402.14905#S3.SS5
      “Jusqu’à présent, nous avons entraîné les petits modèles depuis zéro en utilisant le token suivant comme étiquette dure. Nous avons aussi exploré la distillation de connaissances (KD)... Malheureusement, la KD augmente le temps d’entraînement (2,6 à 3,2 fois plus lent) et a montré une précision similaire ou inférieure à l’entraînement basé sur les étiquettes (voir l’annexe pour plus de détails).”

  • En ce moment, j’ai réellement besoin d’une reconnaissance vocale de type wake-word sur appareil. Quel est le modèle au WER le plus faible qui puisse tourner sur un Raspberry Pi 4B ? Je regarde openWakeWord pour un système d’inventaire DIY

  • Il semble que, pour les petits modèles, la plus forte réduction de taille vienne du partage des embeddings / tying des poids entre la tête linéaire et les embeddings de tokens. Je me demande s’il y a des recherches en cours pour réduire encore davantage à ce niveau-là.

    • Si cela signifie que la LM-head est simplement une matrice d’embedding inversée, alors c’est déjà ce qui se faisait dans GPT-2.
      Malheureusement, tout ce que j’ai trouvé à ce sujet se résume à dire que les grands modèles tirent bénéfice d’une couche séparée. Cela dit, c’est quelque chose que j’ai vu quelque part sur Discord, donc je n’ai pas d’article à lire, et mon intuition personnelle est que cela devrait aussi fonctionner pour les grands modèles. Après tout, GPT-3 n’était qu’un GPT-2 agrandi.
      Dans mes expériences personnelles, quand je donnais au modèle une tâche plus difficile, il apprenait mieux. Les poids liés pourraient faire partie de ces contraintes, tout comme la prédiction multi-token, et on peut aussi voir bitnet de cette manière. Le dropout aussi.

  • Et si, sur desktop, ce n’était pas de l’IA générative, mais simplement de l’IA desktop ? J’aimerais qu’elle organise tous mes fichiers, e-mails et notes, et me permette de rechercher des informations dans mes données.

  • Intéressant. Peut-on aussi utiliser ça pour entraîner un modèle pour PC Windows ? Je n’ai pas beaucoup de RAM.

    • L’entraînement de modèles ne dépend pas du système d’exploitation. La RAM nécessaire dépend de la taille, et à ce niveau, je pense que ce serait bien plus facile à fine-tuner avec moins de RAM GPU.
      Cela dit, l’objectif final sera très probablement de télécharger ce genre de modèle, ou de payer pour en obtenir un fine-tuné, puis de l’utiliser via une puce neuronale optimisée.
      À ce stade, la question est plutôt de savoir quand cela arrivera. Les dernières certifications Windows exigent déjà un certain type de puce neuronale, et mon Google Pixel 8 Pro peut aussi héberger un petit modèle. Le Pixel n’est pas un téléphone bon marché, mais un coprocesseur coûtera bien moins cher qu’un gros GPU.

  • C’est intéressant, mais en dehors d’une meilleure autocomplétion, je me demande à quoi ça pourrait servir.

    • On pourrait probablement les fine-tuner pour des tâches très ciblées, comme tiny-agent https://bair.berkeley.edu/blog/2024/05/29/tiny-agent/
      J’aime bien l’approche qu’Apple semble adopter. Les tâches du quotidien sont traitées par de petits modèles fine-tunés, et ce qu’ils ne peuvent pas gérer avec confiance est transmis à un grand modèle hors de l’appareil. On pourrait constituer un jeu d’entraînement incluant des exemples où il faut produire une réponse de faible confiance, puis ajouter une sortie correspondant en pratique à une « demande d’aide », afin que le modèle apprenne à choisir cette option. Avec de petits modèles, on pourrait en exécuter plusieurs en parallèle, et un autre modèle pourrait router la requête vers l’expert approprié.
    • Des choses comme lire des e-mails, répondre à des e-mails, planifier des rendez-vous, utiliser des API de services.
      En gros, toutes les tâches qui demandent une action plutôt que de la connaissance. Si je dis « préviens ma femme que je serai en retard », il interagirait avec un service d’une façon magique déjà configurée pour s’en occuper.
      Siri gère assez bien la domotique même sans Internet, mais l’ancien Google Assistant et Alexa ne le faisaient pas du tout, et je ne crois pas qu’ils aient jamais pu le faire hors ligne. Cela permettrait d’avoir un assistant local-first qui fonctionne bien.
    • Un agent local comme Siri pourrait gérer des tâches simples et router les demandes plus complexes.
    • On peut le fine-tuner pour des tâches liées à l’appareil. Autrement dit, un petit modèle pourrait, en pratique, utiliser toutes les fonctionnalités offertes par les applications ou services de l’appareil.
      Il peut transmettre les demandes utilisateur en langage naturel aux applications concernées et coordonner ces applications. Les demandes qui dépassent les capacités de l’appareil peuvent être envoyées à un modèle cloud. C’est puissant, car cela peut changer la manière dont on interagit avec son appareil.
    • J’ai testé Google AI sur mon téléphone : alors que le navigateur était ouvert, je lui ai demandé de lire la page, et il m’a répondu qu’il ne pouvait pas accéder à Internet.
      L’assistant IA que je veux devrait 1) comprendre l’anglais et ma langue maternelle, 2) savoir qu’il s’exécute sur Android ou KDE/Linux et comprendre des commandes comme « ouvre la section Applications des paramètres Android », « lis la page ouverte dans le navigateur », « lis le texte de la popup actuellement ouverte », tout en étant intégré au système d’exploitation via des API publiques. Les grandes entreprises d’IA pourraient se faire concurrence en vendant de meilleurs assistants, en particulier aux utilisateurs multilingues.
      3) Le modèle doit être petit et n’a pas besoin de connaître la géographie, l’histoire ou des groupes de musique. Il suffit qu’il ait la possibilité de transmettre les tâches sur lesquelles l’utilisateur l’interroge à un moteur de recherche ou à un LLM en ligne.