600 Millionen Parameter stecken in dem kleinen Sprachmodell, das in einer Browser-Demo zeigt, wie Aufmerksamkeit in Large Language Models tatsächlich funktioniert. Der Autor hat eine interaktive Visualisierung gebaut, die sichtbar macht, welche vergangenen Token ein gerade entstehendes Wort beeinflussen. Beim Kopieren einer Adresse leuchten die Quell-Token hell auf, beim Wort „remain“ verschmelzen Informationen aus zwei Sätzen zu einem neuen Token. Das sieht aus wie Spielerei, ist aber ein Blick in den Mechanismus, der Sprache erzeugt.
Was Attention in einem Transformer überhaupt leistet
Transformer-Modelle erzeugen Text Token für Token, also in kleinen Bedeutungseinheiten, die oft kürzer sind als ganze Wörter. Bei jedem neuen Token hat das Modell Zugriff auf alle vorher erzeugten Token. Das allein reicht nicht. Wenn jedes frühere Token gleich stark wirkte, ginge das Signal im Rauschen unter. Die Architektur braucht einen Mechanismus, der entscheidet: Welche vergangenen Token sind gerade wichtig, welche weniger? Genau das übernimmt der Attention-Mechanismus.
Stell dir einen Assistenten vor, der ein neues Wort formulieren soll und Dutzende Karteikarten mit dem bisherigen Text vor sich hat. Manche Karten sind relevant, andere Hintergrund. Attention ist das Gewicht, das der Assistent jeder Karte gibt. In technischen Begriffen handelt es sich um gelernte Koeffizienten, die bestimmen, wie stark der Wert eines Tokens in die nächste Vorhersage einfließt. Heraus kommen die Attention Heads, also parallel arbeitende Einheiten, die unterschiedliche Aspekte des Kontexts erfassen.
Wie die Visualisierung die Aufmerksamkeit sichtbar macht
Die Demo nutzt Transformers.js, eine JavaScript-Bibliothek, die Modelle direkt im Browser ausführt. Normalerweise gibt eine solche Bibliothek nur die fertig generierten Token zurück. Für die Visualisierung braucht es mehr: Die internen Attention-Gewichte, die Value-Vektoren und den vollständigen Schichtaufbau des Modells. Das Standard-Interface stellt diese Werte nicht bereit.
Der Autor musste deshalb einen eigenen Generierungs-Loop improvisieren, im Text als „vibe-code“ bezeichnet. Gemeint ist explorative Programmierung, bei der man sich Stück für Stück an die richtigen Zugriffe herantastet. Dabei entstand das Problem, dass die ONNX-Dateien den kompletten Rechengraphen in WebAssembly enthalten, also in kompiliertem Binärcode, der direkt im Browser läuft. An interne Zwischenwerte kommt man über die übliche Schnittstelle nicht heran. Die Lösung war ein kleines Skript, das die ONNX-Datei minimal verändert, um die nötigen Werte freizugeben. Dieses instrumentierte Modell liegt auf einem eigenen Hugging-Face-Repository und wird von der App explizit von dort geladen.
Ein praktischer Punkt: Selbst ein 600-Millionen-Parameter-Modell ist einige hundert Megabyte groß. Diese Datenmenge beim ersten Aufruf der Seite zu laden, wäre kaum zumutbar. Deshalb hat der Autor mehrere vorberechnete Prompts hinterlegt. Wer die Demo öffnet, bekommt sofort sichtbare Ergebnisse, ohne auf den Modell-Download zu warten.
Was die Visualisierung tatsächlich zeigt und was sie weglässt
Die Darstellung arbeitet mit einer einzigen Zahl pro vergangenem Token. Sie berechnet das Attention-Gewicht, multipliziert es mit der Länge des Value-Vektoren-Anteils, der in dieses Token fließt, und addiert die Ergebnisse über alle Heads und alle Schichten. Das klingt kompliziert, ist im Kern eine Aggregationsstrategie: Aus den abertausenden Attention-Werten pro Token wird ein einziger Helligkeitswert. Der höchste Wert bekommt volle Deckkraft, alle anderen werden relativ dazu skaliert. Beim Hover über ein generiertes Token leuchten die vergangenen Token hervor, die am stärksten zu seiner Entstehung beigetragen haben.
Dabei gehen viele Informationen verloren. Der Autor betont, dass die Bezeichnung „beeinflusst“ streng genommen nicht exakt ist, weil die Visualisierung eine starke Vereinfachung darstellt. In Wirklichkeit sind Attention-Muster mehrdimensional, abhängig vom Kontext und über viele Köpfe verteilt. Trotz dieser Reduktion entstehen nachvollziehbare Muster. Bemerkenswert, denn ursprünglich hatte der Autor selbst bezweifelt, dass aus einem einzigen Zahlenwert pro Token noch etwas Lesbares hervorgehen würde.
Warum LLMs besser kopieren als der Zufall erlauben würde
Eine häufige Irritation betrifft das Kopieren. Wer schon einmal eine Adresse, ein Datum oder einen Funktionsnamen von einem KI-System reproduzieren ließ, staunt oft, wie fehlerfrei das gelingt. Die intuitive Erwartung sagt: Wenn ein Modell probabilistisch arbeitet, müssten sich über die Länge eines kopierten Abschnitts doch irgendwann Fehler einschleichen. Jeder Schritt habe eine kleine Fehlerwahrscheinlichkeit, und die summiere sich.
Die Visualisierung zeigt, warum diese Rechnung nicht aufgeht. Beim Kopieren greift das Modell gezielt auf genau die Token zurück, die es reproduzieren will. Im „Office Move Summary“-Beispiel genügt es, über die kopierte Stelle zu hovern, und die Quell-Token leuchten hell auf. Das Modell muss die zu kopierende Sequenz nicht aus einem begrenzten internen Zustand rekonstruieren, sondern kann jederzeit direkt auf das Original zugreifen. Die Fehlerwahrscheinlichkeit bleibt niedrig, weil der Mechanismus das Kopieren aktiv unterstützt.
Wenn das Modell Information aus mehreren Quellen kombiniert
Aufschlussreich ist ein Detail aus dem gleichen Demo-Prompt. Der Satz „Existing access cards and phone numbers remain“ enthält das Wort „remain“, und ein Hover darüber zeigt, dass das Modell Informationen aus zwei Stellen des Kontexts zusammenführt. Aus dem Satz „Existing employee access cards will work“ wird das Wort „work“ herangezogen, aus einem anderen Satz das Wort „stay the same“. Das resultierende Token ist eine Art Kompositum aus beiden Bedeutungen.
Das illustriert ein Grundprinzip der Transformer-Architektur: Neue Token entstehen nicht aus einem einzigen Hinweis, sondern durch die gewichtete Mischung vieler Hinweise. Das Modell lernt während des Trainings, welche Kombinationen sinnvoll sind. Im konkreten Fall hat es offenbar gelernt, dass Bedeutungen wie „weiterhin gültig sein“ sowohl mit „work“ als auch mit „stay the same“ ausgedrückt werden können, und nutzt diese Assoziation, um ein Token zu erzeugen, das die zugrundeliegende Intention transportiert.
Was das für den Blick auf Sprachmodelle bedeutet
Die Visualisierung räumt mit einer verbreiteten Vorstellung auf: LLMs sind keine Blackbox, deren Innenleben sich jeder Einsicht entzieht. Viele Details bleiben opak, aber zumindest der Attention-Mechanismus lässt sich mit vertretbarem Aufwand darstellen und interpretieren. Das schlägt eine Brücke zwischen der abstrakten Mathematik der Transformer und dem konkreten Verhalten im Output.
Wer die Demo selbst ausprobieren möchte, findet sie auf der Projektseite. Der Quellcode liegt auf GitHub, das angepasste Modell auf Hugging Face. Die Vorgehensweise – ein ONNX-Modell minimal instrumentieren, einen eigenen Generierungs-Loop schreiben, vorberechnete Prompts anbieten – ist auch für andere Visualisierungsprojekte brauchbar. Sie zeigt, dass selbst in der stark optimierten Browser-Inferenz noch Spielraum besteht, um Modelle von innen sichtbar zu machen, solange man bereit ist, ein wenig über den Standardweg hinauszugehen.
Quelle: ishamf.dev
