Core ML On-Device Inference: Die Muster, die wirklich in Produktion gehen

Core ML ist die On-Device-Inference-Engine, die mit jedem modernen Apple-Gerät ausgeliefert wird. Das Framework dispatcht zur Neural Engine, sofern verfügbar, andernfalls zur GPU und als letzte Option zur CPU – und wählt dabei automatisch den schnellsten Pfad basierend auf Modell und Hardware¹. Das Ergebnis auf einem aktuellen iPhone: Inferenz mit Latenzen im Submillisekunden- bis niedrigen zweistelligen Millisekundenbereich für die meisten produktiven Modellgrößen, kostenlos pro Aufruf, ohne Netzwerk-Roundtrip und ohne Datenweitergabe an Dritte.

Der Ruf des Frameworks als „obskure Klempnerei” ist überholt. Core ML treibt heute das On-Device-LLM von Apple Intelligence an, die semantische Suche der Fotos-App, die Szenenerkennung der Kamera-App und die meisten Dritt-Apps mit lokalem ML. Die Muster, die ein Core-ML-Deployment tatsächlich in Produktion bringen statt nur „funktioniert-auf-meinem-Mac”-Status erreichen lassen, bilden eine kleine Menge: Modellkonvertierung, Dispatch-Hinting, Latenzbudgetierung und Quantisierung. Dieser Beitrag geht jedes Muster anhand der Apple-Dokumentation durch.

TL;DR

• Core ML führt .mlpackage- und .mlmodel-Dateien auf der Neural Engine, der GPU und der CPU von Apple Silicon aus. Das Dispatching erfolgt automatisch, kann aber über MLModelConfiguration.computeUnits gehintet werden².
• Die Modellkonvertierung läuft über coremltools (PyTorch, TensorFlow, ONNX → Core ML). Die Konvertierung ist eine Tooling-Aufgabe, keine Laufzeitaufgabe; sobald ein Modell konvertiert und gebündelt ist, lädt und führt die App es aus.
• Die Unified-Memory-Architektur von Apple Silicon bedeutet, dass Modellgewichte nicht zwischen CPU, GPU und NE kopiert werden; derselbe Speicher liegt allen drei zugrunde³. Dieses architektonische Detail macht Submillisekunden-Inferenz erst möglich.
• Quantisierung (INT8, INT4 in neueren Core-ML-Versionen) verkleinert die Modellgröße und beschleunigt die Inferenz auf der Neural Engine, mit messbaren Genauigkeitseinbußen, die vom Modell abhängen.
• Die Anbindung an Agenten-Workflows: Foundation Models (das On-Device-LLM von Apple Intelligence) wird als Core-ML-Modell hinter einem hochstufigen Swift-API ausgeliefert; dieselben Dispatch- und Quantisierungsmuster gelten.

Das mentale Modell: drei Compute-Pfade, ein Speicher

Apple Silicon (M-Serie-Macs und A-Serie-iPhones ab dem A12 Bionic) liefert drei Inferenzziele:

Neural Engine. Ein spezialisierter Beschleuniger für Matrixmultiplikation bei niedriger Präzision. Am schnellsten für die Operationen, von denen moderne ML-Modelle abhängen (Convolutions, Attention, Embeddings). Niedrigster Energieverbrauch. Beschränkt auf bestimmte Operationstypen und Tensorformen; nicht unterstützte Ops fallen pro Layer auf GPU oder CPU zurück.

GPU. Allzweck-Parallelcompute über Metal. Langsamer als die Neural Engine bei ML-typischer Arbeit, aber schneller als die CPU. Verarbeitet Operationen, die die Neural Engine nicht unterstützt.

CPU. Der Fallback. Langsam für ML-Inferenz, aber immer verfügbar, unterstützt jede Operation und ist vorhersehbar.

Die Unified-Memory-Architektur bedeutet, dass derselbe physische RAM allen drei zugrunde liegt³. Die einmal geladenen Gewichte eines Modells werden nicht kopiert, wenn das Dispatching zwischen Zielen wechselt. Dieser architektonische Fakt macht aus dem Multi-Target-Dispatching keinen Pro-Layer-Kopieraufwand, sondern eine Pro-Layer-Scheduling-Entscheidung.

MLModelConfiguration.computeUnits steuert das Dispatching:

let config = MLModelConfiguration()
config.computeUnits = .all          // default: NE, GPU, CPU
// Other options:
// .cpuAndGPU
// .cpuAndNeuralEngine
// .cpuOnly
let model = try MyModel(configuration: config)

