SmolLM3 – kleines LLM mit Mehrsprachigkeit, langem Kontext und Reasoning

• Das SmolLM3-Modell ist ein Open-Source-LLM, das bei einer Größe von 3B Parametern zugleich auf Effizienz und Leistung abzielt
• Es unterstützt 6 Sprachen, darunter Englisch, Französisch, Spanisch, Deutsch, Italienisch und Portugiesisch, und lässt sich bis auf eine Kontextlänge von 128k erweitern
• Mit dem Dual-Mode (Reasoning/Non-Reasoning) kann über die Flags /think und /no_think zwischen den Modi umgeschaltet werden
• Es stellt verschiedene Trainingsphasen wie Pretraining, Mid-Training und Post-Training sowie die offengelegten Datensätze und Engineering-Blueprints vollständig bereit
• Bei der Leistung übertrifft es Llama-3.2-3B und Qwen2.5-3B und ist auf dem Niveau von 4B-Modellen konkurrenzfähig

---

Überblick

SmolLM3 ist ein Open-Source-LLM, das im Maßstab von 3B Parametern zugleich auf Effizienz und Leistung ausgerichtet ist. Ein zentrales Unterscheidungsmerkmal ist, dass es klein und schnell ist und zugleich Long-Context, Mehrsprachigkeit und Reasoning unterstützt.

• Mit 3B Parametern auf 11 Billionen (11T) Tokens trainiert
• Erreicht State-of-the-Art-Leistung (SoTA) und kann mit 4B-Modellen konkurrieren
• Dual-Mode-Instruct-Modell: Umschaltung zwischen Reasoning und Non-Reasoning über /think und /no_think
• Unterstützung für Englisch, Französisch, Spanisch, Deutsch, Italienisch und Portugiesisch
• Bis zu 128k Kontext durch NoPE und YaRN

Die Architektur des gesamten Trainingsprozesses, die Datenmischung und die Rezepte für jede Phase werden vollständig offengelegt.

Pretraining

Architektur und Trainingseinstellungen

SmolLM3 basiert auf einem Transformer-Decoder und modifiziert die Llama-Architektur, um Effizienz und Leistung bei langen Kontexten zu verbessern.

• Grouped Query Attention (GQA): speichereffizienter als Multi-Head Attention bei gleichwertiger Leistung
• NoPE: Rotary Position Embedding wird in jeder 4. Schicht entfernt, um die Long-Context-Leistung zu verbessern
• Maskierung innerhalb von Dokumenten: Durch Maskierung wird verhindert, dass unterschiedliche Dokumente gegenseitig attendieren, was stabiles Long-Context-Training unterstützt
• Kein Weight Decay auf Embeddings: sorgt für stabiles Trainingsverhalten

Die Trainingskonfiguration:

• Global Batch von 2.36M Tokens, Sequenzlänge 4096, Learning Rate 2e-4, AdamW(β1:0.9, β2:0.95), Weight Decay 0.1, Gradient Clipping 1
• WSD-Scheduler: 2000 Warmup-Schritte, lineare Absenkung in den letzten 10 %
• Verteiltes Training mit dem nanotron-Framework, Nutzung von datatrove-Daten und dem Evaluierungstool lighteval
• 384 H100-GPUs, 24 Tage Training

Datenmischung und stufenweises Training

Pretraining in 3 Phasen:

• Phase 1 (0T→8T): Web (85 %, davon 12 % mehrsprachig), Code (12 %), Mathematik (3 %)
• Phase 2 (8T→10T): Web (75 %, davon 12 % mehrsprachig), Code (15 %), Mathematik (10 %) - zusätzliche höherwertige Code- und Mathematikdaten
• Phase 3 (10T→11.1T): Web (63 %, davon 12 % mehrsprachig), Code (24 %), Mathematik (13 %) - Upsampling hochwertiger Code- und Mathematikdaten sowie Einführung von Instruction-/Reasoning-Daten

Die Mischungsverhältnisse der Daten in jeder Phase wurden durch zahlreiche Ablationsexperimente optimiert.

Nach dem Pretraining wurde zusätzlich ein Mid-Training angewendet, um Long-Context- und Reasoning-Leistung zu stärken.

Mid-Training

Long-Context-Training

Nach dem Pretraining wurde die Kontextlänge mit zusätzlichen 100B Tokens in zwei Stufen (4k→32k→64k) erweitert.

• Erweiterung der Länge durch Anpassung von RoPE theta
• Upsampling von Mathematik-, Code- und Reasoning-Daten
• Optimierung der Leistung auf langen Sequenzen mit NoPE und Decay Mixture
• Im Training bis 64k, bei der Inferenz mit YaRN bis 128k nutzbar

Mid-Training für Reasoning

