Transformer – Was du jetzt wissen musst

Transformer sind keine Blackbox. Ihr Kernmechanismus ist Self-Attention: jedes Token gewichtet, wie stark es auf jedes andere achten soll. Wer das versteht, trifft bessere Entscheidungen bei Modellwahl, Context-Window und Kosten.

Die Technologie hinter ChatGPT, Copilot und Co. ist keine Blackbox. Wenn du verstehst, wie Transformer funktionieren, triffst du bessere Entscheidungen beim KI-Einsatz: bei der Modellwahl, beim Prompt-Design und beim Budget.

Seit der Veröffentlichung des Papers «Attention Is All You Need» von Vaswani et al. im Jahr 2017 hat die Transformer-Architektur praktisch jede andere Methode im Bereich Natural Language Processing verdrängt. Heute steckt sie nicht nur in Sprachmodellen, sondern auch in Bildgeneratoren, Code-Assistenten und Modellen der Strukturbiologie. Als IT-Professional oder Business-Analystin begegnest du Transformern täglich: in deinen Tools, in den APIs, die du anfragst, und in den Budgets, die du rechtfertigst. Höchste Zeit, die Architektur wirklich zu verstehen, nicht nur dem Namen nach.

Stand: Juni 2026. Die Transformer-Architektur selbst ist seit dem Paper von 2017 stabil; was sich laufend verschiebt, sind Modellgrössen, die Länge der Context Windows und Effizienz-Techniken wie Flash Attention und Quantisierung.

Was macht ein Transformer eigentlich, ohne Mystik?

Der entscheidende Mechanismus heisst Self-Attention. Vereinfacht ausgedrückt berechnet das Modell für jedes Token (grob: Wort oder Wortfragment) in einer Sequenz, wie stark es auf jedes andere Token derselben Sequenz «achten» soll. Das Ergebnis ist ein gewichteter Kontext, der weit über einfache Nachbarschaftsbeziehungen hinausgeht.

Ein konkretes Beispiel: Im Satz «Der Beirat empfiehlt dem Vorstand, seine Strategie zu überdenken» muss das Modell wissen, dass sich «seine» auf «Vorstand» bezieht, nicht auf «Beirat». Klassische rekurrente Netze (RNNs) haben das durch sequenzielle Verarbeitung gelöst, langsam und fehleranfällig bei langen Abhängigkeiten. Der Transformer löst es in einem einzigen parallelen Schritt über die gesamte Sequenz. Das ist der Grund, weshalb er sich auf moderner GPU-Hardware so effizient trainieren lässt.

Drei Komponenten, die du kennen musst

1. Multi-Head Attention. Statt einer einzigen Attention-Berechnung führt das Modell mehrere parallel durch. Im Original-Paper waren es acht sogenannte «Heads», in heutigen Grossmodellen deutlich mehr. Jeder Head lernt andere Beziehungsmuster: syntaktische Strukturen, semantische Ähnlichkeiten, Koreferenzen. Genau diese Aufteilung macht das Modell robust gegenüber unterschiedlichen sprachlichen Phänomenen.

2. Feed-Forward-Schichten. Nach der Attention kommt pro Token eine vollverbundene Schicht, die das gelernte Kontextsignal in eine neue Repräsentation übersetzt. Diese Schichten machen einen Grossteil der Modellparameter aus und damit auch einen Grossteil des Speicherbedarfs.

3. Positional Encoding. Transformer verarbeiten Tokens parallel und haben deshalb keine inhärente Reihenfolge. Positional Encodings fügen jedem Token eine Information über seine Position in der Sequenz hinzu: entweder als feste Sinusfunktion (wie im Original), als gelernte Positions-Embeddings (wie in BERT) oder als rotationsbasierte Variante wie RoPE (Rotary Position Embedding), die in vielen aktuellen Modellen eingesetzt wird.

Warum zählt die Grösse, und wo liegen die Grenzen?

Die Anzahl der Parameter ist die meistgenannte Kennzahl, aber sie allein erklärt wenig. Relevanter für den Praxiseinsatz sind drei andere Grössen.

• Context Window: Wie viele Tokens kann das Modell gleichzeitig «sehen»? Frühe Chat-Modelle lagen im niedrigen vierstelligen Bereich, heutige Spitzenmodelle erreichen mehrere Hunderttausend bis über eine Million Tokens. Das entspricht ganzen Büchern. Für Business-Analysten heisst das: grössere Dokumente passen in einen einzigen API-Call, was Chunk-Strategien vereinfacht, aber die Kosten pro Call erhöht.
• Attention-Komplexität: Self-Attention skaliert in der Grundform quadratisch mit der Sequenzlänge. Doppelt so viele Tokens bedeuten rund viermal so viel Rechenaufwand. Deshalb bleiben sehr grosse Context Windows trotz technischem Fortschritt teuer. Ansätze wie Flash Attention optimieren den GPU-Speicherzugriff und mildern das Problem, lösen es aber nicht vollständig.
• Quantisierung: Moderne Deployment-Strategien reduzieren die Präzision der Modellgewichte von 32-Bit-Floats auf 8 Bit oder 4 Bit. Das senkt den Speicherbedarf deutlich, bei überschaubarem Qualitätsverlust. Ein Modell mit wenigen Milliarden Parametern läuft so auch auf einer einzelnen Consumer-GPU, ein Faktor, der Local-Deployment-Entscheidungen direkt beeinflusst.

Encoder, Decoder oder beides: Welches Modell für welchen Use Case?

Nicht jeder Transformer ist gleich aufgebaut. Die Architekturvariante bestimmt, wofür ein Modell geeignet ist.

