Core AI: Modelle auf Apple Silicon ausführen

In Apples On-Device-KI-Stack fehlte bisher eine Sprosse. Foundation Models gibt Ihnen das System-LLM, versiegelt und kostenlos. Core ML führt ein fest konvertiertes Modell aus, wobei der Konverter die Hardware-Entscheidungen für Sie trifft. MLX liefert ein Array-Framework zum Einbetten und ein Modell, das Sie selbst auswählen. iOS 27 ergänzt die Sprosse unterhalb aller drei: Core AI, ein Framework, dessen einzeilige Kurzfassung lautet „Run AI models in your app on Apple silicon.“¹ Es ist die Ebene der Modellausführung, die Stelle, zu der Sie greifen, wenn Sie Spezialisierung, Caching und Inferenz-Scheduling selbst steuern wollen, statt die Vorgaben einer höheren Schicht hinzunehmen.

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

Diese Einordnung ist wichtig, weil Core AI unter den Abstraktionen sitzt, die die meisten Apps verwenden sollten. Apple beschreibt es als von Grund auf für Apple silicon entworfen: Ihre App kann damit die neuesten Modellarchitekturen und Inferenztechniken über CPU, GPU und Neural Engine hinweg nutzen, mit einer Swift-API, die gängige Aufgaben einfach hält und Ihnen bei Bedarf mehr Kontrolle über Modellspezialisierung, Caching und Inferenzleistung 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 das nicht zutrifft. 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 (Inferenz auf einem Gerät ausführen); AIModelCache hält dabei die gerätespezifischen Artefakte, AssetError steht für Fehler bei Asset-Operationen.²³⁶⁴
• Inferenzdaten fließen durch NDArray, ein mehrdimensionales Array aus Skalarwerten, beschrieben durch einen NDArrayDescriptor, der Form, Skalartyp und Erwartungen an das Speicherlayout festlegt.⁵⁷
• Die Hardware sprechen Sie mit ComputeUnitKind (CPU, GPU oder Neural Engine) über SpecializationOptions an, und asynchrone Arbeit planen Sie auf einem ComputeStream ein.⁸⁹¹⁰
• Eine InferenceFunction besitzt die Gewichte und Puffer und führt die Inferenz aus; ein InferenceFunctionDescriptor lässt Sie zuvor ihre Signatur aus Eingaben, Ausgaben und Zuständen inspizieren. Die Funktion ist Sendable, Sie können sie also nebenläufig ausführen.¹⁴¹³
• Modelle werden aus einem .aimodel-Bundle auf der Festplatte geladen. Die Toolchain rund um das Framework ist inzwischen dokumentiert: Das Python-Paket coreai-torch konvertiert PyTorch-Modelle, die CLI coreai-build kompiliert .aimodel vorab zu architekturspezifischen .aimodelc-Assets, und die App Core AI Debugger sowie eine Debug-Anzeige in Xcode und eine Instruments-Vorlage decken Inspektion und Profiling ab.¹⁷ 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 ganze Design tragen: Asset und Modell

Das Erste, was Core AI Ihnen abverlangt, ist die Einsicht, dass ein Modell auf der Festplatte und ein Modell, das Inferenz ausführt, verschiedene Objekte sind und dass es teuer ist, das eine in das andere zu spezialisieren. Das Framework gibt jedem davon einen eigenen Typ.

Ein AIModelAsset ist „an unspecialized source model asset.“² Sie erzeugen es aus der URL eines .aimodel-Bundles auf der Festplatte und nutzen es, um ein Modell zu inspizieren, ohne die Kosten der Spezialisierung zu zahlen. Apple sagt deutlich, warum es diese Trennung gibt: Ein Modell-Asset erlaubt Ihnen, Modellinformationen abzufragen, ohne die Spezialisierung durchzuführen, die eine teure Operation ist. Aus einem Asset lesen Sie Funktionssignaturen, Eingabe- und Ausgabebeschreibungen, Rechen- und Speichertypen sowie vom Autor bereitgestellte Metadaten. Was Sie nicht können, ist Inferenz ausführen; ein Asset dient allein 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; Sie erzeugen eines, indem Sie das Asset von der Festplatte laden.³ Das Asset beantwortet die Frage 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 von beiden Sie meinen. Hundert Kandidatenmodelle zu inspizieren, um eines auszuwählen, ist günstig, solange Sie nur Assets bauen; es wäre ruinös, wenn jede Inspektion spezialisieren würde.

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, die ein Modell lädt, um seine Inferenzfunktionen auszuführen, und Apple merkt an, dass jeder Cache-Eintrag ein spezialisiertes Asset enthält, das aus einem bestimmten .aimodel oder .aimodelc und einer Spezialisierungskombination entsteht.⁶ Praktisch gelesen heißt das: Spezialisierung ist nichts, was Sie bei jedem Start wiederholen wollen. Der Cache ist der Weg, auf dem Core AI den teuren Schritt einmal geschehen lässt und den günstigen Schritt – das Laden zwischengespeicherter Artefakte – danach immer wieder.

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

