Ich starte eine Serie über lokale Modelle — zuerst die Begriffe

Ich fange eine Serie an. In den kommenden Wochen möchte ich sauber und mit Zahlen herausarbeiten, was lokale Sprachmodelle auf käuflicher Hardware tatsächlich leisten — nicht, was eine Rangliste behauptet, und nicht, was ein Hersteller verspricht. Jeder Teil steht für sich, und jeder endet mit etwas Gemessenem statt mit etwas Behauptetem.

Dieser erste Teil enthält überhaupt keine Messungen. Er ist das Vokabular. Jeder folgende Artikel stützt sich auf dieselbe Handvoll Begriffe — Token, Kontext, KV-Cache, Temperature, Seed, Quantisierung —, und die meisten Erklärungen dazu bleiben entweder bei der Analogie stehen oder springen direkt in die Mathematik. Bevor ich also irgendetwas teste, hier das Erdgeschoss: genug Detail für vernünftige Entscheidungen, nicht genug, um einen Kernel zu schreiben.

Was das Modell tatsächlich tut

Ein Sprachmodell kann genau eine Sache: Zu einer Folge von Token schätzt es, wie wahrscheinlich jedes mögliche nächste Token ist. Das ist der ganze Trick. Alles andere — Chat, Code, Zusammenfassungen — ist diese eine Operation, wiederholt.

Um einen Satz zu schreiben, erzeugt das Modell ein Token, hängt es an die Folge und läuft erneut, jetzt mit der längeren Folge. Und wieder. Eine Antwort mit 1.000 Token sind tausend vollständige Durchläufe durch das Netz, jeder etwas teurer als der vorige, weil die Folge wächst. Deshalb fühlt sich Generierung gleichmäßig an statt sofort, und deshalb kostet eine lange Antwort mehr als eine kurze — auf eine Weise, die nicht ganz linear ist.

Das Wort dafür ist autoregressiv: Die Ausgabe fließt zurück in die Eingabe. Es erklärt auch etwas, das viele überrascht — das Modell hat keinen Plan. Es hat nie „entschieden“, wie der Satz endet. Es legt sich Token für Token fest, und die Form der Antwort entsteht erst dabei.

Token sind keine Wörter

Modelle sehen weder Buchstaben noch Wörter. Text wird in Token zerlegt — Fragmente, die der Tokenisierer aus seinen Trainingsdaten gelernt hat. Häufige Wörter sind meist ein Token. Seltene zerfallen. Leerzeichen und Satzzeichen zählen mit.

Die Faustregel fürs Englische lautet rund 0,75 Wörter je Token, also etwa vier Zeichen. Deutsch schneidet schlechter ab, weil Komposita zerfallen: Kontextfenster kostet womöglich drei Token, wo „context window“ mit zwei auskommt. Wer Kontext für deutschen Text plant, sollte gut 20–30 % auf die englische Schätzung aufschlagen. Das wird in dem Moment relevant, in dem ein Dokument in ein festes Fenster passen soll.

Das Kontextfenster ist eine harte Wand

Das Kontextfenster gibt an, wie viele Token das Modell gleichzeitig berücksichtigen kann — und es zählt alles: Systemanweisung, Gesprächsverlauf, deine Frage und die Antwort, die gerade entsteht. Ein Fenster von 32.768 Token, in dem 30.000 Token Verlauf stehen, lässt Platz für eine sehr kurze Erwiderung.

Zwei Dinge daran überraschen regelmäßig. Erstens ist die Grenze architektonisch — ein Modell, das für 40.960 Token trainiert wurde, lässt sich nicht nach mehr fragen, und eine Laufzeitumgebung kappt die Anfrage üblicherweise stillschweigend auf das Modellmaximum, statt sie abzulehnen. Wer von einem 40k-Modell 128k verlangt, bekommt womöglich schlicht 40k, ohne Hinweis. Zweitens ist das Füllen des Fensters nicht umsonst: Jedes Token, das das Modell schreibt, muss über alles hinwegsehen, was schon darin steht.

