Skip to main content
AI Tool Radar
OSI-openLokale Inference und "was läuft auf meiner Maschine"

oMLX

jundot

macOS-nativer LLM-Inference-Server für Apple Silicon mit Continuous Batching und SSD-gestütztem KV-Cache.

16.6k Stars(Stand 2026-06-14)Auf GitHub ansehen

Was ist oMLX?

oMLX ist ein macOS-nativer LLM-Inference-Server, optimiert für Apple Silicon. Er liefert eine SwiftUI-Menubar-App und ein Admin-Dashboard, Continuous Batching, gestuftes KV-Caching mit SSD-Überlauf, Multi-Model-Serving mit LRU-Eviction sowie OpenAI- und Anthropic-kompatible APIs, dazu eingebautes Benchmarking und Unterstützung für Vision-Language-Modelle.

oMLX im Detail

oMLX, ein Apache-2.0-Projekt des Entwicklers jundot, ist ein macOS-nativer Inferenz-Server speziell für Apple Silicon, der dieses Problem praktikabel machen will. Er liefert ein FastAPI-Backend mit OpenAI- und Anthropic-kompatiblen Endpunkten, eine SwiftUI-Menüleisten-App und ein Admin-Dashboard im Browser. Das im README genannte Ziel ist unspektakulär, aber real: Alltagsmodelle im Speicher halten, schwerere bei Bedarf automatisch tauschen, Kontextgrenzen setzen und das Ganze handhabbar halten, ganz ohne Docker-Stack oder dauerhaft laufenden Kommandozeilen-Daemon. Lokale LLMs auf dem Mac sind dank Apples MLX-Framework möglich, der Alltag besteht aber oft aus Terminal-Befehlen, manuellem Modellwechsel und verworfenem Kontext, der bei jeder Anfrage neu berechnet werden muss.

Im Kern setzt oMLX auf den BatchGenerator von mlx-lm für Continuous Batching, mit einem First-come-first-served-Scheduler und standardmäßig acht parallelen Anfragen. Das Besondere ist der gestufte KV-Cache. Heiße Cache-Blöcke bleiben im RAM, und wenn der Speicher voll wird, werden Blöcke als safetensors-Dateien auf die SSD ausgelagert und bei passendem Prefix wiederhergestellt, sogar über Server-Neustarts hinweg. Das ist die Eigenangabe des Projekts und soll bewirken, dass Kontext zwischen Anfragen erhalten bleibt, statt verworfen zu werden. Mehrere Modelle laufen gleichzeitig, mit LRU-Verdrängung, Modell-Pinning, Idle-TTLs und einer prozessweiten Speichergrenze, die standardmäßig auf RAM minus acht Gigabyte gesetzt ist. Ein dreistufiger Memory-Guard soll systemweite Out-of-Memory-Abstürze verhindern.

Die natürliche Zielgruppe sind Apple-Silicon-Nutzer, die ein verwaltetes lokales Inferenz-Setup ohne Terminal wollen. Das Dashboard übernimmt Modell-Downloads von Hugging Face, Echtzeit-Speicherüberwachung, Benchmarking, einen integrierten Chat und die Ein-Klick-Anbindung an Tools wie Claude Code und Copilot. Ein konkreter Anwendungsfall, den das Projekt betont, ist agentisches Coding: Wo eine werkzeuggestützte Sitzung sonst den Kontext überlaufen ließe und eine teure Neuberechnung erzwänge, soll der SSD-gestützte Cache früheren Kontext wiederverwendbar halten. Über reine Textmodelle hinaus unterstützt oMLX Vision-Language-Modelle wie Pixtral und GLM-4V, OCR-Modelle wie DeepSeek-OCR sowie Embedding- und Reranker-Modelle, kann also als ein einziges lokales Backend für mehrere Modelltypen dienen.

Die Grenzen sind deutlich. oMLX läuft ausschließlich auf Apple Silicon und macOS 15.0, ohne Weg für Linux oder Windows, was Server-Deployments oder Multi-GPU-Cluster ausschließt. Das Projekt weist einen großen Backlog offener Issues aus, in der Größenordnung mehrerer Hundert, was auf raue Kanten in einer schnell wachsenden Codebasis hindeutet, die aus einem vllm-mlx-Fork hervorgegangen ist. Die zentrale Abgrenzung zu MLX-LM und llama.cpp liegt vor allem in der GUI- und Serving-Schicht, nicht in der Inferenz-Engine selbst, sodass Kommandozeilen-erfahrene Nutzer weniger gewinnen. Das SSD-Tiering tauscht Plattenplatz und I/O gegen RAM, und die Kontextskalierung ist auf kleinere Kontextmodelle mit Claude Code zugeschnitten, was andeutet, dass sehr große Kontexte auf bescheidener Hardware begrenzt bleiben. Benchmark- und Leistungsangaben sollten auf der eigenen Maschine geprüft werden.

Gegenüber LM Studio, dem naheliegenden kommerziellen Bezugspunkt, bietet oMLX einen stärker serverorientierten und skriptbaren Ansatz mit Open-Source-Transparenz, Anthropic-kompatiblen Endpunkten und dem SSD-gestuften Cache, während LM Studio die rundere, breiter unterstützte und bewährtere Desktop-Option über mehrere Plattformen bleibt. oMLX lohnt sich, wenn du auf einem Mac arbeitest, einen GUI-verwalteten lokalen Server willst, der sich in OpenAI- oder Anthropic-Clients einklinkt, und den persistenten Cache für agentisches Coding schätzt. Zu früh ist es, wenn du Linux- oder Windows-Hosting, Multi-GPU-Inferenz oder produktionsreife Stabilität brauchst, angesichts des Issue-Backlogs und der jungen Codebasis. Für Apple-Silicon-Bastler und Local-First-Entwickler ist es eine glaubwürdige, aktiv entwickelte Option zum Beobachten, kein fertiges Produkt zum Standardisieren.

Vor- & Nachteile

Pros

  • Native SwiftUI-Menubar-App und Admin-Dashboard - polierte Mac-first-Nutzererfahrung
  • Gestufter KV-Cache mit SSD-Überlauf verlängert den effektiven context window über den RAM hinaus (eigene Angabe des Projekts)
  • OpenAI- und Anthropic-API-Kompatibilität macht es zu einem Drop-in-Local-Backend

Cons

  • Nur Apple Silicon - kein Linux oder Windows
  • Großer offener Issue-Rückstand deutet auf raue Kanten hin
  • Unterscheidet sich von MLX-LM und llama.cpp hauptsächlich durch die GUI-Schicht

Lizenz

Apache-2.0 (OSI-open)

Wann interessant

Apple-Silicon-Nutzer, die einen GUI-gesteuerten lokalen Inference-Server ohne Docker oder Kommandozeilen-Daemons wollen.

Wann zu früh

Wenn du Linux- oder Windows-Server-Deployments oder Multi-GPU-Cluster-Inference benötigst.

Kommerzielle Alternative & Verwandtes

  • Kommerzielles Pendant: LM Studio

Dieses Repo war in der Ausgabe 2026-07 des Open-Source-KI-Radars.