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

Core ML ist die On-Device-Inferenz-Engine, die auf jedem modernen Apple-Gerät mitgeliefert wird. Das Framework verteilt die Arbeit an die Neural Engine, sofern verfügbar, an die GPU, wenn nicht, und an die CPU als letzten Ausweg; den schnellsten Pfad wählt es automatisch anhand von Modell und Hardware¹. Auf einem aktuellen iPhone ergibt das Inferenz mit Latenzen von unter einer Millisekunde bis zu wenigen Dutzend Millisekunden für die meisten produktiven Modellgrößen, kostenlos pro Aufruf, ohne Netzwerk-Roundtrip und ohne Datenweitergabe an Dritte.

Der Ruf des Frameworks als „obskure Infrastruktur“ ist überholt. Core ML treibt seit fast einem Jahrzehnt Funktionen auf dem Gerät an, von der semantischen Suche in Fotos bis zu den meisten Drittanbieter-Apps mit lokalem ML, und es bleibt die produktive Oberfläche für ein fixes, konvertiertes Modell auf jedem Betriebssystem zurück bis iOS 11. Seine Position im Stack hat sich auf der WWDC 2026 allerdings verschoben: Apple stellte Core AI als das Low-Level-Framework hinter On-Device-Apple-Intelligence vor und benannte es als Richtung für neue Arbeit an neuronalen Netzen¹¹¹². Die Muster, die ein Core-ML-Deployment tatsächlich auslieferungsfähig machen statt bloß „läuft auf meinem Mac“, sind unverändert und nach wie vor eine kleine Menge: Modellkonvertierung, Dispatch-Hinweise, Latenzbudgetierung und Quantisierung. Dieser Beitrag geht jedes einzelne davon anhand von Apples Dokumentation durch und ordnet Core ML anschließend in den Stack nach der WWDC26 ein.

TL;DR

• Core ML führt .mlpackage- und .mlmodel-Dateien auf der Neural Engine, der GPU und der CPU von Apple Silicon aus. Die Verteilung erfolgt automatisch, lässt sich aber über MLModelConfiguration.computeUnits steuern².
• Die Modellkonvertierung läuft über coremltools (PyTorch, TensorFlow, ONNX → Core ML). Die Konvertierung ist eine Aufgabe der Toolchain, keine Laufzeitaufgabe; sobald ein Modell konvertiert und mitgeliefert ist, lädt die App es und führt es aus.
• Die Unified-Memory-Architektur von Apple Silicon bedeutet, dass Modellgewichte nicht zwischen CPU, GPU und NE kopiert werden; derselbe Speicher liegt allen dreien zugrunde³. Genau dieses architektonische Detail macht Inferenz im Submillisekundenbereich möglich.
• Quantisierung (INT8, INT4 in aktuellen Core-ML-Versionen) verkleinert Modelle und beschleunigt die Inferenz auf der Neural Engine, zu messbaren Genauigkeitskosten, die vom Modell abhängen. coremltools 9.0 (November 2025) ergänzt Deployment-Ziele für iOS 26, das Lesen und Schreiben von Modellzustand sowie int8-Ein- und -Ausgaben¹³.
• Mit der WWDC 2026 hat sich der Stack verändert: Apple positioniert Core AI als das Inferenz-Framework hinter On-Device-Apple-Intelligence und als Oberfläche für neue Arbeit an neuronalen Netzen, während Core ML als produktive Schicht für fixe konvertierte Modelle und klassisches ML weiterläuft¹¹¹².

Das mentale Modell: drei Rechenpfade, ein Speicher

Apple Silicon (M-Macs und A-Chips im iPhone ab dem A12 Bionic) bringt drei Inferenzziele mit:

Neural Engine. Ein spezialisierter Beschleuniger für Matrixmultiplikation bei niedriger Präzision. Am schnellsten für jene Operationen, auf die moderne ML-Modelle angewiesen sind (Faltungen, Attention, Embeddings). Geringster Stromverbrauch. Beschränkt auf bestimmte Operationstypen und Tensorformen; nicht unterstützte Operationen fallen pro Layer auf GPU oder CPU zurück.

