← Alle Beitrage

MLX auf Apple Silicon: Wenn Sie Ihr eigenes Modell brauchen, nicht Apples

Apples Foundation Models Framework reicht Ihnen genau ein Modell: das des Systems, versiegelt, kostenlos und aktualisiert nach Apples Zeitplan. Für die meisten Sprachaufgaben auf dem Gerät ist das genau das richtige Werkzeug, und darüber hinauszugreifen wäre ein Fehler. Manche Arbeit verlangt jedoch nach einem Modell, das Sie selbst wählen: ein bestimmtes Open-Weight-LLM, eine von Ihnen fixierte Version, ein auf eigenen Daten feingetuntes Modell oder eine Fähigkeit, die das Systemmodell schlicht nicht hat. Wenn Ihr eigenes Modell auf dem Gerät laufen soll, heißt die Schicht unterhalb von Foundation Models MLX1.

MLX ist Apples Array-Framework für maschinelles Lernen auf Apple Silicon, mit einer Swift-API (MLX Swift), die Sie direkt in eine App einbetten2. Es ist kein System-Framework, das Sie aufrufen, sondern eine Bibliothek, die Sie zusammen mit den Modellgewichten ausliefern. In diesem Unterschied steckt die gesamte Abwägung, und wenn Sie ihn verstanden haben, können Sie entscheiden, ob Sie eine Schicht tiefer steigen oder dort bleiben, wo Apple Sie hingestellt hat.

Kurzfassung

  • MLX ist ein NumPy-ähnliches Array-Framework, gebaut für Apple Silicon, mit verzögerter Auswertung, kombinierbaren Funktionstransformationen und einem Metal-Backend2.
  • Der gemeinsame Speicher ist der Grund, warum das auf einem Telefon funktioniert. Arrays liegen in einem einzigen Speicherpool, den sich CPU und GPU teilen, sodass MLX auf beiden über dieselben Puffer läuft, ohne Kopiersteuer zwischen Host und Gerät3.
  • Ein Open-Weight-LLM läuft mit LLMModelFactory auf dem Gerät: Sie verweisen auf ein quantisiertes Modell wie mlx-community/Llama-3.2-3B-Instruct-4bit und generieren dann über eine ChatSession4.
  • Feingetunt wird mit LoRA-Adaptern: Sie trainieren einen kleinen Adapter, liefern adapters.safetensors aus, und load(into:) tauscht die Linear-Schichten des Basismodells zur Laufzeit gegen LoRALinear5.
  • Der Preis des eigenen Modells: App-Größe (Gewichte sind groß), Speicherdruck, keine Systemintegration, und jede Aktualisierung liegt bei Ihnen. Foundation Models hat keine dieser Kosten, weil Apple sie trägt.

Was MLX ist und warum Apple Silicon es möglich macht

MLX gibt Ihnen Arrays und Operationen, die aussehen wie NumPy, dazu die Transformationen, die maschinelles Lernen braucht: automatische Differenzierung, Vektorisierung und verzögerte Auswertung, die einen Berechnungsgraphen aufbaut und ihn erst ausführt, wenn Sie ein Ergebnis auslesen2. Das Projekt bewegt sich zudem im Tempo eines Forschungs-Frameworks: MLX erreichte im Juli 2026 Version 0.32.0, MLX Swift in derselben Woche 0.31.6, bei einem Release-Rhythmus von etwa alle paar Wochen7. Fixieren Sie Ihre Versionen und rechnen Sie damit, dass die API-Oberfläche weiter wächst. Für sich genommen beschreibt das ein Dutzend Frameworks. Was MLX dazu befähigt, ein Modell mit mehreren Milliarden Parametern auf einem Gerät in Ihrer Hosentasche auszuführen, ist das Speichermodell.

