Wer einen Mac Studio M3 Ultra für lokale KI kauft, erwartet Spitzenleistung, und erlebt manchmal eine unerwartete Ernüchterung. Die tatsächlichen Token-Raten bleiben deutlich hinter dem zurück, was Benchmark-Tabellen versprechen. Ein KI-Forscher brachte das Problem auf X auf den Punkt: «Performance isn't about the hardware, it's about three software layers stacked on top of it.» (Quelle) In einem Direktvergleich testete er MLX, Ollama, llama.cpp und das neue vllm-mlx auf identischer Hardware und fand erhebliche Unterschiede, verursacht ausschließlich durch die Wahl des Software-Stacks.
Für europäische KMU, die eine On-Premise-KI-Infrastruktur planen, ist diese Erkenntnis zentral: Der Inference-Stack ist mindestens so wichtig wie die Modellwahl oder das Hardware-Budget.
Die drei Software-Schichten
Wer versteht, warum zwei baugleiche Mac Studios unterschiedlich schnell laufen, muss drei Schichten analysieren:
1. Quantisierungsschicht, wie stark sind die Modellgewichte komprimiert?<br> Q4KM ist schnell und speichereffizient; Q8_0 bewahrt mehr Qualität bei fast doppeltem Speicherbedarf; F16 liefert volle Präzision, beansprucht aber das meiste Unified Memory. Diese Wahl allein kann den Throughput um Faktor 1,5 bis 2 verändern, noch bevor die eigentliche Inferenz-Engine zum Zug kommt.
2. Compute-Schicht, welches Framework treibt die eigentliche Berechnung?<br> MLX nutzt Apples natives Metal-Framework direkt und ist für die Unified-Memory-Architektur des Apple Silicon optimiert. llama.cpp arbeitet mit Metal-Offloading, ist jedoch generisch und nicht Apple-exklusiv. Ob Metal-Shader vollständig oder nur teilweise genutzt werden, entscheidet über den Unterschied zwischen GPU-beschleunigter und CPU-seitig abgefangener Inferenz, letztere ist um ein Vielfaches langsamer.
3. Serving-Schicht, wie wird das Modell nach außen exponiert?<br> Ollama fügt einen REST-Server über llama.cpp ein: praktisch, aber mit messbarem Overhead. Wer mlx-lm oder llama.cpp direkt aufruft, spart diese Abstraktion. Bei hohem Anfragevolumen summiert sich der Unterschied erheblich.
Das Zusammenspiel dieser drei Schichten bestimmt, wie schnell Antworten tatsächlich ankommen.
MLX, Ollama, llama.cpp und vllm-mlx im Vergleich
MLX-LM: Native für Apple Silicon
MLX ist Apples eigenes Machine-Learning-Framework, das direkt auf der Unified-Memory-Architektur des M-Chips aufsetzt. mlx-lm stellt darüber eine Python- und Kommandozeilen-Schnittstelle für Sprachmodelle bereit.
Laut Community-Messungen erreicht ein Mac Studio M3 Ultra 192 GB mit MLX-LM und Llama 3.3 70B in Q4KM-Quantisierung zwischen 45 und 65 Token pro Sekunde, die höchsten berichteten Werte für diese Geräteklasse. MLX ruft Metal-Shader direkt auf und vermeidet den Overhead einer Middleware-Schicht vollständig.
Der Kompromiss: mlx-lm ist eine Bibliothek, kein Plug-and-Play-Server. Es eignet sich vor allem für technische Teams, die ein Python-Backend aufbauen, und für Entwicklerinnen und Entwickler, die Modelle direkt in Pipelines einbinden.
Ollama: Komfort mit Overhead
Ollama ist das meistgenutzte Tool für lokale LLMs, und das zu Recht. Ein einziger Befehl lädt ein Modell; ein zweiter startet es. Die REST-API ist direkt kompatibel mit Open WebUI, LangChain, LlamaIndex und den meisten gängigen Frameworks.
Unter der Haube nutzt Ollama llama.cpp als Inferenz-Backend. Der Komfortgewinn kostet laut Community-Berichten 20 bis 30 % Throughput gegenüber einem direkten llama.cpp- oder MLX-LM-Aufruf. Für einen einzelnen Nutzer ist das meist irrelevant; bei einem Team mit fünf bis zehn gleichzeitigen Anfragen summiert sich der Overhead spürbar.
Für KMU, die einen internen Chatbot oder ein dokumentengestütztes Q&A-System einführen wollen, bleibt Ollama die pragmatischste Wahl. Wie wir es im Praxisbetrieb einsetzen, zeigt das kAIra Tools.
llama.cpp direkt: Kontrolle ohne Wrapper
llama.cpp ist die C++-Referenzimplementierung für GGUF-Modelle. Wer es direkt aufruft, ohne den Ollama-Wrapper, , gewinnt typischerweise 10 bis 20 % Throughput zurück. Auf Apple Silicon nutzt llama.cpp sein ggml-metal-Backend; ist Metal-Offloading korrekt konfiguriert, erreicht die Leistung annähernd das Niveau von MLX-LM.
Der entscheidende Portabilitätsvorteil: GGUF-Modelle laufen unverändert auf Mac, Linux und Windows. Wer ein hybrides Setup aus Mac Studio und Linux-Server betreibt, kann dieselben Gewichte auf allen Geräten nutzen, ein praktischer Vorteil für KMU mit gewachsener IT-Infrastruktur.
vllm-mlx: Batching für den Produktionseinsatz
vllm-mlx ist der jüngste Eintrag in diesem Vergleich, und der relevanteste für Teams mit mehreren gleichzeitigen Nutzerinnen und Nutzern. vLLM ist als Produktions-Inference-Server bekannt, der mit seinem PagedAttention-Mechanismus GPU-Speicher effizient über parallele Anfragen verteilt. Der MLX-Port bringt diesen Batching-Vorteil auf Apple Silicon.
Für eine einzelne Person im Chat-Gespräch zeigt vllm-mlx ähnliche Latenz wie mlx-lm. Bei fünf bis zehn simultanen Anfragen eines Teams auf demselben Mac Studio können frühe Community-Berichte zufolge 30 bis 50 % höherer Gesamtdurchsatz erreicht werden, weil Anfragen intelligent gebündelt statt sequenziell abgearbeitet werden.
Quantisierung: Der unterschätzte Hebel
Neben der Wahl des Inference-Stacks ist das Quantisierungsformat der meistunterschätzte Performancehebel:
- Q4KM: Beste Effizienz für die meisten Anwendungsfälle. Llama 3.3 70B in Q4KM belegt rund 40 GB Unified Memory. Für Dokumentenanalyse, Zusammenfassungen und Chat sind Qualitätsunterschiede zu Q8_0 in der Praxis minimal.
- Q8_0: Höhere Qualität, fast doppelter Speicherbedarf. Empfohlen für Code-Generierung und Reasoning-Aufgaben, bei denen numerische Präzision zählt.
- F16: Volle Präzision; für KMU-Deployments in den meisten Fällen nicht notwendig.
Ein Mac Studio M3 Ultra mit 192 GB Unified Memory kann in Q4KM-Quantisierung Modelle bis etwa 405 Milliarden Parameter lokal ausführen, und ist damit das leistungsfähigste Desktop-Gerät für lokale KI, das ohne dedizierten Serverraum betrieben werden kann.
Welcher Stack für welches Szenario?
| Szenario | Empfohlener Stack |
|---|---|
| Entwickler/in, Python-Integration | mlx-lm direkt |
| Team-Chatbot mit UI, 5-20 Personen | Ollama + Open WebUI |
| Mehrere simultane Anfragen, Produktion | vllm-mlx |
| GGUF-Portabilität Mac + Linux | llama.cpp direkt |
Diese Tabelle ist eine erste Orientierung. Welcher Stack für Ihre konkrete Umgebung optimal ist, hängt von Netzwerktopologie, Modellgröße, Nutzerzahl und den eingebundenen Anwendungen ab.
Datenschutz und DSGVO-Konformität
Unabhängig vom gewählten Stack gilt: Jede Inferenz findet vollständig auf lokaler Hardware statt. Kein Token verlässt das Unternehmensnetz, keine Drittlandsübermittlung im Sinne von Art. 44 DSGVO findet statt. Das ist der grundlegende Vorteil von Datensouveränität auf eigener Hardware, und er gilt für MLX-LM, Ollama und vllm-mlx gleichermaßen.
Gemäß unserem Verständnis der EU-KI-Verordnung sind lokale Betreiber von Open-Weight-Modellen in vielen Einsatzszenarien von den strengsten GPAI-Pflichten ausgenommen. Die genaue Einordnung hängt von der konkreten Nutzung ab, diese Aussage ist als informatorischer Kommentar zu verstehen, nicht als Rechtsberatung.
Sie möchten wissen, welcher lokale KI-Stack für Ihr Team optimal ist? Im Rahmen eines Pilotprojekts analysieren wir Ihre Anforderungen und empfehlen den passenden Inferenz-Stack, konkret, kalkulierbar und DSGVO-konform.