MobileLLM: Optimierung von Sprachmodellen mit weniger als einer Milliarde Parametern für On-Device-Anwendungsfälle

• Das MobileLLM-Repository stellt den Trainingscode zum ICML-2024-Paper „MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases“ bereit und behandelt Designansätze zur Steigerung der Qualität von Sprachmodellen mit weniger als 1 Milliarde Parametern
• Das Modelldesign integriert SwiGLU, eine tiefe und schmale Struktur, geteilte Embeddings und grouped-query attention zur Konfiguration von MobileLLM
• MobileLLM-125M/350M erreichten bei Zero-Shot-Common-Sense-Reasoning-Aufgaben gegenüber den bisherigen 125M/350M-SoTA-Modellen jeweils 2,7 %/4,3 % höhere Genauigkeit; die aktualisierte Version zeigt auch bei 600M/1B/1.5B SoTA-Ergebnisse
• Der Trainingscode erfordert Python 3.9 und PyTorch 2.0 oder höher; pretrain.sh startet per torchrun auf einem 1x8-GPU-Knoten, und bei mehr Knoten oder größerer Batch-Größe muss die Lernrate linear erhöht werden
• Die Trainingskosten für 1T Token betragen auf 32 NVIDIA A100 80G GPUs etwa 3 Tage für 125M, 6 Tage für 350M, 8 Tage für 600M, 12 Tage für 1B und 18 Tage für 1.5B

---

Ziel und Umfang der Veröffentlichung von MobileLLM

• MobileLLM ist ein Repository mit Trainingscode zur Optimierung von Sprachmodellen mit weniger als einer Milliarde Parametern für On-Device-Anwendungsfälle
• Das zugrunde liegende Paper ist MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases und wurde auf der ICML 2024 veröffentlicht
• Das zentrale Ziel ist es, auch mit weniger als 1 Milliarde Parametern hochwertige LLMs zu entwickeln, indem mehrere Designelemente ganzheitlich berücksichtigt werden

Elemente des Modelldesigns

• MobileLLM integriert die folgenden Designelemente
  • SwiGLU-Aktivierungsfunktion
  • tiefe und schmale Architektur

  • geteilte Embeddings

    • grouped-query attention
    • In der aktualisierten Version wird dargestellt, dass sich diese Designphilosophie auch auf größere Modelle ausweiten lässt; MobileLLM-600M/1B/1.5B zeigen SoTA-Ergebnisse

Veröffentlichung und Nachrichten zu Nachfolgemodellen

• Am 30. Oktober 2024 wurden MobileLLM-Modelle auf HuggingFace veröffentlicht
• Im September 2025 wurde die Nachfolgearbeit MobileLLM-R1 veröffentlicht
  • Mit etwa 2T Pretraining-Token und insgesamt weniger als 5T Token erreicht oder übertrifft sie bei MATH, GSM8K, MMLU und LiveCodeBench die Ergebnisse von Qwen3-0.6B mit 36T Token
  • Code, Modelle, Daten und Trainingsrezepte wurden veröffentlicht
  • Eine HuggingFace-Kollektion wird bereitgestellt
• Im November 2025 wurde MobileLLM-R1.5 veröffentlicht
  • MobileLLM-R1.5-950M übertrifft DeepSeek-R1-Distill-Qwen-1.5B in allen bewerteten Mathematik- und Coding-Benchmarks
  • Die Parameterzahl ist mit 0.95B gegenüber 1.5B geringer
• Im Januar 2026 wurde MobileLLM-R1 für die ICLR 2026 angenommen

Ausführung und Trainingskonfiguration