.all ist der Default und für nahezu jede App die richtige Wahl. Das Framework wählt den schnellsten Pfad pro Operation, und diese Pro-Operation-Entscheidung ist schneller als jede Heuristik, die der Entwickler schreiben würde. Der seltene Grund für ein Override: .cpuOnly erzwingen, um Testparität zu gewährleisten (ein Modell verhält sich auf verschiedenen Pfaden unterschiedlich, und der Test will den deterministischen Pfad), oder .cpuAndGPU erzwingen, um die Neural Engine für eine andere parallele Aufgabe freizugeben.

Modellkonvertierung: die Tooling-Aufgabe

Die meisten ML-Modelle werden in PyTorch, TensorFlow oder direkt über Apples Create ML trainiert. Core ML akzeptiert .mlpackage-Dateien, das in Xcode 13 eingeführte moderne Format, das das ältere .mlmodel ablöst⁴. Die Konvertierung läuft über coremltools, Apples Open-Source-Python-Paket⁵.

Eine typische PyTorch-zu-Core-ML-Konvertierung folgt drei Schritten:

1. Das trainierte PyTorch-Modell laden und in den Inferenzmodus versetzen.
2. Das Modell mit einem Beispiel-Input-Tensor tracen, der der Eingabeform in Produktion entspricht.
3. Das getracte Modell mit coremltools gegen eine Ziel-Deployment-iOS-Version konvertieren.

import torch
import coremltools as ct

model = MyTrainedModel()
model.load_state_dict(torch.load("weights.pth"))

example_input = torch.rand(1, 3, 224, 224)
traced_model = torch.jit.trace(model, example_input)

mlmodel = ct.convert(
    traced_model,
    inputs=[ct.ImageType(name="image", shape=example_input.shape)],
    minimum_deployment_target=ct.target.iOS18,
    compute_units=ct.ComputeUnit.ALL,
)
mlmodel.save("MyModel.mlpackage")

Die Konvertierung erfolgt einmalig, in einer Entwicklungsumgebung, gegen eine Ziel-Deployment-iOS-Version (minimum_deployment_target). Das ausgegebene .mlpackage ist das, was in das Xcode-Projekt fällt. Die Laufzeit-App führt coremltools nicht aus.

Zwei praktische Stolperfallen bei der Konvertierung. Erstens benötigen dynamisch geformte Eingaben explizite Behandlung über ct.RangeDim, weil der statische Default von Core ML wenig hilfreiche Fehler produziert, wenn die Produktions-App variierende Eingabegrößen liefert. Zweitens benötigen Custom-Ops in PyTorch, die kein Core-ML-Äquivalent haben, entweder einen Core-ML-Custom-Layer (Swift-Code, der die fehlende Op ausführt) oder eine Modellarchitektur-Änderung, um die Op vor der Konvertierung zu entfernen. Beides ist gut dokumentiert⁵.

Latenzbudgets, die tatsächlich greifen

Drei Latenzbudgets sind für produktive Apps relevant:

16 ms (60 fps Live-UI). Ein Echtzeit-Kamerafilter, eine AR-Szene, die pro Frame aktualisiert wird, ein Live-Audio-Analyzer. Das Budget umfasst alles: Bildvorverarbeitung, Modellinferenz, Nachverarbeitung, UI-Update. Modelle, die hineinpassen, sind typischerweise klein (MobileNetV3-Klasse, unter 100M Parameter) und laufen auf der Neural Engine.

100 ms (interaktive UI). Ein Benutzer löst eine Aktion aus und wartet auf das Ergebnis: Tippen zum Identifizieren, Zeichnen zum Erkennen, Diktieren zum Transkribieren. Das Budget ist großzügiger und unterstützt größere Modelle. Sprachmodelle mit unter einer Milliarde Parametern, kleine Vision-Transformer und die meisten produktionstauglichen Klassifikatoren passen bequem hinein.

1 s+ (Hintergrund oder Batch). Indizierung der Fotomediathek, Dokumentenanalyse, Modell-Warmup beim App-Start. Größere Modelle funktionieren, aber die Benutzererwartung muss durch eine Fortschrittsanzeige gesetzt werden. Das On-Device-LLM von Foundation Models ist hier angesiedelt für die Operationen mit größerem Kontextfenster.

Die Budgets sind Richtwerte, keine harten Grenzen. Der richtige Schritt ist, auf einem Zielgerät mit os_signpost oder dem Core-ML-Template von Instruments⁶ zu messen, statt theoretischen Zahlen einer anderen Maschine zu vertrauen.

