Vier KV-Stufen, zwei Nächte: 139 Sekunden bis zum ersten Token — und was die Kompression nicht kostet

Zwischen 5.583 und 178.001 Prompt-Token steigt die Wartezeit von 5,0 auf 122,2 Sekunden — das ist die erwartbare Gerade, kein Knick. Der Prefill liegt über die ganze Leiter bei 1.360 bis 1.990 Token pro Sekunde, der Decode bei 42 bis 44 Token pro Sekunde und hängt damit sichtbar nicht an der Kontextlänge: Wer 200 Token Antwort braucht, wartet bei 262.144 Kontext nicht länger auf die Antwort als bei 8.192 — nur auf das erste Zeichen. Der Flaschenhals ist der Rand, nicht der Fluss.

Ein einziger Wert fällt aus der Reihe: 17,7 Token pro Sekunde Decode bei 8.192 Kontext. Das ist der erste Lauf des Nachts, als die Engine kalt war und die Expertenprofile noch lernten; die vier folgenden Zellen derselben Nacht liegen bei 43 bis 44. Ich lasse die Zeile stehen und markiere sie, statt sie zu streichen.

Befund 2: Die KV-Stufe verschiebt die Wartzeit um bis zu 64 Sekunden

Die Reihenfolge ist über alle drei Ausbaustufen dieselbe: q4_0 ist am schnellsten, fp16 am langsamsten. Bei KV-Anteil 0 trennen q4_0 (155,0 s) und fp16 (180,9 s) 26 Sekunden, bei 32 GiB Anteil 49 Sekunden (169,8 zu 218,8) — über alle Konfigurationen der größte Abstand, den eine KV-Entscheidung hier erzeugt. Der Prefill folgt derselben Ordnung: 1.677 gegen 1.150 Token pro Sekunde, ein Faktor von 1,46. Was die Wahl nicht kostet, steht im nächsten Abschnitt.

Erwartet hatte ich das Gegenteil beim KV-Anteil: mehr Cache im Grafikspeicher sollte schneller sein. Gemessen ist er bei int8 und k8v4 langsamer — 157,7 zu 182,8 Sekunden, 167,6 zu 191,0. Der plausible Grund steht in der Konfigurationsdatei: Der KV-Anteil wird neben Gewichten, Experten-Cache und Vision-Zweig in denselben Speicher gedrängt, und was dort fehlt, holt sich die Engine über den Peer-Reserve von der zweiten Karte. Weniger KV im VRAM heißt in dieser Maschine also mehr Platz für Experten — und Experten-Treffer zählen mehr als KV-Residenz. Bei q4_0 mit seinem kleinen Fußabdruck ist der Effekt kleiner (155,0 zu 169,8).

Befund 3: Vier KV-Stufen, vier Speicherbedarfe, dieselbe Trefferquote

Keine der vier KV-Stufen verliert die Sonde. Zehn Sonden in fünf Konfigurationen, zehn Treffer — bei 4-Bit-KV genauso wie bei unkomprimiertem fp16, bei 2,95 GiB Speicherbedarf genauso wie bei 10,82. Die Tempervorteile des q4_0 sind in dieser Maschine also nicht bezahlt. Wer 262.144 Token fährt, sollte q4_0 nehmen; dass die Flotte das seit dem Herbst tut, steht damit auf zwei Beinen.

Die eine verfehlte Sonde der Nacht gehört zur Geschichte: Im Vorlauf lief es die 90-Prozent-Tiefe mit einem Prompt von 262.133 Token — 11 Token unter dem harten Limit — und die Antwort kam ohne die Marke. Dieselbe Konfiguration traf in halber und oberster Tiefe bei 260.906 und 261.957 Token. Ich deute das nicht als Quanteneffekt, sondern als Rand: Der letzte Kilotonnen-Ring des Fensters ist unzuverlässig, Plane Puffer. Beim nächsten Nachlauf mit zwei Tiefen fand dieselbe Konfiguration beide Sonden.

Befund 4: Speicherplatz wirkt erst, wenn der KV-Cache kniet

Vor der zweiten Nachmessung nahm ich zwei kleine Modelle von den Karten — ein Entscheidungsmodell für den Router und ein Einbettungsmodell, zusammen rund 10 GB. Bei 65.536 Token änderte das messbar nichts: 34,02 zu 34,27 Sekunden bis zum ersten Token, 59,9 zu 57,3 Token pro Sekunde Decode — dieselbe Zelle in zwei Welten. Bei 262.144 Token waren es 182,8 zu 139,5 Sekunden (24 Prozent kürzer) und 42,0 zu 59,8 Token pro Sekunde Decode (42 Prozent schneller).

Der Mechanismus passt zu Befund 1: Solange der KV-Cache einer Sitzung in den freien Grafikspeicher passt, ist er unsichtbar. Passt er nicht mehr, wandert er in den Arbeitsspeicher, und jedes Token des langen Prompts liest über DDR5 statt über die Karte. Zwei Einschränkungen muss ich nennen: Die Vergleichspaares unterscheidet sich nicht nur durch die Modelle auf den Karten, sondern auch durch den KV-Anteil (32 GiB gegen 64 GiB) und durch die Tageszeit (Vormittag gegen vier Uhr nachts, die Telemetrie misst in beiden Fällen 79 bis 94 Prozent Probens mit Kartennutzung durch die Messung selbst). Ein sauberes Paar mit identischem Ausbau steht noch aus; die Richtung deckt sich mit dem, was die Engine über ihren reservierten Speicher ausweist.