• Voraussetzungen sind Python 3.9, PyTorch 2.0 oder höher und pip install -r requirement.txt
• Die Datenvorverarbeitung erfolgt, indem tokenisierte Datensätze aufgeteilt oder eigene Datensätze tokenisiert und dann passend zur Gesamtzahl der Trainingsknoten verteilt werden
  • Jeder Knoten besteht aus 1x8 GPU
  • Die Datenstruktur legt xxx.jsonl-Dateien unter basepath/1, basepath/2, ..., basepath/#nodes ab
  • Jede jsonl-Zeile ist ein Schlüssel-Wert-Paar tokenisierter Daten im Format {"token_ids": [1,2,3,4,...]}
  • Der Trainingscode ist mit der Datenvorverarbeitungsmethode von LLM360/amber-data-prep kompatibel
• pretrain.sh ist ein Skript, das das Training in einer 1x8-Knotenkonfiguration mit torchrun startet
  • Durch Anpassen von --nnodes und weiteren Einstellungen kann es auf Multi-Node-Konfigurationen wie Slurm oder TorchX zugeschnitten werden
  • Die Lernrate im Skript gilt für 1x8 Knoten und Batch-Größe 32
  • Wenn die Anzahl der Knoten oder die Batch-Größe erhöht wird, muss die Lernrate linear skaliert werden
• Der Ablauf besteht darin, in pretrain.sh --train_data_local_path auf die vorverarbeiteten Daten zu setzen, --input_model_filename auf ./configs/{model_size}/ zu setzen und danach bash pretrain.sh auszuführen
• Die Wiki-Evaluierung wird ausgeführt, indem das Modell heruntergeladen, der Checkpoint-Pfad in eval.sh aktualisiert und anschließend bash eval.sh gestartet wird

Trainingskosten

• Beim Training von MobileLLM mit 1T Token auf 32 NVIDIA A100 80G GPUs ergibt sich folgende benötigte Zeit
  • 125M: etwa 3 Tage
  • 350M: etwa 6 Tage
  • 600M: etwa 8 Tage
  • 1B: etwa 12 Tage
  • 1.5B: etwa 18 Tage

Ergebnisse beim Zero-Shot-Common-Sense-Reasoning

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

Verwandte Projekte und Lizenz

• Der Code basiert teilweise auf dem HuggingFace-Repository Transformers, das die Apache License verwendet
• Als verwandte Projekte werden folgende genannt
  • SpinQuant: LLM Quantization with Learned Rotations, ICLR 2025 — Paper, Code
  • LLM-QAT: Data-Free Quantization Aware Training for Large Language Models — Paper, Code
• Als nächster Schritt werden MobileLLM-R1 und die MobileLLM-R1.5-Modelle genannt
  • MobileLLM-R1: Paper, Code, Models
  • MobileLLM-R1.5: Models
• MobileLLM verwendet derzeit die FAIR NC-Lizenz

[GN⁺]

Hacker-News-Kommentare

• Kleine Modelle haben sich etwas verbessert, wirken aber noch unzureichend, um sie für dieselben Zwecke wie Online-Modelle einzusetzen. Trotzdem ist der schrittweise Fortschritt an sich gut.
  Ein Modell mit 1,5 Milliarden Parametern wirkt wie ein ziemlich großer Sprung und schlägt auch größere Modelle mit deutlichem Abstand. Ich weiß nicht, warum man es nicht noch größer gemacht hat. Effizientere Modelle, die auf Hardware wie einen Raspberry Pi passen, könnten die Spielregeln ändern. Soweit ich mich erinnere, lässt sich selbst TinyLlama 7B gerade so ausführen.

  • Noch kleinere Sprachmodelle könnten auch als Teil von Spracherkennungssystemen nützlich sein. In uneindeutigen oder verrauschten Situationen kann ein Sprachmodell dabei helfen einzugrenzen, welches Wort gesagt wurde.
  • Man kann sich vorstellen, dass ein solches Modell in die Instagram-App eingebettet wird und mit Berechnungen auf dem Gerät der Nutzer für Ad-Targeting eingesetzt wird. Dann könnte Facebook deutlich mehr Daten zu geringeren Kosten und mit viel geringerem Prozessrisiko einsehen.
    Für diesen Zweck ist es nicht fair, ein kleines Modell mit einem Cloud-Modell zu vergleichen. Schon eine kleine Verbesserung der Präzision eines kleinen Modells kann relevant sein und sich direkt in Umsatz übersetzen.
  • Ich bin mir nicht sicher, ob der Raspberry Pi das richtige Ziel für die nächste Stufe lokaler LLMs ist; auch die Auslieferung im Web über Engines wie WebLLM ist eine Überlegung wert: https://github.com/mlc-ai/web-llm
    Selbst wenn ein 7B-Modell auf einem Raspberry Pi „gut läuft“, ist mir persönlich ein 7B-Modell etwas zu groß, um es über ein webbasiertes Interface herunterzuladen und auszuführen. Ein ordentliches 125M-Modell dagegen lässt sich auf einer Webseite betreiben, und auch Downloadzeit sowie Bandbreitenkosten für den lokalen Browser sind nicht übertrieben.
  • Llama-3-8b läuft gut auf dem Raspberry Pi.

