Qwen hat mit Qwen3.8-Flash-Next die Architektur gezeigt, auf der Qwen4 stehen wird — und darin steckt eine Idee, die für jeden von uns mit begrenztem VRAM interessanter ist als das Modell selbst. Ich habe sie die letzten zwei Tage auf meinem Mac auseinandergenommen. **Die Idee: Parameter, die nicht rechnen, müssen nicht in den Speicher** Von den 180 Mrd Parametern des Modells sind 51 Mrd eine reine Nachschlagetabelle für kurze Wortfolgen (N-Gramme). Die Tabelle rechnet nie — pro Token werden nur ein paar Zeilen daraus gelesen, wenige Kilobyte. Und was man nur zeilenweise liest, kann auf der SSD liegen. Ich habe das praktisch verifiziert: die 111-GB-Version des Modells auf meinem 96-GB-Mac, 32-GB-Tabelle komplett auf der SSD, Zeilen werden bei Bedarf gelesen. Läuft stabil mit 13 tok/s. Qwen baut das absichtlich so — die Model Card nennt das Embedding wörtlich „more amenable to offloading than MoE". **Warum das der eigentliche Durchbruch sein könnte** Bisher galt: Modellgröße = Speicherbedarf. 35B in 4 Bit ≈ 20 GB — vorbei an jeder 8-GB- oder 16-GB-Karte. Mit dieser Architektur gilt: **VRAM-Bedarf = Kerngröße, nicht Modellgröße.** Die Tabelle skaliert das Wissen fast gratis mit. Gedankenexperiment mit einer RTX 5060: Ein künftiges „35B" nach diesem Bauprinzip — sagen wir 10 Mrd Kern (MoE, ~1–2 Mrd aktiv) plus 25 Mrd Tabelle. Der Kern in 4 Bit: ~6 GB → passt in 8 GB VRAM. Die Tabelle liegt in System-RAM oder auf der NVMe, pro Token wandern ein paar Kilobyte über PCIe — das ist latenzmäßig irrelevant. Genau das unterscheidet den Ansatz vom Experten-Streaming bei klassischem MoE, wo pro Token hunderte Megabyte Expertengewichte gebraucht würden. **Was noch fehlt, ehrlich:** 1. Es gibt dieses Modell bisher nur als 180B-Brocken. Der Durchbruch für kleine Hardware kommt erst, wenn jemand ein 9B- oder 35B-Modell nach diesem Bauprinzip trainiert. 2. Die Runtimes können es noch nicht von allein — ich musste mlx-vlm dafür selbst patchen. llama.cpp & Co. müssen nachziehen, sonst bleibt es ein Bastel-Feature.

Qwen3.8-27B ist seit Freitag draußen. 27B, Apache 2.0, schlägt laut eigenen Zahlen Claude Opus 4.6 Max auf mehreren Benchmarks. Die Timeline ist entsprechend voll. Ich habe es lokal gegen seinen direkten Vorgänger gemessen. Nicht gegen eine Rangliste — gegen Qwen3.6-27B, gleiche Architektur, gleiche Quantisierung, gleiche 15 GB. Ergebnis: Bei einzelnen Prompts kein Unterschied. Bei Werkzeugarbeit fünfeinhalb Punkte. Der Sprung ist real — er liegt nur woanders, als die meisten ihn suchen. ━━━━━━━━━━━━━━━━━━━━ ① Der Sprung steht schon in Qwens eigener Tabelle — man muss sie nur sortieren Wissen, single-shot (GPQA Diamond) +1,4 Code, single-shot (LiveCodeBench v6) +6,4 Agentisch (SWE-bench Pro) +8,2 Agentisch (Terminal Bench) +9,6 Computer Use (AndroidWorld) +11,6 Computer Use (WebArena) +16,0 Computer Use (OSWorld) +20,4 Das ist kein Rauschen, das ist ein Gradient. Je mehr Werkzeuge, Schritte und Umgebung eine Aufgabe hat, desto größer der Vorsprung. Je näher an "ein Prompt, eine Antwort", desto kleiner. Qwen3.8 ist ein Agenten-Upgrade. Das ist eine gute Nachricht — nur eben eine andere als "besseres Modell". ② Ich habe an beiden Enden des Gradienten gemessen — und er stimmt Unten: reines Single-Shot. Sechs Aufgaben, ein Prompt, keine Tools, deutsch. Python-Code und Geschäftstexte aus dem KMU-Alltag. Qwen3.8: 76,5 von 105 Qwen3.6: 77,0 Differenz: −0,5 Oben: agentisch. 72 Routing-Entscheidungen mit fünf Werkzeugen, das Modell muss ermitteln bevor es entscheidet — mehrere Schritte, echte Fallen, Ground Truth aus meinem eigenen System. Qwen3.8: 98,6 % Qwen3.6: 93,1 % Differenz: +5,5 Dasselbe Modellpaar, dieselbe Maschine, derselbe Tag. Bei Single-Shot nicht unterscheidbar, bei Werkzeugarbeit fünfeinhalb Punkte auseinander. Der Unterschied ist sogar im Verhalten sichtbar: 3.8 macht 3,49 Werkzeugaufrufe pro Entscheidung, 3.6 nur 2,24. Das neue Modell prüft mehr, bevor es sich festlegt. Genau das ist die Fähigkeit, die Qwens agentische Benchmarks messen.

