Core AI: Modelle auf Apple Silicon ausführen

Im On-Device-KI-Stack von Apple fehlte bislang eine Sprosse. Foundation Models liefert Ihnen das System-LLM, versiegelt und kostenlos. Core ML führt ein festes, konvertiertes Modell aus, wobei der Konverter die Hardware-Entscheidungen für Sie trifft. MLX bietet ein Array-Framework, das Sie einbetten, und ein Modell, das Sie auswählen. iOS 27 fügt die Sprosse unterhalb dieser drei hinzu: Core AI, ein Framework, dessen einzeiliger Abriss lautet „Run AI models in your app on Apple silicon.”¹ Es ist die Oberfläche für die Modellausführung – der Ort, zu dem Sie greifen, wenn Sie Spezialisierung, Caching und Inference-Scheduling selbst steuern wollen, statt die Standardwerte einer höheren Schicht hinzunehmen.

In Session 324 positioniert Apple Core AI als dasselbe Inference-Framework, das On-Device-Apple-Intelligence antreibt – nun geöffnet für die Intelligenz Ihrer eigenen App.¹⁵

Diese Einordnung ist wichtig, denn Core AI liegt unterhalb der Abstraktionen, die die meisten Apps verwenden sollten. Apple beschreibt es als von Grund auf mit Apple Silicon im Blick entworfen: Ihre App kann damit die neuesten Modellarchitekturen und Inference-Techniken über CPU, GPU und Neural Engine hinweg nutzen, mit einer Swift-API, die gängige Aufgaben einfach macht und Ihnen bei Bedarf mehr Kontrolle über Modellspezialisierung, Caching und Inference-Leistung gibt.¹ Die These dieses Beitrags: Greifen Sie zu Core AI, wenn Sie ein Modell haben, das Sie mit expliziter Kontrolle darüber ausführen wollen, wo und wie es läuft – und bleiben Sie bei Core ML oder Foundation Models, wenn nicht. Das Framework belohnt einen konkreten Bedarf, keine Standardvorliebe.

TL;DR / Wichtigste Erkenntnisse

• Core AI trennt ein unspezialisiertes AIModelAsset (Struktur und Metadaten eines Modells günstig inspizieren) von einem spezialisierten AIModel (Inference auf einem Gerät ausführen), wobei AIModelCache die gerätespezifischen Artefakte vorhält und AssetError Fehler bei Asset-Operationen abbildet.²³⁶⁴
• Inference-Daten fließen durch NDArray, ein mehrdimensionales Array von Skalarwerten, beschrieben durch einen NDArrayDescriptor, der Form, Skalartyp und erwartetes Speicherlayout festlegt.⁵⁷
• Sie wählen die Zielhardware über ComputeUnitKind (CPU, GPU oder Neural Engine) per SpecializationOptions und planen asynchrone Arbeit auf einem ComputeStream ein.⁸⁹¹⁰
• Eine InferenceFunction besitzt die Gewichte und Puffer und führt die Inference aus; ein InferenceFunctionDescriptor lässt Sie zuvor ihre Input-, Output- und State-Signatur inspizieren. Die Funktion ist Sendable, Sie können sie also nebenläufig ausführen.¹⁴¹³
• Modelle werden aus einem .aimodel-Bundle auf der Festplatte geladen, und Core AI liefert neben dem Framework Werkzeuge zur Vorbereitung, Konvertierung und Fehlersuche. Greifen Sie zu Core AI, wenn Sie explizite Kontrolle über Spezialisierung und Scheduling brauchen; andernfalls bleiben Sie bei Core ML oder Foundation Models.²¹

Zwei Begriffe, die das gesamte Design tragen: Asset und Model

Das Erste, was Core AI Sie verinnerlichen lässt, ist, dass ein Modell auf der Festplatte und ein Modell, das Inference ausführt, verschiedene Objekte sind – und die Spezialisierung des einen zum anderen teuer ist. Das Framework gibt jedem einen eigenen Typ.

