← 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 nach Apples Zeitplan aktualisiert. Für die meisten On-Device-Sprachaufgaben ist das genau das richtige Werkzeug, und darüber hinauszugreifen ist ein Fehler. Manche Arbeit aber verlangt nach einem Modell, das Sie selbst wählen: ein bestimmtes Open-Weight-LLM, eine Version, die Sie festnageln, ein auf Ihren eigenen Daten trainierter Fine-Tune oder eine Fähigkeit, die das Systemmodell nicht besitzt. Wenn Sie Ihr eigenes Modell auf dem Gerät laufen lassen müssen, liegt die Schicht unter Foundation Models bei 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 Systemframework, das Sie aufrufen; es ist eine Bibliothek, die Sie mitliefern – zusammen mit den Modellgewichten. Dieser Unterschied ist die ganze Abwägung, und sie zu verstehen ist der Weg, um zu entscheiden, ob Sie eine Schicht tiefer steigen oder dort bleiben, wo Apple Sie hingesetzt hat.

TL;DR

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

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

MLX gibt Ihnen Arrays und Operationen, die wie NumPy aussehen, dazu die Transformationen, die maschinelles Lernen braucht: automatische Differenzierung, Vektorisierung und eine verzögerte Auswertung, die einen Berechnungsgraphen aufbaut und ihn erst ausführt, wenn Sie ein Ergebnis auslesen2. 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 laufen zu lassen, ist das Speichermodell.

Auf einer Desktop-GPU liegen die Daten im System-RAM, und Sie kopieren sie über einen Bus in den separaten Speicher der GPU, um zu rechnen, und die Ergebnisse anschließend wieder zurück. Dieses Kopieren ist die Steuer, und für ein großes Modell ist sie brutal. Apple Silicon besitzt vereinheitlichten Speicher: einen einzigen Pool, den CPU, GPU und Neural Engine alle direkt adressieren. MLX ist um genau diese Tatsache herum gebaut3. Ein Array ist nicht „auf der CPU” oder „auf der GPU”; es liegt im Speicher, und jeder Prozessor operiert an Ort und Stelle darauf. Keine Kopien, keine Bussteuer. Ein auf 4 Bit quantisiertes Modell mit drei Milliarden Parametern passt in wenige Gigabyte und läuft ohne die Hin-und-Her-Wege, die dieselbe Arbeit auf einer Maschine mit dedizierter GPU und vergleichbarem Speicher unpraktikabel machen würden. Die Hardware-Entscheidung, die Apple vor Jahren traf, ist überhaupt erst der Grund, warum die On-Device-Inferenz eines echten Modells machbar ist – und die kachelbasierte Architektur mit vereinheitlichtem Speicher ist das Fundament, auf dem MLX steht.

Ein LLM auf dem Gerät ausführen

Der Weg von „Ich möchte 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 Token-für-Token-UI erzeugen Sie stattdessen einen Stream und rendern die Stü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 den größten Teil des praktischen Gewichts. Erstens ist das 4bit in der Modell-ID kein optionaler Zucker: Quantisierung ist das, was das Modell in den Speicher passen und mit brauchbarer Geschwindigkeit auf einem Gerät laufen lässt. Sie liefern 4-Bit-Gewichte (oder noch geringere), nicht volle Präzision. Zweitens sind die Gewichte selbst quantisiert groß, sodass Sie bewusst entscheiden, ob Sie sie in die App bündeln (sofort verfügbar, aber ein dicker Download) oder beim ersten Start nachladen (schlanke Binärdatei, aber mit Wartezeit und einem Fehlerpfad, den Sie behandeln müssen). Foundation Models stellt diese Frage nie, weil das Modell bereits auf dem Gerät ist. Mit MLX sind die Gewichte Ihr Problem.

