Inferencja Core ML na urządzeniu: wzorce, które naprawdę trafiają na produkcję

Core ML to silnik inferencji na urządzeniu, dostarczany z każdym nowoczesnym urządzeniem Apple. Framework kieruje obliczenia na Neural Engine, gdy jest dostępny, na GPU, gdy go nie ma, a na CPU w ostateczności, wybierając najszybszą ścieżkę automatycznie na podstawie modelu i sprzętu¹. Na współczesnym iPhonie daje to inferencję o opóźnieniu od ułamka milisekundy do kilkudziesięciu milisekund dla większości produkcyjnych rozmiarów modeli, bezpłatnie przy każdym wywołaniu, bez podróży do sieci i bez ujawniania danych podmiotom trzecim.

Opinia o frameworku jako „niszowej instalacji hydraulicznej” jest już nieaktualna. Core ML od blisko dekady napędza funkcje działające na urządzeniu, od wyszukiwania semantycznego w Zdjęciach po większość aplikacji zewnętrznych korzystających z lokalnego ML, i pozostaje produkcyjną warstwą dla stałego, skonwertowanego modelu w każdym systemie aż do iOS 11. Jego pozycja w stosie zmieniła się jednak na WWDC 2026: Apple przedstawiło Core AI jako niskopoziomowy framework napędzający Apple Intelligence na urządzeniu i wskazało go jako kierunek dla nowych prac nad sieciami neuronowymi¹¹¹². Wzorce, dzięki którym wdrożenie Core ML naprawdę trafia na produkcję, zamiast działać wyłącznie „na moim Macu”, pozostały bez zmian i wciąż tworzą niewielki zbiór: konwersja modelu, sterowanie przydziałem, budżetowanie opóźnień i kwantyzacja. Ten artykuł omawia każdy z nich w zestawieniu z dokumentacją Apple, a następnie umieszcza Core ML w stosie po WWDC26.

TL;DR

• Core ML uruchamia pliki .mlpackage i .mlmodel na Neural Engine, GPU i CPU układów Apple Silicon. Przydział jest automatyczny, ale można nim sterować przez MLModelConfiguration.computeUnits².
• Konwersja modelu odbywa się przez coremltools (PyTorch, TensorFlow, ONNX → Core ML). Konwersja to zadanie narzędziowe, nie zadanie czasu wykonania; gdy model jest już skonwertowany i dołączony do pakietu, aplikacja go ładuje i uruchamia.
• Architektura pamięci współdzielonej w Apple Silicon oznacza, że wagi modelu nie są kopiowane pomiędzy CPU, GPU i NE: ta sama pamięć obsługuje wszystkie trzy jednostki³. Właśnie ten szczegół architektury umożliwia inferencję poniżej milisekundy.
• Kwantyzacja (INT8, INT4 w nowszych wersjach Core ML) zmniejsza rozmiar modelu i przyspiesza inferencję na Neural Engine, kosztem mierzalnego spadku dokładności, który zależy od modelu. coremltools 9.0 (listopad 2025) dodaje cele wdrożenia dla iOS 26, odczyt i zapis stanu modelu oraz wejścia i wyjścia modelu w int8¹³.
• Stos zmienił się na WWDC 2026: Apple pozycjonuje Core AI jako framework inferencyjny stojący za Apple Intelligence na urządzeniu oraz jako warstwę dla nowych prac nad sieciami neuronowymi, podczas gdy Core ML pozostaje warstwą produkcyjną dla stałych, skonwertowanych modeli i klasycznego ML¹¹¹².

Model myślowy: trzy ścieżki obliczeń, jedna pamięć

Apple Silicon (Maki z serii M i iPhone’y z serii A od układu A12 Bionic) udostępnia trzy cele inferencji:

Neural Engine. Wyspecjalizowany akcelerator mnożenia macierzy przy niskiej precyzji. Najszybszy dla operacji, od których zależą współczesne modele ML (sploty, attention, embeddingi). Najniższy pobór mocy. Ograniczony do określonych typów operacji i kształtów tensorów; operacje nieobsługiwane są przenoszone warstwa po warstwie na GPU lub CPU.

GPU. Ogólnego przeznaczenia obliczenia równoległe przez Metal. Wolniejsze niż Neural Engine przy pracy o charakterze ML, ale szybsze niż CPU. Obsługuje operacje, których Neural Engine nie wspiera.

CPU. Ścieżka zapasowa. Wolna dla inferencji ML, ale zawsze dostępna, zawsze obsługująca każdą operację i przewidywalna.

