#18 · Zehn Karten, über 100 tok/s: das Team arbeitet jetzt komplett auf dem großen Qwen

Seit einigen Wochen arbeiten fünf bis sechs Entwickler bei uns den ganzen Tag gegen ein einziges Modell: Qwen 3.8 Flash Next, verteilt über alle zehn RTX 3090 unseres Rigs. Das kleine 27B, bis dahin unser Arbeitspferd im Tagesgeschäft, haben wir dafür vorerst komplett abgeschaltet.

Der Eindruck nach diesen Wochen ist wirklich gut. Das große Modell ist merklich klüger als das 27B, und am deutlichsten wird das beim Reviewen von Code. Dazu gehört aber auch die ehrliche Einordnung: An die großen Frontier-Modelle reicht es nicht heran. Für unsere Coding-Pipelines reicht es.

Der Betrieb trägt das überraschend gelassen. Wir fahren ein Kontextfenster von 524.288 Token — möglich wird das durch YaRN, ein Verfahren, das die Positionskodierung streckt und dem Modell ein größeres Fenster gibt, als es trainiert wurde. Die Inferenz-Engine vLLM bewältigt das parallele Arbeiten mehrerer Entwickler ausgezeichnet, und selbst bei großem Kontext wird das Modell kaum langsamer: Über 100 tok/s bei 100.000 Token Kontext sind im Alltag spürbar angenehm. Der gemeinsame Zwischenspeicher, aus dem sich alle laufenden Sitzungen bedienen, liegt jenseits von anderthalb Millionen Token.

Zwei Dinge haben sich gegenüber dem Stand aus #17 geändert. Erstens fahren wir eine Mischung aus zwei Arten von Parallelität. Je zwei Karten teilen sich die einzelnen Gewichtsmatrizen des Modells, das nennt sich Tensor-Parallelität. Fünf solcher Kartenpaare hintereinander teilen sich dann die 48 Schichten, und das ist Pipeline-Parallelität. Zweitens haben wir einen Befund aus dem vorigen Artikel kassiert: den Satz, mehr Karten machten das Modell langsamer. Der stimmte, solange eine Karte im falschen Steckplatz saß.

Was jetzt läuft

Der Endstand: alle zehn Karten, zwei Karten je Tensor-Paar und fünf Pipeline-Stufen, die Schichten im Verhältnis 11/10/10/10/7 verteilt, dazu ein selbst gepatchtes Container-Abbild und spekulatives Dekodieren mit vier Entwurfstoken. Das spekulative Dekodieren war schon in #17 Thema: Das Modell bringt einen kleinen Vorhersagekopf mit, der mehrere Token auf einmal vorschlägt, und das große Modell prüft diesen Entwurf in einem Durchgang.

Kontextpool nennen wir hier den Zwischenspeicher, in dem der Dienst den bereits gelesenen Kontext aller gleichzeitig laufenden Sitzungen hält. Er ist die eigentliche Kapazitätsgrenze im Mehrbenutzerbetrieb, nicht das Kontextfenster einer einzelnen Sitzung. Das Einlesen des Prompts, im Folgenden das Vorfüllen, ist dabei ein eigener Arbeitsschritt mit eigener Geschwindigkeit; er läuft vor dem ersten ausgegebenen Token.

Gegenüber dem Stand des vorigen Artikels ist das der 4,2-fache gemeldete Pool bei 34 Prozent mehr Durchsatz. Nach der tatsächlich gemessenen Kapazität reicht er für etwa 15 Sitzungen mit je 130.000 Token oder knapp vier Sitzungen mit je 500.000. Warum gemeldete und gemessene Zahl so weit auseinanderliegen, ist eine eigene Geschichte und steht weiter unten.

„Mehr Karten machen es langsamer“ — so stimmt es nicht mehr

In #17 steht als Befund, dass zusätzliche Karten den Durchsatz drücken: acht Karten langsamer als vier, zehn langsamer als acht. Inzwischen laufen alle zehn und liefern mehr als jeder frühere Aufbau. Die Auflösung hat zwei Teile, und der zweite ist unangenehmer.

