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 der Aufwärmlauf, die Wiederholung desselben Dokuments und die Vergleichsläufe mit YaRN unterhalb von 262k, die Kapitel 06 zeigt. 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,4 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 12,6 auf 8,1 GiB, und deshalb belegt der Pool für 396k weniger als der native.

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

Bis 192k ist Länge für dieses Modell kein Hindernis: über alle Messläufe bis dahin keine einzige falsche wertbare Antwort. Die 3 fehlenden Antworten liegen alle bei 245k, an der Spitze der nativen Reihe, verteilt auf 2 der 3 Fassungen des Wetterprotokolls.

Das Muster ist kein gleichmäßiger Verfall. Das Modell nennt einen echten Wert aus demselben Protokoll, nur aus der falschen Zeile: bei 245k und bei 990k eine Windspitze von 23 km/h statt 81, bei 594k die Sensorkennung der Nachbarzeile. Bei 396k liest es beide Werte richtig ab. Es verliert also nicht den Text, sondern die genaue Stelle darin.

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

Dahinter stehen ein Block von vier Messläufen in wechselnder Reihenfolge auf einem langen Wetterprotokoll von 4.993 Zeilen, dessen Wiederholungen dieselben Antworten geben, und ein Messlauf mit dem kurzen Wetterprotokoll im Wartungsjournal. Im langen Protokoll findet YaRN die eindeutige Kombination, die das Modell nativ als nicht vorhanden meldet. Im kurzen liest YaRN die Windspitze richtig ab, die nativ aus der falschen Zeile kommt, und zählt dafür eine Teilmenge falsch, die nativ stimmt.

Zwei Dokumente reichen nicht, um YaRN einen Vorteil zuzuschreiben. Sie reichen für den Schluss, dass YaRN nicht verursacht, dass das Modell über 262k schlechter nachschlägt: Bei gleicher Länge schlägt es mit YaRN mindestens so gut nach wie ohne.