Ein AIModelAsset ist „an unspecialized source model asset.”² Sie erstellen es aus der URL eines .aimodel-Bundles auf der Festplatte und nutzen es, um ein Modell zu inspizieren, ohne die Spezialisierungskosten zu zahlen. Apple ist deutlich, warum diese Trennung existiert: Ein Model-Asset lässt Sie Modellinformationen abfragen, ohne die Spezialisierung durchzuführen – eine teure Operation. Aus einem Asset können Sie Funktionssignaturen, Input- und Output-Beschreibungen, Compute- und Storage-Typen sowie vom Autor bereitgestellte Metadaten auslesen. Was Sie nicht können, ist Inference ausführen; ein Asset dient ausschließlich der Inspektion.²

// Call shape is illustrative; confirm the exact initializer against Apple's docs.
let asset = try AIModelAsset(url: bundleURL)   // an .aimodel bundle on disk
// Inspect signatures, input/output descriptions, compute and storage types,
// and author-provided metadata — without specializing.

Das AIModel ist die andere Hälfte: „a specialized model for running inference on a device.”³ Ein AIModel repräsentiert ein spezialisiertes .aimodel-Asset, das für die Hardware des aktuellen Geräts optimiert ist, und Sie erstellen es, indem Sie das Asset von der Festplatte laden.³ Das Asset beantwortet Was ist dieses Modell?; das Modell beantwortet Führe es hier und jetzt aus. Die Kostenasymmetrie zwischen beiden ist der Grund, warum die API Sie zwingt zu benennen, welches Sie wollen. Hundert Kandidatenmodelle zu inspizieren, um eines auszuwählen, ist günstig, solange Sie nur Assets bauen; es wäre ruinös, wenn jede Inspektion eine Spezialisierung auslöste.

Die Spezialisierung erzeugt gerätespezifische Artefakte, und diese Artefakte haben ein Zuhause: AIModelCache, „a cache that stores the specialized model artifacts for inference.”⁶ Der Cache hält die optimierten, gerätespezifischen Artefakte vor, die ein Modell lädt, um seine Inference-Funktionen auszuführen, und Apple weist darauf hin, dass jeder Cache-Eintrag ein spezialisiertes Asset enthält, das aus einer bestimmten .aimodel oder .aimodelc und einer Spezialisierungskombination gebildet wird.⁶ Praktisch gelesen: Spezialisierung ist nichts, was Sie bei jedem Start wiederholen wollen. Der Cache ist die Art und Weise, wie Core AI den teuren Schritt einmal geschehen lässt und den günstigen Schritt (das Laden zwischengespeicherter Artefakte) danach.

Wenn bei Asset-Operationen etwas schiefgeht (ein fehlendes Bundle, eine fehlerhafte .aimodel, eine nicht lesbare Datei), meldet Core AI einen AssetError, „an error that occurs during model asset operations.”⁴ Behandeln Sie ihn so, wie Sie jede I/O-Grenze behandeln: Das Asset liegt auf der Festplatte, Festplattenoperationen schlagen fehl, und das Typsystem sagt Ihnen genau, wohin das catch gehört.

Tensoren: NDArray und sein Descriptor

Inference bewegt Zahlen hinein und Zahlen hinaus, und Core AIs Container für diese Zahlen ist NDArray, „a multidimensional array of scalar values used for model inference.”⁵ Wenn Sie mit NumPys ndarray, MLX-Arrays oder MLMultiArray gearbeitet haben, ist die Form der Idee vertraut: ein n-dimensionaler Block von Skalaren mit einem definierten Layout. Ein NDArray speichert seine Daten in einem Layout, das durch seine Form und die übrigen beschreibenden Eigenschaften definiert ist.⁵

Der Begleittyp ist NDArrayDescriptor, „a description of an array’s shape, scalar type, and memory layout expectations.”⁷ Ein Descriptor ist der Vertrag. Apples Formulierung ist direkt: Der Descriptor enthält die Erwartungen an einen Array-Wert, den Sie einer Inference-Funktion übergeben, und die meisten Erwartungen sind strikt. Gibt der Descriptor einen Skalartyp von .float32 an, muss das Array, das Sie bereitstellen, .float32 verwenden.⁷ Sie raten nicht Form und Typ, die eine Funktion erwartet; Sie fragen den Descriptor der Funktion und richten sich danach.

