Core AI: uruchamianie modeli na Apple silicon

W stosie sztucznej inteligencji działającej na urządzeniu Apple brakowało jednego szczebla. Foundation Models daje systemowy LLM, zaplombowany i darmowy. Core ML uruchamia ustalony, przekonwertowany model, a konwerter podejmuje za nas decyzje dotyczące sprzętu. MLX dostarcza framework tablicowy, który się osadza, oraz model, który się wybiera. iOS 27 dodaje szczebel poniżej całej tej trójki: Core AI, framework, którego jednowierszowy opis brzmi „Uruchamiaj modele AI w swojej aplikacji na Apple silicon”.¹ Jest to powierzchnia wykonywania modeli, miejsce, do którego sięga się, gdy chce się samodzielnie sterować specjalizacją, buforowaniem i harmonogramowaniem inferencji, zamiast akceptować domyślne ustawienia wyższej warstwy.

W sesji 324 Apple pozycjonuje Core AI jako ten sam framework inferencji, który napędza działające na urządzeniu Apple Intelligence, teraz otwarty na potrzeby inteligencji we własnej aplikacji.¹⁵

Ten kontekst ma znaczenie, ponieważ Core AI leży poniżej abstrakcji, których powinna używać większość aplikacji. Apple opisuje go jako zaprojektowany z myślą o Apple silicon, pozwalający aplikacji korzystać z najnowszych architektur modeli i technik inferencji w obrębie CPU, GPU oraz Neural Engine, z Swift API, które upraszcza typowe zadania, dając jednocześnie większą kontrolę nad specjalizacją modelu, buforowaniem i wydajnością inferencji, gdy zajdzie taka potrzeba.¹ Teza tego wpisu: po Core AI należy sięgać wtedy, gdy ma się model, który chce się uruchomić z jawną kontrolą nad tym, gdzie i jak się wykonuje, a pozostać przy Core ML lub Foundation Models, gdy takiej potrzeby nie ma. Framework wynagradza konkretną potrzebę, a nie domyślną preferencję.

Najważniejsze w skrócie

• Core AI oddziela niewyspecjalizowany AIModelAsset (taniej zbadać strukturę i metadane modelu) od wyspecjalizowanego AIModel (uruchomić inferencję na urządzeniu), przy czym AIModelCache przechowuje artefakty właściwe dla danego urządzenia, a AssetError obsługuje niepowodzenia operacji na zasobie.²³⁶⁴
• Dane inferencji przepływają przez NDArray, wielowymiarową tablicę wartości skalarnych, opisaną przez NDArrayDescriptor, który ustala kształt, typ skalarny oraz oczekiwania co do układu pamięci.⁵⁷
• Sprzęt obiera się za pomocą ComputeUnitKind (CPU, GPU lub Neural Engine) poprzez SpecializationOptions, a pracę asynchroniczną harmonogramuje się na ComputeStream.⁸⁹¹⁰
• InferenceFunction posiada wagi i bufory oraz uruchamia inferencję; InferenceFunctionDescriptor pozwala najpierw zbadać sygnaturę wejść, wyjść i stanu. Funkcja jest Sendable, więc można ją uruchamiać współbieżnie.¹⁴¹³
• Modele ładują się z pakietu .aimodel znajdującego się na dysku, a Core AI dostarcza obok frameworka narzędzia do przygotowywania, konwersji i debugowania. Po Core AI należy sięgać, gdy potrzebna jest jawna kontrola nad specjalizacją i harmonogramowaniem; w przeciwnym razie warto pozostać przy Core ML lub Foundation Models.²¹

Dwa słowa, które rządzą całym projektem: zasób i model

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

AIModelAsset to „niewyspecjalizowany źródłowy zasób modelu”.² Tworzy się go z adresu URL pakietu .aimodel na dysku i używa do badania modelu bez ponoszenia kosztu specjalizacji. Apple jasno tłumaczy, dlaczego ten podział istnieje: zasób modelu pozwala odpytywać informacje o modelu bez przeprowadzania specjalizacji, która jest operacją kosztowną. Z zasobu można odczytać sygnatury funkcji, opisy wejść i wyjść, typy obliczeniowe i typy przechowywania oraz metadane dostarczone przez autora. Czego nie można zrobić, to uruchomić inferencji; zasób 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: „wyspecjalizowany model do uruchamiania inferencji na urządzeniu”.³ AIModel reprezentuje wyspecjalizowany zasób .aimodel zoptymalizowany pod sprzęt bieżącego urządzenia, a tworzy się go, ładując zasób z dysku.³ Zasób odpowiada na pytanie czym jest ten model?; model odpowiada uruchom go tu i teraz. Asymetria kosztów między tymi dwoma jest powodem, dla którego API wymusza nazwanie, którego z nich się chce. Zbadanie stu modeli kandydatów w celu wybrania jednego jest tanie, jeśli buduje się tylko zasoby; byłoby rujnujące, gdyby każda inspekcja specjalizowała.

