Skip to content
Tech42 Software Solutions GmbH

Innenansicht eines modernen KI-Systems: Datenebene und Modellarchitektur

Tokens, Embeddings, Attention Heads, BPE — das Vokabular moderner KI ist dicht. Ein Rundgang durch die zwei Ebenen, auf denen die wichtigsten Designentscheidungen fallen: wie aus Rohinformationen Trainingsdaten werden und wie ein Transformer darunter tatsächlich aufgebaut ist.

Jan Raddatz · 18 Min. Lesezeit · KI / LLM / Architektur
Joey, das Tech42-Maskottchen, mit einem AI-Schaltkreis-Symbol über dem Kopf

Wer einen technischen Hintergrund hat, aber noch nicht in der KI gearbeitet hat, dem kommt das Feld oft wie eine Wand aus Fachbegriffen vor. Tokens, Embeddings, Attention Heads, BPE, Layer Norm, Residual Stream — das Vokabular ist dicht, und die meisten Erklärungen kratzen entweder nur an der Oberfläche oder stürzen sich direkt in lineare Algebra, ohne jemals zu erklären, warum das alles so aussieht, wie es aussieht.

Dieser Artikel führt durch die beiden grundlegenden Ebenen eines modernen KI-Systems: die Datenebene (wie aus Rohinformationen etwas wird, aus dem ein Modell lernen kann) und die Modellarchitektur (die eigentliche Struktur des neuronalen Netzes). Das sind die beiden Ebenen, auf denen die wichtigsten Designentscheidungen fallen. Alles, was darauf aufbaut — Trainingsinfrastruktur, Fine-Tuning, Inferenz, Anwendungen — steht in gewissem Sinne im Dienst dieser zwei Ebenen.

Der Fokus liegt durchgehend auf Large Language Models (LLMs), weil dort das aktuelle KI-Momentum liegt, aber die meisten Konzepte lassen sich direkt auf Vision-, Audio- und multimodale Systeme übertragen.

Teil 1: Die Datenebene

Warum Daten die eigentliche Front sind

Bevor es um die Mechanik geht, hilft eine kontraintuitive Tatsache über moderne KI: Die Modellarchitektur ist im Wesentlichen ein gelöstes Problem. Der Transformer, den wir in Teil 2 behandeln, ist seit 2017 das dominante Design. Die architektonischen Änderungen seitdem sind real, aber inkrementell. Was sich dramatisch verändert hat, ist die Skala und Qualität der Trainingsdaten.

Es gibt einen empirisch gut belegten Zusammenhang, die sogenannten Scaling Laws (am bekanntesten dokumentiert von OpenAI 2020 und verfeinert durch das “Chinchilla”-Paper von DeepMind 2022), der zeigt, dass die Modellqualität vorhersagbar mit drei Faktoren steigt: mehr Parameter, mehr Rechenleistung und mehr Daten. Das Chinchilla-Ergebnis argumentierte insbesondere, dass die meisten großen Modelle jener Zeit untertrainiert waren — sie hatten zwar viele Parameter, aber nicht genug Token zum Lernen. Die praktische Konsequenz: Daten sind zum Engpass geworden. Frontier Labs trainieren heute auf Billionen von Token, und diese Menge in hoher Qualität zu beschaffen, ist ein ernsthaftes Engineering- und Forschungsproblem.

Alles in der Datenebene existiert, um genau dieses Problem zu lösen.

Erfassung: Woher die Token kommen

Die erste Aufgabe ist das Sammeln von Quellmaterial. Für ein allgemeines Sprachmodell sind das typischerweise:

  • Web Crawls. Die größte öffentliche Quelle ist Common Crawl, die das Web seit 2008 archiviert und Petabyte an Roh-HTML produziert. Die meisten LLMs werden auf stark gefilterten Teilmengen davon trainiert.
  • Bücher. Sowohl gemeinfreie (Project Gutenberg) als auch lizenzierte Korpora. Bücher liefern lange, kohärente Prosa, die das Web größtenteils nicht hat.
  • Code. GitHub und andere öffentliche Repositories. Code hat sich als ungewöhnlich wertvoll erwiesen, unter anderem weil er die logische Schlussfolgerungsfähigkeit auch bei Nicht-Code-Aufgaben verbessert.
  • Referenzmaterial. Wikipedia, wissenschaftliche Paper (arXiv, PubMed), juristische Dokumente, Behördentexte.
  • Foren und Konversationsdaten. Reddit, Stack Exchange, Q&A-Seiten. Sie geben dem Modell Exposition gegenüber Dialog und Erklärung.
  • Mehrsprachige Quellen. Webseiten, Nachrichten und Referenzwerke in Dutzenden bis Hunderten von Sprachen.