Architektura pamięci współdzielonej oznacza, że ta sama fizyczna pamięć RAM obsługuje wszystkie trzy jednostki³. Wagi modelu, raz wczytane, nie są kopiowane, gdy przydział przenosi się między celami. Właśnie ten fakt architektoniczny zamienia przydział na wiele celów: zamiast kosztu kopiowania na warstwę pozostaje decyzja o szeregowaniu na warstwę.

Przydziałem steruje MLModelConfiguration.computeUnits:

let config = MLModelConfiguration()
config.computeUnits = .all          // default: NE, GPU, CPU
// Other options:
// .cpuAndGPU
// .cpuAndNeuralEngine
// .cpuOnly
let model = try MyModel(configuration: config)

.all jest wartością domyślną i właściwym wyborem dla niemal każdej aplikacji. Framework wybiera najszybszą ścieżkę dla każdej operacji z osobna, a taka decyzja jest lepsza niż jakakolwiek heurystyka napisana ręcznie przez programistę. Rzadkim powodem, by ją nadpisać, jest wymuszenie .cpuOnly dla zgodności testów (model zachowuje się różnie na różnych ścieżkach, a test wymaga ścieżki deterministycznej) albo wymuszenie .cpuAndGPU, aby zwolnić Neural Engine na potrzeby innego, równoległego zadania.

Konwersja modelu: zadanie narzędziowe

Większość modeli ML jest trenowana w PyTorch, w TensorFlow albo bezpośrednio w Create ML od Apple. Core ML przyjmuje pliki .mlpackage, czyli nowoczesny format wprowadzony w Xcode 13, który zastępuje starszy .mlmodel⁴. Konwersja odbywa się przez coremltools, otwartoźródłowy pakiet Pythona przygotowany przez Apple⁵.

Typowa konwersja z PyTorch do Core ML przebiega w trzech krokach:

1. Wczytanie wytrenowanego modelu PyTorch i przełączenie go w tryb inferencji.
2. Prześledzenie modelu przykładowym tensorem wejściowym o kształcie zgodnym z wejściem produkcyjnym.
3. Konwersja prześledzonego modelu przy użyciu coremltools względem docelowej wersji iOS.

import torch
import coremltools as ct

model = MyTrainedModel()
model.load_state_dict(torch.load("weights.pth"))

example_input = torch.rand(1, 3, 224, 224)
traced_model = torch.jit.trace(model, example_input)

mlmodel = ct.convert(
    traced_model,
    inputs=[ct.ImageType(name="image", shape=example_input.shape)],
    minimum_deployment_target=ct.target.iOS26,
    compute_units=ct.ComputeUnit.ALL,
)
mlmodel.save("MyModel.mlpackage")

Konwersja odbywa się jednorazowo, w środowisku deweloperskim, względem docelowej wersji iOS (minimum_deployment_target). Powstały plik .mlpackage trafia następnie do projektu Xcode. Aplikacja w czasie wykonania nie uruchamia coremltools. Bieżące wydanie, coremltools 9.0, dodaje cele wdrożenia aż do iOS 26, możliwość odczytu i zapisu stanu modelu (dla modeli ze stanem, takich jak dekodery transformerów z pamięcią KV), wejścia i wyjścia modelu w int8 oraz obsługę Pythona 3.13 i PyTorch 2.7¹³.

W konwersji czyhają dwie praktyczne pułapki. Po pierwsze, wejścia o dynamicznym kształcie wymagają jawnej obsługi przez ct.RangeDim, ponieważ domyślne założenie statycznego kształtu w Core ML daje mało pomocne błędy, gdy aplikacja produkcyjna podaje zmienne rozmiary wejścia. Po drugie, własne operacje w PyTorch, które nie mają odpowiednika w Core ML, wymagają albo własnej warstwy Core ML (kodu Swift wykonującego brakującą operację), albo zmiany architektury modelu, która usuwa tę operację przed konwersją. Oba przypadki są dobrze udokumentowane⁵.

Budżety opóźnień, które faktycznie obowiązują

Dla aplikacji trafiających na produkcję liczą się trzy budżety opóźnień:

16 ms (interfejs na żywo, 60 fps). Filtr aparatu w czasie rzeczywistym, scena AR odświeżana co klatkę, analizator dźwięku na żywo. Budżet obejmuje wszystko: wstępne przetwarzanie obrazu, inferencję modelu, przetwarzanie końcowe i aktualizację interfejsu. Modele, które się w nim mieszczą, są zwykle małe (klasa MobileNetV3, poniżej 100 mln parametrów) i działają na Neural Engine.

