Qwen3.5 122B auf acht RTX 3090: Das erste große Modell, das sich wie Infrastruktur anfühlte

Nach zahlreichen Läufen mit Reasoning-Schleifen, unerwarteten Sprachwechseln, schwankenden Ranglisten und Hardwarefehlern, die sich zunächst als Modellprobleme tarnten, war unser Maßstab ziemlich nüchtern geworden: Ein Modell, das gerade noch in 192 GB VRAM passt, ist noch kein brauchbarer Server. Es braucht auf dieser Hardware genug Reserve, um sich im Alltag verlässlich betreiben zu lassen.

An diesem Maßstab gemessen war Qwen3.5-122B-A10B das erste wirklich große lokale Modell in diesem Projekt, das wir als Infrastruktur behandeln konnten. Größere und spektakulärere Modelle hatten wir schon vorher betrieben. Qwen war das erste, das über längere Sitzungen hinweg unauffällig blieb, statt wie ein Experiment ständige Aufsicht zu verlangen.

Ein 120-GB-Modell auf 192 GB VRAM lässt noch echte Entscheidungen zu

Unser lokales LLM-Rig besteht aus sieben RTX 3090 und einer RTX 3090 Ti. Zusammen stellen sie rund 192 GB VRAM bereit, angebunden über eine Consumer-PCIe-Topologie ohne NVSwitch. Für diesen Versuch verwendeten wir den dynamischen FP8-Quant RedHatAI/Qwen3.5-122B-A10B-FP8-dynamic: rund 120 GB auf der Festplatte, bereitgestellt mit vLLM 0.25.1.

Diese Größe war für den Versuch entscheidend. Bei MiniMax M2.7 AWQ und HY3 GPTQ hatten die Modellgewichte den verfügbaren Speicher so weit belegt, dass für den KV-Cache und alternative Verteilungen kaum Spielraum blieb; dort mussten wir uns mit der einen Konfiguration abfinden, die überhaupt noch startete. Qwen122 ließ dagegen genug Speicher frei, um zwei ernsthafte Topologien zu testen und zwischen Durchsatz und KV-Kapazität zu wählen.

Zwei KV-Heads verändern die Speicherrechnung

Qwen122 ist ein Mixture-of-Experts-Modell mit 122 Milliarden Gesamtparametern und rund 10 Milliarden aktiven Parametern. Für unsere Ergebnisse bei langem Kontext war allerdings ein anderer Teil der Architektur ausschlaggebend: Von 48 Sprachmodell-Layern arbeitet nur jeder vierte mit Full Attention, die übrigen mit linearer oder rekurrenter Attention. Dazu kommen gerade einmal zwei KV-Heads.

Damit wachsen die teuren KV-Kosten mit dem aktiven Kontext deutlich langsamer als bei den anderen großen Modellen unserer Versuchsreihe. MiniMax M2.7 und HY3 verwenden in sämtlichen Layern Full Attention mit jeweils acht KV-Heads. Die ausführliche Gegenüberstellung und die Grenzen dieser Modelle haben wir im vorherigen Artikel über lange Agentenlast dokumentiert.

Die Parameterzahl allein erklärt deshalb erstaunlich wenig darüber, wie gut sich ein großes Modell lokal betreiben lässt. Zwei Modelle können denselben Gesamtspeicher belegen und dasselbe nominelle Kontextfenster anbieten, während ihre tatsächlich nutzbare KV-Reserve und ihre Decode-Kosten bei langen Sitzungen weit auseinanderliegen.

TP=8: rund 105 Token pro Sekunde und weniger KV-Reserve

Wir begannen mit der naheliegenden Konfiguration und verteilten das Modell per Tensor Parallelism über alle acht GPUs. Im kurzen Single-Stream-Decode erreichte TP=8 ungefähr 104,9 tok/s. Für ein Modell dieser Größe ist das ein sehr komfortabler Wert; die Antworten kamen schnell genug, dass sich die Interaktion unmittelbar anfühlte.

Die breite TP-Verteilung passte allerdings nicht besonders elegant zu den lediglich zwei KV-Heads. vLLM meldete in diesem Aufbau einen gesamten KV-Pool von 474.777 Tokens. Rechnerisch entspricht das etwa 1,81 vollständig belegten Sitzungen mit je 262.144 Tokens. Für eine einzelne schnelle Sitzung ist das eine sehr brauchbare Konfiguration. Als Server für mehrere lange Arbeitsstränge gerät sie früher an ihre Speichergrenze.

TP=2 plus PP=4: weniger Tempo, mehr als dreimal so großer KV-Pool

Die zweite Konfiguration kombinierte Tensor Parallelism über jeweils zwei GPUs mit vier Pipeline-Stufen. Der kurze Decode fiel auf ungefähr 72,6 tok/s. Das sind rund 32 Token pro Sekunde weniger als bei TP=8, für einen einzelnen Stream aber weiterhin eine solide Geschwindigkeit.

Der Gewinn lag im KV-Cache:

Mit 1.551.018 verfügbaren KV-Tokens stellte die PP-lastige Variante mehr als das Dreifache der KV-Kapazität bereit. Gegenüber den knappen Reserven, mit denen wir bei MiniMax und HY3 gearbeitet hatten, war das ungewohnt komfortabel.

1,55 Millionen KV-Tokens sind kein Kontextfenster

Die große Zahl braucht eine wichtige Einschränkung. Qwen122 besitzt pro Request ein hartes Kontextlimit von 262.144 Tokens. Der KV-Pool von gut 1,55 Millionen Tokens ermöglicht daher keine einzelne Unterhaltung mit 1,55 Millionen Tokens.