Wenn Sie ein domänenspezifisches Modell bauen — etwa einen medizinischen Assistenten oder ein Coding-Tool für ein bestimmtes Framework — bedeutet Erfassung etwas anderes. Sie ziehen interne Dokumente, Support-Tickets, Handbücher, Ticket-Historien, Wissensdatenbanken und möglicherweise proprietäre Datensätze, die Sie lizenziert haben.

Zwei Themen dominieren die Erfassung in der Praxis. Das erste ist Recht und Lizenzierung — die Frage, worauf man trainieren darf, ist in vielen Jurisdiktionen ungeklärt und wird gerade gerichtlich verhandelt. Das zweite ist Qualität im Maßstab. Sie können nicht manuell Billionen von Token sichten, also passiert die meiste Arbeit auf der nächsten Stufe.

Bereinigung: Aus Schlamm Signal machen

Rohe Webdaten sind tatsächlich grauenhaft. Eine zufällige HTML-Seite im Internet enthält Navigationsmenüs, Cookie-Banner, Werbung, Scripts, Copyright-Footer, kaputte Zeichenkodierungen, maschinell übersetzten Spam, SEO-Stichwortbrei und gelegentlich den eigentlichen Inhalt, den Sie wollten. Würden Sie direkt darauf trainieren, würde Ihr Modell lernen, Navigationsmenüs zu produzieren.

Die Bereinigung ist die Pipeline, die das ausdünnt. Die Standardschritte:

HTML- und Boilerplate-Entfernung. Tools extrahieren den Hauptinhaltsbereich einer Seite und verwerfen alles andere. Das klingt einfach, ist aber im Maßstab überraschend schwer — jede Website ist anders strukturiert.

Encoding-Normalisierung. Text im Web verwendet Dutzende Zeichenkodierungen; alles wird auf UTF-8 normalisiert, kaputter oder mojibake’d Text wird verworfen.

Spracherkennung. Jedes Dokument wird nach Sprache klassifiziert, damit Sie den Mix ausbalancieren und verschiedene Sprachen unterschiedlich verarbeiten können.

Qualitätsfilterung. Hier wird es interessant. Sie können nicht manuell Milliarden von Dokumenten prüfen, also trainieren Labs Klassifikatoren, die bewerten, ob ein Dokument “wie hochwertiger Text aussieht” — also Prosa mit korrekter Grammatik, faktischem Inhalt, kohärenter Struktur. Eine gängige Technik ist, einen Klassifikator auf einer positiven Menge (Wikipedia, Bücher, kuratierte Referenzen) gegen eine Zufallsstichprobe des Webs zu trainieren und damit alles andere zu bewerten. Dokumente unter einem Schwellwert fallen raus.

Heuristische Filter. Eine lange Liste von Regeln: Dokumente kürzer als N Wörter verwerfen, Dokumente mit zu vielen Sonderzeichen verwerfen, Dokumente mit wiederholten Zeilen verwerfen, Dokumente, in denen mehr als X% der Wörter nicht im Wörterbuch stehen, verwerfen. Das wirkt grob, entfernt aber riesige Mengen Müll sehr günstig.

PII- und Sicherheitsfilterung. Personenbezogene Daten (Telefonnummern, Adressen, Sozialversicherungsnummern) werden geschwärzt oder durch Platzhalter ersetzt. Bekannte Quellen toxischer Inhalte werden geblockt. CSAM-Erkennung läuft über alle Bilddaten.

Dekontamination. Ein subtiler Punkt: Sie müssen sicherstellen, dass Ihre Trainingsdaten nicht die Testsets enthalten, auf denen Sie später evaluieren. Wenn eine Benchmark-Frage und ihre Antwort irgendwo in Ihrem Trainingskorpus liegen, sind Ihre Evaluationsergebnisse bedeutungslos. Dekontamination sucht nach Überschneidungen zwischen Trainingsdaten und bekannten Evaluations-Benchmarks und entfernt Treffer.