100 ms (interfejs interaktywny). Użytkownik wykonuje akcję i czeka na wynik: dotknięcie w celu rozpoznania, rysunek w celu identyfikacji, dyktowanie w celu transkrypcji. Budżet jest łagodniejszy i obsługuje większe modele. Modele językowe poniżej miliarda parametrów, małe transformery wizyjne i większość klasyfikatorów klasy produkcyjnej mieszczą się w nim swobodnie.

1 s i więcej (praca w tle lub wsadowa). Indeksowanie biblioteki zdjęć, analiza dokumentów, rozgrzewanie modelu przy starcie aplikacji. Większe modele działają, ale oczekiwania użytkownika trzeba ustawić wskaźnikiem postępu. Model językowy Foundation Models działający na urządzeniu mieści się tutaj przy operacjach z większym oknem kontekstu.

Te budżety są wskazówkami, a nie sztywnymi limitami. Właściwym krokiem jest pomiar na urządzeniu docelowym przy użyciu os_signpost albo szablonu Core ML w Instruments⁶, zamiast polegania na teoretycznych liczbach z innej maszyny.

Kwantyzacja: kiedy mniejsze znaczy szybsze

Core ML obsługuje kilka poziomów kwantyzacji⁷:

• Float32 (pełna precyzja). Domyślny format treningu. Największy, najdokładniejszy, najwolniejszy.
• Float16. Połowiczna precyzja. Mniejszy i szybszy na GPU oraz NE; utrata dokładności jest zwykle pomijalna dla dobrze uwarunkowanych modeli.
• INT8. Kwantyzacja całkowitoliczbowa 8-bitowa z kalibracją. Około 4x mniejszy niż Float32, często 2-4x szybszy na NE. Utrata dokładności bywa różna; w modelach wizyjnych spadek dokładności top-1 poniżej 1 % jest osiągalny przy treningu uwzględniającym kwantyzację.
• INT4 i niżej. Agresywna kwantyzacja, którą nowsze wersje Core ML obsługują dla wybranych architektur (modele językowe, duże modele wizyjne). Ceną jest znaczna utrata dokładności; technika działa najlepiej w połączeniu z treningiem uwzględniającym kwantyzację i dopasowanym do modelu.

Konfiguracja kwantyzacji liniowej przez coremltools.optimize.coreml.linear_quantize_weights przyjmuje globalną konfigurację operacji, która wybiera tryb kwantyzacji (linear_symmetric lub linear), oraz próg rozmiaru wag, poniżej którego wagi pozostają w pełnej precyzji. Konwersja działa na istniejącym pliku .mlpackage i tworzy nowy, skwantyzowany pakiet; oba mogą trafić obok siebie do pakietu aplikacji, a aplikacja wybiera, który wczytać, na podstawie klasy urządzenia.

Decyzja o kwantyzacji zapada osobno dla każdego modelu: mały klasyfikator może nic nie zyskać, bo jego obliczenia i tak są tanie; duży model językowy zyskuje ogromnie, bo w jego obliczeniach dominują mnożenia macierzy na skwantyzowanych wagach. Właściwe podejście to skwantyzować, zmierzyć dokładność na odłożonym zbiorze testowym i wydać, jeśli spadek dokładności jest akceptowalny dla danego zastosowania.

Wbudowane modele Apple, które można wykorzystać od ręki

Apple udostępnia kilka wstępnie wytrenowanych modeli Core ML na stronie Core ML Models⁸. Kategorie, które warto znać:

• Klasyfikacja obrazów: MobileNetV2, ResNet50, warianty SqueezeNet, wszystkie gotowe do wstawienia w VNCoreMLRequest frameworka Vision.
• Wykrywanie obiektów: YOLOv3, MNIST, warianty CenterNet.
• Szacowanie pozy: PoseNet dla pozy ciała (bazowa alternatywa wobec VNDetectHumanBodyPoseRequest z Vision).
• Segmentacja semantyczna: DeepLabV3 do segmentacji obrazu.
• Rozpoznawanie tekstu: alternatywy OCR oparte na ML wobec rozwiązania wbudowanego w Vision.

W większości aplikacji wstępnie wytrenowane modele Apple pokrywają prymitywy percepcji (klasyfikacja, wykrywanie, segmentacja) bez potrzeby własnego treningu. W zadaniach językowych systemowy model językowy działający na urządzeniu leży w całości ponad tą warstwą: framework Foundation Models udostępnia go za wysokopoziomowym API Swifta, offline i bezpłatnie, bez pliku modelu, który trzeba by dołączać lub konwertować.