Specjalizacja wytwarza artefakty właściwe dla danego urządzenia, a te artefakty mają swój dom: AIModelCache, „pamięć podręczna przechowująca wyspecjalizowane artefakty modelu na potrzeby inferencji”.⁶ Pamięć podręczna przechowuje zoptymalizowane artefakty właściwe dla urządzenia, które model ładuje, aby wykonać swoje funkcje inferencji, a Apple zauważa, że każdy wpis w pamięci podręcznej zawiera wyspecjalizowany zasób utworzony z konkretnego .aimodel lub .aimodelc oraz określonej kombinacji specjalizacji.⁶ Praktyczny wniosek: specjalizacja nie jest czymś, co chce się powtarzać przy każdym uruchomieniu. Pamięć podręczna to sposób, w jaki Core AI pozwala kosztownemu krokowi wydarzyć się raz, a tani krok (ładowanie buforowanych artefaktów) odbywać się odtąd już zawsze.

Gdy operacje na zasobie się nie powiodą (brakujący pakiet, zniekształcony .aimodel, nieczytelny plik), Core AI ujawnia AssetError, „błąd, który występuje podczas operacji na zasobie modelu”.⁴ Należy go traktować tak, jak traktuje się każdą granicę wejścia-wyjścia: zasób żyje na dysku, operacje dyskowe zawodzą, a system typów dokładnie wskazuje, gdzie umieścić catch.

Tensory: NDArray i jego deskryptor

Inferencja wprowadza liczby na wejściu i wyprowadza liczby na wyjściu, a kontenerem Core AI na te liczby jest NDArray, „wielowymiarowa tablica wartości skalarnych używana do inferencji modelu”.⁵ Każdy, kto pracował z NumPy ndarray, tablicami MLX czy MLMultiArray, rozpozna kształt tej idei: n-wymiarowy blok skalarów o zdefiniowanym układzie. NDArray przechowuje swoje dane w układzie zdefiniowanym przez jego kształt i pozostałe właściwości opisowe.⁵

Typem towarzyszącym jest NDArrayDescriptor, „opis kształtu tablicy, typu skalarnego i oczekiwań co do układu pamięci”.⁷ Deskryptor to kontrakt. Ujęcie Apple jest bezpośrednie: deskryptor zawiera oczekiwania wobec wartości tablicowej, którą podaje się funkcji inferencji, a większość oczekiwań jest ścisła. Jeśli deskryptor określa typ skalarny .float32, podana tablica musi używać .float32.⁷ Nie zgaduje się kształtu i typu, których oczekuje funkcja; pyta się o deskryptor funkcji i dostosowuje się do niego.

// 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 odzwierciedla tutaj podział na zasób i model. Core AI konsekwentnie stawia tani obiekt opisu przed kosztownym obiektem wartości. Odczytuje się deskryptor, aby poznać kontrakt, a następnie alokuje NDArray, który go spełnia, zamiast najpierw alokować i odkrywać niezgodność dopiero w czasie inferencji. Specjalnie dla wejść obrazowych Core AI definiuje również ImageDescriptor, „opis wymiarów obrazu i formatu pikseli”, dzięki czemu wejście pikselowe modelu wizyjnego dostaje takie samo, oparte najpierw na deskryptorze, traktowanie.¹¹

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

Apple silicon ma trzy miejsca, w których można obliczać: CPU, GPU i Neural Engine. Powodem, dla którego istnieje Core AI, a nie tylko Core ML, jest to, że Core AI pozwala określić, które z nich obiera framework, zamiast je wnioskować.