Quantisierung: wenn kleiner schneller bedeutet

Core ML unterstützt mehrere Quantisierungsstufen⁷:

• Float32 (volle Präzision). Der Trainings-Default. Am größten, am genauesten, am langsamsten.
• Float16. Halbe Präzision. Kleiner und schneller auf GPU und NE; der Genauigkeitsverlust ist bei gut konditionierten Modellen meist vernachlässigbar.
• INT8. 8-Bit-Integer-Quantisierung mit Kalibrierung. Etwa 4x kleiner als Float32, oft 2-4x schneller auf der NE. Genauigkeitsverlust variiert; bei Vision-Modellen lassen sich mit Quantization-Aware Training Top-1-Genauigkeitsverluste unter 1 % erreichen.
• INT4 und darunter. Aggressive Quantisierung, die neuere Core-ML-Versionen für bestimmte Modellarchitekturen unterstützen (LLMs, große Vision-Modelle). Signifikanter Genauigkeitsverlust ist der Trade-off; die Technik funktioniert am besten in Kombination mit modellbewusstem Quantization-Aware Training.

Die Konfiguration der linearen Quantisierung über coremltools.optimize.coreml.linear_quantize_weights akzeptiert eine globale Op-Konfiguration, die den Quantisierungsmodus (linear_symmetric oder linear) sowie einen Schwellenwert für die Gewichtsgröße auswählt, unterhalb dessen die Gewichte in voller Präzision bleiben. Die Konvertierung läuft gegen ein vorhandenes .mlpackage und erzeugt ein neues quantisiertes Paket; beide können nebeneinander im Bundle ausgeliefert werden, wobei die App basierend auf der Geräteklasse entscheidet, welches sie lädt.

Die Quantisierungsentscheidung ist modellabhängig: Ein kleiner Klassifikator profitiert möglicherweise nicht, weil seine Berechnungen ohnehin günstig sind; ein großes Sprachmodell profitiert enorm, weil seine Berechnung von Matrixmultiplikationen auf den quantisierten Gewichten dominiert wird. Der richtige Ansatz ist: quantisieren, Genauigkeit auf einem zurückgehaltenen Testset messen, und ausliefern, wenn der Genauigkeitsverlust für den Anwendungsfall akzeptabel ist.

Apples integrierte Modelle, die Sie direkt einsetzen können

Apple liefert mehrere vortrainierte Core-ML-Modelle über die Seite Core ML Models aus⁸. Wichtige Kategorien:

• Bildklassifikation: MobileNetV2, ResNet50, SqueezeNet-Varianten, alle gebündelt und einsatzbereit für eine VNCoreMLRequest des Vision-Frameworks.
• Objekterkennung: YOLOv3, MNIST, CenterNet-Varianten.
• Posenschätzung: PoseNet für Körperhaltung (eine Baseline-Alternative zu VNDetectHumanBodyPoseRequest aus Vision).
• Semantische Segmentierung: DeepLabV3 für Bildsegmentierung.
• Texterkennung: ML-basierte OCR-Alternativen zur eingebauten Vision-Funktion.

Für die meisten Apps decken die vortrainierten Modelle von Apple die Wahrnehmungsprimitive (klassifizieren, erkennen, segmentieren) ab, ohne dass eigenes Training nötig ist. Das On-Device-LLM von Foundation Models (behandelt in Foundation Models on-device LLM) ist das größte Beispiel: ein LLM mit mehreren Milliarden Parametern, das als Core-ML-Modell hinter einem hochstufigen Swift-API ausgeliefert wird, auf der Neural Engine dispatcht und offline verfügbar ist.

Modellverschlüsselung und App-Store-Überlegungen

Ein .mlpackage im App-Bundle ist für jeden lesbar, der die IPA entpackt. Für Modelle, die nennenswertes geistiges Eigentum darstellen, unterstützt Apple Modellverschlüsselung über den Workflow Encrypt your Core ML model⁹: Ein Schlüssel wird über Xcode generiert und über CloudKit verwaltet, das Modell im Bundle wird verschlüsselt, und Core ML entschlüsselt zur Ladezeit.

Für die meisten Apps ist Verschlüsselung übertrieben. Ein auf gewöhnlichen ImageNet-Daten trainiertes Modell ist kein Wettbewerbsdifferenzierer; es zu verschlüsseln fügt Betriebskomplexität hinzu, ohne etwas Wertvolles zu schützen. Reservieren Sie Verschlüsselung für Modelle, die echte Investitionen in Trainingsdaten oder Wettbewerbsvorteile repräsentieren.