Das Ergebnis der Bereinigung ist ein deutlich kleineres, aber deutlich höherwertiges Korpus. Ein typischer Web Crawl schrumpft durch diese Pipeline um 90–99 %.

Deduplizierung: Warum derselbe Satz zweimal schlechter ist als einmal

Duplikate sind das größte versteckte Problem in Trainingsdaten. Das Internet wiederholt sich — derselbe Nachrichtenartikel wird auf hundert Seiten syndiziert, dieselbe Stack-Overflow-Antwort wird gespiegelt, derselbe juristische Boilerplate-Text taucht auf Millionen Seiten auf. Trainieren Sie roh darauf, verbraucht das Modell unverhältnismäßig viel Kapazität darauf, den wiederholten Inhalt zu memorieren, statt daraus zu generalisieren.

Deduplizierung passiert auf mehreren Ebenen:

  • Exakte Dokumentduplizierung — identische Dokumente werden auf eine Kopie reduziert.
  • Near-Duplicate Detection — Dokumente, die den Großteil ihres Inhalts teilen (eins ist eine leichte Bearbeitung des anderen), werden identifiziert, meist mit Techniken wie MinHash oder SimHash, die Signaturen erzeugen, die sich günstig vergleichen lassen.
  • Substring-Deduplizierung — selbst innerhalb ansonsten verschiedener Dokumente finden sich lange wiederholte Passagen (ein Absatz, der in tausenden Dokumenten auftaucht); die Duplikate werden entfernt.

Forschung zeigt durchgängig, dass aggressive Deduplizierung die Modellqualität verbessert, das Memorieren bestimmter Passagen reduziert und manchmal erlaubt, mit weniger Daten denselben Effekt zu erzielen. Es ist einer der Schritte mit dem höchsten Hebel in der gesamten Pipeline.

Tokenisierung: Text in Zahlen verwandeln

Neuronale Netze arbeiten mit Zahlen, nicht mit Text. Tokenisierung ist die Brücke: Sie wandelt eine Zeichenkette in eine Folge von Integer-IDs um, die das Modell verarbeiten kann.

Die naiven Ansätze funktionieren nicht gut. Zeichenweise Tokenisierung (ein Token pro Zeichen) produziert zu lange Sequenzen und zwingt das Modell, jedes Mal neu zu lernen, dass “d-e-r” ein Wort ist. Wortweise Tokenisierung (ein Token pro Wort) erzeugt ein riesiges Vokabular (Millionen Wörter über Sprachen und Domänen hinweg) und scheitert an Rechtschreibfehlern, seltenen Wörtern und morphologisch reichen Sprachen.

Die dominante Lösung ist Subword-Tokenisierung, und der gängigste Algorithmus ist Byte-Pair Encoding (BPE). Die Idee:

  1. Mit einem Basisvokabular aus einzelnen Bytes oder Zeichen starten.
  2. In einem großen Trainingskorpus das häufigste Paar benachbarter Token finden.
  3. Dieses Paar zu einem neuen Token zusammenfassen, ins Vokabular aufnehmen.
  4. Wiederholen, bis ein Vokabular der gewünschten Größe entstanden ist (typisch 30.000 bis 200.000 Token).

Das Ergebnis ist ein Vokabular, in dem häufige Wörter (“der”, “und”, “Tokenisierung”) zu einzelnen Token werden, weniger häufige Wörter in bedeutungsvolle Teile aufgespalten werden (“Donaudampfschifffahrtsgesellschaftskapitän” wird zu mehreren Token), und das System kann immer auf einzelne Zeichen oder Bytes zurückfallen für alles, was es noch nie gesehen hat.

Zum Beispiel könnte das Wort “Tokenisierung” als ["Token", "isierung"][1923, 4421] tokenisiert werden. Das Wort “tokenisieren” könnte zu ["token", "isieren"][1923, 8821] werden. Das Modell sieht, dass diese beiden Wörter denselben token-Stamm teilen, und kann lernen, dass sie verwandt sind.