• Muss das unbedingt nur auf Mobilgeräten sein? Es ist zwar ein Nischenanwendungsfall, aber wenn es nicht viele Ressourcen frisst, könnte man es in Spielen nutzen, um NPC-Dialoge interessanter zu machen.
  Noch besser wäre es, wenn man es irgendwie so tunen könnte, dass die Gespräche das Verhalten oder die Aktionen der NPCs beeinflussen.

  • Wären diese Dialoge wirklich interessant? Man könnte zwar die Dialogmenge erhöhen, aber ich frage mich, ob es eine Grundlage gäbe, die Spieler interessant finden. Zum Beispiel könnten Dorfbewohner über die lokale Landschaft oder ihre Beziehungen zu anderen NPCs sprechen, aber die Dinge, die sie beschreiben, existieren möglicherweise gar nicht im eigentlichen Spiel. Persönlich fände ich es seltsam, wenn NPCs anfangen würden, Dinge zu erfinden, die es nicht gibt.
    Ich kann mir vorstellen, ein LLM mit Spieldaten zu trainieren, damit NPCs die tatsächliche Spielwelt beschreiben. Aber ich weiß nicht, welche Größenordnung nötig wäre, damit das günstiger wird, als Menschen Dialoge schreiben zu lassen. Bei der Größenordnung von Ubisoft könnte es vielleicht möglich sein. Soweit ich weiß, hat auch Ubisoft KI-gestütztes Schreiben untersucht, aber hauptsächlich für sehr repetitive und im Grunde rauschartige Zwecke wie Zurufe im Kampf.
  • Es wäre interessant, wenn NPCs mehr Hintergrundgeschichte und komplexeres Verhalten bekämen. Allerdings kann ja alles irgendwie ihr Verhalten beeinflussen, daher dürfte Testen nahezu unmöglich werden.

• Welche Apps gibt es derzeit, die solche Modelle auf dem iPhone ausführen können? Ich kenne nur MLC, und dort gibt es nur drei alte Modelle.

  • Das Android-APK von MLC wird häufig mit eingebauten aktuellen Modellen aktualisiert. Auf dem Samsung S24+ lassen sich auch 7–8B-Modelle bequem mit vernünftiger Geschwindigkeit ausführen, ungefähr 10 Tokens pro Sekunde.
    https://llm.mlc.ai/docs/deploy/android.html
  • Ich habe eine auf mlc-llm basierende App in den App Store gestellt, die mehr als 20 Modelle unterstützt, darunter auch aktuelle Modelle.
  • cnvrs führt GGUF unter iOS aus: https://testflight.apple.com/join/ERFxInZg
  • MLC-Modelle gibt es auch hier: https://huggingface.co/mlc-ai

