Core ML vs MLX vs Foundation Models: jak wybrać stos AI Apple działający na urządzeniu

Apple udostępnia dziś cztery odrębne sposoby uruchomienia modelu na sprzęcie użytkowników, a wybór niewłaściwego kosztuje przepisanie całości od nowa. Na M2 Max, na którym powstaje ten tekst, MLX utrzymuje 11.2 TFLOPS obliczeń macierzowych fp16 i przenosi dane z przepustowością 351 GB/s zmierzoną dla pamięci zunifikowanej¹. Dla większości aplikacji ta moc jest złym wyborem, ponieważ wbudowany framework Foundation Models wykonuje zadanie w sześciu linijkach kodu Swift i nie dokłada ani jednego megabajta do pobierania. Te cztery frameworki nie są konkurentami. To cztery różne odpowiedzi na jedno pytanie: czyj jest model i kto odpowiada za jego wykonanie?

TL;DR

• Foundation Models to opcja domyślna. Jeśli wbudowany w urządzenie LLM Apple, generalista o ~3B parametrów, poradzi sobie z zadaniem (streszczanie, ekstrakcja, klasyfikacja, generowanie ustrukturyzowanego wyniku, wywoływanie własnych narzędzi), nie trzeba dostarczać żadnych wag modelu ani płacić za inferencję, a każde ulepszenie modelu na poziomie systemu przychodzi za darmo.²
• Core ML służy do dostarczenia własnego wytrenowanego modelu wewnątrz aplikacji. To jedyna ścieżka z pełnoprawnym kierowaniem zadań do Neural Engine, pakowaniem przyjaznym dla App Store i kontraktem kompilacji z wyprzedzeniem, który wymienia elastyczność na czas pracy baterii i przewidywalność.³
• MLX wchodzi do gry, gdy to model jest produktem: badania, fine-tuning, uruchamianie LLM o otwartych wagach albo dowolne obciążenie wymagające bezpośredniej kontroli nad tensorami. To narzędzie dla maszyny deweloperskiej i aplikacji na Maca, a nie środek dostarczania na iOS.⁴
• Core AI (iOS 27) to nowy fundament pod tym wszystkim: niskopoziomowy framework wykonywania modeli z tensorami NDArray i jawnym wskazywaniem jednostek obliczeniowych, przeznaczony dla zespołów, które dziś naginają Core ML do roli środowiska uruchomieniowego dla tensorów.
• Decyzja zwykle sprowadza się do jednego pytania: model wbudowany → Foundation Models; własny model na iOS → Core ML; własny model na własnym Macu → MLX; kontrola na poziomie tensorów na iOS → Core AI. Reszta tego wpisu dotyczy tych 20 % przypadków, w których ta heurystyka zawodzi.

Pytanie ukryte za pytaniem

Każda obserwowana przeze mnie debata o tym, „który framework”, sprowadza się do dwóch osi. (Każdej z nich poświęciłem osobną, pogłębioną analizę: Foundation Models, Core ML, MLX, Core AI).

Oś pierwsza: czyje wagi? Wbudowany model Apple, model wytrenowany lub skonwertowany samodzielnie albo otwarte wagi pobrane z huba. Foundation Models uruchamia wyłącznie model Apple (oraz własne adaptery w stylu LoRA).⁵ Core ML i MLX uruchamiają wyłącznie dostarczone wagi. Ten jeden fakt eliminuje połowę przestrzeni opcji, zanim do rozmowy w ogóle wejdzie wydajność.

Oś druga: kto odpowiada za wykonanie? Foundation Models ukrywa wszystko: żadnych tensorów, żadnych jednostek obliczeniowych, żadnego zarządzania oknem kontekstu poza obiektem sesji. Core ML ukrywa większość rzeczy: przekazuje się skompilowany .mlmodelc i sugeruje jednostki obliczeniowe, a framework sam decyduje o rozdziale zadań. MLX nie ukrywa niczego: całą arytmetykę na tablicach pisze się samodzielnie, a leniwa ewaluacja wraz z pamięcią zunifikowaną stanowią cały warsztat. Core AI plasuje się pomiędzy Core ML a MLX: jawne tensory i wskazywanie jednostek obliczeniowych, ale wykonanie zarządzane przez Apple.

