Core AI: uruchamianie modeli na Apple Silicon

W stosie sztucznej inteligencji Apple działającej na urządzeniu brakowało jednego szczebla. Foundation Models daje systemowy model LLM, zapieczętowany i bezpłatny. Core ML uruchamia stały, przekonwertowany model, a decyzje sprzętowe podejmuje za użytkownika konwerter. MLX dostarcza framework tablicowy, który wbudowuje się we własną aplikację, oraz model wybierany samodzielnie. iOS 27 dokłada szczebel położony poniżej całej trójki: Core AI, framework, którego jednozdaniowy opis brzmi „Run AI models in your app on Apple silicon”.¹ To warstwa wykonywania modeli, miejsce, po które sięga się wtedy, gdy specjalizacją, buforowaniem i planowaniem inferencji chce się sterować samodzielnie, zamiast przyjmować ustawienia domyślne wyższej warstwy.

W sesji 324 Apple przedstawia Core AI jako ten sam framework inferencji, który napędza Apple Intelligence na urządzeniu, teraz udostępniony inteligencji własnej aplikacji.¹⁵

To umiejscowienie ma znaczenie, ponieważ Core AI leży poniżej abstrakcji, z których powinna korzystać większość aplikacji. Apple opisuje go jako zaprojektowany z myślą o Apple silicon: pozwala aplikacji korzystać z najnowszych architektur modeli i technik inferencji na CPU, GPU i Neural Engine, przy użyciu API języka Swift, które upraszcza typowe zadania, a w razie potrzeby daje większą kontrolę nad specjalizacją modelu, buforowaniem i wydajnością inferencji.¹ Teza tego artykułu: po Core AI warto sięgnąć wtedy, gdy jest model do uruchomienia i potrzebna jest jawna kontrola nad tym, gdzie i jak się wykonuje; w przeciwnym razie lepiej pozostać przy Core ML lub Foundation Models. Ten framework nagradza konkretną potrzebę, a nie domyślne upodobanie.

TL;DR / najważniejsze wnioski

• Core AI oddziela niewyspecjalizowany AIModelAsset (tanie badanie struktury i metadanych modelu) od wyspecjalizowanego AIModel (uruchamianie inferencji na urządzeniu); AIModelCache przechowuje artefakty właściwe dla urządzenia, a AssetError sygnalizuje niepowodzenia operacji na assetach.²³⁶⁴
• Dane inferencji przepływają przez NDArray, wielowymiarową tablicę wartości skalarnych, opisaną przez NDArrayDescriptor, który ustala kształt, typ skalarny i oczekiwania co do układu pamięci.⁵⁷
• Sprzęt wskazuje się za pomocą ComputeUnitKind (CPU, GPU lub Neural Engine) poprzez SpecializationOptions, a pracę asynchroniczną planuje się na ComputeStream.⁸⁹¹⁰
• InferenceFunction jest właścicielem wag i buforów oraz wykonuje inferencję; InferenceFunctionDescriptor pozwala wcześniej zbadać jej sygnaturę wejść, wyjść i stanów. Funkcja jest Sendable, można ją więc wykonywać współbieżnie.¹⁴¹³
• Modele ładuje się z pakietu .aimodel na dysku. Narzędzia wokół frameworka są już udokumentowane: pakiet Pythona coreai-torch konwertuje modele PyTorch, narzędzie CLI coreai-build kompiluje .aimodel z wyprzedzeniem do assetów .aimodelc dla poszczególnych architektur, a aplikacja Core AI Debugger wraz ze wskaźnikiem debugowania w Xcode i szablonem Instruments obejmuje inspekcję i profilowanie.¹⁷ Po Core AI warto sięgnąć wtedy, gdy potrzebna jest jawna kontrola nad specjalizacją i planowaniem; w przeciwnym razie lepiej pozostać przy Core ML lub Foundation Models.²¹

Dwa słowa, na których opiera się cały projekt: asset i model

Pierwszą rzeczą, którą Core AI każe sobie przyswoić, jest to, że model na dysku i model wykonujący inferencję to różne obiekty, a wyspecjalizowanie jednego w drugi jest kosztowne. Framework nadaje każdemu z nich osobny typ.

