Hallo zusammen,

da mein bisheriger Mac mini mit M2 nur 16 GB RAM hat und die Nutzung einer lokalen KI immer spannender wird, bin ich am überlegen, ihn durch einen aktuellen und sinnvoll konfigurierten Mac Studio zu ersetzen (auch dessen erweiterte Anschlussmöglichkeiten würden mir tatsächlich sehr entgegenkommen).

Ich peile hierbei eine Konfiguration mit mind. 128 GB Unified Memory an (eventuell aber auch gleich 256 GB oder sogar 512 GB).

Für mich persönlich liegt der eigentliche Wert so eines lokal betriebenen Modells dabei nicht unbedingt im höchstmöglichen Benchmark, sondern darin, dass:

1) keine Daten den Server verlassen, denn für einen Administrator, der täglich mit Unmengen an Skripten, internen sensiblen Dokumenten und jeder Menge 'credentials' hantiert, ist das kein "nice to have" sondern dieses Feature wäre das eigentliche Produkt

2) keine Cloud-Kosten pro Token anfallen, sondern lediglich im Voraus zu 100% kalkulierbare "Strom"-Kosten (den initialen Hardware-Anschaffungspreis mal ausgeklammert)

3) keine Drosselung, keine Queue, kein Rate-Limit, keine 429 errors bei Überlastung des Dienstes

4) keine Abhängigkeit von einem Unternehmen, das morgen das Abo um xxx Prozent teurer macht oder das Modell still umbenennt

Denkbar wäre meinem bisher eher laienhaften Verständnis zufolge entweder der Einsatz von z.B. Qwen 2.5 (z.B. 14B oder 32B Coder) oder auch ein aktuelles Reasoning-/MoE-Modell wie DeepSeek-R1 (in einer für den Mac optimierten Destillat-Größe).

Vorweg: Ich möchte weder Grafik- noch Videodaten erstellen oder bearbeiten, auch der Einsatz von "KI Agents" ist für mich vorerst noch ein komplettes "no go" (auch wenn mir klar ist, welches Potential das hätte und welche Vorteile, aber aus meiner Sicht überwiegen derzeit noch die Risiken und somit gravierende Nachteile).

Es geht mir also eher um folgendes:

A) Die "KI" soll komplett lokal laufen.

B) Das ganze soll sozusagen ein "Perplexity"-Abo ersetzen, was ich bisher auch immer nur im direkten normalen Chat benutzt habe und das mich (manchmal mehr, manchmal weniger) erfolgreich bei der Fehlereingrenzung und Fehlersuche unterstützt hat.

C) Den "Reasoning Effort" (das Nachdenken der Modelle vor der Antwort) würde ich gern maximieren, denn lieber soll "die KI" 5 Minuten nachdenken statt nur wenige Sekunden, dafür aber mehrfach geprüft und solide.

D) Mir ist klar, dass ich an einem RAG (Retrieval-Augmented Generation) mit Websuche nicht vorbeikomme, um möglichst aktuelle Ergebnisse / Rückmeldungen erhalten zu können.

E) Idealerweise könnte ich das ganze auch einfach per Web-Interface nutzen und Kollegen könnten das bei aktiver VPN-Verbindung ebenfalls (mit einem eigenen Account) nutzen.

Hierzu meine konkreten Fragen an die Experten / Experimentierer:

Wer von Euch nutzt schon ein ähnliches Setup auf einem Mac Studio für administrative Aufgaben?

Wie löst ihr das Thema lokale Websuche/RAG datenschutzkonform (z.B. über SearXNG )?

Reicht die Bandbreite eines Max-Chips für flüssiges Reasoning im Multi-User-VPN-Betrieb (bis zu 5 User gleichzeitig) oder sollte es doch besser gleich ein Ultra sein?

Welche Erfahrungen habt ihr mit dem RAM-Hunger des KV-Caches bei sehr langen, tiefgründigen Denkprozessen (Reasoning)?

