Der Decoder ist nur ein Teil des Systems
Ein leistungsfähiges Assistenzsystem verbindet Modellgewichte mit Datenauswahl, Posttraining, Bewertung, Inferenzengine, Werkzeugzugriff und Produktlogik. Unser Lehrprojekt implementiert den inneren Sprachmodellweg. Es implementiert keine Recherchemaschine, keine dauerhaft zuverlässige Faktenprüfung und keinen vollständigen Produktionsdienst.
Diese Grenze ist nicht peinlich: Sie hilft, Ursachen richtig zuzuordnen. Wenn ein System eine aktuelle Webseite lesen kann, muss diese Information nicht in seinen Gewichten gespeichert sein. Wenn es einen Rechner benutzt, ist eine korrekte Multiplikation nicht zwingend nur eine intern gelernte Antwort.
Mixture of Experts
MoE ersetzt typischerweise bestimmte dichte Feed-Forward-Schichten durch mehrere Expertennetze plus einen Router. Der Router wählt pro Token eine kleine Teilmenge von Experten. Dadurch können viele Parameter vorhanden sein, während pro Token nur ein Teil aktiviert wird.
Gesamtparameter beschreiben unter anderem den Speicher für alle Expertgewichte. Aktive Parameter sind näher am tatsächlich benutzten Rechenweg pro Token, aber ebenfalls keine vollständige Kostenbeschreibung: Routing, Attention und Kommunikation kommen hinzu. Ein MoE-Modell mit vielen Gesamtparametern muss weiterhin alle benötigten Gewichte irgendwo verfügbar halten.
MoE ist inzwischen in vielen großen offenen Modellen Standard, etwa Mixtral (8 Experten, 2 aktiv pro Token, rund 47 Mrd. Gesamt- und 13 Mrd. aktive Parameter) oder DeepSeek-V3 (671 Mrd. gesamt, 37 Mrd. aktiv pro Token, mit vielen kleinen und geteilten Experten). Für unseren Kurs ist die allgemeine Router/Experten-Idee wichtig, nicht eine behauptete aktuelle Rangfolge aller Modelle. Mixtral of Experts.
Warum MoE nicht dein erster Schritt sein sollte
Ein Router kann bestimmte Experten übernutzen oder kaum benutzen. Lastverteilung, Kapazitätsgrenzen, zusätzliche Zielfunktionen und verteilte Kommunikation machen das Training komplexer. Bei einem kleinen lokalen Lernmodell kann ein dichter Decoder verständlicher und sogar praktischer sein.
Wenn du später ein Mini-MoE baust, prüfe zuerst, wie viele Tokens jeder Experte erhält und ob alle trainieren. Ein fallender Gesamt-Loss allein zeigt nicht, dass der Router gesund arbeitet. Eine didaktische Erweiterung kann mit zwei bis vier kleinen Experten beginnen.
Lange Kontexte und Sparse Attention
Eine höhere konfigurierte Länge reicht nicht. Das Modell muss lernen, relevante Informationen über solche Abstände zu nutzen. Dichte Attention wird rechnerisch teuer; sparse Verfahren lassen bestimmte Verbindungen weg, etwa lokale Fenster oder ausgewählte globale Positionen. Das kann Kosten reduzieren und verändert den Informationsweg.
FlashAttention und Sparse Attention sind daher nicht dasselbe. Auch ein großes Kontextfenster ist kein Nachweis, dass das Modell an jedem Abstand zuverlässig eine relevante Tatsache findet. Evaluiere lange Kontexte mit kontrollierten Positionen, Ablenkungen und Aufgaben, die die Information tatsächlich benötigen.
Multimodalität
Ein multimodales Modell braucht einen Weg von Bildern, Audio oder Video zu internen Repräsentationen. Das kann über separate Encoder und Projektionsmodule geschehen oder über andere tokenartige Repräsentationen. Ein Textdecoder wird nicht allein dadurch visuell, dass du einem Token „Bild“ nennst.
Du brauchst passende Daten, ein Lernziel und eine Schnittstelle zwischen Modalitäten. Für deinen ersten vollständig eigenen Textdecoder lohnt es sich, diese Erweiterung bewusst später anzugehen.
Präferenztraining
SFT trainiert auf gewünschten Antworten. Präferenzdaten enthalten häufig dieselbe Eingabe mit einer bevorzugten und einer weniger bevorzugten Antwort. Das Ziel ist, die bevorzugte Ausgabe relativ wahrscheinlicher zu machen. Dabei bleibt das Modell über einen Strafterm (Parameter β) in der Nähe eines eingefrorenen Referenzmodells, meist des SFT-Checkpoints.
DPO ist ein Verfahren, das eine direkte Zielfunktion auf solchen Paaren verwendet, statt einen vollständigen klassischen RLHF-Ablauf mit separat trainiertem Reward-Modell und PPO-Schritten zu benötigen. Es beseitigt aber nicht die Frage, ob die Präferenzdaten sachlich gut und zum Ziel passend sind. Direct Preference Optimization.
RL mit prüfbaren Belohnungen
Für manche Aufgaben gibt es automatisch prüfbare Ergebnisse, etwa bestandene Programmtests oder korrekte Zahlen. Ein RL-Verfahren kann Antworten erzeugen, ihren Reward bewerten und die Policy anpassen. Entscheidend ist, dass der Reward das tatsächliche Ziel misst. Ein fehlerhafter Prüfer kann das Modell auf Umgehungen statt auf Lösungen trainieren.
Seit 2024/25 trainieren führende Systeme mit solchen prüfbaren Belohnungen sogenannte Reasoning-Modelle: Das Modell erzeugt vor der Antwort eine lange Zwischenrechnung (Chain of Thought). Mehr Rechenaufwand bei der Inferenz – längeres „Nachdenken“ – kann die Trefferquote bei Mathematik- und Programmieraufgaben deutlich erhöhen; man spricht von Test-Time-Compute. Ein verbreitetes Verfahren ist GRPO, das statt eines separaten Wertmodells mehrere Antworten auf dieselbe Frage miteinander vergleicht. Ein bekanntes offenes Beispiel ist DeepSeek-R1. Auch hier gilt: Die Zwischenrechnung ist erzeugter Text, kein garantierter Einblick in die interne Berechnung.
Ein Reward ist nicht einfach ein weiterer Textkorpus. Sampling, Varianz, Kreditzuweisung und Regularisierung machen die Optimierung anders als gewöhnliches SFT. Baue zuerst eine gute Evaluation, bevor du mit komplexem RL experimentierst.
Werkzeuge und Retrieval
Retrieval holt relevante externe Textstücke in den Kontext. Ein Werkzeugaufruf kann rechnen oder eine Datenbank abfragen. Das Modell muss diese Fähigkeiten passend auswählen und die Ergebnisse korrekt benutzen. Das Gesamtsystem kann dadurch leistungsfähiger sein, ohne dass der Decoder allein alle Aufgaben beherrscht.
Für dein eigenes Modell ist ein früher sinnloser Werkzeugaufruf kein Fortschritt. Prüfe Eingabeformat, Ergebnisformat und Fehlerfälle. Systemevaluation umfasst auch, ob Werkzeuge zum richtigen Zeitpunkt verwendet werden.
Was „modern“ wirklich verlangt
Es gibt keinen universellen Architektur-Checkzettel. Gute Systeme wählen Bausteine passend zu Daten, Budget und Einsatz und belegen ihre Wirkung. Dein nächster Schritt sollte deshalb eine präzise Frage sein: „Kann ein Mini-MoE bei gleichem aktivem Rechenbudget meinen Validierungs-Loss verbessern?“ ist untersuchbar. „Ich füge alles Moderne hinzu“ ist kein Experiment.