Core ML vs MLX vs Foundation Models: Apples On-Device-KI-Stack richtig wählen

Apple liefert inzwischen vier grundverschiedene Wege, ein Modell auf der Hardware Ihrer Nutzer auszuführen, und die falsche Wahl kostet eine komplette Neuentwicklung. Auf dem M2 Max, an dem dieser Text entsteht, hält MLX 11,2 TFLOPS fp16-Matrixmathematik und bewegt Daten mit gemessenen 351 GB/s Unified-Memory-Bandbreite¹. Für die meisten Apps ist diese Rechenleistung dennoch die falsche Wahl, denn das mitgelieferte Foundation-Models-Framework erledigt die Aufgabe in sechs Zeilen Swift, ohne dem Download auch nur ein Megabyte hinzuzufügen. Die vier Frameworks sind keine Konkurrenten. Sie sind vier verschiedene Antworten auf eine einzige Frage: Wessen Modell ist es, und wer pflegt die Ausführung?

TL;DR

• Foundation Models ist die Standardwahl. Wenn Apples geräteinternes LLM mit rund 3 Milliarden Parametern die Aufgabe bewältigt (zusammenfassen, extrahieren, klassifizieren, strukturierte Ausgaben erzeugen, Ihre eigenen Werkzeuge aufrufen), liefern Sie null Modellgewichte aus, zahlen keine Inferenzkosten und erben jedes Modell-Upgrade auf Betriebssystemebene kostenlos.²
• Core ML dient dazu, Ihr trainiertes Modell in einer App auszuliefern. Es ist der einzige Weg mit erstklassigem Dispatch auf die Neural Engine, mit App-Store-tauglicher Paketierung und mit einem Vorabkompilierungsvertrag, der Flexibilität gegen Akkulaufzeit und Vorhersagbarkeit eintauscht.³
• MLX greift dann, wenn das Modell selbst das Produkt ist: Forschung, Fine-Tuning, das Ausführen offener LLM-Gewichte oder jede Arbeitslast, die unmittelbare Kontrolle über Tensoren verlangt. Es ist ein Werkzeug für Entwicklungsrechner und Mac-Apps, kein Auslieferungsvehikel für iOS.⁴
• Core AI (iOS 27) ist das neue Fundament unter alldem: ein hardwarenahes Framework zur Modellausführung mit NDArray-Tensoren und expliziter Adressierung von Recheneinheiten, gedacht für Teams, die heute Core ML als Tensor-Laufzeitumgebung zweckentfremden.
• Meist genügt eine einzige Frage: eingebautes Modell → Foundation Models; Ihr Modell unter iOS → Core ML; Ihr Modell auf Ihrem Mac → MLX; Kontrolle auf Tensorebene unter iOS → Core AI. Der Rest dieses Beitrags behandelt die 20 Prozent der Fälle, in denen diese Faustregel bricht.

Die Frage hinter der Frage

Jede Debatte über die Frage „welches Framework”, die ich beobachtet habe, fällt am Ende auf zwei Achsen zusammen. (Zu jedem der vier habe ich eine ausführliche Analyse geschrieben: Foundation Models, Core ML, MLX, Core AI.)

Achse eins: Wessen Gewichte? Apples eingebautes Modell, ein Modell, das Sie trainiert oder konvertiert haben, oder offene Gewichte aus einem Hub. Foundation Models führt ausschließlich Apples Modell aus, ergänzt allenfalls um Ihre Adapter im LoRA-Stil⁵. Core ML und MLX führen ausschließlich Gewichte aus, die Sie selbst bereitstellen. Allein diese Tatsache streicht die Hälfte des Möglichkeitsraums, bevor überhaupt von Performance die Rede ist.

Achse zwei: Wem gehört die Ausführung? Foundation Models verbirgt alles: keine Tensoren, keine Recheneinheiten, kein Kontextfenster-Management jenseits eines Session-Objekts. Core ML verbirgt das meiste: Sie übergeben eine kompilierte .mlmodelc und geben Hinweise auf Recheneinheiten, über den Dispatch entscheidet das Framework. MLX verbirgt nichts: Sie schreiben die Array-Mathematik selbst, und Lazy Evaluation samt Unified Memory sind Ihre Werkzeuge. Core AI liegt zwischen Core ML und MLX: explizite Tensoren und explizit adressierte Recheneinheiten, aber eine von Apple verwaltete Ausführung.