AIModelAsset to „an unspecialized source model asset”.² Tworzy się go z adresu URL pakietu .aimodel na dysku i służy do badania modelu bez ponoszenia kosztu specjalizacji. Apple wprost tłumaczy, po co ten podział istnieje: asset modelu pozwala odpytać informacje o modelu bez przeprowadzania specjalizacji, która jest operacją kosztowną. Z assetu można odczytać sygnatury funkcji, opisy wejść i wyjść, typy obliczeniowe i typy przechowywania oraz metadane dostarczone przez autora. Czego zrobić nie można, to uruchomić inferencji; asset służy wyłącznie do inspekcji.²

// 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.

AIModel to druga połowa: „a specialized model for running inference on a device”.³ AIModel reprezentuje wyspecjalizowany asset .aimodel, zoptymalizowany pod sprzęt bieżącego urządzenia, a tworzy się go, ładując asset z dysku.³ Asset odpowiada na pytanie czym jest ten model?, model odpowiada uruchom go tutaj i teraz. Asymetria kosztów między nimi jest powodem, dla którego API zmusza do nazwania, o który z nich chodzi. Zbadanie stu modeli kandydujących w celu wybrania jednego jest tanie, dopóki buduje się wyłącznie assety; byłoby rujnujące, gdyby każda inspekcja wiązała się ze specjalizacją.

Specjalizacja wytwarza artefakty właściwe dla urządzenia, a te artefakty mają swoje miejsce: AIModelCache, „a cache that stores the specialized model artifacts for inference”.⁶ Pamięć podręczna przechowuje zoptymalizowane, właściwe dla urządzenia artefakty, które model ładuje, aby wykonać swoje funkcje inferencji; Apple zaznacza przy tym, że każdy wpis zawiera wyspecjalizowany asset powstały z konkretnego .aimodel lub .aimodelc oraz z określonej kombinacji specjalizacji.⁶ Praktyczny wniosek: specjalizacji nie warto powtarzać przy każdym uruchomieniu. Pamięć podręczna to sposób, w jaki Core AI pozwala kosztownemu krokowi wydarzyć się raz, a tanemu krokowi — ładowaniu zbuforowanych artefaktów — powtarzać się później.

Gdy operacje na assetach zawodzą (brakujący pakiet, uszkodzony .aimodel, nieczytelny plik), Core AI zgłasza AssetError, „an error that occurs during model asset operations”.⁴ Należy traktować go jak każdą inną granicę wejścia-wyjścia: asset leży na dysku, operacje dyskowe zawodzą, a system typów wskazuje dokładnie, gdzie umieścić catch.

Tensory: NDArray i jego deskryptor

Inferencja przyjmuje liczby na wejściu i oddaje liczby na wyjściu, a kontenerem Core AI dla tych liczb jest NDArray, „a multidimensional array of scalar values used for model inference”.⁵ Komuś, kto pracował z ndarray z NumPy, tablicami MLX czy MLMultiArray, kształt tego pomysłu wyda się znajomy: n-wymiarowy blok skalarów o zdefiniowanym układzie. NDArray przechowuje dane w układzie wyznaczonym przez swój kształt i pozostałe właściwości opisowe.⁵

Typem towarzyszącym jest NDArrayDescriptor, „a description of an array’s shape, scalar type, and memory layout expectations”.⁷ Deskryptor jest kontraktem. Ujęcie Apple jest bezpośrednie: deskryptor zawiera oczekiwania wobec wartości tablicowej przekazywanej funkcji inferencji, a większość tych oczekiwań jest ścisła. Jeśli deskryptor wskazuje typ skalarny .float32, przekazywana tablica musi używać .float32.⁷ Kształtu ani typu oczekiwanego przez funkcję się nie zgaduje; pyta się o nie deskryptor funkcji i dostosowuje się do odpowiedzi.

// 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).