// Call shape is illustrative; confirm exact property/method names against Apple's docs.
let inputDescriptor = function.descriptor.inputs.first!   // an NDArrayDescriptor
// The descriptor fixes shape, scalar type, and layout; the array you build
// must satisfy those expectations (e.g. .float32 means .float32).

Die Designlehre hier spiegelt die Trennung von Asset und Model. Core AI stellt konsequent ein günstiges Beschreibungsobjekt vor ein teures Wertobjekt. Sie lesen den Descriptor, um den Vertrag zu erfahren, und allozieren dann das NDArray, das ihn erfüllt – statt zuerst zu allozieren und zur Inference-Zeit eine Unstimmigkeit zu entdecken. Speziell für Bildeingaben definiert Core AI zudem einen ImageDescriptor, „a description of an image’s dimensions and pixel format,” sodass die Pixeleingabe eines Vision-Modells dieselbe Descriptor-zuerst-Behandlung erhält.¹¹

Wählen, wo die Inference läuft

Apple Silicon hat drei Orte zum Rechnen: CPU, GPU und Neural Engine. Der Grund, warum Core AI existiert und nicht nur Core ML, ist, dass Core AI Sie sagen lässt, welchen davon das Framework anvisiert, statt ihn abzuleiten.

ComputeUnitKind ist „a type of hardware compute unit available for model inference.”⁸ Sie verwenden Compute-Unit-Kinds zusammen mit den Spezialisierungsoptionen, um zu steuern, welche Hardware das Framework bei der Spezialisierung eines Modells anvisiert; standardmäßig nutzt die Spezialisierung alle auf dem Gerät verfügbaren Compute-Units.⁸ Der Standard ist für die meiste Arbeit die richtige Antwort, und genau das ist der Punkt: Sie überschreiben ihn nur, wenn Sie einen Grund haben (ein latenzkritischer Pfad, den Sie auf die Neural Engine festnageln wollen, ein Debugging-Durchlauf, den Sie auf die CPU zwingen wollen, eine GPU-lastige Pipeline, die Sie mit anderer GPU-Arbeit koordinieren).

Diese Absicht übergeben Sie über SpecializationOptions, die Struktur, die die zur Spezialisierungszeit getroffenen Entscheidungen trägt.⁹ Die Spezialisierung ist der teure Schritt von zuvor, und in SpecializationOptions leben das Compute-Unit-Targeting und die übrigen Spezialisierungsentscheidungen. Da ein Cache-Eintrag über eine bestimmte Asset- und Spezialisierungskombination indiziert wird, ändert eine Änderung Ihrer Optionen, welches zwischengespeicherte Artefakt Sie zurückbekommen – was den Kreis zwischen Targeting und Caching schließt.⁶

Scheduling ist die andere Achse des „Wie es läuft”, und Core AI modelliert es als ComputeStream, „a stream of work to be run asynchronously.”¹⁰ Einen Compute-Stream stellen Sie bereit, um Arbeit auf den Stream zu kodieren, und Apple weist darauf hin, dass mehrere auf denselben Stream kodierte Inferences je nach gelesenen und geschriebenen Werten bei Bedarf serialisiert werden.¹⁰ Daraus folgen zwei Konsequenzen. Erstens ist ein Stream Ihr Ordnungsprimitiv: Kodieren Sie abhängige Inferences auf einen Stream, und Core AI ordnet sie nach Datenabhängigkeit. Zweitens ist Arbeit standardmäßig asynchron, sodass der Stream auch das Mittel ist, den aufrufenden Thread frei zu halten, während die Neural Engine oder GPU die Arbeit erledigt.

Inference-Funktionen: Das, was tatsächlich läuft

Eine geladene .aimodel ist nicht ein einzelnes aufrufbares Objekt. Modelle stellen benannte Funktionen bereit (einen Encoder, einen Decoder, einen Vision-Tower, einen Prefill- gegenüber einem Decode-Schritt), und Core AIs Ausführungseinheit ist die InferenceFunction: „a function that performs inference on input values and produces output values.”¹⁴

