Qwen3.8-Flash-Next auf dem HP ZBook Ultra G1a

01 · Setup und Speicher

Warum ein 180B-Modell auf einem Notebook überhaupt läuft

Ein Modell mit 176,9 Milliarden Parametern auf einem Gerät mit 128 GiB Arbeitsspeicher (125,1 GiB davon nutzbar), dessen dedizierter Grafikspeicher 0,5 GiB beträgt – das geht nur, weil drei Dinge zusammenkommen: die Bauart des Modells, die Speicherarchitektur der Plattform und das, was die Engine daraus macht.

Warum der Speicher die erste Frage ist

Bei einem Modell dieser Größe entscheidet der Speicher vor allem anderen. Er ist die harte Grenze: Was nicht hineinpasst, läuft nicht. Und was gerade eben hineinpasst, belegt das Gerät für die Dauer der Rechnung so weit, dass daneben nichts anderes mehr Platz hat – auf einem Notebook, das zugleich Arbeitsgerät ist, ist das der Unterschied zwischen brauchbar und blockiert.

Deshalb stehen hier zwei Angaben nebeneinander: wie viel Speicher im Betrieb gebunden war und auf welche Weise er gehalten wurde. Beides fällt bei diesen beiden Engines auseinander, und die zweite Angabe entscheidet darüber, wie die erste zu lesen ist.

Was der Betrieb an Speicher bindet

Ein Sensor erfasste während beider Läufe alle zwei Sekunden den Speicherstand. Zwei Begriffe aus der folgenden Tabelle sind dabei erklärungsbedürftig.

GTT steht für Graphics Translation Table und bezeichnet den Teil des Arbeitsspeichers, den der Grafiktreiber der GPU zugänglich macht: Seiten des Systemspeichers werden in den Adressraum der GPU eingeblendet, sodass dort ohne Umkopieren in dedizierten Grafikspeicher gelesen und gerechnet werden kann. Auf dieser Plattform ist das der Regelfall, nicht die Ausnahme – dediziert stehen nur 0,5 GiB zur Verfügung, die Obergrenze für die GTT setzt der Kernelparameter amdgpu.gttsize, hier 110 GiB. Was die Tabelle als GTT ausweist, ist also kein zusätzlicher Speicher, sondern der Anteil desselben Arbeitsspeichers, der zum Messzeitpunkt der GPU zugeteilt war.

MemAvailable ist die Schätzung des Kernels, wie viel Speicher einer neuen Anwendung noch zur Verfügung stünde – einschließlich dessen, was er dafür freiräumen könnte. Die Zeile „frei geblieben“ nennt den Tiefstand dieses Werts über den Lauf, also das, was dem übrigen System im ungünstigsten Moment blieb.

5.065 Messpunkte über den vollständigen halogen-Lauf. Für llama.cpp liegen 5.854 Punkte vor, die allerdings nur die letzten drei Aufgaben abdecken: Dieser Lauf wurde in zwei Sitzungen gefahren, und der Sensor lief in der zweiten. Es sind die drei Kontextaufgaben – der speicherintensivste Teil des Satzes.

Zwei Wege, dieselben Gewichte zu halten

Die unteren beiden Zeilen laden dazu ein, sie als Bedarfsangabe zu lesen. Das wären sie nur, wenn beide Engines den Speicher auf dieselbe Weise beanspruchten. Sie tun es nicht:

• llama.cpp legt die Gewichte mit -ngl 999 als GTT-Allokationen an – Gerätespeicher, der aus demselben Arbeitsspeicher stammt. Solche Seiten sind nicht rückholbar; sie senken MemAvailable in voller Höhe.
• halogen blendet den Checkpoint ein (mapped 124,1 GB). Dessen Seiten sind sauber und dateigestützt. Der Kernel führt sie als verfügbar, weil er sie jederzeit verwerfen und bei Bedarf erneut von der Platte lesen kann.

Im Protokoll der Engine ist das direkt ablesbar: Auf pinned 65,64 GiB folgt wenige Zeilen später host memory left for everything else: 81,1 GiB. Die gepinnten Seiten erscheinen im belegten Speicher also nicht.