GPU. Allgemeine parallele Berechnung über Metal. Langsamer als die Neural Engine bei ML-typischer Arbeit, aber schneller als die CPU. Übernimmt Operationen, die die Neural Engine nicht unterstützt.

CPU. Der Rückfallpfad. Langsam für ML-Inferenz, dafür immer verfügbar, immer zu jeder Operation fähig und berechenbar.

Die Unified-Memory-Architektur bedeutet, dass derselbe physische Arbeitsspeicher allen dreien zugrunde liegt³. Einmal geladene Modellgewichte werden nicht kopiert, wenn die Verteilung zwischen den Zielen wechselt. Genau diese architektonische Tatsache macht aus der Verteilung auf mehrere Ziele statt Kopierkosten pro Layer eine Scheduling-Entscheidung pro Layer.

MLModelConfiguration.computeUnits steuert die Verteilung:

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

.all ist die Voreinstellung und für nahezu jede App die richtige Wahl. Das Framework wählt pro Operation den schnellsten Pfad, und diese Entscheidung pro Operation ist besser als jede Heuristik, die Entwickler selbst schreiben würden. Der seltene Grund für ein Übersteuern liegt darin, .cpuOnly für Testparität zu erzwingen (ein Modell verhält sich auf verschiedenen Pfaden unterschiedlich und der Test braucht den deterministischen Pfad) oder .cpuAndGPU zu erzwingen, um die Neural Engine für eine andere gleichzeitige Aufgabe freizugeben.

Modellkonvertierung: die Aufgabe der Toolchain

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

Eine typische Konvertierung von PyTorch nach Core ML folgt drei Schritten:

1. Das trainierte PyTorch-Modell laden und in den Inferenzmodus versetzen.
2. Das Modell mit einem Beispiel-Eingabetensor tracen, der der produktiven Eingabeform entspricht.
3. Das getracte Modell mit coremltools gegen eine iOS-Zielversion 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.iOS26,
    compute_units=ct.ComputeUnit.ALL,
)
mlmodel.save("MyModel.mlpackage")

Die Konvertierung geschieht einmalig, in einer Entwicklungsumgebung, gegen eine iOS-Zielversion (minimum_deployment_target). Das erzeugte .mlpackage ist das, was ins Xcode-Projekt gelegt wird. Die App führt zur Laufzeit kein coremltools aus. Die aktuelle Ausgabe, coremltools 9.0, ergänzt Deployment-Ziele bis iOS 26, die Möglichkeit, Modellzustand zu lesen und zu schreiben (für zustandsbehaftete Modelle wie Transformer-Decoder mit KV-Caches), int8-Ein- und -Ausgaben sowie Unterstützung für Python 3.13 und PyTorch 2.7¹³.

Zwei praktische Fallen bei der Konvertierung. Erstens brauchen Eingaben mit dynamischer Form eine ausdrückliche Behandlung über ct.RangeDim, weil die statische Formvorgabe von Core ML wenig hilfreiche Fehler erzeugt, sobald die produktive App wechselnde Eingabegrößen liefert. Zweitens benötigen eigene Operationen in PyTorch ohne Core-ML-Entsprechung entweder einen Core-ML-Custom-Layer (Swift-Code, der die fehlende Operation ausführt) oder eine Änderung der Modellarchitektur, die die Operation vor der Konvertierung entfernt. Beides ist gut dokumentiert⁵.

Latenzbudgets, die tatsächlich greifen

Für ausgelieferte Apps zählen drei Latenzbudgets:

16 ms (Live-UI mit 60 fps). Ein Echtzeit-Kamerafilter, eine AR-Szene, die sich pro Frame aktualisiert, ein Live-Audioanalysator. Das Budget umfasst alles: Bildvorverarbeitung, Modellinferenz, Nachverarbeitung, UI-Aktualisierung. Passende Modelle sind typischerweise klein (Klasse MobileNetV3, unter 100 Mio. Parameter) und laufen auf der Neural Engine.