Als Software-Lösungen für macOS kenne ich bisher (aber auch nur sehr oberflächlich):

Ollama (als lokales Backend)

Open WebUI (für das ChatGPT / Perplexity-ähnliche Interface inkl. Multi-User-Support)

LM Studio

oMLX

Ich freue mich auf Eure Erfahrungen und Empfehlungen.

Noch ein kurzes Update zu den konkreten Hardware-Plänen (M5 Ultra + oMLX):

Da ich das Thema zukunftssicher angehen will, liebäugle ich mittlerweile mit der absoluten Spitzenkonfiguration, also einem Mac Studio mit M5 Ultra und 512 GB Unified Memory.

Als Software-Backend plane ich fest den Einsatz von oMLX, da dieses Framework dank seines "Two-Tier-SSD-Cachings" inaktive Chat-Kontexte und riesige Reasoning-Ketten automatisch auf die SSD auslagert, statt sie zu löschen.

Da bei 512 GB RAM vor allem gigantische Modelle (wie Qwen 122B oder GLM 5.3) lokal laufen sollen und oMLX die SSD intensiv als erweiterten KV-Cache nutzt, stellt sich mir die Frage zur SSD-Größe:

Reichen hier 4 TB dauerhaft aus, oder sollte man bei diesem Extrem-Szenario direkt auf 8 oder gar 16 TB gehen, um nicht in ein paar Monaten ein Speicherproblem durch die oMLX-Cache-Auslagerung und die riesigen Modell-Repositorys zu bekommen?

Hat hier schon jemand oMLX mit derart großen Modellen im Multi-User-Einsatz getestet?

PS: Mir ist bewusst, dass die reine Generierungsgeschwindigkeit (Decode) auf Apple Silicon durch die Speicherbandbreite limitiert wird. Beim M5 Ultra liegt diese ja bei stattlichen 1,2 TB/s. Nach meinen Recherchen sollte das für ein Qwen 122B (in Q4) auf ca. 14–18 Tokens/Sekunde hinauslaufen, was für mich vollkommen ausreicht.

Der Hauptgrund für oMLX in Kombination mit dem M5 Ultra ist für mich aber der Prefill-Speed. Da wir im Admin-Alltag oft riesige Logfiles oder seitenlange Skripte übergeben, war die "Time-to-First-Token" (TTFT) bei älteren Macs oft der Flaschenhals. oMLX soll hier dank nativem MLX-Caching Eingaben mit extrem hohen Raten (mehrere tausend Tokens/Sek.) wegbügeln.

Habt ihr Erfahrungswerte, wie sich oMLX bei Multi-User-Inferenz verhält? Bricht der Token-Stream ein, wenn zwei Kollegen parallel eine Anfrage an ein 120B+ Modell stellen, oder fängt das Continuous Batching von oMLX das sauber ab?

Ich habe zwar nur einen Mac mini mit 24 GB und bin damit auf Qwen3 14B beschränkt, aber einen Gedanken kann ich vielleicht beitragen:

Schau dir mal an, wie groß die Modelle tatsächlich sind. Ein 70B-Modell liegt in Q4 bei rund 40–45 GB, Qwen3.8 27B bei knapp 20 GB. Selbst mit großzügigem Puffer für Kontext und den Rest des Systems landest du bei 64 bis 96 GB, aber nicht 256 GB.

Der limitierende Faktor ist die Speicherbandbreite, die bestimmt, wie schnell Tokens rauskommen. Und da liegt ein Ultra deutlich vor einem Max. Ich würde deshalb eher einen Ultra mit 96 GB nehmen, weil sonst eher das Warten nervt als die Ergebnisse. Und große Modelle sind übrigens auch langsamer.

Für einen Großteil der Admin-Fragen reichen 14B-Modelle, erst recht wenn RAG die Fakten beisteuert und das Modell sie nur noch einordnen muss. Wenn es doch 27B sein soll, so ist der Heise-Keno ganz angetan und der Tenor ist, dass man mehr nicht braucht.