Bevor Sie eine aufrufen, inspizieren Sie sie. InferenceFunctionDescriptor ist „a description of an inference function’s signature,” und Sie verwenden einen Descriptor, um vor der Inference die Namen und Typen der Inputs, Outputs und States einer Funktion zu inspizieren.¹³ States sind das Detail, bei dem es sich innezuhalten lohnt: Eine Funktion mit State ist die Art, wie ein zustandsbehaftetes Modell (etwa ein KV-Cache in einer Transformer-Decode-Schleife) Informationen zwischen Aufrufen bewahrt, und der Descriptor sagt Ihnen, dass eine Funktion sie hat, bevor Sie versuchen, sie anzusteuern.

Die InferenceFunction selbst besitzt die Ressourcen, die die Inference braucht, einschließlich Modellgewichten und Zwischenpuffern. Sie laden eine Funktion aus einem Modell und rufen run(inputs:states:outputViews:) auf, um die Inference durchzuführen.¹⁴ Die Signatur von run wird in Apples eigener Erläuterung benannt, sodass die drei Dinge, die ein Aufruf braucht, explizit sind: die Input-Werte, die State-Werte und die Output-Views, die Sie geschrieben haben wollen.

// run(inputs:states:outputViews:) is named in Apple's docs; surrounding
// loading/value-construction shapes are illustrative — confirm against Apple's docs.
let function: InferenceFunction = /* load from an AIModel */
let outputs = try function.run(
    inputs: inputValues,        // InferenceValue per input
    states: stateValues,        // any stateful values the function declares
    outputViews: outputViews
)

Zwei Eigenschaften machen die Funktion unter Last angenehm. Sie ist Sendable, sodass Sie sie nebenläufig aus mehreren Tasks ausführen können, und Apple weist darauf hin, dass sie bei Bedarf automatisch zusätzliche Zwischenpuffer alloziert, um diese Nebenläufigkeit zu unterstützen.¹⁴ Sie serialisieren Aufrufe nicht hinter einem Lock, um gemeinsam genutzten Scratch-Speicher zu schützen; die Funktion verwaltet ihre eigenen Puffer pro nebenläufigem Aufrufer. Das ist ein bedeutender Unterschied zu APIs, bei denen ein einzelnes Inference-Handle faktisch single-threaded ist.

Die Werte, die durch run fließen, sind InferenceValue-Instanzen, „a value that an inference function accepts as input or produces as output.”¹² Ein InferenceValue umhüllt entweder ein NDArray oder einen Pixelpuffer, und Sie rufen ein Ergebnis nach der Inference über seine value-Eigenschaft ab.¹² Die Hülle ist es, die eine einzige run-Signatur sowohl Tensor- als auch Bildeingaben tragen lässt, ohne separate Overloads: Ein Textmodell übergibt NDArray-gestützte Werte, ein Vision-Modell übergibt pixelpuffer-gestützte, und die Funktion liest den Descriptor, um zu wissen, welche sie erwartet.

Wann man zu Core AI greift

Der schwierigste Teil von Core AI ist nicht die API. Es ist das Wissen, dass Sie überhaupt hier sein sollten und nicht eine Schicht darüber. Der ehrliche Entscheidungsbaum:

• Foundation Models, wenn Apples Systemmodell die Aufgabe erledigt. Zusammenfassen, klassifizieren, extrahieren, umschreiben, strukturierte Ausgabe: Das gehört zu Foundation Models, das Sie keine Gewichte, kein Speicherbudget und keinen Spezialisierungsschritt kostet. Wenn Ihre Funktion passt, hören Sie dort auf. Zu Core AI hinabzusteigen, um nachzubilden, was das Systemmodell bereits tut, ist verschwendete Arbeit.
• Core ML, wenn Sie ein festes, konvertiertes Modell haben und wollen, dass der Konverter die Hardware- und Optimierungsentscheidungen für Sie trifft. Core ML visiert die Neural Engine mit straffer Leistungs- und Latenzkontrolle für ein abgeschlossenes Produktionsmodell an und verlangt von Ihnen nichts zu Spezialisierung oder Scheduling. Wenn Sie nicht über Compute-Unit-Targeting oder Compute-Streams nachdenken wollen, ist das das Signal, bei Core ML zu bleiben.
• MLX, wenn Sie ein Array-Framework auf Forschungsniveau wollen, das Sie einbetten und iterieren: Ihre eigene Trainingsschleife, quantisierte Open-Weight-Modelle, LoRA-Fine-Tunes, schnelles Experimentieren. MLX ist eine Bibliothek, die Sie mit Gewichten ausliefern, keine systemseitige Oberfläche zur Modellausführung. Es punktet mit Flexibilität und Iterationsgeschwindigkeit.
• Core AI, wenn Sie ein Modell auszuführen haben und die expliziten Hebel des Frameworks wollen: ein AIModelAsset, das Sie inspizieren, bevor Sie sich festlegen, SpecializationOptions, die Compute-Units festnageln, ein AIModelCache, den Sie verwalten, ein ComputeStream, auf den Sie planen, und InferenceFunctions, die Sie nebenläufig aufrufen. Sie greifen hierher, wenn die Standardwerte der höheren Schichten das sind, was Ihnen im Weg steht, und Sie benennen können, welchen Standard Sie überschreiben müssen.

Der rote Faden durch den gesamten Stack: Jede Schicht weiter unten gibt einen Standard auf und tauscht ihn gegen einen Hebel ein. Foundation Models reicht Ihnen alles und verlangt nichts. Core AI reicht Ihnen die Hebel und verlangt von Ihnen zu wissen, welchen Sie ziehen müssen. Wenn Sie die Kontrolle über Spezialisierung, Caching oder Scheduling, die Sie brauchen, nicht benennen können, brauchen Sie Core AI noch nicht.

Eine Aussage aus einem WWDC-2026-Lab schärft, wo für neue Arbeit die Grenze zwischen Core AI und Core ML verläuft. Paraphrasiert aus einer lokal transkribierten Aufzeichnung des WWDC 2026 Coding Intelligence, Machine Learning & AI Group Lab sagte ein Core-AI-Ingenieur auf dem Panel, dass Apple alle, die mit neuronalen Netzen arbeiten, bittet, künftig auf Core AI umzusteigen, wobei Core ML bestehen bleibt, sich aber auf klassisches Machine Learning wie Entscheidungsbäume konzentriert, und alles Neue zu Core AI wandert.¹⁶ Lesen Sie es als ein Richtungssignal der Leute, die das Framework bauen, statt als dokumentierte Richtlinie: Wenn Sie für ein neues Projekt zu einem neuronalen Netz greifen, hat das Lab Core AI als die Oberfläche eingeordnet, auf der man aufbauen sollte.

Wie ein Modell zu Core AI gelangt

Das Framework ist die Laufzeithälfte eines größeren Workflows. Apple weist darauf hin, dass Core AI neben dem Framework zusätzliche Werkzeuge zur Modellvorbereitung, Integration und Fehlersuche enthält: Sie bereiten Ihre Modelle für Apple Silicon vor, konvertieren sie in das .aimodel-Format und nutzen eine Begleit-App, die Visualisierung und numerisches Debugging unterstützt.¹ Die Beschreibung dieser Werkzeugnamen im Fact-Sheet ist abgeschnitten, bestätigen Sie also die genauen Werkzeugnamen und ihren Aufruf anhand von Apples Core-AI-Dokumentation, statt einer Rekonstruktion zu vertrauen.¹ Verifiziert ist die Form der Pipeline: Ein Quellmodell wird vorbereitet, in .aimodel konvertiert, als AIModelAsset zur Inspektion geladen, zu einem AIModel spezialisiert und über seine InferenceFunctions ausgeführt, wobei AIModelCache die spezialisierten Artefakte vorhält, damit der teure Schritt einmal geschieht.¹²³⁶¹⁴

FAQ

Was ist Apples Core-AI-Framework?