Entscheidungen bei der Tokenisierung haben überraschend große Folgekonsequenzen:

  • Vokabulargröße beeinflusst die Modellgröße (die Embedding- und Output-Layer skalieren damit) und die Sequenzlänge (ein größeres Vokabular bedeutet weniger Token pro Wort, also längere effektive Kontexte).
  • Sprachabdeckung hängt davon ab, worauf der Tokenisierer trainiert wurde. Ein primär auf Englisch trainierter Tokenisierer repräsentiert Englisch effizient (ein typisches Wort ist ein oder zwei Token), zerstückelt aber Sprachen wie Thai oder Tamil womöglich in viele Token pro Wort, was sie teurer in der Verarbeitung und schwerer lernbar macht.
  • Code und Mathematik sind tokenisierungssensitiv. Ob ” ” (ein Leerzeichen) und ” ” (zwei Leerzeichen) eigene Token sind, wie Zahlen aufgespalten werden, ob gängige Code-Patterns einzelne Token sind — all das beeinflusst, wie gut das Modell mit diesen Domänen umgeht.
  • Spezielle Token werden hinzugefügt für Dokumentanfang, Dokumentende, Padding und (bei instruktionsgetunten Modellen) System/User/Assistant-Rollenmarkierungen.

Sobald Sie einen Tokenisierer haben, lassen Sie Ihr gesamtes bereinigtes, dedupliziertes Korpus hindurchlaufen. Das Ergebnis ist eine riesige flache Folge von Token-IDs, oft als memory-mapped Binärdateien für effizientes Training abgelegt.

Datenpipeline: rohe Web Crawls werden bereinigt, dedupliziert und in eine Token-Sequenz verwandelt — pro Stufe schrumpft das Volumen um etwa eine Größenordnung.

Daten-Mix und Curriculum

Ein letztes Konzept lohnt sich: Man trainiert selten auf einer einzelnen homogenen Datenquelle. Stattdessen mischt man sorgfältig verschiedene Quellen in unterschiedlichen Verhältnissen — etwa 60 % hochwertiges Web, 15 % Code, 10 % Bücher, 8 % Referenzmaterial, 7 % mehrsprachig. Die genauen Verhältnisse werden experimentell justiert und beeinflussen dramatisch, worin das Modell gut wird. Zu wenig Code, und das Reasoning leidet; zu viel Code, und die Prosa wird hölzern.

Manche Trainings-Setups nutzen auch ein Curriculum: Dem Modell werden früh im Training einfachere oder allgemeinere Daten gezeigt, gegen Ende dann höherwertige oder spezialisiertere. Das ist ein aktives Forschungsfeld mit gemischten Befunden, aber die Grundintuition — dass Reihenfolge und Mischung der Daten wichtig sind, nicht nur die Gesamtmenge — ist gut etabliert.

Teil 2: Die Modellarchitektur

Von RNNs zum Transformer — kurz

Um zu verstehen, warum moderne KI-Architekturen so aussehen, wie sie aussehen, hilft ein Blick auf das, was sie abgelöst haben. Für den Großteil der 2010er-Jahre war die dominante Architektur für Sprache das Recurrent Neural Network (RNN), insbesondere Varianten wie LSTM und GRU. RNNs verarbeiten Text Token für Token und führen dabei einen versteckten Zustand mit, der bei jedem Schritt aktualisiert wird. Das machte intuitiv Sinn — Sprache ist sequenziell, also verarbeite sie sequenziell — hatte aber zwei fatale Probleme. Training war prinzipiell seriell (Sie können Token 100 nicht verarbeiten, bevor Sie Token 99 verarbeitet haben), und der versteckte Zustand transportierte Informationen schlecht über große Distanzen.

2017 stellte ein Google-Paper namens Attention Is All You Need den Transformer vor, eine Architektur, die alle Token parallel verarbeitet und einen Mechanismus namens Self-Attention nutzt, um jedem Token direkten Zugriff auf jeden anderen Token zu geben. Sie war schneller trainierbar, skalierte besser und behandelte Langstreckenbezüge weit effektiver. Innerhalb weniger Jahre hatte sie im Wesentlichen das gesamte Sprachmodellieren übernommen, kurz darauf auch Vision, Audio und die meisten anderen Modalitäten.

Jedes moderne LLM, von dem Sie gehört haben — GPT, Claude, Gemini, Llama, Mistral, DeepSeek, Qwen — ist ein Transformer. Die Variationen sind real, laufen aber meist auf Feintuning desselben Grunddesigns hinaus.

Das große Bild