100 ms (interaktive UI). Benutzer lösen eine Aktion aus und warten auf das Ergebnis: tippen zum Identifizieren, zeichnen zum Erkennen, diktieren zum Transkribieren. Das Budget ist großzügiger und trägt größere Modelle. Sprachmodelle unter 1 Mrd. Parametern, kleine Vision-Transformer und die meisten produktionsreifen Klassifikatoren passen bequem hinein.

1 s und mehr (Hintergrund oder Batch). Indizierung der Fotomediathek, Dokumentenanalyse, Aufwärmen des Modells beim App-Start. Größere Modelle funktionieren, doch die Erwartung der Benutzer muss über eine Fortschrittsanzeige gesetzt werden. Das On-Device-LLM der Foundation Models liegt hier, sobald es um Operationen mit größerem Kontextfenster geht.

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

Quantisierung: wenn kleiner schneller ist

Core ML unterstützt mehrere Quantisierungsstufen⁷:

• Float32 (volle Präzision). Die Voreinstellung beim Training. 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-Ganzzahlquantisierung mit Kalibrierung. Rund 4x kleiner als Float32, oft 2-4x schneller auf der NE. Der Genauigkeitsverlust schwankt; bei Vision-Modellen ist mit quantisierungsbewusstem Training ein Verlust von unter 1 % Top-1-Genauigkeit erreichbar.
• INT4 und darunter. Aggressive Quantisierung, die aktuelle Core-ML-Versionen für bestimmte Modellarchitekturen unterstützen (LLMs, große Vision-Modelle). Der Preis dafür ist ein deutlicher Genauigkeitsverlust; die Technik wirkt am besten zusammen mit modellbewusstem, quantisierungsbewusstem Training.

Die Konfiguration linearer Quantisierung über coremltools.optimize.coreml.linear_quantize_weights nimmt eine globale Op-Konfiguration entgegen, die den Quantisierungsmodus (linear_symmetric oder linear) wählt, sowie einen Schwellenwert für die Gewichtsgröße, unterhalb dessen Gewichte in voller Präzision bleiben. Die Umwandlung läuft gegen ein vorhandenes .mlpackage und erzeugt ein neues, quantisiertes Paket; beide lassen sich nebeneinander im Bundle ausliefern, wobei die App nach Geräteklasse entscheidet, welches sie lädt.

Die Entscheidung über Quantisierung fällt pro Modell: Ein kleiner Klassifikator profitiert womöglich nicht, weil seine Berechnung ohnehin günstig ist; ein großes Sprachmodell profitiert enorm, weil seine Berechnung von Matrixmultiplikationen auf den quantisierten Gewichten bestimmt wird. Der richtige Weg ist, zu quantisieren, die Genauigkeit auf einem zurückgehaltenen Testsatz zu messen und auszuliefern, sofern der Genauigkeitsverlust für den Anwendungsfall vertretbar ist.

Apples eingebaute Modelle zum direkten Einsetzen

Apple liefert mehrere vortrainierte Core-ML-Modelle über die Seite Core ML Models⁸. Kategorien, die man kennen sollte:

• Bildklassifikation: MobileNetV2, ResNet50, SqueezeNet-Varianten, alle fertig gebündelt und bereit, in einen VNCoreMLRequest des Vision-Frameworks eingesetzt zu werden.
• Objekterkennung: YOLOv3, MNIST, CenterNet-Varianten.
• Posenschätzung: PoseNet für die Körperhaltung (eine Basisalternative zu VNDetectHumanBodyPoseRequest aus Vision).
• Semantische Segmentierung: DeepLabV3 für Bildsegmentierung.
• Texterkennung: ML-basierte OCR-Alternativen zur eingebauten Variante von Vision.

Für die meisten Apps decken Apples vortrainierte Modelle die Wahrnehmungsprimitive ab (klassifizieren, erkennen, segmentieren), ohne dass eigenes Training nötig wäre. Für Sprachaufgaben sitzt das systemeigene On-Device-LLM vollständig über dieser Schicht: Das Foundation Models Framework macht es hinter einer Swift-API auf hoher Ebene zugänglich, offline und kostenlos, ohne eine Modelldatei, die Sie bündeln oder konvertieren müssten.