Core AI ist das Low-Level-Framework von iOS 27 zur Ausführung von KI-Modellen auf Apple Silicon, von Apple zusammengefasst als „Run AI models in your app on Apple silicon.”¹ Es führt Modell-Inference über CPU, GPU und Neural Engine hinweg aus, mittels einer Swift-API, die gängige Aufgaben einfach macht und Ihnen bei Bedarf Kontrolle über Modellspezialisierung, Caching und Inference-Leistung gibt.¹ Es liegt unterhalb von Foundation Models und Core ML als Oberfläche zur Modellausführung.

Was ist der Unterschied zwischen AIModelAsset und AIModel?

AIModelAsset ist ein unspezialisiertes Quell-Asset, das Sie aus der URL eines .aimodel-Bundles auf der Festplatte erstellen; Sie nutzen es, um die Funktionssignaturen, Input- und Output-Beschreibungen, Compute- und Storage-Typen und Metadaten eines Modells zu inspizieren, ohne zu spezialisieren – weil die Spezialisierung teuer ist und ein Asset keine Inference ausführen kann.² AIModel ist das spezialisierte, für die Hardware des aktuellen Geräts optimierte Modell, das tatsächlich Inference ausführt; Sie erstellen es, indem Sie das Asset von der Festplatte laden.³ Die Trennung erlaubt es Ihnen, günstig zu inspizieren und nur dann zu spezialisieren, wenn Sie sich festlegen.

Wie wählt Core AI zwischen CPU, GPU und Neural Engine?

Sie steuern das Hardware-Targeting mit ComputeUnitKind über SpecializationOptions. Ein Compute-Unit-Kind benennt einen Typ von Hardware-Compute-Unit, der für Inference verfügbar ist, und Sie verwenden ihn, um zu steuern, welche Hardware das Framework bei der Spezialisierung eines Modells anvisiert; standardmäßig nutzt die Spezialisierung alle auf dem Gerät verfügbaren Compute-Units.⁸⁹ Sie überschreiben den Standard nur, wenn Sie einen konkreten Grund haben, etwa einen latenzkritischen Pfad auf eine Compute-Unit festzunageln.

Was ist eine InferenceFunction und wie führe ich sie aus?

Eine InferenceFunction führt Inference auf Input-Werten aus und produziert Output-Werte, wobei sie die Modellgewichte und Zwischenpuffer besitzt.¹⁴ Sie inspizieren ihre Signatur zuerst über einen InferenceFunctionDescriptor, der die Namen und Typen der Inputs, Outputs und States der Funktion beschreibt, laden dann die Funktion aus einem AIModel und rufen run(inputs:states:outputViews:) auf.¹³¹⁴ Die Funktion ist Sendable und alloziert automatisch Zwischenpuffer, um Nebenläufigkeit zu unterstützen, sodass mehrere Tasks sie gleichzeitig ausführen können.¹⁴

Sollte ich Core AI statt Core ML oder Foundation Models verwenden?

Verwenden Sie Foundation Models, wenn das Systemmodell die Aufgabe erledigt, und Core ML, wenn Sie ein festes, konvertiertes Modell haben und wollen, dass der Konverter die Hardware- und Optimierungsentscheidungen für Sie trifft. Greifen Sie zu Core AI, wenn Sie explizite Kontrolle über Spezialisierung (SpecializationOptions, ComputeUnitKind), Caching (AIModelCache) und Scheduling (ComputeStream) wollen, die die höheren Schichten für Sie übernehmen.⁸⁹⁶¹⁰ Wenn Sie die benötigte Kontrolle nicht benennen können, bleiben Sie eine Schicht darüber.

Der vollständige Apple-Ecosystem-Cluster: MLX auf Apple Silicon für das Array-Framework, das Sie einbetten, wenn Sie Ihr eigenes Modell und Ihre eigene Trainingsschleife wollen; TBDR und Unified Memory von Apple Silicon für das Hardware-Substrat, das die gemeinsame Nutzung von CPU/GPU/Neural Engine ermöglicht; Core-ML-On-Device-Inference für die Festmodell-Schicht oberhalb von Core AI; und Foundation Models für Apples versiegeltes System-LLM an der Spitze des Stacks. Der Hub liegt bei der Apple Ecosystem Series. Für breiteren Kontext zu iOS mit KI-Agenten siehe den Leitfaden zur iOS-Agent-Entwicklung.

Referenzen