Lekcja projektowa jest tu odbiciem podziału na asset i model. Core AI konsekwentnie stawia tani obiekt opisu przed kosztownym obiektem wartości. Najpierw czyta się deskryptor, aby poznać kontrakt, a dopiero potem alokuje NDArray, który go spełnia — zamiast alokować najpierw i odkrywać niezgodność dopiero w czasie inferencji. Specjalnie dla wejść obrazowych Core AI definiuje też ImageDescriptor, „a description of an image’s dimensions and pixel format”, dzięki czemu pikselowe wejście modelu wizyjnego otrzymuje to samo podejście z deskryptorem na pierwszym miejscu.¹¹

Wybór miejsca, w którym wykonuje się inferencja

Apple silicon ma trzy miejsca do liczenia: CPU, GPU i Neural Engine. Powodem, dla którego istnieje Core AI, a nie wyłącznie Core ML, jest to, że Core AI pozwala wskazać, które z nich framework ma obrać za cel, zamiast wnioskować to samodzielnie.

ComputeUnitKind to „a type of hardware compute unit available for model inference”.⁸ Rodzajów jednostek obliczeniowych używa się razem z opcjami specjalizacji, aby sterować tym, jaki sprzęt framework obiera za cel podczas specjalizacji modelu; domyślnie specjalizacja wykorzystuje wszystkie jednostki obliczeniowe dostępne na urządzeniu.⁸ Ustawienie domyślne jest właściwą odpowiedzią przy większości zadań i o to właśnie chodzi: nadpisuje się je tylko wtedy, gdy istnieje ku temu powód (wrażliwa na opóźnienia ścieżka, którą warto przypiąć do Neural Engine, przebieg diagnostyczny wymuszony na CPU, obciążający GPU potok koordynowany z inną pracą karty graficznej).

Tę intencję przekazuje się przez SpecializationOptions, strukturę niosącą decyzje podjęte w chwili specjalizacji.⁹ Specjalizacja to wspomniany wcześniej kosztowny krok, a w SpecializationOptions mieszczą się wybór jednostek obliczeniowych i pozostałe decyzje specjalizacyjne. Ponieważ wpis w pamięci podręcznej jest kluczowany konkretnym assetem i konkretną kombinacją specjalizacji, zmiana opcji zmienia to, który zbuforowany artefakt wraca — i tak domyka się pętla między wyborem sprzętu a buforowaniem.⁶

Planowanie to druga oś pytania „jak to się wykonuje”, a Core AI modeluje ją jako ComputeStream, „a stream of work to be run asynchronously”.¹⁰ Strumień obliczeniowy podaje się po to, by zakodować na nim pracę; Apple zaznacza, że wiele inferencji zakodowanych na tym samym strumieniu jest w razie potrzeby serializowanych na podstawie odczytywanych i zapisywanych wartości.¹⁰ Płyną z tego dwa wnioski. Po pierwsze, strumień jest prymitywem porządkującym: wystarczy zakodować zależne od siebie inferencje na jednym strumieniu, a Core AI ustawi je w kolejności wynikającej z zależności danych. Po drugie, praca jest domyślnie asynchroniczna, więc strumień jest również sposobem na utrzymanie wolnego wątku wywołującego, podczas gdy Neural Engine albo GPU liczy.

Funkcje inferencji: to, co faktycznie się wykonuje

Załadowany .aimodel nie jest pojedynczym obiektem wywoływalnym. Modele udostępniają nazwane funkcje (enkoder, dekoder, wieżę wizyjną, krok prefill w odróżnieniu od kroku decode), a jednostką wykonania w Core AI jest InferenceFunction: „a function that performs inference on input values and produces output values”.¹⁴

Zanim się ją wywoła, należy ją zbadać. InferenceFunctionDescriptor to „a description of an inference function’s signature”; deskryptora używa się do zbadania nazw i typów wejść, wyjść oraz stanów funkcji przed uruchomieniem inferencji.¹³ Stany to szczegół, przy którym warto się zatrzymać: funkcja ze stanem to sposób, w jaki model stanowy — na przykład pamięć KV w pętli decode transformera — zachowuje informacje między wywołaniami, a deskryptor sygnalizuje ich obecność, zanim podejmie się próbę sterowania funkcją.