ComputeUnitKind to „rodzaj sprzętowej jednostki obliczeniowej dostępnej do inferencji modelu”.⁸ Rodzajów jednostek obliczeniowych używa się wraz z opcjami specjalizacji, aby sterować tym, na jaki sprzęt framework kieruje się podczas specjalizacji modelu, a domyślnie specjalizacja wykorzystuje wszystkie dostępne jednostki obliczeniowe urządzenia.⁸ Domyślne ustawienie to właściwa odpowiedź dla większości prac, i o to właśnie chodzi: nadpisuje się je tylko wtedy, gdy ma się ku temu powód (ścieżka wrażliwa na opóźnienia, którą chce się przypiąć do Neural Engine, przebieg debugowania, który chce się wymusić na CPU, intensywnie korzystający z GPU potok koordynowany z inną pracą GPU).

Tę intencję przekazuje się przez SpecializationOptions, strukturę, która niesie wybory dokonane w czasie specjalizacji.⁹ Specjalizacja to wspomniany wcześniej kosztowny krok, a SpecializationOptions to miejsce, w którym mieszczą się kierowanie na jednostki obliczeniowe oraz inne decyzje specjalizacyjne. Ponieważ wpis w pamięci podręcznej kluczuje się po konkretnym zasobie i kombinacji specjalizacji, zmiana opcji zmienia, który buforowany artefakt zostaje zwrócony, co domyka pętlę między kierowaniem a buforowaniem.⁶

Harmonogramowanie to druga oś tego, „jak się uruchamia”, a Core AI modeluje je jako ComputeStream, „strumień pracy do uruchomienia asynchronicznie”.¹⁰ Strumień obliczeniowy to to, co podaje się, aby zakodować pracę do strumienia, a Apple zauważa, że wiele inferencji zakodowanych do tego samego strumienia jest serializowanych w razie potrzeby na podstawie odczytanych i zapisanych wartości.¹⁰ Wynikają z tego dwa wnioski. Po pierwsze, strumień to prymityw porządkowania: zakodowanie zależnych inferencji do jednego strumienia sprawia, że Core AI sekwencjonuje je według zależności danych. Po drugie, praca jest domyślnie asynchroniczna, więc strumień to także sposób na utrzymanie wątku wywołującego wolnym, gdy Neural Engine lub GPU wykonuje pracę.

Funkcje inferencji: to, co naprawdę się wykonuje

Załadowany .aimodel nie jest pojedynczym obiektem wywoływalnym. Modele udostępniają nazwane funkcje (enkoder, dekoder, wieżę wizyjną, krok prefill kontra krok decode), a jednostką wykonania Core AI jest InferenceFunction: „funkcja, która przeprowadza inferencję na wartościach wejściowych i wytwarza wartości wyjściowe”.¹⁴

Zanim się ją wywoła, bada się ją. InferenceFunctionDescriptor to „opis sygnatury funkcji inferencji”, a deskryptora używa się do zbadania nazw i typów wejść, wyjść i stanów funkcji przed uruchomieniem inferencji.¹³ Stany to szczegół wart zatrzymania się: funkcja ze stanem to sposób, w jaki model stanowy (na przykład pamięć podręczna KV w pętli decode transformatora) zachowuje informacje między wywołaniami, a deskryptor mówi, że funkcja je posiada, zanim spróbuje się nią sterować.

Sam InferenceFunction posiada zasoby potrzebne do inferencji, w tym wagi modelu i bufory pośrednie. Ładuje się funkcję z modelu i wywołuje run(inputs:states:outputViews:), aby przeprowadzić inferencję.¹⁴ Sygnatura run jest nazwana we własnym omówieniu Apple, więc trzy rzeczy potrzebne wywołaniu są jawne: wartości wejściowe, wartości stanu i widoki wyjściowe, które chce się zapisać.

// 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 przyjemna pod obciążeniem. Jest Sendable, więc można ją uruchamiać współbieżnie z wielu zadań, a Apple zauważa, że automatycznie alokuje dodatkowe bufory pośrednie w miarę potrzeb, aby tę współbieżność wesprzeć.¹⁴ Nie serializuje się wywołań za blokadą, by chronić współdzieloną pamięć roboczą; funkcja zarządza własnymi buforami dla każdego współbieżnego wywołującego. To znacząca różnica względem API, w których pojedynczy uchwyt inferencji jest faktycznie jednowątkowy.

Wartości przepływające przez run to instancje InferenceValue, „wartość, którą funkcja inferencji przyjmuje jako wejście lub wytwarza jako wyjście”.¹² InferenceValue opakowuje albo NDArray, albo bufor pikseli, a wynik pobiera się po inferencji za pomocą jego właściwości value.¹² To opakowanie pozwala jednej sygnaturze run przenosić zarówno wejścia tensorowe, jak i wejścia obrazowe bez osobnych przeciążeń: model tekstowy przekazuje wartości oparte na NDArray, model wizyjny przekazuje wartości oparte na buforze pikseli, a funkcja odczytuje deskryptor, aby wiedzieć, którego oczekuje.

