Lokale KI von Grund auf

Alles, was man braucht, um Tokens, VRAM, Agenten und Qwen Code zu verstehen — ohne Vorwissen

Die meisten Texte über lokale Sprachmodelle beginnen in der Mitte.

Sie sagen «zieh Qwen3.5», «setz num_ctx auf 128k», «der Prefill ist zu lang». Wer das zum ersten Mal liest, hat das Gefühl, eine fremde Sprache zu hören.

Dieser Artikel beginnt vor der Mitte.

Er erklärt die Begriffe so, dass danach die restliche Serie lesbar wird: der Nibbles-Prozessbericht, das Briefing-Paket, die settings.json, der Text über festgefahrene Agenten. Du musst dafür kein Studium mitbringen. Du musst nur bereit sein, ein paar Bilder im Kopf zu behalten.

Wenn ein Satz später lautet: «Das 27B-Modell in Q4 passt nicht in 16 GB, sobald der KV-Cache dazu kommt», sollst du ihn zerlegen können.

1. Was hier überhaupt passiert

Ein normales Programm ist eine Liste von Anweisungen, die ein Mensch geschrieben hat.

Wenn Taste rechts gedrückt:
    Schlange eins nach rechts bewegen

Der Computer führt genau das aus. Er erfindet nichts.

Ein Sprachmodell ist ein anderes Ding. Es hat keine Liste «wenn der User Snake sagt, schreibe diese Datei». Es hat Milliarden gelernter Zahlen. Aus einem Text, den es sieht, schätzt es, welches Stück Text als Nächstes wahrscheinlich ist. Dann das nächste Stück. Dann das nächste.

Das fühlt sich wie Denken an. Es ist Vorhersage.

Manchmal ist die Vorhersage guter Code. Manchmal ist sie eine erfundene Erfolgsmeldung. Beides kommt aus demselben Mechanismus. Deshalb braucht ein Coding-Agent äußere Kontrollen: Compiler, Tests, Git, eine Spezifikation. Das Modell selbst weiß nicht, ob es recht hat.

2. Training und Inferenz

Zwei Phasen darf man nicht verwechseln.

Training ist das teure Lernen. Ein Labor füttert das Modell mit enorm viel Text und passt die Zahlen so an, dass die Vorhersagen besser werden. Das machst du zu Hause in der Regel nicht.

Inferenz ist das Benutzen eines fertig trainierten Modells. Du gibst Text hinein, es kommt Text heraus. Genau das tut Ollama auf deinem Rechner.

Wenn jemand sagt «ich betreibe das Modell lokal», meint er Inferenz. Die Intelligenz wurde woanders gelernt. Du führst sie nur aus.

3. Tokens: die wahre Maßeinheit

Das Modell liest keine Wörter und keine Dateien.

Es liest Tokens.

Ein Token ist ein Brocken Text, den das Modell zählen kann: ein kurzes Wort, ein Wortteil, ein Satzzeichen, manchmal ein Leerzeichen. «Hallo» kann ein Token sein. Ein langes deutsches Kompositum wird oft in mehrere Tokens zerlegt. Programmcode und Fehlermeldungen brauchen typischerweise mehr Tokens als derselbe Gedanke in einfachem Englisch.

Grobe Faustregel:

1 Token    ≈ 4 Zeichen Englisch
1000 Tokens ≈ 750 englische Wörter

Für Deutsch und für Code eher etwas mehr Tokens pro Seite.

Alles, was das Modell «sieht» — Systemanweisung, Chatverlauf, Dateiinhalt, Tool-Ergebnis — wird vorher in Tokens zerlegt. Ein «Kontextfenster von 32k» heißt: etwa 32 000 solcher Brocken haben Platz, nicht 32 000 Wörter.

Wenn der Agent eine Datei «liest», kopiert das Werkzeug Text in diesen Token-Eimer. Die Datei auf der Festplatte bleibt. Nur eine Kopie landet im Fenster.

4. Prompt, Completion, Kontextfenster

Drei Wörter, die ständig durcheinandergeraten.

Der Prompt ist alles, was das Modell liest, bevor es schreibt: Anweisungen, bisheriger Chat, Werkzeugbeschreibungen, Dateiauszüge, deine letzte Nachricht.

Die Completion ist das, was es anschließend schreibt.

Das Kontextfenster ist die harte Obergrenze für Prompt plus Completion zusammen.

