mlx-serve: nativer Inference-Server für Apple Silicon, in Zig statt Python

Ein Binary statt Python-Stack für lokale Modelle

Die meisten lokalen Inference-Setups auf dem Mac bestehen aus mehreren Schichten: einer Python-Umgebung mit mlx-lm oder llama-cpp-python, einem Wrapper, der daraus einen HTTP-Endpunkt macht, und einem Client, der diesen Endpunkt anspricht. mlx-serve setzt genau dort an und ersetzt die mittleren Schichten durch einen in Zig geschriebenen Server. Die README formuliert das als 'No Python. No cloud. No Electron.' und meint damit sowohl den Build als auch die Laufzeit. Adressiert sind damit zwei Gruppen: Entwickler, die Claude Code, den OpenAI-SDK oder Continue gegen ein lokales Modell laufen lassen wollen, ohne eine Python-Toolchain zu pflegen, und Anwender, die eine grafische Oberfläche bevorzugen und trotzdem denselben Serverprozess nutzen. Der Server lauscht laut README auf http://localhost:11234, und genau diese Adresse ist der gemeinsame Nenner zwischen App, CLI und allen kompatiblen Clients.

Drei API-Oberflächen auf einem Port

Der interessanteste Teil des Entwurfs ist die Protokollschicht. mlx-serve implementiert nach eigener Darstellung die OpenAI-kompatible API, die Anthropic Messages API und zusätzlich die Ollama-API mit Endpunkten wie /api/chat, /api/generate, /api/tags, /api/embed und /api/pull. Das bedeutet konkret: Ein Werkzeug, das bisher gegen einen Ollama-Daemon auf Port 11434 zeigte, lässt sich auf 11234 umbiegen, ohne dass sein Code angepasst werden muss. Für Claude Code ist die Anthropic-Oberfläche relevant, für den OpenAI-SDK-Aufruf die andere. Der Datenfluss bleibt in allen Fällen gleich: Der Client schickt einen Chat- oder Completion-Request, der Server lädt das benannte Modell bei Bedarf nach, führt die Inferenz auf der Metal-Ebene aus und streamt die Antwort zurück. Bemerkenswert ist, dass der Server laut README Modelle erst bei Nennung lädt ('models load on demand by name'). Das hält den Leerlaufverbrauch niedrig, kostet aber beim ersten Request Zeit.

MLX und GGUF im selben Prozess

Die meisten lokalen Server entscheiden sich für eine der beiden Gewichtsformate. mlx-serve beansprucht beide: native MLX-Modelle und jedes GGUF von HuggingFace, wobei llama.cpp nach README-Angabe eingebettet ist. Das ist eine bewusste Architekturentscheidung mit Kosten. Ein eingebettetes llama.cpp bedeutet, dass die Bibliothek mitgebaut und mitgepflegt werden muss, statt als externe Abhängigkeit zu laufen. Der Nutzen liegt auf der Hand: Wer ein Modell nur als GGUF findet, muss nicht auf einen zweiten Server ausweichen. Wer ohnehin nur MLX-Gewichte verwendet, trägt diesen Teil des Builds ohne Gegenwert mit. In der Vergleichstabelle der README wird GGUF bei Ollama mit einem gelben Punkt bewertet und bei mlx-lm als nicht unterstützt geführt; das ist die Stelle, an der sich das Projekt am deutlichsten von mlx-lm abgrenzt.

Installation über Homebrew oder aus dem Quelltext

Der einfachste Weg führt über Homebrew mit einem eigenen Tap: brew tap ddalcu/mlx-serve https://github.com/ddalcu/mlx-serve, danach brew install --cask mlx-core für die App oder brew install mlx-serve für CLI und Server ohne GUI. Die CLI folgt bewusst dem Ollama-Muster: mlx-serve run gemma4 lädt Gemma 4 E4B in 4-Bit, startet den Server und öffnet eine REPL im Terminal. mlx-serve pull qwen3.6:27b lädt nur herunter, laut README fortsetzbar und direkt von Hugging Face. mlx-serve list zeigt den lokalen Bestand, mlx-serve serve bedient alles Geladene. Kurznamen, org/repo-IDs und name:tag-Notation werden gleichermaßen akzeptiert. Der Quelltextbau verlangt Xcode 26.2 oder neuer mit der Metal-Toolchain-Komponente; falls xcrun -sdk macosx metal --version fehlschlägt, hilft xcodebuild -downloadComponent MetalToolchain. Danach: git clone --recurse-submodules, brew bundle install --file=Brewfile für cmake und webp, schließlich ./app/build.sh. Zig, mlx und llama.cpp werden laut README vom Skript gepinnt und geholt oder gebaut.

Die Geschwindigkeitszahl bleibt eine Herstellerangabe

Die README nennt für die Decode-Geschwindigkeit einen Geomean von +26 Prozent gegenüber LM Studio bei identischen MLX-Gewichten und den Shipping-Defaults, sowie +11 Prozent gegenüber mlx-lm und geschätzte -15 Prozent für Ollama im GGUF-Vergleich. Diese Zahlen stammen aus der Projektkommunikation, nicht aus einer unabhängigen Messung, und die Fußnote zur Ollama-Zeile räumt selbst ein, dass der Vergleich GGUF gegen GGUF läuft, weil Ollama MLX kaum ausführen kann. Wer die Zahl als Entscheidungsgrundlage nutzen will, muss sie auf seiner eigenen Hardware mit seinen eigenen Gewichten nachstellen. Eine Randbedingung ist dabei hart: macOS 26.2 oder neuer auf Apple Silicon, sonst startet nichts. Das schließt ältere Intel-Macs und alles vor der genannten Systemversion aus, unabhängig von der Leistungsfrage.