Um die Reasoning-Fähigkeit zu erhöhen, wurde das Modell mit 35B Tokens (OpenThoughts3-1.2M, Llama-Nemotron-Post-Training-Dataset usw.) erneut trainiert.

• Training allgemeiner Reasoning-Fähigkeiten ohne Spezialisierung auf ein bestimmtes Fachgebiet
• Nutzung von ChatML-Template und Wrapped Packing
• Speicherung von Checkpoints nach 4 Epochen (~140B Tokens)

Post-Training

Während die meisten Reasoning-Modelle geschlossene oder komplexe RL-Prozesse benötigen, implementiert SmolLM3 mit offenen Daten und klaren Rezepten eine Dual-Instruction-Struktur für Reasoning und Non-Reasoning.

Chat-Template

• Umschaltung des Reasoning-Modus durch Einfügen der Flags /think und /no_think in den System-Prompt
• Separate Abschnitte für XML Tools und Python Tools zur Unterstützung von Code- und Tool-Aufrufen
• Nutzung von Systemnachricht und Metadaten (Datum, Knowledge Cut-off, Reasoning-Modus), mit flexibler Möglichkeit zum Override

Supervised Finetuning (SFT)

Nach dem Mid-Training mit 140B Reasoning-Daten wurde ein überwachtes Finetuning mit 1.8B Tokens (SFT-Daten: logisches Reasoning/Nicht-Reasoning) durchgeführt.

• Zur Ergänzung seltener Reasoning-Domänen wurden synthetische Reasoning-Daten mit Qwen3-32B erzeugt
• Maximierung von Speicher- und Effizienzvorteilen mit Verfahren wie Best-Fit Decreasing Packing
• Vollständige Daten und Trainingsskripte sollen veröffentlicht werden

Anchored Preference Optimization (APO)

• Nach dem SFT wurde das Modell über APO, eine Variante von DPO, auf Basis von Tulu3 Preferences (Non-Reasoning) und synthetischen Preference-Paaren von Qwen3-32B/0.6B (Reasoning) aligned
• Die Loss wird aus Triplet-Prompt + Antwort aufgebaut, was stabile Optimierung und gute Leistung ermöglicht
• Da durch das Reasoning-Mid-Training eine Verschlechterung der Long-Context-Leistung beobachtet wurde, wurde dies durch Model Merging überwunden

Model Merging

• Nutzung der Bibliothek MergeKit, lineares Merging im Verhältnis APO-Checkpoint-Modelsoup (0.9) + Mid-Training-Checkpoint (0.1)
• Wiederherstellung der 128k-Long-Context-Leistung bei gleichzeitigem Erhalt der Gesamtleistung
• Veröffentlichung des finalen Modells mit dem optimalen Checkpoint

Evaluierung

Basismodell

In 12 wichtigen Benchmarks deutlich stärker als andere 3B-Modelle und nahe an der Leistung von 4B-Modellen

• Ausgewogene Stärken bei Dokumentenverständnis, Reasoning, Mathematik und Coding
• Klare Fähigkeiten zur Längenskalierung, etwa bei RULER 64k
• Mehrsprachige Fähigkeiten belegt durch Global MMLU, MLMM HellaSwag, Flores-200, Belebele usw.
• Konsistente Leistung auch in fünf europäischen Sprachen neben Englisch

Dual-Instruct-/Reasoning-Modell

Non-Reasoning-Evaluierung

SmolLM3 ist Llama3.2-3B Instruct und Qwen2.5 3B Instruct überlegen und bietet ein ausgewogenes Verhältnis aus Effizienz und Leistung auf dem Niveau von 4B-Reasoning-Modellen.

Reasoning-Evaluierung

Bei aktiviertem /think steigt die Leistung in den meisten Benchmarks deutlich an

• AIME 2025 (36.7 % vs. 9.3 %), LiveCodeBench (30.0 % vs. 15.2 %), GPQA Diamond (41.7 % vs. 35.7 %) usw.; auch schwierige Aufgaben werden gelöst
• 3B-Reasoning auf Augenhöhe mit Qwen3 4B, starke mathematische Reasoning-Fähigkeiten und gutes Lösen komplexer Probleme

Der Dual-Mode ermöglicht die Wahl zwischen Geschwindigkeit und tiefer Analyse.

Hinweise zur praktischen Nutzung

SmolLM3 wird offiziell ab transformers v4.53.0 unterstützt

• Laden des Modells, Schreiben von Prompts und Ausführen von Inferenz mit einfachem Code
• Umschaltung zwischen Reasoning und Non-Reasoning über die Flags /think und /no_think im System-Prompt

Für Tool-Calling (Agentic) werden die Parameter xml_tools und python_tools unterstützt.

Fazit

SmolLM3 ist ein vollständig offenes Modell, das im 3B-Maßstab Long-Context, Mehrsprachigkeit und Reasoning zugleich unterstützt.