Modellverschlüsselung und Überlegungen zum App Store

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

Für die meisten Apps ist Verschlüsselung überzogen. Ein auf handelsüblichen ImageNet-Daten trainiertes Modell ist kein Wettbewerbsvorteil; es zu verschlüsseln erhöht den betrieblichen Aufwand, ohne etwas Wertvolles zu schützen. Verschlüsselung bleibt Modellen vorbehalten, in deren Trainingsdaten echte Investitionen stecken oder die einen Wettbewerbsvorsprung darstellen.

Datenschutz auf dem Gerät: der architektonische Gewinn

Die Datenschutzlage ist eindeutig. Core-ML-Inferenz läuft vollständig auf dem Gerät. 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) beseitigt diese architektonische Tatsache eine ganze Klasse von Compliance-Arbeit. Es gibt keinen Auftragsverarbeiter, den man in eine Datenschutzerklärung aufnehmen müsste. Es gibt keinen Modell-API-Endpunkt, den man sicherheitstechnisch prüfen müsste. Es gibt keine Frage nach dem Speicherort der Daten, weil die Daten sich nie bewegen.

Das Format des Privacy Manifest¹⁰ hält die Datenschutzlage für die Einreichung im App Store fest: Eine App, die Core ML für Inferenz auf dem Gerät nutzt und sonst nichts, kann für den Inferenzpfad null Datenweitergabe an Dritte erklären. Der Einreichungsprozess wird schneller, die Datenschutzprüfung kürzer und das für Benutzer sichtbare Datenschutzetikett sauberer.

Die Verbindung zum Agenten-Workflow

Core ML fügt sich mit drei Mustern zusammen, die dieses Cluster bereits behandelt hat:

VNCoreMLRequest aus dem Vision-Framework. Eigene Core-ML-Modelle laufen mit automatischer Vorverarbeitung durch die Vision-Pipeline. Dieses Muster (behandelt im Beitrag Vision Framework) ist der richtige Weg, einen eigenen Bildklassifikator oder Detektor in einer iOS-App auszuliefern.

Das On-Device-LLM der Foundation Models. Das System-LLM von Apple Intelligence liegt hinter dem Foundation Models Framework, und seit der WWDC 2026 benennt Apple Core AI als das Inferenz-Framework dahinter¹¹. Die Konzepte aus diesem Beitrag übertragen sich weiterhin unmittelbar: Verteilung auf Recheneinheiten, quantisierte Gewichte und Latenzbudgets bestimmen das System-LLM genauso wie ein selbst konvertiertes Modell. Der Framework-Beitrag behandelt die LLM-API; dieser Beitrag behandelt die darunterliegenden Inferenzmuster.

App-Intents-Werkzeuge mit lokalem ML. Ein AppIntent, der einen lokalen Bild- oder Textklassifikator ausführt, liefert strukturierte Ergebnisse an Apple Intelligence zurück, ohne Netzwerk-Roundtrip. Diese Kombination macht ein „agentisches Apple“ tatsächlich privat; die Werkzeuge des Agenten laufen lokal, weil das Framework es hergibt.

Wann Cloud-Inferenz die richtige Wahl ist

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

Modelle, die zu groß für ein Bundle sind. Ein LLM mit 70 Mrd. Parametern passt nicht in ein App-Bundle. Für Lasten dieser Größenordnung ist Cloud-Inferenz (oder Ausführung auf dem Gerät mit gestreamten Gewichten, ein anderes Muster) das richtige Werkzeug.

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

Schnelle Modelliteration. Ein Team, das täglich Modellaktualisierungen ausliefert, profitiert von serverseitiger Inferenz, weil Rollouts keine Prüfzyklen im App Store erfordern. Das Muster von Core ML, das Modell in die App zu packen, bremst die Taktung neuer Modellstände; dieser Zielkonflikt ist real.

Das Muster: Die Cloud gewinnt bei Skalierung und Iterationstempo; Core ML gewinnt bei Latenz, Kosten und Datenschutz.

Wo Core ML nach der WWDC 2026 steht