Befund 5: Der Sweetspot heißt 131.072 Token mal acht Sitzungen

Die Zeile 131.072 × 8 ist die Antwort auf vierte Frage: Voll ausgereizt trägt die Maschine 1,05 Millionen Token im Speicher und liefert 78,0 Token pro Sekunde Gesamtdurchsatz bei Kurzabfragen, während die langen Kontexte arbeiten. Die Wartzeit pro Anfrage bleibt dabei konstant — von zwei auf acht Sitzungen steigt sie bei 131.072 Token von 66,25 auf 66,35 Sekunden, weil die Engine die Vorläufe durch die Warteschlange staffelt statt sie zu parallelisieren. Wer also mehrere lange Dokumente gleichzeitig verarbeitet, zahlt mit Durchsatz pro Sitzung, nicht mit Wartezeit.

Doppelzimmer sind der Grund, warum ich die KV-Frage überhaupt stelle: Der Router stellt pro Sitzung garantierte KV-Zellen bereit. Bei 131.072 Token und 2,71 GiB int8-KV je Sitzung sind acht Sitzungen 21,6 GiB — tragbar, weil der KV-Cache komprimiert ist und ein Teil im Arbeitsspeicher liegt. Unkomprimiert (fp16, 5,41 GiB je Sitzung) wären es 43,3 GiB, und bei vollen 262.144 Token pro Sitzung 86,6 GiB. Ohne komprimierten KV-Cache wäre dieses Raster nicht acht Sitzungen groß, sondern zwei.

Was ich nicht gemessen habe

Vier Lücken, jede mit Grund. Erstens fehlt die Qualitätsachse jenseits der Nadelsuche: Ich habe gefunden, aber nicht gerechnet — keine Klassifikations- oder Zusammenfassungsaufgabe über den vollen Kontext, keine perplexität. Die Nadeltest-Quote ist eine untere Schranke für Retrieval, kein Qualitätsbeweis. Zweitens die Slot-Achse: Die Engine hätte gern pro Sitzung garantierte Zellen; wie sich garantierte Zellen und gewechselte Sitzungsplatz-Zahl (ein Slot plus Warteschlange gegen vier Slots) zueinander verhalten, ist für diese Maschine offen. Drittens fehlt die Quantleiter-Arm der dichten 27B-Modelle bei langem Kontext — die Datei passte nicht in den freien Speicher der Modelldisk, und aufräumen wollte ich mitten in der Messnacht nicht. Viertens die Wiederholung des KV-Ausbau-Paares (32 gegen 64 GiB) unter identischer Kartenbelegung, die Befund 4 sauber machen würde.

Dazu drei Grenzen, die ich nicht wegredne: Alle Zellen stammen von einem Modell und einer Engine-Version; Mediane beruhen auf zwei Läufen pro Zelle, weil ein Nachlauf von 260.000 Prompt-Token gut zwei Minuten kostet und die Nacht 27 bis 53 Zellen tragen musste; und ein Teil der Zellen lief bei laufendem Produktivbetrieb, weil die Produktionsinstanz nicht abgeschaltet war — die Leerlauf-Tore vor jeder Zelle fangen das, was sie fangen können, und die Telemetrie weist es pro Zelle aus.

Was ich daraus mache

Vier Entscheidungen, alle ab sofort: Erstens bleibt der KV-Cache auf q4_0, die Messung hat den Verdacht in zwei Richtungen bestätigt (schnellste Stufe, keine Trefferquote verloren). Zweitens setze ich den interaktiven Arbeitspunkt auf 131.072 Token — 66 Sekunden Wartezeit sind an einem Schreibtisch noch erträglich, 139 bis 219 Sekunden sind es nicht; für Batch-Verarbeitung über mehrere Dokumente nehme ich acht Sitzungen und rechne mit 78 Token pro Sekunde Gesamtdurchsatz. Drittens plane ich das Kontextfenster nie ohne Puffer: Die eine verfehlte Sonde lag 11 Token unter dem Limit, also bestelle ich 245.000 statt 262.144. Viertens bleiben die kleinen Modelle von den Karten weg, die der große braucht — der Umzug hat die Wartzeit am Rand des Fensters um 24 Prozent gedrückt.

Der zweite Teil der Serie misst, was jenseits des Fensters liegt: denselben Rechner mit Rope-Stretching auf 512k und 1 Mio Token, die Nadeltest-Quote, die Antwortzeit eines vollen Durchlaufs — und was davon auf der GB10-Maschine anders läuft.

Artefakte

Die Messwerte als offene Dateien: alle Kennzahlen als JSON (Mediane je Zelle, Herkunftszeitstempel, Nadeltest-Einzelergebnisse) und die Zellen als CSV (Phase, KV-Stufe, Ausbau, Kontext, Sitzungen, Promptgröße, erstes Token, Prefill, Decode, Restdurchsatz, Kartenspitze, Nadelquote). Gebaut wird die Matrix mit einem Phasenläufer, der vor jeder Konfiguration die Engine-Datei umschreibt und danach zurückbaut; der Messer, die Nadelprüfung und der Auswerter liegen im selben Harness, das ich für den Patch-Vergleich gebaut habe.

Die fünf Grafiken in Originalgröße (1200 × 630): Vom ersten Token, nicht vom Speicher · Die Kurve steigt, aber sie bricht nicht · Was die KV-Stufe kostet und was sie bringt · Erst wenn der KV-Cache plaetzlich fehlt, zaehlt der Speicher · Der Punkt, den ich morgen fahre.