Der erste Teil ist die Art der Parallelität. Die alte Aussage galt für Tensor-Parallelität, also für den Fall, dass sich alle beteiligten Karten jede einzelne Gewichtsmatrix teilen und nach jeder Teilrechnung ihre Zwischenergebnisse abgleichen müssen. Bei fünf Pipeline-Stufen verteilt sich dieses Problem: Ein langsames Kartenpaar trägt nur noch ein Fünftel der Schichten statt eines Drittels, und die Abgleiche innerhalb eines Paars sind kurz.

Der zweite Teil: Eine Karte steckte im falschen Steckplatz. Unser Board hat zwei CPU-Sockel. Neun der zehn Karten hingen an der zweiten CPU, eine einzige an der ersten; dass sie dort weg sollte, stand seit dem Umbau auf unserer Liste, nur war der Preis nie gemessen. Ausgerechnet diese Karte bildete im Sechs-Karten-Aufbau mit ihrer Nachbarin das erste Tensor-Paar — und Tensor-Parallelität synchronisiert nach jeder Teilmatrix. Jeder dieser Abgleiche lief damit dauerhaft über die Sockelgrenze, also über die Verbindung zwischen den beiden CPUs. Das System selbst bewertet diesen Weg mit dem Abstandsmaß 32 gegenüber 10 innerhalb eines Sockels.

Die Gegenprobe war billig: gleicher Aufbau, gleiche Konfiguration, nur ein anderer Kartensatz, dessen sechs Karten alle an derselben CPU hängen. Der Kurzlauf stieg von 70,93 auf 99,21 tok/s, also um 40 Prozent. Bei 100.000 Token Kontext ging es von 83,86 auf 98,97 tok/s, plus 18 Prozent. Sämtliche Messwerte des vorigen Artikels sind damit gegen einen benachteiligten Aufbau erhoben worden.

Die letzte Zeile ist der Grund, warum wir reine Tensor-Parallelität über acht Karten nicht fahren. Die Generierung sieht brauchbar aus, das Vorfüllen bricht um den Faktor 5,5 ein: Ohne NVLink läuft jeder Abgleich über PCIe und den Hauptspeicher, und beim Einlesen eines langen Prompts gibt es sehr viele davon. Dazu kommt eine Eigenheit des Modells, die in #17 schon die Kartenzahl bestimmt hat: Für den Kontext-Zwischenspeicher hat es nur zwei Köpfe, also zwei parallele Teilrechnungen, über die sich dieser Speicher verteilen ließe. Auf acht Karten lassen sich zwei nicht aufteilen, also wird der Speicher vervielfacht statt geteilt, und der Pool fällt entsprechend.

Dann haben wir die Karte tatsächlich umgesteckt, und die Ehrlichkeit verlangt den Nachtrag: Bei zehn Karten und gleicher Schichtverteilung brachte die Sockel-Lokalität nur noch sechs Prozent bei 100.000 Token, von 103,63 auf 109,92 tok/s. Im Kurzlauf sank der Median sogar von 98,99 auf 91,02 — bei einem Mittelwert von 105,77 im Referenzlauf streuen die Kurzlaufwerte zu stark, um Unterschiede dieser Größe zu belegen. Die 40 Prozent aus dem Sechs-Karten-Versuch übertragen sich jedenfalls nicht. Bei fünf Stufen trug das benachteiligte Paar nur noch gut neun von 48 Schichten statt sechzehn, und damit fiel es kaum mehr ins Gewicht. Der Fund war trotzdem richtig; er war nur zu dem Zeitpunkt, als wir ihn umsetzen konnten, schon halb entschärft.

Die Schichtverteilung ist der größere Hebel

Bei fünf Pipeline-Stufen ist frei wählbar, wie viele der 48 Schichten jede Stufe trägt. Wir haben vier Verteilungen gemessen, alle nach dem Umstecken, alle mit zehn Karten und sonst gleicher Konfiguration.

