HuggingFace hat ein über 200 Seiten langes "Praktisches Handbuch" veröffentlicht, das Sie "Schritt für Schritt" vom Entscheidungsfindungsprozess bis zur Umsetzung beim Training von Large Language Models unterrichtet.

In letzter Zeit hat HuggingFace einen über 200 Seiten langen technischen Blog veröffentlicht, in dem es systematisch über das end-to-end-Erfahrungswissen beim Training fortschrittlicher LLMs teilt.

Der Schwerpunkt des Blogs liegt auf der „chaotischen Realität“ im LLM-Entwicklungsprozess. Es dokumentiert offen, welche Methoden funktionieren, welche fehlschlagen und wie man mit den Fallstricken umgeht, die man in der praktischen Ingenieurarbeit antrifft. Der Inhalt basiert auf den tatsächlichen Projekterfahrungen des Teams, insbesondere auf dem Prozess des Trainings des 3B-Parameter-Modells SmolLM3 mit 384 H100-GPUs in letzter Zeit.

Im Blog werden detaillierte technische Details, Code-Schnipsel und Debugging-Tipps bereitgestellt, was für Leser, die sich für das eigene Bauen von LLMs interessieren, sehr hilfreich ist.

Im Folgenden finden Sie eine Zusammenfassung des Blog-Inhalts. Wir empfehlen es sehr, dass interessierte Leser den Originaltext lesen.

• Blog-Adresse: https://huggingface.co/spaces/HuggingFaceTB/smol-training-playbook#positional-encodings--long-context

Trainingskompass: Warum → Was → Wie

In diesem Abschnitt wird vor dem Eintauchen in die technischen Details (wie man trainiert) die zentrale Frage gestellt: „Brauchen Sie wirklich dieses Modell zu trainieren?“

Angesichts der Tatsache, dass es immer wieder weltklasse Open-Source-Modelle wie Qwen, Gemma und Llama gibt, müssen die meisten Leute möglicherweise nicht von Grund auf ihr eigenes Modell trainieren.

Warum

Im Artikel werden einige falsche Gründe aufgeführt, warum man ein Modell nicht trainieren sollte, wie z. B. „Wir haben ungenutzte Rechenkapazitäten“, „Alle anderen machen es“ oder „KI ist die Zukunft“.

Dann wird ein Flussdiagramm bereitgestellt, das Ihnen hilft, zu überlegen, ob Sie wirklich ein eigenes Modell trainieren sollten.

Wenn Sie feststellen, dass das vorhandene Modell nicht verwendbar ist -> die Prompt-Engineering nicht hilft -> das Fine-Tuning nicht hilft, können Sie überlegen, von Grund auf zu trainieren.

Das maßgeschneiderte Pre-Training eignet sich in der Regel für drei Hauptbereiche:

• Forschung: Sie haben eine klare wissenschaftliche Frage, die Sie beantworten müssen. Zum Beispiel das Testen eines neuen Optimierers, die Erforschung der Modellfähigkeiten (z. B. nur mit Reinforcement Learning) oder das Testen eines neuen Datensatzes (z. B. rein synthetische Daten).
• Produktion: Ihr Geschäft hat bestimmte Bedürfnisse, die nicht erfüllt werden können. So wie hoch spezialisierte Vokabeln oder Logiken in Bereichen wie DNA, Recht, Finanzen usw.; Es muss auf bestimmten Hardware (z. B. Drohnen, lokalen FPGAs) laufen oder es gibt strenge Latenzanforderungen; Sie befinden sich in einer regulierten Branche und müssen 100 % Kontrolle und Nachverfolgbarkeit über die Trainingsdaten und das Modellverhalten haben.
• Strategisches Open-Source: Sie entdecken und haben die Fähigkeit, eine bestimmte Lücke im aktuellen Open-Source-Ökosystem zu schließen.

Was

Sobald Sie den „Warum“-Aspekt klar haben, können Sie ableiten, „was zu trainieren ist (Was)“. Dies umfasst den Modelltyp (dicht, MoE, Hybrid, eine neue Art), die Modellgröße, die Architekturdetails und die Datenmischung.

Gleichzeitig bestimmen die vorherigen Bereichsziele Ihre Trainingsentscheidungen: Beispielsweise für die Ausführung auf Geräten -> Trainieren eines kleinen und effizienten Modells; Wenn Sie Mehrsprachigkeitsfähigkeit benötigen -> Verwenden eines größeren Tokenizer-Vokabulars; Für einen sehr langen Kontext -> Hybridarchitektur.