Szyfrowanie modelu i kwestie związane z App Store

Plik .mlpackage w pakiecie aplikacji może odczytać każdy, kto rozpakuje archiwum IPA. Dla modeli stanowiących istotną własność intelektualną Apple wspiera szyfrowanie modelu poprzez procedurę Encrypt your Core ML model⁹: klucz szyfrujący jest generowany w Xcode i zarządzany przez CloudKit, model w pakiecie jest zaszyfrowany, a Core ML odszyfrowuje go w czasie wczytywania.

W większości aplikacji szyfrowanie to przesada. Model wytrenowany na powszechnie dostępnych danych ImageNet nie jest wyróżnikiem konkurencyjnym; jego szyfrowanie zwiększa złożoność operacyjną, nie chroniąc niczego wartościowego. Szyfrowanie warto zarezerwować dla modeli, w których tkwi realna inwestycja w dane treningowe albo przewaga konkurencyjna.

Prywatność na urządzeniu: architektoniczna wygrana

Kwestia prywatności jest tu prosta. Inferencja Core ML odbywa się w całości na urządzeniu. Dane wejściowe (obrazy, dźwięk, tekst) nie opuszczają urządzenia. Plik modelu jest lokalny, inferencja jest lokalna, wynik jest lokalny.

W aplikacjach z branż regulowanych (zdrowie, finanse, edukacja) ten fakt architektoniczny eliminuje całą klasę prac związanych ze zgodnością. Nie ma zewnętrznego podmiotu przetwarzającego dane, którego trzeba by dopisać do polityki prywatności. Nie ma punktu końcowego API modelu, który trzeba by prześwietlić pod kątem bezpieczeństwa. Nie ma pytania o miejsce przechowywania danych, bo dane nigdy się nie przemieszczają.

Format Privacy Manifest¹⁰ zapisuje tę kwestię prywatności na potrzeby zgłoszenia do App Store: aplikacja, która używa Core ML wyłącznie do inferencji na urządzeniu, może zadeklarować zerowe udostępnianie danych podmiotom trzecim dla ścieżki inferencji. Proces zgłoszenia jest szybszy, przegląd prywatności krótszy, a widoczna dla użytkownika etykieta prywatności czystsza.

Powiązanie z przepływem pracy agentów

Core ML łączy się z trzema wzorcami, które ten cykl artykułów już opisał:

VNCoreMLRequest z frameworka Vision. Własne modele Core ML przechodzą przez potok Vision z automatycznym wstępnym przetwarzaniem. Ten wzorzec (opisany w artykule Vision Framework) to właściwy sposób na wydanie własnego klasyfikatora lub detektora obrazu w aplikacji iOS.

Model językowy Foundation Models na urządzeniu. Systemowy model językowy Apple Intelligence leży za frameworkiem Foundation Models, a od WWDC 2026 Apple wskazuje Core AI jako framework inferencyjny, który go napędza¹¹. Pojęcia z tego artykułu wciąż przenoszą się wprost: przydział jednostek obliczeniowych, skwantyzowane wagi i budżety opóźnień rządzą systemowym modelem językowym tak samo, jak rządzą modelem skonwertowanym samodzielnie. Artykuł o frameworku opisuje API modelu językowego; ten artykuł opisuje leżące pod spodem wzorce inferencji.

Narzędzia App Intents korzystające z lokalnego ML. Obiekt AppIntent, który uruchamia lokalny klasyfikator obrazu lub tekstu, zwraca ustrukturyzowane wyniki do Apple Intelligence bez podróży do sieci. To właśnie takie połączenie sprawia, że „agentowe Apple” jest naprawdę prywatne: narzędzia agenta działają lokalnie, bo framework na to pozwala.

Kiedy inferencja w chmurze jest słusznym wyborem

Sufitem Core ML jest moc obliczeniowa urządzenia. Trzy przypadki, w których chmura ma rację bytu:

Modele zbyt duże, by dołączyć je do pakietu. Model językowy o 70 mld parametrów nie zmieści się w pakiecie aplikacji. Dla obciążeń tej skali właściwym narzędziem jest inferencja w chmurze (albo praca na urządzeniu ze strumieniowanymi wagami, co jest osobnym wzorcem).

