Werkzeuge · Grundlagen

Wie LLMs funktionieren:
fünf Stufen zum Selbernachbauen.

19. August 2026 · Lesezeit ca. 12 Minuten

Das Projekt how-llms-work von w3cj zerlegt die Sprachmodell-Pipeline in fünf Stufen, die alle im Browser laufen: von einem Chatbot ohne jede Intelligenz bis zu einem Transformer, der ohne ML-Bibliothek trainiert wird. Ich habe den Aufbau durchgesehen und ordne ein, welche Stufe im Alltag mit LLMs tatsächlich weiterhilft.

Transparenzhinweis. Ich habe das Repository gelesen und den Aufbau nachvollzogen, aber keine eigenen Trainingsläufe gemessen. Alle Aussagen zum Projekt stammen aus dessen Dokumentation oder aus den verlinkten Arbeiten. Wo ich aus eigener Projektpraxis schreibe, steht es dabei.

Worum es geht

Die meisten Erklärungen zu Sprachmodellen bleiben bei Metaphern stehen. Wortwolken, Aufmerksamkeitspfeile, ein Bild vom Vektorraum. how-llms-work geht den anderen Weg und lässt den Leser den Code ausführen. Fünf Abschnitte, jeder mit einer eigenen Route auf dem Server, einem Client-Hook und einer Visualisierung, die per Server-Sent Events mitläuft, während gerechnet wird.

Der Stack ist schmal gehalten: Hono für Server, JSX und Client-Komponenten, Vite für Entwicklung und Bundling. Keine ML-Bibliothek. Was gerechnet wird, steht als TypeScript im Repository, inklusive Rückwärtspass und Optimierer. Das Projekt auf GitHub.

pnpm install
pnpm dev

Vorausgesetzt sind pnpm und Node 20 oder neuer. Wenn pnpm die Build-Skripte blockiert, mit pnpm approve-builds das Paket esbuild freigeben und danach erneut installieren.

Stufe 1: Ein Chatbot ohne Intelligenz

Simple Chat

ELIZA-Logik mit modernem Streaming

Grundlage: Weizenbaum (1966), ELIZA

Die erste Stufe ist ein Chatbot aus Bedingungen und Textmustern, wie ihn Joseph Weizenbaum 1966 gebaut hat. Er kennt keine Wahrscheinlichkeiten und lernt nichts. Er prüft, ob ein Muster passt, und antwortet mit dem hinterlegten Satz. Die Antwort kommt Wort für Wort über Server-Sent Events, also über dieselbe Übertragungsart, die ChatGPT benutzt.

Der Trick dieser Stufe liegt im Kontrast. Die Oberfläche fühlt sich an wie ein Sprachmodell, weil Streaming, Tippanimation und Chatverlauf identisch sind. Dahinter steckt eine Wenn-dann-Kette. Wer schon einmal einen Prototyp gesehen hat, der vor allem deshalb überzeugte, weil die Oberfläche stimmte, erkennt das Muster wieder.

Für die Praxis heißt das: Die gefühlte Qualität einer KI-Anwendung hängt zu einem erheblichen Teil an Dingen, die mit dem Modell nichts zu tun haben. Latenz bis zum ersten Token, Streaminggeschwindigkeit, Verlaufsdarstellung. Umgekehrt lässt sich ein schwaches Modell dadurch auch kaschieren, jedenfalls für die ersten Minuten.

Stufe 2: XOR und die Grenze einer Schicht

Neural Net

Warum ein Perzeptron an vier Datenpunkten scheitert

Grundlage: Rumelhart, Hinton & Williams (1986), Learning Representations by Back-Propagating Errors

Hier trainiert ein Netz live im Browser auf die XOR-Funktion, also auf vier Eingabepaare mit vier bekannten Antworten. Ein einschichtiges Perzeptron schafft das nicht, weil sich die Lösung nicht durch eine Gerade trennen lässt. Genau daran hing der KI-Winter der Siebzigerjahre, nachdem Minsky und Papert die Grenze 1969 beschrieben hatten.