Die WWDC 2026 hat die Landkarte unter diesem Beitrag neu gezeichnet, ohne ihn zu entwerten. Apple stellte Core AI vor, ein iOS-27-Framework, dessen Kurzbeschreibung „Run AI models in your app on Apple silicon“ lautet, und erklärte in Session 324, Core AI sei das Inferenz-Framework hinter On-Device-Apple-Intelligence und stehe nun auch Drittanbieter-Apps offen¹¹. Wo der Konverter von Core ML die Entscheidungen über Hardware und Optimierung für Sie trifft, gibt Core AI Ihnen die Hebel in die Hand: ausdrückliche Modellspezialisierung, einen verwalteten Artefakt-Cache, gezielte Auswahl der Recheneinheiten und asynchrone Compute-Streams. Die vollständige Auseinandersetzung steht in Core AI: Modelle auf Apple Silicon ausführen.

Das Signal zur Marschrichtung ist stärker, als die Dokumentation allein vermuten lässt. Im Group Lab zu maschinellem Lernen auf der WWDC 2026 sagte ein Core-AI-Ingenieur, Apple bitte alle, die mit neuronalen Netzen arbeiten, künftig auf Core AI zu wechseln, während Core ML bestehen bleibe, sich aber auf klassisches maschinelles Lernen wie Entscheidungsbäume konzentriere¹². Diese Aussage ist eine Paraphrase aus dem Lab und keine veröffentlichte Richtlinie, sie passt jedoch zur Form des Releases: Core AI bekam die neue Toolchain, die neuen Formate und die Last von Apple Intelligence.

Die praktische Lesart für eine App, die heute ausgeliefert wird:

• Bestehende Core-ML-Deployments laufen weiter. Nichts in iOS 27 erklärt den Weg über .mlpackage für veraltet, und coremltools 9.0 hat noch im November 2025 neue Fähigkeiten gebracht (iOS-26-Ziele, zustandsbehaftete Modelle, int8-IO)¹³.
• Core ML bleibt unterhalb von iOS 27 die einzige Option und die pragmatische Wahl für ein fixes, konvertiertes Modell, bei dem die Voreinstellungen des Konverters genau das Gewünschte liefern.
• Neue Arbeit an neuronalen Netzen für iOS 27+ sollte zuerst Core AI prüfen, besonders dort, wo Sie die benötigte Spezialisierung, Zwischenspeicherung oder Steuerung des Schedulings konkret benennen können.
• Die übrigen Schichten bewegen sich nicht. Das System-LLM bleibt hinter Foundation Models, und MLX bleibt das einbettbare Array-Framework für Modelle mit offenen Gewichten und für eigene Feinabstimmungen. Core ML gegen Core AI ist eine Frage der Ausführungsschicht für Ihr Modell, keine Frage dieser beiden.

Was dieses Muster für Apps ab iOS 26 bedeutet

Drei Erkenntnisse.

1. Nehmen Sie standardmäßig Core ML für jedes Modell, das ins Bundle passt und pro Aufruf ein Ergebnis liefert, mit dem Benutzer etwas anfangen können. Bildklassifikation, Objekterkennung, Audioklassifikation, Gestenerkennung, Erzeugung von Embeddings, kleine bis mittlere Sprachaufgaben. Die automatische Verteilung des Frameworks und die NPU von Apple Silicon liefern kostenlos Inferenz von unter einer Millisekunde bis zu wenigen Dutzend Millisekunden.

2. Quantisieren Sie aggressiv, solange der Genauigkeitsverlust vertretbar ist. INT8 ist meist unbedenklich; INT4 eignet sich für große Modelle, bei denen die Größenersparnis zählt. Messen Sie die Genauigkeit auf einem zurückgehaltenen Datensatz, statt darauf zu vertrauen, dass Quantisierung allgemein unbedenklich sei.

3. Kombinieren Sie Vision und Foundation Models zu vollständig lokalen Pipelines. Core ML ist die Engine; Vision ist die Wahrnehmungs-API darüber; Foundation Models ist das LLM darüber. Der Vision-Beitrag und der Foundation-Models-Beitrag dieses Clusters behandeln die höher liegenden Oberflächen.