Tragen Sie eine reale Funktion auf diesen beiden Achsen ab, dann wählt sich das Framework von selbst.

Foundation Models: Der Null-Megabyte-Standard

Das Framework, das die meisten Teams zuerst ausprobieren sollten, ist jenes, das gar kein Modell benötigt. Foundation Models macht das geräteinterne LLM hinter Apple Intelligence über LanguageModelSession zugänglich, und sein entscheidendes Merkmal ist nicht das Modell. Es ist die Guided Generation: Annotieren Sie eine Swift-Struktur mit @Generable, und das Framework schränkt die Dekodierung so ein, dass die Ausgabe des Modells Ihr Typ ist – und nicht eine Zeichenkette, die Sie parsen und dabei hoffen müssen.²

@Generable
struct Itinerary {
    let destination: String
    let days: Int
    @Guide(description: "Budget in USD") let budget: Double
}

let session = LanguageModelSession()
let itinerary = try await session.respond(
    to: "Weekend in Kyoto under $800",
    generating: Itinerary.self
).content

Das ist die vollständige Integration. Kein Download-Schritt, keine Quantisierungsentscheidungen, keine Wärmeentwicklung, über die nachzudenken wäre; das System plant das Modell ein, teilt es zwischen allen Apps auf dem Gerät und aktualisiert es mit jeder Version. Über Tool Calling ruft das Modell Funktionen auf, die Sie definieren – genug, um ohne jeden Server wirklich agentische Funktionen zu bauen.²

Die Einschränkung ist symmetrisch: Das Modell ist ein Generalist mit rund 3 Milliarden Parametern. Es fasst zusammen, extrahiert, klassifiziert und liefert strukturierte Ausgaben überzeugend; Weltwissen aus offenen Domänen, Dokumentenanalyse über lange Kontexte oder das, was ein Frontier-Modell leistet, gehört nicht dazu. Reicht das eingebaute Modell nicht, lautet Apples Antwort: Adapter, also Fine-Tunes im LoRA-Stil, die Sie mit Apples Toolkit gegen das Basismodell trainieren. Ein Adapter ist allerdings eine Verpflichtung, denn Sie trainieren ihn jedes Mal neu, wenn Apple das Basismodell überarbeitet⁵. Meine vollständige Analyse samt Session-Verwaltung und den Fehlerbildern, über die Prüfer stolpern, steht in der ausführlichen Betrachtung zu Foundation Models.

Wählen Sie es, wenn: die Aufgabe sprachlicher Natur ist, das eingebaute Modell Ihre Qualitätsschwelle erreicht und es zählt, null Gewichte auszuliefern. Das trifft auf mehr Funktionen zu, als die meisten Teams vermuten; probieren Sie es aus, bevor Sie zu einer der folgenden Optionen greifen.

Core ML: Ihr Modell, Apples Ausführung

Core ML beantwortet eine andere Frage. Sie haben bereits ein Modell – einen Bildklassifikator, ein Embedding-Modell, eine Sprachpipeline, ein destilliertes LLM –, und es muss in einer iOS-App laufen, im Akkubetrieb, innerhalb der Größengrenzen des App Store, und zwar noch in diesem Jahr.

Der Vertrag lautet: vorab kompilieren. Sie konvertieren die Gewichte mit coremltools, das Modell wird zu .mlmodelc kompiliert, und zur Laufzeit verteilt das Framework die Arbeit über Neural Engine, GPU und CPU. Die ANE ist genau der Teil, den Ihnen heute nichts anderes auf dieser Liste unter iOS bietet. Im Konvertierungsschritt steckt die eigentliche Ingenieursarbeit: Operator-Abdeckung, Quantisierung (Palettisierung, lineare 8/4-Bit-Verfahren, Sparsity – der Optimierungs-Stack von coremltools reicht wirklich tief⁶) und jene Hinweise auf Recheneinheiten, die darüber entscheiden, ob Ihr Modell mit 2 oder mit 8 Watt läuft. Welche Muster den Produktivbetrieb tatsächlich überstehen – Dispatch-Hinweise, Latenzbudgets, die Quantisierungsleiter –, behandelt der Core-ML-Grundlagenbeitrag.