Ein transformerbasiertes Sprachmodell nimmt eine Folge von Token-IDs als Eingabe und erzeugt für jede Position eine Wahrscheinlichkeitsverteilung darüber, was das nächste Token sein sollte. Beim Training geben Sie ihm echten Text und bringen ihm bei, an jeder Position gleichzeitig das nächste Token vorherzusagen. Bei der Inferenz (Generierung) ziehen Sie ein Token aus der Verteilung, hängen es an die Sequenz an und lassen das Modell erneut laufen, um das nächste zu bekommen.

Das Modell ist ein Stapel identischer Blöcke (typisch 24, 32, 80 oder mehr) mit Embeddings auf der Eingabeseite und einem Output Head auf der Ausgabeseite. Daten fließen wie durch eine Pipeline hindurch, wobei jeder Block die Repräsentation der Sequenz weiter verfeinert.

Aufbau eines Transformer-Blocks: Pre-Norm, Multi-Head Self-Attention, Residual, Pre-Norm, Feedforward-Netz, Residual — gestapelt zu einem tiefen Modell.

Gehen wir die Komponenten durch.

Embeddings: Von Token-IDs zu Vektoren

Das Erste, was das Modell tut, ist Token-IDs in Vektoren umzuwandeln — Zahlenlisten, typisch 2048, 4096, 8192 oder mehr Dimensionen breit, je nach Modell. Das passiert über eine Lookup-Tabelle, die Embedding-Matrix: Zeile 1923 der Matrix ist der Vektor für Token 1923.

Diese Vektoren starten als Zufallszahlen und werden während des Trainings justiert. Mit der Zeit lernen sie, Bedeutung zu kodieren: Token, die in ähnlichen Kontexten auftreten, landen mit ähnlichen Vektoren. Berühmt ist, dass im entstehenden “Embedding-Raum” semantische Beziehungen oft als geometrische Beziehungen erscheinen — das klassische Beispiel ist, dass der Vektor für “König” minus “Mann” plus “Frau” in der Nähe von “Königin” landet. Moderne Embeddings sind reicher und komplexer, aber die Intuition stimmt.

Es gibt noch ein zweites Element: Positionsinformation. Self-Attention ist standardmäßig reihenfolgeblind — sie würde “Hund beißt Mann” und “Mann beißt Hund” identisch behandeln. Um das zu beheben, fügen Modelle den Embeddings Positionsinformationen hinzu. Frühe Transformer nutzten feste Sinusfunktionen; moderne nutzen typisch gelernte Positions-Embeddings oder, neuerdings, Rotary Position Embeddings (RoPE), die Position kodieren, indem sie Query- und Key-Vektoren in der Attention um einen Winkel proportional zur Position rotieren. RoPE hat sich durchgesetzt, weil es auf längere Sequenzen, als im Training gesehen, besser generalisiert.

Nach Embedding und Positionskodierung haben Sie eine Matrix der Form [Sequenzlänge × Hidden-Dimension] — ein Vektor pro Token, bereit für den Transformer-Stack.

Self-Attention: Der zentrale Mechanismus

Self-Attention ist das Herz des Transformers und der Teil, den zu verstehen sich am meisten lohnt.

Die Intuition: Für jeden Token in der Sequenz will das Modell herausfinden, welche anderen Token relevant sind. Im Satz “Die Katze saß auf der Matte, weil sie müde war” erfordert die Klärung, worauf “sie” sich bezieht, einen Blick auf die anderen Token und die Entscheidung, dass “Katze” relevanter ist als “Matte”. Self-Attention ist der Mechanismus, der das tut, und zwar für jeden Token gleichzeitig und auf eine Weise, die aus Daten gelernt wird.

Self-Attention visualisiert: Das Token 'sie' verteilt seine Aufmerksamkeit über die vorhergehenden Tokens — der höchste Anteil entfällt auf 'Katze'. Rechts daneben die Q/K/V-Mechanik und die Attention-Formel.

Mechanisch erzeugt das Modell für jeden Token drei Vektoren, indem es dessen Embedding mit drei gelernten Gewichtsmatrizen multipliziert:

  • Einen Query-Vektor — “wonach suche ich?”
  • Einen Key-Vektor — “was biete ich?”
  • Einen Value-Vektor — “welche Information trage ich?”

