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,3 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,5 auf 8,0 GiB, und deshalb belegt der Pool für 396k weniger als der native.

Bei 990k wird es eng. Nach dem Start blieben dem Rechner 19,0 bis 19,2 GiB für alles andere, und schon beim Reservieren des Pools musste der Kernel den Speicher je nach Start 378- bis 6.192-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 kaum ein Hindernis. Die zwei fehlenden Antworten liegen bei 128k und 245k, nicht gehäuft am oberen Ende: Bei 128k übersieht das Modell in einer Fassung beim Maximum die Bedingung des Standorts, bei 245k liest es in einer Fassung die Windspitze aus einer falschen Zeile.

Das Muster ist kein gleichmäßiger Verfall. Das Modell nennt echte Werte aus demselben Protokoll, nur aus der falschen Zeile: bei 396k und 594k die Sensorkennung der Nachbarzeile, bei 990k eine Windspitze von 23 km/h statt 81. Beim Maximum wählt es den Messpunkt mit der höchsten Windspitze, übersieht aber, dass er am falschen Standort liegt. Es verliert also nicht den Text, sondern die genaue Stelle darin.

Auch das Einlesen wird jenseits der Grenze teurer: bei 990k kostet jedes Token 26 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, und bestimmt den Abstand zweier Einträge richtig. Im kurzen sind dieselben wertbaren Aufgaben richtig; nur bei den zwei Rechenaufgaben tauschen nativ und YaRN die richtige Antwort.

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.