Das Kontextfenster, technisch
Warum langer Kontext teuer ist, was in der Mitte verlorengeht und wie sich die Grenze verschieben lässt, ohne das Modell neu zu trainieren.
Die Idee
Das Kontextfenster ist alles, was das Modell bei einer Anfrage gleichzeitig sehen kann: Systemanweisung, Verlauf, angehängte Dokumente und die bisherige Antwort. Gemessen wird es in Token, nicht in Zeichen oder Seiten.
Größenordnungen
| Fenster | Entspricht etwa |
|---|---|
| 8.000 Token | 20 bis 25 Seiten deutscher Text |
| 32.000 Token | 80 bis 100 Seiten |
| 128.000 Token | ein Buch mittlerer Länge |
| 1.000.000 Token | mehrere tausend Seiten |
Die Kosten
| Phase | Aufwand | Was das heißt |
|---|---|---|
| Prompt verarbeiten | quadratisch in der Länge | Doppelte Eingabe, vierfache Zeit bis zum ersten Token |
| Token erzeugen | linear in der Länge | Jedes neue Token liest den gesamten Cache |
| Speicher | linear in der Länge | Der Cache wächst mit jedem Token |
- Unveränderliche Teile an den Anfang, damit Prompt-Caching greift.
- Das Wichtigste an den Anfang und ans Ende, nicht in die Mitte.
- Statt alles hineinzugeben, gezielt abrufen. Zehn passende Abschnitte schlagen zweihundert beliebige.
- Die maximale Eingabelänge im Betrieb begrenzen, sonst ist Kapazität nicht planbar.
Kontext verlängern
Reine Interpolation verschlechtert die Auflösung bei kurzen Abständen, weil auch benachbarte Token zusammenrücken. NTK-bewusste Verfahren strecken deshalb nicht gleichmäßig, sondern hohe Frequenzen weniger als niedrige, und behalten damit die Genauigkeit im Nahbereich.
Das Mittelteilproblem messen
Der übliche Test besteht darin, eine eindeutig auffindbare Information an verschiedenen Stellen eines langen Kontexts zu platzieren und die Trefferquote über die Position aufzutragen. Typischer Verlauf bei einem Modell mit 128.000 Token Fenster:
| Position der Information | Trefferquote |
|---|---|
| erste 10 % | 95 bis 99 % |
| 25 % | 85 bis 92 % |
| 50 % | 60 bis 80 % |
| 75 % | 80 bis 90 % |
| letzte 10 % | 93 bis 98 % |
Die U-Form ist robust über Modelle hinweg. Sie ist der Grund, warum ein Abruf mit wenigen passenden Ausschnitten einem sehr langen Kontext praktisch überlegen ist.
Kosten- und Speicherrechnung
Für ein Modell mit 32 Schichten, h_kv = 1024 (gruppierte Abfragen), float16:
| Kontext | KV-Cache je Anfrage | Zeit bis zum ersten Token, relativ |
|---|---|---|
| 4.000 | 0,5 GB | 1 |
| 16.000 | 2,1 GB | 16 |
| 64.000 | 8,4 GB | 256 |
| 128.000 | 16,8 GB | 1.024 |
Die letzte Spalte ist der Grund, warum sehr lange Prompts in der Praxis Sekunden bis Minuten bis zur ersten Ausgabe brauchen. Wer diese Zeit nicht akzeptieren kann, muss abrufen statt anzuhängen. Siehe RAG, technisch.