Um Attention für einen gegebenen Token zu berechnen, nehmen Sie dessen Query-Vektor und berechnen einen Ähnlichkeitswert (ein Skalarprodukt) mit dem Key-Vektor jedes Tokens in der Sequenz. Diese Werte werden skaliert und durch eine Softmax-Funktion geschickt, woraus eine Wahrscheinlichkeitsverteilung entsteht — die Attention Weights. Der Output für diesen Token ist dann eine gewichtete Summe aller Value-Vektoren in der Sequenz, mit diesen Attention Weights gewichtet.

In einem Satz: Jeder Token blickt auf jeden anderen Token, entscheidet über eine gelernte Ähnlichkeitsfunktion, wie viel jeder zählt, und zieht eine gewichtete Mischung ihrer Information heran.

Ein paar wichtige Details:

  • Causal Masking. Für ein Sprachmodell, das das nächste Token vorhersagt, dürfen Sie einem Token nicht erlauben, auf zukünftige Token zu schauen — das wäre Schummeln im Training. Also werden die Attention Weights für zukünftige Positionen auf null gezwungen. Das nennt man kausale oder autoregressive Attention.
  • Rechenkosten. Weil jeder Token auf jeden anderen Token achtet, sind die Kosten von Self-Attention quadratisch in der Sequenzlänge. Eine Verdopplung des Kontextfensters vervierfacht den Attention-Aufwand. Deshalb sind Long-Context-Modelle teuer und deshalb gibt es so viel Forschung zu effizienten Attention-Varianten (Sliding Window, Sparse, Linear Attention usw.).

Multi-Head Attention: Parallele Perspektiven

Eine einzelne Attention-Berechnung kann nur eine Art von Beziehung lernen. In der Praxis möchte man, dass das Modell viele Arten gleichzeitig verfolgt — grammatikalische Kongruenz, Koreferenz, thematische Ähnlichkeit, syntaktische Struktur und so weiter. Die Lösung ist Multi-Head Attention: Statt einer großen Attention-Berechnung laufen viele kleinere parallel (typisch 16, 32 oder 64 “Heads”), jeder mit eigenen gelernten Query-, Key- und Value-Projektionen, und die Ergebnisse werden konkateniert.

Forscher haben im Nachhinein festgestellt, dass sich verschiedene Heads in trainierten Modellen tatsächlich auf interpretierbare Weise spezialisieren — manche achten auf das vorherige Wort, manche tracken, welches Subjekt zu welchem Verb gehört, manche suchen nach passenden Klammern oder Anführungszeichen. Das war nicht so designt; es entstand durchs Training.

Das Feedforward-Netz: Wo das Wissen wohnt

Nach der Attention durchläuft jeder Token-Vektor ein Feedforward-Netz (FFN), auch MLP genannt. Eine deutlich einfachere Komponente: zwei lineare Schichten mit einer Nichtlinearität dazwischen, unabhängig auf jeden Token angewendet.

Das FFN ist strukturell weniger interessant als Attention, aber dort lebt der Großteil der Parameter des Modells — typisch zwei Drittel oder mehr der Gesamtzahl. Forschung in Mechanistic Interpretability legt nahe, dass hier der Großteil des faktischen Wissens und der gelernten Assoziationen gespeichert ist. Attention bewegt Information; das FFN verarbeitet sie.

Eine moderne Variante, die man kennen sollte, ist das Mixture of Experts (MoE) FFN, eingesetzt in Modellen wie Mixtral und DeepSeek. Statt eines großen FFN gibt es viele kleinere “Experten”-FFNs und einen Router, der jeden Token nur an ein, zwei davon schickt. So kann man die Gesamtparameterzahl gewaltig hochskalieren, während die Rechenkosten pro Token in etwa konstant bleiben — ein “großes” Modell, das pro einzelnem Token “klein” bei der Inferenz ist.

Layer Norm und Residual Connections: Das Ganze trainierbar machen

Zwei Stücke Klempnerei machen, dass das Ganze in der Praxis funktioniert.

Residual Connections (oder “Skip Connections”) addieren den Input jeder Sub-Schicht wieder auf deren Output. Statt output = attention(input) ist es also output = input + attention(input). Das bedeutet, Information kann um jeden Block herumfließen, und Gradienten beim Training können sauber durch sehr tiefe Netze rückwärts propagiert werden. Ohne Residuals trainieren Netze, die tiefer als etwa ein Dutzend Schichten sind, schlecht; mit ihnen lässt sich auf Hunderte skalieren.