Kiedy sięgać po Core AI

Najtrudniejsza część Core AI to nie API. Jest nią świadomość, że w ogóle powinno się 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: te należą do Foundation Models, które nie kosztuje żadnych wag, żadnego budżetu pamięci ani kroku specjalizacji. Jeśli funkcja pasuje, należy się tam zatrzymać. Zejście do Core AI, by ponownie zaimplementować to, co systemowy model już robi, to praca zmarnowana.
• Core ML, gdy ma się ustalony, przekonwertowany model i chce się, by konwerter podejmował za nas decyzje dotyczące sprzętu i optymalizacji. Core ML kieruje się na Neural Engine z ciasną kontrolą mocy i opóźnień dla zablokowanego modelu produkcyjnego i niczego od nas nie wymaga w kwestii specjalizacji czy harmonogramowania. Jeśli nie chce się myśleć o kierowaniu na jednostki obliczeniowe ani o strumieniach obliczeniowych, to sygnał, by pozostać przy Core ML.
• MLX, gdy chce się framework tablicowy klasy badawczej, który się osadza i nad którym się iteruje: własna pętla treningowa, skwantyzowane modele o otwartych wagach, dostrojenia LoRA, szybkie eksperymentowanie. MLX to biblioteka dostarczana wraz z wagami, a nie systemowa powierzchnia wykonywania modeli. Wygrywa elastycznością i szybkością iteracji.
• Core AI, gdy ma się model do uruchomienia i chce się jawnych uchwytów frameworka: AIModelAsset, który bada się przed zaangażowaniem, SpecializationOptions, które przypina jednostki obliczeniowe, AIModelCache, którym się zarządza, ComputeStream, na który się harmonogramuje, oraz funkcje InferenceFunction, które wywołuje się współbieżnie. Sięga się tutaj, gdy domyślne ustawienia wyższych warstw są tym, co stoi na drodze, i potrafi się nazwać, które z nich trzeba nadpisać.

Myśl przewodnia całego stosu: każda warstwa w dół wymienia domyślne ustawienie na uchwyt. Foundation Models oddaje wszystko i niczego nie wymaga. Core AI oddaje dźwignie i wymaga wiedzy, którą pociągnąć. Jeśli nie potrafi się nazwać kontroli nad specjalizacją, buforowaniem czy harmonogramowaniem, jakiej się potrzebuje, to Core AI nie jest jeszcze potrzebne.

Wypowiedź z laboratorium WWDC 2026 zaostrza, gdzie przebiega granica między Core AI a Core ML dla nowych prac. Parafrazując z lokalnie przepisanego nagrania z laboratorium grupowego Coding Intelligence, Machine Learning & AI na WWDC 2026, inżynier Core AI z panelu powiedział, że Apple prosi wszystkich pracujących z sieciami neuronowymi, by w przyszłości przeszli na Core AI, podczas gdy Core ML pozostaje na miejscu, ale skupiony na tradycyjnym uczeniu maszynowym, takim jak drzewa decyzyjne, a wszystko nowe trafia do Core AI.¹⁶ Należy to czytać jako sygnał kierunku marszu od ludzi budujących framework, a nie jako udokumentowaną politykę: jeśli sięga się po sieć neuronową w nowym projekcie, laboratorium przedstawiło Core AI jako powierzchnię, na której warto budować.

Jak model dociera do Core AI

Framework to połowa wykonawcza większego przepływu pracy. Apple zauważa, że Core AI obejmuje obok frameworka dodatkowe narzędzia do przygotowywania modeli, integracji i debugowania: przygotowuje się modele pod Apple silicon, konwertuje się je do formatu .aimodel i używa się towarzyszącej aplikacji, która wspiera wizualizację i debugowanie numeryczne.¹ Opis nazw tych narzędzi w arkuszu faktów jest urwany, więc dokładne nazwy narzędzi i sposób ich wywoływania warto potwierdzić z dokumentacją Core AI Apple, a nie ufać jakiejkolwiek rekonstrukcji.¹ Co jest zweryfikowane, to kształt potoku: model źródłowy zostaje przygotowany, przekonwertowany do .aimodel, załadowany jako AIModelAsset do inspekcji, wyspecjalizowany w AIModel i uruchomiony przez swoje funkcje InferenceFunction, przy czym AIModelCache zachowuje wyspecjalizowane artefakty, aby kosztowny krok wydarzył się raz.¹²³⁶¹⁴