Agent-Modus, Sandbox und die Frage der Angriffsfläche

Neben der reinen Textinferenz bringt mlx-serve einen Agent-Modus mit MCP-Werkzeugaufrufen mit, laut README zehn Werkzeuge, dazu eine 'sandboxed agent shell' in einer isolierten Linux-VM sowie Ein-Klick-Starter für Claude Code, OpenCode und Pi. Das ist mehr Funktionsumfang, als ein Inferenzserver üblicherweise trägt. Die Sandbox ist die richtige Reaktion auf das Problem, dass ein Agent Shell-Befehle ausführen darf, aber sie ist auch ein zusätzlicher beweglicher Teil, der gebaut, aktualisiert und verstanden werden will. Wer nur eine Chat-Completion gegen ein lokales Modell braucht, zahlt hier für Code, den er nie ausführt. Umgekehrt gilt: Wer den Agent-Modus tatsächlich nutzt, sollte vorher klären, was die VM vom restlichen System sieht, denn dazu macht die README keine präzise Aussage. Die Lizenzangabe ist ein weiterer offener Punkt. Der Repository-Metadatensatz führt NOASSERTION, während das Lizenz-Badge in der README MIT anzeigt. Wer mlx-serve weiterverbreiten oder einbetten will, muss die LICENSE-Datei im Repository selbst lesen, statt sich auf das Badge zu verlassen. Das ist keine Rechtsberatung, sondern nur der Hinweis auf den Widerspruch.

Wo llama.cpp und mlx-lm die bessere Wahl bleiben

Die naheliegende Alternative ist llama.cpp in seiner reinen Form, typischerweise über llama-server. Der Unterschied liegt nicht im Format, beide lesen GGUF, sondern im Zuschnitt: llama-server liefert eine OpenAI-kompatible Oberfläche und sonst wenig. Keine Menüleisten-App, kein Agent-Loop, keine Bild-, Video-, Sprach- oder 3D-Generierung, dafür ein kleinerer Bauplan mit weniger Abhängigkeiten und einer längeren Liste unterstützter Plattformen, darunter Linux und Windows. Wer Modelle auf einer heterogenen Flotte betreibt oder den Server in ein Container-Image packen will, ist mit llama.cpp besser bedient, weil mlx-serve an Apple Silicon und eine aktuelle macOS-Version gebunden ist. Die zweite Alternative ist mlx-lm direkt: Es bleibt die Referenz für MLX-Inferenz, verlangt aber eine Python-Laufzeit und bietet laut der Vergleichstabelle der README weder eine OpenAI-kompatible API noch Continuous Batching. Wer bereits eine Python-Pipeline um mlx-lm herum gebaut hat und sie beherrscht, hat wenig Grund zu wechseln, außer eben dem Wunsch, Python loszuwerden.

Wartung, Release-Takt und was vor der Übernahme zu prüfen ist

Der Release-Takt ist dicht: v26.9.2 vom 9. September 2026, v26.9.1 vom 3. September, v26.8.11 vom 29. August, jeweils mit Änderungen an Modellunterstützung und MLX-Version. Ein solcher Rhythmus bedeutet laufenden Pflegeaufwand auf beiden Seiten. Wer mlx-serve einsetzt, muss mit häufigen Aktualisierungen rechnen, weil neue Modellarchitekturen und MLX-Versionen nachgezogen werden. Der Quelltextbau bindet zudem Xcode 26.2 mit Metal-Toolchain, cmake und webp über die Brewfile, und das Build-Skript lädt oder baut Zig, mlx und llama.cpp selbst. Das ist reproduzierbar, solange die Pins aktuell bleiben, und es ist ein Bruchpunkt, sobald eine der gepinnten Quellen nicht mehr erreichbar ist. Vor einer Übernahme in eine bestehende Toolchain sind drei Dinge konkret zu klären: erstens die tatsächliche Lizenz in der LICENSE-Datei angesichts der Abweichung zwischen NOASSERTION und MIT-Badge, zweitens ob die Zielmaschine macOS 26.2 oder neuer fährt, und drittens ob die Decode-Geschwindigkeit mit den eigenen Gewichten tatsächlich über der bisherigen Lösung liegt. Der letzte Punkt lässt sich nicht aus der README ableiten, sondern nur durch einen eigenen Lauf gegen denselben Prompt und dieselbe Modellquantisierung.

Redaktionelles Fazit

Wer auf Apple Silicon lokal Modelle betreiben will und Clients wie Claude Code, Continue oder Open WebUI ohne Python-Zwischenschicht anbinden möchte, findet in mlx-serve einen architektonisch eigenständigen Kandidaten: ein einzelnes Zig-Binary, das MLX und GGUF hinter drei API-Oberflächen vereint. Wer dagegen reproduzierbare Messwerte braucht, bevor er seine Toolchain umstellt, sollte zuerst den Build aus dem Quelltext unter docs/building.md nachvollziehen und die Decode-Geschwindigkeit mit den eigenen Gewichten gegen die bisherige Lösung messen, statt die in der README genannte Zahl von +26 Prozent gegenüber LM Studio zu übernehmen. Für reine GGUF-Nutzung ohne MLX-Bedarf bleibt llama.cpp die schlankere Wahl, und wer kein macOS 26.2 oder neuer einsetzen kann, ist hier ohnehin außen vor.

Offizielle Quellen

1. ddalcu/mlx-serve on GitHub
2. Issues
3. Project website
4. README
5. Releases