Der KV-Cache und warum es ihn gibt

Das Problem, das der Cache löst: Bei jedem Durchlauf vergleicht die Aufmerksamkeit das aktuelle Token mit allen vorherigen. Naiv umgesetzt hieße das Erzeugen von Token 1.000, die Repräsentation der Token 1 bis 999 erneut zu berechnen — zum tausendsten Mal.

Also legt die Laufzeitumgebung sie ab. Für jedes verarbeitete Token werden zwei Vektoren — Key und Value — im VRAM behalten. Dieser Speicher ist der KV-Cache, und beim nächsten Durchlauf greift das Modell darauf zu, statt neu zu rechnen. Ohne ihn wären lange Gespräche unbenutzbar.

Daraus folgen zwei Dinge, und es sind genau die, die in der Praxis wehtun:

Der Cache belegt VRAM neben den Modellgewichten. Die Karte muss beides halten. Ein Modell, das mit kleinem Kontext bequem passt, kann mit großem überlaufen.
Der Cache muss für jedes erzeugte Token gelesen werden. Je größer er ist, desto mehr Speicherverkehr kostet jedes Token. Deshalb wird Generierung langsamer, während ein Gespräch wächst — auch wenn nichts an Speicher ausgegangen ist.

Man kann den Cache verkleinern, indem man diese Vektoren mit geringerer Genauigkeit ablegt. q8_0 speichert sie mit 8 statt 16 Bit und halbiert ihn dadurch grob — zu Qualitätskosten, die die meisten nie bemerken. Auf einer fast vollen Karte kann diese Einstellung der Unterschied zwischen funktionieren und nicht funktionieren sein.

Temperature: Null heißt nicht „aus“

Das Modell liefert für jedes mögliche nächste Token eine Wahrscheinlichkeit. Temperature entscheidet, wie diese Liste genutzt wird.

Temperature 0 — immer das wahrscheinlichste Token nehmen. Es wird nicht gewürfelt. Gleiche Eingabe, gleiche Ausgabe.
Temperature um 0,7 — der übliche Standardwert. Wahrscheinliches bleibt wahrscheinlich, aber Unwahrscheinliches bekommt eine echte Chance. Das lässt Text natürlich statt mechanisch wirken.
Temperature über 1 — die Verteilung flacht ab. Erst kreativ, dann seltsam, dann zusammenhanglos.

Der verbreitete Denkfehler ist, Temperature 0 als „Zufall abschalten“ zu lesen. Genauer ist: Es nimmt die Wahl heraus. Das Modell bewertet weiterhin jedes Token, es greift nur immer zum obersten. Das hat einen unterschätzten Preis — gieriges Dekodieren kann sich in einer Wiederholungsschleife festfahren und findet nicht heraus, weil das Token, das die Schleife bräche, nie ganz das wahrscheinlichste ist.

Zum Messen ist Temperature 0 die richtige Voreinstellung: Man will das Modell messen, nicht den Würfel. Zum Schreiben ist es meist zu starr.

Seed: nur sinnvoll, wenn überhaupt etwas zufällig ist

Der Seed initialisiert den Zufallszahlengenerator, der zwischen den Kandidaten auswählt. Gleicher Seed und gleiche Einstellungen, gleiche Auswahlentscheidungen, gleicher Text.

Woraus der Punkt folgt, den die meisten Anleitungen auslassen: Bei Temperature 0 tut der Seed nichts. Es gibt keine Auswahl, die er steuern könnte. Wer einen Benchmark bei Temperature 0 fährt und dabei den Seed variiert, misst keine Streuung des Modells — sondern ob der Rest des Aufbaus deterministisch ist. Das ist eine andere und ebenfalls nützliche Frage.

Ebenfalls wissenswert: Gleiche Einstellungen garantieren keinen gleichen Text, wenn die Berechnung abweicht. Gleitkomma-Arithmetik ist nicht assoziativ, also kann ein anderer Ausführungsweg — andere Hardware, andere Stapelbildung, ein Teil des Modells läuft woanders — das Ergebnis verändern, selbst bei festem Seed. Reproduzierbarkeit ist eine Eigenschaft des gesamten Aufbaus, nicht des Seeds allein.