Edit: Wenn du dir das Video anschaust, siehst du, dass der nächste sinnvolle Schritt jenseits eines Ultra mit 96 GB erst ein Stack aus vier Ultras mit 512 GB ist. Dazwischen liegt nichts, was eine neue Modellklasse erschließt. Das ist eine andere Art von Kaufentscheidung.
Von Perplexity war ich übrigens nicht so sonderlich begeistert, das nur zu deinem Vergleich.

Ein "alter" M1 Ultra mit 64Gb oder 128Gb würde deinen Ansprüche mehr als genügen und den bekommst du, wenn du noch einen findest, für unter 1500€ (Wir haben selbst einen Nagelnauen für den Preis gekauft). Alles neuere wird nochmal schneller sein aber auch teurer.

Als System zum Verwenden kannst du LM Studio nehmen oder gleich Bionic in der Kombination (selber Anbieter).

sudoRinger: Danke schon mal für Deinen input.

Ja, die Ergebnisse von Perplexity sind insg. doch eher 'durchwachsen', das haut dann doch mal deutlich daneben und erst nach einer längeren Diskussion und Einordnung bekommt man das Ding dann wieder eingefangen und in die richtige Richtung geschubst, da gebe ich Dir vollkommen recht.

Was mich dabei dann aber immer wieder besonder nervt, ist wie schnell er den eigentlichen Kontext und die Grundbedingungen "vergisst", obwohl man das erst vorher ausführlich definiert hatte – aber gefühlt nach 20-30 Minuten intensiver Auseinandersetzung löst sich das dann auch schneller als einem das lieb sein kann in heiße Luft auf.

Auch aus diesem Grund erhoffe ich mir da speziell mit dem Einsatz von oMLX eine deutliche Verbesserung.

Was die Ausstattung betrifft: Ich möchte diesen Rechner parallel auch für meine normale Arbeit nutzen können, d.h. da sind auch immer mind. 2 VMs (1x Linux, 1x Windows) parallel im Einsatz und auch Mails, Kalender usw. würde ich natürlich damit bearbeiten – also sozusagen das 'daily business' eines Home-Office (unterwegs arbeite ich natürlich direkt an meinem MBP).

Deshalb würde ich voraussichtlich mind. 128 GB RAM einplanen.