Tensoren: NDArray und sein Deskriptor

Inferenz bewegt Zahlen hinein und Zahlen heraus, und Core AIs Container für diese Zahlen ist NDArray, „a multidimensional array of scalar values used for model inference.“⁵ Wenn Sie schon mit NumPy-ndarray, MLX-Arrays oder MLMultiArray gearbeitet haben, ist Ihnen die Form der Idee vertraut: ein n-dimensionaler Block aus Skalaren mit definiertem Layout. Ein NDArray speichert seine Daten in einem Layout, das durch seine Form und seine übrigen beschreibenden Eigenschaften bestimmt wird.⁵

Der Begleittyp ist NDArrayDescriptor, „a description of an array’s shape, scalar type, and memory layout expectations.“⁷ Ein Deskriptor ist der Vertrag. Apples Formulierung ist direkt: Der Deskriptor enthält die Erwartungen an einen Array-Wert, den Sie einer Inferenzfunktion übergeben, und die meisten Erwartungen sind strikt. Gibt der Deskriptor den Skalartyp .float32 vor, muss das übergebene Array .float32 verwenden.⁷ Sie raten nicht, welche Form und welchen Typ eine Funktion erwartet; Sie fragen den Deskriptor 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 Designlektion spiegelt hier die Trennung von Asset und Modell. Core AI stellt konsequent ein günstiges Beschreibungsobjekt vor ein teures Wertobjekt. Sie lesen den Deskriptor, um den Vertrag zu erfahren, und allokieren dann das NDArray, das ihn erfüllt, statt zuerst zu allokieren und die Abweichung erst zur Inferenzzeit zu entdecken. Speziell für Bildeingaben definiert Core AI zusätzlich einen ImageDescriptor, „a description of an image’s dimensions and pixel format“, sodass die Pixeleingabe eines Vision-Modells dieselbe deskriptorbasierte Behandlung erfährt.¹¹

Wählen, wo die Inferenz läuft

Apple silicon hat drei Orte zum Rechnen: CPU, GPU und Neural Engine. Der Grund, warum es Core AI gibt und nicht nur Core ML, ist, dass Core AI Sie sagen lässt, welchen davon das Framework anspricht, statt ihn selbst zu erschließen.

ComputeUnitKind ist „a type of hardware compute unit available for model inference.“⁸ Sie verwenden Compute-Unit-Arten zusammen mit den Spezialisierungsoptionen, um zu steuern, welche Hardware das Framework beim Spezialisieren eines Modells anspricht; standardmäßig nutzt die Spezialisierung alle auf dem Gerät verfügbaren Recheneinheiten.⁸ 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 Debug-Durchlauf, den Sie auf die CPU zwingen, eine GPU-lastige Pipeline, die Sie mit anderer GPU-Arbeit koordinieren).

Diese Absicht übergeben Sie über SpecializationOptions, die Struktur, die die zum Zeitpunkt der Spezialisierung getroffenen Entscheidungen trägt.⁹ Die Spezialisierung ist der teure Schritt von vorhin, und in SpecializationOptions wohnen die Compute-Unit-Auswahl und die übrigen Spezialisierungsentscheidungen. Weil ein Cache-Eintrag über ein bestimmtes Asset und eine bestimmte Spezialisierungskombination adressiert wird, ändert sich mit Ihren Optionen auch, welches zwischengespeicherte Artefakt Sie zurückbekommen – damit schließt sich der Kreis zwischen Auswahl und Caching.⁶