Die Tabelle weist damit aus, wie viel Speicher das System als vergeben führt. Das ist die betriebsrelevante Größe – von ihr hängt ab, ob neben dem Modell noch gearbeitet werden kann. Eine Bedarfsangabe im Sinne von „so viel Speicher benötigt die Engine“ ist sie nicht, und ein Vergleich der beiden Spalten misst zu einem Teil die Buchführung des Kernels statt den Bedarf der Engine.

Die Rolle der SSD

Von 115,6 GiB Mapping sind 65,64 GiB festgepinnt; der Rest bleibt als Dateiseiten liegen und kann verdrängt werden. Damit wird die Platte Teil des Speicherpfades: Sie trägt den Kaltstart und fängt auf, was unter Speicherdruck ausgelagert wird. Erst diese Rückfallebene lässt einen Checkpoint dieser Größe auf einem Gerät mit 128 GiB überhaupt zu – und macht die Wahl einer schnellen SSD zu einer Entscheidung über die Startzeit, nicht nur über den Plattenplatz.

Wie groß dieser Unterschied ausfällt, zeigt der Startvorgang selbst. Liegt der Checkpoint noch im Page-Cache, sind die 65,64 GiB in 3,6 Sekunden fixiert – 19,4 GB/s, also gar kein Plattenzugriff. Liegt er nicht dort, liest die Engine ihn tatsächlich vom Laufwerk: 2,1 GB/s, aus 3,6 werden 33,2 Sekunden. Beide Werte stammen von derselben Maschine und demselben Checkpoint; verschieden ist nur der Weg, den die Daten nehmen.

Wie viel im Verlauf der Läufe nachgeladen wurde, weist diese Messung nicht aus: Der Sensor erfasste GPU-Leistung, Takt, Temperatur, GTT und MemAvailable, jedoch keine I/O-Zähler. Eine belastbare Aussage darüber verlangt einen eigenen Lauf mit Blockstatistik.

Die eigentliche Grenze ist das Generierungsbudget

Die Messung lief mit einem Kontextfenster von 134.400 Positionen; das Modell beherrscht 262.144. Auch dieses volle Fenster ist auf dem Gerät fahrbar. Der KV-Speicher kostet rund 28 KiB je Position – die gefahrenen Positionen belegen 3,7 GiB, die vollen 262.144 entsprechend 7,2 GiB. Mit einem Pool dieser Größe und demselben Generierungsbudget von 49.152 Token ist die Engine auf der ansonsten unbelasteten Maschine nach 18,9 Sekunden bereit und beantwortet den längsten Prompt des Aufgabensatzes, 68.801 Token, mit 1.005 Token/s Prompt-Verarbeitung; 76,3 GiB Arbeitsspeicher bleiben frei.

Begrenzend wirkt eine andere Größe: HALOGEN_MAX_TOK bestimmt nicht nur, wie lang eine Antwort werden darf, sondern bemisst zugleich die Prefill-Arena.

Der Engpass ist dabei nicht die Menge des Speichers, sondern seine Form. Die Engine braucht große zusammenhängende Blöcke; sind nur noch kleine vorhanden, verbringt sie den Start mit Kompaktierung. Bei 65.536 Token Budget bleiben nach dem Start 184 zusammenhängende 2-MiB-Blöcke bei 637 Kompaktierungsläufen allein für die Pool-Reservierung, und ein Prefill von 60 Token dauert dann 127 Sekunden statt 2,3. Der große KV-Pool wirkt in dieselbe Richtung, wenn auch schwächer: Mit 262.144 Positionen verbleiben 275 Blöcke bei 285 Kompaktierungsläufen.

Für die Messung fiel die Wahl deshalb auf 134.400 Positionen: Dieses Fenster deckt den längsten Prompt des Satzes samt vollem Budget ab und lässt der Arena den meisten zusammenhängenden Speicher. Wer den vollen Kontext braucht, bekommt ihn – und bezahlt ihn mit einem knapperen Start.

02 · Und im Vergleich

Dieselbe Maschine, dieselben Aufgaben, die andere Engine

Trefferquote

17 : 18 von 20

McNemar exakt p = 1,000 – kein messbarer Unterschied in der Fähigkeit.

Prompt-Verarbeitung

7,1 ×

126 gegen 886 Token/s bei 69.000 Token Prompt.

Dauer des Laufs

486 → 157 min