Feinjustierung: 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 Fine-Tuning eines Modells mit mehreren Milliarden Parametern auf dem Gerät ist nicht der richtige Zug. LoRA (Low-Rank-Adaptation) schon: Sie trainieren einen kleinen Satz Adaptergewichte, die das Verhalten des Basismodells anpassen, während das Basismodell selbst unberührt bleibt. Der Adapter ist megabyte-, nicht gigabytegroß5.

MLX Swift lädt einen trainierten Adapter aus einem Verzeichnis, das adapter_config.json und adapters.safetensors enthält, und wendet ihn dann auf ein bereits in einem Container geladenes Modell an5:

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 standardmäßigen Linear-Schichten des Modells durch LoRALinear-Schichten, die die Low-Rank-Deltas des Adapters einfalten, sodass die Inferenz nun Ihren Fine-Tune widerspiegelt. Da das Modell innerhalb des Containers lebt, wenden Sie den Adapter über container.update an, und Sie können Adapter zur Laufzeit im laufenden Betrieb austauschen (einen mit unload(from:), einen anderen mit load(into:)), um einem einzigen Basismodell je Funktion unterschiedliches Verhalten zu geben. Das Muster spiegelt das wider, was Apple für das Systemmodell über Foundation Models mit eigenen Adaptern anbietet: Der Unterschied ist, dass hier das Basismodell, die Trainingspipeline und das Ergebnis Ihnen gehören, statt dass Sie ein Modell anpassen, das Sie nicht einsehen können.

Die Entscheidung: Foundation Models, MLX oder Cloud

Drei Schichten – und falsch zu wählen kostet Sie entweder Fähigkeit oder einen Berg vermeidbarer Arbeit.

  • Foundation Models, wenn das Systemmodell die Aufgabe erledigen kann. Kostenlos, privat, keine Gewichte zum Mitliefern, kein Speicher, den Sie verwalten, und Systemintegration, die Sie umsonst bekommen. Hier ist die Voreinstellung. Die On-Device-Sprachaufgaben, für die Apple es gebaut hat (zusammenfassen, klassifizieren, extrahieren, umschreiben, strukturierte Ausgabe), gehören hierher, Punkt.
  • MLX, wenn Sie ein Modell brauchen, das das System nicht hergibt: ein bestimmtes Open-Weight-LLM, eine festgenagelte Version, die sich unter einem OS-Update nicht verschiebt, einen Domänen-Fine-Tune oder eine Architektur (ein Vision-Language-Modell, ein Nicht-Text-Modell) außerhalb des Umfangs von Foundation Models. Sie bezahlen mit App-Größe, Speicher und Eigentümerschaft und kaufen dafür Kontrolle.
  • Cloud, wenn das Modell tatsächlich groß sein muss: Reasoning auf Spitzenniveau, Analyse über lange Kontexte, alles, was die größten Modelle leisten und ein On-Device-Modell mit wenigen Milliarden Parametern nicht kann. On-Device ist kein Ersatz für ein Frontier-Modell; es ist ein anderer Punkt auf der Kurve.

Die ehrliche Lesart: MLX ist ein bewusster Schritt nach unten aus einem bestimmten Grund, nicht die bessere Voreinstellung. Wenn Sie die Fähigkeit nicht benennen können, die Foundation Models Ihrer Funktion vorenthält, brauchen Sie MLX nicht – und es trotzdem auszuliefern bedeutet, gigabytegroße Gewichte und ein Speicherbudget mitzuschleppen, das Sie gar nicht hätten haben müssen.