Sama InferenceFunction jest właścicielem zasobów potrzebnych do inferencji, w tym wag modelu i buforów pośrednich. Funkcję ładuje się z modelu i wywołuje run(inputs:states:outputViews:), aby przeprowadzić inferencję.¹⁴ Sygnatura run jest wymieniona w omówieniu samego Apple, więc trzy rzeczy potrzebne w wywołaniu są jawne: wartości wejściowe, wartości stanu oraz widoki wyjściowe, które mają zostać zapisane.

// 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
)

Dwie właściwości sprawiają, że funkcja jest wygodna pod obciążeniem. Jest Sendable, można ją zatem wykonywać współbieżnie z wielu zadań, a Apple zaznacza, że w razie potrzeby automatycznie alokuje dodatkowe bufory pośrednie, aby tę współbieżność obsłużyć.¹⁴ Nie trzeba serializować wywołań za blokadą, by chronić wspólny obszar roboczy; funkcja zarządza własnymi buforami dla każdego współbieżnego wywołującego. To istotna różnica wobec API, w których pojedynczy uchwyt inferencji jest w praktyce jednowątkowy.

Wartości przepływające przez run to instancje InferenceValue, „a value that an inference function accepts as input or produces as output”.¹² InferenceValue opakowuje albo NDArray, albo bufor pikseli, a wynik po inferencji pobiera się przez jego właściwość value.¹² To opakowanie sprawia, że jedna sygnatura run przenosi zarówno wejścia tensorowe, jak i obrazowe, bez osobnych przeciążeń: model tekstowy przekazuje wartości oparte na NDArray, model wizyjny — oparte na buforze pikseli, a funkcja czyta deskryptor, aby wiedzieć, czego oczekuje.

Kiedy sięgnąć po Core AI

Najtrudniejsza w Core AI nie jest API. Najtrudniejsza jest świadomość, że w ogóle należy być tutaj, a nie warstwę wyżej. Uczciwe drzewo decyzyjne:

• Foundation Models, gdy systemowy model Apple wykonuje zadanie. Streszczanie, klasyfikacja, ekstrakcja, przeredagowanie, ustrukturyzowane wyjście: to należy do frameworka Foundation Models, który nie kosztuje ani wag, ani budżetu pamięci, ani kroku specjalizacji. Jeśli dana funkcja się tam mieści, na tym warto poprzestać. Schodzenie do Core AI po to, by od nowa zaimplementować to, co model systemowy już potrafi, jest pracą zmarnowaną.
• Core ML, gdy jest stały, przekonwertowany model, a decyzje sprzętowe i optymalizacyjne ma podejmować konwerter. Core ML celuje w Neural Engine przy ciasnym budżecie energii i opóźnień dla zamkniętego modelu produkcyjnego i niczego nie wymaga w kwestii specjalizacji ani planowania. Jeśli nie ma ochoty myśleć o wyborze jednostek obliczeniowych ani o strumieniach obliczeniowych, to sygnał, żeby pozostać przy Core ML.
• MLX, gdy potrzebny jest framework tablicowy klasy badawczej, który wbudowuje się we własny kod i na którym się iteruje: własna pętla treningowa, skwantyzowane modele o otwartych wagach, dostrajanie metodą LoRA, szybkie eksperymentowanie. MLX to biblioteka dostarczana razem z wagami, a nie systemowa warstwa wykonywania modeli. Wygrywa elastycznością i tempem iteracji.
• Core AI, gdy jest model do uruchomienia i potrzebne są jawne uchwyty frameworka: AIModelAsset badany przed podjęciem zobowiązania, SpecializationOptions przypinające jednostki obliczeniowe, AIModelCache pod własnym zarządem, ComputeStream, na którym się planuje, oraz InferenceFunction wywoływane współbieżnie. Sięga się tutaj wtedy, gdy to właśnie ustawienia domyślne wyższych warstw stoją na drodze i można nazwać, które z nich trzeba nadpisać.

Wspólna nić całego stosu: każda warstwa niżej wymienia jedno ustawienie domyślne na jeden uchwyt. Foundation Models oddaje wszystko i o nic nie prosi. Core AI podaje dźwignie i wymaga wiedzy, za którą pociągnąć. Jeśli nie da się nazwać potrzebnej kontroli nad specjalizacją, buforowaniem czy planowaniem, Core AI nie jest jeszcze potrzebny.