FAQ

Czym jest framework Core AI firmy Apple?

Core AI to niskopoziomowy framework iOS 27 do uruchamiania modeli AI na Apple silicon, streszczany przez Apple jako „Uruchamiaj modele AI w swojej aplikacji na Apple silicon”.¹ Uruchamia inferencję modelu w obrębie CPU, GPU i Neural Engine poprzez Swift API, które upraszcza typowe zadania, dając jednocześnie kontrolę nad specjalizacją modelu, buforowaniem i wydajnością inferencji, gdy zajdzie taka potrzeba.¹ Leży poniżej Foundation Models i Core ML jako powierzchnia wykonywania modeli.

Jaka jest różnica między AIModelAsset a AIModel?

AIModelAsset to niewyspecjalizowany zasób źródłowy, który tworzy się z adresu URL pakietu .aimodel na dysku; używa się go do badania sygnatur funkcji modelu, opisów wejść i wyjść, typów obliczeniowych i typów przechowywania oraz metadanych bez specjalizowania, ponieważ specjalizacja jest kosztowna, a zasób nie może uruchomić inferencji.² AIModel to wyspecjalizowany model zoptymalizowany pod sprzęt bieżącego urządzenia, który faktycznie uruchamia inferencję; tworzy się go, ładując zasób z dysku.³ Podział pozwala badać tanio i specjalizować dopiero wtedy, gdy się angażuje.

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

Kierowaniem na sprzęt steruje się za pomocą ComputeUnitKind poprzez SpecializationOptions. Rodzaj jednostki obliczeniowej nazywa typ sprzętowej jednostki obliczeniowej dostępnej do inferencji, a używa się go do sterowania tym, na jaki sprzęt framework kieruje się podczas specjalizacji modelu; domyślnie specjalizacja wykorzystuje wszystkie dostępne jednostki obliczeniowe urządzenia.⁸⁹ Domyślne ustawienie nadpisuje się tylko wtedy, gdy ma się konkretny powód, taki jak przypięcie ścieżki wrażliwej na opóźnienia do jednej jednostki obliczeniowej.

Czym jest InferenceFunction i jak ją uruchomić?

InferenceFunction przeprowadza inferencję na wartościach wejściowych i wytwarza wartości wyjściowe, posiadając wagi modelu i bufory pośrednie.¹⁴ Najpierw bada się jej sygnaturę przez InferenceFunctionDescriptor, który opisuje nazwy i typy wejść, wyjść i stanów funkcji, następnie ładuje się funkcję z AIModel i wywołuje run(inputs:states:outputViews:).¹³¹⁴ Funkcja jest Sendable i automatycznie alokuje bufory pośrednie, aby wesprzeć współbieżność, więc wiele zadań może ją uruchamiać naraz.¹⁴

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

Foundation Models należy używać, gdy systemowy model wykonuje zadanie, a Core ML, gdy ma się ustalony, przekonwertowany model i chce się, by konwerter podejmował decyzje dotyczące sprzętu i optymalizacji. Po Core AI sięga się, gdy chce się jawnej kontroli nad specjalizacją (SpecializationOptions, ComputeUnitKind), buforowaniem (AIModelCache) i harmonogramowaniem (ComputeStream), które wyższe warstwy obsługują w naszym imieniu.⁸⁹⁶¹⁰ Jeśli nie potrafi się nazwać potrzebnej kontroli, warto pozostać warstwę wyżej.

Pełny klaster Apple Ecosystem: MLX na Apple Silicon dla frameworka tablicowego, który się osadza, gdy chce się własnego modelu i pętli treningowej; TBDR i pamięć zunifikowana Apple Silicon dla podłoża sprzętowego, które umożliwia współdzielenie CPU/GPU/Neural Engine; inferencja na urządzeniu Core ML dla warstwy ustalonego modelu nad Core AI; oraz Foundation Models dla zaplombowanego systemowego LLM Apple na szczycie stosu. Centrum znajduje się w serii Apple Ecosystem. Szerszy kontekst iOS z agentami AI znajduje się w przewodniku po tworzeniu agentów iOS.

Źródła