Scheduling ist die andere Achse des „Wie es läuft“, und Core AI modelliert sie als ComputeStream, „a stream of work to be run asynchronously.“¹⁰ Einen Compute-Stream übergeben Sie, um Arbeit auf den Strom zu kodieren, und Apple merkt an, dass mehrere auf denselben Strom kodierte Inferenzen bei Bedarf anhand der gelesenen und geschriebenen Werte serialisiert werden.¹⁰ Daraus folgen zwei Dinge. Erstens ist ein Strom Ihr Ordnungsprimitiv: Kodieren Sie voneinander abhängige Inferenzen auf einen Strom, dann reiht Core AI sie nach Datenabhängigkeit. Zweitens ist die Arbeit standardmäßig asynchron, der Strom ist also auch der Weg, den aufrufenden Thread frei zu halten, während Neural Engine oder GPU rechnen.

Inferenzfunktionen: das, was tatsächlich läuft

Ein geladenes .aimodel ist kein einzelnes Aufrufbares. 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 nutzen einen Deskriptor, um Namen und Typen der Eingaben, Ausgaben und Zustände einer Funktion zu inspizieren, bevor Sie Inferenz ausführen.¹³ Die Zustände sind das Detail, bei dem innezuhalten sich lohnt: Eine Funktion mit Zustand ist der Weg, auf dem ein zustandsbehaftetes Modell – etwa ein KV-Cache in der Decode-Schleife eines Transformers – Informationen zwischen Aufrufen behält, und der Deskriptor sagt Ihnen, dass eine Funktion Zustände hat, bevor Sie versuchen, sie zu steuern.

Die InferenceFunction selbst besitzt die Ressourcen, die die Inferenz braucht, einschließlich Modellgewichten und Zwischenpuffern. Sie laden eine Funktion aus einem Modell und rufen run(inputs:states:outputViews:) auf, um Inferenz auszuführen.¹⁴ Die Signatur von run wird in Apples eigener Erläuterung benannt, damit sind die drei Dinge, die ein Aufruf braucht, explizit: die Eingabewerte, die Zustandswerte und die Ausgabe-Views, die geschrieben werden sollen.

// 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, Sie können sie also nebenläufig aus mehreren Tasks ausführen, und Apple merkt an, dass sie bei Bedarf automatisch zusätzliche Zwischenpuffer allokiert, um diese Nebenläufigkeit zu unterstützen.¹⁴ Sie serialisieren Aufrufe nicht hinter einem Lock, um gemeinsamen Scratch-Speicher zu schützen; die Funktion verwaltet ihre eigenen Puffer je nebenläufigem Aufrufer. Das ist ein bedeutsamer Unterschied zu APIs, bei denen ein einzelnes Inferenz-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 umschließt entweder ein NDArray oder einen Pixelpuffer, und ein Ergebnis holen Sie nach der Inferenz über dessen value-Eigenschaft ab.¹² Der Wrapper ist das, was einer einzigen run-Signatur erlaubt, Tensoreingaben und Bildeingaben ohne separate Überladungen zu tragen: Ein Textmodell übergibt NDArray-gestützte Werte, ein Vision-Modell pixelpuffergestützte, und die Funktion liest den Deskriptor, um zu wissen, was sie erwartet.

Wann Sie zu Core AI greifen sollten

Das Schwerste an Core AI ist nicht die API. Es ist die Einsicht, dass Sie überhaupt hier sein sollten statt eine Schicht höher. Der ehrliche Entscheidungsbaum:

• Foundation Models, wenn Apples Systemmodell die Aufgabe erledigt. Zusammenfassen, klassifizieren, extrahieren, umschreiben, strukturierte Ausgabe: Das gehört zum Foundation-Models-Framework, das Sie keine Gewichte, kein Speicherbudget und keinen Spezialisierungsschritt kostet. Wenn Ihr Feature dazu passt, hören Sie dort auf. Auf Core AI hinabzusteigen, um nachzubauen, was das Systemmodell bereits kann, 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 spricht die Neural Engine mit engem Energie- und Latenzbudget für ein abgeschlossenes Produktionsmodell an und verlangt Ihnen nichts zu Spezialisierung oder Scheduling ab. Wenn Sie über Compute-Unit-Auswahl oder Compute-Streams nicht nachdenken wollen, ist das das Signal, bei Core ML zu bleiben.
• MLX, wenn Sie ein forschungstaugliches Array-Framework wollen, das Sie einbetten und an dem Sie iterieren: Ihre eigene Trainingsschleife, quantisierte Open-Weight-Modelle, LoRA-Feinabstimmungen, schnelles Experimentieren. MLX ist eine Bibliothek, die Sie mit Gewichten ausliefern, keine System-Ebene für Modellausführung. Es gewinnt bei Flexibilität und Iterationsgeschwindigkeit.
• Core AI, wenn Sie ein Modell auszuführen haben und die expliziten Griffe des Frameworks wollen: ein AIModelAsset, das Sie inspizieren, bevor Sie sich festlegen, SpecializationOptions, die Recheneinheiten festnageln, einen AIModelCache, den Sie verwalten, einen ComputeStream, auf den Sie einplanen, und InferenceFunctions, die Sie nebenläufig aufrufen. Hierher greifen Sie, wenn die Vorgaben der höheren Schichten Ihnen im Weg stehen und Sie benennen können, welche Vorgabe Sie überschreiben müssen.

