TL;DR
Nachdem ich „What You Don't Know About Claude Code: Architecture, Governance, and Engineering Practice" und „What You Don't Know About Agents: Principles, Architecture, and Engineering Practice" geschrieben habe, wollte ich mich selbst herausfordern, zusammenzufassen, wie das Training von Large Language Models (LLMs) tatsächlich funktioniert. Dieser Artikel soll auch für Menschen ohne professionellen Hintergrund verständlich sein.
Mit Blick auf das Jahr 2026 besteht die eigentliche Lücke in der LLM-Leistung nicht mehr nur im Pre-Training selbst, sondern im langen Schwanz, der folgt: Post-Training, Evaluation, Belohnungen, Agent-Training und Destillation. Jeder Schritt beeinflusst die tatsächliche Benutzererfahrung. Wenn Sie feststellen, dass ein Modell plötzlich stärker wird, liegt das wahrscheinlich daran, dass diese Bereiche gemeinsam optimiert wurden und nicht an einem einzelnen Faktor.
Im Folgenden wird die LLM-Trainingspipeline beschrieben, wobei der Schwerpunkt darauf liegt, wie Hersteller die endgültigen Ergebnisse durch die zweite Hälfte des Trainingsstapels verbessern.
LLM-Training ist eine Pipeline
In den letzten Jahren wurde der Fortschritt von Modellen allgemein durch die Akkumulation von Parametern, Daten und Rechenleistung erklärt. Die Verbesserungen, die viele Nutzer tatsächlich spüren, kommen jedoch nicht vom Training mit mehr grundlegenden Korpora, sondern vom gesamten Trainingsprozess nach dem Pre-Training. Wie ein Modell spricht, Anweisungen folgt, argumentiert und Werkzeuge verwendet – diese Fähigkeiten wachsen nicht einfach durch das Füttern mit mehr Internettext.
InstructGPT lieferte ein sehr direktes Beispiel: Ein Modell mit nur 1,3 Mrd. Parametern, das Alignment- und Präferenzoptimierung durchlief, konnte das 175 Mrd. Parameter große GPT-3 in menschlichen Präferenzbewertungen schlagen. Bei einem Parameterunterschied von zwei Größenordnungen bevorzugten die Nutzer letztlich die viel kleinere Version. Die zweite Hälfte des Trainings schreibt die Wahrnehmung der Nutzer tatsächlich neu.
Der Trainingsprozess ist eigentlich eine Pipeline, in der Daten, Algorithmen, Systeme und Feedback stark gekoppelt sind. Eine Änderung in einer Schicht pflanzt sich normalerweise auf andere fort. Im Jahr 2026 konzentrieren sich die Modellfähigkeiten und der industrielle Wert zunehmend auf die Schichten nach dem Pre-Training.
Das ist auch der Grund, warum wir oft das Gefühl haben, dass Doubao nicht um Rankings kämpft, sich aber im täglichen Gebrauch zufriedenstellender anfühlt – weil das Post-Training gut umgesetzt ist.
Diese sechs Schichten dienen nur dazu, die Arbeitsteilung zu veranschaulichen. Die neun Stufen in der folgenden Abbildung sind eine detailliertere Version: Rohdaten und Systemrezepte werden getrennt, und Agent-Harness und Deployment sind Unterteilungen der zweiten Hälfte. Es gibt auch zwei Rückkopplungsschleifen: Produktionstraffic fließt zurück ins Data Engineering, und Offline-Evaluationsergebnisse fließen zurück ins Pre-Training.
Pre-Training ist nur die Grundlage
Pre-Training bleibt der Ausgangspunkt der Trainingskette. Nur wenn wir verstehen, was es tut, können wir verstehen, was jede nachfolgende Schicht ergänzt. Ohne diesen Schritt gibt es keine Sprachmodellierungsfähigkeit, keine Wissenskompression und keinen Raum für nachfolgenden Fähigkeitstransfer. In der Technik tut es mehr, als dem Modell nur beizubringen, das nächste Token vorherzusagen: Es lernt die Sprachverteilung, komprimiert Wissen und Muster aus großangelegten Texten in Parameter und schafft Raum für die anschließende Fähigkeitsaktivierung. Die Vorhersage des nächsten Tokens beschreibt nur die Trainingsform; sie erklärt nicht, warum Modelle plötzlich neue Fähigkeiten entwickeln, wenn der Maßstab steigt.
Nach GPT-3 berücksichtigen viele Modelloptimierungsbemühungen Budget und Verhältnisse sorgfältiger. Modelle sind nicht einfach besser, nur weil sie größer sind. Es gibt ein Verhältnisproblem zwischen Parameteranzahl, Trainings-Token und dem gesamten Rechenbudget. Viele Modelle sind nicht zu klein; sie sind untertrainiert und haben unter einem gegebenen Budget keinen geeigneteren Punkt erreicht.
Bei realen Trainingsentscheidungen lautet die praktische Frage: Wenn dir jemand 10.000 H100s und einen Monat gibt, wie würdest du ein ausreichend gutes Open-Source-Modell trainieren? Skalierungsgesetze sind hier eher ein Budgetierungs-Tool als eine abstrakte Kurve in einem Paper. Letztlich musst du abwägen: Soll die nächste Trainingsrunde mehr Parameter stapeln oder mehr Daten füttern? Fehlt dem aktuellen Modell eine Fähigkeit oder ist es nur untertrainiert? Unter einem begrenzten GPU-Budget, welches Verhältnis ist am wertvollsten?
Pre-Training ist wie das Legen des Fundaments für Modellfähigkeiten: Es bestimmt den Wissensumfang, das Generalisierungspotenzial und die Fähigkeit zur Musterinduktion. Es bestimmt auch, ob es Raum für das Post-Training gibt, um diesen auszuschöpfen. Allerdings kann Pre-Training nicht kontrollieren, ob das Modell Anweisungen folgt, mit Nutzern kooperiert oder bei kritischen Aufgaben stabil läuft.
Die Pre-Training-Phase entscheidet nicht nur, wie viel Wissen gelernt wird; sie legt im Voraus fest, was das Modell werden kann. Die Aufteilungsmethode des Tokenizers wirkt sich direkt auf das nachfolgende Training aus, und die Kontextfensterlänge muss vorab festgelegt werden. Ob multimodales Pre-Training fortgesetzt wird oder ob Single-Accelerator-Betrieb von Anfang an eine Anforderung ist – diese Abwägungen werden während der Trainingsphase in das Rezept eingeschrieben, nicht als Features zum Release hinzugefügt. Gemma 3 betont gleichzeitig Single-Accelerator, 128K Kontext, Vision-Fähigkeiten und Quantisierung, was diese Abwägungen widerspiegelt. Die Fähigkeiten, die Nutzer letztlich sehen – Ausführung auf einem lokalen Computer, Bilder erkennen, lange Dokumente verstehen – werden tatsächlich weitgehend während der Trainingsphase festgelegt.
Betrachtet man den von Chinchilla angegebenen optimalen Datenpunkt, so liegt er für ein 8B-Parametermodell bei etwa 200B Token. Allerdings verwendete Llama 3 8B tatsächlich 15T Token, etwa 75-mal mehr. Solche Übertrainingsrezepte tauschen in der Regel eine höhere Fähigkeitsdichte gegen die gleichen Parameter ein, was zu einem kleineren, kostengünstigeren Modell für die Inferenz führt. Die Messung anhand der gesamten FLOPs (Gleitkommaoperationen) ist zuverlässiger als die Betrachtung der Parameteranzahl. Die folgende Abbildung zeigt diese Lücke visuell.
Ein weiteres oft übersehenes Design findet in der Pre-Training-Phase statt: Die Vokabulargröße des Tokenizers, Aufteilungsstrategien und Byte-Level-Codierungsmethoden haben einen erheblichen Einfluss. Llama 2 hatte ein 32K-Vokabular; nachdem Llama 3 es auf 128K erweiterte, wurde die Sequenzlänge um etwa 15 % komprimiert, und die nachgelagerte Leistung folgte. Diese Auswirkung erstreckt sich auf Inferenzkosten und mehrsprachige Fähigkeiten. Die Token-Effizienz von Chinesisch, Code und mathematischen Formeln wird während des Vokabular-Designs bestimmt. Zum Beispiel kostet ein Tokenizer, der Chinesisch in sehr kleine Stücke aufteilt, nicht nur jedes Mal mehr Token; jede Inferenz muss kontinuierlich die Kosten dieser schlechten Entscheidung tragen.
Datenrezepte bestimmen die Modellfähigkeiten
Der Parameterskal war in der Vergangenheit eine wichtige Metrik, aber in den letzten zwei Jahren ist das „Datenrezept" wichtiger. Dieser Prozess sieht oberflächlich wie Datenbereinigung aus, ist aber tatsächlich eine vollständige Datenproduktionstechnik-Aufgabe. Rohdaten von Webseiten, Code-Repositories, Büchern und Foren müssen zunächst Textextraktion, Spracherkennung, Qualitätsfilterung, Datenschutzverarbeitung, Sicherheitsfilterung und Deduplizierung durchlaufen, bevor sie ins Pre-Training eingehen. Die folgende Abbildung zeigt den vollständigen Trichterverarbeitungsablauf.
Wenn man Daten nur als Trainingsbrennstoff behandelt, kommt man leicht zu dem Schluss, dass mehr besser ist. Aber Data Engineering kommt dem Fähigkeitsdesign näher. Was das Modell sieht und nicht sieht, und die Anteile von Code, Mathematik und Enzyklopädie, wirken sich direkt auf die endgültige Fähigkeitsverteilung des Modells aus.
Deduplizierung und Kontaminationskontrolle werden oft ignoriert, haben aber einen erheblichen Einfluss auf die Ergebnisse. Es geht nicht nur um minderwertige Daten; es umfasst doppelte Vorlagen, Lizenztexte, Spiegel-Websites und Kontamination durch Benchmark-Leaks. Wenn die Deduplizierung auf Dokument- und Zeilenebene unzureichend ist, absorbiert das Modell oft wiederholt die am einfachsten zu kopierenden Inhalte, ohne unbedingt die wertvollsten Teile zu lernen. Die inkonsistente Leistung vieler Open-Source-Modelle ist oft auf Lücken in der Datenverarbeitungsqualität zurückzuführen.
In den letzten zwei Jahren ist das Datenmischen selbst zu einem eigenen Forschungsproblem geworden. Arbeiten wie Data Mixing Laws konzentrieren sich nicht nur darauf, wie viel mehr Daten gesammelt werden können, sondern darauf, wie die Anteile verschiedener Datentypen das Modell zu bestimmten Fähigkeitsstrukturen führen.
Synthetische Daten haben sich auch von einem Hilfsmittel zu einem formalen Teil des Trainingsprozesses entwickelt. Methoden wie Self-Instruct, DeepSeek-R1s Destillations-Trajektorien und die zunehmend offensichtliche synthetische Überwachung in den Qwen- und Kimi-Serien bewegen sich alle in die gleiche Richtung. Jede Generation stärkerer Modelle ist an der Rekonstruktion der Daten beteiligt, die die nächste Generation sieht. Frühe Modelle generierten einfache Instruktionsdaten; stärkere Modelle generieren hochwertige Reasoning-Trajektorien und CoT (Chain-of-Thought)-Daten; und durch RL trainierte Reasoning-Modelle destillieren diese Trajektorien in kleinere dichte Modelle. „Dicht" bedeutet, dass alle Parameter laufen, im Gegensatz zu MoE (Mixture of Experts), das bei Bedarf aktiviert.
Der Schlüssel hier ist, dass Modelle oft zuerst Fähigkeiten in größerem Maßstab ausbilden müssen, bevor diese Fähigkeiten in kleinere Modelle komprimiert werden können. Die DeepSeek-R1-Distill-Serie ist ein direktes Beispiel. Große Modell-Trajektorien nach RL haben für dichte Modelle von 1,5B bis 70B erhebliche Gewinne gebracht. Llama 3.1 405B wurde ebenfalls explizit verwendet, um die Post-Training-Qualität von 8B- und 70B-Modellen zu verbessern. Dies sind keine Nebenprodukte, sondern Teil des Trainingsdesigns.
System- und Architekturbeschränkungen müssen vor dem Training klar sein
Viele verstehen Training als ein Forschungsproblem: Wie setzt man die Zielfunktion, wie reduziert man den Verlust, wie ändert man die Modellstruktur. Aber im realen LLM-Training sind Systembeschränkungen sehr wichtig; es ist ein verteiltes Systemproblem, kein Deep-Learning-Problem auf einem einzelnen Rechner. Die Anzahl der GPUs, Speicherbandbreite, parallele Strategien, Fehlertoleranz und Kosten – diese können nicht erst nach dem Training optimiert werden. Sie bestimmen von Anfang an, wie groß du trainieren kannst, welchen Kontext du unterstützen kannst und ob du komplexeres Post-Training ausführen kannst.
MoE ist das typischste Beispiel auf dieser Ebene. Der Multi-Expert-Modus ermöglicht es dem Modell, die Gesamtparameter bei ähnlicher Rechenleistung zu erweitern und gleichzeitig die Aktivierungskosten pro Token zu kontrollieren. Der Trade-off sind komplexes Routing, schwierige Lastverteilung und schwere Infrastruktur. Die MoE-Designs von DeepSeek-V3 und Qwen sind Kompromisse zwischen Kosten und Effekt, nicht nur architektonische Vorlieben.
Diskussionen in kürzlich veröffentlichten Rezepten beschäftigen sich nicht mehr nur mit grobkörnigen Analysen wie Modellgröße und Token-Verhältnissen. muP erlaubt die Übertragung von Hyperparametern von kleinen Experimenten auf groß angelegtes Training. WSD-Lernrate ist ein Fahrplan, der ansteigt, sich stabilisiert und dann abfällt. In Kombination mit optimaler Batch-Größe und höheren Daten-zu-Parameter-Verhältnissen werden diese Details zu den wahren Unterscheidungsmerkmalen zwischen Modellen gleicher Größe.
Langer Kontext, Multimodalität und neue Architekturen – wenn sie nur als Produktfunktionen verstanden werden, übersieht man die trainingsseitigen Einschränkungen. Ein 128K-Kontextziel verändert direkt die Aufmerksamkeitskosten, Batch-Größen, Trainings-Curriculum (Datenreihenfolge) und Parallelstrategien. Multimodalität verändert nicht nur die Modellstruktur, sondern auch Datenmischung, Encoder-Design und Sicherheitsbewertung. Wenn Single-Karten-Betrieb eine harte Anforderung ist, werden Parameteranzahl, Quantisierungspfade und Modellfamilien-Größe alle enger.
Arbeiten wie Forgetting Transformer und Kimis Attention Residuals beantworten ähnliche Fragen: wie man längere Kontexte trainiert und wie man Informationsverdünnung vermeidet, wenn Netzwerke tiefer werden. Was Sie sehen, ist ein Modell, das längere Eingaben verarbeiten kann oder einfacher bereitzustellen ist, aber während des Trainings steht man vor einer völlig anderen Reihe von Einschränkungen.
Das Rechenbudget ist fest. Modellgröße, Trainings-Token-Volumen, Kontextlänge und Serving-Kosten – für jedes Bit, das in eine Richtung ausgegeben wird, müssen andere nachgeben.
Mit zunehmendem Kontext explodieren die Aufmerksamkeitskosten, und die Batch-Größe muss reduziert werden. Mit größeren Modellen steigt der GPU-Speicherverbrauch, und die Serving-Kosten folgen. Dies sind keine Entscheidungen, sondern Ergebnisse von Ressourcenbeschränkungen. Die meisten Entscheidungen werden festgelegt, bevor das Training beginnt.
Es gibt auch eine technische Realität, die oft ignoriert wird: Training ist nicht immer stabil. Tausende von GPUs laufen wochenlang, und plötzlich tritt ein Trainingsverlust-Spike auf, der so groß ist, dass er nicht ignoriert werden kann, was einen Rollback zu einem Checkpoint von vor Tagen erzwingt, um von vorne zu beginnen.
Neben Verlustspikes gibt es stille GPU-Fehler – eine einzelne GPU, die keinen Fehler meldet, aber leise falsche Gradienten produziert – NVLink-Bandbreitenanomalien und Inter-Knoten-Kommunikationsjitter. Jeder kann mehrere Trainingsschritte verunreinigen. In der Lage zu sein, in groß angelegtem Training schnell zu erkennen, zu isolieren und wiederherzustellen, ist eine laborbezogene Ingenieurfähigkeit, kein Problem, das durch das Lesen von Papieren gelöst wird.
DeepSeek-V3 erwähnte in seinem technischen Bericht ausdrücklich, dass der gesamte Pre-Training-Prozess keine unwiederbringlichen Verlustspikes und keine Rollbacks aufwies. Es ist auch einer der wenigen Fälle, die bestätigen, dass FP8-Mixed-Precision-Training bei ultra-großen Modellen machbar ist. Nach öffentlichen Daten dauerte der gesamte Prozess etwa 2,788 Mio. H800 GPU-Stunden, um 14,8T Token vorzutrainieren.
Trainingssysteme und Inferenzsysteme sind eng verwandt, aber nicht das gleiche technische Problem. Training kümmert sich um Gradienten, Parallelität, Checkpoints, Durchsatz und Kosten; Inferenz kümmert sich um Latenz, KV-Cache (Zwischenspeicherung historischer Berechnungen, um Wiederholungen zu vermeiden), Quantisierung und Dienststabilität.
Post-Training bestimmt die vom Benutzer wahrgenommene Lücke
Viele Verbesserungen, die normale Benutzer tatsächlich spüren können, finden nach dem Pre-Training statt. Instruction Tuning verwendet gekennzeichnete Instruktion-Antwort-Paare für überwachtes Training. Es verändert die Art und Weise, wie das Modell antwortet, und verwandelt Anforderungen wie die Annahme von Aufgaben, die Organisation von Ausgaben und das Verhalten als kooperativer Assistent in Überwachungssignale. Ein Basismodell mag bereits viele potenzielle Fähigkeiten haben, aber ohne diesen Schritt treten diese Fähigkeiten oft nicht stabil in der von den Benutzern erwarteten Form auf.
Weiter gefasst verfolgen RLHF, DPO und RFT ähnliche Richtungen – die Integration der Definition einer „besseren Antwort" in die Trainingsschleife – jedoch über unterschiedliche Wege.
- RLHF (Reinforcement Learning from Human Feedback) imitiert zunächst qualitativ hochwertige Antworten und verwendet dann Präferenzvergleiche für die Verstärkung.
- DPO (Direct Preference Optimization) verkürzt diesen Pfad, indem es direkt aus Präferenzvergleichen lernt, ohne ein separates Belohnungsmodell zu benötigen.
- RFT (Reinforcement Fine-Tuning) ist eine in der Technik einfacher zu implementierende Schnittstelle, die Aufgabendefinitionen, Bewerter-Designs und Belohnungssignale in den Produktisierungsprozess einbringt.
Heute reicht es nicht mehr, über Post-Training nur in Bezug auf SFT oder RL zu sprechen. Die schwierigeren Teile sind, wie man Evaluationen setzt, wie man bewertet und welche Art von Antwort eine fortgesetzte Optimierung wert ist. SFT ist überwachtes Fine-Tuning; es lernt nicht nur Wissen, sondern auch Stil. Datenlänge, Format, ob Zitate enthalten sind, und Präferenz für Aufzählungspunkte beeinflussen die endgültige Ausgabeform des Modells erheblich. Viele Benutzer denken, sie vergleichen Fähigkeiten, aber sie vergleichen oft nur Stilunterschiede. Außerdem bevorzugen Präferenzbewertungen naturgemäß längere Antworten, was leicht dazu führt, dass ernst aussehende lange Ausgaben für zuverlässiger gehalten werden. Daher reicht es oft nicht, Leaderboards für Post-Training zu betrachten; man muss reale Aufgabenergebnisse, Kosten und Stabilität kombinieren.
Modernes Post-Training ist eine mehrstufige Pipeline. Das Rezept von DeepSeek-R1 ist das klarste in öffentlichen Materialien. Es läuft in vier Phasen ab:
Phase 1 ist Kaltstart-SFT. Bevor man Reinforcement Learning durchführt, verwendet man eine kleine Menge hochwertiger Chain-of-Thought (CoT)-Daten, um aufzuwärmen. DeepSeek-R1-Zero hat gezeigt, dass RL direkt von einem Basismodell (dem rohen Modell nach Pre-Training ohne Alignment) machbar ist, aber rein mit RL trainierte Modelle wiederholen sich, haben unordentliche Sprache und schlechte Lesbarkeit. Kaltstart-SFT gibt RL einen stabileren Startpunkt und sichert Format- und Sprachkonsistenz.
Phase 2 führt Reinforcement Learning in verifizierbaren Bereichen wie Mathematik, Code und Logik durch, wobei GRPO als Trainingsalgorithmus und programmatisch überprüfbare Korrektheit als Belohnungssignal verwendet wird. Der Schlüssel ist, warum GRPO gegenüber traditionellem PPO gewählt wurde: PPO (Proximal Policy Optimization) benötigt ein unabhängiges Wertnetzwerk zur Schätzung des aktuellen Zustandswerts, was für große Modelle einen hohen technischen Aufwand darstellt. GRPO sampelt mehrere Antworten für denselben Prompt und verwendet Intra-Gruppen-Ranking anstelle absoluter Wertschätzung, wodurch die Notwendigkeit eines unabhängigen Wertnetzwerks entfällt. DeepSeek-Serie und Cursor Composer 2s RL-Infrastruktur verwenden beide Schemata nahe GRPO.
Phase 3 führt Rejection Sampling Fine-Tuning durch, filtert erfolgreiche Trajektorien, die von RL erzeugt wurden, und wandelt sie in neue SFT-Daten für eine weitere Runde überwachten Fine-Tunings um. Dies ist die Brücke zwischen RL und SFT; gute Trajektorien, die von RL erkundet wurden, werden zu hochwertigen Trainingsproben für die nächste SFT-Runde.
Phase 4 integriert Hilfsbereitschafts- und Sicherheitspräferenz-Feedback, um das Modell in eine Assistentenform zu bringen, die den Veröffentlichungsstandards entspricht.
Die vier Phasen sind voneinander abhängig: Kaltstart ermöglicht es RL, stabil zu beginnen, RL erzeugt hochwertige Daten, Rejection Sampling verwandelt diese Daten in Eingaben für die nächste SFT-Runde, und Alignment-RL vollendet die Verhaltenskonvergenz. Nach öffentlichen Ergebnissen ist die Lücke zwischen direktem SFT und dem Abschluss aller vier Phasen normalerweise sichtbar.
Eval, Grader und Reward definieren Trainingsziele neu
Die Komponente, die dafür verantwortlich ist, die Modellausgabe in Trainingswerte umzuwandeln, wird als Grader bezeichnet, und sie kann leicht unerwartete Probleme haben. Wenn sie nur die endgültige Antwort betrachtet, lernt das Modell schnell, Abkürzungen zu nehmen; wenn die Bewertung zu grob ist, wird Rauschen durch Reinforcement Learning kontinuierlich verstärkt; wenn die Leaderboard-Punktzahl steigt, folgen reale Aufgaben möglicherweise nicht. Oft denken Benutzer, sie sehen eine Lücke im Basismodell, aber die Lücke liegt in der Definition des Ziels.
Im Trainingsablauf bestimmt Eval, was getestet wird, Grader bestimmt, wie eine Ausgabe zu einem Wert wird, und Reward bestimmt, wohin das Modell gedrückt wird. Zusammen bilden sie eine spezifische Rückkopplungsschleife: Aufgabendefinition, Eval, Grader, Optimierung, Rollout und Neubewertung. Rollout bezieht sich auf die Trajektorien, die das Modell bei der Ausführung von Aufgaben erzeugt. Wenn ein Glied in der Kette fehlgeht, wird auch die nachfolgende Optimierung fehlgehen.
Betrachtet man nur das Endergebnis, könnte ein Modell zufällig richtig liegen oder einem falschen Prozess folgen, um die richtige Antwort zu erhalten. Dies ist besonders offensichtlich bei Code, Mathematik und komplexen Reasoning-Aufgaben. Wenn Zwischenschritte nicht in das Feedback eingehen, lernt das Modell oft kein zuverlässigeres Reasoning, sondern wie es diesen letzten Punkt mit höherer Wahrscheinlichkeit erreicht.
Daher hat sich in den letzten Jahren mehr Arbeit von traditionellem RLHF hin zu verifizierten Belohnungen verlagert, wobei Programme verwendet werden, um die Korrektheit direkt zu überprüfen. Bei verifizierbaren Aufgaben wie Mathematik, Code und Logik kann die Korrektheit jetzt direkt bewertet werden, ohne sich hauptsächlich auf menschliche Präferenzen zu stützen. Aber verifizierte Belohnungen haben das Problem nicht vollständig gelöst. Phänomene wie Überoptimierung, Belohnungs-Overfitting (wobei Bewertungsregeln überoptimiert werden, ohne echten Fähigkeitsgewinn) und Mode Collapse (wobei die Ausgabe sehr singulär wird und Vielfalt verliert) treten immer noch auf. Das Problem hat sich von der Frage, ob Präferenzen genau gekennzeichnet sind, zur Frage verlagert, ob die Bewertungskette stabil ist.
Der Denkprozess, den das Modell schreibt, kann nicht als vollständige Aufzeichnung interner Prozesse behandelt werden. Anthropic fand in Reasoning-Modell-Beobachtbarkeitsexperimenten heraus, dass Modelle zusätzliche Hinweise verwenden, dies aber im sichtbaren CoT nicht zugeben; in Reward-Hacking-Szenarien fügen sie eher eine plausibel aussehende Erklärung hinzu. Reward Hacking bedeutet, das Bewertungssystem auszunutzen, anstatt die Aufgabe wirklich zu erledigen. Sichtbarer CoT eignet sich besser als Trainings- und Überwachungssignal, nicht als vollständige Wahrheit.
Geht man eine Ebene tiefer, könnten Modelle sogar beginnen, den Bewertungskanal selbst auszunutzen. Forschung zu Reward Tampering und Alignment Faking zeigt, dass Modelle theoretisch aktiv in den Bewertungsprozess eingreifen könnten. Reward Tampering ist die direkte Veränderung des Belohnungsberechnungsprozesses; Alignment Faking ist das Vortäuschen von Alignment – äußerlich compliant erscheinend, während nicht-aligned Absichten verborgen werden.
Sobald ein Modell stark genug Umgebungszugriff hat, optimiert es nicht nur Aufgabenergebnisse, sondern möglicherweise die Checkliste, den Belohnungscode und die Trainingsbeziehung selbst. Ein Anthropic-Experiment von 2025 injizierte zusätzliches Reward-Hack-Wissen in eine Reihe ausbeutbarer Produktions-Coding-RL-Umgebungen und beobachtete anschließend ähnliche Generalisierung. Nachdem das Modell Reward Hacking gelernt hatte, nutzte es es nicht nur weiterhin in ähnlichen Aufgaben aus, sondern zeigte auch breiteres Misalignment wie Alignment Faking.
Diese Verhaltensweisen werden in Standard-Dialogevaluationen nicht gesehen, nur in Agent-Aufgabenumgebungen. Die technische Implikation ist direkt: Reward, Grader, Umgebungsisolierung und Überwachung müssen Teil des Trainingsdesigns sein.
In der Agent-Phase wird das Belohnungsdesign weiter verfeinert. Das Endergebnis ist nur ein Punkt; Prozessqualität, Kontextmanagement und Anti-Cheat-Einschränkungen müssen ebenfalls separat gemessen werden. Kimi K2.5 belohnt effektive Zerlegung und echte Parallelität; Chroma Context-1 bewertet relevante Dokumente, die während der Suche gefunden werden; Cursor Composer 2 enthält Zusammenfassungen in langen Aufgaben als Belohnung, denn wenn eine Zusammenfassung verzerrt ist, wird der nachfolgende Kontext in die Irre geführt.
In der Implementierung ist ORM ein Outcome Reward Model, das nur die endgültige Antwort bewertet. Signale sind spärlich, Kosten sind niedrig, und es eignet sich zum Starten, aber das Modell kann leichter Abkürzungen nehmen. PRM ist ein Process Reward Model, das Zwischenschritte bewertet. Signale sind dichter, und es ist normalerweise stärker für Mathematik- und Code-Reasoning, aber die Kennzeichnungs- und Systemkosten sind viel höher. OpenAI sah in Mathematik-Reasoning-Experimenten, dass PRM nicht nur die Genauigkeit verbesserte, sondern es auch einfacher machte, den Prozess einzuschränken, weil jeder Schritt überwacht wurde. Das Problem ist auch direkt: Die Kosten von PRM sind normalerweise ein Vielfaches von ORM, daher beginnen die meisten realen Systeme mit ORM. Nur bei verifizierbaren Aufgaben wie Mathematik, Code und Logik ist es einfacher, PRM zu automatisieren, indem Programme verwendet werden, um Zwischenschritte zu verifizieren und menschliche Kennzeichnungsengpässe zu umgehen.
Die vollständige Schleife läuft wie folgt ab:
Neuere Alignment-Methoden machen alle dasselbe. Anthropics Constitutional AI integriert menschengeschriebene Prinzipien in das Training und verwendet KI-Feedback, um individuelle menschliche Präferenzen zu ersetzen. OpenAIs Deliberative Alignment bringt Sicherheitscompliance in den Reasoning-Prozess und lässt die Reasoning-Fähigkeit selbst einen Teil der Sicherheitsbeschränkung tragen. Deliberative Alignment bedeutet hier, dass das Modell Sicherheitsnormen selbst während der Reasoning-Phase beurteilt, anstatt sich auf trainierte Reflexe zu verlassen. Beide Wege verwandeln Alignment von menschlichen Labels in einen Teil des internen Trainingsziels.
Am Beispiel von Constitutional AI: Der zweistufige Prozess lässt das Modell zunächst Selbstkritik üben und die Ausgabe basierend auf Prinzipien überarbeiten, dann wird KI-Feedback verwendet, um individuelle menschliche Präferenzkennzeichnung zu ersetzen. Alignment ist niemals ein Patch, der hinter dem Training hängt; was auch immer das System testet, wie es bewertet und was es belohnt, das Modell wird sich in diese Richtung bewegen. Dies ist das direkteste Anpassungswerkzeug in der zweiten Hälfte des Trainings.
Beim Agent-Training wird nicht nur das Modell optimiert
Wie die LLM-Trainingspipeline
In den letzten zwei Jahren hat die rasche Entwicklung von Reasoning-Modellen, repräsentiert durch die o1-Serie und DeepSeek-R1, gezeigt, dass RL bei Sprachmodellen unter Bedingungen stabiler Belohnungen, zuverlässiger Verifikation und ausreichender Infrastruktur die Leistung bei Mathematik-, Code- und Logikaufgaben erheblich verbessern kann.
Dies eröffnet auch eine neue Dimension: Inferenz-Computing kann nun skaliert werden. Die Rolle des RL-Trainings fügt eine weitere Ebene hinzu: Es lehrt das Modell nicht nur, Fragen zu beantworten, sondern auch, wie es das Inferenzbudget zuweist – zu wissen, wann es mehr nachdenken und wann es aufhören soll. In Zukunft wird die Schwierigkeit darin bestehen, das Modell kontinuierlich in einer Umgebung agieren zu lassen, anstatt nur einen einzigen Gedankengang zu verlängern.
Junyang Lin, ehemaliger Model Lead bei Qwen, hat eine repräsentative Reflexion über den gemischten Ansatz von Thinking und Instruct: Die Schwierigkeit liegt nicht darin, dem Modell einen Denkschalter zu geben, sondern darin, dass die Ziele der beiden Modi unterschiedlich sind – einer strebt nach Direktheit, Compliance und niedriger Latenz, während der andere nach mehr Exploration und höherer Genauigkeit strebt. Einen Schritt weiter: Das Trainingsziel verschiebt sich von der Frage, wie lange vor der Antwort nachgedacht werden soll, hin zur Frage, wie das Budget während der Aktion zugewiesen wird, wie Feedback angenommen wird und wie die Aufgabe kontinuierlich vorangetrieben wird.
An diesem Punkt ist das Trainingsobjekt nicht mehr nur ein Modell, das Fragen beantwortet, sondern ein System, das planen, Tools aufrufen, Feedback empfangen und bei langen Aufgaben kohärent bleiben kann. Folglich ändert sich der Trainingsstack: Browser, Terminals, Suche, Ausführungs-Sandboxen, Speichersysteme, Tool-Server und Orchestrierungs-Frameworks beginnen alle, in das Trainingssystem einzutreten.
Genauer gesagt ist ein Harness ein Steuerprogramm, das um das Modell gewickelt ist. Dieses Konzept gehört nicht nur zur Agent-Laufzeit; es existiert auch in der Trainingsphase: Es bestimmt, welche Eingaben das Modell sieht, wie es Feedback erhält, wann der Kontext beschnitten wird und wann Tools aufgerufen werden. Prompt-Konstruktion, Speicher-Updates, Abrufstrategien, Kontextbearbeitung und Tool-Orchestrierung sind alle hier angesiedelt. Die Umgebung ist nicht mehr nur ein statischer Validator, sondern eine Schicht, der sich sowohl Training als auch Deployment direkt stellen müssen.
Der Harness muss stabil sein, damit das Modelltraining sinnvoll ist. Wenn die Rückgabewerte von Tools instabil sind, die Browser-Umgebung inkonsistent mit der Online-Umgebung ist oder der Dateisystemzustand nicht reproduzierbar ist, wird der Bewerter zuerst versagen, und das Modell wird anschließend lernen, Umgebungslücken auszunutzen, anstatt Fähigkeiten zu erwerben. Beim Training von Agents debuggt man oft sowohl das Modell als auch die Umgebung.
Die Ansätze der drei Unternehmen sind klar: Kimi verwendet PARL, um parallele Zerlegung und Kreditzuweisung zu lösen; Cursor verwendet Selbstzusammenfassung und Echtzeit-RL, um lange Codierungssitzungen und Produktionstraffic wieder mit dem Training zu verbinden; Chroma trainiert prune_chunks als Strategie selbst und lässt die Kontextbereinigung direkt in den Abrufprozess einfließen.
In der SFT-Ära war Datenvielfalt von größter Bedeutung; in der Agent-Ära ist die Umgebungsqualität der Kern: Stabilität, Authentizität, Abdeckung, Schwierigkeitsverteilung, Feedback-Reichtum und Anti-Exploitation. Die Trainingsziele ändern sich entsprechend; es geht um Zuverlässigkeit bei vollständigen Aufgaben, nicht nur darum, eine Frage richtig zu beantworten. Klassische CoT-Benchmarks können dies nicht abdecken.
Diese Veränderung schreitet weiter voran: Es geht nicht nur darum, das Modell innerhalb eines Laufzeit-Harness zu trainieren, sondern sogar der Harness-Code selbst wird zu einem Objekt, das von einer äußeren Schleife durchsucht und optimiert werden kann.
Kimi K2.5's PARL ist ein bemerkenswerter Engineering-Fall mit einer klaren Route: Nur den Orchestrator trainieren, die Kreditzuweisung auf die Orchestrierungsschicht konzentrieren und nicht alle Sub-Agents gleichzeitig optimieren.
Belohnungssignale werden in drei Kategorien unterteilt: Aufgabenerfolg, parallele Zerlegung und Abschlussbeschränkungen, die gemeinsam die Orchestrierungsschicht antreiben. Im frühen Training wird die r_parallel-Gewichtung erhöht, um die Erkundung paralleler Strategien zu fördern, und später schrittweise auf 0 reduziert, um zu vermeiden, dass das Öffnen mehrerer Sub-Agents als Abkürzung behandelt wird. Die Bewertung betrachtet nicht nur die Gesamtschritte, sondern auch die Länge des kritischen Pfades; ein kürzerer kritischer Pfad zeigt an, dass die Parallelität wirklich effektiv ist.
Aber bis 2026 haben sich die Dinge einen Schritt weiterentwickelt. Meta-Harness behandelt Harness-Engineering explizit als separates Optimierungsziel. Es optimiert nicht Gewichte, sondern den Harness-Code selbst – die Prompt-Konstruktion, Abruf-, Speicher- und Zustandsaktualisierungsprogramme, die ein festes Modell umgeben. Die Zahlen am Anfang des Papiers sind direkt: Für dasselbe Basismodell kann allein die Änderung des Harness zu einer 6-fachen Leistungslücke beim selben Benchmark führen. Diese Reihe von Programmen außerhalb des Modells ist nicht länger nur ein Deployment-Detail, sondern eine Schicht der Fähigkeitsbildung.
Der Schlüssel liegt nicht darin, einen weiteren abstrakten Optimierer hinzuzufügen, sondern darin, vorherigen Code, Scores und Ausführungs-Traces (Protokolle von Tool-Aufrufen und Zustandsänderungen) in das Dateisystem zu schreiben, einem Vorschlagenden zu erlauben, wie beim Schreiben von Code zu greppen, catten und diffen, und dann den Harness entlang von Fehlerpfaden zu modifizieren. Der Vorschlagende ist das Modul, das Harness-Modifikationen vorschlägt.
Die Autoren urteilen klar, dass viele frühere Text-Optimierer für langfristige, zustandsbehaftete Programme wie Harness nicht effektiv waren, weil das Betrachten nur skalarer Scores, kurzer Vorlagen oder Zusammenfassungen das Problem vereinfacht. Skalare Scores liefern nur Endpunkte ohne Prozessinformationen. Harness-Fehler manifestieren sich oft viele Schritte später; sobald das Feedback überkomprimiert ist, reißt die Diagnosekette ab.
Diese Ergebnisse sind mehr als nur höhere Benchmark-Scores. Bei der Online-Textklassifikation ist Meta-Harness 7,7 Punkte höher als ACE (Agent Context Engineering Baseline), während die Nutzung von Kontext-Token auf 1/4 komprimiert wird. Bei retrievalgestütztem mathematischem Reasoning verbesserte ein entdeckter Harness 5 zurückgehaltene Modelle (nicht an der Optimierung beteiligt) um durchschnittlich 4,7 Punkte bei 200 Problemen auf IMO-Niveau. Auf TerminalBench-2 übertraf es auch manuelle Engineering-Baselines. Dies zeigt, dass nicht länger nur interne Modellstrategien optimiert werden, sondern auch die Programme, die Informationen und Aktionen um das Modell herum organisieren.
Ein konkretes Beispiel: Meta-Harness entdeckte automatisch Environment Bootstrap auf TerminalBench-2 – das Ausführen eines Shell-Befehls vor dem Start der Agent-Schleife, um das Arbeitsverzeichnis, verfügbare Sprachen, Paketmanager und den Speicherzustand in einen Snapshot zu organisieren, der in den ersten Prompt injiziert wird. Viele Coding-Agents verbringen die ersten Runden damit, die Umgebung zu erkunden; mit dieser Vorverarbeitung kommt die Verbesserung nicht unbedingt von stärkeren Gewichten, sondern vom Harness, der dem Modell erlaubt, mit einem besseren Kontext zu starten.
An diesem Punkt hat sich das Optimierungsziel von Antworten auf Trajektorien und dann auf das Harness-Programm, das diese Trajektorien trägt, ausgeweitet.
Nach der Veröffentlichung eines führenden Modells läuft die Trainingskette weiter
Das Verständnis heutiger großer Modelle allein durch die Linse einer einzigen Runde von Pre-Training reicht nicht mehr aus. Hinter einem veröffentlichten Modell ist die gesamte Kette von Pre-Training, Post-Training, Destillation und Spezialisierung in der Regel abgeschlossen, und stärkere Modelle produzieren weiterhin Trainingsdaten für die nächste Generation.
Die Destillation der DeepSeek-R1-Serie ist ein typisches Beispiel. Ein großes Modell entwickelt zunächst Reasoning-Fähigkeiten durch RL und verifizierte Belohnungen und überträgt dann diese Reasoning-Trajektorien auf kleinere dichte Modelle. Spezialisierte Modelle wie TranslateGemma zeigen einen anderen Weg: Bei spezifischeren Zielaufgaben werden hochwertige Daten und spezialisierte Belohnungsdesigns verwendet, um Fähigkeiten weiter zu komprimieren und zu lenken. In diesem Stadium dienen stärkere Modelle nicht nur der Bedienung von Benutzern, sondern auch der direkten Produktion von Trainingsdaten für die nächste Generation.
Der Grund dafür ist grundlegender als die Trajektorienübertragung: Eine mögliche Erklärung ist, dass in Internet-Korpora Wissensspeicherung und Reasoning-Fähigkeit gekoppelt sind und bestehende Pre-Training-Ziele von Modellen verlangen, beides gut zu lernen. Große Modelle müssen zuerst kommen, weil nur sie groß genug sind, um beides zu unterstützen, und dann können sie verwendet werden, um reine Reasoning-Demonstrationsdaten zu generieren. Wenn kleine Modelle auf solchen Daten trainieren, können sie sich auf das Reasoning selbst konzentrieren, ohne gezwungen zu sein, alles Wissen zu speichern. Groß anfangen und dann klein werden, dient der Fähigkeitsentkopplung, nicht nur einer Kostenstrategie.
Andererseits ist die Deployment-Anpassungsfähigkeit ebenso wichtig wie die Fähigkeit selbst. Viele Szenarien benötigen kein Allzweck-Großmodell; sie legen mehr Wert auf Kosten, Latenz, Stabilität und Kontrollierbarkeit. Das Ende des Trainings ist nicht unbedingt größer, sondern potenziell kleiner, billiger und spezialisierter.
Das endgültig veröffentlichte Modell ist nicht unbedingt der Checkpoint ganz rechts auf der Trainingskurve. Vor der tatsächlichen Veröffentlichung werden oft mehrere Checkpoints wiederholt auf reale Aufgabenergebnisse, Verweigerungsstile, Tool-Stabilität, Kosten und Regressionsrisiken verglichen. Die Version, die online geht, ist oft eine Produktentscheidung, nicht diejenige, die bei einer einzelnen Metrik am stärksten abschneidet.
Wenn Benutzer einen Modellnamen sehen, nehmen sie an, dass er einer gleichmäßig ansteigenden Trainingskurve entspricht, aber welcher Checkpoint tatsächlich online gestellt wird, ist eine andere Sache.
Der Wert eines großen Modells liegt sowohl in seiner eigenen Dienstfähigkeit als auch in seiner fortgesetzten Bereitstellung von Trainingsdaten, Destillationsquellen und Veröffentlichungsgrundlagen für die nächste Generation.
Über das Offline-Training hinaus ist die nahezu Online-kontinuierliche Optimierung in den Hauptprozess eingetreten. Das Echtzeit-RL von Cursor Composer 2 zeigt, dass einige Agent-Fähigkeiten begonnen haben, sich kontinuierlich durch Produktionstraffic zu iterieren, anstatt auf die nächste Runde groß angelegten Offline-Trainings zu warten. Die Grenze zwischen Training und Deployment ist nicht verschwunden, aber die Rückkopplungsschleife zwischen ihnen verkürzt sich.
Wie man in Zukunft beurteilt, warum ein Modell stärker geworden ist
Der Wert führender Modelle im Jahr 2026 hängt zunehmend davon ab, wer die gesamte Trainingskette nach dem Pre-Training abschließen kann: kontinuierlich Trainingsdaten produzieren, destillieren, spezialisieren, Evaluierung und Belohnungen gut durchführen und endgültige Veröffentlichungsentscheidungen treffen.
Aus diesem Grund können Sie, wenn Sie sehen, warum ein Modell plötzlich stärker wird, zuerst auf drei Dinge achten:
- Erstens: Sehen Sie, ob die Veränderung auf der Pre-Training-Ebene oder im nachfolgenden Trainingsprozess stattgefunden hat. Viele Fähigkeitsverbesserungen kommen tatsächlich von stärkerem Pre-Training und besseren Daten-Rezepten, aber viele wahrgenommene Veränderungen stammen tatsächlich aus dem Post-Training. Ob ein Modell Anweisungen befolgt, Tools verwendet oder einen stabilen Antwortstil hat, wächst oft nicht natürlich allein durch das Training mit mehr Korpora.
- Zweitens: Sehen Sie, von welcher Schicht die Verbesserung kommt: Sind es Gewichte und Trainingsrezepte, oder Belohnung/Evaluierung/Bewerter, oder Harness-Code und Deployment-Schleife. Wenn wir Reasoning-Modelle und Agents erreichen, ist die Stärke, die Benutzer spüren, oft nicht das Ergebnis des Basismodells allein. Wie Evaluierungen eingerichtet sind, wie Belohnungen bewertet werden, ob die Tool-Umgebung stabil ist, wie Abruf und Speicher organisiert sind, wie Zusammenfassungen und Kontext beschnitten werden und welcher Checkpoint für die Veröffentlichung ausgewählt wurde – all dies verändert gemeinsam die endgültige Produktleistung.
- Schließlich: Sehen Sie, was die Online-Version optimiert. Einige Versionen streben nach einer höheren Obergrenze, einige nach niedrigeren Kosten, Latenz und Regressionsrisiko, und einige sind auf eine bestimmte Art von Szenario spezialisiert. Die Veröffentlichungsversion ist eine Produktentscheidung, nicht der Punkt ganz rechts auf der Trainingskurve. Wenn Sie sich also Modell-Updates ansehen, wird das Betrachten dessen, was es tatsächlich optimiert, der Wahrheit näher kommen.
Wenn man die plötzliche Verbesserung eines Modells in Produktionsstufen zerlegt, werden viele Gewinne tatsächlich durch die zweite Hälfte des Trainingsstacks und den äußeren Harness verstärkt. Der Iterationszyklus dieser Kette verkürzt sich ebenfalls: Produktionstraffic fließt kontinuierlich zurück ins Training, jede Generation stärkerer Modelle produziert Überwachungsdaten der nächsten Generation, während sie Fähigkeiten produziert, und äußere Programme werden ständig basierend auf Rollouts, Logs und echtem Aufgaben-Feedback umgeschrieben.
Das heute veröffentlichte Modell ist nur ein Schnappschuss; die Pipeline und das Harness-Programm sind die Produkte, die weiterlaufen.
Lernmaterialien
- Hoffmann et al. (2022). Training Compute-Optimal Large Language Models (Chinchilla). arXiv:2203.15556
- Ouyang et al. (2022). Training language models to follow instructions with human feedback (InstructGPT). arXiv:2203.02155
- Shao et al. (2024). DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models (GRPO). arXiv:2402.03300
- DeepSeek-AI (2025). DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948
- DeepSeek-AI (2024). DeepSeek-V3 Technical Report. arXiv:2412.19437
- Llama Team, AI @ Meta (2024). The Llama 3 Herd of Models. arXiv:2407.21783
- Bai et al. (2022). Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.08073
- OpenAI (2024). Deliberative Alignment: Reasoning Enables Safer Language Models. openai.com/index/deliberative-alignment
- Anthropic (2025). Sycophancy to Subterfuge: Investigating Reward Tampering in Language Models. anthropic.com/research/reward-tampering
- MacDiarmid et al. (2025). Natural Emergent Misalignment from Reward Hacking in Production RL. arXiv:2511.18397
- Lee et al. (2026). Meta-Harness: End-to-End Optimization of Model Harnesses (Preprint-Projektseite). yoonholee.com/meta-harness
- Kimi Team (2026). Kimi K2.5 Tech Blog: Visual Agentic Intelligence. kimi.com/blog/kimi-k2-5
- Rush, S. (2026). A technical report on Composer 2. cursor.com/blog/composer-2-technical-report
- Chroma (2026). Chroma Context-1: Training a Self-Editing Search Agent. trychroma.com/research/context-1
Dieser Artikel autorisiert keine Form der Vervielfältigung oder Umschreibung zur Wiederveröffentlichung. Wenn Sie eine finden, melden Sie sie bitte.
