Rapid-MLX: Ein LLM-Inferenzserver für Apple Silicon, gebaut für Coding-Agenten

Apple Silicon nimmt bei lokalen LLMs seit Langem eine unbequeme Stellung ein. Der einheitliche Speicher erlaubt es, auf einem einzigen Mac mini ein quantisiertes Modell mit mehreren Milliarden Parametern zu halten, doch die Serving-Schicht darum herum ist weit weniger ausgereift als das, was CUDA-Nutzer gewohnt sind. Rapid-MLX zielt genau auf diese Lücke. Es ist ein quelloffener Inferenzserver unter Apache-2.0-Lizenz, gebaut auf Apples MLX-Framework. Er bietet sowohl OpenAI-artige als auch Anthropic-artige Endpunkte an, nämlich /v1/chat/completions, /v1/responses und /v1/messages. Der erklärte Schwerpunkt ist schlicht: zuverlässige Tool-Aufrufe für Coding-Agenten. Diese Wahl ist aufschlussreich, denn das Projekt macht rohe Geschwindigkeit nicht zum einzigen Ziel. Es gewichtet gleich hoch, ob ein Agent Werkzeuge aufrufen kann, ohne dass etwas bricht. Auch die Installation ist bewusst gewöhnlich: Das Paket liegt auf PyPI und in Homebrew core, ein Befehl, brew install rapid-mlx, startet den Server, und es gibt eine Desktop-App sowie einen Modell-Mirror.

Die Geschwindigkeit ist das Hauptargument. Laut Projekt erreicht das Decoding bis zum Vierfachen von Apples eigenem mlx-lm und bei einer typischen Aufgabe etwa das 1,5-Fache, mit gleichem Modell und gleichen Gewichten. Die Zahlen stammen von Qwen3.5-9B in 4 Bit auf einem Mac mini M4 Pro, mit Greedy-Decoding, beide Server in Standardeinstellung. Zwei Vorbehalte gelten. Erstens zeigt der Abstand zwischen „bis zu 4-fach“ und „typisch 1,5-fach“, dass der Gewinn stark von der Form der Last abhängt: Szenarien mit Cache-Treffern oder mehreren gleichzeitigen Anfragen profitieren am meisten. Zweitens deckt der Test nur ein Modell, eine Maschine und einen Decoding-Modus ab, und veröffentlicht hat ihn das Projekt selbst. Die Werte sind daher ein Richtungshinweis und sollten mit eigenen Modellen und Aufgaben nachgemessen werden. Positiv ist, dass das Projekt Ergebnisse je Aufgabe, Methode und Rohdaten offenlegt. So können Außenstehende prüfen, statt einer einzelnen Marketingzahl zu glauben.

Hinter diesen Zahlen wirken mehrere Mechanismen zusammen. Der erste ist Continuous Batching: Viele Anfragen schreiten in einer gemeinsamen Decoding-Schleife voran, sodass eine lange Anfrage die übrigen nicht aushungert. Der zweite ist das Präfix-Caching. Rapid-MLX hält einen Präfix-Cache in Form eines Radixbaums im Speicher, sichert Zustands-Snapshots für Modelle mit hybrider Architektur, schreibt den Cache beim Beenden auf die Platte und stellt ihn beim Start wieder her. Für Coding-Agenten ist das besonders wichtig. In jeder Runde sendet ein Agent einen langen Systemprompt, die Tool-Definitionen und den bisherigen Gesprächsverlauf erneut, und der größte Teil dieses Präfixes gleicht der Vorrunde. Wiederverwendung des Caches spart den Großteil des Prefills. Der dritte Mechanismus ist ein quantisierter KV-Cache, der etwas Genauigkeit gegen Speicher tauscht, damit der begrenzte einheitliche Speicher längere Kontexte oder mehr parallele Sitzungen fasst. Zusammen zielen sie auf das statistische Profil von Agentenverkehr mit langen Präfixen, vielen Runden und wiederholten Aufrufen, nicht auf den Spitzendurchsatz einer einzelnen Frage.

Das Parsen von Tool-Aufrufen ist der zweite Hauptstrang und unterscheidet das Projekt von vielen Mitbewerbern. Modellfamilien geben Tool-Aufrufe in unterschiedlichen Textformaten aus: mal als XML-artige Tags, mal als JSON-Fragmente, mal vermischt mit Denktext. Parst der Server schlecht, erhält der Agent fehlerhafte Argumente und bricht mitten in der Aufgabe ab. Rapid-MLX bringt 27 Parser-Module mit, dazu einen Fallback mit automatischer Erkennung, damit Nutzer beim Modellwechsel nichts von Hand anpassen müssen. Laut der Vergleichstabelle des Projekts bietet der Server von mlx-lm Tool-Aufrufe nur für Modelle, deren Tokenizer dies deklariert, während Ollama und LM Studio jeweils eigene Dokumentation und Umsetzung pflegen. Eine Warnung gehört dazu: Die Zahl der Parser ist nicht gleich Zuverlässigkeit. Der echte Test ist, ob sich in langen Gesprächen, bei verschachtelten Argumenten oder bei einem mitten im Aufruf abgebrochenen Stream noch ein gültiger Aufruf rekonstruieren lässt. Das sollten Leser mit ihrem eigenen Agenten-Framework prüfen.

Im größeren Feld hat Rapid-MLX reichlich Konkurrenz. oMLX baut ebenfalls auf MLX und nutzt einen gestuften KV-Cache mit heißer Speicherebene und kalter SSD-Ebene. Ollama verarbeitet standardmäßig eine Anfrage parallel je Modell und hat eine MLX-Engine für safetensors-Modelle ergänzt. LM Studio liefert sowohl eine llama.cpp- als auch eine MLX-Engine. Der mit mlx-lm gelieferte Server bearbeitet bei quantisiertem KV-Cache nur eine Anfrage zugleich. Die vom Projekt erstellte Tabelle, datiert auf den 26. September 2026, zeigt selbst, wie schnell diese Kategorie auf einen gemeinsamen Funktionsumfang zuläuft. Unterschiede entstehen künftig durch Detailarbeit und gemessenes Verhalten. Wer auf einem Mac einen lokalen Coding-Agenten betreibt, sollte Rapid-MLX mit demselben Modell und derselben Aufgabe gegen die bisherige Lösung antreten lassen und drei Werte beobachten: die Zeit bis zum ersten Token, die Cache-Trefferquote über eine lange Sitzung und die Fehlerquote bei Tool-Aufrufen. Sie sagen mehr über die Eignung als jeder Geschwindigkeitsfaktor.