Der rote Faden über den gesamten Stack: Jede Schicht tiefer tauscht eine Vorgabe gegen einen Griff. Foundation Models reicht Ihnen alles und verlangt nichts. Core AI reicht Ihnen die Hebel und verlangt, dass Sie wissen, an welchem zu ziehen ist. 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 Lab der WWDC 2026 schärft, wo die Linie zwischen Core AI und Core ML für neue Arbeit verläuft. Sinngemäß wiedergegeben aus einer lokal transkribierten Aufzeichnung des WWDC 2026 Coding Intelligence, Machine Learning & AI Group Lab sagte ein Core-AI-Ingenieur im Panel, Apple bitte alle, die mit neuronalen Netzen arbeiten, künftig auf Core AI zu wechseln; Core ML bleibe bestehen, konzentriere sich aber auf klassisches maschinelles Lernen wie Entscheidungsbäume, und alles Neue gehe zu Core AI.¹⁶ Lesen Sie das als Richtungssignal der Leute, die das Framework bauen, nicht als dokumentierte Richtlinie: Wenn Sie in einem neuen Projekt zu einem neuronalen Netz greifen, hat das Lab Core AI als die Ebene gerahmt, auf der man aufbauen sollte.

Wie ein Modell zu Core AI gelangt

Das Framework ist die Laufzeithälfte eines größeren Arbeitsablaufs, und seit den Juni-Betas hat Apple die Werkzeughälfte vollständig veröffentlicht.¹⁷ Die Pipeline läuft so.

Konvertieren. Sie beginnen mit einer .aimodel-Datei, entweder aus einem Quellmodell mit dem Paket coreai-torch konvertiert (Apples Core AI PyTorch Extensions für Python) oder bereits im Format vorbereitet.¹⁷ Das .aimodel wandert wie jede andere Ressource in Ihr Xcode-Target, erscheint in der Build-Phase Compile Sources und bekommt in Xcode einen Modell-Viewer, der Parameter, Speichergröße, Metadaten und den Operationsgraphen anzeigt. Eine Abhängigkeit im Build-System sollten Sie vorab kennen: Die Core-AI-Modellintegration benötigt die Metal Toolchain, die Xcode nicht standardmäßig installiert; ohne sie schlagen Builds mit .aimodel-Dateien mit einem Fehler über einen fehlenden Metal-Compiler fehl.¹⁷

Optional vorab kompilieren. Die Spezialisierung geschieht automatisch, wenn Sie ein AIModel erzeugen, und bei großen Modellen sind diese Kosten beim ersten Laden real. Das Kommandozeilenwerkzeug coreai-build verlagert den teuersten Teil, die Modellkompilierung, auf Ihre Build-Maschine: Es wandelt .aimodel in .aimodelc-Assets um, eines je Gerätearchitektur (das Kompilieren von MyModel.aimodel erzeugt MyModel.<arch>.aimodelc), und zur Laufzeit wählt die App das zum aktuellen Gerät passende Asset, sodass Core AI den Kompilierschritt überspringt.¹⁷ Die Vorab-Kompilierung zielt auf die Hardware-Untergrenze von Apple Intelligence: iPhone oder iPad mit A17 Pro oder neuer, Macs mit M1 oder neuer und Apple Vision Pro mit M2.¹⁷

