Ein Sprachmodell von Grund auf zu trainieren ist kein Akt reiner Rechenleistung. Es ist ein Ingenieurprojekt mit Dutzenden aufeinander aufbauender Entscheidungen, bei dem ein früher Fehler Wochen an Rechenzeit und Tausende Euro an GPU-Kosten zunichtemachen kann. Die meisten Leitfäden erklären die ideale Pipeline (Tokenizer, Datensatz, Vortraining, Feintuning), aber fast keiner geht auf die Fehler ein, die tatsächlich passieren, wenn jemand versucht, sie in die Praxis umzusetzen. Dieser Artikel behandelt genau das: die häufigsten Fehler und wie man sie erkennt, bevor es zu spät ist.
Fehler in der Datenphase: der Ursprung fast aller Probleme
1. Den Datensatz in Gigabyte statt in nutzbaren Tokens messen
Ein häufiger Fehler ist es, mit dem Korpus aufgrund seiner Größe auf der Festplatte zu prahlen. Eine komprimierte Datei von 50 GB kann weniger nutzbaren Text enthalten, als sie vermuten lässt, und nach Deduplizierung und Filterung von HTML-Boilerplate kann nur ein Bruchteil übrig bleiben. Was zählt, ist die Anzahl der Tokens nach der tatsächlichen Tokenisierung, nicht das Gewicht der Datei.
So vermeiden Sie es: Tokenisieren Sie eine repräsentative Stichprobe (zum Beispiel 1 GB entpackt) mit genau dem Tokenizer, den Sie verwenden werden, berechnen Sie das Verhältnis Tokens/Zeichen und extrapolieren Sie. Wiederholen Sie die Berechnung nach jeder Bereinigungsphase. Wenn der endgültige Korpus kein angemessenes Volumen für die Modellgröße erreicht, überdenken Sie das Ziel, bevor Sie das Training starten.
2. Nur mit exakter Übereinstimmung deduplizieren
Die Deduplizierung per exaktem Hash entfernt identische Kopien, lässt aber Paraphrasen, wiederholte Vorlagen und nahezu doppelte Fragmente durch, die bestimmte Verteilungen künstlich aufblähen. Das Modell memorisiert am Ende wiederkehrende Sätze und erzeugt repetitive Ausgaben.
So vermeiden Sie es: Wenden Sie unscharfe Deduplizierung per n-Grammen oder per MinHash-Ähnlichkeit auf Dokumentblöcke an. Sie brauchen kein perfektes System: Das Entfernen naher Duplikate auf Absatzebene reduziert das Rauschen bereits erheblich.
3. Die Domänenmischung und die Qualitätsfilterung ignorieren
Generisches Web, Code, wissenschaftliche Artikel und Foren ohne Gewichtung zu mischen, erzeugt Modelle, die den Ton eines Forums in Antworten imitieren, die formell sein sollten. Ebenso häufig werden toxische Inhalte, Spam oder automatisch generierter Text nicht gefiltert.
So vermeiden Sie es: Legen Sie explizite Anteile pro Quelle fest, dokumentieren Sie, woher jeder Block stammt, und wenden Sie leichte Qualitätsklassifikatoren an. Laut offizieller Dokumentation mehrerer offener Projekte hat die Qualitätsfilterung mehr Einfluss auf das Endergebnis als das Hinzufügen weiterer Daten minderer Qualität.
4. Kontamination des Evaluierungsdatensatzes
Dies ist wahrscheinlich der stillste Fehler. Wenn Ihr Validierungsdatensatz oder Ihre internen Benchmarks – auch nur teilweise – in den Trainingsdaten auftauchen, lügen die Metriken. Ein Modell, das sich bei jeder Evaluierung „verbessert», memorisiert möglicherweise einfach nur.
So vermeiden Sie es: Trennen Sie die Evaluierungsdatensätze ab, bevor Sie den Korpus erstellen, speichern Sie Fingerabdrücke (Hashes von n-Grammen) dieser Datensätze und prüfen Sie die Überschneidung mit dem Trainingsdatensatz. Bei Übereinstimmungen entfernen Sie diese aus dem Korpus, nicht aus dem Test.
Fehler bei Tokenisierung und Architektur
5. Den Tokenizer mit einem Korpus trainieren, der die endgültige Domäne nicht repräsentiert
Wenn der Tokenizer nur mit Englisch trainiert wird und das Modell später für Spanisch oder Code verwendet wird, steigt die Anzahl der Tokens pro Wort sprunghaft an, das effektive Kontextfenster schrumpft und die Trainings- und Inferenzkosten steigen, ohne dass dies in den anfänglichen Metriken auffällt.
So vermeiden Sie es: Trainieren Sie den Tokenizer mit einer geschichteten Stichprobe, die die tatsächlichen Sprachen und Domänen der Nutzung widerspiegelt. Prüfen Sie mit Out-of-Sample-Text, wie viele Tokens derselbe Satz in verschiedenen Sprachen verbraucht; bei enormen Unterschieden überprüfen Sie das Vokabular.
6. Die Modellgröße ohne klares Rechenbudget wählen
Ein größeres Modell ist für ein konkretes Ziel nicht immer besser und stellt zudem Speicher- und Zeitanforderungen, die viele Projekte unterschätzen. Ein Vortraining zu starten, ohne die Gesamtkosten (GPU-Stunden, Checkpoints, Speicher, Wiederholungsläufe) berechnet zu haben, ist ein schneller Weg, auf halbem Weg steckenzubleiben.
So vermeiden Sie es: Führen Sie einen Skalierungstest mit einem kleinen Modell über wenige Stunden durch, messen Sie den tatsächlichen Durchsatz auf Ihrer Hardware und extrapolieren Sie. Wenn das Budget nicht das vollständige Training plus mindestens einen Neustart aus dem Checkpoint abdeckt, reduzieren Sie die Größe.
7. Die realistische Kontextlänge nicht definieren
Riesige Kontexte anzukündigen, ohne Daten, die sie nutzen, erzeugt Modelle, die bei langen Fenstern schlechter abschneiden, als die Architektur vermuten lässt. Die Attention über lange Sequenzen verteuert das Training, und wenn der Korpus aus kurzen Dokumenten besteht, lernt das Modell nie, sie zu nutzen.
So vermeiden Sie es: Richten Sie die Sequenzlänge an der tatsächlichen Verteilung Ihrer Dokumente aus. Wenn Sie langen Kontext benötigen, nehmen Sie Daten mit langer Struktur auf und evaluieren Sie gezielt Aufgaben, die ihn erfordern.
Fehler während des Vortrainings
8. Den Loss nicht pro Domäne überwachen
Der globale Loss kann sinken, während eine bestimmte Domäne schlechter wird. Wenn das Modell sich an das generische Web überanpasst und Fähigkeiten in Code oder einer bestimmten Sprache verliert, verbirgt die aggregierte Metrik dies.
So vermeiden Sie es: Protokollieren Sie den Validierungs-Loss aufgeschlüsselt nach Quelle. Ein Dashboard mit getrennten Kurven pro Domäne erkennt Ungleichgewichte viel früher als der globale Durchschnitt.
9. Unzureichende oder schlecht verwaltete Checkpoints
Nur am Ende zu speichern, ist ein Glücksspiel. Hardwarefehler, Cluster-Neustarts oder numerische Instabilität können dazu zwingen, Tage an Rechenzeit zu wiederholen. Ebenso häufig werden Checkpoints gespeichert, ohne die zugehörige exakte Konfiguration zu protokollieren, was es unmöglich macht, den Zustand zu reproduzieren.
So vermeiden Sie es: Speichern Sie regelmäßige Checkpoints mit ihrer Konfiguration, ihrem Seed und dem Zustand des Optimierers. Verifizieren Sie, dass die Wiederaufnahme aus dem Checkpoint funktioniert, bevor Sie das lange Training starten.
10. Die numerische Instabilität ignorieren
Loss-Spitzen, explodierende Gradienten oder sporadische NaN sind Anzeichen dafür, dass die Trainingskonfiguration nicht stabil ist. Viele Projekte behandeln sie als Rauschen und machen weiter, und das endgültige Modell bleibt auf schwer zu diagnostizierende Weise beeinträchtigt.
So vermeiden Sie es: Verwenden Sie Gradient Clipping, überprüfen Sie die Initialisierungsskala und testen Sie mit kürzeren Sequenzen, bevor Sie skalieren. Wenn NaN auftreten, stoppen Sie und analysieren Sie; starten Sie nicht blind neu.
Fehler beim Feintuning und bei der Evaluierung
11. Feintuning mit der Behebung von allem verwechseln
Feintuning korrigiert kein mangelhaftes Vortraining. Wenn das Basismodell nicht genügend Kapazität oder Daten hat, kaschiert das Feintuning nur das Ergebnis im Evaluierungsdatensatz und generalisiert schlecht.
So vermeiden Sie es: Evaluieren Sie das Basismodell vor dem Feintuning. Wenn die Basis-Metriken schlecht sind, investieren Sie in Daten und Vortraining, nicht in mehr Feintuning-Epochen.
12. Nur mit automatischen Metriken evaluieren
Perplexität und Genauigkeit bei synthetischen Aufgaben beschreiben nicht das tatsächliche Verhalten. Ein Modell kann sich bei einer Metrik verbessern und dabei repetitiver, unsicherer oder im Gespräch weniger nützlich werden.
So vermeiden Sie es: Kombinieren Sie automatische Metriken mit menschlichen Bewertungen anhand einer kleinen, aber klar definierten Stichprobe. Dokumentieren Sie die Kriterien und prüfen Sie regelmäßig, ob sie noch messen, was Ihnen wichtig ist.
13. Den Prozess nicht dokumentieren
Ohne Aufzeichnung von Datenversionen, Hyperparametern und Ergebnissen ist jedes Experiment nicht wiederholbar. Das ist kein akademisches Detail: Im Produktivbetrieb ist die Nachvollziehbarkeit das, was eine Diagnose ermöglicht, wenn etwas schiefgeht.
So vermeiden Sie es: Versionieren Sie den Datensatz, die Konfiguration und die Checkpoints mit klaren Bezeichnern. Eine minimale, aber konsistente Aufzeichnung erspart Wochen der Verwirrung.
Ein konkretes Beispiel, das das Problem veranschaulicht
In einem realen Projekt zum Feintuning eines kleinen Modells für technische Antworten auf Spanisch stellte das Team fest, dass das Modell korrekte Antworten, aber in einem seltsam werblichen Ton erzeugte. Die Ursache lag nicht im Feintuning: Der Vortrainingskorpus enthielt einen hohen Anteil an Marketingseiten und Produktblogs, die bestimmte Themen dominierten. Der globale Loss war gut, und die automatischen Metriken erkannten es nicht. Korrigiert wurde es durch Neuausbalancieren der Domänenmischung und Filtern werblicher Inhalte, nicht durch Hinzufügen weiterer Daten.
Diese Art von Problem erkennt man nur, wenn man regelmäßig echte Modellausgaben liest und sie mit dem Erwarteten vergleicht, nicht nur indem man Loss-Kurven betrachtet.
Was dieser Artikel nicht abdeckt und warum
Ein LLM von Grund auf in industriellem Maßstab zu trainieren, erfordert verteilte Infrastruktur, Parallelisierungsstrategien und Speicheroptimierungen, die von der konkreten Hardware und dem gewählten Framework abhängen. Das hier Beschriebene konzentriert sich auf die Beurteilungsfehler, die in jedem Maßstab auftreten, von einem kleinen Modell auf einer einzelnen GPU bis zu einem größeren Projekt. Keine dieser Empfehlungen garantiert Ergebnisse: Das endgültige Verhalten hängt vom Zusammenspiel von Daten, Architektur und Konfiguration ab, und es gibt immer Unsicherheit.
Wenn eines diejenigen auszeichnet, die Modelle erfolgreich trainiert haben, dann ist es Umsicht: Sie gehen davon aus, dass der Datensatz Probleme hat, dass die Metriken täuschen können und dass das erste Training nicht das endgültige sein wird. Für diese Realität zu planen, spart mehr Zeit als jede voreilige Optimierung.