Wystarczy nanieść dowolną realną funkcję na te dwie osie, a framework wybierze się sam.

Foundation Models: domyślny wybór o zerowej wadze pobierania

Framework, od którego większość zespołów powinna zacząć, to ten, który nie wymaga żadnego modelu. Foundation Models udostępnia działający na urządzeniu LLM stojący za Apple Intelligence poprzez LanguageModelSession, a jego najmocniejszą cechą nie jest sam model. Jest nią generowanie sterowane: wystarczy oznaczyć strukturę Swift atrybutem @Generable, a framework ograniczy dekodowanie tak, aby wynik modelu był zadanym typem, zamiast łańcucha znaków, który trzeba parsować i liczyć na łut szczęścia.²

@Generable
struct Itinerary {
    let destination: String
    let days: Int
    @Guide(description: "Budget in USD") let budget: Double
}

let session = LanguageModelSession()
let itinerary = try await session.respond(
    to: "Weekend in Kyoto under $800",
    generating: Itinerary.self
).content

To cała integracja. Żadnego kroku pobierania, żadnych decyzji o kwantyzacji, żadnego rozważania kwestii cieplnych; system planuje pracę modelu, współdzieli go pomiędzy wszystkie aplikacje na urządzeniu i aktualizuje wraz z każdym wydaniem. Wywoływanie narzędzi pozwala modelowi sięgać po samodzielnie zdefiniowane funkcje, co wystarcza do zbudowania naprawdę agentowych funkcji bez żadnego serwera.²

Ograniczenie jest symetryczne: model to generalista o ~3B parametrów. Dobrze streszcza, wydobywa dane, klasyfikuje i odgrywa role przy ustrukturyzowanym wyniku; nie zapewnia natomiast wiedzy o świecie w otwartej dziedzinie, analizy dokumentów o długim kontekście ani niczego, co potrafi model klasy frontier. Gdy wbudowany model nie wystarcza, odpowiedzią Apple są adaptery (dostrojenia w stylu LoRA trenowane zestawem narzędzi Apple na bazie modelu podstawowego), lecz adapter to zobowiązanie: trzeba go trenować od nowa za każdym razem, gdy Apple wyda nową wersję modelu bazowego.⁵ Pełna analiza, wraz z zarządzaniem sesjami i trybami awarii, na które natrafiają recenzenci, znajduje się w pogłębionym omówieniu Foundation Models.

Warto wybrać wtedy, gdy: zadanie ma naturę językową, wbudowany model spełnia przyjęty próg jakości, a dostarczenie zerowej liczby wag ma znaczenie. Dotyczy to większej liczby funkcji, niż zakłada większość zespołów; warto spróbować, zanim sięgnie się po cokolwiek z poniższych.

Core ML: własny model, wykonanie po stronie Apple

Core ML odpowiada na zupełnie inne pytanie. Model już istnieje (klasyfikator obrazu, model osadzeń, potok mowy, destylowany LLM) i musi działać wewnątrz aplikacji iOS, na baterii, w granicach rozmiaru narzuconych przez App Store, jeszcze w tym roku.

Kontraktem jest kompilacja z wyprzedzeniem. Wagi konwertuje się narzędziem coremltools, model kompiluje się do .mlmodelc, a w czasie wykonania framework rozdziela pracę pomiędzy Neural Engine, GPU i CPU; to właśnie ANE jest tym, czego nic innego z tej listy dziś na iOS nie daje. Prawdziwa inżynieria mieszka w kroku konwersji: pokrycie operatorów, kwantyzacja (paletyzacja, liniowa 8/4-bitowa, rzadkość; stos optymalizacji coremltools jest naprawdę rozbudowany⁶) oraz podpowiadanie jednostek obliczeniowych, które przesądza, czy model pobiera 2 waty, czy 8. Wzorce, które faktycznie przeżywają zderzenie z produkcją (podpowiedzi rozdziału zadań, budżety opóźnień, drabina kwantyzacji), są tematem filaru poświęconego Core ML.

