35 Milliarden Parameter, drei Milliarden aktiv: Warum Qwen3.6 lokal so schnell ist
Ein Modell mit 35 Milliarden Parametern, rund 150 Token pro Sekunde im Single-Stream-Decode und dafür nur zwei RTX 3090: Diese Kombination hatten wir so nicht erwartet. Auf dem Papier sah Qwen3.6-35B-A3B nach einem weiteren großen Modell aus, das vor allem viel VRAM beansprucht. Im Betrieb wurde es zu dem Modell, zu dem wir auffallend oft zurückkehrten.
Der Grund war keine spektakuläre Bestmarke in einer allgemeinen Benchmarktabelle. Qwen3.6-35B-A3B verband auf unseren lokalen Systemen drei Eigenschaften, die selten so günstig zusammenkommen: Es antwortete schnell, hatte genug Qualität für ernsthafte Arbeit und ließ sich sinnvoll auf Hardware betreiben, die für ein Modell dieser Größenklasse ungewöhnlich klein oder preiswert ist.
Die folgenden Werte stammen aus unseren eigenen Single-Stream-Messungen mit den jeweils genannten Quants, Engines und GPU-Topologien. Sie sind damit eine Beschreibung unserer Aufbauten und kein universeller Modellbenchmark. Besonders beim Vergleich zwischen dem FP8-Pfad unter vLLM und dem GGUF-Pfad unter llama.cpp ist diese Einschränkung wichtig.
Die entscheidende Angabe im Namen lautet A3B
Die 35B beschreiben ungefähr die Gesamtzahl der Parameter. Während der Erzeugung eines Tokens wird bei diesem Mixture-of-Experts-Modell jedoch nur ein Teil der Experten verwendet. Laut offizieller Modellbeschreibung sind pro Token rund drei Milliarden Parameter aktiv. Dafür steht A3B.
Diese Unterscheidung verändert die Rechnung bei der Inferenz erheblich. Sämtliche Modellgewichte müssen weiterhin gespeichert und passend über die Hardware verteilt werden. Beim Decode wird die Geschwindigkeit aber wesentlich davon bestimmt, wie viele aktive Gewichte für jedes neue Token tatsächlich gelesen und verarbeitet werden müssen. Qwen3.6-35B-A3B trägt also den Wissens- und Kapazitätsrahmen eines 35B-MoE, bewegt pro Token aber nur einen kleinen Teil davon durch die Rechenpfade.
Wie stark sich das auswirkt, zeigte der Vergleich mit dem dichten Qwen3.6-27B. Obwohl die A3B-Variante nominell größer ist, decodierte sie in unseren lokalen Messungen mehr als doppelt so schnell. Beim dichten 27B-Modell arbeitet pro Schritt ein erheblich größerer Anteil der Gewichte. Die Modellbezeichnung allein sagt deshalb wenig darüber aus, wie schnell neue Tokens entstehen.
Zwei RTX 3090 lieferten bereits fast den gesamten Durchsatz
Auf zwei RTX 3090 betrieben wir die offizielle FP8-Variante mit TP=2. Bei einem konfigurierten Kontext von rund 192.000 Tokens erreichte sie etwa 150 tok/s. Für einen interaktiven lokalen Agenten liegt das weit oberhalb der Grenze, ab der die reine Ausgabegeschwindigkeit noch knapp wirkt.
Auf unserem vollständigen 8×3090-Rig stieg der beste gemessene Single-Stream-Decode auf ungefähr 164,8 tok/s. Dafür verwendeten wir TP=4 + PP=2 und 262.000 Tokens Kontext. Acht statt zwei GPUs brachten somit nur knapp zehn Prozent mehr Decode-Durchsatz.
Das ist eine schlechte Skalierung, wenn das Ziel eine annähernd lineare Beschleunigung durch zusätzliche GPUs ist. Für die praktische Einordnung des Modells ist es zugleich ein ausgesprochen nützlicher Befund: Zwei 3090 reichen bereits aus, um den größten Teil seiner Single-Stream-Geschwindigkeit abzurufen. Das Modell muss nicht auf acht Karten verteilt werden, damit sich seine Architektur auszahlt.
Unsere relevanten vLLM-Aufbauten im Überblick:
| Topologie | GPUs | Kontext | Single-Stream-Decode | Einordnung |
|---|---|---|---|---|
TP=2 |
2 | ungefähr 192k | ungefähr 150 tok/s | höchste Effizienz pro GPU |
TP=2 + PP=3 |
6 | 262k | ungefähr 153,7 tok/s | mehr Kontext bei fast gleichem Decode |
TP=4 + PP=2 |
8 | 262k | ungefähr 164,8 tok/s | bester gemessener Kompromiss auf dem vollständigen Rig |
TP=2 + PP=4 |
8 | 262k | ungefähr 152,4 tok/s | langsamer durch zusätzliche Pipeline-Bubbles |
TP=4 + PP=2 war damit unsere beste 8-GPU-Konfiguration. Ihr Vorteil bestand in der Verbindung aus dem höchsten gemessenen Decode, vollem 262k-Kontext und einer für unser Rig brauchbaren Verteilung. TP=2 + PP=4 zeigte die Gegenrechnung: Mehr Pipeline-Stufen schaffen Verteilungsspielraum, kosten bei einem einzelnen Request aber Zeit durch Pipeline-Bubbles.
Zusätzliche GPUs verschafften uns bei diesem Modell vor allem Kontextreserve, mehr Möglichkeiten bei der Platzierung und mehr Spielraum, die Gesamtgewichte unterzubringen. Der Single-Stream-Durchsatz stieg dagegen nur geringfügig. Bei einem MoE mit rund drei Milliarden aktiven Parametern steht schlicht nicht genug zusätzliche Rechenarbeit bereit, um den Kommunikationsaufwand einer immer breiteren Verteilung aufzuwiegen.
Der Ein-GPU-GGUF-Pfad war ein anderer Versuchsaufbau
Auch auf einer einzelnen RTX 3090 war das Modell auffällig schnell. Mit einem lokalen GGUF aus der Unsloth-Quantfamilie maßen wir ungefähr 131,6 tok/s.
Diese Zahl lässt sich nicht sauber gegen die FP8-vLLM-Läufe stellen. Engine, Quantisierungsformat und Verteilung unterscheiden sich; damit ändern sich gleich mehrere Ursachen des gemessenen Durchsatzes auf einmal. Der Ein-GPU-Wert beantwortet eine andere Frage: Kann der kleine aktive Parametersatz auch auf einer einzelnen guten Consumer-GPU ein reaktionsschnelles System ergeben? In unserem Aufbau lautete die Antwort klar ja.
Damit wurde der Quantisierungspfad mehr als nur ein Mittel, das Modell überhaupt in den Speicher zu bekommen. Bei unseren vorherigen Versuchen mit sehr großen quantisierten Modellen hatten wir gelernt, niedrige Bitbreiten mit Vorsicht zu behandeln. MiniMax M2.7 zeigte unter langem aktivem Kontext, wie unauffällig ein zunächst schneller und überzeugender Quant später in Schleifen laufen, die Sprache wechseln oder in seinen Urteilen instabil werden kann.
Bei Qwen3.6-35B-A3B blieb dieses Muster in unseren alltäglichen Aufgaben aus. Die getesteten IQ-Quants wirkten in den für uns relevanten Einsätzen nicht messbar weniger intelligent. Unser Befund ist eng auf diese Quantisierungen und Aufgaben begrenzt und sagt wenig über andere Varianten oder über beliebig lange Kontexte aus. In unseren Läufen fanden wir keinen Qualitätsverlust, der den erheblichen Vorteil bei Speicherbedarf und lokaler Nutzbarkeit zunichtegemacht hätte.
Ein lokales Arbeitspferd braucht keine acht GPUs
Mit ungefähr 150 tok/s auf zwei 3090 verschob sich die Rolle des Modells vom gelegentlichen Versuch auf dem vollständigen Rig zum schnellen lokalen Worker, den man einer konkreten Aufgabe zuordnen kann.
Damit werden kleinere Aufbauten sinnvoll: ein separater Rechner für interaktive Agenten, ein günstiger Knoten für Coding-Aufgaben, ein System für einen Voice-Agenten oder eine geteilte Umgebung, in der das 8-GPU-Rig die schweren Jobs übernimmt und ein kleinerer Rechner die schnellen Dialoge verarbeitet. Die genaue Eignung hängt weiterhin von Kontext, Quant und Aufgabe ab. Interessant ist vor allem, dass solche Optionen bei einem 35B-Modell überhaupt ernsthaft zur Wahl stehen.
Größere Spitzenmodelle bleiben bei manchen anspruchsvollen Aufgaben überlegen. Qwen3.6-35B-A3B bietet dafür eine andere Kombination aus Tempo, Qualität und Hardwarebedarf:
- Der Decode ist schnell genug für unmittelbar wirkende Interaktion.
- Die Qualität reicht für ernsthafte lokale Arbeit statt nur für Demonstrationen.
- Der geringe aktive Rechenaufwand erlaubt ungewöhnlich flexible Hardwareentscheidungen.
Im Alltag gewinnt diese Kombination häufig gegen ein Modell, das in einer isolierten Bewertung vielleicht fünf Prozent besser abschneidet, dafür aber dreimal aufwendiger betrieben werden muss. Ein lokales Modell arbeitet schließlich nicht in einer Rangliste. Es wartet auf Prompts, hält Kontext vor, bedient Werkzeuge und belegt dabei reale GPUs.
Der nächste sinnvolle Versuch heißt 2×3060
Der Ein-GPU-GGUF-Lauf und die schwache Skalierung oberhalb von zwei RTX 3090 führten zur nächsten Frage: Wie weit lässt sich der Hardwarepreis senken, bevor der praktische Vorteil verschwindet?
Zwei RTX 3060 sind dafür ein ernsthafter Test. Unsere Erwartungen bleiben nüchtern: weniger Durchsatz als auf den 3090 und mögliche Qualitätseinbußen durch die stärkere Quantisierung. Die Architektur macht den Aufbau trotzdem plausibel. Wenn pro Token nur rund drei Milliarden Parameter aktiv sind und ein guter Q4- beziehungsweise IQ-Quant genug Qualität bewahrt, könnte ein deutlich günstigeres 2×3060-System immer noch schnell genug für einen lokalen Assistenten sein.
Bei einem dichten 35B-Modell wäre derselbe Versuch wesentlich weniger attraktiv. Bei A3B reicht uns ein erfolgreicher Start als Ergebnis nicht aus. Das Modell muss auf der preiswerteren Hardware weiterhin so reaktionsschnell und verlässlich arbeiten, dass wir ihm tägliche Aufgaben anvertrauen wollen.
Zwischen MiniMax und HY3 zählt der Betrieb
Unsere MiniMax- und HY3-Versuche hatten zwei unterschiedliche Grenzen gezeigt. MiniMax konnte bei kurzen Aufgaben sehr stark wirken und unter langer Agentenlast qualitativ instabil werden. HY3 blieb in den beobachteten Langkontextläufen inhaltlich überzeugender, bezahlte dafür aber mit steil fallendem Decode-Durchsatz. Die Details und Messbedingungen stehen im Artikel über lange Agentenlast.
Qwen3.6-35B-A3B beantwortete eine andere Frage. Seine Architektur machte ein fähiges Modell im Betrieb ungewöhnlich unkompliziert: hoher lokaler Decode, brauchbare Quants und wenig zusätzlicher Single-Stream-Gewinn durch ein Vielfaches an GPUs. Das technische Profil zählte damit fast so viel wie die Modellqualität selbst.
Für unsere Modellwahl folgt daraus eine praktische Regel. Einige Prozent mehr Qualität in einem isolierten Test rechtfertigen nicht automatisch einen deutlich teureren, langsameren oder störanfälligeren Betrieb. Sobald ein Modell täglich auf realer Hardware arbeitet, werden Geschwindigkeit, Kontextreserve, Quantisierbarkeit und sinnvolle GPU-Topologien zu einem Teil seiner Fähigkeiten.
Der 2×3060-Versuch wird deshalb mehr klären als ein weiterer Screenshot mit einer hohen Tokenrate. Wenn Qwen3.6-35B-A3B dort genug Qualität behält und praktisch schnell bleibt, liefe ein leistungsfähiger lokaler Worker auch ohne großes GPU-Rig. Genau diese Verschiebung macht A3B für uns interessanter als die bloße Zahl 35B.