Lokale Dokumenten-KI auf dem Mac: Apple Silicon, MLX & oMLX

Warum ein Mac eine überraschend gute lokale KI-Maschine ist

Was Apple Silicon bei lokalen Sprachmodellen über sein Gewicht hinaus schlagen lässt, ist der Unified Memory. Auf einem Mac teilen sich CPU und GPU einen einzigen physischen RAM-Pool, statt Tensoren über einen PCIe-Bus zu einer separaten Grafikkarte hin- und herzukopieren. Es gibt keine Kopie vom Host zum Device, keine VRAM-Grenze, die kleiner ist als dein Arbeitsspeicher. Ein Modell kann fast den gesamten RAM der Maschine nutzen, und ein Mac mit 32 oder 64 GB schlägt im Stillen viele Desktop-GPUs, die nur 8 bis 12 GB dedizierten Speicher mitbringen. Für Dokumenten-Fragen, bei denen ein leistungsfähiges Modell ständig geladen und reaktionsschnell sein soll, ist das genau die Eigenschaft, die du willst.

MLX, MLX-LM und die mlx-community-Modelle

MLX ist Apples offenes Array- und Machine-Learning-Framework, eigens für die Unified-Memory-Architektur von Apple Silicon gebaut. Weil Arrays im geteilten Speicher liegen, laufen Operationen auf CPU oder GPU ohne explizite Kopie. Daher kommt ein großer Teil der Effizienz.

Darauf sitzt MLX-LM, das Paket, das große Sprachmodelle mit MLX ausführt und feintunt. Du musst Modelle auch nicht selbst konvertieren und quantisieren: Die mlx-community-Organisation auf Hugging Face veröffentlicht vorquantisierte MLX-Builds genau der offenen Familien, die du willst: Gemma, Qwen, Mistral, Llama. Modell wählen, Quantisierung wählen, laden.

Der praktische Gewinn: Auf Apple Silicon ist MLX für kleinere Modelle in der Regel schneller als llama.cpp und GGUF. Ist deine Maschine ein Mac und dein Modell im kleinen bis mittleren Bereich, der bequem in den Speicher passt, ist der MLX-Weg meist der schnellste zu einem reaktionsschnellen lokalen Assistenten.

oMLX: ein lokaler Server, auf den pdf2okf zeigen kann

Ein Framework ist noch kein Server. Genau das ist oMLX: ein eigener lokaler Inferenz-Server für Apple Silicon, auf MLX gebaut, der sowohl OpenAI- als auch Anthropic-kompatible Endpunkte bereitstellt. Er läuft als Menüleisten-App. Du startest ihn, er stellt ein Modell bereit, und alles, was diese APIs spricht, kann mit ihm reden. Er braucht Apple Silicon, macOS 15+ und mindestens 16 GB RAM.

Das ist das Teil, auf das es für pdf2okf ankommt. Weil pdf2okf auf jeden OpenAI-kompatiblen Endpunkt zeigen kann, richtest du es direkt auf den lokalen Endpunkt von oMLX und betreibst die ganze Pipeline auf dem Mac vor dir. Es ist BYOK-artig (bring your own key), nur dass der „Anbieter" dein eigener Laptop ist und es weder Schlüssel noch Netzwerkaufruf gibt. Nichts verlässt die Maschine.

Willst du oMLX nicht betreiben, hast du auf derselben Hardware zwei weitere Zugänge zu MLX: Ollama hat in v0.19 (März 2026) ein MLX-Backend bekommen, und LM Studio liefert neben der GGUF- auch eine MLX-Runtime. Alle drei stellen einen OpenAI-kompatiblen Endpunkt bereit, aus Sicht von pdf2okf sind sie also austauschbar.

Wie viel RAM brauchst du wirklich?

Die Faustregel ist einfach. Ein 4-Bit-Modell braucht etwa die Hälfte seiner Parameterzahl in Gigabyte RAM, plus etwas Overhead für das Kontextfenster (den KV-Cache). Also:

| Modellgröße | RAM (4-Bit, ca.) | Bequem auf | |---|---|---| | 7B | ~4–5 GB | jedem modernen Mac | | 27B-Klasse | ~14–16 GB | einem 32-GB-Mac |

Ein leistungsfähiges Modell der 27B-Klasse landet in 4-Bit bei etwa 14 bis 16 GB und passt auf einen 32-GB-Mac, mit Platz für Betriebssystem und Kontext. Die Standard-Quantisierung in der GGUF-Welt ist Q4_K_M (rund 75% kleiner als volle Präzision bei etwa 3% Qualitätsverlust), und die mlx-community-Builds bieten die entsprechenden 4-Bit-MLX-Quantisierungen. Passt du das Modell an deinen echten Speicher an, läuft es; übertreibst du, kriecht es oder lädt nicht.

MLX vs. GGUF auf dem Mac

Beides läuft auf Apple Silicon. GGUF (ausgeführt von llama.cpp, Ollama oder LM Studio) ist der portable Standard, der überall läuft, auf Macs via Metal. MLX ist der Apple-native Weg, der für die kleineren Modelle tendenziell schneller ist. Die ehrliche Empfehlung: Bist du auf einem Mac und jagst Geschwindigkeit bei einem Modell, das in den Speicher passt, probiere zuerst den MLX-Build; willst du ein Format, das zu jeder Maschine reist, ist GGUF die sichere Wahl. Du musst dich nicht auf ewig entscheiden. Deinen Dokumenten ist egal, welches du fährst.

Wo pdf2okf hineinpasst

pdf2okf ist von Grund auf modell- und runtime-agnostisch. Es erzeugt ein OKF-kompatibles Bundle aus einfachen Markdown-Konzeptdateien, und die Struktur lebt im Bundle, nicht im Modell. Modell und Server darunter sind also austauschbare Teile. Richte pdf2okf auf oMLX, auf Ollamas MLX-Backend oder auf LM Studio, und dein Mac betreibt das Ganze: Die Dokumente bleiben auf der Platte, die Inferenz läuft im Unified Memory, und nichts verlässt die Maschine. Es ist die sauberste Form lokaler KI, und auf Apple Silicon obendrein eine schnelle. Die Runtimes im direkten Vergleich findest du in Ollama vs. llama.cpp vs. LM Studio vs. vLLM; das große Bild liefert KI lokal betreiben 2026.