Współdzielony stan między urządzeniami w trakcie inferencji. Modele, które w trakcie inferencji muszą czytać ze wspólnej bazy danych lub do niej zapisywać (systemy rekomendacyjne z filtrowaniem kolaboratywnym na miliardach rekordów). Czysto lokalny model Core ML tu nie pasuje.

Szybka iteracja modelu. Zespół wydający aktualizacje modelu codziennie zyskuje na inferencji po stronie serwera, bo wdrożenia nie wymagają cykli przeglądu w App Store. Wzorzec Core ML, czyli dołączanie modelu do aplikacji, wprowadza tarcie w rytm kolejnych wersji modelu; ten kompromis jest realny.

Wzorzec wygląda tak: chmura wygrywa skalą i tempem iteracji, Core ML wygrywa opóźnieniem, kosztem i prywatnością.

Miejsce Core ML po WWDC 2026

WWDC 2026 przerysowała mapę pod tym artykułem, nie unieważniając go. Apple przedstawiło Core AI, framework dla iOS 27, którego opis brzmi „Run AI models in your app on Apple silicon”, i stwierdziło w sesji 324, że Core AI jest frameworkiem inferencyjnym napędzającym Apple Intelligence na urządzeniu, otwartym teraz dla aplikacji zewnętrznych¹¹. Tam gdzie konwerter Core ML podejmuje decyzje o sprzęcie i optymalizacji za programistę, Core AI oddaje mu dźwignie do ręki: jawną specjalizację modelu, zarządzaną pamięć podręczną artefaktów, wskazywanie jednostek obliczeniowych i asynchroniczne strumienie obliczeń. Pełna analiza znajduje się w artykule Core AI: uruchamianie modeli na Apple silicon.

Sygnał co do kierunku jest silniejszy, niż sugeruje sama dokumentacja. Podczas grupowego labu poświęconego uczeniu maszynowemu na WWDC 2026 inżynier pracujący nad Core AI 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 klasycznym uczeniu maszynowym, takim jak drzewa decyzyjne¹². To zdanie jest parafrazą z labu, a nie opublikowaną polityką, ale odpowiada kształtowi tego wydania: Core AI dostało nowe narzędzia, nowe formaty i obciążenie Apple Intelligence.

Praktyczny wniosek dla aplikacji wydawanej dzisiaj:

• Istniejące wdrożenia Core ML działają dalej. Nic w iOS 27 nie oznacza ścieżki .mlpackage jako przestarzałej, a coremltools 9.0 przyniosło nowe możliwości (cele iOS 26, modele ze stanem, wejścia i wyjścia int8) jeszcze w listopadzie 2025¹³.
• Core ML pozostaje jedyną opcją poniżej iOS 27 i opcją pragmatyczną dla stałego, skonwertowanego modelu, gdy domyślne ustawienia konwertera są dokładnie tym, czego się oczekuje.
• Nowe prace nad sieciami neuronowymi celujące w iOS 27 i nowsze powinny najpierw rozważyć Core AI, zwłaszcza tam, gdzie da się nazwać potrzebną specjalizację, buforowanie albo kontrolę nad szeregowaniem.
• Pozostałe warstwy się nie przesuwają. Systemowy model językowy zostaje za Foundation Models, a MLX pozostaje osadzalnym frameworkiem tablicowym dla modeli o otwartych wagach i własnych dostrojeń. Core ML kontra Core AI to pytanie o warstwę wykonania modelu, a nie o tamte rozwiązania.

Co ten wzorzec oznacza dla aplikacji na iOS 26 i nowsze

Trzy wnioski.

1. Domyślnie warto wybierać Core ML dla każdego modelu, który mieści się w pakiecie i zwraca w jednym wywołaniu wynik, na którym użytkownik może działać. Klasyfikacja obrazów, wykrywanie obiektów, klasyfikacja dźwięku, rozpoznawanie gestów, generowanie embeddingów, małe i średnie zadania językowe. Automatyczny przydział we frameworku oraz układ NPU w Apple Silicon dają za darmo inferencję od ułamka milisekundy do kilkudziesięciu milisekund.

2. Warto kwantyzować agresywnie, dopóki spadek dokładności pozostaje akceptowalny. INT8 jest zwykle bezpieczny; INT4 nadaje się do dużych modeli, w których liczy się oszczędność rozmiaru. Dokładność należy zmierzyć na odłożonym zbiorze, zamiast zakładać, że kwantyzacja jest bezpieczna zawsze.

3. Warto łączyć Core ML z Vision i Foundation Models w pełni lokalne potoki. Core ML jest silnikiem, Vision jest leżącym nad nim API percepcji, a Foundation Models jest leżącym nad nim modelem językowym. Artykuł o Vision oraz artykuł o Foundation Models z tego cyklu opisują warstwy wyższego poziomu.