Wypowiedź z laboratorium WWDC 2026 wyostrza, gdzie przebiega granica między Core AI a Core ML w nowych projektach. Sparafrazowane na podstawie lokalnie transkrybowanego nagrania z WWDC 2026 Coding Intelligence, Machine Learning & AI Group Lab: inżynier Core AI zasiadający w panelu powiedział, że Apple prosi wszystkich pracujących z sieciami neuronowymi o przejście na Core AI, przy czym Core ML pozostaje na miejscu, ale skupia się na tradycyjnym uczeniu maszynowym, takim jak drzewa decyzyjne, a wszystko nowe kieruje się do Core AI.¹⁶ Warto czytać to jako sygnał kierunku od ludzi budujących ten framework, a nie jako udokumentowaną politykę: jeśli w nowym projekcie sięga się po sieć neuronową, laboratorium przedstawiło Core AI jako warstwę, na której należy budować.

Jak model trafia do Core AI

Framework jest wykonawczą połową większego procesu, a od czerwcowych wersji beta Apple opublikowało w całości połowę narzędziową.¹⁷ Potok wygląda następująco.

Konwersja. Punktem wyjścia jest plik .aimodel, przekonwertowany z modelu źródłowego za pomocą pakietu coreai-torch (rozszerzenia Core AI PyTorch Extensions Apple dla Pythona) albo już przygotowany w tym formacie.¹⁷ Plik .aimodel trafia do targetu Xcode jak każdy inny zasób, pojawia się w fazie kompilacji Compile Sources i otrzymuje w Xcode podgląd modelu pokazujący parametry, rozmiar zapisu, metadane i graf operacji. Jedna zależność systemu budowania warta poznania od razu: integracja modeli Core AI wymaga Metal Toolchain, którego Xcode nie instaluje domyślnie, a bez niego kompilacje zawierające pliki .aimodel kończą się błędem o brakującym kompilatorze Metal.¹⁷

Opcjonalna kompilacja z wyprzedzeniem. Specjalizacja zachodzi automatycznie przy tworzeniu AIModel, a przy dużych modelach ten koszt pierwszego ładowania jest odczuwalny. Narzędzie wiersza poleceń coreai-build przenosi najkosztowniejszą część, czyli kompilację modelu, na maszynę budującą: przekształca .aimodel w assety .aimodelc, po jednym na architekturę urządzenia (kompilacja MyModel.aimodel daje MyModel.<arch>.aimodelc), a w czasie działania aplikacja wybiera asset pasujący do bieżącego urządzenia, dzięki czemu Core AI pomija krok kompilacji.¹⁷ Kompilacja z wyprzedzeniem celuje w sprzętowe minimum Apple Intelligence: iPhone lub iPad z A17 Pro albo nowszym, komputery Mac z M1 albo nowszym oraz Apple Vision Pro z M2.¹⁷

Debugowanie i profilowanie. Obserwowalność pokrywają trzy narzędzia: Core AI Debugger, samodzielna aplikacja dla macOS służąca do badania grafu operacji modelu, uruchamiania go na urządzeniu i porównywania wyjść z przebiegiem referencyjnym; wskaźnik debugowania Core AI w Xcode, monitorujący na żywo ładowanie, specjalizację i aktywność inferencji w trakcie sesji debugowania; oraz instrument Core AI, czyli szablon Instruments profilujący czasy wykonania na CPU, GPU i Neural Engine.¹⁷

Opisany wcześniej kształt czasu wykonania wpisuje się w ten proces bez zmian: przygotowany model ładuje się jako AIModelAsset do inspekcji, specjalizuje do AIModel i uruchamia przez jego InferenceFunction, a AIModelCache zachowuje wyspecjalizowane artefakty, aby kosztowny krok wydarzył się tylko raz.¹²³⁶¹⁴

Często zadawane pytania

Czym jest framework Core AI firmy Apple?

