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.

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: