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.

Wenn Kontextgröße und Parallelbetrieb wichtig sind, sollte es definitiv der Ultra mit ordentlich RAM sein. Wenn es finanziell möglich ist, lieber eine Stufe mehr RAM, als man gerade durchgerechnet braucht, um auch für zukünftige Ansprüche gerüstet zu sein.
Vielleicht merkst du bei einer bestimmten Aufgabe, dass Modell x in Quantisierungsstufe y besser ist, aber bei 20 Prompts schon der Speicher voll ist, dann wäre man wieder am Limit und ärgert sich.

Ok, da müsstest Du dann (beispielsweise) statt Qwen2.5-7B-Instruct-Vision die Variante Qwen2.5-7B-Instruct (also ohne Vision) wählen.

Ohne diese Vision-Gewichte greift LM Studio dann auf die Standard-Text-Engine (mlx-lm) zurück. Dort funktioniert die KV-Cache-Quantisierung problemlos und spart bei langem Kontext enorm viel RAM.

Aber falls Du auf Vision-Language-Modelle (VLMs) angewiesen sein solltest, ist das für Dich natürlich keine Lösung …

Mal eine Frage als jemand der sich mit dem Thema gar nicht aus kennt.

Wie gut sind solche lokalen KIs im Vergleich zu z. B. GPT Astra im Coden?

PythagorasTraining: Einen Tag nach der Veröffentlichung von GPT-6 Astra fragst Du nach einem Vergleich?

Solche kommerziellen (und teuren) Modelle sind (aktuell) sehr wahrscheinlich überlegen, aber die offenen / frei verfügbaren Modelle entwicklen sich in den letzten Monaten auch rasant weiter – und "coden" ist ja nun auch ein sehr allgemein gehaltener Begriff. Wie genau definiert sich das denn für Deine theoretischen Anwendungsfälle?

Für meine Zwecke (Shell-Skripte unter Linux, BSD und macOS) sind die aktuellen "Open Source"-Modelle wie Qwen 2.5 Coder oder Llama 3.1 vermutlich ebenbürtig mit den kommerziellen Riesen. Warum?

Shell-Befehle (awk, sed, grep, Schleifen, Systemkonfigurationen) sind seit Jahrzehnten standardisiert und im Trainingsmaterial der KIs millionenfach vorhanden.

Und solche Skripte sind meistens relativ kurz. Lokale KIs müssen also nicht gigantische Code-Mengen im Gedächtnis behalten, um die perfekte Lösung auszuspucken.

Bei C++, Java, C#, Rust usw. sieht es mit Sicherheit etwas anders aus, allerdings weniger wegen der Sprache selbst, sondern wegen der Projektgröße.

Entscheidend ist dabei dann u.a. die Kontext-Größe (also sozusagen das "Gedächtnis"): Wenn du ein großes C++-Projekt mit hunderten Dateien, Klassen und Abhängigkeiten hast, musst du die KI mit extrem viel Code füttern, damit sie den Zusammenhang versteht.

Kommerzielle Modelle in der Cloud haben gigantische "Kontextfenster" (sie können ganze Buchbände auf einmal im Kopf behalten). Unsere lokalen KIs stoßen hier (je nach Arbeitsspeicher-Ausstattung) schneller an ihre Grenzen (also selbst der Mac Studio mit M5 Ultra und den maximal möglichen 512 GB Speicher).

Auch die Architektur-Entscheidungen sind bei solchen kommerziellen KIs noch mächtiger: Wenn es also z.B. darum geht, wie man eine komplexe Software-Infrastruktur über mehrere Server hinweg aufbaut, zeigen GPT-4o oder Claude 3.5 Sonnet noch eine tiefere logische Abstraktionsfähigkeit.

Kurz: Es ist wie fast immer in der IT – es kommt darauf an …

Stimmt es direkt mit Astra zu vergleichen ist zu früh.

Aber du hast meine Frage verstanden und perfekt für mich beantwortet. Vielen Dank dafür.
In deinem Fall macht die lokale KI Sinn und ist bestimmt cool das ganze zu Nutzen.

In meinem Fall wird so eine lokale KI wahrscheinlich nicht das richtige Werkzeug sein. Denn zusammen mit einem Freund entwickeln wir eine iPad App. Ich bin Ideengeber, Tester, Anwender und er programmiert mit KI-Unterstützung dann die App. Aktuell sind über 200.000 Zeilen Code schon entstanden. Wird etwas ergänzt oder geändert muss die KI im Blick haben funktionierende Teile der App nicht zu zerschießen. Deinen Ausführungen entnehme ich, dass dies bei einer lokalen KI schnell problematisch werden kann. Nochmal vielen Dank.

Ich habe ein DGX Spark mit Qwen 3.8 27b FP8 laufen, es ist nett, die antworten dauern lange, und man muss auch alles danach wieder nacharbeiten. Nebenbei den DGX noch nutzen ist eher nicht so drin, im idle brauch es 96GB, wenn man daten einwirft gehts auch schnell auf 115-120GB hoch. Daher würde ich mindestens 256GB ansetzen.


@Pythagoras Training,

Lokal 4/10 vs 10/10 astra. Kimi K3 soll gut sein, aber da brauch man eher 8 Mac studios a 512GB damit es auch atmen kann. Alex Ziskind bei YT gibt eine gute übersicht was möglich ist.

So ähnlich sehe ich das auch. Ich habe zwar nur einenM3 Max mit 64Gb, aber meine bisherigen Tests mit Qwen 3.8 27b FP4und anderen vergleichbaren Modellen waren eher ernüchternd. Aktuelle Modelle wie Astra oder auch Sol sind Lichtjahre entfernt wenn man das Ergebnis und die Geschwindigkeit berücksichtigt. Zumindestens beim coden komplexerer Plugins und Apps.

Ich nutze KI mittlerweile recht häufig und komme mit einem GPT Pro Abo für 100 € und einem ergänzenden Claude Abo für 20 € gut hin. Selbst wenn ich nochmal ein paar Tokens zusätzlich kaufen müsste, könnte ich das ziemlich lange bezahlen im Vergleich zu einem Studio Ultra mit 512 GB RAM + Strom und das mit einem viel viel besseren Ergebnis. Ich hätte auch gerne auf eine lokale Lösung umgestellt und hatte mir davon auch deutlich mehr versprochen. Aber so ist das für mich ein No-brainer.

Spannend. Allerdings ist die Speicherbrandbreite beim Studio Max und Ultra M5 doch nochmal deutlich höher, die Inferenzgeschwindigkeit sollte also auch deutlich höher ausfallen.

Gibt es einen Grund, warum du auf FP8 setzt? Von dem, was ich gelesen habe, sollte der Abfall in der Qualität, der ja zwischen FP8 und INT4/FP4 recht deutlich bestand, mit der NVFP4-Quantisierung vernachlässigbar sein. Da ließe sich eventuell auch nochmal was beschleunigen. Zumindest Ollama setzt NVFP4 ja dann in Apples MLX-Framework um; das funktioniert bei mir mit Modellen der 12b Klasse ganz gut.

Ich warte noch auf den Studio mit 96 GB, kann zu den Modellen hier also noch nichts aus eigener Erfahrung beisteuern.

Die qualität des ergebnisses nimmt mit der quantisierung exponentiell ab, die token ausgabe mag schneller sein, dafür kommt viel ai slop. Als faustregel scheint sich anzudeuten das man immer x2 rechnen sollte, ein 128gb modell sollte 256gb haben damit es brauchbar wird, usw. Alles unter 64gb produziert unbrauchbaren output.

Hmm, das ist eine etwas pauschale Aussage. Sie deckt sich auch nicht mit dem, was ich über aktuelle Modelle gelesen habe. Und mit meinen Erfahrungen eigentlich auch nicht, aber da spreche ich aktuell nur von kleineren Modellen.

Dass die Qualität exponentiell abnimmt ist klar, die Frage ist doch dann aber: wann kommt der „Knick“ in der exponentiellen Kurve; wann wird der Qualitätsverlust für den jeweiligen Anwendungsfall wirklich spürbar/relevant?

Bis vor ein paar Monaten bin ich davon ausgegangen: von FP16 zu FP8 ist der Verlust vernachlässigbar. Das passt, wenn man dann noch zusätzlichen Speicher für Kontextfenster, Cache etc. mitrechnet, ungefähr zu deiner Faustregel (Modell mit 120billionen Parameter → ca. 120 GB für das reine Modell in FP8 → ca. 256 GB Speicherbedarf). Mit INT4 kommt es dann aber doch zu einen klaren Verlust. Ist halt eine echte „Kompromisslösung“. Und unter 4bit sind die Modelle dann für viele Anwendungen weniger gut zu gebrauchen. Da wurde oft FP6 als „sweet spot“ gehandelt.

Wenn man sich Quantisierungen anschaut, die mit Kompression arbeiten (ich meine, das nennt man Blockskalierung, da fängt bei mir aber das Halbwissen an, die Zusammenhänge verstehe ich nicht wirklich), also MXFP4 oder insbesondere NVFP4, dann verschiebt sich das „abknicken“ der exponentiellen Kurve zum Qualitätsverlust.

Hier in der Tabelle auf Seite 9 sieht man das ungefähr: https://arxiv.org/pdf/2509.23202

Geht man von der Qualität von FP16 als 100% aus, dann ist man bei FP8 noch wirklich sehr nah dran (ca. 99%), bei INT4 ist man schnell in den niedrigen 9x%, bei NVFP4 aber in den mittleren 9x% .

Hier (https://arxiv.org/pdf/2601.09527), dann auch das Key Finding (Seite 6): „NVFP4 provides the best performance-efficiency
trade-off, delivering 1.6×throughput improvement over BF16 with
41% energy reduction and minimal quality degradation.“

Was heißt das letztlich?:
1. Wenn ich genau weiß, welches Modell ich betreiben will, dann wähle ich natürlich die höchste Quantisierungsstufe, die noch schnell genug läuft – bzw. nehme einfach FP8. Da ist deine Faustregel sicherlich richtig.
2. Wenn ich in der Modellwahl frei bin sähe ich das aber anders: Bevor ich jetzt für lokale Inferenz ein „kleines“ LLM mit FP8 betreibe bei dem mir die Geschwindigkeit noch reicht, sollte ich lieber ein größeres Modell mit mehr Parametern mit NVFP4 bei gleicher Geschwindigkeit und gleichem Speicherbedarf betreiben, weil die Qualität in den meisten Fällen besser sein wird.

Davon gehe ich zumindest im Moment aus, korrigiert mich da gerne! Ist ja sowieso viel Kaffeesatzleserei, solange man keinen guten Benchmark für genau seinen eigenen Anwendungsfall gefunden hat.

Sicherlich kann man kleine lokale modelle für bestimmte arbeitsschritte auch mit mxfp4 optmieren. Ich habe hier mal ein video von Alex Ziskind, der geht einmal alle stuffen durch, das zeigt recht gut ab wo der breaking point ist.

Ich bin von Astra wieder zurück noch Sol. Astra ist die Token nicht wert.