Pełny cykl o ekosystemie Apple: typowane App Intents; serwery MCP; pytanie o routing; Foundation Models; rozróżnienie między modelem językowym czasu wykonania a narzędziowym; trzy warstwy styku; wzorzec jednego źródła prawdy; Dwa serwery MCP; hooki w programowaniu dla Apple; Live Activities; kontrakt czasu wykonania w watchOS; wnętrzności SwiftUI; przestrzenny model myślowy RealityKit; dyscyplina schematu w SwiftData; wzorce Liquid Glass; wydawanie na wiele platform; macierz platform; framework Vision; Symbol Effects; o czym odmawiam pisać. Węzłem całości jest seria o ekosystemie Apple. Szerszy kontekst iOS z agentami AI opisuje przewodnik po tworzeniu agentów na iOS.

Często zadawane pytania

Jak Core ML wybiera pomiędzy Neural Engine, GPU i CPU?

Core ML analizuje każdą operację w grafie modelu i kieruje ją do najszybszego celu, który tę operację obsługuje. Neural Engine obsługuje wspierane operacje (większość mnożeń macierzy, sploty, attention) przy najniższym opóźnieniu i poborze mocy. GPU obsługuje operacje, których NE nie wspiera. CPU obsługuje resztę. Decyzja zapada dla każdej operacji osobno, automatycznie, i jest lepsza niż ręcznie napisana heurystyka.

Czy zawsze należy używać .computeUnits = .all?

Prawie zawsze. Automatyczny przydział we frameworku jest dobrze dostrojony. Warto przełączyć na .cpuOnly przy testowaniu zgodności wyników (ten sam model zwraca nieco inne rezultaty na NE i na CPU z powodu zaokrągleń zmiennoprzecinkowych) albo na .cpuAndGPU, aby zwolnić Neural Engine na potrzeby równoległego zadania.

Jaka jest praktyczna różnica między .mlpackage a .mlmodel?

.mlpackage to nowoczesny format wprowadzony w Xcode 13. Obsługuje przechowywane metadane, wiele wariantów modelu dla kompilacji ML Program (mlprogram) oraz łańcuch narzędzi z okresu po iOS 13. .mlmodel to format starszy. Oba nadal wczytują się przez MLModel; nowe prace powinny korzystać z .mlpackage.

Jak duży może być model Core ML w pakiecie aplikacji?

Nie ma sztywnego limitu, ale rozmiar pakietów w App Store jest ograniczony do 4 GB przy pobieraniu i ma praktyczne granice przy instalacji bezprzewodowej. Systemowy model językowy działający na urządzeniu całkowicie omija to pytanie: rozprowadza go system operacyjny, a aplikacje sięgają po niego przez Foundation Models bez dołączania czegokolwiek. Dla modeli dołączanych do aplikacji poniżej 100 MB jest wygodne; od 100 do 500 MB jest wykonalne przy strategii wczytywania w czasie startu; powyżej 500 MB najlepiej sięgnąć po pobieranie w tle przez BGProcessingTask albo po zasoby na żądanie.

Czy dla nowego modelu wybrać Core ML czy Core AI?

Poniżej iOS 27 Core ML jest jedyną opcją. W iOS 27 i nowszych deklarowanym kierunkiem Apple jest Core AI dla sieci neuronowych, przy czym Core ML pozostaje dla klasycznego uczenia maszynowego i istniejących wdrożeń¹¹¹². Jeśli model jest stały, skonwertowany, a domyślne ustawienia konwertera wystarczają, Core ML nadal doskonale się sprawdza; jeśli potrzebna jest jawna kontrola nad specjalizacją, buforowaniem albo szeregowaniem, właśnie po to istnieje Core AI.

Skąd wiadomo, czy kwantyzacja pogorszyła dokładność modelu?

Należy odłożyć zbiór testowy, uruchomić inferencję na pierwotnym modelu Float32 i na modelu skwantyzowanym, porównać metryki (dokładność top-1 dla klasyfikatorów, F1 dla detektorów, perplexity dla modeli językowych, BLEU dla tłumaczenia i tak dalej), a następnie zdecydować na podstawie wymagań dokładności danego zastosowania. Trening uwzględniający kwantyzację (trenowanie modelu z symulowaną kwantyzacją w funkcji straty) zwykle odzyskuje większość utraconej dokładności.

Źródła