• Encoder-only (Beispiel: BERT, RoBERTa): Verarbeitet die gesamte Eingabesequenz bidirektional. Optimal für Klassifikation, Named Entity Recognition und Embedding-Generierung. Ein Modell, das du als Retrieval-Engine in einem RAG-System einsetzt, gehört oft in diese Kategorie.
• Decoder-only (Beispiel: GPT-Familie, LLaMA, Mistral): Verarbeitet autoregressiv von links nach rechts und generiert Token für Token. Das ist die Architektur hinter den gängigen Chat- und Code-Assistenten. Vorteil: ein Modell für viele Aufgaben durch Prompting. Nachteil: bei reinen Klassifikationsaufgaben weniger effizient als ein Encoder-Modell.
• Encoder-Decoder (Beispiel: T5, BART, das ursprüngliche Transformer-Design): Der Encoder verarbeitet den Input, der Decoder generiert den Output. Klassisch für Übersetzung, Zusammenfassung und Aufgaben, bei denen Input- und Output-Länge stark abweichen.

Für die Praxis bedeutet das: Wenn du ein internes Dokument-Retrieval aufbaust, nutzt du wahrscheinlich ein Encoder-Modell für die Vektorisierung und ein Decoder-Modell für die Antwortgenerierung, zwei verschiedene Transformer-Typen in einer Pipeline.

Fine-Tuning, Prompting oder RAG: Wie entscheidest du?

Das Verständnis der Architektur hilft dir, die richtige Anpassungsstrategie zu wählen. Drei Wege stehen zur Auswahl, und sie schliessen sich nicht aus.

• Prompting verändert die Gewichte nicht. Du gibst dem Modell Kontext und Instruktionen im Input. Geeignet für allgemeine Aufgaben, schnelle Prototypen und Situationen ohne proprietäre Trainingsdaten. Grenze: Das Modell «weiss» nichts, was nicht in seinen Gewichten steckt oder im Context Window steht.
• RAG (Retrieval-Augmented Generation) kombiniert einen Retriever (meist ein Encoder-Modell, das Dokumente in Vektoren umwandelt) mit einem Generativmodell. Deine internen Dokumente bleiben separat, das Basismodell unverändert. Geeignet für wissensbasierte Anwendungen mit häufig aktualisierten Inhalten.
• Fine-Tuning passt die Gewichte des Modells an deine Daten an. Mit LoRA (Low-Rank Adaptation) geht das heute mit vergleichsweise geringem Aufwand: Ein Modell mit wenigen Milliarden Parametern lässt sich auf einer einzelnen GPU in überschaubarer Zeit auf domänenspezifische Aufgaben spezialisieren. Geeignet für konsistenten Stil, spezifische Ausgabeformate und Fachsprache. Weniger geeignet, um aktuelles Wissen einzuschleusen, dafür ist RAG meist die bessere Wahl.

Was bedeutet das für deine Arbeit?

Transformer sind keine uniform einsetzbaren Werkzeuge. Wer sie nur als API-Endpunkt behandelt, verzichtet auf relevante Steuerungsmöglichkeiten. Drei konkrete Punkte für deinen Alltag.

Erstens: Context-Window-Management ist Kostenmanagement. Lange Prompts mit unnötigem Kontext erhöhen deine API-Kosten weitgehend linear, weil die meisten Anbieter pro Token abrechnen. Ein strukturierter Prompt, der nur den nötigen Kontext mitschickt, ist günstiger als einer, der ein ganzes Dokument vorsorglich anhängt. Bei täglich tausenden Anfragen wird daraus ein relevanter Budgetposten.

Zweitens: Embeddings sind wiederverwendbar. Wenn du Dokumente vektorisierst, um sie durchsuchbar zu machen, musst du diese Berechnung nur einmal durchführen und kannst die Vektoren in einer Datenbank ablegen. Jede spätere Suchanfrage vergleicht nur noch den frischen Query-Vektor mit dem bestehenden Bestand, statt das gesamte Korpus neu zu verarbeiten. Das senkt die laufenden Kosten eines RAG-Systems erheblich und macht den Unterschied zwischen einem Prototyp und einem System, das im Dauerbetrieb wirtschaftlich bleibt.

Drittens: Die Architekturvariante ist eine Auswahlentscheidung, keine Nebensache. Für Klassifikation oder semantische Suche ist ein schlankes Encoder-Modell oft schneller und günstiger als ein grosses Decoder-Modell, das man für dieselbe Aufgabe per Prompt zweckentfremdet. Wer die Varianten kennt, kann gezielt das passende Modell wählen, statt reflexhaft zum grössten Chat-Modell zu greifen.

Fazit

Der Transformer ist das Fundament fast aller produktiv genutzten KI-Modelle, und sein Innenleben ist erklärbar. Self-Attention erlaubt parallele Verarbeitung ganzer Sequenzen, die Architekturvariante (Encoder, Decoder, beides) bestimmt den Einsatzzweck, und Grössen wie Context Window, Attention-Komplexität und Quantisierung steuern direkt deine Kosten. Du musst kein Modell von Grund auf trainieren, um davon zu profitieren. Es reicht, die Hebel zu kennen.

Unsere Empfehlung für die nächste Architektur-Entscheidung: Kläre zuerst die Aufgabe (klassifizieren, generieren, übersetzen, durchsuchen), dann die Variante, dann erst die Modellgrösse. Greife zu RAG, wenn dein Wissen aktuell bleiben muss, zu Fine-Tuning für konsistenten Stil und Format, und zu reinem Prompting, solange Context Window und Basismodell ausreichen. So bezahlst du nur für die Komplexität, die deine Aufgabe wirklich braucht.

Mehr Orientierung im Zusammenhang findest du in unseren KI-Grundlagen, dem Lernpfad, der Modelle, Tokens und lokale KI Schritt für Schritt einordnet.