[Übersetzung] Eine umfassende Studie zu Small Language Models (SLM)

Eine umfassende Studie zu Small Language Models (SLM) (Small Language Models: Survey, Measurements, and Insights)

Einführung in die Arbeit

Die jüngsten Fortschritte bei Sprachmodellen lassen sich in zwei Trends unterteilen. Der erste sind Large Language Models (LLM), die in großen Rechenzentren mit Hunderttausenden GPUs betrieben werden. Diese Modelle verarbeiten anspruchsvolle Sprachaufgaben und zielen darauf ab, mithilfe von künstlicher Intelligenz komplexe Probleme etwa in der Wissenschaft zu lösen. Solche LLMs erfordern jedoch hohe Kosten und enorme Rechenressourcen und sind für die Bereitstellung auf persönlichen Geräten unrealistisch.

Demgegenüber wurden Small Language Models (SLM) für den Einsatz auf Geräten mit begrenzten Ressourcen entwickelt, etwa Smartphones, Tablets oder Wearables. Das Ziel kleiner Sprachmodelle ist es, KI für alle leicht zugänglich zu machen, indem sie kosteneffiziente und praktische künstliche Intelligenz bereitstellen. Diese Arbeit ist die erste umfassende Untersuchung zu SLMs und analysiert in den vergangenen Jahren veröffentlichte kleine Sprachmodelle im Hinblick auf technische Innovationen, Leistung und Ausführungskosten auf Geräten.

Architektur, Datensätze und Training von Small Language Models (SLM)

Überblick über Small Language Models (SLM)

SLMs sind zwar kleiner als Sprachmodelle mit sehr vielen Parametern, haben aber ihre Leistungsfähigkeit in unterschiedlichen Aufgaben wie Common-Sense-Reasoning, mathematischer Problemlösung und In-Context Learning gezeigt. Damit verdeutlichen sie das Potenzial von KI, die direkt auf dem Gerät ausgeführt werden kann.

In dieser Studie werden SLMs untersucht, deren Zahl seit Ende 2023 stark zugenommen hat. Nach den folgenden Kriterien wurden 59 SLMs ausgewählt und hinsichtlich Leistung und Kosten betrachtet:

• Die Modellgröße von SLMs wurde als Bereich von 100M bis 5B definiert, und berücksichtigt wurden nur Modelle mit offen veröffentlichten Gewichten, die evaluiert werden können.

• Für hohe Leistung und reale Bereitstellung wurden nur Modelle mit einer decoder-only-Transformer-Architektur berücksichtigt. Modelle mit Architekturen wie RWKV und Mamba wurden also nicht einbezogen.

• Da sich diese Untersuchung auf das im Vortraining erworbene Grundwissen konzentriert, wurden nur Basismodelle betrachtet, ausgenommen Modelle, die nur als instruct-fine-tuned Versionen bereitgestellt werden (Microsoft Phi und StabilityAI StableLM).

• Darüber hinaus wurden auch abgeleitete Modelle ausgeschlossen, die durch Fine-Tuning vortrainierter Modelle entstanden sind.

Die nach diesen Kriterien ausgewählte Modellliste lautet wie folgt:

Modellarchitektur von SLMs (Model Architecture)

Die Modellarchitektur von SLMs basiert auf dem Transformer und weist verschiedene Varianten auf. Der Kern der Transformer-Architektur sind Multi-Head Attention (MHA) und Feed-Forward Neural Networks (FFN). MHA ermöglicht es, sich auf unterschiedliche Teile der Eingabedaten zu konzentrieren, und erhöht so die Effizienz der Parallelverarbeitung. In neueren Modellen gibt es beim Attention-Mechanismus, bei FFNs und bei Aktivierungsfunktionen folgende unterschiedliche Ansätze:

1. Attention-Mechanismen (Attention Mechanisms):

   • Multi-Head Attention (MHA): Der Kern des Transformers; ein Mechanismus, der mehreren Teilen der Eingabedaten gleichzeitig Aufmerksamkeit schenkt.
   • Group-Query Attention (GQA): Ein Verfahren, bei dem mehrere Query-Werte gruppiert werden, um die Rechenkomplexität der Attention zu verringern.
   • Multi-Query Attention (MQA): Ein Verfahren zur Reduzierung der Rechenkomplexität, indem für jede Query unterschiedliche Key- und Value-Projektionen zugelassen werden.

2. Feed-Forward Neural Network (FFN):

   • Standard-FFN: Eine einfache Netzwerkstruktur aus zwei Schichten.
   • Gated FFN: Eine Struktur mit einer zusätzlichen Gate-Schicht zur Leistungssteigerung.

3. Dimensionsausweitungsfaktor des Feed-Forward Neural Network (The intermediate ratio of the FFN): Ein Wert, der die Größe der Hidden Layer im Verhältnis zur Eingabedimension angibt und üblicherweise den Faktor der Dimensionsausweitung beschreibt. Je größer dieser Faktor ist, desto komplexere Muster kann das FFN lernen, allerdings steigen auch die Rechenkosten. Beim Standard-FFN liegt dieser Faktor typischerweise bei etwa 4, beim Gated FFN zwischen 2 und 8.

4. Aktivierungsfunktionen (Activation Functions): In SLMs werden hauptsächlich ReLU (Rectified Linear Unit), GELU (Gaussian Error Linear Unit), $GELU_{tanh}$ und SiLU (Sigmoid Linear Unit) verwendet. 2022 war ReLU am verbreitetsten, 2023 GELU und seine Varianten, und seit 2024 wird SiLU am häufigsten als Aktivierungsfunktion eingesetzt.

5. Layer-Normalisierung (Layer Normalization): Für die Layer-Normalisierung werden LayerNorm und RMSNorm verwendet. RMSNorm wird zunehmend häufiger eingesetzt und trägt dazu bei, die Trainingsstabilität des Modells zu erhöhen.

6. Größe des Vokabulars (Vocabulary Size): Die Größe des Vokabulars bezeichnet die Anzahl eindeutiger Tokens, die ein SLM erkennen kann. Jüngere SLMs verfügen meist über ein Vokabular von mehr als 50.000 Einträgen, und es wurde bestätigt, dass eine größere Vokabulargröße die Leistung verbessert.

Für die zuvor ausgewählten 59 Modelle lässt sich die zeitliche Entwicklung der Verteilung dieser sechs Varianten wie folgt zusammenfassen:

Bei der Betrachtung dieser Modellstrukturen konnten auch Innovationen in der Modellarchitektur (Model Architecture Innovations) identifiziert werden:

1. Parameter Sharing

   • Parameter Sharing ist eine Technik, die in Large Language Models (LLM) eingesetzt wird, um dieselben Gewichtssätze über mehrere Schichten oder Komponenten des Netzwerks hinweg wiederzuverwenden. Dieser Ansatz kann die Anzahl der Parameter im Modell erheblich reduzieren und zugleich die Leistung erhalten, was zu effizienterem Training und effizienterer Inferenz führt.
   • Embedding-lm_head-Sharing: Das Teilen der Embedding-Gewichte mit der finalen lm_head-Schicht ist die gebräuchlichste Form des Weight Sharing. Dabei geht es um das Teilen der Wort-Embedding-Schicht und es hat keinerlei Bezug zu RoPE (Rotary Position Encoding). Modelle wie Gemma und Qwen nutzen diese Sharing-Technik.
   • Schichtweises Attention-/FFN-Sharing (Layer-wise Attention/FFN sharing): Bei diesem Verfahren werden dieselben Gewichtssätze über mehrere Schichten des Modells hinweg wiederverwendet. Das ist in SLMs/LLMs verbreitet, bei denen alle Transformer-Schichten dieselben Parameter teilen. Beispielsweise teilt MobiLLaMA die FFN-Gewichte aller Transformer-Blöcke, und MobileLLM teilt die Attention- und FFN-Gewichte jeweils zwischen zwei benachbarten Transformer-Blöcken.

2. Schichtweise Parameterskalierung (Layer-wise Parameter Scaling)

   • Diese Technik wurde in OpenELM vorgeschlagen und eingesetzt. Bestehende SLMs verwenden für jede Transformer-Schicht des Modells dieselbe Konfiguration, sodass die Parameter gleichmäßig auf die Schichten verteilt werden. Im Unterschied dazu besitzt jede Transformer-Schicht in OpenELM eine andere Konfiguration, etwa hinsichtlich der Anzahl der Heads und der Dimension des FFN, sodass jede Schicht unterschiedlich viele Parameter nutzen kann. Dadurch kann OpenELM das verfügbare Parameterbudget besser ausschöpfen, um eine höhere Genauigkeit zu erreichen.

3. Kompensation der Nichtlinearität (Nonlinearity Compensation)

   • PanGu-$\pi$ analysiert aktuelle Sprachmodelle mit dem Ziel, das Problem des Feature Collapse zu lösen. Das Feature-Collapse-Problem tritt beim Lernen hochdimensionaler Repräsentationen wie in LLMs auf und bezeichnet das Phänomen, dass das Modell für unterschiedliche Eingaben identische oder sehr ähnliche Features lernt. Um dieses Problem zu beheben, ermöglicht PanGu-$\pi$ eine Kompensation der Nichtlinearität von Aktivierungsfunktionen wie GELU oder ReLU und skaliert die Größe der Layer-Ausgaben so, dass die Schwankungsbreite der Ausgabewerte konstant bleibt.

Wichtige Erkenntnisse: Bei der Modellarchitektur von SLMs gibt es zwei zentrale Beobachtungen:

1. Stand August 2024 verwendet eine typische SLM-Architektur GQA (Group-Query Attention), Gated FFN mit der SiLU-Aktivierungsfunktion, ein FFN-Erweiterungsverhältnis (Intermediate Ratio of FFN) zwischen 2 und 8, RMSNorm sowie eine Vokabulargröße von mehr als 50.000. Diese Einstellungen beruhen jedoch größtenteils auf empirischen Erkenntnissen und wurden nicht streng und öffentlich validiert.
2. Innovationen in der Transformer-Struktur von SLMs sind begrenzt. Abgesehen von der Technik zum Teilen von Embedding und lm_head wurde kein starker Beleg dafür beobachtet, dass andere Verfahren der klassischen Transformer-Architektur (Vanilla Transformer) überlegen sind. Außerdem werden sie von verschiedenen Forschungsgruppen oder Unternehmen weder allgemein übernommen noch breit untersucht, weshalb künftig weitere Validierung nötig ist.

Trainingsdatensatz (Training Dataset)

Die Leistung von SLMs hängt stark von den für das Training verwendeten Datensätzen ab. In dieser Studie wurden 12 öffentliche Datensätze untersucht, die von SLM-Modellen verwendet werden:

Name	Anzahl Tokens	Hauptdomäne	Beschreibung und Zweck
The Pile	825B	Wissenschaft, Fachpublikationen, Webtext, juristische Dokumente	Ein Datensatz, der verschiedene kleine Datensätze kombiniert und Texte aus mehreren Domänen enthält. Er wird verwendet, um das allgemeine Verständnisvermögen des Modells zu verbessern.
FineWeb-Edu	1.3T/5.4T	Bildungstexte, Lehrbücher, Unterrichtsmaterialien	Ein groß angelegter Datensatz aus bildungsbezogenen Texten, die aus FineWeb gefiltert wurden. Er dient dazu, die Modellleistung bei Lern- und Bildungsaufgaben zu verbessern.
StarCoder	35B	Python-Code	Ein Datensatz mit Code in der Programmiersprache Python, der zum Trainieren von Modellen für Codegenerierung und programmierbezogene Aufgaben verwendet wird.
Cosmopedia	25B	Synthetischer Text, Unterrichtsmaterialien	Ein Datensatz aus synthetischem Text, darunter Lehrbücher, Blogbeiträge, Geschichten und WikiHow-Artikel, der dem Modell hilft, unterschiedliche Schreibstile und Kontexte zu lernen.
RefinedWeb	5T	Webdokumente, Nachrichtenartikel, Blogs, technische Dokumentation	Ein Datensatz mit streng gefilterten, hochwertigen Webdaten aus CommonCrawl, der verwendet wird, um breites Domänenwissen für Natural-Language-Processing-Aufgaben zu lernen.
RedPajama	1.2T	Webdaten, Nachrichten, soziale Medien	Enthält riesige Textmengen aus Snapshots von CommonCrawl und wird für das Training webtextbasierter Modelle verwendet.
Dolma	-	Deduplizierter englischer Text	Ein englischer Korpus, der mithilfe des MinHash-Algorithmus dedupliziert wurde und zur Optimierung der Modellleistung mit bereinigten Daten ohne Duplikate dient.
WuDaoCorpora	4T	Chinesischer Text	Ein groß angelegter Korpus auf Basis chinesischer Daten mit 3T Tokens Trainingsdaten und 1,08T chinesischen Zeichen, der zum Trainieren chinesischer Sprachmodelle verwendet wird.
RoBERTa CCNewsV2	-	Nachrichtenartikel	Eine aktualisierte Version des News-Datensatzes von CommonCrawl, die für NLP-Aufgaben auf Basis aktueller Nachrichtendaten verwendet wird.
PushShift Reddit	-	Daten aus sozialen Medien (Reddit-Beiträge)	Daten, die auf einer Plattform zum Sammeln, Analysieren und Speichern von Reddit-Daten erhoben wurden und für soziale Medien-Interaktionen sowie das Training dialogorientierter Sprachmodelle genutzt werden.
DCLM-baseline	1.35T	Webtext	Ein standardisierter Korpus aus Common Crawl, der als Datensatz für vortrainierte Sprachmodelle dient und sich für verschiedene Evaluierungsaufgaben eignet.
CulturaX	6.3T	Mehrsprachiger Text	Ein riesiger mehrsprachiger Textdatensatz in 167 Sprachen, der als umfangreiche Textressource für das Training mehrsprachiger Modelle verwendet wird.