Wann Sie nicht zu MLX greifen sollten

  • Das Systemmodell erledigt es bereits. Lesen Sie die Foundation-Models-Aufgaben noch einmal. Steht Ihre auf der Liste, hören Sie hier auf.
  • Sie können sich die Gewichte nicht leisten. Ein quantisiertes kleines Modell ist immer noch ein großer Vermögenswert. Wenn App-Größe oder der Download beim ersten Start für Ihre Benutzer eine echte Einschränkung sind, entscheidet diese Einschränkung die Frage womöglich von ganz allein.
  • Sie brauchen den energieärmsten Pfad der Neural Engine für ein festes Modell. Für ein bekanntes, ausgeliefertes Modell, das sich nicht ändert, zielen Core ML und sein Konverter mit der knappsten Leistungs- und Latenzbilanz auf die Neural Engine. MLX glänzt bei Flexibilität und Iteration auf Forschungsniveau; Core ML glänzt bei einem abgeschlossenen Produktionsmodell. Es sind unterschiedliche Werkzeuge, und „On-Device-ML” ist keine einzelne Entscheidung.
  • Sie werden es nicht warten. Ihr eigenes Modell bedeutet, dass Ihnen seine Aktualisierungen, seine Sicherheit und seine Drift gehören. Apple aktualisiert das Systemmodell für Sie. Wenn Sie nicht aufgestellt sind, ein Modell zu betreuen, sollten Sie keines übernehmen.

Die Fähigkeit, die MLX belohnt, ist Zurückhaltung darüber, wann man es einsetzt. Das Framework ist wahrhaft bemerkenswert: ein echtes Sprachmodell, auf Ihre Domäne feinjustiert, das vollständig auf dem Gerät läuft – ohne Server und ohne Kosten pro Token, auf Hardware, deren Speicherarchitektur für genau dies gebaut wurde. Diese Fähigkeit ist es wert, danach zu greifen, wenn Sie den Grund benannt haben. Greifen Sie ohne einen danach, haben Sie Apples kostenloses, gewartetes, integriertes Modell gegen eine schwerere, ungewartete Kopie eingetauscht, die nun Ihnen gehört. Das Urteilsvermögen ist die eigentliche Arbeit.



  1. Verortung von MLX gegenüber dem Foundation-Models-Framework: Foundation Models stellt Apples festes On-Device-Systemmodell bereit (siehe Apple Foundation Models: Das On-Device-LLM-Framework); MLX führt Modelle aus, die Sie selbst wählen und feinjustieren. Die beiden bedienen unterschiedliche Bedürfnisse auf unterschiedlichen Schichten des On-Device-Stacks. 

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

  3. MLX-Dokumentation, unified memory. MLX-Arrays liegen im gemeinsam genutzten Speicher; Operationen können auf CPU oder GPU laufen, ohne Daten zwischen getrennten Speicherpools zu übertragen – das ist die Eigenschaft, die den vereinheitlichten Speicher von Apple Silicon für die On-Device-Modellausführung effizient macht. Hintergrund zur Hardware: Apple Silicons TBDR und vereinheitlichter Speicher

  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 einen Stream von .chunk(text)-Ereignissen für inkrementelle Ausgabe über GenerateParameters und UserInput

  5. Apple Machine Learning Research, MLX Swift LM LoRA adapters reference. LoRAContainer.from(directory:) lädt einen Adapter aus einem Verzeichnis, das adapter_config.json und adapters.safetensors enthält; angewandt über container.update, ersetzt adapter.load(into: context.model) die Linear-Schichten des Modells durch LoRALinear-Schichten, und unload(from:) entfernt einen, sodass Adapter zur Laufzeit im laufenden Betrieb ausgetauscht werden können. Vergleichen Sie Apples Pfad für das Systemmodell in Foundation Models mit eigenen Adaptern

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

Verwandte Beiträge

Apple Foundation Models: The On-Device LLM Framework, Explained

Apple's Foundation Models framework: LanguageModelSession, @Generable guided generation, tool calling, availability, and…

11 Min. Lesezeit

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

Apple Vision liefert mehr als zwei Dutzend On-Device-CV-Operationen. Die meisten Entwickler greifen standardmäßig zu Ope…

11 Min. Lesezeit

KI-Systeme entwickeln: Von RAG zu Agenten

Ich habe ein 3.500 Zeilen umfassendes Agentensystem mit 86 Hooks und Konsensvalidierung gebaut. Hier sind meine Erkenntn…

8 Min. Lesezeit