Die gleichmäßige Verteilung, die die Engine selbst vorschlägt, liefert den kleinsten Pool und beim Kurzlauf das niedrigste Tempo. Den größten Pool und gleichzeitig den höchsten Durchsatz liefert eine leicht schiefe Verteilung mit elf Schichten auf der ersten und sieben auf der letzten Stufe.

Die Mechanik dahinter ist unintuitiv, aber einfach. Der Dienst verwaltet den Kontext in Blöcken fester Größe, und alle fünf Stufen müssen dieselbe Anzahl dieser Blöcke halten; jede speichert darin aber nur den Kontext ihrer eigenen Schichten. Die Karte mit dem wenigsten freien Speicher setzt damit das Maß für alle zehn, und freier Speicher oberhalb dieses Engpasses ist strukturell unerreichbar. Die letzte Stufe trägt zusätzlich die Ausgabeschicht des Modells und ist deshalb fast immer die engste — sie braucht drei bis vier Schichten weniger als die anderen, damit sie nicht alle übrigen ausbremst. Im besten der gemessenen Fälle bleiben so 28,3 von 240 GiB Grafikspeicher ungenutzt, davon rund 16 GiB als Arbeitsreserve, die man nicht antasten darf.

Genau an dieser Reserve endet die Optimierung. Die Verteilung 11/11/11/11/4 hat den Puffer, den die Karten für ihre Abstimmung brauchen, so weit gedrückt, dass der Start mit Speichermangel abbrach — oder, schlimmer, erst nach Stunden Dauerlast. Unter etwa 1,6 GiB freiem Grafikspeicher auf der engsten Karte wird es unsicher. Das ist keine theoretische Grenze: Eine der früheren Verteilungen lief erst eine ganze Nacht durch und brach dann mit Speichermangel auf einer Karte ab.

Der Pool ist kleiner, als der Server meldet

Der Dienst meldet beim Start 3.334.471 Token Kontextpool. Diese Zahl taugt nicht für die Planung, und das ist der Befund, der uns am meisten überrascht hat. Eine Kontrollmessung mit einem einzelnen langen Prompt zeigt es:

Prompt mit 362.948 Token
belegt vom gemeldeten Pool:  18,61 %
rechnerisch zu erwarten:     10,88 %

362.948 / 0,1861  =  rund 1.950.000 Token tatsächliche Kapazität
gemeldet werden    3.334.471  —  ein Aufschlag von rund 71 Prozent

Die Ursache liegt in der Architektur des Modells. 36 seiner 48 Schichten sind rekurrent: Sie führen einen Zustand mit, den das jeweils nächste Token braucht. Dieser Zustand wird alle 1.616 Token gesichert, damit der Dienst an einer Sitzung weiterarbeiten kann, ohne alles neu zu rechnen. Die Sicherungspunkte belegen denselben Speicher wie der Kontext-Zwischenspeicher — bei einem Prompt von 363.000 Token sind das rund 225 Punkte je Sitzung. In der gemeldeten Poolgröße tauchen sie nicht auf, denn die zählt allein den Zwischenspeicher der übrigen zwölf Schichten, die klassische Aufmerksamkeit rechnen.

Für die Kapazitätsplanung gilt die rechte Spalte. Praktisch heißt das: Wer die Anzeige für die Wahrheit nimmt, läuft bei etwa 60 Prozent angezeigter Belegung in die Verdrängung, weil der Speicher dann tatsächlich voll ist und der Dienst beginnt, Kontext hinauszuwerfen. Die Einschränkung gehört dazu: Das ist eine Messung bei einer Kontextlänge. Dass der Aufschlag je Token konstant ist, ist plausibel und unbelegt.

Der Zerfall in ein einziges Wort

Parallel zu diesen Messungen lief ein Fehler mit, der den Betrieb härter traf als jede fehlende Kapazität. Sitzungen kippten reproduzierbar in die endlose Wiederholung eines einzigen Tokens. Es war immer dasselbe Token, das englische Wort „duct“. Danach füllte das Modell sein ganzes Ausgabebudget mit diesem Wort und endete am Token-Limit.

