Langer Kontext auf dem HP ZBook Ultra G1a

Wer wissen will, ob ein Modell langen Kontext versteht, muss die Länge ändern und die Aufgabe festhalten. Gefragt wird deshalb immer nach demselben Wetterprotokoll: 651 Zeilen Messwerte von Wetterstationen, rund 32.000 Token, dazu acht Fragen mit eindeutiger Antwort. Auf die jeweilige Länge kommt der Text durch ein fachfremdes Wartungsjournal davor und dahinter, bei 990k mit 957.999 Token. Ändert sich das Ergebnis, kann es nur an der Länge liegen.

Bis 245k liefen je Stufe drei Fassungen des Wetterprotokolls mit anderen Zufallswerten, darüber eine: 21 Messläufe für das Verstehen. Für das Tempo zählen alle 54 gewerteten Messläufe dieser Tage, auch die mit anderen Dokumenten derselben Länge; wie schnell die Maschine einliest und antwortet, hängt an der Zahl der Token, nicht an ihrem Inhalt. Verworfen sind Aufwärmläufe, Wiederholungen desselben Dokuments und Vorläufe mit anderer Einstellung. Welcher Messlauf warum fehlt, steht in der Auswertung im Repository.

Für die Arbeit mit einem langen Dokument heißt das: Man wartet einmal, bei 245k 3,9 Minuten, und fragt danach im Gespräch weiter. Ein Agent, der seinen Verlauf fortschreibt, zahlt das Einlesen nur für das, was neu hinzukommt.

Oberhalb 262k lief halogen mit einem Generierungsbudget von 16.384 statt 32.768 Token. Das senkt den Arbeitsspeicher von 21,4 auf 12,5 GiB, und deshalb belegt der Pool für 396k weniger als der native.

Bei 990k wird es eng. Nach dem Start blieben dem Rechner 4,1 bis 5,6 GiB für alles andere, und schon beim Reservieren des Pools musste der Kernel den Speicher 534-mal verdichten; bei den kleineren Pools kein einziges Mal. Neben einem Pool dieser Größe sollte auf dem Notebook nichts Großes mehr laufen.

Innerhalb der nativen Grenze ist Länge für dieses Modell kein Hindernis. Die erste Fassung des Wetterprotokolls löst in jeder Stufe bis 245k alle acht Aufgaben, auch die zwei Rechenaufgaben; über alle 18 Messläufe fehlen 2 Antworten, verteilt auf 64k und 245k, nicht gehäuft am oberen Ende.

Das Muster ist kein gleichmäßiger Verfall. Das Modell nennt eine echte Sensorkennung aus demselben Protokoll, nur aus der falschen Zeile; bei 245k greift es dieselbe Zeile noch sicher. Es verliert also nicht den Text, sondern die genaue Stelle darin.

Auch das Einlesen wird jenseits der Grenze teurer: bei 990k kostet jedes Token 35 Prozent mehr Zeit als bei 245k. Die Ausgabe bleibt davon fast unberührt.

Zwei unabhängige Gegenproben stehen dahinter: ein Block von vier Messläufen in wechselnder Reihenfolge auf einem langen Wetterprotokoll von 4.993 Zeilen, und ein Messlauf mit dem kurzen Wetterprotokoll im Wartungsjournal, der genau an die native Reihe anschließt. Der Wortlaut der Antworten ändert sich mit YaRN, die Lösung nicht.

YaRN macht die Längen über 262k erst möglich, verursacht aber nicht, dass das Modell dort schlechter nachschlägt. Das liegt an der Länge selbst.