Wenn Du sagst, 96 GB sind grundsätzlich ausreichend für die "normalen, kleineren" Modelle (insbesondere für administrative ToDo's), dann wäre "mein Sweet Spot" vermutlich ein Gerät mit 128 GB RAM, um noch etwas Luft für die VMs und das macOS selbst + einige Standard Apps zu haben?

Aber trotzdem besser ein Ultra als ein Max?

Und bei der internen SSD wären sicher auch mind. 2 TB, besser gleich 4 TB sinnvoll (siehe auch meine ergänzende Frage kurz vor Deinem Posting)?

Beachte, dass du gar nicht frei wählen kannst: Bei Apple gibt es 96 GB nur mit dem Ultra und 128 GB nur mit dem Max. Deine Frage ist also nicht „96 oder 128 GB", sondern „Ultra oder Max". Ich würde eher den Ultra nehmen. Die VMs brauchen zwar ihren Teil, RAM-Druck kannst du notfalls durch ein etwas kleineres Modell entschärfen, was aber vermutlich gar nicht nötig ist.

Mmh, ich spiele allerdings auch mit dem Gedanken, drei oder vier Modelle parallel nutzen zu können (z.B. Qwen + DeepSeek + Codestral + Llama). Außerdem sollen große Mengen an Dokumentationen (z.B. das komplette pfSense-Handbuch) im Kontext-Speicher gehalten werden.

Um dieses "aushandeln" (MoA) lokal auf dem Mac Studio zu realisieren, müssen dann voraussichtlich Frameworks wie Together MoA, LangGraph oder CrewAI zum Einsatz kommen?

Genau deshalb mein ursprünglicher Ansatz mit "möglichst viel RAM" – also gar nicht so sehr für "noch größere" Modelle, sondern um kleine spezialisierte Modelle parallel nutzen zu können und dann die Essenz daraus zu extrahieren.

Ich stehe gerade vor ähnlicher Entscheidung. Meine Tendenz geht gerade auch zum Ultra, jedoch mit 96 GB RAM. Denke für 70B Modelle sollte dies auf jeden Fall ausreichend sein...

Darf ich fragen: Was von alledem brauchst du für den angestrebten Ersatz von "Perplexity für die "Fehlersuche" aus deinem ersten Beitrag?

sudoRinger: Gern doch, es geht mir nicht nur um den Ersatz einer klassischen Google-Fehlersuche, sondern tatsächlich um etwas mehr (da habe ich mich eingangs eventuell etwas unglücklich ausgedrückt, sorry).

Stell dir vor, ich brauche ein Nextcloud-Setup mit OnlyOffice, aber nicht einfach nur die Standard-Installation, sondern vollständig gehärtet nach Best Practices (Sicherheits-Header, isolierte Docker-Netzwerke, Non-Root-Container) und bei Bedarf direkt als ausfallsicheres Cluster konzipiert. Das händisch fehlerfrei aufzubauen, kostet enorm viel Zeit.

Oder nimm die automatisierte Bereitstellung von WireGuard-RoadWarrior-Zugängen inklusive OTP auf unseren OPNsense/pfSense-Firewalls via Skript.

Durch das lokale parallele Abfragen von hochoptimierten Modellen wie Qwen und DeepSeek lassen sich solche komplexen Konfigurationen und Skripte extrem beschleunigen: Das eine Modell schreibt den Code, das andere validiert die Security-Härtung, und ich bekomme in Sekunden ein Enterprise-bereites Ergebnis.

Und das Beste: Da alles lokal auf dem Mac Studio läuft, verlässt kein einziges internes Konfigurationsdetail unser Netz.

Soweit die Idee …

Ok, nachvollziehbar. Nur würde ich vorsichtig sein: Zwei Modelle, die sich gegenseitig prüfen, irren meist gemeinsam. Sie haben aus denselben Quellen gelernt und halten dieselbe veraltete Empfehlung für Best Practice. Beim Security-Härten funktioniert das Ergebnis und ist trotzdem Murks.
Was ich schon mache: ein Modell etwas ausarbeiten lassen, das zweite nach einer Rückmeldung fragen und die dann wieder ins erste Modell zurückspiegeln. Der Unterschied ist, dass ich dabei selbst dazwischenstehe und auswähle, wie es weitergeht. Aber das läuft ja nicht parallel.

Zudem bei deinem Szenario: wenn sich herausstellt, dass ein Modell auf einem Mac nicht reicht, dann kannst du ja einen zweiten Mac für das zweite Modell kaufen.

sudoRinger: Ja da hast du vollkommen recht, das ist ein durchaus berechtigter Einwand.

Genau das ist eine der größten Gefahren bei der Nutzung von KI-Modellen, insbesondere wenn wir sie (wie wir) in der IT nutzen wollen.

Wenn man zwei Modelle einfach nur blind nacheinander fragt, nicken sie sich oft gegenseitig zu und kopieren dieselben veralteten StackOverflow-Fehler. Das ist der klassische Consensus Bias …

Genau deshalb will ich das System auch nicht als "Zustimmungs-Maschine" laufen lassen. Ich mache vermutlich fast das gleiche wie du, nur dass ich den Prozess letztlich über ein kontradiktorisches Prinzip (Debatten-Design) automatisieren möchte, anstatt Prompts händisch hin und her zu kopieren.

Also konkret:

1) Klare Rollenverteilung: Ich sage nicht beiden Modellen "Schreib mir das perfekte Setup". Modell A (z.B. Qwen) bekommt den Auftrag: "Baue dieses Docker-Setup funktional auf." Modell B (z.B. DeepSeek-R1) bekommt die Rolle des peniblen, misstrauischen IT-Auditors: "Suche gezielt nach Sicherheitslücken, veralteten Versionen und Härtungsfehlern im Code von Modell A."