Auf einer Desktop-GPU liegen die Daten im System-RAM, werden über einen Bus in den separaten Speicher der GPU kopiert, dort berechnet, und die Ergebnisse wandern wieder zurück. Dieses Kopieren ist die Steuer, und bei einem großen Modell fällt sie brutal aus. Apple Silicon hat gemeinsamen Speicher: einen einzigen Pool, den CPU, GPU und Neural Engine direkt adressieren. Genau um diese Tatsache herum ist MLX gebaut3. Ein Array ist nicht „auf der CPU“ oder „auf der GPU“; es liegt im Speicher, und jeder Prozessor arbeitet an Ort und Stelle damit. Keine Kopien, keine Bussteuer. Ein auf 4 Bit quantisiertes Modell mit 3 Milliarden Parametern passt in wenige Gigabyte und läuft ohne die Hin-und-Her-Transfers, die dieselbe Arbeit auf einer Maschine mit dedizierter GPU und vergleichbarem Speicher unpraktikabel machen würden. Die Hardware-Entscheidung, die Apple vor Jahren getroffen hat, ist überhaupt erst der Grund, warum sich ein echtes Modell auf dem Gerät ausführen lässt, und die kachelbasierte Architektur mit gemeinsamem Speicher bildet das Fundament, auf dem MLX steht.

Ein LLM auf dem Gerät ausführen

Der Weg von „Ich will ein bestimmtes Modell“ bis zu Text auf dem Bildschirm ist kurz. Die LLM-Schicht von MLX Swift lädt ein quantisiertes Modell aus dem Hugging Face Hub und führt es aus4:

let container = try await LLMModelFactory.shared.loadContainer(
    from: HubClient.default,
    using: TokenizersLoader(),
    configuration: .init(id: "mlx-community/Llama-3.2-3B-Instruct-4bit")
)

let session = ChatSession(container)
let response = try await session.respond(to: "Summarize this in one line: \(text)")

Für eine UI, die Token für Token aufbaut, erzeugen Sie stattdessen einen Stream und rendern die Bruchstücke, sobald sie eintreffen4:

let input = try await container.prepare(input: UserInput(prompt: prompt))
let stream = try await container.generate(input: input, parameters: GenerateParameters())
for await event in stream {
    if case let .chunk(text) = event { /* append to UI */ }
}

Zwei Details tragen dabei das meiste praktische Gewicht. Erstens ist das 4bit in der Modell-ID kein optionales Beiwerk: Erst die Quantisierung sorgt dafür, dass das Modell in den Speicher passt und auf einem Gerät mit brauchbarer Geschwindigkeit läuft. Ausgeliefert werden 4-Bit-Gewichte (oder noch weniger), nicht volle Präzision. Zweitens sind die Gewichte selbst quantisiert noch groß, weshalb Sie bewusst entscheiden müssen, ob Sie sie in die App bündeln (sofort verfügbar, aber ein fetter Download) oder beim ersten Start nachladen (schlankes Binary, dafür Wartezeit und ein Fehlerpfad, den Sie abfangen müssen). Foundation Models stellt diese Frage nie, weil das Modell bereits auf dem Gerät liegt. Bei MLX sind die Gewichte Ihr Problem.

Feintuning: ein LoRA-Adapter, kein neues Modell

Der Grund, ein eigenes Modell mitzubringen, ist selten das Basismodell selbst; es geht darum, ihm Ihre Domäne beizubringen. Ein vollständiges Feintuning eines Modells mit mehreren Milliarden Parametern auf dem Gerät ist nicht der richtige Weg. LoRA (Low-Rank-Adaptation) schon: Sie trainieren einen kleinen Satz Adaptergewichte, die das Verhalten des Basismodells anpassen, während das Basismodell unangetastet bleibt. Der Adapter ist Megabyte groß, nicht Gigabyte5.

MLX Swift lädt einen trainierten Adapter aus einem Verzeichnis mit adapter_config.json und adapters.safetensors und wendet ihn auf ein Modell an, das bereits in einem Container geladen ist5:

let adapter = try LoRAContainer.from(directory: adapterURL)
await container.update { context in
    try? adapter.load(into: context.model)   // swaps Linear layers for LoRALinear
}

load(into:) ersetzt die üblichen Linear-Schichten des Modells durch LoRALinear-Schichten, die die Low-Rank-Deltas des Adapters einrechnen, sodass die Inferenz nun Ihr Feintuning widerspiegelt. Weil das Modell im Container lebt, wenden Sie den Adapter über container.update an, und Sie können Adapter im laufenden Betrieb tauschen (einen mit unload(from:) entfernen, einen anderen mit load(into:) laden), um einem einzigen Basismodell je Funktion unterschiedliches Verhalten zu geben. Das Muster entspricht dem, was Apple für das Systemmodell über eigene Adapter für Foundation Models anbietet — mit dem Unterschied, dass hier Ihnen das Basismodell, die Trainingspipeline und das Ergebnis gehören, statt dass Sie ein Modell anpassen, in das Sie nicht hineinsehen können.