Mit einer verdeckten Schicht und Backpropagation fällt der Fehler dann doch. Man sieht die Gewichte wandern und die Verlustkurve sinken, und das an einem Problem, das auf ein Blatt Papier passt.

Diese Stufe erklärt mehr über Modelltraining als jedes Diagramm über Gradientenabstieg. Backpropagation ist der Mechanismus, mit dem im Netz überhaupt Lernen stattfindet. Alles, was danach kommt, GPT eingeschlossen, ist dieselbe Rechnung in größerem Maßstab.

Stufe 3: Der Tokenizer, der die Rechnung schreibt

BPE

Byte Pair Encoding, trainiert auf eigenem Text

Grundlage: Sennrich, Haddow & Birch (2016), Neural Machine Translation of Rare Words with Subword Units

Der Nutzer gibt Text ein, der Algorithmus beginnt bei einzelnen Zeichen und verschmilzt in jedem Durchgang das häufigste Paar zu einer neuen Einheit. Die Visualisierung zeigt jeden Verschmelzungsschritt, bis aus Buchstaben Silben und aus Silben ganze Wörter geworden sind.

Von allen fünf Stufen ist das die mit dem größten praktischen Nutzen, weil der Tokenizer bestimmt, was ein Aufruf kostet und wie viel in das Kontextfenster passt. Wer eigenen Text durch die Demo schickt, sieht, warum deutsche Texte teurer sind als englische: Die gängigen Tokenizer wurden überwiegend auf englischem Material trainiert, also zerfallen Komposita, Umlaute und Flexionsendungen in mehr Einheiten. In meinen RAG-Projekten liegt der Aufschlag bei deutschen Fachtexten üblicherweise bei einem Drittel bis der Hälfte gegenüber einer englischen Übersetzung desselben Inhalts.

Dasselbe Verhalten erklärt die bekannten Aussetzer: dass Modelle die Buchstaben in einem Wort nicht sauber zählen, dass lange Zahlen ungenau werden, dass tief verschachteltes JSON überproportional Kontext frisst. Nichts davon ist ein Denkfehler des Modells. Es sieht die Zeichen gar nicht, es sieht Tokens.

Stufe 4: Embeddings, und warum das Modell für RAG entscheidet

Word2Vec

Skip-Gram mit Negative Sampling

Grundlage: Mikolov et al. (2013), Efficient Estimation of Word Representations und Distributed Representations of Words and Phrases

Das Modell lernt zu jedem Wort einen Vektor, indem es vorhersagt, welche Wörter in dessen Umgebung stehen. Negative Sampling zieht dazu einige zufällige Nichtnachbarn, statt über das gesamte Vokabular zu normieren, was das Training überhaupt erst bezahlbar macht. Die Demo zeigt, wie sich Wörter mit ähnlichem Gebrauch im Laufe des Trainings zusammenschieben.

Word2Vec ist von 2013 und in heutigen Systemen durch Transformer-Embeddings abgelöst. Der Mechanismus dahinter ist derselbe geblieben: Nähe im Vektorraum bedeutet Ähnlichkeit im Gebrauch, nicht Ähnlichkeit in der Bedeutung. Daran scheitert semantische Suche regelmäßig bei Gegensatzpaaren. „Vertrag gekündigt“ und „Vertrag verlängert“ stehen in fast identischen Umgebungen und landen entsprechend dicht beieinander.

Wer eine Wissensdatenbank aufbaut, entscheidet mit dem Embedding-Modell mehr über die Trefferqualität als mit dem nachgeschalteten Sprachmodell. Bei deutschsprachigen Beständen liegen mehrsprachig trainierte Modelle in meinen Vergleichen vor den englischlastigen Standardmodellen, und der Abstand fällt bei kurzen Chunks größer aus als bei langen.

Stufe 5: Ein Transformer ohne Bibliothek

GPT from scratch

Decoder-only, alles von Hand

Grundlage: Vaswani et al. (2017), Attention Is All You Need · Radford et al. (2018), GPT-1