Betrachtet man die Trends bei den für das Pretraining verwendeten Datensätzen der untersuchten SLMs von 2022 bis 2024, ergibt sich folgendes Bild:

2022 und 2023 war The Pile der am weitesten verbreitete Pretraining-Datensatz. In jüngerer Zeit wurden jedoch mehr Datensätze vorgeschlagen, wodurch die Auswahl breiter geworden ist. Im Jahr 2024 wird The Pile für das Pretraining von SLMs nicht mehr verwendet; stattdessen werden Datensätze wie RefinedWeb oder RedPajama zunehmend breit eingesetzt. Das zeigt, dass Forschung und Engineering zur Entwicklung qualitativ besserer Pretraining-Datensätze intensiv vorangetrieben werden.

Anschließend wurde die Leistung von SLMs in Abhängigkeit vom verwendeten Pretraining-Datensatz untersucht. Dabei wurden SLMs, die in den letzten drei Jahren veröffentlicht wurden, nach Parametergröße in vier Gruppen eingeteilt (<1B / 1B-1.4B / 1.5-2B / 2.5B-3B) und innerhalb jeder Gruppe nach durchschnittlicher Genauigkeit sortiert, wobei diese als Mittelwert aus zwei Genauigkeitstypen (Common-Sense-Reasoning/Verständnis sowie Problemlösung) definiert wurde:

Aus diesen Ergebnissen lässt sich erkennen, dass zwei kürzlich veröffentlichte Datensätze, DCLM(DataComp-LM) und FineWeb-Edu, im Vergleich zu anderen Datensätzen eine überlegene Leistung zeigen. Ein gemeinsames Merkmal dieser beiden Datensätze ist die Nutzung modellbasierter Datenfilterung.

Außerdem enthalten Pretraining-Datensätze wie StarCoder häufig Coding-Daten, obwohl Coding-Fähigkeiten keine zentrale Aufgabe von SLMs sind, die auf Geräten bereitgestellt werden. Ein möglicher Grund dafür ist die verbreitete Annahme, dass Coding-Daten das Schlussfolgerungsvermögen von Modellen verbessern können.

Als Nächstes wurden die Anzahl der im Pretraining verwendeten Tokens und die Modellgröße sowie die Anzahl der im Pretraining verwendeten Tokens und die durchschnittliche Genauigkeit betrachtet.

Zunächst besagt das Chinchilla-Gesetz (Chinchilla Law), das den Zusammenhang zwischen Modellgröße und Datenmenge (Anzahl der Tokens) im Training untersucht, dass das optimale Verhältnis zwischen der Zahl der Modellparameter und der Zahl der Trainingstokens bei etwa 20 liegen sollte. Für ein 1B-Modell wäre demnach also ein Trainingsdatensatz im Umfang von 20B Tokens erforderlich.

Eine statistische Analyse der Größe von SLMs und der Anzahl der Trainingstokens bei zwischen 2022 und 2024 veröffentlichten Modellen (linke Abbildung unten, (a)) zeigt, dass größere Modelle im Allgemeinen mit mehr Tokens trainiert werden und dass neuere Modelle tendenziell mehr Trainingstokens verwenden. Bemerkenswert ist, dass SLMs unabhängig von ihrer Modellgröße mit deutlich mehr Tokens trainiert werden, als vom Chinchilla-Gesetz vorgeschlagen wird — in der Regel mit mehr als 1,5T Tokens.

Die Analyse der von SLMs im Pretraining verwendeten Tokenzahl und der durchschnittlichen Genauigkeit (rechte Abbildung unten, (b)) zeigt, dass zwischen diesen beiden Kennzahlen im Allgemeinen eine positive Korrelation besteht, die besonders deutlich ist, wenn weniger als 700B Tokens für das Training verwendet werden. Überschreitet die Zahl der Trainingstokens jedoch 1T, fällt die Korrelation schwächer aus, weil dann die Qualität der Trainingsdaten wichtiger wird als ihre Menge.

> #### Wichtige Erkenntnisse: Bei den Trainingsdatensätzen für SLMs gibt es zwei zentrale Beobachtungen:
> - Die Qualität der Trainingsdaten ist für die Leistung von SLMs von entscheidender Bedeutung und rückt in der jüngeren SLM-Forschung zunehmend in den Fokus. Im Allgemeinen ist der Einfluss der Datenqualität auf SLMs meist größer als der von Datenmenge und Modellarchitektur. Ein bemerkenswerter Trend in der Datensatzforschung ist der Einsatz modellbasierter Filterung, wobei FineWeb-Edu (1.3T/5.4T) und DCLM-baseline (4T) prominente Beispiele sind. SLMs, die mit diesen beiden Datensätzen trainiert wurden, zeigten eine wettbewerbsfähige Leistung gegenüber SLMs, die mit proprietären Datensätzen trainiert wurden.
> - Neuere SLMs werden unabhängig von der Modellgröße mit einer großen Menge an Trainingstokens trainiert, in der Regel mehr als 1.5T. In manchen Fällen wird auch eine kleinere Datenmenge verwendet. (Beispiel: Qwen2-0.5B nutzte 12T Tokens, während Qwen2-1.5B nur 7T Tokens verwendete.) Das bedeutet, dass sie im Vergleich zum Chinchilla-Gesetz deutlich „übertrainiert“ (over-training) sind. Dieses Übertrainieren wird eingesetzt, um durch mehr Trainingszeit leistungsfähigere SLMs zu deployen.

Trainingsalgorithmus (Training Algorithm)

Für das Training von SLMs gibt es verschiedene Algorithmen. Zu den wichtigsten Trainingsalgorithmen gehören Maximal Update Parameterization (μP), Knowledge Distillation und die Strategie des Two-Stage Pre-training.

