Bevor du Code anfasst: Was du wirklich brauchst, um ein LLM zu trainieren
Ein Sprachmodell von Grund auf zu trainieren bedeutet nicht, ein Skript herunterzuladen und die Eingabetaste zu drücken. Es ist ein Ingenieurprojekt mit drei Fronten, die du vor der ersten Codezeile lösen musst: Daten, Rechenleistung und Evaluierung. Laut der offiziellen Dokumentation von Frameworks wie PyTorch und Hugging Face stammen die meisten Misserfolge in Trainingsprojekten nicht vom Code, sondern von einer mangelhaften Planung des Korpus und einer schlecht dimensionierten Infrastruktur.
Dieser Artikel beschreibt eine Schritt-für-Schritt-Konfiguration unter der Annahme, dass du ein kleines oder mittleres Modell (zwischen 100M und 1.500M Parametern) für eine bestimmte Domäne erstellen möchtest, keinen Konkurrenten der großen generalistischen Modelle. Wenn dein Ziel ein Modell mit 70B Parametern und massiven mehrsprachigen Daten ist, wird das Budget in Millionen von Dollar gemessen und dieses Tutorial reicht nicht aus: Erkenne das von Anfang an an.
Schritt 1: Definition des Umfangs und des Rechenbudgets
Bevor du den Tokenizer schreibst, entscheide die Modellgröße in Abhängigkeit von den verfügbaren GPUs. Die in der Industrie verwendete Faustregel setzt Trainingstoken in Beziehung zu Parametern: Ein gut trainiertes Modell verbraucht in der Regel zwischen 20 und 100 Mal mehr Token als Parameter. Für ein Modell mit 125M Parametern ist ein Korpus von 2.500M bis 10.000M Token vernünftig.
Schätzung von VRAM und Zeit
Der während des Trainings benötigte Speicher hängt nicht nur von der Modellgröße ab. Die Zustände des AdamW-Optimizers vervierfachen das Gewicht des Modells in gemischter Präzision. Ein Modell mit 125M Parametern kann allein für die Optimizer-Zustände zwischen 2 und 3 GB verbrauchen, plus Aktivierungen und Gradienten. Auf einer GPU mit 24 GB kannst du Modelle mit bis zu 300-400M Parametern mit kleinem Batch und Gradient Checkpointing trainieren.
Ein häufiger Fehler, den ich bei unerfahrenen Teams gesehen habe: anzunehmen, dass eine Consumer-RTX 4090 das Training eines Modells mit 1B Parametern ohne Speicherspar-Techniken ermöglicht. Die Realität ist, dass das Training nach wenigen Schritten wegen OOM (out of memory) stoppt und die Debugging-Zeit die Trainingszeit übersteigt.
Schritt 2: Aufbau und Bereinigung des Korpus
Der Datensatz ist das wertvollste und am meisten vernachlässigte Asset. Für ein Domänenmodell (Recht, Medizin, Technik, Kundenservice) benötigst du zwischen 1.000 und 10.000 Millionen Token hochwertigen Text. Wenn du bei null anfängst, muss die Bereinigungs-Pipeline Folgendes umfassen:
- Deduplizierung auf Dokument- und Absatzebene mit MinHash oder SimHash. Ohne dies memorisiert das Modell und überanpasst sich an wiederholte Sätze.
- Sprachfilterung mit einem leichten Klassifikator (fastText funktioniert gut), um Inhalte zu verwerfen, die nicht Spanisch sind, falls das deine Domäne ist.
- Entfernung von Boilerplate (Navigationsmenüs, Cookie-Hinweise, Footer), die das Trainingssignal vergiften.
- Heuristische Qualitätskontrolle: Verhältnis alphabetischer Zeichen, durchschnittliche Satzlänge, Vorhandensein von n-Gramm-Wiederholungen.
Laut Branchenstudien zu öffentlichen Datensätzen wie C4 und The Pile werden zwischen 40% und 60% des Rohtexts nach der Bereinigung verworfen. Plane den Speicher entsprechend: Ein Korpus von 10.000M Token in Klartext belegt etwa 40 GB.
Schritt 3: Domänenspezifischer Tokenizer
Verwende den Tokenizer von GPT-2 oder Llama nicht wieder, wenn deine Domäne ein eigenes Vokabular hat. Ein auf deinem Korpus trainierter BPE-Tokenizer reduziert die Anzahl der Token pro Dokument und beschleunigt das Training. Die Konfiguration mit der Bibliothek tokenizers von Hugging Face ist unkompliziert:
from tokenizers import Tokenizer, models, trainers, pre_tokenizers
tokenizer = Tokenizer(models.BPE(unk_token=»[UNK]»))
tokenizer.pre_tokenizer = pre_tokenizers.ByteLevel(add_prefix_space=False)
trainer = trainers.BpeTrainer(vocab_size=32000, special_tokens=[«[PAD]»,»[UNK]»,»[BOS]»,»[EOS]»])
tokenizer.train_from_iterator(corpus_iter, trainer=trainer)
tokenizer.save(«tokenizer_dominio.json»)
Ein Vokabular zwischen 32.000 und 50.000 Token deckt allgemeines Spanisch gut ab. Für technische Domänen mit vielen Akronymen ziehe 48.000 in Betracht. Überprüfe die Kompressionsrate: Wenn dein Tokenizer im Durchschnitt mehr als 1,4 Token pro Wort erzeugt, benötigst du wahrscheinlich mehr Vokabular oder einen repräsentativeren Trainingskorpus.
Schritt 4: Modellarchitektur und Anfangskonfiguration
Für ein Modell von Grund auf ist eine Decoder-only-Architektur vom GPT-Typ der Standard. Die Konfiguration muss kohärent sein: verborgene Dimension (d_model), Anzahl der Schichten, Attention-Heads und Feed-Forward-Dimension. Eine Regel, die funktioniert: Feed-Forward = 4 × d_model, und die Anzahl der Heads so, dass die Dimension pro Head 64 oder 128 beträgt.
Beispielkonfiguration für ein Modell mit 125M
{
«vocab_size»: 32000,
«hidden_size»: 768,
«num_hidden_layers»: 12,
«num_attention_heads»: 12,
«intermediate_size»: 3072,
«max_position_embeddings»: 1024,
«hidden_act»: «gelu»,
«dropout»: 0.1
}
Mit dieser Konfiguration hat das Modell ungefähr 125M Parameter. Wenn deine GPU 16 GB hat, reduziere den Batch pro Gerät auf 8 und verwende Gradientenakkumulation von 4 für einen effektiven Batch von 32. Die typische anfängliche Learning Rate ist 3e-4 mit Cosinus-Scheduler und Warmup von 2.000 Schritten.
Schritt 5: Trainingsschleife mit PyTorch und Accelerate
Die minimal viable Konfiguration verwendet transformers mit Trainer oder eine manuelle Schleife mit accelerate. Für vollständige Kontrolle ist die manuelle Schleife vorzuziehen. Die kritischen Punkte:
- Gemischte Präzision (fp16 oder bf16) mit torch.cuda.amp. Auf Ampere- oder neueren GPUs ist bf16 stabiler.
- Gradient Checkpointing aktiviert, wenn das Modell nicht in den Speicher passt.
- Speichern von Checkpoints alle 500 Schritte, nicht jede Epoche. Bei großen Modellen kann eine Epoche undurchführbar sein.
- Evaluierung der Perplexität auf einem Validierungssatz von 5% des Korpus.
Ein Detail, das man nur durch Praxis lernt: Der Loss kann stabil erscheinen, aber die Validierungs-Perplexität divergiert, wenn der Validierungskorpus eine andere Verteilung hat. Stelle sicher, dass die Validierung zufällig aus demselben bereinigten Korpus entnommen wird, nicht aus einer anderen Quelle.
Schritt 6: Evaluierung und Alarmsignale
Die Perplexität reicht nicht aus. Du musst das Modell in konkreten Aufgaben evaluieren: Textgenerierung, Klassifikation oder Beantwortung von Fragen. Für ein kleines Modell verwende leichte Benchmarks wie eine Teilmenge der Reasoning-Aufgabe oder manuelle Generierungstests mit Prompts aus deiner Domäne.
Anzeichen dafür, dass etwas schief läuft:
- Loss, der sinkt, aber inkohärente Generierung: wahrscheinlich Überanpassung durch Duplikate im Korpus.
- Validierungs-Perplexität, die nach einem Minimum ansteigt: Learning Rate zu hoch oder Korpus zu klein für die Modellgröße.
- Wiederholungen in der Generierung: mangelnde Vielfalt im Korpus oder schlecht trainierter Tokenizer.
Schritt 7: Feintuning und Deployment
Ein von Grund auf trainiertes Basismodell befolgt keine Anweisungen. Für den praktischen Einsatz benötigst du eine Instruktionsphase oder überwachtes Feintuning mit Frage-Antwort-Paaren aus deiner Domäne. Diese Phase ist leichter: Zwischen 10.000 und 100.000 hochwertige Beispiele reichen in der Regel für ein kleines Modell aus.
Das Deployment mit vLLM oder llama.cpp ermöglicht es, das Modell mit Quantisierung auf 8 oder 4 Bit zu bedienen, wodurch die VRAM-Anforderungen reduziert werden. Ein Modell mit 125M, auf 4 Bit quantisiert, belegt weniger als 100 MB und kann auf der CPU laufen, obwohl die Latenz höher sein wird.
Einschränkungen, die du akzeptieren musst
Von Grund auf zu trainieren garantiert keine Qualität. Ein Modell mit 125M, trainiert mit 5.000M Token auf Spanisch, wird begrenztes Faktenwissen haben und häufig halluzinieren. Es konkurriert nicht mit größeren vortrainierten Modellen. Wenn dein Ziel ein allgemeiner Konversationsassistent ist, ist das Feintuning eines bestehenden Modells kosteneffizienter und zeitsparender. Das Training von Grund auf ist sinnvoll, wenn du vollständige Kontrolle über das Vokabular, die Lizenz oder die Architektur benötigst oder wenn du Trainingsdynamiken erforschst.
Laut der offiziellen PyTorch-Dokumentation und den Hugging-Face-Leitfäden kann der Aufwand für ein Training mit 125M Parametern und 5.000M Token auf einer einzelnen GPU mit 24 GB je nach Durchsatz zwischen mehreren Tagen und einer Woche liegen. Es gibt keine Abkürzungen: Die Daten-Pipeline verbraucht genauso viel Zeit wie das Training.
Wenn du dich entscheidest, voranzuschreiten, beginne mit einem Korpus von 500M Token und einem Modell mit 50M Parametern. Validiere die gesamte Pipeline, bevor du skalierst. Die Erfahrung zeigt, dass 80% der Fehler in den ersten 24 Trainingsstunden auftreten und mit einem kleinen Modell leichter zu korrigieren sind.