Kontextfenster
    ├── Prompt   (Eingabe)
    └── Completion (Ausgabe)

Ist das Fenster 32 768 Tokens groß und der Prompt schon 30 000, bleiben rund 2 700 Tokens für Denken und Antwort. Ist der Prompt größer als das Fenster, schneidet die Runtime ab oder lehnt die Anfrage ab.

Zwei Zahlen auf einer Modellkarte meinen oft Verschiedenes:

Nativer Kontext ist, wofür die Architektur gebaut oder nachträglich verlängert wurde. «256k nativ» heißt: theoretisch so weit.

Konfigurierter Kontext (num_ctx) ist, wie viel Speicher du dieses Mal reserviert hast. Auf einem Gaming-Rechner setzt du den fast immer kleiner als nativ, damit der Speicher reicht.

Der Agent-Client hat eine dritte Zahl: contextWindowSize. Die muss zur reservierten Zahl passen. Sonst glaubt der Agent, er hätte 128k, während Ollama nur 32k angelegt hat.

5. Parameter: was «7B» und «27B» bedeuten

Ein Modell besteht aus Milliarden kleiner Zahlen. Die heißen Parameter.

«7B» heißt etwa sieben Milliarden Parameter. «27B» etwa siebenundzwanzig Milliarden.

Mehr Parameter heißen grob: mehr Kapazität, mehr Dateigröße, mehr Rechenarbeit pro Token.

Das ist keine Garantie für «besser im Alltag». Ein kleineres Modell, das in den Grafikspeicher passt, kann einen Agenten flüssiger steuern als ein riesiges Modell, das ständig auf den Prozessor ausweicht.

Zwei Bauarten:

Ein dichtes Modell (dense) benutzt bei jedem Token praktisch alle Parameter. Qwen3.8 27B ist so gebaut. Jeder erzeugte Token zahlt den vollen Preis.

Ein Mixture of Experts (MoE) hat viele Parameter auf der Platte, schaltet pro Token aber nur einen Teil scharf. «8B-A1B» heißt: etwa 8 Milliarden insgesamt, etwa 1 Milliarde aktiv. Die Datei folgt der Gesamtgröße. Die Geschwindigkeit folgt oft dem aktiven Teil.

dichtes 27B     große Datei, teure Rechnung jeden Token
MoE 20B / 3B    große Datei, billigere Rechnung pro Token

Deshalb kann ein 20B-MoE sich schneller anfühlen als ein dichtes 14B — und trotzdem viel Speicher brauchen.

6. Quantisierung: warum Q4 kein anderes Modell ist

Hier sitzt das Wort, das die meisten googeln.

Beim Training werden Parameter oft als 16-Bit-Zahlen gespeichert. Das ist genau und fett. Eine 27B-Datei in voller Genauigkeit sprengt einen normalen Rechner.

Quantisierung speichert dieselben Parameter mit weniger Bits. Die Architektur bleibt. Der Tokenizer bleibt. Der Name bleibt. Nur das Zahlenformat wird grober.

Stell dir ein Foto vor.

Rohdatei aus der Kamera     sehr groß, jedes Detail
JPEG mittel                 viel kleiner, fast gleich
JPEG stark                  noch kleiner, Kanten weich

Q4, Q5, Q8 sind solche Stufen für Modellgewichte.

Q4_K_M     etwa 4 Bit pro Gewicht, üblicher Alltag
Q5 / Q6    dazwischen
Q8_0       8 Bit, näher am Original, größere Datei
BF16 / F16 fast volle Genauigkeit, oft zu groß

«Q4» ist also kein neues Modell. Es ist dasselbe Netz, billiger verpackt.

Der Preis: etwas weniger Präzision. Manche Antworten werden etwas dümmer, Tool-Aufrufe etwas unsauberer. Der Gewinn: die Datei passt in den Grafikspeicher.

Der Hugging-Face-Filter «6B bis 9B Parameter» sieht diesen Unterschied nicht. 9B in Q4 und 9B in Q8 haben dieselbe Parameterzahl und sehr verschiedenen Speicherbedarf.

7. Bits, Bytes, Gigabyte — nur so viel Mathematik

Ein Bit ist 0 oder 1.

Acht Bits sind ein Byte.

1024 Bytes      ≈ 1 KB
1024 KB         ≈ 1 MB
1024 MB         ≈ 1 GB