2) Der "digitale Schlagabtausch": Die Modelle treten in Sekundenbruchteilen digital gegeneinander an. Da DeepSeek-R1 durch sein spezielles Reasoning-Training extrem tief bohrt, findet es genau die Schwachstellen, die Qwen eventuell standardmäßig übersieht (nochmals: soweit die Theorie, in der Praxis muss sich das dann erst noch beweisen).

3) Die Entscheidungsvorlage: Ein drittes, kleines Modell fasst mir am Ende diese Debatte zusammen.

Ich stehe also am Ende immer noch als Letztinstanz (Human-in-the-Loop) dazwischen.

Der Unterschied dabei wäre dann im Idealfall die Effizienz: Statt dass ich 10 Minuten lang Prompts von Fenster zu Fenster kopiere, wirft mir die Pipeline in 5 Sekunden das fertige Skript inklusive einer Liste der architektonischen Schwachstellen und Trade-offs aus, die die Modelle untereinander diskutiert haben.

Ich wähle dann, wie es weitergeht. Es nimmt mir einfach die lästige Klick-Arbeit ab.

Aber wie gesagt, das ist hier jetzt eher "lautes nachdenken über das geplante Projekt" und weniger qualifizierte Expertiese und Erfahrung.

Sehe ich wenig nutzen Modelle so zu kombinieren. Dann lieber eines und dafür den Speicher frei für Kontext. Genau den brauchst du nämlich am meisten. Es muss auch meistens kein Model mit 40b aufwärts sein. Viel wichtiger ist die Qualität des Models und das es die Aufgaben beherrscht. Dann reicht oft schon ein Model von unter 15B locker aus. MOE Models gibt es schon fertig, sich selbst ein MOE aus mehreren vollen Models zu bauen sehe ich alleine wegen dem Kontext Bedarf schon problematisch.

Rafael Zeier hat ein Video zum Thema gemacht: . (Auf Einsteiger ausgerichtet, für Dich vielleicht zu sehr?)

Und von Jan-Keno Janssen von der c’t gibt es auch ein ganz frisches Video:

Danke für dein Feedback, ich glaube allerdings, hier liegt ein kleines Missverständnis bezüglich der Architektur vor. Ich habe nicht vor ein MoE (Mixture of Experts) auf Modell-Ebene nachzubauen, sondern ein Multi-Agenten-System auf Prozess-Ebene. Das sind zwei völlig verschiedene Paar Schuhe.

1. Kontext & Speicher: Die Modelle laufen nicht gleichzeitig im selben VRAM-Slot und teilen sich keinen Kontext. Sie werden per Pipeline sequenziell (nacheinander) angesteuert. Modell B bekommt also den vollen, frischen Kontext + den Code von Modell A als Input. Da wird nichts blockiert oder halbiert.

2. MoE schützt nicht vor Bias: Ein fertiges MoE-Modell (wie z.B. Mixtral) teilt Aufgaben zwar intern auf verschiedene "Experts" auf, operiert aber immer noch unter einem System-Prompt und einer Gewichtung. Wenn das Modell zu einem Fehler neigt, nicken die internen Experts den Fehler oft trotzdem ab.

3. Das Vier-Augen-Prinzip: Genau darum geht es mir. Ein Modell unter 15B (z.B. Qwen 7B) reicht für das initiale Docker-Setup locker aus. Aber wenn ich dasselbe Modell nach Fehlern frage, leidet es unter Betriebsblindheit (Consensus Bias).

Erst durch den gezielten Rollenwechsel ("Du bist der penible Auditor") und das Gegeneinander-Ausspielen (z.B. mit einem tiefen Reasoning-Modell wie DeepSeek-R1) breche ich eben genau dieses Muster auf.

Es geht mir also nicht um mehr Parameter, sondern um einen automatisierten, kontradiktorischen Prozess.