Dieselben zwanzig Aufgaben, hintereinander, ohne Fremdlast.

Wiederholbarkeit

0/18 : 9/9

Byteweise identische Antwortpaare auf dieselbe Frage bei Temperatur 0.

Was darunter folgt, ist diese Messung in neun Kapiteln: was gefragt wurde, was beide gelöst haben, wo die Zeit hingeht, wie sie an die Aufgaben herangehen – und was die Arbeit nicht zeigt.

03 · Was gemessen wurde

Zwanzig Aufgaben, drei Sorten, zwei Stapel

Zwölf Aufgaben aus den AIME-Wettbewerben 2024 und 2025 – ganzzahlige Lösung, maschinell prüfbar. Vier eigene Codeaufgaben, deren Antwort im rootlosen Sandkasten ohne Netz gegen Testfälle ausgeführt wird. Und vier eigene Kontextaufgaben über eine Messreihe von rund 69.000 Token, die der Prompt vollständig enthält.

Die eigenen Aufgaben sind die kontaminationsfreie Gegenprobe zu den öffentlichen AIME-Sätzen: Sie standen nirgends im Netz, als das Modell trainiert wurde. Beide Engines bekamen exakt dieselben Prompts in derselben Reihenfolge, Temperatur 0, Prompt-Cache aus, am 140-W-Netzteil im Leistungsprofil. Während eines Laufs lief nichts anderes auf der Maschine; der Runner bricht ab, wenn er einen Fremdprozess oder ein anderes Energieprofil vorfindet.

Spaltenkopf anklicken zum Sortieren

Ein Unterschied im Aufbau ist erwähnenswert, weil er sonst wie ein Vorteil aussähe: llama.cpp lief mit einem Token-Budget von 65.536, halogen mit 49.152 – bei halogen ist dieser Wert zugleich die Prefill-Arena und hätte bei 65.536 rund 33 GiB belegt. Ausgewertet wird deshalb auf dem gemeinsamen Budget 49.152. Die Umrechnung nimmt llama.cpp eine gelöste Aufgabe und gibt keiner Engine etwas dazu.

04 · Fähigkeit

In der Fähigkeit trennt sie nichts

17 gegen 18 gelöste Aufgaben von zwanzig. Gepaart ausgewertet: McNemar exakt, p = 1,000. Bei zwanzig Aufgaben und 3 unterschiedlich beantworteten ist ein realer Unterschied dieser Größe vom Zufall nicht zu trennen.

Wer eine der beiden Engines wählt, weil sie bessere Antworten gebe, wählt auf einer Grundlage, die diese Messung nicht hergibt. Das ist keine Schwäche des Vergleichs, sondern sein wichtigstes Ergebnis: Es räumt die Fähigkeitsfrage ab und macht den Weg frei für die Frage, die tatsächlich Unterschiede zeigt.

05 · Prompt-Verarbeitung

Der Vorsprung wächst mit der Länge des Prompts

Bei kurzen Fragen liest llama.cpp den Prompt mit 99, halogen mit 129 Token/s ein – spürbar, aber nicht dramatisch. Bei den vier Kontextaufgaben mit knapp 69.000 Token stehen 126 gegen 886 Token/s: Faktor 7,1 zugunsten von halogen.

Der Grund, warum das wichtig ist, steht nicht in der Zahl, sondern in der Arbeitsweise: Ein langer Prompt ist der Normalfall, sobald ein Modell eine Datei, ein Protokoll oder einen Verlauf lesen soll. Genau dort verlangt llama.cpp gut sieben Minuten für das, wofür halogen eine braucht – bevor das erste Zeichen der Antwort erscheint.

06 · Ausgabetempo

Der eine bricht im langen Kontext ein, der andere nicht

Bei kurzen Fragen erzeugt llama.cpp 21,1, halogen 39,3 Token/s – gut 1,9 × so schnell. Mit 69.000 Token Vorlauf fällt llama.cpp auf 9,7 Token/s – etwa die Hälfte seines eigenen Tempos. halogen bleibt bei 39,9.

Beides zusammen – langsamer eingelesen und danach langsamer geschrieben – ist der Grund, warum sich die Laufzeiten am Ende nicht um Prozente, sondern um einen Faktor unterscheiden.

07 · Warum das zählt