Unquantisiert braucht ein Parameter oft 2 Bytes (16 Bit). Dann gilt grob:

Parameterzahl × 2 Bytes ≈ Dateigröße
7 Milliarden × 2 ≈ 14 GB

Bei Q4 braucht ein Parameter im Schnitt etwa ein halbes Byte. Dieselbe 7B-Datei landet eher bei 4 bis 5 GB. Dazu kommt oft noch ein kleiner Aufschlag für Tabellen und, bei Bildmodellen, ein Projektor.

Du musst die Formel nicht auswendig können. Du musst nur merken:

Parameterzahl  ≠  Dateigröße
Dateigröße     ≠  belegter Grafikspeicher zur Laufzeit

Zur Laufzeit kommt der KV-Cache dazu. Davon handelt der nächste große Block.

8. CPU, GPU, RAM, VRAM

Vier Kästen, vier Jobs.

Die CPU ist der Alleskönner-Prozessor. Betriebssystem, Browser, Editor. Stark in Flexibilität, nicht dafür gebaut, Milliarden Multiplikationen parallel zu machen.

Die GPU ist die Grafikkarte. Viele kleine Rechenkerne. Genau das, was Inferenz will.

RAM ist der Arbeitsspeicher am Mainboard. Die CPU greift schnell darauf zu. 32 GB RAM heißen: viel Platz für Windows, Browser und ausgelagerte Modellteile.

VRAM ist der Speicher auf der Grafikkarte. 16 GB VRAM heißen: so viel darf das Modell plus Cache dort liegen, wenn alles schnell bleiben soll.

Lokal willst du Gewichte und Cache im VRAM.

Passen sie nicht, lagert die Runtime Schichten ins RAM aus und rechnet sie auf der CPU. Das heißt Offload.

Offload «funktioniert». Es ist viel langsamer. Prefill dauert plötzlich Minuten. Der Client denkt, die Verbindung sei tot.

Die Kontrolle ist nicht die Download-Größe. Die Kontrolle ist:

ollama ps

Du willst 100 % GPU. Jeder CPU-Anteil heißt: ein Teil pendelt durch den Systemspeicher.

9. Die wichtige Gleichung

VRAM ≈ Gewichte + Bild-Projektor + KV-Cache + Runtime-Reserve

Gewichte sind fast fest pro Quantisierung. Qwen3.5 9.7B in Q4 liegt bei etwa 6,6 GB. Qwen3.8 27B in Q4 bei etwa 17 GB. Schon die zweite Zahl ist auf einer 16-GB-Karte zu groß — noch bevor jemand chattet.

Der Projektor gehört zu Modellen, die Bilder lesen. Er ist ein zweites, kleineres Netz. Ein paar hundert MB bis ein paar GB extra.

Der KV-Cache wächst mit der Länge des Gesprächs und mit dem reservierten Fenster. Grobe Richtung bei einem 9.7B-Modell: etwa 1 GB Cache pro 32k Kontext. Das ist keine Naturkonstante, hilft aber beim Schätzen.

Die Runtime-Reserve ist Verwaltung, CUDA, Fragmentierung. Plane nie «Datei 15,9 GB, Karte 16 GB, passt genau».

Praktische Konsequenz auf 16 GB:

kleines Modell (5–8 GB)     langes Fenster oft noch 100 % GPU
20B-MoE (13 GB)             64k oft der sichere Default
27B (17 GB)                 Offload unvermeidlich, Fenster klein halten

«Das Modell kann 256k» und «meine Karte hält 256k» sind zwei Sätze. Nur der zweite interessiert den Alltag.

10. Attention und KV-Cache

Wenn das Modell ein Token liest, berechnet es intern «Schlüssel» und «Werte» (Keys und Values). Die braucht es, um später zu entscheiden, welche früheren Tokens für das nächste Wort wichtig sind. Dieser Mechanismus heißt Attention.

Ohne Speicher müsste bei jedem neuen Token der gesamte Prompt neu gelesen werden. Das wäre unerträglich langsam.

Deshalb legt die Runtime einen KV-Cache an: eine Tabelle der schon berechneten Keys und Values.

ohne Cache     jeder neue Token liest alles nochmal
mit Cache      nur das Neue wird gerechnet, Altes liegt bereit

Der Preis ist Speicher, der wächst mit:

Schichten × KV-Köpfe × Kopfgröße × Kontextlänge

