NOVA am Modellprüfstand: Qwen3.6 35B gegen Qwen3.8 Distill
Executive Summary
Wir wollen zwei 35B-Modelle auf derselben lokalen Hardware vergleichen: das originale Qwen3.6–35B-A3B und die von Empero veröffentlichte Qwen3.8–35B-A3B-Distill-Version. Der zweite Kandidat ist eine Community-Distillation mit Qwen3.6‑Basis, keine offizielle Qwen3.8‑Veröffentlichung des Qwen-Teams.
Unser Prüfstand ist eine Windows-Umgebung mit Ollama und NVIDIA GeForce RTX 5090 mit 32 GB VRAM. Der Vergleich soll zeigen, welche Konfiguration für ausgewählte NOVA-Aufgaben brauchbar ist. Reaktionszeit und Speicherbedarf zählen ebenso wie die fachliche Qualität der Ergebnisse.
Eigene Messergebnisse liegen für diesen Vergleich noch nicht vor. Dieser Beitrag beschreibt den vorgesehenen Testaufbau. Einen Sieger nennen wir erst, wenn nachvollziehbare Messungen und eine Auswertung derselben Aufgaben vorliegen.
Ein neuer Name ist noch kein besseres Arbeitsergebnis
Zwei Downloads, dieselbe Grafikkarte, eine vermeintlich einfache Frage: Welches Modell ist besser?
Bei näherem Hinsehen wird daraus die Frage, die uns an NOVA wirklich interessiert: Welches Modell erledigt welche Aufgabe unter unseren Bedingungen besser? Ein neuerer Name verspricht noch keine bessere Antwort. Ein schnelleres Modell hilft wenig, wenn das Team danach jeden Datensatz von Hand korrigieren muss.
Deshalb wollen wir den Vergleich auf unserer tatsächlichen Windows- und Ollama-Umgebung durchführen. Apple-Silicon-Messungen können andere Einsatzfälle beleuchten. Für diese Reihe ist aber die vorhandene RTX 5090 der maßgebliche Prüfstand.
In unserer Illustration stehen zwei Komponenten auf derselben Werkbank. NOVA hat noch keine davon ausgewählt. Diese offene Entscheidung entspricht dem Stand des Vorhabens.
Was genau vergleichen wir?
Das originale Qwen3.6–35B-A3B stammt vom Qwen-Team. Die Bezeichnung A3B beschreibt ein Mixture-of-Experts-Modell mit ungefähr 3 Milliarden aktiven Parametern pro Token bei einer größeren Gesamtparameterzahl.
Die Empero-Modellkarte beschreibt eine Distillation auf Basis dieser Architektur. Die Veröffentlichung übernimmt laut Anbieter Trainingssignale aus Qwen3.8‑Lehrermodellen. Diesen Herkunftshinweis halten wir fest, statt den kürzeren Namen als offizielles Upgrade zu verwenden.
Für die lokale Prüfung benötigen wir außerdem die genaue Quantisierung und den Stand des heruntergeladenen Artefakts. Ein Ollama-Tag kann sich ändern; Modell-Digest, Quelle und Datum machen nachvollziehbar, welche Datei tatsächlich gemessen wurde.
Gleiche Bedingungen, dokumentierte Unterschiede
Beide Kandidaten erhalten dieselben Aufgaben und dieselben freigegebenen Testdokumente. Wir dokumentieren Ollama-Version, Treiber und Kontextgröße. Wenn eine Quantisierung oder ein Chat-Template abweicht, wird das im Protokoll sichtbar.
Ein fairer Vergleich bedeutet nicht, jedem Modell blind dasselbe ungeeignete Template aufzuzwingen. Modellgerechte Vorlagen bleiben erhalten; der Auftrag und die Bewertung des Ergebnisses sind für beide identisch. Gemeinsame Einstellungen bilden die Vergleichsbasis. Zusätzliche optimierte Varianten werden getrennt ausgewertet.
Der Test soll NOVA-Arbeit abbilden
Eine erste Aufgabe besteht aus einer Wissensfrage mit einer eindeutig belegten Antwort. Beide Modelle erhalten denselben relevanten Dokumentenausschnitt. Wir prüfen, ob sie den Zusammenhang richtig wiedergeben, die Fundstelle zuordnen und bei fehlender Information eine Rückfrage stellen.
Die zweite Aufgabe verlangt eine strukturierte Ausgabe. Ein festgelegtes JSON-Schema enthält Pflichtfelder und einen definierten Umgang mit fehlenden Angaben. Automatische Validierung prüft die Struktur; das Team prüft die extrahierten Werte.
Für einen Tool-Aufruf stellen wir eine begrenzte Test-Schnittstelle bereit. Der Auftrag ist gleich, die erlaubten Funktionen stehen fest. Ein kontrolliert erzeugter Fehler zeigt, ob das Modell einen zulässigen nächsten Schritt vorbereitet. Produktive Daten werden dadurch nicht verändert.
Eine kleine Coding-Aufgabe ergänzt den Vergleich. Ein bekanntes Fehlerbild und vorbereitete Tests machen das Ergebnis überprüfbar. Ein schöner Erklärungstext zählt nicht als gelöster Fehler, wenn der Test danach weiterhin fehlschlägt.
Was wir im Messprotokoll festhalten
Wir messen die Zeit bis zum ersten Token und den anschließenden Ausgabedurchsatz getrennt. Dazu kommen die Gesamtdauer bis zu einem brauchbaren Ergebnis und der Spitzenbedarf im Grafikspeicher. Fehlversuche und nötige Wiederholungen bleiben im Protokoll.
Für unterschiedliche Kontextlängen wird derselbe Aufgabentyp wiederholt. Modellladen und Aufwärmlauf erfassen wir separat. Mehrere Messläufe zeigen, ob ein einzelner schneller Durchlauf typisch war. Ausgabebudgets und Thinking-Einstellungen werden dokumentiert, damit lange interne Herleitungen nicht als zusätzliche produktive Antwortleistung gezählt werden.
Eine Basismessung ohne spekulative Beschleunigung steht für sich. Falls ein zusätzlicher Drafter eingerichtet wird, bekommt dieser einen eigenen Vergleich. So schreiben wir einen Unterschied im Backend nicht versehentlich dem Sprachmodell allein zu.
32 GB bestimmen den sinnvollen Versuchsaufbau
Die gesamte Modellstruktur muss im Betrieb verfügbar sein, auch wenn pro Token nur einige Experten aktiv rechnen. Hinzu kommen Kontextspeicher und Laufzeit. Wir messen daher, welche Konfiguration tatsächlich vollständig auf der GPU arbeitet und wann Daten in den Hauptspeicher ausweichen.
Ein zunächst moderater Kontext schafft eine nachvollziehbare Basis. Erst danach erhöhen wir die Länge. Falls eine Konfiguration nicht in den Grafikspeicher passt, halten wir das als Grenze dieser Konfiguration fest. Es ist keine allgemeine Aussage über die Modellfamilie.
NOVA wählt eine Komponente, keinen Pokalsieger
Der Vergleich soll unsere Modellauswahl für NOVA begründen. Ein Modell kann für kurze strukturierte Schritte gut passen, das andere für eine längere Analyse. Vielleicht ist die Qualität so ähnlich, dass Speicherreserve oder Wartbarkeit den Ausschlag geben. Auch das wäre ein brauchbares Ergebnis.
Für die Wissensaufgabe gehört ein sauber vorbereitetes NOVA-Wissenssystem dazu. Für den Tool-Test brauchen wir eine begrenzte Anbindung an die Anwendung. Diese Komponenten beeinflussen den Erfolg genauso wie das Modell.
Sobald echte Messungen vorliegen, lässt sich dieser Beitrag um die dokumentierte Konfiguration und die Resultate ergänzen. Bis dahin bleibt die Auswahl offen. Wer bereits einen eigenen Ablauf hat, kann über die NOVA-Hauptseite eine passende Testaufgabe mit uns besprechen.
Persönliches Gespräch gefällig?
Autor
Prof. Dr. Alexander Lutz, Professor für Big Data und KI an der FOM München, Doktor der Humangenetik und Anthropologie, ehemaliger Onlinespiele-Designer und natürlich Gründer und Inhaber der Agentur Die NEOs. Neben den Themen der künstlichen Intelligenz und deren Einsatzmöglichkeiten in der Praxis konzentriert sich Alexander auf die Kundenkommunikation. Neue Problemfelder oder technische Innovationen bereitet er so auf, dass der Nutzen für unsere Kunden deutlich wird. Er schläft zeitverantwortlich und agiert schnell, sein Motto: “Tue es, oder tue es nicht. Es gibt kein Versuchen.”
Die NEOs – KI-generiert