Die Entscheidung: Foundation Models, MLX oder Cloud

Drei Schichten, und wer falsch wählt, zahlt entweder mit Fähigkeiten oder mit einem Berg vermeidbarer Arbeit.

  • Foundation Models, wenn das Systemmodell die Aufgabe erledigen kann. Kostenlos, privat, keine auszuliefernden Gewichte, kein Speicher, den Sie verwalten müssen, und Systemintegration, die Sie geschenkt bekommen. Das ist die Standardwahl. Die Sprachaufgaben auf dem Gerät, für die Apple es gebaut hat (zusammenfassen, klassifizieren, extrahieren, umschreiben, strukturierte Ausgabe), gehören hierher, Punkt.
  • MLX, wenn Sie ein Modell brauchen, das Ihnen das System nicht gibt: ein bestimmtes Open-Weight-LLM, eine fixierte Version, die sich unter einem OS-Update nicht verschiebt, ein Feintuning auf Ihre Domäne oder eine Architektur (ein Vision-Language-Modell, ein Modell jenseits von Text) außerhalb des Zuschnitts von Foundation Models. Sie zahlen mit App-Größe, Speicher und Verantwortung, und Sie kaufen sich Kontrolle.
  • Cloud, wenn das Modell wirklich groß sein muss: Reasoning auf Frontier-Niveau, Analyse über lange Kontexte, alles, was die größten Modelle können und ein Modell mit ein paar Milliarden Parametern auf dem Gerät nicht. Ausführung auf dem Gerät ersetzt kein Frontier-Modell; sie ist ein anderer Punkt auf derselben Kurve.

Ehrlich gelesen: MLX ist ein bewusster Schritt nach unten aus einem bestimmten Grund, kein besserer Standard. Wenn Sie die Fähigkeit nicht benennen können, die Foundation Models für Ihre Funktion fehlt, brauchen Sie MLX nicht — und es auszuliefern hieße, Gigabyte an Gewichten und ein Speicherbudget mitzuschleppen, die Sie nicht hätten haben müssen.

iOS 27 fügt dieser Landkarte eine vierte Schicht hinzu. Core AI ist Apples System-Framework, um ein von Ihnen bereitgestelltes Modell auszuführen, mit expliziter Kontrolle über Spezialisierung, Caching und die Zuteilung von Recheneinheiten. Es überschneidet sich mit MLX auf der Ebene „Ihr Modell, auf dem Gerät“, nähert sich ihr aber von der Gegenseite: Core AI ist eine systemverwaltete Ausführungsumgebung für ein vorbereitetes .aimodel, während MLX eine Bibliothek ist, die Sie einbetten und in der Ihre eigene Trainingsschleife, Quantisierung und Iteration steckt. Wenn Sie ein konvertiertes Modell schnell und unter Systemverwaltung ausführen wollen, bewirbt sich Core AI um den Job; wenn Sie experimentieren, Feintuning betreiben oder die gesamte Pipeline besitzen wollen, bleibt MLX das Werkzeug.6

Wann Sie nicht zu MLX greifen sollten

  • Das Systemmodell kann es bereits. Lesen Sie die Aufgabenliste von Foundation Models noch einmal. Steht Ihre darauf, hören Sie hier auf.
  • Sie können sich die Gewichte nicht leisten. Auch ein kleines quantisiertes Modell bleibt eine große mitgelieferte Ressource. Wenn App-Größe oder der Download beim ersten Start für Ihre Nutzer eine echte Beschränkung darstellen, entscheidet diese Beschränkung womöglich schon allein die Frage.
  • Sie brauchen für ein festes Modell den sparsamsten Pfad über die Neural Engine. Für ein bekanntes, ausgeliefertes Modell, das sich nicht ändert, zielen Core ML und sein Konverter mit dem engsten Verbrauchs- und Latenzprofil auf die Neural Engine, und unter iOS 27 ist Core AI Apples erklärte Richtung für neue Arbeit an neuronalen Netzen mit expliziter Kontrolle über die Spezialisierung. MLX glänzt bei Flexibilität und Iteration auf Forschungsniveau; die System-Frameworks glänzen bei einem festgezurrten Produktionsmodell. Das sind unterschiedliche Werkzeuge, und „ML auf dem Gerät“ ist keine einzelne Entscheidung.
  • Sie werden es nicht pflegen. Ein eigenes Modell heißt: Ihnen gehören seine Aktualisierungen, seine Sicherheit und seine Drift. Das Systemmodell aktualisiert Apple für Sie. Wenn Sie personell nicht aufgestellt sind, ein Modell zu besitzen, schaffen Sie sich keines an.