Deshalb ändert PARAMETER num_ctx 65536 in einer Ollama-Modelfile nicht die heruntergeladene Gewichtsdatei. Es ändert, wie viel Cache reserviert wird.

Ein 27B-Modell kann im Picker als 32k, 64k, 96k, 128k erscheinen. Das sind keine vier Downloads. Das sind vier Reservierungen.

11. Prefill und Decode: die zwei Hälften einer Antwort

Eine Anfrage hat zwei Phasen.

Prefill liest den Prompt und baut den Cache. Du siehst noch keine Antwort. Bei 40 000 Tokens und 680 Tokens pro Sekunde sind das etwa eine Minute Stille, wenn nichts im Cache liegt. Bei einem Treffer auf den alten Anfang vielleicht zwanzig Sekunden.

Decode schreibt die Antwort, Token für Token. Das ist der sichtbare Stream.

Anfrage
  1. Prefill   still, teuer, Cache bauen
  2. Decode    sichtbarer Text

Cloud-Clients nehmen Stille oft als tote Leitung. Lokales Prefill ist still. Bricht der Client nach 18 Sekunden ab, steht im Ollama-Log sinngemäß:

Prompt wird verarbeitet … 90 %
HTTP 500
cancel task
truncated = 0

truncated = 0 heißt: Es wurde kein Antwort-Token erzeugt. Der Prompt war noch nicht fertig gelesen.

Prefix-Cache oder Checkpoint: Beginnt die nächste Anfrage mit denselben Tokens wie die letzte, kann Ollama einen Teil des Caches wiederherstellen. Ändert sich der Systemprompt, das Modell oder der Gesprächsast, ist der günstige Prefix weg. Dann fühlt sich «nur eine kurze Nachfrage» plötzlich langsam an.

12. Temperatur und Sampling

Das Modell liefert zu jedem nächsten Token Wahrscheinlichkeiten. Sampling würfelt daraus das konkrete Token.

Temperatur nahe 0: fast immer das wahrscheinlichste Token. Trocken, wiederholbar, gut für strikte Formate.

Höhere Temperatur: mehr Zufall. Lebendiger, unzuverlässiger.

top_p und top_k schneiden unwahrscheinliche Kandidaten weg.

Für Coding-Agenten willst du meist die Defaults des Modells oder eher konservative Werte. Wenn sowohl die Modelfile als auch der Client Temperatur setzen, weißt du bei schlechtem Output nicht, welche Seite gewonnen hat. Eine saubere Regel: Sampling in Ollama lassen, der Client schickt nur max_tokens.

max_tokens ist das Budget für die Ausgabe, nicht das Fenster. Ein Denkmodell kann dieses Budget mit einer inneren Spur verbrauchen und dann «aufhören», obwohl die Aufgabe offen ist.

13. Systemprompt, Chat, Tools

Ein Chat ist nicht nur «User gegen Modell».

Typische Rollen:

system     wer das Modell sein soll, welche Regeln gelten
user       du
assistant  das Modell
tool       Ergebnis eines Werkzeugs, wieder als Text im Fenster

Der Systemprompt frisst Tokens bei jedem Turn. Dazu kommen oft Memory-Dateien und Skill-Texte. Bei einem Coding-Agenten sind das leicht 15 000 Tokens, bevor du etwas tippst.

Deshalb ist ein 16k-Fenster für Qwen Code fast voll, bevor die Arbeit beginnt. 32k ist die erste Größe, die sich wie eine Sitzung anfühlt.

14. Was ein Agent ist — und was nicht

Ein Chatmodell antwortet mit Text.

Ein Coding-Agent ist ein Programm um das Modell herum:

Prompt schicken
    ↓
Text oder Werkzeugaufruf empfangen
    ↓
Werkzeug ausführen (Datei lesen, Patch, Shell)
    ↓
Ergebnis an den Prompt hängen
    ↓
wiederholen, bis das Modell aufhört

Diese Schleife heißt Tool-Loop.

Tools sind Funktionen, die das Modell beantragen darf. Das Modell führt sie nicht selbst aus. Der Host tut das: Qwen Code, Cursor, Claude Code.

Wenn das Modell schreibt «ich habe die Datei geändert», ohne dass ein Edit-Werkzeug erfolgreich war, hat es den Zustand des Repositories halluziniert. Genau das passiert lokalen Modellen häufig. Deshalb dürfen Fortschritt nur Compiler, Tests und git diff bezeugen — nicht der letzte Satz im Chat.