Ebenso tragend ist, was Core ML nicht tut: Es trainiert nicht, es macht kein Fine-Tuning, und es gibt Ihnen keine Tensoren mitten im Graphen. Es ist ein Inferenz-Gerät. Teams, die „meinen Graphen ausführen UND Zwischenergebnisse anfassen” wollten, haben Core ML historisch zu einer Tensor-Laufzeitumgebung verbogen; genau diese Verrenkung soll Core AI nun auffangen.

Wählen Sie es, wenn: die Gewichte Ihnen gehören, das Ziel iOS/iPadOS (oder plattformübergreifend Apple) heißt und Akku, Größe und ANE eine Rolle spielen. Das gilt für so gut wie jede ausgelieferte Funktion mit eigenem Modell auf dieser Plattform.

MLX: Die Forschungsmaschine in Ihrem Mac

MLX fällt aus der Reihe: ein quelloffenes Array-Framework aus Apples ML-Forschungsgruppe, kein Systemframework⁴. Es sieht aus wie NumPy, wertet verzögert aus und behandelt den Unified Memory von Apple silicon als das Merkmal, das er ist: keine Kopien zwischen Host und Gerät, weil es keinen getrennten Gerätespeicher gibt.

Die Zahlen dieser Maschine machen den Fall konkret. Ein M2 Max hält unter MLX ohne jede Optimierung 11,2 TFLOPS fp16-Matrixmultiplikation bei 4096×4096 und 351 GB/s gemessene Streaming-Bandbreite¹: genug, um quantisierte Modelle mit 30 Milliarden Parametern und offenen Gewichten interaktiv zu betreiben, 7B-Modelle über Nacht mit LoRA zu finetunen und Trainingsläufe zu iterieren, für die man sonst Cloud-GPUs mieten müsste. Dank des Ökosystems rund um mlx-lm sind die meisten offenen Modelle nur ein pip install und einen Download entfernt.

Ebenso konkret sind die Grenzen. Keine Neural Engine: MLX programmiert die GPU (und die CPU), nicht die ANE. Keine Auslieferung unter iOS: Technisch lässt sich MLX einbetten, doch Gewichtsverteilung, Wärmeentwicklung und Prüfrichtlinien machen es zum falschen Werkzeug. MLX gehört auf Ihren Mac, auf die Macs Ihrer Nutzer und in Ihre Forschungsschleife. Und niemand verwaltet die Ausführung für Sie: Speicherdruck, Quantisierungsentscheidungen und die Planung der Auswertung liegen bei Ihnen. Wann „mein eigenes Modell statt Apples” diese Verantwortung wert ist, behandelt der MLX-Grundlagenbeitrag.

Wählen Sie es, wenn: Sie trainieren oder finetunen, offene LLM-Gewichte lokal betreiben oder Mac-native Werkzeuge bauen, bei denen die Kontrolle über das Modell das Produkt ist. Ist Ihr täglicher Begleiter ein Apple-silicon-Mac mit ordentlich RAM, macht MLX daraus eine ernstzunehmende ML-Workstation.

Core AI: Das neue Fundament

iOS 27 hat die Schicht ergänzt, die Apple bislang fehlte: Core AI, ein hardwarenahes Framework zur Modellausführung mit NDArray-Tensoren, einer Trennung von Asset und Modell, expliziter Adressierung von Recheneinheiten und aufrufbaren Inferenzfunktionen⁷. Sie greifen dazu, wenn der Core-ML-Vertrag „reich mir ein kompiliertes Modell, erhalte Vorhersagen” zu starr ist: Pipelines, die Tensormathematik mit Modellaufrufen verschränken, eigene Vor- und Nachverarbeitung, die auf die ANE gehört, Graphen aus mehreren Modellen mit gemeinsamen Puffern.