Das vollständige Cluster zum Apple-Ökosystem: typisierte App Intents; MCP-Server; die Routing-Frage; Foundation Models; die Unterscheidung zwischen Laufzeit- und Werkzeug-LLM; drei Oberflächen; das Muster der einzigen Wahrheitsquelle; Zwei MCP-Server; Hooks für die Apple-Entwicklung; Live Activities; der watchOS-Laufzeitvertrag; SwiftUI-Interna; das räumliche mentale Modell von RealityKit; Schemadisziplin in SwiftData; Liquid-Glass-Muster; Auslieferung für mehrere Plattformen; die Plattformmatrix; Vision-Framework; Symbol Effects; worüber ich bewusst nicht schreibe. Der Knotenpunkt ist die Serie zum Apple-Ökosystem. Für den breiteren Kontext zu iOS mit KI-Agenten siehe den Leitfaden zur iOS-Agentenentwicklung.

Häufige Fragen

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

Core ML prüft jede Operation im Modellgraphen und weist sie dem schnellsten Ziel zu, das die Operation unterstützt. Die Neural Engine übernimmt unterstützte Operationen (die meisten Matrixmultiplikationen, Faltungen, Attention) bei niedrigster Latenz und geringstem Stromverbrauch. Die GPU übernimmt Operationen, die die NE nicht unterstützt. Die CPU übernimmt den Rest. Die Entscheidung fällt pro Operation, automatisch und besser als jede handgeschriebene Heuristik.

Sollte ich immer .computeUnits = .all verwenden?

Fast immer. Die automatische Verteilung des Frameworks ist gut abgestimmt. Setzen Sie auf .cpuOnly, wenn Sie auf Ausgabeparität testen (dasselbe Modell liefert auf NE und CPU wegen Fließkommarundung leicht abweichende Ergebnisse), oder auf .cpuAndGPU, um die Neural Engine für eine gleichzeitige Aufgabe freizugeben.

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

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

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

Eine feste Grenze gibt es nicht, aber App-Store-Bundles sind beim Download auf 4 GB gedeckelt und stoßen bei der Installation über Mobilfunk auf praktische Grenzen. Das systemeigene On-Device-LLM umgeht die Frage vollständig: Das Betriebssystem verteilt es, und Apps erreichen es über Foundation Models, ohne irgendetwas zu bündeln. Für Modelle im App-Bundle sind unter 100 MB bequem; 100-500 MB sind mit einer Ladestrategie beim Start machbar; alles über 500 MB behandelt man am besten über einen Hintergrunddownload per BGProcessingTask oder über On-Demand-Ressourcen.

Sollte ich für ein neues Modell Core ML oder Core AI verwenden?

Unterhalb von iOS 27 ist Core ML die einzige Option. Ab iOS 27 lautet Apples erklärte Richtung Core AI für neuronale Netze, während Core ML für klassisches maschinelles Lernen und bestehende Deployments weiterläuft¹¹¹². Wenn Sie ein fixes, konvertiertes Modell haben und die Voreinstellungen des Konverters Ihnen genügen, lässt sich Core ML weiterhin problemlos ausliefern; brauchen Sie ausdrückliche Kontrolle über Spezialisierung, Zwischenspeicherung oder Scheduling, dann ist genau diese Kontrolle der Grund, aus dem Core AI existiert.

Woran erkenne ich, ob die Quantisierung der Genauigkeit meines Modells geschadet hat?

Halten Sie einen Testsatz zurück, führen Sie die Inferenz auf dem ursprünglichen Float32-Modell und auf dem quantisierten Modell aus, vergleichen Sie die Kennzahlen (Top-1-Genauigkeit bei Klassifikatoren, F1 bei Detektoren, Perplexität bei Sprachmodellen, BLEU bei Übersetzung usw.) und entscheiden Sie anhand der Genauigkeitsanforderungen der Anwendung. Quantisierungsbewusstes Training (Training des Modells mit simulierter Quantisierung im Verlust) holt den Genauigkeitsverlust meist weitgehend zurück.

Referenzen