To, czego Core ML nie robi, waży tak samo dużo: nie trenuje, nie dostraja i nie daje dostępu do tensorów w środku grafu. To urządzenie do inferencji. Zespoły, które potrzebują „uruchomić mój graf ORAZ zajrzeć do wyników pośrednich”, od lat wyginały Core ML w stronę środowiska uruchomieniowego dla tensorów; dokładnie po to, aby wchłonąć tę akrobację, powstało Core AI.

Warto wybrać wtedy, gdy: wagi są własne, celem jest iOS/iPadOS (albo wieloplatformowość w ekosystemie Apple), a bateria, rozmiar lub ANE mają znaczenie. Czyli: przy niemal każdej dostarczonej na tej platformie funkcji opartej na własnym modelu.

MLX: maszyna badawcza w Macu

MLX odstaje od reszty: to otwartoźródłowy framework tablicowy z grupy badawczej ML w Apple, a nie framework systemowy.⁴ Wygląda jak NumPy, ewaluuje leniwie i traktuje pamięć zunifikowaną Apple silicon jako to, czym ona jest: brak kopiowania z hosta na urządzenie, bo nie istnieje osobna pamięć urządzenia.

Liczby z tej maszyny czynią argument namacalnym. M2 Max utrzymuje 11.2 TFLOPS mnożenia macierzy fp16 przy 4096×4096 oraz 351 GB/s zmierzonej przepustowości strumieniowej pod MLX bez jakiegokolwiek strojenia¹: tyle wystarcza, aby interaktywnie uruchamiać skwantyzowane modele o otwartych wagach i 30B parametrów, dostrajać modele 7B z użyciem LoRA przez jedną noc oraz iterować nad treningami, które inaczej oznaczałyby wynajem GPU w chmurze. Dzięki ekosystemowi mlx-lm większość otwartych modeli dzieli od uruchomienia jedno pip install i pobranie plików.

Granice są równie namacalne. Brak Neural Engine: MLX programuje GPU (oraz CPU), a nie ANE. Brak sensownej ścieżki dostarczania na iOS: technicznie da się go osadzić, lecz dystrybucja wag, kwestie cieplne i wytyczne recenzji czynią z niego niewłaściwe narzędzie; MLX jest dla własnego Maca, Maców użytkowników i pętli badawczej. Nikt też nie zarządza wykonaniem za nikogo: presja pamięci, wybory kwantyzacji i planowanie ewaluacji pozostają po stronie autora. Filar poświęcony MLX omawia, kiedy „własny model, a nie model Apple” jest wart tej odpowiedzialności.

Warto wybrać wtedy, gdy: trwa trenowanie lub dostrajanie, lokalne uruchamianie LLM o otwartych wagach albo budowa natywnych narzędzi na Maca, w których kontrola nad modelem jest produktem. Jeśli codzienną maszyną jest Mac na Apple silicon z realną ilością RAM, MLX zamienia go w pełnoprawną stację roboczą ML.

Core AI: nowy fundament

iOS 27 dodał warstwę, której Apple brakowało: Core AI, niskopoziomowy framework wykonywania modeli z tensorami NDArray, rozdziałem na asset i model, jawnym wskazywaniem jednostek obliczeniowych oraz wywoływalnymi funkcjami inferencji.⁷ Sięga się po niego wtedy, gdy kontrakt Core ML w postaci „podaj skompilowany model, odbierz predykcje” okazuje się zbyt sztywny: potoki przeplatające arytmetykę tensorową z wywołaniami modelu, własne przetwarzanie wstępne i końcowe, którego miejsce jest na ANE, wielomodelowe grafy ze współdzielonymi buforami.