Die Speicherbandbreite wird für die Geschwindigkeit ausschlaggebend sein:
Nvidia 5090 hat 1.792 TB/s
Apple M5 Ultra soll 1.2 TB/s haben

Der M5 Ultra wird mit Qwen3.8-27B vielleicht (Spekulation meinerseits) 50 bis 60 Token pro Sekunde erreichen.
Die Nvidia 5090 liefert laut einem Bericht um die 100 Token pro Sekunde, bzw. 120 (UD-Q5_K_XL) .

Mit 5 Usern gleichzeitig wird das voraussichtlich sehr langsam auf dem Mac Studio.
Man bekommt mit dem Mac Studio die Kapazität große Modelle laden zu können, aber nur wenig Geschwindigkeit.

DeepSeek R1 ist zwar stark, aber Qwen3.8-27B ist neuer und vermutlich in vielen Bereichen überlegen. Mit dem Reasoning werden viele Token nur für den Denkprozess generiert. Das führt dann zu einer ziemlich langsamen Bearbeitung.

Generell würde ich empfehlen lieber ein kleines Modell mit viel Kontext zu betreiben, sonst leidet die Qualität sehr. Ein Problem auf meinem Mac mit 32GB RAM: Für besagtes Qwen3.8-27B (4-Bit quantisiert) sind gerade einmal um die 20k Kontextfenster in LM Studio Bionic möglich. Das führt dazu, dass viele Aufgaben gar nicht fertig werden, da während der Aufgabe das Kontextfenster mehrfach verdichtet („compacting”) wird und dann das Modell von vorne anfängt.

Die Dense-Modelle sind aufgrund der begrenzten Speicherbandbreite vom Mac schwierig. Bei größeren Modellen würde ich daher eher MoE-Modelle (Mixture of Experts) vorziehen.

Vielleicht wäre Stundenweise Grafikleistung mieten (z.B. Runpod) eine Alternative? Die Abos für Claude etc. kosten teils 20€ im Monat, da ist das mit dem Break-Even-Point für den Mac schwierig. Und ja, ich sehe das mit dem Datenschutz auch sehr kritisch.

ts: Sehr interessant, danke schon mal für Deinen Beitrag.

Bezüglich des "compacting"-Problems bei Deinem 32 GB Mac hätte ich eventuell einen Tipp: Hast Du mal versucht, die KV-Cache Quantisierung zu aktivieren?

Suche in den Einstellungen von LM Studio mal nach "KV Cache Quantization" oder "Flash Attention / Context Precision". Stelle diesen Wert von FP16 (Standard) auf Q4_0 oder Q8_0 um.

Dadurch wird das "Gedächtnis" ebenfalls komprimiert. Dein 20k-Limit sollte somit auf 40k bis 60k Kontext springen, ohne dass du mehr RAM brauchst.

Für meine geplante Umgebung kann ich übrigens realistisch davon ausgehen, dass es zwar "bis zu 5 User" geben wird, aber voraussichtlich nur 1 bis maximal 2 User "gleichzeitig" auf "die KI" zugreifen werden.

Hier mal ein Artikel aus dem Apple Machine Learning Research . Die Unterschiede zw. M4 und M5 sind beachtlich: Prompt-Verarbeitung bis zu 4×, Antwort-Tempo ~1,2×. Also bei dem, was prefill-dominiert ist, zählt das 4x. Weitere Quelle:

Im Prinzip kann man den KV-Cache quantisizeren, aber in der Praxis nicht unbedingt.
LM Studio und LM Studio Bionic geben dann einen Fehler aus: "Error when loading model: ValueError: The mlx-vlm batched vision path does not support KV cache quantization yet".
Okay, dann wäre die Geschwindigkeit wahrscheinlich akzeptabel. Ich würde trotzdem empfehlen erste praktische Tests abzuwarten.

Die Reasoning-Modelle wie Qwen 3.8-27B geben sehr große think-Blöcke aus. Ich gehe davon aus, dass die Geschwindigkeit dieser Modelle eher vom Decode dominiert wird.