Dieser Entscheidungsprozess gliedert sich in zwei Phasen. Planung: Mapping Ihrer Beschränkungen (aus dem „Warum“) auf konkrete Modell-Spezifikationen; Validierung: Testen Ihrer Auswahl durch systematische Experimente (Ablations-Experimente).

Der Artikel weist auf zwei Schlüsselmerkmale erfolgreicher LLM-Trainingsteams hin:

• Iterationsgeschwindigkeit: Das Training von LLMs ist ein Prozess des „Lernens beim Trainieren“. Teams, die schnell und häufig (z. B. vierteljährlich statt jährlich) neue Modelle trainieren können, werden schneller voranschreiten.
• Datenverwaltung: Die besten Teams sind diejenigen, die „verrückt nach hochwertigen Daten“ sind. Die Datenqualität hat einen weitaus größeren Einfluss als die Architekturauswahl.

Der Artikel empfiehlt auch, dass ein Pre-Trainingsteam am Anfang nicht viele Personen braucht (2 - 3 Personen reichen aus). Das Wichtigste ist, genügend Rechenkapazitäten bereitzustellen und eine schnelle Iteration aufrechtzuerhalten.

Jedes große Modell beginnt mit einem kleinen Ablations-Experiment

Vor dem Start des LLM-Trainings müssen eine Reihe von Schlüsselentscheidungen getroffen werden (Architektur, Optimierer, Datenkombination usw.). Menschen meinen oft, dass diese Entscheidungen durch gründliche Überlegungen getroffen werden, aber die reine logische Überlegung reicht nicht aus, da das Verhalten von LLMs oft kontra-intuitiv ist.

Ein typisches Beispiel ist: Die Verwendung von scheinbar „hochwertigsten“ arXiv-Wissenschaftspapierdaten kann die Leistung des Modells (insbesondere kleiner Modelle) eher beeinträchtigen, da diese zu spezialisiert sind und die Vielfalt von allgemeinem Text fehlt.

Da die reine Überlegung nicht funktioniert, lautet die Lösung, wie ein Empirist „eine Vielzahl von Experimenten durchzuführen“ (d. h. Ablations-Experimente).

Der vollständige Ablauf für das Einrichten von Ablations-Experimenten:

Auswahl Ihrer Basislinie

Beginnen Sie nicht von Null. Wählen Sie stattdessen eine bewährte, ausgereifte Architektur (z. B. Llama 3.1, Qwen3, Gemma3) als Ausgangspunkt, um alle bekannten Optimierungen und Stabilitätserfahrungen zu übernehmen.

Die Basislinie ist gut, aber möglicherweise nicht für Sie maßgeschneidert. Daher müssen Sie Änderungen vornehmen. Allerdings geht „jede Änderung an der Architektur mit Risiken einher“. Deshalb müssen Sie die Disziplin der „Risikoreduktion“ befolgen, d. h. „Ändern Sie nichts, wenn Sie nicht getestet haben, dass es wirklich hilft.“

Die Schwierigkeit bei den Änderungen liegt darin, dass es zu viele Komponenten gibt, die miteinander interagieren. Sie können nicht alle Kombinationen testen. Die richtige Methode ist: Testen Sie immer nur eine vielversprechende Änderung auf einmal. Wenn es funktioniert, integrieren Sie es und machen es zur neuen Basislinie, und testen Sie dann die nächste Änderung.

Auswahl des Trainingsframeworks

Dies ist eine zentrale technische Entscheidung, bei der Sie zwischen Funktionalität, Stabilität und Durchsatz abwägen müssen.

Der Artikel vergleicht einige führende Frameworks:

• Megatron-LM / DeepSpeed: Sehr leistungsfähig und praktisch erprobt, aber der Codebase ist riesig und komplex.
• TorchTitan: Leichtergewichtig, einfach zu erlernen und zu experimentieren, aber relativ neu.
• nanotron (selbst entwickelt vom Autor): Bietet volle Flexibilität, aber erfordert einen großen Aufwand für die Entwicklung und das Testen.

Entwurf des Ablations-Experimentes

Das Experiment muss schnell genug sein (für eine schnelle Iteration) und zuverlässig genug (die Ergebnisse müssen auf das Endmodell extrapolierbar sein). Es gibt zwei Hauptmethoden:

• Vollformat-Modell, weniger Daten: Verwenden Sie die Größe des Endmodells (z. B. das 3B-Modell SmolLM3), aber trainieren Sie auf weniger Token (z. B. 100M anstelle von 11T).
• Kleines Proxy-Modell: Wenn das Zielmodell zu groß ist (z. B. 1T Parameter), verwenden Sie ein skaliertes Proxy-Modell (z. B. ein 3B-Modell) für das Experiment.

Anschließend wird der Artikel über seine Baseline-Ablations-Einstellung (1B Llama-Modell, Training mit 45B Token) und zeigt die Schlüsselteile der Konfigurationsdatei (Daten, Modell, Optimierer usw.).

Verständnis, was funktioniert: Bewertung

Der Artikel weist darauf hin, dass es unzuverlässig ist, nur den Trainingsverlust (Loss) bei der Bewertung der Experimentergebnisse zu betrachten. Beispielsweise ist der Loss beim Training auf Wikipedia niedriger, aber das bedeutet nicht, dass das Modell leistungsfähiger ist; Das Ändern des Tokenizers führt auch dazu, dass die Loss-Werte nicht direkt verglichen werden können. Daher müssen Sie eine feingliedrigere Downstream-Bewertung verwenden.

Eine zuverlässige Bewertungsaufgabe sollte vier Kriterien erfüllen: Monotonie, geringer Rauschen, überzufällige Leistung und Rangkonsistenz.

Insbesondere in den frühen Experimenten ist das „Fill-in-the-Blank (CF)“-Format besser als das „Multiple-Choice (MCF)“-Format, da letzteres (z. B. MMLU) in den frühen Phasen des Modelltrainings nahezu zufällig agiert und keine effektiven frühen Signale liefern kann.

Der wahre Wert der Ablations-Experimente liegt nicht nur darin, ein gutes Modell zu bauen, sondern auch darin, dass es das Vertrauen für die zukünftige Fehlersuche schafft: Wenn beim Haupttraining unweigerlich Fehler auftreten, können die systematischen Experimentergebnisse dem Team helfen, das Problem schnell zu lokalisieren.

Allerdings ist der Preis für diesen Wert extrem hoch. Am Beispiel von SmolLM3 hat die Ablation und das Debugging mehr als die Hälfte der GPU-Zeit des Haupttrainings beansprucht.

Modellarchitektur-Entwurf

Dieser Abschnitt beschreibt ausführlich den gesamten Entscheidungsprozess für das Design und die Festlegung der LLM-Architektur, von den hohen Zielsetzungen bis hin zur konkreten Komponentenauswahl und Hyperparameter-Einstellung.

Der Artikel verwendet das 3B (3 Milliarden Parameter)-Modell namens SmolLM3 als Beispiel und zeigt systematisch, wie man von Grund auf ein Modell-„Bauplan“ erstellt.

Der Artikel geht tief in die Kernarchitekturauswahl ein, die moderne Transformer ausmacht, und weist darauf hin, dass heutige Modelle (z. B. Qwen3, Gemma3) die Transformer-Basis teilen, aber durch Komponentenverbesserungen (z. B. GQA, Positionskodierung) spezifische Probleme (z. B. Speicher, Stabilität) lösen.

• Attention-Mechanismus: Dies ist der Hauptengpass bei der Inferenz. Der Schlüssel liegt im KV-Cache. Der Artikel vergleicht MHA (Standard, hoher Speicherbedarf), MQA (extreme Kompression, möglicherweise Leistungseinbußen) und GQA (Gruppenabfragen). Ablations-Experimente haben bestätigt, dass GQA in Bezug auf die Leistung mit MHA vergleichbar ist, aber den KV-Cache stark spart. Es ist die endgültige Wahl für SmolLM3.
• Langzeitkontext: Der Artikel untersucht zwei Strategien. Erstens ist die Dokumentmaske. Beim Training von „gepackten“ Daten verhindert sie, dass das Modell auf andere Dokumente in der Sequenz achtet, was für die Erweiterung des langen Kontexts von entscheidender Bedeutung ist. Zweitens ist die Positionskodierung. Die Standard-RoPE hat beschränkte Extrapolationsfähigkeiten bei langen Sequenzen. SmolLM3 verwendet eine Hybridstrategie von NoPE (eigentlich RNoPE), d. h. abwechselnd RoPE-Schichten (für kurze Kontexte) und NoPE-Schichten (für die Suche über lange Distanzen). Ablations-Experimente zeigen, dass diese Methode die Leistung bei kurzen Kontexten nicht beeinträchtigt und zugleich die Grundlage für einen langen Kontext schafft.