Quantisierung: der Regler zwischen Größe und Qualität

Modelle werden mit 16 Bit Genauigkeit trainiert. Ein Modell mit 30 Milliarden Parametern belegt bei 16 Bit rund 60 GB — jenseits jeder Consumer-Karte. Quantisierung legt die Gewichte mit weniger Bits ab, damit sie passen.

Die Bezeichnungen wirken kryptisch, lassen sich aber leicht auflösen. Bei q4_K_M: q4 sind vier Bit je Gewicht, K steht für das neuere Verfahren, das Gewichte gruppiert und je Gruppe einen Skalierungsfaktor ablegt statt einen für alles, und M ist die mittlere Variante — einige Schichten bleiben genauer, weil sie mehr wiegen. q8_0 sind acht Bit im älteren, einfacheren Verfahren.

Grob: q4_K_M landet bei etwa einem Viertel der Ursprungsgröße und ist die praktische Voreinstellung für eine 24-GB-Karte. Unter vier Bit leidet die Qualität spürbar. Über acht bezahlt man meist VRAM für einen Unterschied, den man nicht messen kann.

Der Vergleich, auf den es ankommt: Ein größeres, stärker quantisiertes Modell schlägt in der Regel ein kleineres mit voller Genauigkeit. Mehr Parameter auf die Karte zu bekommen wiegt schwerer, als jeden einzelnen genau zu halten.

Flash Attention

Herkömmliche Aufmerksamkeit baut eine Matrix, die jedes Token mit jedem anderen vergleicht, schreibt sie in den Speicher und liest sie wieder. Bei 32.000 Token ist diese Matrix riesig, und der Engpass ist nicht das Rechnen — es ist das Hin- und Herschieben der Daten zum VRAM.

Flash Attention baut die Berechnung so um, dass sie in Kacheln arbeitet, die im schnellen chipnahen Speicher bleiben; die vollständige Matrix wird nie herausgeschrieben. Das Ergebnis ist mathematisch dasselbe, entsteht aber mit weit weniger Speicherverkehr. Der Nutzen wächst mit der Kontextlänge, und es kostet nichts außer einem Schalter. Einschalten.

Die Regler, die man wirklich setzt

Einstellung	Was sie tut	Was oft falsch verstanden wird
`num_ctx`	Kontextfenster dieser Anfrage. Reserviert den KV-Cache.	„Sicherheitshalber groß“ reserviert VRAM, das man fürs Modell selbst braucht.
`num_predict`	Höchstzahl zu erzeugender Token.	Zu klein schneidet stillschweigend mitten im Satz ab; die Antwort wirkt fertig, ist es aber nicht.
`temperature`	Wie mutig ausgewählt wird.	Wird als Qualitätsregler gelesen. Es ist ein Vielfaltsregler.
`seed`	Legt die Zufallsfolge fest.	Wirkt bei Temperature 0 überhaupt nicht.
`keep_alive`	Wie lange das Modell nach einer Anfrage im VRAM bleibt.	Zu kurz heißt, die Ladezeit immer wieder zu zahlen; zu lang blockiert die Karte.
KV-Cache-Typ	Genauigkeit des Caches, z. B. `q8_0`.	Wird komplett übersehen — oft der billigste Weg zu mehr Kontext.
Flash Attention	Speichersparende Aufmerksamkeit.	In manchen Aufbauten standardmäßig aus.

Was das Tempo bestimmt

Zwei Phasen, zwei verschiedene Engpässe — und sie zu vermischen verursacht die meiste Verwirrung rund um Benchmarks.

Prefill ist das Lesen der Eingabe. Sie lässt sich vollständig parallel verarbeiten, ist also durch reine Rechenleistung begrenzt und läuft meist mit Tausenden Token pro Sekunde.