Layer Normalization reskaliert die Werte, die durchs Netz fließen, um sie in einem gut handhabbaren numerischen Bereich zu halten. Ohne sie wachsen oder schrumpfen die Aktivierungen in einem tiefen Netz exponentiell und das Training divergiert. Moderne Transformer nutzen eine Variante namens RMSNorm, angewendet vor jeder Sub-Schicht (sogenanntes Pre-Norm) statt danach, weil das für sehr tiefe Modelle stabiler ist.

Diese beiden zusammen sind der Grund, warum sich Transformer dutzende oder hunderte Schichten tief stapeln lassen, ohne dass sie auseinanderfallen.

Der Output Head: Von Vektoren zu Vorhersagen

Oben im Stack haben Sie einen finalen Vektor pro Token-Position, der alles zusammenfasst, was das Modell über diese Position gelernt hat. Um daraus eine Vorhersage zu machen, wendet das Modell eine letzte lineare Schicht an — den Output Head oder Unembedding — der den Hidden-Vektor zurück auf einen vokabulargroßen Vektor projiziert. Dieser Vektor enthält einen Logit für jedes mögliche Token im Vokabular.

Eine Softmax verwandelt Logits in eine Wahrscheinlichkeitsverteilung über das gesamte Vokabular: “Gegeben den Kontext, hier ist, wie wahrscheinlich jeder mögliche nächste Token ist.” Viele Modelle teilen die Gewichte des Output Heads mit der Embedding-Matrix (sogenanntes Weight Tying), was Parameter spart und tendenziell hilft.

Beim Training vergleichen Sie diese Verteilung mit dem tatsächlichen nächsten Token und berechnen einen Loss (Cross-Entropy), der durchs gesamte Modell rückpropagiert wird, um alle Gewichte zu aktualisieren.

Bei der Generierung ziehen Sie ein Token aus dieser Verteilung. Rein gieriges Sampling (immer das wahrscheinlichste Token wählen) erzeugt repetitiven Output, also samplt man in der Praxis mit Anpassungen wie Temperature (verflacht oder schärft die Verteilung), Top-k (nur die k wahrscheinlichsten Token in Betracht ziehen) oder Top-p (nur Token, die kumulativ p % der Wahrscheinlichkeitsmasse abdecken).

Stellschrauben und Trade-offs

Die Transformer-Architektur hat eine überschaubare Zahl von Stellschrauben, und sie wirken alle aufeinander:

  • Schichtanzahl (Tiefe) — mehr Schichten bedeuten mehr sequenzielle Verfeinerung, mehr Kapazität für komplexes Reasoning, aber mehr Rechenaufwand pro Token und schwerere Optimierung.
  • Hidden-Dimension (Breite) — breitere Vektoren tragen mehr Information pro Token; skaliert auch die FFN-Parameter.
  • Anzahl Attention Heads — mehr Heads bedeuten mehr parallele “Perspektiven”, aber kleinere Pro-Head-Dimension.
  • Feedforward-Dimension — typisch 4× die Hidden-Dimension, aber variabel. MoE-Varianten erlauben, das mit Sparse Activation sehr groß zu skalieren.
  • Kontextlänge — wie viele Token das Modell sehen kann. Moderne Modelle reichen von 4K bis über 1M. Längere Kontexte sind ohne architektonische Anpassungen quadratisch teurer.
  • Vokabulargröße — größeres Vokabular kann mehrsprachige und spezialisierte Inhalte effizienter repräsentieren, fügt aber an Embedding- und Output-Enden Parameter hinzu.
  • Gesamtparameterzahl — die Schlagzeilen-”Größe” des Modells, von unter einer Milliarde (kleine offene Modelle) bis zu Hunderten Milliarden oder mehr (Frontier-Modelle).

Die Chinchilla Scaling Laws schlagen als grobe Regel vor, dass Rechenleistung in etwa gleichmäßig zwischen größeren Modellen und mehr Trainings-Token aufgeteilt werden sollte, mit optimal etwa 20 Token pro Parameter. Die Praxis weicht oft davon ab — Llama 3 wurde für ein 8B-Modell auf 15 Billionen Token trainiert, weit jenseits des Chinchilla-Optimums, weil ein zusätzlicher Trainings-Token billig ist relativ zum Nutzen, ein dauerhaft besseres kleines Modell auszurollen.

Varianten jenseits von Sprache

