Rapid-MLX: schnellere lokale KI auf Apple Silicon

Auf X stellt ein Entwickler ein neues Werkzeug vor und nennt es, mit dem üblichen Vorbehalt, die möglicherweise schnellste lokale Inferenz-Engine auf dem Mac. Rapid-MLX ist quelloffen, läuft nur auf Apple Silicon und will ein direkter Ersatz für Ollama sein, bei zwei bis vier mal mehr Tempo. Der Quellcode liegt öffentlich auf GitHub unter Apache-2.0-Lizenz.

Wir haben schon Ende Juli beschrieben, dass auf dem Mac Studio die Software über das Tempo entscheidet, nicht allein die Hardware. Rapid-MLX ist genau davon ein neuer, benennbarer Fall: eine Engine in Version 0.11.1, deren Dokumentation den Stand 28. Juli 2026 trägt und die konkrete Messwerte gegen Ollama legt, statt nur allgemein schneller zu sein.

Was Rapid-MLX ist

Rapid-MLX baut direkt auf MLX auf, dem hauseigenen ML-Framework von Apple, ohne Umweg über llama.cpp oder eine Metal-Zwischenschicht. Das ist der technische Kern des Versprechens: reine MLX-Kernel, abgestimmt auf den geteilten Speicher von Apple Silicon.

Für den Alltag zählt weniger die Architektur als die Schnittstelle. Rapid-MLX spricht die OpenAI- und die Anthropic-API nach, unter Adressen wie /v1/chat/completions. Ein Programm, das heute gegen ein Cloud-Modell arbeitet, lässt sich damit auf ein lokales Modell umbiegen, indem man nur die Adresse ändert. Der Entwickler nennt Claude Code, Cursor und Aider als Werkzeuge, die so ohne Anpassung funktionieren. Nach Projektangaben deckt die Engine über 200 Modellvarianten ab, darunter Qwen3.5 und 3.6, Gemma 4 und weitere.

Die Installation läuft über ein Skript, ein Einzeiler im Terminal. Das senkt die Hürde für einen Test, verlagert aber auch Verantwortung: Ein Skript aus dem Netz blind auszuführen, ist auf einem Arbeitsrechner mit Zugriff auf Firmendaten kein Automatismus, sondern eine Entscheidung.

Die Zahlen, und wer sie gemessen hat

Der Entwickler nennt auf einem Mac Studio M3 Ultra mit 192 GB unter anderem diese Werte gegen Ollama:

• Qwen3.5-9B: 66 gegen 16 Token pro Sekunde, also rund das Vierfache.
• Qwen3.5-4B: 95 gegen 38 Token pro Sekunde.
• Devstral-24B: 31 gegen 13 Token pro Sekunde.

Dazu kommt ein Wert, der im Werkzeug-Alltag oft mehr wiegt als der reine Durchsatz: die Zeit bis zum ersten Token. Bei wiederholten Anfragen im selben Gespräch soll ein Verfahren namens DeltaNet den Zustand zwischenspeichern und diese Wartezeit von etwa 1,5 Sekunden auf unter 200 Millisekunden drücken. Im Zwischenspeicher nennt das Projekt 0,08 Sekunden.

Jetzt der ehrliche Teil. Diese Zahlen stammen vom Entwickler selbst, gemessen auf seiner Maschine. In der Diskussion, in der er die Engine für ein bekanntes Coding-Werkzeug vorschlägt, steht bis heute keine einzige unabhängige Antwort, kein Gegentest, keine Bestätigung durch Dritte. Das macht die Werte nicht falsch. Es macht sie zu einer Herstellerangabe, und die liest man anders als eine geprüfte Messung.

Für einen Betrieb heißt das praktisch: Eine Vervierfachung im Marketing bedeutet nicht, dass Ihre Aufgabe vier mal schneller wird. Der größte Sprung zeigt sich beim kleineren Modell und im günstigsten Fall. Wie viel davon bei Ihrem Modell, Ihrer Kontextlänge und Ihrer Hardware ankommt, sagt nur ein Test auf Ihrer eigenen Maschine. Ollama misst auf demselben Gerät in wenigen Minuten mit, das ist die Vergleichsbasis, die zählt.

Was für einen Betrieb wirklich zählt

Reines Tempo ist selten der Engpass. Wer lokale KI im Mittelstand einführt, stolpert eher über Betrieb, Wartung und Verlässlichkeit als über Token pro Sekunde. Drei Punkte wiegen bei einem so jungen Projekt schwerer als der Durchsatz.

Erstens die Reife. Version 0.11.1 ist eine frühe Zahl. Ollama und llama.cpp haben Jahre an Fehlerberichten, Paketen und Anleitungen hinter sich. Ein neues Werkzeug kann technisch besser sein und trotzdem im falschen Moment eine Ecke haben, für die es noch keine gefundene Lösung gibt. Wer allein arbeitet und selbst debuggen kann, lebt damit. Wer ein System für Kollegen betreibt, die nur damit arbeiten wollen, zahlt jeden solchen Sonderfall in Ausfallzeit.

Zweitens der Support. Hinter Rapid-MLX steht sichtbar eine einzelne Person. Das ist kein Vorwurf, viele gute Werkzeuge fangen so an. Aber für einen Betrieb, der ein System in den Arbeitsablauf hängt, ist die Frage berechtigt, wer in einem Jahr Fehler behebt und Modelle nachzieht.

Drittens die Sicherheit. Der Vorteil einer lokalen Engine ist, dass keine Anfrage das Haus verlässt. Das gilt aber nur, wenn das Werkzeug hält, was es verspricht. Ein Server, der eine OpenAI-Schnittstelle im Netz öffnet, will abgesichert sein, sonst ist die vermeintlich private Lösung ein offenes Tor im eigenen Netz. Der Gewinn an Souveränität, den wir unter lokale KI beschreiben, hängt an sauberem Betrieb, nicht am Benchmark.

Wann ein Wechsel sich lohnt, wann nicht

Zwei Lager, klare Empfehlung.

Für Entwicklung und Erprobung auf einem einzelnen Mac ist Rapid-MLX einen Nachmittag wert. Die OpenAI-Schnittstelle macht den Wechsel fast kostenlos: Adresse ändern, das eigene Werkzeug gegenlaufen lassen, mit derselben Aufgabe gegen Ollama messen. Fällt der Unterschied auf Ihrer Maschine deutlich aus, haben Sie gratis Tempo gewonnen. Fällt er klein aus, wissen Sie es mit einer Stunde Aufwand und bleiben bei dem, was läuft.

Für den Produktivbetrieb, an dem Kollegen oder Kundenprozesse hängen, ist der Zeitpunkt zu früh. Hier zählt eine Lösung, die seit Monaten stabil läuft und Ansprechpartner hat, mehr als der schnellste Balken in einer Grafik. Behalten Sie in jedem Fall die bisherige Engine als Rückfallebene, solange die neue sich nicht über Wochen im echten Betrieb bewährt hat.

Und die Grundfrage bleibt dieselbe wie bei jedem Modellthema: Rechnet sich lokale KI für Sie überhaupt, gemessen an Vertraulichkeit und Anfragevolumen, oder ist die Cloud bei Ihrem Muster günstiger. Wenn Sie diese Abwägung einmal sauber mit Ihren eigenen Zahlen durchgehen wollen, statt sich von einem Benchmark treiben zu lassen, starten Sie mit einem Pilotprojekt. Wir bauen den Aufbau mit Ihnen und messen ihn an Ihrer Aufgabe, nicht an fremden Balken.