Thinking / Reasoning ist bei manchen Modellen eine Zwischen Spur vor der sichtbaren Antwort. Sie zählt gegen Fenster und gegen max_tokens.

Vision heißt: das Modell kann Bilder im Prompt lesen. Dafür braucht es den Projektor und Tokens für das Bild. Ein Screenshot einer IDE kann das Fenster hart treffen.

15. Warum der Agent «steht»

Vier Ursachen sehen in der Oberfläche gleich aus: die Runde endet, du musst weitermachen.

Freigabe. Der Host fragt vor Shell oder Edit. Das Modell wartet auf dich. In Qwen Code: approvalMode. yolo fragt nicht. Das ist Vertrauenspolitik, kein Modellfeature.

Turn-Limit. maxSessionTurns beendet den Lauf nach N Runden. -1 nimmt die Kappe weg.

Yield. Das Modell schreibt einen Absatz statt des nächsten Tool-Aufrufs. Die Runtime ist gesund. Das Modell hat intern «fertig» gesagt. Kleine lokale Modelle tun das oft.

Abgebrochenes Prefill. Der HTTP-Request stirbt in der stillen Phase. Timeouts auf Cloud-Defaults sind hier falsch. Für lokale Arbeit: Idle- und Lifetime-Timeouts auf 0, plus kürzere Prompts (/compress).

Kannst du die vier nicht unterscheiden, startest du immer dieselbe kaputte Sitzung neu.

16. Ollama: die Runtime

Ollama ist das lokale Betriebssystem für Modelle.

Es lädt eine gepackte Datei, hält sie im Speicher, und spricht HTTP.

Ein Tag ist ein Name: qwen3.5:latest, granite4.1:8b. Dein eigenes Tag aus einer Modelfile ist nur ein neuer Name auf denselben Gewichten plus anderen Parametern.

GGUF ist ein Dateiformat für solche Gewichte (oft quantisiert). Ollama kann GGUF importieren. Viele Bibliotheksmodelle kommen schon fertig.

Eine Modelfile ist ein kurzes Rezept:

FROM qwen3.8:latest
PARAMETER num_ctx 65536

ollama create qwen3.8-qwen-64k -f Modelfile

Kein zweiter 17-GB-Download. Nur eine andere Cache-Reservierung.

Wichtige Befehle:

ollama list          was liegt auf der Platte
ollama ps            was läuft, GPU-Anteil, Kontext
ollama show NAME     num_ctx, Tools, Thinking, Vision
ollama stop NAME     entladen

OLLAMA_HOST entscheidet, an welcher Adresse der Dienst lauscht. Standard ist nur dieser Rechner. 0.0.0.0:11434 öffnet das LAN. Dann brauchst du eine Firewall-Regel. Portweiterleitung am Router ist eine schlechte Idee.

Ollama liest nicht settings.json von Qwen Code. Die beiden Dateien müssen von Hand dieselbe Wahrheit erzählen.

17. Die OpenAI-kompatible Fläche

Die meisten Agenten sprechen nicht «Ollama-Dialekt».

Sie sprechen eine HTTP-API, die so tut wie OpenAI:

POST http://127.0.0.1:11434/v1/chat/completions

Im JSON stehen Modellname, Nachrichten, oft Werkzeugdefinitionen.

Ein API-Key ist bei lokalem Ollama meist Theater. Der Client verlangt ein Feld. Der Wert ollama reicht. Ollama prüft ihn nicht.

baseUrl muss zu OLLAMA_HOST passen. Steht Ollama nur auf localhost und der Client zeigt auf 192.168.1.127, kommt nichts an — oder umgekehrt.

18. Qwen Code und settings.json

Qwen Code ist der Agent-Host. Er besitzt Tools, Memory, Freigaben, Timeouts.

~/.qwen/settings.json ist der Client-Vertrag.

Ollamas Modelfile ist der Runtime-Vertrag.

Die Sitzung funktioniert, wenn id, Tag, Fenster und Timeouts einen Betriebspunkt beschreiben.

Wichtige Fallen in Version 4:

modelProviders.openai muss ein nacktes Array sein. Die Form { protocol, models: [...] } wird still ignoriert. Die Datei ist gültiges JSON. Der Picker ist leer.