Dieselbe Architektur, mit kleinen Anpassungen, treibt die meisten anderen Modalitäten:

  • Vision Transformers (ViT) zerlegen ein Bild in Patches, flachen jeden Patch aus und behandeln die Patches wie Token. Alles dahinter ist identisch.
  • Audio-Transformer tokenisieren Audio entweder über gelernte Codecs (Audio-Chunks werden auf ein diskretes Vokabular abgebildet) oder indem sie Spektrogramme direkt verarbeiten.
  • Multimodale Modelle kombinieren mehrere Encoder — etwa einen Vision Encoder und einen Text-Tokenisierer — und füttern deren Outputs in einen gemeinsamen Transformer, der über beide hinweg argumentieren kann.

Die Vereinheitlichung ist bemerkenswert: Ein einziges architektonisches Muster, skaliert und angepasst, dominiert inzwischen Machine Learning quer durch die Modalitäten.

Wie die beiden Ebenen zusammenhängen

Datenebene und Modellarchitektur sind eng miteinander verflochten. Der Tokenisierer ist technisch Teil der Daten-Pipeline, bestimmt aber das Eingabevokabular, um das das Modell herum gebaut ist. Der Daten-Mix prägt, welche Fähigkeiten aus der Architektur emergieren. Die Kontextlänge, die die Architektur unterstützt, beschränkt, wie Dokumente in der Datenvorbereitung gechunkt werden müssen. Entscheidungen auf einer Ebene wirken auf die andere durch.

Ein nützliches mentales Modell: Die Architektur ist die Maschine, die Daten sind das Material. Die Maschine bestimmt, welche Arten von Mustern extrahiert und repräsentiert werden können; das Material bestimmt, welche Muster tatsächlich extrahiert werden. Eine perfekte Architektur, auf Müllinhalten trainiert, ergibt ein Müllmodell. Exzellente Daten, durch eine schlecht designte Architektur gejagt, vergeuden die Daten. Der State of the Art findet sich, wenn beides gleichzeitig stimmt.

Was als Nächstes

Wenn Sie tatsächlich etwas bauen wollten, ist der realistische Weg für die meisten nicht, ein Modell von Grund auf vorzutrainieren — das erfordert mindestens zweistellige Millionen an Rechenkosten für irgendetwas Konkurrenzfähiges. Stattdessen:

  • Ein Open-Weights-Basismodell verwenden (Llama, Mistral, Qwen, DeepSeek, Gemma) als Ausgangspunkt.
  • Es auf Ihren Domänendaten finetunen mit Techniken wie LoRA, die eine kleine Zahl zusätzlicher Parameter anpassen, statt das ganze Modell neu zu trainieren.
  • Die umgebende Anwendung bauen — Retrieval, Tool Use, Prompting, Evaluation — wo der meiste praktische Wert liegt.

Aber zu verstehen, was unter dem Modell liegt, das man benutzt — zu wissen, was ein Token ist, was Attention tut, warum Deduplizierung wichtig ist — verändert, wie man über alles darüber argumentiert. Die Abstraktionen lecken ständig, und die Leute, die sie effektiv debuggen, sind die, die wissen, was darunter passiert.

Das ist das Fundament. Der Rest des Stacks — Trainingsinfrastruktur, Fine-Tuning-Techniken, Evaluation, Inferenz-Optimierung, Agenten und Anwendungen — sitzt obenauf. Jeder Punkt ist einen eigenen Deep Dive wert.

Wenn Sie KI in Ihrem Produkt einsetzen wollen

Wir bauen aus Hamburg heraus Enterprise-Software für den deutschen Mittelstand und integrieren KI dort, wo sie konkrete Probleme löst — Retrieval, Klassifikation, Assistenzfunktionen, Agenten in geschäftskritischen Prozessen. Die Modellseite ist heute eher Werkzeug als Hexerei; der Unterschied entsteht in der Datenpipeline um das Modell herum und in der Engineering-Disziplin der Anwendung.

Wenn Sie KI sinnvoll in ein Produkt oder einen Prozess integrieren möchten, sprechen wir gern darüber. Mehr zu unserer Arbeit unter KI-Integration und Software-Architektur.

Lust auf ein Gespräch?

Wenn Sie hier weitergelesen haben, lohnt sich vielleicht auch ein direktes Gespräch. Erstgespräch unverbindlich.