Core AI to niskopoziomowy framework iOS 27 do uruchamiania modeli sztucznej inteligencji na Apple silicon, podsumowany przez Apple jako „Run AI models in your app on Apple silicon”.¹ Wykonuje inferencję modeli na CPU, GPU i Neural Engine przez API języka Swift, które upraszcza typowe zadania, a w razie potrzeby daje kontrolę nad specjalizacją modelu, buforowaniem i wydajnością inferencji.¹ Leży poniżej Foundation Models i Core ML jako warstwa wykonywania modeli.

Czym różni się AIModelAsset od AIModel?

AIModelAsset to niewyspecjalizowany asset źródłowy tworzony z adresu URL pakietu .aimodel na dysku; służy do badania sygnatur funkcji, opisów wejść i wyjść, typów obliczeniowych i typów przechowywania oraz metadanych modelu bez specjalizacji, ponieważ specjalizacja jest kosztowna, a asset nie może uruchomić inferencji.² AIModel to wyspecjalizowany model zoptymalizowany pod sprzęt bieżącego urządzenia, który faktycznie wykonuje inferencję; tworzy się go, ładując asset z dysku.³ Podział pozwala badać tanio, a specjalizować dopiero w momencie podjęcia zobowiązania.

Jak Core AI wybiera między CPU, GPU i Neural Engine?

Wyborem sprzętu steruje się za pomocą ComputeUnitKind poprzez SpecializationOptions. Rodzaj jednostki obliczeniowej nazywa typ sprzętowej jednostki dostępnej dla inferencji i służy do sterowania tym, jaki sprzęt framework obiera za cel podczas specjalizacji modelu; domyślnie specjalizacja wykorzystuje wszystkie jednostki obliczeniowe dostępne na urządzeniu.⁸⁹ Ustawienie domyślne nadpisuje się wyłącznie wtedy, gdy istnieje konkretny powód, na przykład przypięcie wrażliwej na opóźnienia ścieżki do jednej jednostki obliczeniowej.

Czym jest InferenceFunction i jak ją uruchomić?

InferenceFunction wykonuje inferencję na wartościach wejściowych i wytwarza wartości wyjściowe, będąc właścicielem wag modelu i buforów pośrednich.¹⁴ Najpierw bada się jej sygnaturę przez InferenceFunctionDescriptor, który opisuje nazwy i typy wejść, wyjść oraz stanów funkcji, a następnie ładuje funkcję z AIModel i wywołuje run(inputs:states:outputViews:).¹³¹⁴ Funkcja jest Sendable i automatycznie alokuje bufory pośrednie, aby obsłużyć współbieżność, dzięki czemu wiele zadań może wykonywać ją jednocześnie.¹⁴

Czy używać Core AI zamiast Core ML lub Foundation Models?

Foundation Models sprawdza się wtedy, gdy zadanie wykonuje model systemowy, a Core ML wtedy, gdy jest stały, przekonwertowany model, a decyzje sprzętowe i optymalizacyjne ma podejmować konwerter. Po Core AI warto sięgnąć, gdy potrzebna jest jawna kontrola nad specjalizacją (SpecializationOptions, ComputeUnitKind), buforowaniem (AIModelCache) i planowaniem (ComputeStream), którymi wyższe warstwy zajmują się samodzielnie.⁸⁹⁶¹⁰ Jeśli nie da się nazwać potrzebnej kontroli, lepiej pozostać warstwę wyżej.

Pełny klaster Ekosystem Apple: MLX na Apple Silicon — framework tablicowy wbudowywany wtedy, gdy potrzebny jest własny model i własna pętla treningowa; TBDR i pamięć zunifikowana Apple Silicon — sprzętowe podłoże, dzięki któremu współdzielenie CPU, GPU i Neural Engine w ogóle działa; inferencja na urządzeniu z Core ML — warstwa stałego modelu powyżej Core AI; oraz Foundation Models — zapieczętowany systemowy model LLM Apple na szczycie stosu. Punktem centralnym jest Seria Ekosystem Apple. Szerszy kontekst iOS wraz z agentami AI opisuje przewodnik po tworzeniu agentów na iOS.

Źródła