vllm-mlx: Continuous Batching und zwei API-Dialekte auf Apple Silicon
High-performance OpenAI and Anthropic compatible LLM inference server for Apple Silicon. Native MLX, continuous batching, multimodal models, MCP tool calling, and Claude Code support.
Auf einen Blick
- Was ist das?
- Ein Inferenzserver für Macs mit M-Chips, der OpenAI- und Anthropic-Endpunkte aus einem Prozess bedient. Die README verspricht vLLM-ähnliche Batch-Verwaltung, die Beispiele zeigen, wo die Grenzen liegen.
- Für wen ist es gedacht?
- Wer auf einem M-Series-Mac einen lokalen Endpunkt braucht, der sowohl OpenAI-SDKs als auch Claude Code ohne Proxy dazwischen bedient, findet hier einen einzelnen Prozess statt zweier Server. Wer CUDA-Hardware oder Multi-Node-Serving im Einsatz hat, sollte nicht wechseln: das Projekt nennt ausschließlich Apple Silicon als Zielplattform.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 10 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Zwei API-Dialekte aus einem Prozess
Der Ausgangspunkt ist ein praktisches Problem: Wer lokal auf einem Mac ein Modell laufen lässt und sowohl OpenAI-SDK-Code als auch Claude Code nutzen will, betreibt üblicherweise zwei Server oder einen Übersetzungsproxy dazwischen. vllm-mlx bedient laut README beide Schnittstellen aus einem Prozess. Auf der OpenAI-Seite stehen /v1/chat/completions, /v1/completions, /v1/embeddings, /v1/rerank und /v1/responses. Auf der Anthropic-Seite /v1/messages mit Streaming, Tool-Nutzung und System-Prompts. Der Claude-Code-Pfad ist in der README als zwei export-Zeilen dokumentiert: ANTHROPIC_BASE_URL auf http://localhost:8000 und ANTHROPIC_API_KEY auf not-needed, danach der Aufruf claude. Das ist die Zielgruppe: Entwickler mit einem M-Chip-Mac, die keinen Cloud-Endpunkt anbinden wollen, aber ihre bestehenden Clients nicht umschreiben möchten. Der Anspruch ist ausdrücklich vLLM-artig, nicht Ollama-artig. Der Unterschied liegt in der Batch-Verwaltung, nicht im Modellformat.
Continuous Batching, Paged KV Cache und die Trie-Struktur
Die README nennt vier Speicher- und Durchsatzmechanismen, die zusammenwirken. Continuous Batching hält mehrere gleichzeitige Anfragen in derselben Dekodierrunde, statt sie sequenziell abzuarbeiten. Der Paged KV Cache teilt den Key-Value-Speicher in Seiten auf, damit Anfragen Speicher gemeinsam nutzen können. Darüber sitzt ein Prefix Cache auf Trie-Basis, der gemeinsame Anfangssequenzen über Requests hinweg wiederverwendet. Die vierte Ebene ist ein SSD-gestützter Cache, der Prefix-Daten auf die Platte auslagert; aktiviert wird er über --ssd-cache-dir, gedacht für Agenten mit langem Kontext. Zusätzlich lassen sich populäre Prefixe beim Start vorladen, gesteuert über --warm-prompts. Die README beziffert den Effekt dieser Vorladung mit 1.3 bis 2.25x auf die Time to First Token. Das ist eine Angabe aus der Projektdokumentation, keine unabhängige Messung. Wer die Batch-Ergebnisse selbst nachvollziehen will, findet in docs/benchmarks/ Material zu Continuous Batching, KV-Cache-Quantisierung in 4 Bit, 8 Bit und fp16 sowie zu MoE-top-k-Sweeps.
Installation und der erste Serverstart
Der Einstieg ist ein pip-Befehl, gefolgt von einem serve-Aufruf mit Modellkennung, Port und Batch-Flag: pip install vllm-mlx, dann vllm-mlx serve mlx-community/Llama-3.2-3B-Instruct-4bit --port 8000 --continuous-batching. Die Modellnamen folgen der mlx-community-Konvention und enthalten die Quantisierungsstufe im Namen. Für Audio kommt ein Extra: pip install vllm-mlx[audio]. Auf macOS ist für nicht-englische TTS zusätzlich espeak-ng über Homebrew nötig. Ein eigenes Embedding-Modell lässt sich parallel laden, etwa mit --embedding-model mlx-community/all-MiniLM-L6-v2-4bit, und wird dann unter dem Modellnamen im embeddings-Aufruf adressiert. Reasoning-Modelle brauchen einen expliziten Parser: --reasoning-parser qwen3 trennt den Denktext vom Ergebnis, das OpenAI-SDK liest ihn anschließend über r.choices[0].message.reasoning. Für Qwen3-30B-A3B nennt die README --moe-top-k zur Reduktion aktiver Experten, für Qwen3-Next das Flag --mtp, und --spec-prefill für aufmerksamkeitsbasiertes Prefill. Observability ist optional: --metrics schaltet den /metrics-Endpunkt im Prometheus-Format frei.
Multimodalität und strukturierte Ausgabe
Der Server verarbeitet Text, Bild, Video und Audio in einem Prozess. In Chat-Anfragen erscheinen Bilder als image_url-Content-Block, Audio als audio_url. Als Vision-Modelle listet die README Gemma 3, Gemma 4, Qwen3-VL, Pixtral und Llama-Vision-Varianten. Für Sprachausgabe sind elf Stimmen über Kokoro, Chatterbox, VibeVoice und VoxCPM dokumentiert, für Transkription die Whisper-Familie. Strukturierte Ausgabe läuft über response_format mit type json_schema und wird laut README mit lm-format-enforcer durchgesetzt. Beim Reranking-Endpunkt /v1/rerank gibt es eine bemerkenswerte Designentscheidung: Der Forward-Pfad unterstützt Standard-Gewichte vom Typ BERT und XLM-RoBERTa mit den hidden_act-Werten gelu, gelu_new, gelu_fast, relu sowie silu beziehungsweise swish. Andere Aktivierungen schlagen explizit fehl. Die README begründet das damit, dass eigene Reranker-Architekturen lieber einen dedizierten Adapter ergänzen sollen, statt stillschweigend die falsche Aktivierung zu verwenden. Ein Fehler ist hier die bessere Ausgabe als ein plausibles falsches Ranking.
Wo das Projekt an seine Grenzen stößt
Die Plattformbindung ist absolut. Die README nennt Apple Silicon der Generationen M1 bis M5 mit Metal-Kernels über MLX und schließt damit jede CUDA- oder x86-Umgebung aus. Wer bereits NVIDIA-Hardware betreibt, hat hier nichts zu gewinnen. Zweitens stammen alle Performance-Zahlen in der README von einem einzigen System, einem M4 Max mit 128 GB. Für kleinere Konfigurationen, etwa ein MacBook Air mit 16 GB, gibt es in der README keine Vergleichswerte. Das Unified Memory ist zugleich die harte Obergrenze: Modellgewicht, KV Cache und multimodale Eingaben konkurrieren um denselben Speicher. Der SSD-Cache über --ssd-cache-dir hilft bei langem Kontext, aber die README beschreibt nicht, welcher Durchsatz dabei von der Platte kommt. Bleibt noch die Versionslage: zwischen v0.4.0 im Juni 2026 und v0.4.1 im August 2026 liegt ein Release-Zyklus von rund sieben Wochen, davor ein Release Candidate. Das deutet auf ein Projekt in aktiver Entwicklung, nicht auf eine eingefrorene Schnittstelle. Wer die Flags --moe-top-k, --mtp oder --spec-prefill produktiv setzt, sollte deren Verhalten an die eigene Modellversion binden.
Abgrenzung zu mlx-lm und Ollama
Der naheliegendste Vergleich ist mlx-lm direkt. Dessen Server ist ein einzelner Modellprozess ohne Batch-Verwaltung über Anfragen hinweg; die README von vllm-mlx nennt genau das als Unterscheidungspunkt, nämlich Continuous Batching, Paged KV Cache, Prefix Caching und SSD-Cache als zusätzliche Schicht. Ollama wiederum verwaltet Modelle und lädt sie bei Bedarf, ist aber auf einen OpenAI-kompatiblen Endpunkt ausgelegt. Der Anthropic-Pfad /v1/messages mit Streaming, Tool-Nutzung und System-Prompts fehlt dort, weshalb Claude Code gegen Ollama einen Übersetzungsproxy braucht. vllm-mlx liefert diesen Pfad selbst. Der Preis dafür ist eine andere Betriebsform: Das Modell wird beim serve-Aufruf festgelegt, nicht über einen Modellmanager nachgeladen. Wer viele Modelle abwechselnd testet, hat mit Ollama weniger Reibung; wer einen festen Endpunkt für Agenten mit langem Kontext braucht, fährt mit dem Batch- und Cache-Stack von vllm-mlx besser.
Wartung, Lizenz und Prüfschritte
Lizenziert ist das Projekt unter Apache-2.0, was kommerzielle Nutzung und Modifikation erlaubt und eine Weitergabe der Lizenzhinweise verlangt. Das ist eine Einordnung, keine Rechtsberatung; wer den Code in ein Produkt einbettet, sollte die Bedingungen selbst prüfen. Das letzte Release v0.4.1 stammt vom 12. August 2026, der letzte Push ins Repository vom 6. September 2026. Vor einem Upgrade lohnt ein Blick auf die Release Notes, weil sich Flags zwischen Minor-Versionen ändern können. Die README verlinkt docs/benchmarks/ mit Ergebnissen zu Continuous Batching, KV-Cache-Quantisierung und MoE-top-k-Sweeps; diese Zahlen sind die einzige im Material greifbare Grundlage für eine Kapazitätsplanung. Ein eingebautes Werkzeug hilft beim Nachmessen: vllm-mlx bench-serve akzeptiert --url, --concurrency, --prompts, --workload, --repetitions und --output und schreibt CSV oder JSON. Wer das Projekt bewertet, sollte diesen Lauf mit dem eigenen Modell und dem eigenen Mac wiederholen, statt die M4-Max-Tabelle zu übernehmen.
Redaktionelles Fazit
Wer auf einem M-Series-Mac einen lokalen Endpunkt braucht, der sowohl OpenAI-SDKs als auch Claude Code ohne Proxy dazwischen bedient, findet hier einen einzelnen Prozess statt zweier Server. Wer CUDA-Hardware oder Multi-Node-Serving im Einsatz hat, sollte nicht wechseln: das Projekt nennt ausschließlich Apple Silicon als Zielplattform. Vor dem produktiven Einsatz lohnt ein Blick in docs/benchmarks/ und ein eigener Lauf mit vllm-mlx bench-serve gegen das konkret genutzte Modell, weil die README nur Messwerte für M4 Max mit 128 GB aufführt.
Community-Notizen