Dwa doprecyzowania oszczędzają większości czytelników błędnego skrętu. Core AI nie jest alternatywą dla Foundation Models (na tej warstwie wciąż nie ma wbudowanego LLM; skompilowane assety trzeba przynieść ze sobą). I nie jest to MLX na iOS: żadnego trenowania, żadnego autogradu, żadnej zachłannej pętli badawczej. To maszynownia Core ML z otwartym włazem. Komu nigdy nie doskwierała abstrakcja Core ML, ten Core AI nie potrzebuje; kto raz dostarczył akrobacje na MLMultiArray albo łańcuchował modele przez zbędne konwersje, potrzebuje go już teraz. Model tensorów i API wskazywania jednostek omawia filar poświęcony Core AI.

Przypadki, o które naprawdę trwają spory

„Potrzebujemy LLM, ale własnego albo większego”. Foundation Models nie potrafi wczytać zewnętrznych wag, kropka. Mały destylowany LLM przez Core ML działa i daje dostęp do ANE; skwantyzowany otwarty model przez MLX działa na Macu. Warto szczerze nazwać alternatywę, której nikt w obozie przetwarzania na urządzeniu nie chce wypowiedzieć na głos: jeśli zadanie wymaga jakości klasy frontier, odpowiedzią jest wywołanie serwera, a warstwy działające na urządzeniu obsługują awaryjne ścieżki i podzbiory wrażliwe na prywatność.

„Chcemy jednego stosu na iPhone’a i Maca”. Foundation Models i Core ML są wieloplatformowe w obrębie ekosystemu Apple; MLX w praktyce pozostaje wyłącznie na Macu. Zespoły dostarczające profesjonalną aplikację na Maca wraz z towarzyszącą aplikacją na iOS zwykle lądują z MLX na Macu (duże modele, wagi dostarczone przez użytkownika) oraz Core ML lub Foundation Models na iOS: ta sama funkcja, dwa silniki i jedno uczciwe przyznanie, że urządzenia się różnią.

„Mamy już potok na Core ML; czy Core AI jest celem migracji?” Tylko tam, gdzie potok boli. Core AI wchłania krawędzie o naturze tensorowej; rdzeń oparty na skompilowanym modelu, który działa dzisiaj, działa nadal. Hurtowa migracja zdrowego wdrożenia Core ML nie kupuje niczego.

„Czy SwiftData albo App Intents cokolwiek tu zmieniają?” Są sąsiednie, nie nakładają się: warstwa modeli zasila funkcje, które App Intents udostępnia systemowi, a wszystko, co zostaje utrwalone, podlega regułom schematu SwiftData. Omawiane tu frameworki rozstrzygają, jak przebiega inferencja, a nie jak zbudowana jest otaczająca ją aplikacja.

Drzewo decyzyjne

Is the task language-shaped and within a ~3B generalist's reach?
├── YES → Foundation Models. Ship zero weights. Done.
└── NO → Whose weights?
    ├── Apple's, but specialized → Foundation Models + trained adapter
    │     (accept: retrain per base-model rev)
    └── Yours →  Where does it run?
        ├── iOS/iPadOS app → Core ML
        │     └── unless you need tensor-level control → Core AI (iOS 27+)
        ├── Mac, models-as-product / training / open weights → MLX
        └── Frontier-quality required → server, with on-device fallback

Najważniejsze wnioski

Dla zespołów aplikacyjnych dostarczających funkcje: - Prototyp warto zbudować najpierw na Foundation Models; sześć linijek kodu Swift to najtańszy możliwy eksperyment, a „wbudowany model wystarcza” to najczęstsza niespodzianka. - Czas konwersji do Core ML należy budżetować osobno od czasu inferencji; to pokrycie operatorów i kwantyzacja pochłaniają tygodnie.

