Lokale Modelle sind keine Spielerei mehr: Qwen als Gehirn, GLM als Ideengeber, Fusion als Sicherheitsnetz

In den letzten Artikeln ging es viel um Frontier-Modelle: GPT, Claude, Gemini, DeepSeek, HyperFusion Deep und die Frage, wie weit man Reasoning-Qualität treiben kann, wenn man die stärksten verfügbaren Systeme verwendet.

In der Praxis gibt es aber noch eine zweite, viel bodenständigere Frage.

Muss wirklich alles zu Drittanbietern gehen?

Viele Unternehmen und auch Privatpersonen haben gute Gründe, vorsichtig zu sein. Sensible Firmendaten, interne Dokumente, juristische Texte, persönliche Informationen, Strategien, Quellcode oder private Notizen möchte man nicht immer in eine fremde Cloud schicken. Erst recht nicht, wenn unklar ist, in welchem Land die Daten verarbeitet werden, wer betrieblich Zugriff hat und welche regulatorischen Folgen das haben kann.

Für europäische Firmen ist das besonders wichtig. Es geht nicht um Paranoia, sondern um Compliance, Geschäftsgeheimnisse, DSGVO, Cybersicherheit und den einfachen Wunsch, Kontrolle über die eigenen Daten zu behalten.

Also habe ich die Frage anders gestellt:

Was passiert, wenn wir starke KI wirklich lokal bauen?

Nicht über Frontier-APIs, nicht in der Cloud, sondern auf einer starken Grafikkarte, mit Open-Weight-Modellen, die man selbst kontrolliert.

Ich nahm mein Notebook mit RTX 5090, brachte mehrere lokale Modelle darauf zum Laufen und testete, wie weit man kommt, ohne Daten vom eigenen Rechner wegzuschicken. Es ging nicht nur darum, ein Modell zu starten und die Geschwindigkeit zu messen. Ich wollte wissen, ob man lokale Modelle zu einem System verbinden kann: ein schnelles Modell als Quelle für Kandidaten, ein stärkeres Modell als Reasoner und Judge, darüber eine einfache Fusion-Schicht.

Wenn die letzten Artikel also fragten, wie intelligent die besten Modelle der Welt sind, fragt dieses Experiment das Gegenteil:

Wie stark kann ein lokales, günstiges und kontrollierbares System heute schon werden?

Ich habe deshalb denselben Aufgabentyp wie im Ein-Fragen-Benchmark lokal auf zwei Modellen getestet:

• GLM-4.7-Flash-Heretic-NEO-CODE, Q4_K_M, ca. 17,6 GB
• Qwen3.6-27B, Q4_K_M, ca. 16 GB

Das Setup lief über llama.cpp mit CUDA auf einer RTX 5090 mit 24 GB VRAM, Kontext 32768, Flash Attention aktiv und lokaler OpenAI-kompatibler API.

Warum die Modelle so verschieden waren: MoE gegen dense

Der wichtigste Punkt ist nicht nur, dass Qwen besser abgeschnitten hat. GLM und Qwen sind architektonisch zwei verschiedene Arten von Gehirn.

GLM 4.7 Flash Heretic ist ein schnelles, aber flacheres MoE-Modell. Die Architektur folgt dem DeepSeek-V2-Stil: Mixture-of-Experts mit MLA-Attention. Das Label 64x2.6B bedeutet 64 Experten, aber pro Token werden nur 4 Experten plus ein geteilter Experte aktiviert. Von ungefähr 30 Milliarden Parametern nutzt ein Token real nur etwa 3-4 Milliarden aktive Parameter. Das Modell hat 47 Schichten, Embedding 2048, stark komprimiertes KV (head_count_kv=1), ein Vokabular von 154.880 Tokens und einen nativen Kontext um 200k Tokens. Heretic / NEO-CODE steht für einen Community-Finetune mit weniger Zensur und stärkerem Code-Fokus.

Genau diese Sparsity erklärt das Ergebnis. GLM lief mit etwa 140 Tokens pro Sekunde und kostete ungefähr 2,8 CZK pro Million Tokens. Als schneller Drafting-Motor ist es hervorragend. Aber jeder Token läuft nur durch einen kleinen Teil des Netzes, und bei dieser Reasoning-Aufgabe zeigte sich das als schwächere Verifikation.

Qwen3.6-27B ist dagegen ein dense Modell. Keine Experten, kein Routing. Alle 27 Milliarden Parameter sind bei jedem Token aktiv. In Q4_K_M belegt es etwa 16 GB, hat 64 Schichten, Embedding 5120, GQA mit 24:4 Köpfen und einen nativen Kontext bis 256k Tokens. Es lief nur mit etwa 36 Tokens pro Sekunde und kostete eher 11 CZK pro Million Tokens, löste den Benchmark aber fehlerfrei.

Kurz gesagt:

GLM ist ein sparsames MoE-Modell für Durchsatz: billig und schnell, aber beim Reasoning flacher. Qwen ist ein dense Modell, das pro Token etwa 7-8× mehr aktives „Gehirn“ einsetzt: langsamer, teurer, aber deutlich zuverlässiger.

Die Aufgabe: mep, dap und der Roboter

Die Aufgabe wirkt zunächst banal: Regeln für mep und dap erkennen, mep(5,8) und dap(5,8) berechnen, dann ein kleines Roboterproblem lösen und Unsicherheit benennen.

Die einfachen richtigen Hypothesen sind:

• mep(x,y) = x * (y + 1), also mep(5,8) = 45
• dap(x,y) = x^2 + y^2, also dap(5,8) = 89

Der Roboter startet bei (0,0) und darf nur (+2,+1) oder (+1,+3) gehen. Für (17,24) müsste gelten:

2a + b = 17
a + 3b = 24

Daraus folgt a = 27/5, also keine ganze Zahl. Der Punkt ist nicht erreichbar.

Schwer ist nicht die Mathematik, sondern die Disziplin: Findet das Modell nur ein hübsches Muster, oder prüft es das Muster gegen alle Daten?

Ergebnisse: Qwen sauber, GLM schnell, Fusion am besten

Die Kurzfassung:

• GLM baseline: schnell, aber falsches mep, falsches dap, falsche Zahlen. Etwa 38/100.
• GLM boost: dap korrigiert, aber die Asymmetrie von mep vertauscht: 48 statt 45. Etwa 58/100.
• Qwen baseline: richtige Regeln, richtiger Roboterbeweis, gute Metakognition. Etwa 93/100.
• Qwen boost: stabil über Temperaturen, inhaltlich korrekt. Etwa 95/100.
• Lokale Fusion: löste Widersprüche, verwarf falsche Antworten und behielt die besten Teile. Etwa 98/100.

Die wichtigste Prompt-Zeile war fast peinlich einfach:

Prüfe jede Hypothese gegen alle gegebenen Daten. Wenn ein Fall nicht passt, verwerfe sie.

Qwen macht das fast von selbst. GLM nicht. Mehr „Denken“ reicht nicht; entscheidend sind Verifikation und Terminierung.

Wie die Modelle verbunden wurden

Das Prinzip:

Beide Modelle antworten unabhängig, mehrere Temperaturen liefern ein Kandidatenpanel, und danach prüft Qwen als stärkerer Judge jede Antwort gegen die Daten, entscheidet die Widersprüche und erstellt eine Select-and-Augment-Synthese.

AUFGABE (mep/dap + Roboter + Metakognition)
        │
        ├── GLM 4.7 Flash, MoE ~3-4B aktiv
        │      schnelle Diversität, oft falsches mep
        │
        └── Qwen3.6-27B, dense 27B
               langsamer, stabil und korrekt

        ↓

ANONYMISIERTES PANEL A · B · C · D
        ↓
JUDGE = Qwen3.6-27B @ temp 0
        1) jedes Regelwerk auf allen Daten prüfen
        2) Widersprüche und Fallen finden
        3) die beste Basis wählen
        ↓
SYNTHESE = auswählen und ergänzen
        ↓
FINALE ANTWORT ~98/100
        45 · 89 · Roboter unerreichbar

Warum ist Fusion besser als der beste Einzelversuch?

1. Billige Diversität: GLM liefert schnelle Kandidaten.
2. Der Judge mittelt nicht, er prüft: 48, 40 und -39 werden verworfen, weil sie nicht zu den Daten passen.
3. Konfrontation findet elegante Fehler: Der schöne Roboter-Invariant von GLM hatte eine arithmetische Lücke.
4. Select and augment statt neu schreiben: Die beste Antwort bleibt erhalten und wird verbessert.

Kurz: GLM ist der schnelle Ideengeber, Qwen ist Gehirn und Jury, Fusion ist das Sicherheitsnetz.

Lokale Modelle im Kontext

Das bedeutet nicht, dass Qwen 27B allgemein auf dem Niveau der stärksten Frontier-Modelle liegt. Es bedeutet etwas Engeres: In dieser konkreten Aufgabe kann ein gut geprompteter lokaler Qwen plus einfache Fusion bereits sehr ernsthafte Arbeit leisten.

Für die Praxis würde ich die Pipeline so bauen:

1. GLM als schnellen divergenten Drafter.
2. Qwen als Haupt-Reasoner.
3. Self-consistency für Zahlen.
4. Qwen als Judge/Synthesizer bei Temperatur 0.
5. Harte Regeln für Terminierung.

Die eigentliche Frage lautet nicht nur: „Welches Modell ist das beste?“ Sondern: Wer antwortet, wer prüft, wer darf einen schönen Fehler verwerfen, und wer schreibt den finalen Verdikt?

Lokal ist das überraschend nah.