Er erlaubt stattdessen mehrere lange Sitzungen gleichzeitig. Neben einer umfangreichen Coding-Sitzung können beispielsweise ein separater Experimentierlauf, ein langer Recherchekontext und weitere ruhende Gespräche im Cache bleiben, ohne dass jeder neue Request sofort einen Verteilungskampf um den verbliebenen Speicher auslöst. Bei vollständiger Auslastung reicht das Budget rechnerisch für fast sechs Requests am Modellmaximum; reale Sitzungen sind natürlich unterschiedlich groß.

Der praktische Wert liegt in dieser Parallelität, nicht in einer großen Cache-Zahl auf einem Screenshot. Mehrere ernsthafte Arbeitsstränge nebeneinander halten zu können, verändert unmittelbar, wie wir den Server einsetzen: Das Modell wird von einer einzelnen großen Vorführung zu einer gemeinsam nutzbaren Ressource.

Lange Sitzungen verliefen erstmals unspektakulär

Bei MiniMax und HY3 kostete jeder große aktive Kontext zusätzliche Diagnosearbeit. Wir mussten damit rechnen, dass Reasoning-Schleifen länger wurden, Sprache und Bewertungen drifteten oder der Decode-Durchsatz bei mehr als 100.000 aktiven Tokens stark einbrach. Die Probleme traten bei beiden Modellen unterschiedlich auf, doch lange Sitzungen verlangten in jedem Fall Aufmerksamkeit.

Qwen122 verhielt sich in unseren Läufen ruhiger. Der Durchsatz in kurzen Decodes war hoch, die PP-lastige Topologie stellte reichlich KV-Reserve bereit, und lange Arbeitsstränge wirkten dadurch weniger fragil. Das ist eine qualitative Beobachtung aus unserem konkreten Aufbau, kein universeller Stabilitätsbenchmark. Für den täglichen Einsatz war sie dennoch mindestens so relevant wie die gemessene Tokenrate.

Perfekt war das Modell nicht. Qwen122 kann ausführlicher antworten als nötig, bleibt gegenüber kleineren Modellen langsamer und ersetzt nicht pauschal aktuelle Cloud-Spitzenmodelle. Auch ein großer KV-Pool garantiert keine inhaltliche Qualität. Er beseitigt lediglich einen betrieblichen Engpass, der bei anderen großen lokalen Modellen jede lange Sitzung überschattete.

Im Vergleich wurde Qwen zu unserem Alltagsmodell

Unsere vorangegangenen Versuche hatten zwei unterschiedliche Grenzfälle gezeigt. MiniMax konnte bei kurzen Aufgaben sehr stark sein, verlor aber genau unter der langen Agentenlast an Urteilsstabilität, auf die es uns ankam. HY3 blieb in langen Läufen inhaltlich überzeugender, bezahlte seine Full-Attention-Architektur jedoch mit steil steigenden Decode-Kosten. Der GPTQ-Pfad auf vLLM bot zudem kaum Kontextreserve.

Qwen122 besetzte die weniger glamouröse, betrieblich aber wertvollere Position. Es war schnell genug, ließ sich topologisch an die Aufgabe anpassen und behandelte langen Kontext sparsamer. Damit wurde es zum Werkzeug, das einfach verfügbar blieb, statt für einen einzelnen besonderen Lauf vorbereitet zu werden.

Dass 122 Milliarden Parameter in den Speicher passten, war dafür nur die Ausgangsbedingung. Die hybride Attention-Architektur und die zwei KV-Heads senkten den Preis, den das System für lange aktive Historien zahlen musste. Gleichzeitig blieb genügend Speicher frei, um mit TP und PP unterschiedliche Betriebsziele zu verfolgen. Ein ähnlich großes Modell mit durchgängiger Full Attention kann auf demselben Rig deshalb erheblich schwerfälliger sein.

Welche Topologie wir für welchen Betrieb wählen

Für eine einzelne interaktive Sitzung oder eine Vorführung ist TP=8 die klare Wahl. Rund 105 tok/s liefern die bessere Reaktionsgeschwindigkeit, und der KV-Pool reicht weiterhin für mindestens einen Request über das volle Kontextfenster, mit etwas Reserve darüber hinaus.

Für einen gemeinsam genutzten Agentenserver bevorzugen wir TP=2 plus PP=4. Rund 73 tok/s bleiben als Single-Stream-Durchsatz gut nutzbar. Der wesentlich größere KV-Pool erlaubt zugleich mehrere umfangreiche Sitzungen, ohne den Server auf einen einzigen maximalen Kontext festzulegen.

Welche Topologie richtig ist, entscheidet also die Arbeitslast. TP=8 optimiert die Geschwindigkeit des einzelnen Streams, TP=2 plus PP=4 die verfügbare Arbeitsfläche des Servers. Sobald mehrere reale Sitzungen parallel laufen, wiegt diese Reserve für uns schwerer als der zusätzliche Durchsatz eines kurzen Einzelbenchmarks.

Dieser Versuch hat unsere Modellbewertung konkret verändert: Neben dem Kontextlimit pro Request dokumentieren wir künftig auch den gesamten KV-Pool und die daraus resultierende Parallelität. Die 262.144 Tokens auf der Modellkarte sagen, wie lang eine Sitzung werden darf. Ob sich das Modell auf acht Consumer-GPUs tatsächlich wie ein Server nutzen lässt, entscheidet sich erst daran, wie oft diese Sitzung in den vorhandenen Speicher passt.