Der Unterschied ist Durchsatz, nicht Geschwätzigkeit

Ein schnellerer Lauf könnte auch schlicht ein kürzerer sein. Ist er nicht: llama.cpp erzeugte über die zwanzig Aufgaben 362.635 Token, halogen 339.134 – halogen also sogar 6,5 % weniger.

Beide denken damit ähnlich lang über dieselben Aufgaben nach. Der Zeitunterschied entsteht nicht daraus, dass einer sich kürzer fasst, sondern daraus, wie schnell dieselbe Menge Text durch die Maschine geht.

08 · Zusammengeführt

Sekunden je gelöster Aufgabe

Trefferquote und Tempo in eine Zahl gebracht: 1.714 gegen 524 Sekunden je gelöster Aufgabe. Faktor 3,3 – bei gleicher Trefferquote. Über den ganzen Lauf: 486 gegen 157 Minuten.

09 · Die blinde Gegenprobe

Sie lösen die Aufgaben nicht nur gleich oft, sondern gleich

Ein Prüfer, der nicht wusste, welche Engine welchen Text erzeugt hatte, bekam zu jeder der zwanzig Aufgaben beide vollständigen Lösungswege vorgelegt. Ergebnis: in 19 von 20 Fällen derselbe Ansatz – dieselbe Substitution, derselbe Satz, derselbe Algorithmus.

Auch das Prüfverhalten unterscheidet sich nicht: Wer nachrechnet, wer eine Probe macht, wer in eine Sackgasse läuft und wie er wieder herausfindet, verteilt sich über beide Stapel gleich. Das stützt den Befund aus Kapitel 04 von einer anderen Seite – nicht über die Trefferquote, sondern über den Weg dorthin.

10 · Der ungeplante Befund

Dieselbe Frage, dieselbe Antwort – oder eben nicht

Bei Temperatur 0 sollte dieselbe Anfrage dieselbe Antwort ergeben. llama.cpp tut das in keinem einzigen Fall: 0 von 18 Antwortpaaren über 18 Durchgänge in zwei Konfigurationen waren byteweise identisch. halogen in allen: 9 von 9, über Neustarts der Engine hinweg.

Bei einer Aufgabe lagen die Antworten auf dieselbe Frage zwischen 1.165 und 36.455 Token. Der naheliegende Verdächtige – llama.cpps Übernahme des Slot-Zustands zwischen Anfragen – wurde durch einen zweiten Durchlauf mit cache_prompt: false ausgeschlossen. Gleich war nur die erste Anfrage nach einem Serverstart, und die über zwei unabhängige Starts hinweg byteweise: Die Streuung sitzt im Zustand zwischen den Anfragen, nicht im Sampling.

Für die Praxis heißt das zweierlei. Erstens: Wer eine Antwort belegen oder eine Regression eingrenzen will, braucht die Wiederholbarkeit – und bekommt sie hier nur von einer der beiden Seiten. Zweitens, und unbequemer: Die llama.cpp-Zeiten in dieser Messung sind eine Stichprobe, keine Konstante. Sie sind mit einer breiten, hier nicht bezifferten Streuung zu lesen.

11 · Was diese Arbeit nicht zeigt

Vier Einschränkungen, die man mitlesen muss

• Kontamination. AIME 2024 und 2025 sind öffentlich und stehen wahrscheinlich in den Trainingsdaten. Für den Vergleich zweier Quantisierungen desselben Modells ist das tragbar – beide haben dieselbe Erinnerung –, als absolute Fähigkeitsaussage taugt es nicht. Die eigenen Code- und Kontextaufgaben sind die Gegenprobe.
• Ein Notebook mit 70 W GPU-Budget ist kein Desktop. Die absoluten Zahlen gelten für dieses Gerät an diesem Netzteil.
• Ein Durchgang je Engine – und bei llama.cpp ist das nachweislich eine Stichprobe, keine Konstante (Kapitel 10).
• Der Stand von heute ist nicht der Stand der Messung. Der rocmfpx-Fork ist seit dem Messtag dreizehn Commits weiter, mit einer Optimierung genau am hier gemessenen Schwachpunkt; halogen liegt bei 0.5.0. Nachgemessen wurde das nicht – diese Seite gilt für die Fassungen, die sie nennt.