Generierung ist das Schreiben der Antwort, Token für Token, jedes vom vorigen abhängig. Über Token hinweg lässt sich nichts parallelisieren, und jeder Schritt liest Modellgewichte und KV-Cache aus dem VRAM. Begrenzt wird das durch die Speicherbandbreite, nicht durch Rechenleistung — weshalb zwei Karten mit ähnlichen Teraflops, aber unterschiedlichem Speichertempo sich völlig verschieden verhalten, und weshalb „Token pro Sekunde“ ohne Angabe der Phase eine bedeutungslose Zahl ist.

Über allem steht eine Klippe: Passt das Modell nicht ins VRAM, legt die Laufzeitumgebung einen Teil der Schichten in den Systemspeicher und rechnet sie auf der CPU. Diese Schichten schieben ihre Daten dann über den PCIe-Bus mit einem Bruchteil der VRAM-Bandbreite, und jedes Token wartet auf sie. Das ist kein sanfter Abfall. Es ist das Erste, was man prüft, bevor man irgendetwas anderem die Schuld gibt.

Glossar

Token — Textfragment; ~0,75 Wörter im Englischen, weniger im Deutschen.
Kontextfenster — Höchstzahl gleichzeitig berücksichtigter Token, Eingabe und Antwort zusammen.
KV-Cache — gespeicherte Key/Value-Vektoren vergangener Token; liegt im VRAM, wächst mit dem Kontext.
Autoregressiv — jedes Token entsteht aus allen vorherigen.
Prefill — Verarbeiten der Eingabe; rechenbegrenzt, schnell.
Generierung / Dekodierung — Schreiben der Antwort; bandbreitenbegrenzt, langsamer.
Temperature — wie mutig ausgewählt wird; 0 nimmt stets das wahrscheinlichste Token.
Seed — legt die Zufallsfolge fest; bei Temperature 0 wirkungslos.
Quantisierung — Gewichte mit reduzierter Genauigkeit ablegen; q4_K_M ist der übliche Kompromiss.
Flash Attention — speichersparende Aufmerksamkeit; gleiches Ergebnis, weniger Verkehr.
Auslagerung — Teile des Modells laufen auf der CPU, weil das VRAM nicht reicht; teuer.
VRAM — Speicher auf der Grafikkarte; die bindende Beschränkung für lokale Modelle.

Nichts davon setzt voraus, Transformer zu verstehen, um damit zu arbeiten. Aber zu wissen, welcher Regler auf welchen Engpass wirkt, macht aus „das Modell ist langsam“ eine Frage, die man tatsächlich beantworten kann.

Was diese Serie behandeln wird

Der Plan, in der Reihenfolge, in der ich ihn abarbeiten will:

Prompt Engineering — was eine Antwort wirklich verändert, was Folklore ist, und wie man beides auf der eigenen Maschine auseinanderhält.
Agent Engineering — was passiert, wenn ein Modell Werkzeuge, Gedächtnis und mehrere Schritte bekommt, und ab wann das aufhört, verlässlich zu sein.
Prompt-Optimierung — aus einem Prompt, der funktioniert, einen machen, der zuverlässig funktioniert; gemessen statt gefühlt.
Graph Engineering — Wissen so strukturieren, dass ein Modell es durchlaufen kann, statt daran zu raten. Für später in der Serie geplant.
Ein Second Brain, das ein Modell benutzen kann — wie ich Obsidian als Wissensbasis betreibe, die Mensch und Agent gleichermaßen lesen können, und was das von den Notizen verlangt. Ebenfalls später.

Parallel dazu laufen die Messungen selbst: Durchsatz, Kontextverhalten und wie sich dieselben Modelle auf unterschiedlicher Hardware schlagen. Diese Teile verweisen auf dieses Glossar, statt es zu wiederholen.

Widerspricht ein späterer Artikel etwas von hier, gewinnt der spätere — und ich sage es in beiden dazu. Das ist in diesem Projekt schon mehrfach vorgekommen, und so zu tun, als wäre es anders, würde die Zahlen nicht wertvoller machen, sondern billiger.