Debuggen und profilen. Drei Werkzeuge decken die Beobachtbarkeit ab: der Core AI Debugger, eine eigenständige macOS-App, um den Operationsgraphen eines Modells zu inspizieren, es gegen ein Gerät laufen zu lassen und Ausgaben mit einem Referenzlauf zu vergleichen; eine Core-AI-Debug-Anzeige in Xcode, die Laden, Spezialisierung und Inferenzaktivität während einer Debug-Sitzung live überwacht; und ein Core-AI-Instrument, eine Instruments-Vorlage, die die Ausführungszeiten über CPU, GPU und Neural Engine hinweg profiliert.¹⁷

Die Laufzeitform von weiter oben fügt sich unverändert in diesen Ablauf ein: Das vorbereitete Modell wird als AIModelAsset zur Inspektion geladen, zu einem AIModel spezialisiert und über seine InferenceFunctions ausgeführt, während AIModelCache die spezialisierten Artefakte behält, damit der teure Schritt nur einmal geschieht.¹²³⁶¹⁴

Häufige Fragen

Was ist Apples Core-AI-Framework?

Core AI ist das systemnahe Framework von iOS 27 zum Ausführen von KI-Modellen auf Apple silicon, von Apple zusammengefasst als „Run AI models in your app on Apple silicon.“¹ Es führt Modellinferenz über CPU, GPU und Neural Engine hinweg aus, über eine Swift-API, die gängige Aufgaben einfach hält und Ihnen bei Bedarf Kontrolle über Modellspezialisierung, Caching und Inferenzleistung gibt.¹ Es sitzt unterhalb von Foundation Models und Core ML als Ebene der 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 erzeugen; Sie nutzen es, um Funktionssignaturen, Eingabe- und Ausgabebeschreibungen, Rechen- und Speichertypen sowie Metadaten eines Modells zu inspizieren, ohne zu spezialisieren, denn die Spezialisierung ist teuer, und ein Asset kann keine Inferenz ausführen.² AIModel ist das spezialisierte, für die Hardware des aktuellen Geräts optimierte Modell, das die Inferenz tatsächlich ausführt; Sie erzeugen eines, indem Sie das Asset von der Festplatte laden.³ Die Trennung erlaubt Ihnen, günstig zu inspizieren und erst dann zu spezialisieren, wenn Sie sich festlegen.

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

Die Hardware-Auswahl steuern Sie mit ComputeUnitKind über SpecializationOptions. Eine Compute-Unit-Art benennt einen Typ von Hardware-Recheneinheit, der für die Inferenz verfügbar ist, und Sie nutzen sie, um zu steuern, welche Hardware das Framework beim Spezialisieren eines Modells anspricht; standardmäßig nutzt die Spezialisierung alle auf dem Gerät verfügbaren Recheneinheiten.⁸⁹ Den Standard überschreiben Sie nur, wenn Sie einen konkreten Grund haben, etwa um einen latenzkritischen Pfad auf eine Recheneinheit festzunageln.

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

Eine InferenceFunction führt Inferenz auf Eingabewerten aus und erzeugt Ausgabewerte; sie besitzt dabei die Modellgewichte und die Zwischenpuffer.¹⁴ Ihre Signatur inspizieren Sie zuerst über einen InferenceFunctionDescriptor, der Namen und Typen der Eingaben, Ausgaben und Zustände der Funktion beschreibt, dann laden Sie die Funktion aus einem AIModel und rufen run(inputs:states:outputViews:) auf.¹³¹⁴ Die Funktion ist Sendable und allokiert Zwischenpuffer automatisch, 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. Zu Core AI greifen Sie, wenn Sie explizite Kontrolle über Spezialisierung (SpecializationOptions, ComputeUnitKind), Caching (AIModelCache) und Scheduling (ComputeStream) wollen, die die höheren Schichten für Sie erledigen.⁸⁹⁶¹⁰ Wenn Sie die Kontrolle, die Sie brauchen, nicht benennen können, bleiben Sie eine Schicht höher.

Der vollständige Cluster zum Apple-Ökosystem: 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 und Neural Engine überhaupt möglich macht; Core ML für Inferenz auf dem Gerät für die Schicht der festen Modelle über Core AI; und Foundation Models für Apples versiegeltes System-LLM an der Spitze des Stacks. Der Knotenpunkt ist die Serie zum Apple-Ökosystem. Für den breiteren Kontext zu iOS mit KI-Agenten siehe den Leitfaden zur iOS-Agentenentwicklung.

Referenzen