Heute war der Tag, an dem es endlich klick gemacht hat. Nicht weil ich eine neue Technologie entdeckt habe. Sondern weil ich zum ersten Mal gespürt habe, wie sich ein vollständig lokales AI-Coding-Setup anfühlt, wenn es wirklich funktioniert. Morgens: .NET-Migration mit lokalem Sprachmodell. Backend, C#, BouncyCastle, iText7, Security CVEs. Das Modell hat gebaut, geprüft, korrigiert. Kein Cloud-API, keine Daten die das Haus verlassen. Mittags: Cline in VSCodium eingerichtet. Temperatur korrigiert, CLAUDE.md hinterlegt, Vue-Frontend analysiert. Das Modell hat den Repo-Kontext gelesen und Fragen gestellt bevor es gehandelt hat. Abends: n8n MCP Server gebaut und in Cline eingebunden. Cline kann jetzt gleichzeitig meinen Code lesen und meine n8n Workflows lesen. Lokales Modell, lokale Automatisierung, lokale Daten. Der Moment wo es klick macht ist nicht spektakulär. Es ist der Moment wo du merkst, dass du dem Tool vertraust. Weil du weißt wo die Daten sind. Weil du den Server-Log siehst. Weil du die Temperatur selbst eingestellt hast. Das ist kein Produkt das ich empfehle. Das ist ein Setup das ich selbst täglich nutze, für echte Kundenprojekte, mit echten Daten, unter DSGVO. Wer das auch aufbauen möchte: es braucht einen guten Nachmittag, einen M2 Mac mit genug RAM, und die Bereitschaft ein paar Build-Fehler zu debuggen. Es lohnt sich. Welchen Teil davon würdet ihr euch genauer anschauen?