• Ich frage mich, wie weit man den Ansatz, Modelle tiefer und schmaler zu machen, treiben kann. Irgendwann, wenn das ganze FFN in den L2-Cache passt, dürfte es einen Bereich geben, in dem die Performance ziemlich deutlich springt.

  • Andere Forschung von Meta FAIR deutet darauf hin, dass man, um die Genauigkeit zu erhalten und gleichzeitig die Performance zu steigern, eher tiefe Schichten prunen sollte: https://arxiv.org/html/2403.17887v1
    Dann müsste es eine Grenze für kleine Netzwerke geben, bei denen dieser Ansatz funktioniert. Andernfalls widersprechen sich die Ergebnisse. Oder es könnte bedeuten, dass sich diese neuen Modelle noch deutlich weiter verbessern lassen.
  • Das erinnert an die Ergebnisse aus Googles EfficientT5-Paper: https://arxiv.org/abs/2109.10686. Dort nennen sie es „DeepNarrow“.

• Vielleicht übersehe ich etwas, aber würde hier nicht so etwas wie Knowledge Distillation helfen?

  • Im Paper steht, dass sie das versucht haben: https://arxiv.org/abs/2402.14905
    HTML-Deeplink zum relevanten Abschnitt: https://ar5iv.labs.arxiv.org/html/2402.14905#S3.SS5
    „Bisher haben wir kleine Modelle von Grund auf trainiert und dabei das nächste Token als hartes Label verwendet. Wir haben auch Knowledge Distillation (KD) untersucht ... Leider erhöht KD die Trainingszeit (2,6- bis 3,2-mal langsamer) und zeigte eine ähnliche oder niedrigere Genauigkeit als labelbasiertes Training (Details im Anhang).“

• Ich brauche derzeit tatsächlich On-Device-Spracherkennung ähnlich einem Wake Word. Welches Modell, das auf einem Raspberry Pi 4B laufen kann, hat die niedrigste WER? Ich schaue mir openWakeWord für ein DIY-Inventarsystem an.

• Kleine Modelle scheinen ihre Größe am stärksten durch Embedding-Sharing/Weight Tying zwischen linearem Head und Token-Embeddings zu reduzieren. Ich frage mich, ob daran geforscht wird, dort noch weiter zu verkleinern.

  • Wenn damit gemeint ist, dass der LM-Head einfach die umgedrehte Embedding-Matrix ist, dann wurde das bereits bei GPT-2 gemacht.
    Leider habe ich dazu nur gefunden, dass große Modelle von einer separaten Schicht profitieren. Das war allerdings etwas, das ich irgendwo auf Discord gesehen habe, daher habe ich kein Paper zum Nachlesen; meinem persönlichen Gefühl nach sollte es aber auch bei großen Modellen funktionieren. Schließlich war GPT-3 letztlich auch eine hochskalierte Version von GPT-2.
    In meinen eigenen Experimenten lernte das Modell besser, wenn man ihm schwierigere Aufgaben gab. Gebundene Gewichte könnten so etwas sein, Multi-Token Prediction ebenfalls, und bitnet kann man auch so betrachten. Dropout genauso.

• Wie wäre es auf dem Desktop nicht mit generativer AI, sondern einfach mit Desktop-AI? Es wäre gut, wenn sie all meine Dateien, E-Mails und Notizen organisiert und Informationen in meinen Daten sucht.

• Klingt gut. Kann man das auch zum Trainieren von Modellen für Windows-PCs verwenden? Ich habe nicht viel RAM.

  • Modelltraining ist nicht vom Betriebssystem abhängig. Der RAM-Bedarf hängt von der Größe ab, und bei dieser Größenordnung dürfte Fine-Tuning mit deutlich weniger GPU-RAM viel einfacher sein.
    Trotzdem dürfte das Endziel eher sein, solche Modelle herunterzuladen oder nach bezahltem Fine-Tuning zu bekommen und sie dann über optimierte Neural-Network-Chips zu nutzen.
    Im Moment ist es eher eine Frage, wann das passiert. Die neuesten Windows-Zertifizierungen verlangen bereits irgendeine Art Neural-Network-Chip, und mein Google Pixel 8 Pro kann ebenfalls kleine Modelle hosten. Das Pixel ist kein günstiges Smartphone, aber ein Co-Prozessor dürfte deutlich billiger sein als eine große GPU.