Belegt haben wir das an drei Fällen aus zwei exportierten Sitzungen: Zerfall nach 0 Token bei 14.623 Token Kontext, nach 303 Token bei 75.593 und nach 24 Token bei 108.256. Der Fall mit null generierten Token ist der aufschlussreichste — da war nichts, was man als Verrennen in eine lange Denkkette deuten könnte. Das ist kein Überdenken, sondern ein zerstörter Zustand.

Die Reproduktionsbedingung haben wir ausgemessen, und sie passt genau zum Produktivbetrieb:

• Einzeln, bei rund 100.000 Token Kontext: 24 Läufe, kein einziger Zerfall.
• Vier gleichzeitig, gleicher Kontext: acht Läufe, ein Zerfall.

Die Ursache war ein Fehler in der Engine, behoben in einem Beitrag vom 5. September; unser Container-Abbild war vier Tage älter. Laut dem Fehlerbericht braucht es dafür mindestens zwei gleichzeitig eingelesene Prompts und aktives spekulatives Dekodieren — beides ist bei uns der Normalfall, sobald mehr als ein Entwickler arbeitet. Für den Betrieb gibt es ein brauchbares Diagnosemerkmal: Bei betroffenen Anfragen fällt die Akzeptanzrate der Spekulation, also der Anteil der angenommenen Entwurfstoken, auf exakt null.

Damit klärt sich ein offener Punkt aus der Betriebsstatistik. 36 von 382 Anfragen waren seinerzeit ins Token-Limit gelaufen statt regulär zu enden, und wir hatten das einem zu knapp gesetzten Ausgabebudget auf Client-Seite zugeschrieben. Mit hoher Wahrscheinlichkeit waren es diese Zerfälle: Auf einer Instanz mit ausschließlich seriellem Verkehr endeten anschließend 139 von 139 Anfragen regulär, keine einzige am Limit.

Das gepatchte Abbild

Der Fix war vorhanden, nur nicht nutzbar. Das neue Abbild startete bei uns gar nicht — ein bekannter Fehler bei hybriden Modellen unter Pipeline-Parallelität: Eine Stufe kann für eine Gruppe von Cache-Schichten überhaupt keine Schicht besitzen, und diese leere Gruppe bringt die Speicherzuteilung beim Start zum Absturz. Die Lösung waren zwei Zeilen aus einem noch offenen Beitrag, die wir in den Container hineinkopiert und als eigene Abbild-Schicht gesichert haben.

Dabei liegt eine Falle, auf die man erst einmal kommen muss: Beim Sichern übernimmt das Werkzeug den Startbefehl des Hilfscontainers, in dem gepatcht wurde. Ohne ausdrückliches Setzen bleibt dort der Schlafbefehl stehen, mit dem man den Hilfscontainer offen gehalten hat. Das fertige Abbild startet dann nicht den Server, beendet sich sofort und schreibt keine einzige Logzeile. Schon in #17 war der lehrreichste Startfehler einer ohne jede Fehlermeldung; hier war die aussagekräftigste Logzeile wieder die, die fehlte.

Das gepatchte Abbild bringt noch eine Änderung mit, die man beim Hauptspeicher einplanen muss. Die große Nachschlagetabelle des Modells, die bei uns im Arbeitsspeicher des Rechners liegt statt auf den Karten, braucht darin keinen eigenen Hilfsprozess mehr. Das macht einen Fehlerpfad überflüssig, kostet aber rund 131 GiB gemeinsam genutzten Hauptspeicher statt bisher 93 GiB privater.

Tempo gegen Platz

Das spekulative Dekodieren ist der größte Einzelposten im Kontextpool, und zwar auf eine Weise, die man dem Schalter nicht ansieht. Bei identisch zugeteiltem Grafikspeicher gemessen:

Die Spekulation halbiert den Pool, weil die Tabelle der Kontextblöcke mit vier Entwurfstoken fünf Spalten je Sitzung braucht statt einer — der Dienst reserviert die Plätze für den Entwurf, ob er genutzt wird oder nicht. Das ist ein echter Zielkonflikt und kein Fehler: Tempo gegen Platz, in diesem Fall Faktor zwei gegen 67 Prozent mehr Durchsatz bei langem Kontext. Wir haben uns für Tempo entschieden.

Die Pipeline selbst skaliert mit der Zahl gleichzeitiger Anfragen nur schwach. In einer Messreihe ohne Spekulation auf sechs Karten lieferten drei gleichzeitige Anfragen 104,4 tok/s zusammen, sechs Anfragen 128,8 und zwölf Anfragen 223,5. Der Grund liegt in der Arbeitsweise der Pipeline: Bei drei Stufen verteilt der Planer der Engine drei Anfragen auf drei Teilschritte mit je einer Sequenz. Die Pipeline füllt sich, gebündelt gerechnet wird aber nichts.

Im Alltag merken wir davon wenig, und das liegt an der Spekulation — ihr Nutzen war lange unterschätzt. Früher hatten wir eine Akzeptanzrate von 22,9 Prozent gemessen, allerdings an synthetischen Testaufgaben. Unter echter Arbeitslast liegt sie bei 64,6 Prozent, das Modell übernimmt also 3,58 Token je Prüfdurchlauf statt einem. Damit wird auf der anderen Achse gebündelt, was die Pipeline nicht bündelt: Rund 71 Prüfdurchläufe je Sekunde mal 3,58 angenommene Token ergeben rechnerisch etwa 254 tok/s, beobachtet haben wir im laufenden Betrieb 132 bis 234 tok/s über alle Sitzungen.

Der Kontext bremst die Generierung nicht

Eine Messgewohnheit hat uns dabei zweimal in die Irre geführt: Token geteilt durch Gesamtdauer sinkt mit dem Kontext, weil das Vorfüllen in diese Rate mit einfließt. Getrennt gemessen ist die reine Generierung über alle Kontextlängen nahezu konstant — 60,1 tok/s bei 71 Token Kontext, 63,0 bei 55.051 und 58,0 bei 140.851. Die absoluten Werte stammen aus einem anderen Aufbau als der Endstand oben; interessant ist hier allein, dass sie von 71 bis über 140.000 Token Kontext nicht abfallen. Was mit dem Kontext wächst, ist das Vorfüllen. Wer beides in einer Zahl mischt, misst einen Effekt, den es nicht gibt.

Der Denkdeckel, diesmal je Anfrage

Das Modell denkt gern lange, bevor es antwortet, und ohne Begrenzung verbraucht es dabei sein ganzes Ausgabebudget. In unserer Testreihe mit Programmieraufgaben heißt das wörtlich: kein Code, nur Denktext, Abbruch am Limit. Mit einem Deckel für den Denkteil kommt Code — bei 512 Token nach 13,3 Sekunden, bei 2.000 Token nach 43,3 Sekunden. Ohne Deckel lief dieselbe Aufgabe 65,8 Sekunden und lieferte nichts Ausführbares.

Beim 27B hatten wir dasselbe Problem, dort ließ es sich nur für den ganzen Dienst lösen — der Nachtrag zu #15 beschreibt das. Beim großen Modell ist die Lage besser. Zum einen gibt es ein Denkbudget je Anfrage, das ohne Neustart des Dienstes wirkt; die Clients können es also selbst setzen. Zum anderen erreicht hier auch die Einstellung für den Denkaufwand tatsächlich das Chat-Template, also die Vorlage, aus der der Dienst den endgültigen Prompt zusammensetzt. Nachgewiesen haben wir das über die Gegenprobe: Ungültige Stufen werden mit Fehler abgelehnt, und die drei gültigen Stufen erzeugen messbar unterschiedlich lange Prompts, 53, 41 und 11 Token. Die Einstellung kommt also an, statt stillschweigend ignoriert zu werden.