🧪 Qwen3.6-35B-A3B-4bit auf meinem M2 Max (96 GB), drei Runs auf meinem 105-Punkte-Benchmark. Das neue Modell spielt in der Top-Liga, aber mit einer klaren Schwachstelle. ───────────────────────────── 📊 DIE ZAHLEN ───────────────────────────── Drei unabhängige Runs, 6 Aufgaben, Temperatur 0,1. 🟣 Run 1: 98/105 (93,3%) 🟢 Run 2: 99/105 (94,3%) 🔵 Run 3: 101/105 (96,2%) Mittelwert: 99,3/105, also 94,6 %. Damit liegt das Modell gleichauf mit gpt-oss-120b und gemma4:31b Dense, bei nur 3B aktiven Parametern und rund 20 GB RAM. Konstant 83 bis 87 tok/s. ───────────────────────────── ⚡ DIE CODE-QUALITÄT IST BEMERKENSWERT ───────────────────────────── Drei Python-Aufgaben: Sortierfunktion, CSV-Bugfix, HTTP-Client mit Retry-Logik. Über alle drei Runs: 🟣 A1 Sortieren: 15, 15, 15 🟢 A2 CSV-Debugging: 15, 14, 15 🔵 A3 HTTP-Client: 15, 15, 15 Das Interessante ist nicht die Punktzahl, sondern die Stilvarianz. Gleicher Prompt, drei völlig unterschiedliche produktionsreife Lösungen. Beim HTTP-Client: Run 1 zentralisiert mit einem _execute_request-Helper. Run 2 liefert Context Manager plus Retry-After-Header-Parsing. Run 3 trennt sauber in _should_retry und _wait_before_retry. Alle drei brauchbar. Das ist Stilvarianz auf hohem Niveau, nicht Qualitätsvarianz. ───────────────────────────── ⚠️ DIE SCHWACHSTELLE ───────────────────────────── Juristische Texte. In jedem der drei Runs hat das Modell bei revDSG-Argumentation Artikelnummern halluziniert. Run 1: FDPB statt EDÖB, Art. 31 falsch zugeordnet Run 2: "Unterlageverarbeitungsverträge" statt Auftragsverarbeitungsverträge Run 3: Art. 5 und Art. 6 revDSG falsch zitiert Die Konzepte sitzen, FISA 702, EO 12333, Angemessenheit. Aber die Paragraphen-Zuordnung wackelt. Für juristisch sensible Outputs ohne RAG-Layer nicht einsetzbar. ───────────────────────────── 🎯 FAZIT FÜR DEN KMU-EINSATZ ───────────────────────────── Grün: Python-Automatisierung, Kundenkommunikation, Erklärtexte für nicht-technische Stakeholder. Gelb: Business-Texte brauchen Gegenlesen, Sprache schwankt (Genus-Fehler, gelegentlich schiefe Formulierungen).

🧠 Du brauchst keinen besseren Prompt. Du brauchst ein Modell, das dein Business versteht. Ich habe das gleiche 7B Modell zweimal gegen die gleiche Aufgabe antreten lassen. Einmal mit einem langen, detaillierten System-Prompt. Einmal feingetuned auf 327 Beispielen. Das Ergebnis war eindeutig. ━━━━━━━━━━━━━━━━━━━━━━ Der Use Case: Kundengespräche einer Gartenbaufirma automatisch analysieren und bewerten. Das Modell muss Budget, Fläche, Material, Untergrund und Eigentümerstatus erkennen, auch wenn der Kunde chaotisch redet. Das Setup: ① Trainingsdaten synthetisch erzeugen → 35B Modell generiert 400 Gespräche (390 fehlerfreie) → Gleiches 35B Modell annotiert die Gespräche im gewünschten JSON-Schema → Ergebnis: 327 saubere Trainingsbeispiele ② Training auf dem 7B Modell → 80/20 Split (Training / Validierung) → 600 Iterationen, Batch-Größe 2 → Bester Checkpoint nach ca. 200 Iterationen (danach beginnt das Auswendiglernen) ━━━━━━━━━━━━━━━━━━━━━━ Die drei Testszenarien, und was mich überrascht hat: Szenario 1, positiv: Das Originalmodell listet den Zeitraum als fehlende Info, obwohl der Kunde "Ende Mai" gesagt hat. Das feingetunte Modell erkennt es korrekt. Szenario 2, negativ: Lead Score 25 vs. 15. Das feingetunte Modell bewertet die Gesprächsqualität realistischer, weil kein Budget erkennbar ist. Szenario 3, Chaos: Der Kunde springt zwischen Rasenmäher, Urlaub und Terrasse. Und dann sagt er, der Hund zerstört immer den Rasen. Das feingetunte Modell erkennt daraus: Untergrund ist Rasenfläche, draußen. Das Originalmodell listet den Untergrund als fehlend. Das Modell hat nicht nur das Schema gelernt. Es hat gelernt, was in diesem Kontext wichtig ist. ━━━━━━━━━━━━━━━━━━━━━━ Wann lohnt sich Feintuning überhaupt? ▸ Immer die gleiche Aufgabe ▸ Fixes Output-Schema (JSON, strukturierte Ausgabe) ▸ Domänenspezifischer Kontext (Fachbegriffe, Branchenlogik) ▸ Beispiele vorhanden oder synthetisch erzeugbar ▸ Kosten und Latenz spielen eine Rolle (kleineres Modell, kürzerer Prompt)