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.

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.

Letzte Woche bin ich über MiroFish gestolpert – ein Open-Source Projekt das gerade #1 auf GitHub Trending war. Innerhalb von 24 Stunden hat der Entwickler 4 Millionen Dollar Investment bekommen. Ich wollte wissen warum. Was MiroFish macht: Statt einer KI zu fragen "Was passiert wenn...?" – baut MiroFish eine digitale Gesellschaft und schaut es sich an. Du lädst ein Dokument hoch (Pressemitteilung, E-Mail, Report) und MiroFish generiert automatisch autonome KI-Agenten mit eigenen Persönlichkeiten, Erinnerungen und Meinungen. Die interagieren miteinander auf simulierten Social-Media-Plattformen – und aus dem emergenten Verhalten entsteht eine Vorhersage. Was ich gebaut habe: Eine vollständig lokale MiroFish-Infrastruktur auf meinem M2 Max (96GB): → 2× Qwen3-14B via vllm-mlx hinter nginx Load Balancer → Neo4j für den Knowledge Graph → Ollama für Embeddings → Kein einziges Byte verlässt den Mac → DSGVO-konform Der konkrete Test – A/B Vergleich für einen E-Commerce Händler: Szenario: Ein Haus/Garten Online-Shop (10 Mio. EUR Umsatz) hat Lieferverzögerungen in der Hauptsaison April. ▸ Variante A – Reaktiv: Kurzer Social-Media-Post nach ersten Kundenbeschwerden. Kein Angebot, kein konkretes Datum. ▸ Variante B – Proaktiv: Persönliche E-Mail vom Geschäftsführer mit konkretem Lieferdatum, 10€ Gutschein und täglichen Updates. Die simulierten Ergebnisse: Variante A: "I didn't know my order was delayed until a day after I expected it. That's not good enough" → Kunde wechselt zur Konkurrenz Variante B: "It was reassuring to get updates every 24 hours. I felt informed and not left in the dark" → Kunde bleibt Die ROI-Rechnung: → Gutschein-Investition: 1.700 € → Vermiedene Stornierungen: 8.075 € → Vermiedener Bewertungsschaden: 120.000 € → Gesamtvorteil proaktive Kommunikation: 128.075 € Eine persönliche E-Mail und ein 10€ Gutschein verhindern 128.000 EUR Schaden. Das ist kein Bauchgefühl – das ist eine Simulation mit echtem Agenten-Verhalten. Was mich beeindruckt hat:

🧪 Ich habe drei lokale LLMs in LM Studio auf meinem Apple M2 Max (96 GB) gegeneinander getestet. Das überraschendste Ergebnis war nicht die Antwortqualität – sondern die Zeit, die die Modelle zum Denken brauchen. ───────────────────────────── 🔬 DIE DREI MODELLE ───────────────────────────── ① Qwen3.5-27B · Claude 4.6 Opus Distilled (14 GB) ② Qwen3.5-35B-A3B · Claude 4.6 Opus Distilled, MoE (19,5 GB) ③ Qwen3.5-27B Original – kein Finetuning (14 GB) 6 Aufgaben: Python-Code, Debugging, API-Client-Architektur, deutsche Geschäftstexte, Rechtsfragen (revDSG). ───────────────────────────── ⏱ DER THINKING-SCHOCK ───────────────────────────── Diese Modelle denken laut – sie haben einen sichtbaren „Thinking"-Block bevor die Antwort erscheint. Und genau da lag der wahre Unterschied. Beispiel: Eine einfache Sortierfunktion in Python. 🟣 27B Distilled: 4 Sekunden 🟢 35B MoE: 4 Sekunden ⬜ 27B Original: 173 Sekunden Dasselbe Ergebnis. Dreimal. Der gleiche Prompt. Das Original grübelt fast 3 Minuten über eine Aufgabe, für die das Distilled-Modell 4 Sekunden braucht. Über alle 6 Aufgaben: 🟣 27B Distilled: 87 Sekunden gesamt 🟢 35B MoE: 55 Sekunden gesamt ⬜ 27B Original: ~775 Sekunden gesamt ───────────────────────────── 💡 WARUM IST DAS SO? ───────────────────────────── Beim Knowledge Distillation lernt das kleinere Modell nicht aus Rohdaten – es lernt aus den vollständigen Reasoning-Trajektorien eines Frontier-Modells (hier: Claude 4.6 Opus). Das bedeutet konkret: → Das Original-Modell exploriert beim Denken: es probiert Wege aus, verwirft sie, dreht im Kreis – sichtbar im Thinking-Block als endlose Bullet-Listen → Das Distilled-Modell hat Claudes Denkmuster internalisiert: strukturieren → Teilprobleme identifizieren → direkt lösen. Kein Herumirren. → Das Ergebnis: nicht nur bessere Antworten, sondern ein fundamental effizienterer Denkprozess Das ist der eigentliche Wert der Destillation. Nicht mehr Wissen – sondern besseres Denken. ─────────────────────────────

Wer von Euch mit LM Studio arbeitet sollte mit dem aktuellen Update vorsichtig sein. Die Version 0.3.39 bringt bei mir einen Fehler bei der Nutzung mit n8n, so wie es aussieht ist da ein required Parameter hinzugekommen den die OpenAI Node von n8n noch nicht kennt. In den Release Nodes konnte ich aber nichts finden.