• Vollständige Offenlegung der Engineering-Blueprints wie Trainingsrezepte für alle Phasen, Datensätze und Trainingslogs
• Maximiert die Möglichkeit für die Community, sich an Verbesserungen und Validierung zu beteiligen

Materialien

• Modell, Skripte, Datensätze usw.: HuggingFaceTB/SmolLM3-3B
• Für Paper, Evaluierung, Leichtgewichtsversionen und Merging-Tools siehe die jeweiligen Links zu GitHub, Hugging Face und Papers

[GN⁺]

Hacker-News-Kommentare

• Es wirkt, als hätte sich das Modell dem seltenen Club der Modelle angeschlossen, die den Großteil der SOTA-Leistung mit einer Größe von 3B erreichen und dabei vollständig offen sind – inklusive Code und Reproduktionsrezept. Um es selbst zu trainieren, bräuchte man wohl GPU-Zeit im Gegenwert von etwa einer Million Dollar (bei 4000 GPUs/24 Tagen). Beeindruckend ist auch die umfangreiche Dokumentation; insgesamt eine positive und solide Bereicherung für die Branche.
  • Tatsächlich müssten eher 384 H100s 24 Tage lang laufen, also liegen die Kosten nicht einmal bei der Hälfte von einer Million Dollar.
  • Ich habe heute Morgen etwa 10 Minuten lang mit Phi-4-mini-Benchmarks gegengeprüft. Es war merkwürdig, dass dieses Modell in den Benchmarks fehlte, und insgesamt sah es dort so aus, als läge es immer hinten. Zur Einordnung: Ich entwickle gerade einen LLM-Client, und mein Kernziel ist es, die Lücke zwischen lokal und Cloud zu minimieren (mit llama.cpp). Außer Microsoft gibt es derzeit kaum Firmen, die Local AI dauerhaft ernst nehmen. Normalerweise halte ich mich mit solchen Aussagen zurück, aber auch wenn HF wirklich ein vorbildlicher Akteur ist, finde ich es problematisch, nur die Stärke anderer Modelle zu betonen, ohne den Superstar zu erwähnen – das führt dazu, dass die langjährige lokale SoTA in diesem Bereich übergangen wird. Deshalb wollte ich mich diesmal bewusst dazu äußern.
• Dieses Modell ist klein (3B) und zeigt in Benchmarks eine starke Leistung. Es eignet sich gut für Edge-/Mobile-Deployments und bietet daher klare Vorteile gegenüber gemma3-4b. Es unterstützt einen Dual-Modus für Reasoning/Nicht-Reasoning und legt außerdem den gesamten Trainingsansatz vollständig offen. > Wir veröffentlichen SmolLM3 zusammen mit einem Engineering-Blueprint. Enthalten sind die Detailarchitektur, eine dreistufige Pretraining-Strategie zur schrittweisen Steigerung der domänenspezifischen Leistung sowie eine Methodik zum Aufbau hybrider Reasoning-Modelle. Für solche Ergebnisse müsste man normalerweise monatelang Reverse Engineering betreiben, aber wir legen die gesamte Methodik offen.
• Ich habe selbst den Chat-Template-Fix für llama.cpp und andere Inference-Engines gemacht. Zum Ausführen folgenden Befehl eingeben: ./llama.cpp/llama-cli -hf unsloth/SmolLM3-3B-GGUF:Q4_K_XL --jinja -ngl 99
• Die Leistung kommt fast an Qwen3 distill heran, obwohl das Modell nur 75 % von dessen Größe hat – das ist bemerkenswert. Das smollm-Basismodell war ohnehin schon hochwertig, daher habe ich es auch für Fine-Tuning konstant verwendet und plane, es in naher Zukunft auch für lokale Agenten oder Code-Vervollständigung einzusetzen. Der RL-Algorithmus wirkt ebenfalls interessant. Bisher habe ich vor allem mit OpenAI-Algorithmen gearbeitet, aber es scheint Zeit zu sein, die aktuelle SOTA wieder zu prüfen (das Tempo in diesem Bereich ist wirklich absurd schnell und schwer nachzuhalten).
• Mich würde interessieren, welche kleinen Modelle sich gut für Fine-Tuning auf verschiedenen Enterprise-Datensätzen eignen. Unsere Business Unit sucht nach kleinen Modellen, die im Browser und auf Mobilgeräten laufen können, idealerweise ohne den Aufwand mit RAG und Cloud-Ressourcen.
  • Kleine Modelle haben Schwächen bei der Wissensspeicherung. Fine-Tuning mit dem Ziel, Wissen direkt einzupflanzen, würde ich eher nicht empfehlen. Stattdessen scheint ein eingebettetes, offline deploybares RAG-System in wasm sinnvoller; es gibt bereits Beispiele, bei denen dieser Ansatz erfolgreich ist.
  • Wichtig ist, selbst mehrere Modelle zu testen und ein ordentliches Benchmarking zu haben. Machine Learning ist nicht mein Spezialgebiet, aber auch beim Fine-Tuning mit dem offiziellen Mistral-7B-Guide und den Tools blieben die Ergebnisse hinter den Erwartungen zurück. Ich habe sehr spezifische Fragen aus dem Datensatz eingebracht, doch egal welche Fine-Tuning-Variante ich probiert habe, das Modell konnte sie nicht sauber beantworten. Statt darauf zu hoffen, dass es die Information „lernt“, ist eine Mischung aus Vektorsuche und Keyword-Suche für das Extrahieren von Kontext deutlich effektiver. Ich habe den Ansatz über vortrainierte Datensätze genutzt; möglicherweise wäre ein datenbasierter Ansatz besser, bei dem man Q&A synthetisch aus den Daten erzeugt und damit trainiert, aber ich hatte nicht genug Zeit, das ebenfalls zu testen.
  • Ich habe Gemma 3N 2B finegetunt, und die Leistung war gut, nur lädt es auf dem S23U langsam. Wenn es einmal läuft, funktioniert es ordentlich. Ich habe auch SmolVLM 256M und 500M ausprobiert; die starten deutlich schneller und lassen sich als Assets in die App einbinden, also mit etwas Know-how durchaus brauchbar. Allerdings sind kleine Modelle durch ihre Parametergrenzen in der Leistung limitiert. Außerdem lassen sich auf Android Dateien über 2 GB wegen Kompressionsproblemen nicht direkt mit der App ausliefern, daher muss das Modell separat heruntergeladen werden. Und aus dem Download-Ordner kann es nicht sofort geladen werden, sondern muss erst in einen app-spezifischen Ordner kopiert werden. Gemma 3N 2B ist 3,14 GB groß, dafür braucht man mindestens 7 GB freien Speicherplatz.
  • Mich würde interessieren, welches Ziel ihr mit so einem Fine-Tuning verfolgt.