On-Device-Privatsphäre: der architektonische Gewinn

Die Privacy-Story ist klar. Core-ML-Inferenz findet vollständig auf dem Gerät statt. Eingabedaten (Bilder, Audio, Text) verlassen das Gerät nicht. Die Modelldatei ist lokal; die Inferenz ist lokal; das Ergebnis ist lokal.

Für Apps in regulierten Branchen (Gesundheit, Finanzen, Bildung) eliminiert dieser architektonische Fakt eine ganze Klasse an Compliance-Arbeit. Es gibt keinen Drittanbieter-Datenverarbeiter, der zu einer Datenschutzerklärung hinzugefügt werden muss. Es gibt keinen Modell-API-Endpunkt, der auf Sicherheit zu prüfen wäre. Es gibt keine Datenresidenz-Frage, weil die Daten sich nie bewegen.

Das Privacy-Manifest-Format¹⁰ kodifiziert die Privacy-Story für die App-Store-Einreichung: Eine App, die Core ML für On-Device-Inferenz und sonst nichts nutzt, kann für den Inferenzpfad null Drittanbieter-Datenweitergabe deklarieren. Der Einreichungsprozess wird schneller, die Datenschutzprüfung kürzer, und das benutzerseitige Privacy-Nutrition-Label sauberer.

Die Verbindung zum Agenten-Workflow

Core ML verbindet sich mit drei Mustern, die im Cluster bereits behandelt wurden:

Vision Frameworks VNCoreMLRequest. Eigene Core-ML-Modelle laufen über die Vision-Pipeline mit automatischer Vorverarbeitung. Dieses Muster (behandelt in Vision Framework) ist der richtige Weg, einen eigenen Bildklassifikator oder -detektor in einer iOS-App auszuliefern.

On-Device-LLM von Foundation Models. Das LLM von Apple Intelligence ist ein Core-ML-Modell hinter einem hochstufigen Swift-API. Dieselben Muster gelten: Dispatching (Neural Engine zuerst), Quantisierung (INT4 für die LLM-Gewichte) und Latenzbudgetierung (Subsekunden-Latenz für kurze Generationen). Der Beitrag zu Foundation Models behandelt das API; dieser Beitrag behandelt die zugrundeliegende Engine.

App-Intents-Tools, die lokales ML nutzen. Ein AppIntent, der einen lokalen Bild- oder Textklassifikator ausführt, gibt strukturierte Ergebnisse an Apple Intelligence zurück, ohne Netzwerk-Roundtrip. Diese Kombination ist es, die „agentisches Apple” tatsächlich privat macht; die Werkzeuge des Agenten laufen lokal, weil das Framework es unterstützt.

Wann Cloud-Inferenz die richtige Wahl ist

Die Decke von Core ML ist die Rechenleistung des Geräts. Drei Fälle, in denen Cloud korrekt ist:

Modelle zu groß für ein Bundle. Ein LLM mit 70 Milliarden Parametern passt nicht in ein App-Bundle. Für Workloads dieser Größenordnung ist Cloud-Inferenz (oder On-Device-via-Streaming-Gewichte, ein anderes Muster) das richtige Werkzeug.

Geräteübergreifender geteilter Zustand während der Inferenz. Modelle, die während der Inferenz aus einer geteilten Datenbank lesen oder in sie schreiben müssen (Empfehlungssysteme mit kollaborativem Filtern gegen Milliarden Datensätze). Das rein lokale Modell von Core ML passt hier nicht.

Schnelle Modelliteration. Ein Team, das täglich Modellaktualisierungen ausliefert, profitiert von serverseitiger Inferenz, weil Rollouts keine App-Store-Review-Zyklen erfordern. Das Bundle-the-Model-in-the-App-Muster von Core ML fügt dem Modell-Revisionstempo Reibung hinzu; dieser Trade-off ist real.

Das Muster: Cloud gewinnt bei Skalierung und Iterationsgeschwindigkeit; Core ML gewinnt bei Latenz, Kosten und Privatsphäre.

Was dieses Muster für iOS 26+ Apps bedeutet

Drei Erkenntnisse.

1. Wählen Sie Core ML als Default für jedes Modell, das in das Bundle passt und ein Pro-Aufruf-Ergebnis liefert, auf das der Benutzer reagieren kann. Bildklassifikation, Objekterkennung, Audioklassifikation, Gestenerkennung, Embedding-Generierung, kleine bis mittlere Sprachaufgaben. Das automatische Dispatching des Frameworks und die Apple-Silicon-NPU produzieren Submillisekunden- bis niedrige zweistellige Millisekunden-Inferenz – kostenlos.