model.name muss exakt einer Provider-id gleichen, inklusive :latest.

contextWindowSize muss num_ctx gleichen.

samplingParams am besten nur max_tokens. Rest in Ollama.

Timeouts für stilles Prefill gehören in die Umgebung:

QWEN_CODE_API_TIMEOUT_MS=0
QWEN_STREAM_IDLE_TIMEOUT_MS=0
QWEN_STREAM_MAX_LIFETIME_MS=0

generationConfig.timeout ist ein anderes Rad: wie lange ein HTTP-Request insgesamt leben darf. 600 000 ms (10 Minuten) ist für lokale 27B-Läufe sinnvoll.

settings.env setzt nur Variablen, die noch nicht existieren. ComSpec existiert unter Windows immer. Deshalb kannst du die Shell nicht allein über diese Datei auf PowerShell zwingen.

Die Datei darf Kommentare enthalten (JSONC). Speichert die App sie selbst, können Kommentare verschwinden.

19. Die Shell ist nicht «dein Terminal»

Das Shell-Werkzeug startet einen Prozess mit einem bestimmten Programm.

Unter Windows ist das oft cmd.exe, gewählt über ComSpec.

cmd.exe kennt kein head, kein grep, kein Select-String.

head          Unix / Git Bash / WSL
Select-String PowerShell
findstr       cmd.exe

Die Meldung

Der Befehl "..." ist entweder falsch geschrieben oder konnte nicht gefunden werden.

kommt von cmd.exe.

Das Modell «kann kein Windows». Es wurde mit Unix-Beispielen gefüttert. Ohne eine harte Anweisung (QWEN.md) wiederholt es head und /tmp.

ComSpec global auf pwsh zu setzen, ist gefährlich. Windows startet .cmd-Starter selbst über ComSpec. Dann hängt qwen.cmd.

20. Edit-Werkzeuge und «Datei nicht gelesen»

Viele Agenten dürfen eine Datei nur patchen, wenn sie sie in dieser Sitzung schon gelesen haben.

Die Fehlermeldung

File ... has not been read in this session

heißt nicht, dass old_string nicht passt. Sie heißt: der Host verweigert den Patch.

Richtige Reihenfolge:

1. Datei lesen
2. old_string exakt aus diesem Lesen
3. erst dann editieren

Denselben Edit nach der Meldung nochmal zu schicken, ist verschwendete Arbeit.

Ein fehlgeschlagener Tool-Aufruf ist kein Fortschritt. Wenn der Agent danach «Milestone 2 erledigt» schreibt, hat er den Repo-Zustand erfunden.

21. Compiler, Tests, Git: die Außenwelt, die recht hat

Das Modell kann nicht zuverlässig unterscheiden:

bereits bewiesen
gerade kaputt
noch gar nicht gebaut

Deshalb lagert man die Wahrheit aus.

Der Compiler (tsc --noEmit) prüft: Ist das überhaupt TypeScript? Ungültige Syntax wie read-only grow(...) fällt sofort auf.

Ein Test ist eine kleine, automatische Behauptung:

Gegeben: Schlange auf (10,10), Richtung rechts
Wenn:    ein Tick
Dann:    Kopf ist (11,10)

TDD dreht die Reihenfolge: erst der fehlschlagende Test (rot), dann der kleinste Code (grün), dann die ganze Suite (Regression).

Ein Agent «repariert» einen roten Test auf zwei Wegen. Den richtigen: Produktionscode ändern. Den falschen: den Test weichspülen. Deshalb gelten grüne Acceptance-Tests als unantastbare Wächter. Löschen, Skippen, Abschwächen ist verboten.

Git friert einen bewiesenen Stand ein. Kleine Commits nach kleinen Beweisen. Dann kann ein späterer Irrweg nicht still drei gute Schritte zerlegen.

Determinismus: Math.random() und echte Uhrzeit machen Tests unmöglich reproduzierbar. Zufall und Zeit müssen einschleusbar sein (RandomSource, Ticks). Sonst ist «der Test ist rot» kein Signal, sondern Wetter.

22. Das Briefing-Paket: das Modell vergisst das Projekt

Ein Frontier-Modell in der Cloud rekonstruiert viel aus dem Repo.

Ein lokales 9B- oder 27B-Modell nicht.

Ohne Dateien im Wurzelverzeichnis passiert typischerweise:

Regeln aus kaputtem Code ableiten
Aufgabe aufblasen
Teilmenge grüner Tests als fertig verkaufen
STATUS-Datei als Werbung schreiben
nächste Sitzung glaubt die Werbung

Fünf Dateien unterbrechen das:

QWEN.md     wie gearbeitet werden darf
SPEC.md     was das Produkt tun muss
TASK.md     was jetzt erlaubt ist, inkl. STOP
STATE.md    was wahr ist — nur nach echten Commands
README.md   Startprompt für die nächste Sitzung

SPEC.md gewinnt gegen den Code.

TASK.md ist ein Auftrag, keine Roadmap.

STATE.md ist ein Notizbuch, keine Pressemitteilung. Häkchen sind kein Beweis. Der letzte erfolgreiche Befehl ist der Beweis.

Widersprechen sich TASK.md («Snake stabilisieren, aufhören») und STATE.md («Milestone 8 fertig»), glaubst du den Tests, nicht der Statusdatei.

23. Ein Bild für den ganzen Stapel

du
  → Coding-Agent (Tools, Memory, Freigaben, Timeouts)
      → HTTP, OpenAI-kompatibel
          → Ollama
              → Gewichte (quantisiert)
              → KV-Cache (Größe = num_ctx)
              → GPU wenn es passt, sonst CPU-Offload

Jeder Pfeil kann allein sterben.

Das Modell kann gut sein, und der Request stirbt im Prefill.

Die GPU kann leer sein, und der Agent wartet auf «Darf ich bauen?».

Das Fenster kann riesig sein und trotzdem unbrauchbar, wenn die ersten 17k Tokens nur Overhead sind.

Das Repo kann Tests haben, und der Agent erklärt sie für grün, ohne sie auszuführen.

Sobald diese Sätze selbstverständlich sind, ist der Rest Konfiguration und Disziplin.

24. Mini-Glossar zum Nachschlagen

25. Wie du das übst, ohne zwanzig Modelle zu sammeln

Nimm ein kleines Modell.

ollama run irgendetwas-kleines

Schreib einen Satz. Merke, wie schnell das erste Wort kommt.

Dann:

ollama ps

Steht dort 100 % GPU?

Erhöhe num_ctx. Sinkt der GPU-Anteil? Dann hast du den Cache gesehen.

Schick einen sehr langen Prompt. Die Pause vor dem ersten Wort ist Prefill.

Öffne den Agenten. Wenn es /context gibt: Sieh, wie voll das Fenster schon ist, bevor du sprichst.

Lies danach eine Modellkarte noch einmal. «27B», «Q4_K_M», «256k», «tools», «thinking» sollten jetzt jeweils auf eine konkrete Kostenstelle zeigen.

26. Wohin danach

Dieser Text ist das Wörterbuch.

Die anderen Beiträge sind die Anwendung:

• Vom «Baue Nibbles nach» zum kontrollierten Prozess — warum Autonomie ohne Beweise den Fortschritt zerlegt.
• The Local Agent Does Not Remember the Project — die fünf Dateien im Repo.
• settings.json Is the Client. The Modelfile Is the Runtime. — der Vertrag zwischen Qwen Code und Ollama.
• The Coding Agent Did Not Stall. The Runtime Did. — VRAM, Varianten, Prefill-500, cmd.exe.

Du musst nicht alles auf einmal können.

Du musst die Teile benennen können, die Speicher, Zeit und Tokens ausgeben.

Dann wird «einfach lokal laufen lassen» eine Reihe von Entscheidungen — und kein Hoffnungssatz.

Fazit

Ein Sprachmodell sagt das nächste Token voraus. Es führt kein Programm aus und es prüft nicht, ob das Repository wirklich geändert wurde.

Quantisierung macht dasselbe n Netz kleiner, indem es Zahlen gröber speichert. VRAM hält Gewichte plus Cache. Der Cache wächst mit dem Fenster. Prefill ist die stille Hälfte. Der Agent ist eine Werkzeugschleife um das Modell. Ollama ist die Runtime. settings.json ist der Client. Tests, Compiler und Git sind die Instanzen, die recht haben dürfen.

Wer diese Sätze halten kann, kann die Restserie lesen.

Wer sie nicht halten kann, wird an jedem zweiten Log «GPU 61 % / CPU 39 %» wieder von vorn anfangen.

Das ist kein Makel.

Das ist der Stoff, den dieser Artikel tragen soll.