Die Kunst, die MLX belohnt, ist Zurückhaltung bei der Frage, wann man es einsetzt. Das Framework ist wirklich bemerkenswert: ein echtes Sprachmodell, feingetunt auf Ihre Domäne, vollständig auf dem Gerät laufend, ohne Server und ohne Kosten pro Token, auf Hardware, deren Speicherarchitektur für genau das gebaut wurde. Nach dieser Fähigkeit zu greifen, lohnt sich, sobald Sie den Grund benannt haben. Greifen Sie ohne Grund danach, haben Sie Apples kostenloses, gepflegtes, integriertes Modell gegen eine schwerere, ungepflegte Kopie eingetauscht, die nun Ihnen gehört. Das Urteilsvermögen ist die eigentliche Arbeit.

FAQ

Was ist Apples MLX-Framework?

MLX ist ein Array-Framework für maschinelles Lernen auf Apple Silicon, mit einer NumPy-ähnlichen API, kombinierbaren Funktionstransformationen (automatische Differenzierung, Vektorisierung), verzögerter Berechnung und einem Metal-Backend2. MLX Swift ist die Swift-API, um es in Apps einzubetten, sodass Sie eigene Modelle auf dem Gerät ausführen und feintunen können.

Wie nutzt MLX den gemeinsamen Speicher von Apple Silicon?

MLX-Arrays liegen im gemeinsamen Speicher, sodass Operationen auf CPU oder GPU laufen, ohne Daten zwischen getrennten Speicherpools zu kopieren3. Genau diese Eigenschaft — kein Transfer — macht den gemeinsamen Speicher von Apple Silicon für die Ausführung von Modellen auf dem Gerät effizient.

Kann ich mit MLX ein Open-Weight-LLM auf dem Gerät ausführen?

Ja. LLMModelFactory.shared.loadContainer(from:using:configuration:) lädt ein quantisiertes Modell wie mlx-community/Llama-3.2-3B-Instruct-4bit aus dem Hugging Face Hub; ChatSession gibt Ihnen respond(to:) für einzelne Aufrufe, und container.generate(input:parameters:) streamt .chunk(text)-Ereignisse für inkrementelle Ausgabe4.

Wie führe ich mit MLX ein Feintuning eines Modells durch?

Mit einem LoRA-Adapter statt mit einem neuen Modell. LoRAContainer.from(directory:) lädt einen Adapter aus einem Verzeichnis mit adapter_config.json und adapters.safetensors; über container.update angewendet, tauscht er die Linear-Schichten des Modells gegen LoRALinear-Schichten und kann Adapter im laufenden Betrieb wechseln5.

MLX, Foundation Models oder Core ML — was sollte ich nehmen?

Standardmäßig Foundation Models, wenn Apples Systemmodell die Aufgabe erledigen kann (kostenlos, privat, keine auszuliefernden Gewichte)1. Zu MLX greifen Sie nur, wenn Sie ein Modell brauchen, das Ihnen das System nicht gibt: ein bestimmtes Open-Weight-LLM, eine fixierte Version, ein Feintuning auf Ihre Domäne oder eine Architektur außerhalb des Zuschnitts von Foundation Models. Core ML nehmen Sie für ein festgezurrtes Produktionsmodell, das den sparsamsten Pfad über die Neural Engine braucht, Core AI unter iOS 27, wenn Sie die systemverwaltete Ausführung Ihres eigenen Modells mit expliziter Kontrolle über Spezialisierung und Zuteilung wollen, und die Cloud, wenn das Modell wirklich auf Frontier-Niveau sein muss.

Wann sollte ich nicht zu MLX greifen?