2. Quantisieren Sie aggressiv, wenn der Genauigkeitsverlust akzeptabel ist. INT8 ist meist sicher; INT4 ist angemessen für große Modelle, bei denen die Größenersparnis zählt. Messen Sie die Genauigkeit auf einem zurückgehaltenen Set, statt darauf zu vertrauen, dass Quantisierung universell sicher ist.

3. Kombinieren Sie mit Vision und Foundation Models für vollständige lokale Pipelines. Core ML ist die Engine; Vision ist das Wahrnehmungs-API darüber; Foundation Models ist das LLM darüber. Der Vision-Beitrag und der Foundation-Models-Beitrag des Clusters behandeln die übergeordneten Schichten.

Das vollständige Apple-Ecosystem-Cluster: typisierte App Intents; MCP-Server; die Routing-Frage; Foundation Models; die Unterscheidung zwischen Laufzeit- und Tooling-LLM; drei Oberflächen; das Single-Source-of-Truth-Muster; Zwei MCP-Server; Hooks für die Apple-Entwicklung; Live Activities; der watchOS-Laufzeitvertrag; SwiftUI-Internas; RealityKits räumliches Mentalmodell; SwiftData-Schema-Disziplin; Liquid-Glass-Muster; Multi-Plattform-Auslieferung; die Plattform-Matrix; Vision-Framework; Symbol Effects; worüber ich nicht schreibe. Der Hub liegt unter Apple Ecosystem Series. Für den weiteren Kontext „iOS mit KI-Agenten” siehe den iOS Agent Development Guide.

FAQ

Wie entscheidet Core ML zwischen Neural Engine, GPU und CPU?

Core ML untersucht jede Operation im Modellgraphen und dispatcht sie zum schnellsten Ziel, das die Operation unterstützt. Die Neural Engine verarbeitet unterstützte Operationen (die meisten Matrixmultiplikationen, Convolutions, Attention) mit der niedrigsten Latenz und dem geringsten Energieverbrauch. Die GPU verarbeitet Ops, die die NE nicht unterstützt. Die CPU verarbeitet den Rest. Die Entscheidung ist pro Operation, automatisch und schneller als eine handgeschriebene Heuristik.

Sollte ich immer .computeUnits = .all verwenden?

Fast immer. Das automatische Dispatching des Frameworks ist gut abgestimmt. Override auf .cpuOnly, wenn auf Output-Parität getestet wird (dasselbe Modell liefert auf NE vs. CPU aufgrund von Gleitkomma-Rundung leicht unterschiedliche Ergebnisse), oder auf .cpuAndGPU, um die Neural Engine für eine parallele Aufgabe freizugeben.

Was ist der praktische Unterschied zwischen .mlpackage und .mlmodel?

.mlpackage ist das in Xcode 13 eingeführte moderne Format. Es unterstützt gespeicherte Metadaten, mehrere Modellvarianten für ML-Program-Kompilierung (mlprogram) und die Toolchain ab iOS 13. .mlmodel ist das Legacy-Format. Beide laden weiterhin über MLModel; neue Entwicklung sollte .mlpackage verwenden.

Wie groß darf ein Core-ML-Modell in einem App-Bundle sein?

Es gibt keine feste Obergrenze, aber App-Store-Bundle-Größen sind auf 4 GB für den Download begrenzt und haben praktische Grenzen für Over-the-Air-Installation. Das On-Device-LLM von Foundation Models ist etwa 3 GB groß und wird vom Betriebssystem statt vom App-Bundle verteilt. Für app-gebündelte Modelle ist sub-100 MB komfortabel; 100-500 MB ist mit einer Lade-Strategie zur Startzeit machbar; 500 MB+ wird am besten über BGProcessingTask-Hintergrunddownload oder On-Demand-Resources gehandhabt.

Wie weiß ich, ob die Quantisierung die Genauigkeit meines Modells beeinträchtigt hat?

Halten Sie ein Testset zurück, führen Sie die Inferenz auf dem ursprünglichen Float32-Modell und dem quantisierten Modell aus, vergleichen Sie die Metriken (Top-1-Genauigkeit für Klassifikatoren, F1 für Detektoren, Perplexität für Sprachmodelle, BLEU für Übersetzung etc.) und entscheiden Sie auf Basis der Genauigkeitsanforderungen der Anwendung. Quantization-Aware Training (Training des Modells mit simulierter Quantisierung im Loss) gewinnt typischerweise den Großteil des Genauigkeitsverlusts zurück.

References