• Klingt wie Stoff für einen britischen Comedy-Sketch: „Das hier ist also ein großes Sprachmodell, obwohl es klein sein soll?“ „Ja, wirklich klein.“ „Aber wie kann es groß und klein zugleich sein?“ „Gemessen an großen Sprachmodellen … ist es klein.“ „Also ist es doch groß?“ „Genau, ziemlich groß.“ „Und im Vergleich wozu ist es groß?“ „Zu kleinen Sprachmodellen.“ „Und was ist dann so etwas wie ChatGPT? Groß unter den Großen?“ „Ganz genau. Ein LLLM.“
  • Hat etwas von australischer Comedy, erinnert an den Stil von Clarke and Dawe/Utopia.
  • Die Maßstäbe verschieben sich ständig. GPT-2 galt einmal als „groß“, heute hat es nicht einmal die Hälfte dieser Modellgröße. Außerdem meinte Sam Altman damals sogar, GPT-2 sei zu gefährlich, um es zu veröffentlichen. Für mich ist alles „groß“, was nicht auf Consumer-Geräten laufen kann, und über Definitionen zu streiten bringt wenig.
  • Den Miniatur-Riesen-Weltraumhamster rühre ich nicht an. (BG-Spielwitz)
  • Ich komme durcheinander, ob es ein big little planet oder ein small big planet ist.
• Soweit ich gehört habe, lassen sich llama3-Modelle recht gut fine-tunen (wenn ich falsch liege oder es hier bessere Modelle gibt, gern korrigieren). Mich würde interessieren, wie schwierig das Fine-Tuning von smollm3 ist; MoE-LLMs wirken in dem Punkt oft besonders launisch.
• Interessant ist auch, dass sie RL nicht direkt selbst angewendet haben, sondern nur per Fine-Tuning mit Reasoning-Traces aus einem großen Datensatz gearbeitet haben.
  • Tatsächlich wurde ein Offline-Verfahren wie Anchored Preference Optimization verwendet. Wie man schon im Open-R1-Projekt gesehen hat, ist Multi-Task-RL auf kleinen Modellen keineswegs trivial. Offline-Methoden hängen stark von Datensatz-Kuratierung/-Erzeugung ab, dafür ist die Iterationsgeschwindigkeit deutlich höher. Für die Modellgrößen, mit denen wir arbeiten, ist das ein passender Ansatz.
• Tolle Arbeit, großen Respekt an anton und alle Beteiligten. Hoffentlich geht es auch mit Modellen im Bereich 50–100M Parameter weiter. Ich halte Modelle, die wie im Solve-by-LLM-Testfall auf der CPU schnell fertig werden, ebenfalls für sehr sinnvoll.