• Interessant ist es schon, aber ich frage mich, wofür man es außer besserer Autovervollständigung nutzen würde.

  • Es dürfte sich für eng umrissene Aufgaben wie tiny-agent fine-tunen lassen https://bair.berkeley.edu/blog/2024/05/29/tiny-agent/
    Mir gefällt der Ansatz, den Apple offenbar verfolgt: Alltagsaufgaben werden von kleinen, fine-getunten Modellen erledigt, und Dinge, die sie nicht mit hoher Sicherheit bearbeiten können, werden an ein großes Modell außerhalb des Geräts weitergereicht. Man könnte ein Trainingsset mit Beispielen erstellen, in denen eine Antwort mit niedriger Sicherheit ausgegeben werden müsste, und eine Ausgabe hinzufügen, die faktisch einem „um Hilfe bitten“ entspricht, sodass das Modell lernt, diese Option zu wählen. Bei kleinen Modellen könnte man mehrere parallel laufen lassen und ein weiteres Modell die Anfrage an den passenden Experten routen lassen.
  • Dinge wie E-Mails lesen, E-Mails beantworten, Termine planen und Service-APIs verwenden.
    Im Grunde alle Aufgaben, bei denen es nicht um Wissen, sondern um Handlungen geht. Wenn man sagt: „Sag meiner Frau, dass ich mich verspäte“, spricht es auf eine eingerichtete, magische Weise mit irgendeinem Dienst und erledigt es.
    Siri beherrscht Heimautomatisierung auch ohne Internet ziemlich gut, aber der frühere Google Assistant und Alexa konnten das überhaupt nicht und waren meines Wissens nie offline dazu in der Lage. Das ermöglicht einen Assistenten, der local-first gut funktioniert.
  • Ein lokaler Agent wie Siri kann einfache Aufgaben erledigen und komplexere Anfragen weiterleiten.
  • Er kann für gerätebezogene Aufgaben fine-getunt werden. Anders gesagt: Ein kleines Modell kann faktisch alle Funktionen nutzen, die Anwendungen oder Dienste auf dem Gerät besitzen.
    Es kann Nutzeranfragen in natürlicher Sprache an die jeweilige Anwendung weitergeben und Anwendungen koordinieren. Anfragen, die über die Gerätefunktionen hinausgehen, können an ein Cloud-Modell gesendet werden. Das ist mächtig, weil es verändern kann, wie man mit Geräten interagiert.
  • Ich habe Google AI auf dem Smartphone getestet: Als ich den Browser geöffnet hatte und sie bat, die Seite vorzulesen, antwortete sie, dass sie keinen Zugriff auf das Internet habe.
    Der AI-Assistent, den ich möchte, sollte 1) Englisch und meine Muttersprache verstehen, 2) wissen, dass er unter Android oder KDE/Linux läuft, Befehle wie „Öffne den Anwendungsbereich in den Android-Einstellungen“, „Lies die im Browser geöffnete Seite vor“ oder „Lies den Text des gerade geöffneten Pop-ups vor“ verstehen und über öffentliche APIs in das Betriebssystem integriert sein. Große AI-Unternehmen könnten insbesondere bei mehrsprachigen Nutzern darüber konkurrieren, bessere Assistenten zu verkaufen.
    3) Das Modell sollte klein sein und muss nichts über Geografie, Geschichte oder Musikbands wissen. Es reicht, wenn es die Möglichkeit gibt, Aufgaben, nach denen Nutzer fragen, an eine Suchmaschine oder ein Online-LLM weiterzuleiten.