Wenn das Systemmodell es bereits kann, wenn Sie sich das Ausliefern von Gigabyte an Gewichten nicht leisten können, wenn ein festes Modell mit Core MLs sparsamstem Pfad über die Neural Engine besser bedient wäre, oder wenn Sie personell nicht aufgestellt sind, für Aktualisierungen, Sicherheit und Drift eines Modells geradezustehen. MLX ist ein bewusster Schritt nach unten aus einem benannten Grund, kein besserer Standard.



  1. Einordnung von MLX gegenüber dem Foundation Models Framework: Foundation Models legt Apples festes Systemmodell auf dem Gerät offen (siehe Apple Foundation Models: Das LLM-Framework auf dem Gerät); MLX führt Modelle aus, die Sie auswählen und feintunen. Die beiden bedienen unterschiedliche Bedürfnisse auf unterschiedlichen Ebenen des Stacks auf dem Gerät. 

  2. Apple Machine Learning Research, MLX und MLX Swift. MLX ist ein Array-Framework für maschinelles Lernen auf Apple Silicon mit einer NumPy-ähnlichen API, kombinierbaren Funktionstransformationen (automatische Differenzierung, Vektorisierung), verzögerter Berechnung und einem Metal-Backend. MLX Swift ist die Swift-API zum Einbetten in Apps. 

  3. MLX-Dokumentation, unified memory. MLX-Arrays liegen im gemeinsamen Speicher; Operationen können auf CPU oder GPU laufen, ohne Daten zwischen getrennten Speicherpools zu übertragen — genau die Eigenschaft, die den gemeinsamen Speicher von Apple Silicon für die Ausführung von Modellen auf dem Gerät effizient macht. Hintergrund zur Hardware: TBDR und gemeinsamer Speicher bei Apple Silicon

  4. Apple Machine Learning Research, MLX Swift Examples / MLX Swift LM. LLMModelFactory.shared.loadContainer(from:using:configuration:) lädt ein quantisiertes Modell (zum Beispiel mlx-community/Llama-3.2-3B-Instruct-4bit) aus dem Hugging Face Hub; ChatSession stellt respond(to:) für einzelne Aufrufe bereit, und container.generate(input:parameters:) liefert über GenerateParameters und UserInput einen Strom von .chunk(text)-Ereignissen für inkrementelle Ausgabe. 

  5. Apple Machine Learning Research, MLX Swift LM LoRA adapters reference. LoRAContainer.from(directory:) lädt einen Adapter aus einem Verzeichnis mit adapter_config.json und adapters.safetensors; über container.update angewendet, ersetzt adapter.load(into: context.model) die Linear-Schichten des Modells durch LoRALinear-Schichten, und unload(from:) entfernt einen Adapter wieder, sodass sich Adapter im laufenden Betrieb tauschen lassen. Zum Vergleich Apples Weg über das Systemmodell in eigene Adapter für Foundation Models

  6. Praktische MLX-Arbeit des Autors: eine autonome ML-Forschungsschleife, die auf Apple Silicon über MLX Trainingsexperimente mit festem Budget fährt, dabei Architektur und Hyperparameter autonom verändert, um die Validierungs-Bits-pro-Byte zu minimieren, und nur Verbesserungen behält. Das hier beschriebene Verhalten von gemeinsamem Speicher und Quantisierung stammt aus dieser Experimentierarbeit. 

  7. MLX releases (v0.32.0, 7. Juli 2026; abgeglichen mit PyPI) und MLX Swift releases (0.31.6, 2. Juli 2026). Das Projekt hat seit dem Start Dutzende Releases veröffentlicht, etwa alle paar Wochen eines. 

Verwandte Beiträge

Apple Foundation Models: Das On-Device-LLM-Framework, erklärt

Apples Foundation Models Framework: LanguageModelSession, geführte Generierung mit @Generable, Tool-Aufrufe — und wann S…

15 Min. Lesezeit

Apple Vision Framework: On-Device-CV, die die meisten Entwickler übersehen

Apple Vision bietet über zwei Dutzend On-Device-CV-Operationen – kostenlos und in Millisekunden. Warum die meisten Entwi…

11 Min. Lesezeit

KI-Systeme entwickeln: Von RAG zu Agenten

Ich habe ein Agentensystem mit 3.500 Zeilen, 86 Hooks und Konsensvalidierung gebaut. Meine Erkenntnisse zu RAG, Fine-Tun…

8 Min. Lesezeit