Zwei Klarstellungen ersparen den meisten Lesern einen Umweg. Core AI ist keine Alternative zu Foundation Models (auf dieser Ebene gibt es weiterhin kein eingebautes LLM, kompilierte Assets bringen Sie selbst mit). Und es ist kein MLX für iOS: kein Training, kein Autograd, keine unmittelbare Forschungsschleife. Es ist der Maschinenraum von Core ML mit geöffneter Luke. Wer nie mit der Abstraktion von Core ML gerungen hat, braucht Core AI nicht; wer schon einmal MLMultiArray-Turnübungen ausgeliefert oder Modelle über unnötige Konvertierungen verkettet hat, braucht es bereits. Das Tensormodell und die API zur Adressierung behandelt der Core-AI-Grundlagenbeitrag.

Die Fälle, über die tatsächlich gestritten wird

„Wir brauchen ein LLM, aber unser eigenes oder ein größeres.” Foundation Models kann keine externen Gewichte laden, Punkt. Ein destilliertes kleines LLM über Core ML funktioniert und verschafft Ihnen die ANE; ein quantisiertes offenes Modell über MLX funktioniert auf dem Mac. Seien Sie ehrlich zu der Alternative, die in der On-Device-Welt niemand laut aussprechen mag: Verlangt die Aufgabe Frontier-Qualität, lautet die Antwort Serveraufruf, und die geräteinternen Schichten übernehmen Rückfallebene und datenschutzsensible Teilmengen.

„Wir wollen einen Stack für iPhone und Mac.” Foundation Models und Core ML sind innerhalb von Apples Ökosystem beide plattformübergreifend; MLX bleibt in der Praxis dem Mac vorbehalten. Teams, die eine Mac-Profi-App plus eine iOS-Begleit-App ausliefern, landen üblicherweise bei MLX für den Mac (große Modelle, vom Nutzer bereitgestellte Gewichte) und bei Core ML oder Foundation Models unter iOS: dieselbe Funktion, zwei Engines und ein ehrliches Eingeständnis, dass die Geräte verschieden sind.

„Wir haben bereits eine Core-ML-Pipeline; ist Core AI ein Migrationsziel?” Nur dort, wo die Pipeline schmerzt. Core AI fängt die tensorförmigen Ränder auf; der kompilierte Modellkern, der heute funktioniert, funktioniert weiter. Eine gesunde Core-ML-Installation vollständig zu migrieren, bringt nichts ein.

„Ändern SwiftData oder App Intents daran etwas?” Benachbart, nicht überlappend: Ihre Modellschicht speist Funktionen, die App Intents dem System zugänglich machen, und was Sie persistieren, folgt den Schemaregeln von SwiftData. Die Frameworks hier entscheiden, wie Inferenz läuft, nicht, wie die App darum herum gebaut wird.

Ein Entscheidungsbaum

Is the task language-shaped and within a ~3B generalist's reach?
├── YES → Foundation Models. Ship zero weights. Done.
└── NO → Whose weights?
    ├── Apple's, but specialized → Foundation Models + trained adapter
    │     (accept: retrain per base-model rev)
    └── Yours →  Where does it run?
        ├── iOS/iPadOS app → Core ML
        │     └── unless you need tensor-level control → Core AI (iOS 27+)
        ├── Mac, models-as-product / training / open weights → MLX
        └── Frontier-quality required → server, with on-device fallback

Die wichtigsten Erkenntnisse

Für App-Teams, die Funktionen ausliefern: - Prototypen zuerst gegen Foundation Models bauen; sechs Zeilen Swift sind das denkbar billigste Experiment, und „das eingebaute Modell reicht” ist die häufigste Überraschung. - Planen Sie die Konvertierungszeit für Core ML getrennt von der Inferenzzeit ein; Operator-Abdeckung und Quantisierung verschlingen die Wochen.