Die letzte Stufe baut einen Decoder-only-Transformer und trainiert ihn im Browser. Multi-Head Causal Self-Attention, Layer Normalization, Feed-Forward-Blöcke, Rückwärtspass und Adam-Optimierer sind ausgeschrieben. Für die Geschwindigkeit läuft das Training über mehrere Threads mit SharedArrayBuffer.

Die Bauteile stammen aus einer Reihe von Arbeiten, die das Projekt einzeln verlinkt und die im Code als benannte Funktionen wieder auftauchen:

BauteilHerkunftAufgabe
Xavier-InitialisierungGlorot & Bengio, 2010Startgewichte so skalieren, dass Signale in tiefen Netzen weder verpuffen noch explodieren
Layer NormalizationBa, Kiros & Hinton, 2016Aktivierungen vor Attention und Feed-Forward normieren, damit das Training stabil bleibt
AdamKingma & Ba, 2014Lernrate je Parameter anpassen statt global
Causal Self-AttentionVaswani et al., 2017Jedes Token gewichtet die vorangehenden Token, künftige bleiben verdeckt
Nucleus SamplingHoltzman et al., 2019Bei der Ausgabe nur aus der Wahrscheinlichkeitsmasse ziehen, die den Anteil p abdeckt

Für den Betrieb interessant wird diese Stufe beim Sampling. Holtzman et al. haben 2019 gezeigt, dass die jeweils wahrscheinlichste Fortsetzung zu wiederholtem, leblosem Text führt, während reines Zufallsziehen aus der vollen Verteilung entgleist. Top-p schneidet den Schwanz der Verteilung ab und zieht aus dem Rest. Wer in einer Anwendung an temperature und top_p dreht, verschiebt genau diese Grenze, und in der Demo lässt sich der Effekt an einem winzigen Modell direkt beobachten.

Wie das Projekt aufgebaut ist

Alle fünf Abschnitte folgen demselben Dreischritt, was das Lesen erleichtert, sobald man einen davon verstanden hat:

  1. Server-Route unter src/routes/: ein Hono-POST-Endpunkt, der die Eingabe annimmt und den Rechenfortschritt als SSE-Ereignisse zurückschickt.
  2. Client-Hook unter src/client/hooks/: hält den UI-Zustand und verbindet den Ereignisstrom über useSSEChat mit der Darstellung.
  3. Result-Komponente unter src/client/components/: zeichnet die eintreffenden Daten als Visualisierung.

Geteilt werden der BPE-Tokenizer in src/server/lib/bpe.ts, den die Stufen 3 bis 5 gemeinsam nutzen, sowie die SSE-Hilfsfunktionen auf beiden Seiten. Wer nur ein Detail nachlesen will, kommt über diese Dateien schnell hin.

Was ich daraus mitnehme

Für Teams, die LLM-Anwendungen betreiben, lohnen sich vor allem die Stufen 3 und 4. Tokenizer und Embeddings sind die beiden Stellen, an denen eigene Entscheidungen anstehen und an denen Fehler direkt aufs Budget und auf die Trefferqualität durchschlagen. Die Stufen 2 und 5 erklären, warum Modelle sich verhalten, wie sie sich verhalten, ändern an der eigenen Architektur aber wenig.

Ein Vorbehalt: Ein Transformer, der im Browser auf einem kleinen Korpus trainiert, zeigt den Mechanismus, nicht das Verhalten großer Modelle. Was ein Modell mit dreistelliger Milliardenzahl an Parametern kann, folgt nicht aus dem, was ein Spielzeugmodell tut. Wer den Sprung mitliest, verwechselt leicht Skalenfrage mit Prinzipfrage.

Der Aufwand hält sich in Grenzen. Repository klonen, pnpm install, pnpm dev, danach lassen sich alle fünf Abschnitte mit eigenem Text füttern.

LLM-Anwendung im Aufbau?

Ich baue RAG- und LLM-Anwendungen für den Produktivbetrieb, von der Wahl des Embedding-Modells über Chunking und Auswertung bis zum Monitoring im laufenden Betrieb. 30 Minuten Erstgespräch, kostenlos.