Dla inżynierów ML: - Mac na Apple silicon z 64GB+ to realne stanowisko do fine-tuningu pod MLX; warto zmierzyć, zanim wynajmie się GPU w chmurze. Przytoczone wyżej wartości 11.2 TFLOPS / 351 GB/s pochodzą z układu laptopowego sprzed dwóch generacji.¹ - ANE pozostaje przewagą Core ML, a teraz również Core AI. Jeśli liczy się pobór energii na jedną inferencję, żadna ścieżka przez GPU nie dorównuje.

Dla architektów: - Te cztery frameworki należy traktować jak warstwy, a nie rywali: Foundation Models do funkcji językowych, Core ML do dostarczanych modeli własnych, Core AI do krawędzi tensorowych, MLX na Maca i do laboratorium. Wdrożenia mieszane są normą w poważnych aplikacjach, a nie sygnałem ostrzegawczym. - Własność modelu to długoterminowe centrum kosztów: wagi Foundation Models utrzymuje Apple, wszystkie pozostałe trzeba utrzymywać samodzielnie. Warto wliczyć to w cenę wyboru.

Często zadawane pytania

Którego frameworka Apple użyć do uruchomienia modelu na urządzeniu?

Decyzja zwykle sprowadza się do jednego pytania. Model wbudowany: Foundation Models; własny model na iOS: Core ML; własny model na własnym Macu: MLX; kontrola na poziomie tensorów na iOS: Core AI. Wystarczy nanieść funkcję na dwie osie, czyje wagi uruchamia i kto odpowiada za wykonanie, a framework wybierze się sam. Całą czwórkę warto traktować jak warstwy, a nie rywali; wdrożenia mieszane są normą w poważnych aplikacjach.

Czy Foundation Models może uruchomić własne wagi modelu?

Nie. Foundation Models uruchamia wyłącznie wbudowany model Apple działający na urządzeniu, generalistę o mniej więcej 3B parametrów, oraz własne adaptery w stylu LoRA. Nie potrafi wczytać zewnętrznych wag, kropka. Gdy potrzebny jest własny LLM, mały destylowany model przez Core ML działa i daje dostęp do Neural Engine, a skwantyzowany otwarty model przez MLX działa na Macu. Jeśli zadanie wymaga jakości klasy frontier, odpowiedzią jest wywołanie serwera.⁵

Czy można dostarczyć MLX wewnątrz aplikacji iOS?

Realnie nie. MLX jest otwartoźródłowym frameworkiem tablicowym z grupy badawczej ML w Apple, a nie frameworkiem systemowym, programuje GPU i CPU bez jakiegokolwiek dostępu do Neural Engine, a dystrybucja wag, kwestie cieplne i wytyczne recenzji czynią z niego niewłaściwe narzędzie do pakietu iOS. MLX jest dla własnego Maca, Maców użytkowników i pętli badawczej.⁴

Czym różni się Core ML od Core AI?

Core ML to inferencja z kompilacją z wyprzedzeniem: przekazuje się skompilowany .mlmodelc, sugeruje jednostki obliczeniowe, a framework decyduje o rozdziale zadań. Core AI, dodane w iOS 27, to ta sama maszynownia z otwartym włazem: tensory NDArray, rozdział na asset i model oraz jawne wskazywanie jednostek obliczeniowych. Nadal nie prowadzi trenowania i nie dostarcza wbudowanego LLM. Komu nigdy nie doskwierała abstrakcja Core ML, ten go nie potrzebuje.⁷

Jak szybki jest M2 Max w lokalnym uczeniu maszynowym?

Na M2 Max, na którym powstaje ten tekst, MLX utrzymuje 11.2 TFLOPS mnożenia macierzy fp16 przy 4096×4096 oraz 351 GB/s zmierzonej przepustowości strumieniowej, bez jakiegokolwiek strojenia. To wystarcza, aby interaktywnie uruchamiać skwantyzowane modele o otwartych wagach i 30B parametrów oraz dostrajać modele 7B z użyciem LoRA przez jedną noc. Warto zmierzyć, zanim wynajmie się GPU w chmurze; te liczby pochodzą z układu laptopowego sprzed dwóch generacji.¹

Źródła