1. Maximal Update Parameterization (μP): Sie steuert Modellinitialisierung (initialization), schichtweise Lernraten (layer-wise learning rate), Aktivierungsgrößen (activation magnitude) usw., um stabiles Training unabhängig von der Breite der Modellschichten (model's layer width) sicherzustellen. Diese Methode verbessert nicht nur die Trainingsstabilität, sondern erhöht auch die Übertragbarkeit von Trainingshyperparametern von kleinen auf große Modelle, sodass etwa dieselbe Lernrate verwendet werden kann. Cerebras-GPT trainiert seine Modelle mit dieser Technik.

2. Knowledge Distillation: Ein Konzept, das vor allem bei Large Language Models (LLMs) eingesetzt wird. Dabei wird wertvolles Wissen aus einem großen und komplexen Lehrermodell extrahiert und auf ein kleineres, effizienteres Schülermodell übertragen. Der Kern dieser KD-Technik besteht darin, die Unterschiede zwischen den Ausgaben beider Modelle zu minimieren, damit das Schülermodell das Verhalten und die Vorhersagen des Lehrermodells näherungsweise erlernt. LaMini-GPT und Gemma-2 verwenden diese Technik.

3. Two-Stage Pre-training: Wie der Name schon sagt, handelt es sich um eine Trainingsstrategie, bei der das Modell zwei unterschiedliche Phasen durchläuft. Zunächst wird in der Pretraining Phase mit großen Mengen minderwertiger Daten trainiert. Dieser Prozess erfordert mehr Rechenressourcen. Anschließend werden in der Annealing Phase hochwertige, auf bestimmte Aufgaben ausgerichtete SFT-Daten (Supervised Fine-Tuning) mit den Pretraining-Daten gemischt. MiniCPM verwendet diese Technik.

Fähigkeiten von SLMs (Capabilities)

Evaluationsdatensätze und Metriken für SLMs (Evaluation Datasets and Metrics)

In dieser Studie wurden 12 Datensätze zur Bewertung der Fähigkeiten von SLMs in drei Kategorien eingeordnet: Commonsense Reasoning, Problem Solving und Mathematics:

Name	Typ	Beschreibung und Zweck
HellaSwag	Commonsense Reasoning	Testet das Verständnis von Beschreibungen und bewertet mögliche Satzvervollständigungen.
TruthfulQA	Commonsense Reasoning	Ein Datensatz zur Bewertung, ob ein Modell keine falschen Informationen liefert.
Winogrande	Commonsense Reasoning	Ein Datensatz zur Bewertung von Commonsense-Reasoning-Fähigkeiten über die Auflösung von Pronomenmehrdeutigkeiten.
CommonsenseQA	Commonsense Reasoning	Bietet Commonsense-Reasoning-Aufgaben in Form von Multiple-Choice-Fragen, die Alltagswissen erfordern.
PIQA	Commonsense Reasoning	Ein Datensatz zur Bewertung physikalischen Commonsense Reasoning und von Objektinteraktionen.
OpenBookQA	Commonsense Reasoning	Enthält offene wissenschaftliche Fragen, die durch die Kombination von naturwissenschaftlichem Wissen und Alltagswissen gelöst werden müssen.
BoolQ	Commonsense Reasoning	Bewertet Commonsense- und faktenbasiertes Schlussfolgern anhand von Ja/Nein-Fragen.
ARC Easy	Problem Solving	Ein Datensatz mit einfachen naturwissenschaftlichen Fragen, die Allgemeinwissen und Schlussfolgern testen.
ARC Challenge	Problem Solving	Bietet komplexe naturwissenschaftliche Prüfungsfragen, die Wissensintegration erfordern.
MMLU	Problem Solving	Ein Datensatz zur Bewertung von Problemlösungsfähigkeiten in verschiedenen Fachgebieten.
GSM8K	Mathematics	Ein Datensatz zur Bewertung mathematischer Schlussfolgerungsfähigkeiten auf Grundschulniveau.
Minerva Math	Mathematics	Bewertet fortgeschrittene mathematische Schlussfolgerungsfähigkeiten in verschiedenen Themenbereichen.

Bei der Evaluation wird Accuracy als zentrale Metrik verwendet, also das Verhältnis der korrekten Vorhersagen zur Gesamtzahl der Beispiele im Evaluationsdatensatz. In den Bereichen Commonsense Reasoning, Problem Solving und Mathematics wird bewertet, ob die richtige Antwort gewählt wurde oder wie präzise eine Lösung ausfällt.

Gesamtleistung von SLMs (Overall Capabilities)

Für die drei Aufgabenbereiche Commonsense Reasoning, Problem Solving und Mathematik wurden Experimente mit ausgewählten SLMs durchgeführt und der Fortschritt wie in der folgenden Abbildung analysiert. Insgesamt zeigt sich eine deutliche Leistungssteigerung; konkret verbesserten sich die Werte je nach Aufgabe um 10.4 %, 13.5 % und 13.5 %. Zum Vergleich: Das Open-Source-Large-Language-Model LLaMA verbesserte sich im selben Zeitraum im Durchschnitt nur um 7.5 %:

Insbesondere die mit proprietären Datensätzen trainierte Phi-Familie von Microsoft zeigte bessere Leistungen als alle anderen Modelle und erreichte ein Leistungsniveau ähnlich dem aktuellen LLaMA 3.1 mit 7B Parametern (67.6 % bei Commonsense Reasoning und 72.4 % bei Problem Solving). Im Bereich Mathematik gibt es zwar noch gewisse Unterschiede, doch bei allgemeinem Reasoning schließt sich die Lücke zwischen SLMs und LLMs schnell. Auch wenn es Ausnahmen wie Qwen2 gibt, zeigt sich generell die Tendenz, dass die Leistung mit der Modellgröße zunimmt.

Einige wegweisende SLMs werden zwar mit proprietären Datensätzen trainiert, doch die Lücke zwischen Open-Source- und proprietären Modellen bei Commonsense-Reasoning-Aufgaben wird allmählich kleiner. Beispielsweise zeigen SmolLM und DCLM-1B dank hochwertiger Datensätze wie DCLM und FineWeb-Edu im Bereich Commonsense Reasoning eine sehr starke Leistung (mit 64.2 % bzw. 63.8 %). Bei Aufgaben, die komplexes Schlussfolgern oder Logik erfordern, insbesondere in der Mathematik, besteht jedoch weiterhin eine deutliche Lücke, da es an hochwertigen Datensätzen mangelt.

Wichtige Erkenntnisse: Bei der Entwicklung von SLM gibt es vier zentrale Beobachtungen:

• Von 2022 bis 2024 haben SLM bei verschiedenen Sprachaufgaben ihre Leistung deutlich verbessert. Insgesamt zeigen sie erhebliche Leistungssteigerungen und übertreffen die Verbesserungen von LLaMA-7B (Versionen 1/2/3/3.1). Diese Ergebnisse wecken die Erwartung, dass sich damit auf On-Device-Systemen verschiedene Downstream Tasks lösen lassen.
• Die Phi-Modellfamilie zeigt bei den meisten Aufgaben durchgängig State-of-the-Art-Leistung. Phi-3-mini erreichte im September 2024 eine Genauigkeit auf dem Niveau von Llama-3.1-8B. Diese Leistung ist vermutlich Microsofts sorgfältigem Data Engineering zu verdanken, könnte aber auch auf instruction tuning für bestimmte Datensätze und potenzielles Overfitting zurückzuführen sein.
• Im Allgemeinen verbessert sich die Leistung mit wachsender Modellgröße, es gibt jedoch Ausnahmen wie Qwen2-1.5B. Solche Ausnahmen zeigen, dass kleinere Modelle bei bestimmten Aufgaben eine hervorragende Leistung erzielen können.
• Im Bereich Common-Sense-Reasoning verringert sich der Leistungsabstand zwischen SLM, die mit Open-Source-Datensätzen trainiert wurden, und proprietären SLM. Bei Aufgaben, die komplexes Reasoning oder Logik erfordern, besteht jedoch weiterhin eine beträchtliche Lücke, sodass Datensätze mit Fokus auf mathematisches Reasoning benötigt werden.

In-Context-Learning-Fähigkeiten

In-Context Learning (ICL) ist eine wichtige Fähigkeit von SLM und bezeichnet die Fähigkeit, auf Basis des gegebenen Eingabekontexts neue Aufgaben auszuführen. Es wurden Experimente zu den In-Context-Learning-Fähigkeiten mit verschiedenen Modellen und jeweils 2B großen Varianten dieser Modelle über acht Aufgaben hinweg durchgeführt, darunter Common-Sense-Reasoning und Problemlösung. Im Allgemeinen konnten SLM bei allen Aufgaben deutliche Vorteile erzielen. Bei einfachen Datensätzen wie HellaSwag und PIQA zeigte sich jedoch ausnahmsweise unabhängig von der Anzahl der ICL-Beispiele (ICL Shots) eine ähnliche Leistung. Darüber hinaus verbessert In-Context Learning mit durchschnittlich fünf Beispielen (5-shot) die Zero-Shot-Leistung über alle Aufgaben hinweg im Schnitt um 2,1 %.

Besonders das Gemma2-Modell zeigte mit einem Genauigkeitszuwachs von 4,8 % die größte Verbesserung. Das LaMini-Modell stellte eine Ausnahme dar und verzeichnete einen Leistungsrückgang von mehr als 2 %. Daraus wurde die Hypothese abgeleitet, dass LaMini auf den Trainingsdatensatz overfittet ist und zusätzliche Beispiele daher Rauschen verursachen können.

Insgesamt ließ sich bestätigen, dass sich die In-Context-Learning-Leistung von SLM mit zunehmender Modellgröße verbessert.

Wichtige Erkenntnisse: Bei den In-Context-Learning-Fähigkeiten von SLM gibt es zwei zentrale Beobachtungen:

• Im Allgemeinen verfügen die meisten SLM über ein gewisses Maß an In-Context-Learning-Fähigkeit. Diese Fähigkeit fällt jedoch je nach Aufgabentyp unterschiedlich aus: Die meisten SLM verbessern sich bei der Arc Challenge deutlich, während der Effekt bei HellaSwag oder PIQA gering ist.
• Je größer ein SLM ist, desto stärker ist tendenziell seine In-Context-Learning-Fähigkeit im Vergleich zu kleineren Modellen. Einige kleinere SLM wie LaMini zeigen bei der Nutzung von In-Context Learning sogar Leistungsverschlechterungen.

Laufzeitkosten von SLM

Die Laufzeitkosten von SLM umfassen die Latenz und den Speicherbedarf, die beim Ausführen des Modells auf einem realen Gerät entstehen. Diese Studie bewertet die Runtime-Performance von SLM und analysiert Versuchsergebnisse auf verschiedener Hardware. Außerdem erläutert sie den Einfluss von Modellarchitektur und Quantisierung auf die Leistung und behandelt, wie sich SLM für Echtzeitumgebungen optimieren lassen.

Zur Messung der Laufzeitkosten wurden zwei Arten von Edge Devices verwendet: der vor allem in Edge-Geräten wie Drohnen oder kleinen Robotern genutzte Jetson Orin sowie das im Alltag weit verbreitete Smartphone. Im Einzelnen waren dies:

Gerätename	Hardwaretyp	Spezifikation
Jetson Orin NX 16GB	GPU	1024-core NVIDIA Ampere architecture GPU with 32 tensor cores, 16G DRAM
MEIZU 18Pro	CPU	Snapdragon 888, 8G RAM

Da sich die Methoden zur Ermittlung der offiziellen Parameteranzahl je nach Modell unterscheiden, verwendeten die Autoren die aus llama.cpp gewonnenen Parameterwerte. Die Messung wurde in die Prefill-Phase und die Decode-Phase zum Inferenzzeitpunkt unterteilt. Sofern nicht anders angegeben, wurde die Prompt-Länge auf 50 und die Länge der Tokengenerierung ebenfalls auf 50 gesetzt. Um Leistungseinbußen durch thermal throttling zu vermeiden, wurden die Tests außerdem in Abständen von 10 Sekunden durchgeführt. Für die Messung größerer Modelle wurde eine 4-Bit-Quantisierung angewendet.

• Latenzmessung: Je nach Modellgröße werden die Zeit bis zur Erzeugung des ersten Tokens (prefill) und die Zeit für die Erzeugung jedes nachfolgenden Tokens (decode) gemessen.
• Messung des Speicherbedarfs: Durch die Messung von KV-Cache und Memory Buffer wird analysiert, wie viel Speicher das Modell belegt.

Überblick über die Laufzeitkosten

Ein Überblick über Inference Latency und Memory Footprint der in dieser Studie behandelten SLM sieht wie folgt aus:

• Inference Latency (Inferenzlatenz): Die Inferenzlatenz von SLM wird je nach Modellgröße in drei Bereiche unterteilt: 0.1-1B, 1-2B und 2-3B. Innerhalb dieser Bereiche zeigen die einzelnen Modelle ähnliche Latenzzeiten. Konkret ist auch der Einfluss der Modellarchitektur auf die Latenz erheblich. So weist Qwen2-0.5B beispielsweise eine 1,46-fach längere Zeit bis zum ersten Token auf als andere Modelle derselben Größe, während Qwen1.5-0.5B eine ähnliche Leistung wie das eigentlich kleinere Modell OpenELM-1.1B zeigt.

  • Prefill-Phase: Die Phase, in der der Eingabe-Prompt verarbeitet und der KV-Cache erstellt wird; mehrere Tokens werden dabei parallel verarbeitet.
  • Decode-Phase: Die Phase, in der auf Basis jedes erzeugten Tokens das nächste Token vorhergesagt wird; sie benötigt mehr Speicherressourcen.

• Memory Footprint (Speicherbedarf): Der Speicherbedarf von SLM variiert je nach Modellgröße und Kontextlänge. Insbesondere Modelle wie Bloom-560M und Gemma-2B benötigen mehr Speicher, da sie über ein sehr großes Vokabular (256.000 Einträge) verfügen. Die OpenELM-Serie spart dagegen Speicherbedarf, indem sie GQA (Group-Query Attention) verwendet und so die Größe des KV-Caches reduziert.

> #### Zentrale Erkenntnisse: Zu den Ausführungskosten von SLM gibt es drei wichtige Beobachtungen:
> - Neben der Modellgröße beeinflusst auch die Modellarchitektur die Latenz. So hat Qwen1.5-0.5B beispielsweise 25,4 % mehr Parameter als Qwen2-0.5B, läuft auf Jetson Orin jedoch 31,9 % schneller. Das bedeutet, dass SLM bei der Entwicklung auf die Zielhardware für die Bereitstellung abgestimmt werden sollten.
> - Der Einfluss der Modellarchitektur auf die Inferenzgeschwindigkeit ist in der Prefill-Phase größer als in der Decode-Phase. Der Grund ist die höhere Rechendichte in der Prefill-Phase, während die Decoding-Phase hauptsächlich Memory-bound ist. Unterschiede in der Modellarchitektur wirken sich leichter auf Compute-bound-Szenarien aus. Beispielsweise weisen breitere und flachere Modelle eine höhere computational parallelism auf.
> - Der Speicherverbrauch zur Laufzeit korreliert im Allgemeinen linear mit der Modellgröße. Einige Modelle mit größerem Vokabular benötigen jedoch mehr Speicher als andere Modelle ähnlicher Größe. So beträgt die Vokabulargröße der Bloom-Modellfamilie 250.880 und ist damit etwa 5- bis 8-mal größer als bei den meisten anderen Modellen.

Auswirkungen von Quantisierung und Hardware (Impact of Quantization and Hardware)

Zunächst wurde die Latenz des Phi-1.5-Modells mit fünf Quantisierungsmethoden (Q8_0, Q6_K, Q5_K, Q4_K_M, Q3_K) sowie vor der Quantisierung (FP16) gemessen, um zu untersuchen, wie sich Quantisierung auf die Ausführungskosten von SLM auswirkt:

Auf mobilen Geräten kann die Unterstützung für int8-Operationen begrenzt sein, dennoch lässt sich der Overhead für Speicherzugriffe effektiv reduzieren. Das liegt daran, dass die geringere Präzision zu Datenkompression führt und dadurch die Cache-Auslastung verbessert wird. Jede Methode quantisiert auf n Bit; Qn_K und Qn_K_M verwenden die k-quant-Methode, um Modelle mit einer mittleren Anzahl an Parametern auf n Bit zu quantisieren, während Qn_0 eine symmetrische Quantisierung bezeichnet.

Effekt der Quantisierung in der Prefill-Phase: Bei kurzen Prompt-Längen reduziert Quantisierung die Latenz um mindestens 25 %. Mit zunehmender Prompt-Länge nimmt dieser Effekt jedoch ab, und bei einer Prompt-Länge nahe 50 zeigen die Quantisierungsmethoden Q6_K und Q3_K eine ähnliche oder sogar höhere Latenz als das nicht quantisierte FP16-Modell. Die Methoden Q8_0, Q4_K_M und Q5_K liefern stabile Leistungsverbesserungen, wobei insbesondere Q4_K_M die beste Leistung zeigt und im Durchschnitt eine Reduktion der Latenz um 50 % erreicht.

Effekt der Quantisierung in der Decode-Phase: Hier zeigen sich konsistentere Leistungsverbesserungen; die Latenz sinkt um bis zu 75 %, bei einem Minimalwert von 17 %. Wie in der Prefill-Phase ist auch hier Q4_K_M die effektivste Methode, während Q6_K am ineffizientesten ist.

> #### Zentrale Erkenntnisse: Zum Einfluss der Quantisierung von SLM auf die Ausführungskosten gibt es zwei wichtige Beobachtungen:
> - Die Vorteile der Quantisierung sind in der Decode-Phase größer als in der Prefill-Phase. Auf mobilen Geräten reduziert Quantisierung in erster Linie den Overhead von Speicherzugriffen. Da die Decode-Phase stärker von der Speicherbandbreite abhängt, kann sie stärker von Quantisierung profitieren als die stärker rechenlastige Prefill-Phase.
> - Je regelmäßiger die Quantisierungspräzision ist, desto besser ist die Performance. Eine 3-Bit-Quantisierung bietet zwar eine höhere Kompressionsrate als eine 4-Bit-Quantisierung, doch 4-Bit-Quantisierung liefert sowohl in der Prefill- als auch in der Decode-Phase die bessere Leistung. Die schwächere Performance von 3-Bit-Quantisierung liegt an der unregelmäßigen Bitbreite, für die es weniger Hardware-Optimierungsunterstützung gibt, sowie an zusätzlichem Overhead durch data alignment & padding. Daher ist 4-Bit-Quantisierung trotz geringerer Kompressionsrate effizienter; entsprechend zeigen auch 5-Bit- und 6-Bit-Quantisierung trotz höherer Kompressionsrate eine ähnliche oder sogar höhere Inferenzlatenz als 8-Bit-Quantisierung.

Als Nächstes wurde das Bloom-1B1-Modell auf Jetson Orin NX 16GB (mit GPU) und Meizu 18 Pro (mit CPU) getestet, um zu messen, wie sich die Hardware auf die Ausführungskosten von SLM auswirkt:

In der Prefill-Phase zeigt Jetson Orin bei kurzen Prompt-Längen eine 10- bis 20-mal höhere Geschwindigkeit als das Meizu 18 Pro. Zudem wird der Leistungsvorteil von Jetson mit zunehmender Prompt-Länge noch deutlicher. Zwar steigt bei längeren Prompts auf beiden Geräten die Zeit bis zur Erzeugung des ersten Tokens linear an, Jetson hält jedoch auch bei längeren Prompts eine stabile Leistung.

In der Decode-Phase steigt die Latenz pro Token beim Meizu 18 Pro mit zunehmender Zahl generierter Tokens stark an. Besonders zwischen dem ersten und zehnten Token nimmt die Latenz sprunghaft zu, danach stabilisiert sie sich. Dieser starke Latenzanstieg beim Meizu 18 Pro ist auf die Temperaturerhöhung zurückzuführen, da DVFS (Dynamic Voltage and Frequency Scaling) oder Thermal Throttling den Stromverbrauch und die Frequenz anpassen und dadurch die Recheneffizienz sinkt. Jetson zeigt dagegen dank eines effizienteren Kühlsystems bis zur Erzeugung von 30 Tokens nur geringe Schwankungen der Latenz; erst danach wird ein Anstieg beobachtet.

> #### Zentrale Erkenntnisse: Zum Einfluss der Hardware auf die Ausführungskosten von SLM gibt es zwei wichtige Beobachtungen:
> - Während in der Decode-Phase Tokens nacheinander erzeugt werden, können in der Prefill-Phase die Tokens innerhalb des Prompts parallel verarbeitet werden, weshalb auf der GPU eine deutlich höhere Leistung erzielt wird.
> - Bei langen Inferenzaufgaben zeigt Jetson eine bessere Leistungsstabilität als ein Smartphone. Das liegt daran, dass Jetson aufgrund seiner vergleichsweise einfachen Hardwarestruktur Wärme besser ableiten kann.

Aufschlüsselung von Latenz und Speicher (Latency and Memory Breakdown)

Zur detaillierteren Analyse der Latenz wurde bei den Modellen Qwen1.5-0.5B und Qwen2-0.5B untersucht, welchen Anteil jede Schicht (layer) und jede Operation an der Gesamtlatenz hat:

Die Modelle Qwen1.5-0.5B und Qwen2-0.5B sind ähnlich groß, unterscheiden sich jedoch bei der Latenz. Mithilfe einer detaillierten Analyse der Modelllatenz wurde gemessen, wie sich die Zeit auf die einzelnen Schichten (Embedding, Attention, FFN, LM_Head) verteilt.

In der Prefill-Phase nimmt beim Modell Qwen1.5 die Attention-Schicht einen größeren Anteil ein als die FFN-Schicht. Das liegt daran, dass durch die zunehmende Größe des KV-Cache mehr Berechnungen in der Attention-Schicht erforderlich werden. Beim Modell Qwen2 nimmt dagegen die FFN-Schicht einen größeren Anteil ein als die Attention-Schicht. Das ist darauf zurückzuführen, dass die FFN-Schicht im Qwen2-Modell breiter ist.

In der Decode-Phase steigt der Anteil der Attention-Berechnungen im Qwen1.5-Modell noch weiter an. Der Grund ist, dass erzeugte Tokens mit zuvor erzeugten Tokens interagieren und dadurch mehr Berechnungen notwendig werden; mit wachsender Größe des KV-Cache wird dieser Trend noch deutlicher. Beim Qwen2-Modell beansprucht weiterhin die FFN-Schicht die meiste Zeit, da die größere Rechenbreite des FFN mehr Zeit benötigt.

Bei der Analyse der Operatoren zeigt sich, dass bei beiden Modellen die Matrix-Vektor-Multiplikation (matrix-vector multiplication, mul_mat_vec_q) durchgängig mehr als 80 % der gesamten Rechenzeit ausmacht. Insbesondere beim Modell Qwen2-0.5B nimmt mul_mat_vec_q einen noch größeren Anteil ein, weil die FFN-Schicht breiter ist.

Außerdem ergibt die Analyse des Speicherverbrauchs Folgendes:

Die Analyse hebt hervor, dass nicht nur die Größe des Modells, sondern auch die Größe des Vokabulars (vocabulary size) einen großen Einfluss auf den Speicherverbrauch hat. Je größer das vom Modell verwendete Vokabular ist, desto größer wird der Compute Buffer in der Ausgabeschicht. Beim Modell Bloom-560M beträgt die Vokabulargröße beispielsweise 250.880, wodurch der Compute Buffer auf 492 MB anwächst; das entspricht einem 3,5-fach höheren Speicherverbrauch als bei OpenELM-1.1B mit einer Vokabulargröße von 32.000.

Außerdem haben Modelle mit GQA (Group-Query Attention) einen kleineren KV Cache als Modelle mit MHA (Multi-Head Attention). So beträgt der KV Cache des Modells OpenELM-3B 164 MB und ist damit etwa 3,9-mal kleiner als der von StableLM-zephyr-3B.

Mit zunehmender Kontextlänge (context length) werden Compute Buffer und KV Cache zu den entscheidenden Faktoren für den Speicherverbrauch eines Modells. In der Modellreihe Qwen2 machen Compute Buffer und KV Cache bei einer Kontextlänge von 131.072 83 % bis 87 % des gesamten Speicherverbrauchs aus. Bei Qwen1.5 hingegen entfallen bei der maximalen Kontextlänge von 32.768 85 % bis 90 % des gesamten Speichers auf diese beiden Faktoren.

Diese Analyse zeigt klar, wie sich die Größe des Vokabulars (Vocabulary Size) und die Kontextlänge (Context Length) auf den Speicherverbrauch von SLMs auswirken: Je größer das Vokabular und je länger der Kontext, desto stärker steigt der Speicherverbrauch an.

Fazit und künftige Forschungsrichtungen

Bis hierhin wurden umfassende Untersuchungen und Leistungsmessungen zu Small Language Models (SLM) mit Größen von 100M bis 5B durchgeführt und dabei unter anderem Modellleistung und Ausführungskosten bewertet. Auf dieser Grundlage sollen der aktuelle Stand und die Grenzen von SLMs analysiert sowie verschiedene Forschungsthemen aufgezeigt werden, die künftig weiter untersucht werden sollten:

• Ko-Design und gemeinsame Optimierung von SLM-Architektur und Prozessoren (Co-design and co-optimizations of SLM architecture and device processors.): Die Leistung von SLMs kann selbst bei gleicher Modellgröße je nach Architekturkonfiguration stark variieren. So haben etwa das Tiefen-Breiten-Verhältnis eines Transformers, der Attention-Typ und die Aktivierungsfunktion großen Einfluss auf die Ausführungsgeschwindigkeit. Besonders wichtig ist, wie sich SLMs quantisieren lassen, damit sie auf für Ganzzahloperationen optimierten Prozessoren wie NPUs (Neural Processing Units) effizient ausgeführt werden können. Um optimale Trade-offs zwischen Genauigkeit und Geschwindigkeit zu erreichen, sind auf die jeweilige Hardware zugeschnittene Architekturentwürfe und Optimierungen essenziell; ein möglicher Ansatz wäre, schon vor dem Pretraining eine auf Geschwindigkeit optimierte Architektur zu finden.

• Aufbau hochwertiger synthetischer Datensätze (Constructing high-quality synthetic dataset): Kürzlich veröffentlichte Pretraining-Datensätze wie DCLM und FineWeb-Edu haben die Leistung von SLMs deutlich verbessert. Die zentrale Innovation dieser Datensätze besteht darin, vortrainierte Modelle zu verwenden, um hochwertige Daten aus großen Korpora herauszufiltern. Die Forschung zu synthetischen Daten steht jedoch noch am Anfang und bietet großes Potenzial. Dringend nötig ist der Aufbau standardisierter Prozesse für das Management synthetischer Daten, etwa für Deduplizierung, Filterung, Mischung und Evaluierung.

• Erweiterung des Chinchilla-Gesetzes unter Berücksichtigung der Deployment-Umgebung (A deployment-aware Chinchilla law for model scaling): Dem Chinchilla-Gesetz zufolge ist zur Optimierung der Modellleistung ein Gleichgewicht zwischen Modellgröße und Umfang der Trainingsdaten (Anzahl der Token) von ungefähr 1:20 erforderlich. SLMs müssen jedoch an die begrenzten Speicher- und Rechenressourcen von Endgeräten angepasst werden und neigen deshalb dazu, deutlich größere Datenmengen zu verwenden. Dieser Ansatz ist bis zu einem gewissen Grad wirksam, doch lässt sich die Menge der Trainingsdaten nicht unbegrenzt skalieren; die optimale Form der Datenskalierung zu finden, bleibt daher eine offene Frage. Zudem müssen nicht nur Datengröße sowie Trainings- und Inferenzkosten berücksichtigt werden, sondern auch der Lebenszyklus und der wirtschaftliche Nutzen von SLMs. Durch den Einsatz von Sparsity wie bei MoE (Mixture-of-Experts) wird dieses Problem noch komplexer.

• Kontinuierliches On-Device-Lernen zur Personalisierung (Continual on-device learning for personalization): Wenn SLMs auf Geräten bereitgestellt werden, können sie On-Device-Daten nutzen, um ohne Sorgen über Datenlecks bessere Leistung oder Personalisierung zu erreichen. Ein erster Ansatz dafür ist die Verwendung von RAG (Retrieval-Augmented Generation), um persönliche Daten in den Prompt einzubringen. Diese Methode erhöht jedoch die Zeit für die Erzeugung von Text-Embeddings und die Prompt-Verarbeitung und bringt das Problem mit sich, dass Personalisierungsdaten lange auf dem Gerät gespeichert werden müssen. Ein zweiter Ansatz ist das Fine-Tuning des SLM, bei dem für die Personalisierung benötigtes Wissen in die Modellgewichte eingebettet wird und die Daten nach dem Fine-Tuning gelöscht werden können. On-Device-Fine-Tuning verursacht jedoch einen hohen Verbrauch an Speicher und Energie, wodurch gravierende Ressourcenprobleme entstehen können. Denkbar sind etwa Forschungen zu Methoden, die Zeroth-Order Optimization einsetzen, um keine Aktivierungswerte im Speicher abzulegen und zugleich Hardware-Beschleuniger in der Inferenzphase zu nutzen.

• Zusammenarbeit von SLM und LLM auf Gerät und in der Cloud (Device-cloud SLM-LLM collaboration): Obwohl sich die Fähigkeiten von SLMs schnell weiterentwickeln, besteht weiterhin eine Lücke zu großen Sprachmodellen (LLMs), die in der Cloud laufen. Um diese zu schließen, wird die Zusammenarbeit zwischen Gerät und Cloud ein wichtiges Forschungsthema sein. Intuitiv könnten SLMs Aufgaben übernehmen, die sich direkt auf dem Gerät leicht lösen lassen, während Cloud-LLMs als Filter für komplexe Aufgaben dienen. Dafür braucht es jedoch ein Entscheidungsmodul, das zwischen Aufgaben unterscheidet, die ein SLM bewältigen kann, und solchen, die es nicht bewältigen kann; auch die Frage nach einer geeigneten Form der Zusammenarbeit zwischen Gerät und Cloud erfordert weitere Forschung.

• Fairness bei der Bewertung der SLM-Leistung (Benchmarking SLMs fairly): SLMs haben insbesondere bei weit verbreiteten Benchmarks wie GSM8k Probleme mit Overfitting. Zudem werden viele SLMs mit nicht öffentlichen Datensätzen trainiert, was faire Leistungsvergleiche erschwert. Da SLMs hauptsächlich On-Device ausgeführt werden, übernehmen sie andere Aufgaben als in Cloud-Umgebungen. Auf Smartphones eingesetzte SLMs verarbeiten tendenziell Aufgaben, die sensibel auf Nutzerdaten reagieren; da solche spezialisierten Ad-hoc-Aufgaben in bestehenden Benchmarks nicht enthalten sind, könnten sie bei wichtigen Bewertungen außen vor bleiben.

• SLMs mit Sparsity (Sparse SLMs): Gegenwärtig gibt es kaum Forschung zur Anwendung von Sparsity in SLMs. Ein Grund dafür ist, dass bei SLMs im Vergleich zu LLMs ein relativ geringeres Sparsity-Niveau zu erwarten ist und die Vorteile in Form von Geschwindigkeitssteigerungen oder Speichereinsparungen dadurch begrenzt sein könnten. Zudem können auf Sparsity basierende Architekturen wie MoE (Mixture-of-Experts) zwar den Speicherverbrauch senken, im Gegenzug aber die Rechenkomplexität erhöhen, weshalb sie für speicherbeschränkte Geräte ungeeignet sein könnten. SLMs ließen sich zwar weiter skalieren, indem feste Gewichte (Cold Weights) im externen Speicher eines Smartphones, etwa Flash-Speicher, abgelegt und bei Bedarf geladen werden; für solche Ansätze sind jedoch weitere Untersuchungen nötig, unter anderem zu Problemen mit I/O-Latenzen und zur Aufrechterhaltung der Kompatibilität mit heterogenen Hardware-Beschleunigern.

Umfassende Survey-Arbeit zu Small Language Models: Small Language Models: Survey, Measurements, and Insights

https://arxiv.org/abs/2409.15790

Projekt-Homepage

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

GitHub-Repository

https://github.com/UbiquitousLearning/SLM_Survey

---

Dieser Beitrag basiert auf einem mit einem GPT-Modell zusammengefassten Text; daher kann es vorkommen, dass Inhalte anders als im Original oder nicht ganz im Sinne des Originals dargestellt sind. Wenn Sie das Thema interessiert, lesen Sie bitte auch den Originaltext. Falls Ihnen beim Lesen unnatürliche Formulierungen oder Fehler auffallen, teilen Sie uns dies bitte in den Kommentaren mit. 🤗

⚠️Werbung⚠️: Fanden Sie diesen von der PyTorch Korea User Group🇰🇷 zusammengestellten Beitrag hilfreich? Wenn Sie Mitglied werden, senden wir Ihnen wichtige Beiträge per E-Mail💌 zu! (Standard ist wöchentlich, aber eine Umstellung auf täglich ist ebenfalls möglich.)