Für ML-Ingenieure: - Ein Apple-silicon-Mac mit 64 GB oder mehr ist unter MLX ein echter Rechner für Fine-Tuning; messen Sie, bevor Sie Cloud-GPUs mieten. Die oben genannten 11,2 TFLOPS und 351 GB/s stammen von einem zwei Generationen alten Notebook-Chip.¹ - Die ANE bleibt der Burggraben von Core ML – und jetzt auch von Core AI. Zählt der Akkuverbrauch pro Inferenz, hält kein GPU-Pfad mit.

Für Architekten: - Behandeln Sie die vier Frameworks als Schichten, nicht als Rivalen: Foundation Models für Sprachfunktionen, Core ML für ausgelieferte eigene Modelle, Core AI für die tensorförmigen Ränder, MLX für den Mac und das Labor. In ernsthaften Apps ist der gemischte Einsatz die Regel und kein schlechtes Zeichen. - Der langfristige Kostenblock ist der Besitz des Modells: Apple pflegt die Gewichte von Foundation Models, alles andere pflegen Sie. Rechnen Sie das in Ihre Entscheidung ein.

Häufige Fragen

Welches Apple-Framework sollte ich nutzen, um ein Modell auf dem Gerät auszuführen?

Meist genügt eine einzige Frage. Eingebautes Modell: Foundation Models. Ihr Modell unter iOS: Core ML. Ihr Modell auf Ihrem Mac: MLX. Kontrolle auf Tensorebene unter iOS: Core AI. Tragen Sie die Funktion auf zwei Achsen ab – wessen Gewichte sie ausführt und wem die Ausführung gehört –, und das Framework wählt sich von selbst. Betrachten Sie die vier als Schichten, nicht als Rivalen; in ernsthaften Apps ist der gemischte Einsatz die Regel.

Kann Foundation Models meine eigenen Modellgewichte ausführen?

Nein. Foundation Models führt ausschließlich Apples eingebautes geräteinternes Modell aus, einen Generalisten mit etwa 3 Milliarden Parametern, ergänzt um Ihre Adapter im LoRA-Stil. Externe Gewichte kann es nicht laden, Punkt. Brauchen Sie ein eigenes LLM, funktioniert ein destilliertes kleines Modell über Core ML und verschafft Ihnen die Neural Engine, und ein quantisiertes offenes Modell über MLX funktioniert auf dem Mac. Verlangt die Aufgabe Frontier-Qualität, lautet die Antwort Serveraufruf.⁵

Kann ich MLX in einer iOS-App ausliefern?

Realistisch nicht. MLX ist ein quelloffenes Array-Framework aus Apples ML-Forschungsgruppe und kein Systemframework, es programmiert GPU und CPU ohne Zugriff auf die Neural Engine, und Gewichtsverteilung, Wärmeentwicklung sowie Prüfrichtlinien machen es zum falschen Werkzeug für ein iOS-Bundle. MLX gehört auf Ihren Mac, auf die Macs Ihrer Nutzer und in Ihre Forschungsschleife.⁴

Worin unterscheiden sich Core ML und Core AI?

Core ML ist vorab kompilierte Inferenz: Sie übergeben eine kompilierte .mlmodelc, geben Hinweise auf Recheneinheiten, und das Framework entscheidet über den Dispatch. Core AI, ergänzt in iOS 27, ist derselbe Maschinenraum mit geöffneter Luke: NDArray-Tensoren, eine Trennung von Asset und Modell und explizit adressierbare Recheneinheiten. Trainiert wird weiterhin nicht, und ein eingebautes LLM liefert es auch nicht mit. Wer nie mit der Abstraktion von Core ML gerungen hat, braucht es nicht.⁷

Wie schnell ist ein M2 Max für lokales maschinelles Lernen?

Auf dem M2 Max, an dem dieser Text entsteht, hält MLX ohne jede Optimierung 11,2 TFLOPS fp16-Matrixmultiplikation bei 4096×4096 und 351 GB/s gemessene Streaming-Bandbreite. Das genügt, um quantisierte Modelle mit 30 Milliarden Parametern und offenen Gewichten interaktiv zu betreiben und 7B-Modelle über Nacht mit LoRA zu finetunen. Messen Sie, bevor Sie Cloud-GPUs mieten; diese Zahlen stammen von einem zwei Generationen alten Notebook-Chip.¹

Quellen