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)

Das ist keine theoretische Frage. Es geht um Mindestanforderungen für produktiven Betrieb — und die Antwort überrascht. Ich habe meinen M2 Max (96 GB) systematisch unter Last gestellt. Mit vllm-mlx, einem nginx Load Balancer und einem realistischen RAG-Prompt (~400 Input-Tokens: System-Prompt + 2 Dokument-Chunks + Frage). 🔬 Erst mal die Modell-Frage klären Nicht alle Modelle skalieren gleich. Ich habe drei getestet: → Qwen3-14B Dense 4bit: 55 tok/s bei 5 parallelen Anfragen → Qwen3.5-27B Dense 4bit: 30 tok/s — größer, aber langsamer → Qwen3.5-35B-A3B MoE 4bit: 157 tok/s bei 5 parallelen Anfragen MoE hat 35B Parameter gesamt, aber nur ~3,5B aktiv pro Token. So schnell wie ein kleines Modell — so intelligent wie ein großes. Nur ~28 GB RAM statt ~50 GB für ein vergleichbares Dense-Modell. 💡 Lektion 1: Die Architektur des Modells ist wichtiger als die Parameterzahl. 📊 Der Realitätscheck: RAG unter Last Getestet mit konfigurierbarer Ankunftsrate — verteilt wie echte User, nicht alle gleichzeitig: ✅ 0,5 req/s — stabil. P95-Latenz unter 10 s, 100 % Erfolgsrate. RAM: ~52 GB. ⚠️ 1,0 req/s — noch stabil, aber P95-Latenz steigt auf 26 s. RAM: ~72 GB. ❌ 2,0 req/s — Queue läuft voll. 75 % der Anfragen fallen raus. Der nachhaltige Durchsatz liegt zwischen 0,5 und 1 req/s — je nach akzeptabler Latenz. 💡 Lektion 2: "Gleichzeitige User" und "gleichzeitige Requests" sind zwei sehr verschiedene Dinge. Bei 0,5 req/s und 7 s Ø Latenz sind nur ~3,5 Requests aktiv. Ein User liest die Antwort aber 45–90 Sekunden, bevor er die nächste Frage stellt. Ergebnis: 30–50 eingeloggte User sind problemlos bedienbar. ⚖️ Wann der Load Balancer wirklich hilft Nicht primär für Durchsatz — sondern für Rolling Restarts ohne Downtime. Der Prefix-Cache wächst über Zeit (~23 MB pro Request) und muss irgendwann durch einen Neustart freigegeben werden. Mit Load Balancer passiert das unsichtbar: eine Instanz startet neu, die andere übernimmt. Gelöst mit einem automatischen Memory Watchdog. 💡 Lektion 3: Der Load Balancer ist weniger für Durchsatz als für Betriebsstabilität wertvoll.

Das Ergebnis war zunächst enttäuschend. Dann wurde es interessant. Gestern hat Ollama 0.19 eine Preview veröffentlicht: Apple MLX als neues Backend statt llama.cpp. Ich hab sofort einen direkten Vergleich aufgebaut: Ollama 0.19 vs. mein bestehendes vllm-mlx Setup. Gleiches Modell (Qwen3.5-35B), gleiche Prompts, echter Benchmark. Erster Lauf. Ollama verliert haushoch: → vllm-mlx: TTFT 60 ms → Ollama 0.19: TTFT 26.000 ms Der Grund: Thinking Mode. Ollama aktiviert ihn standardmäßig, vllm-mlx nicht. Kein fairer Vergleich. Also Thinking deaktiviert — was sich als eigene Odyssee herausstellte: ✘ /no_think im Prompt? Ignoriert. Das Modell analysiert den Text buchstäblich: "Input: /no_think zähle von 1 bis 10" ✔ "think": false im API-Body? Funktioniert — aber nur bei Ollama Nach dem Fix: der echte Vergleich. SHORT (Wissensabfrage) → vllm-mlx: TTFT 60 ms | 85 Tokens/s | 1,5 s → Ollama 0.19: TTFT 86 ms | 68 Tokens/s | 1,8 s CODE (C# HTTP-Client) → vllm-mlx: TTFT 56 ms | 79,6 Tokens/s | 29,5 s → Ollama 0.19: TTFT 76 ms | 65,5 Tokens/s | 28,1 s LONG (KMU-Analyse, 5 Kriterien) → vllm-mlx: TTFT 64 ms | 77,5 Tokens/s | 21,6 s → Ollama 0.19: TTFT 85 ms | 60,9 Tokens/s | 28,9 s Das Fazit in Zahlen: vllm-mlx ist ~25% schneller in Tokens/s und hat ~30% niedrigeren RAM-Verbrauch (44-46 GB vs. 50-51 GB). Was erklärt den RAM-Unterschied? Ollama 0.19 lädt das NVFP4-Modell anders in den Unified Memory als mein bestehendes MLX-4bit in vllm. Ob das an der Quantisierung liegt oder am neuen Backend — unklar. Das wäre der nächste Test. Was Ollama 0.19 trotzdem richtig macht: ✅ MLX als Backend ist die richtige Entscheidung — endlich kein llama.cpp-Workaround mehr ✅ "think": false funktioniert sauber über die API ✅ Caching über Conversations hinweg — relevant für Agenten-Workflows ✅ NVFP4 bringt Production-Parität mit Cloud-Providern Mein Fazit für KMU-Deployments: Ollama 0.19 ist noch nicht das schnellste lokale Setup auf Apple Silicon — aber es ist das einfachste. Kein Python-Venv, kein nginx Load-Balancer, kein manuelles Start-Script.