Was der optimale Deckel für dieses Modell ist, wissen wir nicht. Beim 27B lag das Optimum bei 4.000 bis 5.000 Token; für den großen Bruder liegen uns bisher nur die beiden Einzelmessungen bei 512 und 2.000 vor.

Eine Fremdbehauptung, nachgemessen

Die Gewichte des Modells liegen bei uns in einer zusammengedrückten Fassung vor, vier Bit statt sechzehn je Zahl. Solche Fassungen heißen Quantisate, und verschiedene Anbieter stellen sie unterschiedlich her. Dazu gab es die Behauptung, die Geschwätzigkeit des Modells sei ein Artefakt des Quantisierungsverfahrens — ein anderes Quantisat würde also kürzer denken. Das ließ sich prüfen: zwei Quantisate, dieselbe Engine, dieselben Startargumente.

Der Wechsel kostet 20 Prozent Geschwindigkeit bei langem Kontext und 28 Prozent Kontextpool. Am Denkverhalten ändert er nichts: Beim fremden Quantisat haben wir die Testreihe ohne Denkdeckel vollständig gefahren, null von 38 Aufgaben bestanden, jeder Lauf verbrauchte das volle Ausgabebudget. Die Behauptung ist damit widerlegt, und wir bleiben beim alten Quantisat.

Was offen ist

Zwei der zehn Karten drosseln unter Last, und zwar nicht thermisch — die Temperaturen liegen zwischen 55 und 76 °C, alle Karten hängen mit vollen acht PCIe-Bahnen der vierten Generation am Board. Die beiden laufen gegen ihre Leistungsgrenze von 250 Watt, während an anderen Karten im Rig höhere Grenzen gesetzt sind. Ausgerechnet diese beiden bilden die letzte Pipeline-Stufe, und eine Pipeline ist so schnell wie ihre langsamste Stufe. Ob ein Anheben dieser beiden Grenzen etwas bringt, haben wir nicht gemessen.

Weiter offen bleibt die Ausgabegüte bei sehr langem Kontext. Die 524.288 Token entstehen durch Streckung über die trainierte Länge hinaus; gemessen haben wir Durchsatz, nicht Qualität bei 300.000 oder 500.000 Token. Wer diesen Bereich ernsthaft nutzt, sollte das an eigenen Aufgaben nachprüfen.

Abgesichert ist der Betrieb bisher mit einem kleinen Überwachungsskript, das die Schnittstelle jede Minute abfragt und den Dienst nach fünf Minuten Ausfall mit Ursachenmeldung neu startet. Einen Neustart des Rigs übersteht diese Absicherung nicht; eine automatische Wiederanlaufregel für den Container haben wir bewusst noch nicht gesetzt, weil sie nach den Erfahrungen aus #17 jeden Startfehler in einer Schleife unsichtbar macht.

Und eine Bilanz, die wir so nicht erwartet hatten: Von den Fremdempfehlungen, die wir in diesen Wochen geprüft haben, widersprachen drei unseren eigenen Messungen. Eine Blockgröße für die Wiederverwendung gelesener Prompt-Anfänge wird in der Dokumentation eines Forks als praktisch verpflichtend bezeichnet — unsere Trefferquote von 88,8 Prozent bei genau dieser Wiederverwendung sagt etwas anderes. Eine Option der Speicherverwaltung soll die Abstimmung zwischen den Karten zerstören; wir fahren sie und stürzen nicht ab. Und eine Kombination von Zusatzschaltern, die laut Quelle 19 bis 39 Prozent mehr Durchsatz bringen soll, hat uns gemessen 23 Prozent gekostet — dieselbe Kombination, die in #17 schon einmal negativ aufgefallen ist.

Bei diesem Modell auf dieser Hardware ist die eigene Messung also belastbarer als die fremde Angabe. Das gilt auch dann, wenn sie dem widerspricht, was wir selbst im letzten Artikel geschrieben haben.