Core ML – inferencja na urządzeniu: wzorce, które naprawdę trafiają do produkcji

Core ML to silnik inferencji na urządzeniu, który jest dostarczany z każdym nowoczesnym urządzeniem Apple. Framework kieruje obliczenia do Neural Engine, gdy jest dostępny, do GPU, gdy nie jest, oraz do CPU jako ostateczność, automatycznie wybierając najszybszą ścieżkę na podstawie modelu i sprzętu¹. Rezultatem na nowszym iPhonie jest inferencja o opóźnieniu od poniżej milisekundy do kilkudziesięciu milisekund dla większości produkcyjnych rozmiarów modeli, bez kosztu za wywołanie, bez podróży sieciowej i bez ujawniania danych podmiotom trzecim.

Reputacja frameworka jako „nieczytelnej hydrauliki” jest nieaktualna. Core ML zasila obecnie LLM Apple Intelligence działający na urządzeniu, wyszukiwanie semantyczne w aplikacji Zdjęcia, rozpoznawanie scen w aplikacji Aparat oraz większość zewnętrznych aplikacji, które dostarczają lokalne ML. Wzorce, dzięki którym wdrożenie Core ML faktycznie trafia do produkcji, a nie tylko działa-na-moim-Macu, to niewielki zestaw: konwersja modelu, sterowanie dyspozycją, budżetowanie opóźnień i kwantyzacja. Wpis omawia każdy z nich w odniesieniu do dokumentacji Apple.

TL;DR

• Core ML uruchamia pliki .mlpackage i .mlmodel na Neural Engine, GPU i CPU procesorów Apple Silicon. Dyspozycja jest automatyczna, ale można ją sterować przez MLModelConfiguration.computeUnits².
• Konwersja modelu odbywa się przez coremltools (PyTorch, TensorFlow, ONNX → Core ML). Konwersja to zadanie narzędziowe, a nie zadanie czasu wykonania; po skonwertowaniu modelu i dołączeniu go do pakietu aplikacja go ładuje i uruchamia.
• Architektura zunifikowanej pamięci Apple Silicon oznacza, że wagi modelu nie są kopiowane między CPU, GPU a NE; ta sama pamięć obsługuje wszystkie trzy³. Ten szczegół architektoniczny umożliwia inferencję poniżej milisekundy.
• Kwantyzacja (INT8, INT4 w nowszych wersjach Core ML) zmniejsza rozmiar modelu i przyspiesza inferencję na Neural Engine, z mierzalnym kosztem dokładności zależnym od modelu.
• Powiązanie z przepływem agentów: Foundation Models (LLM Apple Intelligence działający na urządzeniu) jest dostarczany jako model Core ML za wysokopoziomowym API Swift; mają zastosowanie te same wzorce dyspozycji i kwantyzacji.

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

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

Neural Engine. Wyspecjalizowany akcelerator do mnożenia macierzy w niskiej precyzji. Najszybszy dla operacji, na których opierają się nowoczesne modele ML (sploty, atencja, embeddingi). Najniższe zużycie energii. Ograniczony do określonych typów operacji i kształtów tensorów; nieobsługiwane operacje są przekazywane do GPU lub CPU warstwa po warstwie.

GPU. Ogólnoprzeznaczeniowe obliczenia równoległe poprzez Metal. Wolniejsze niż Neural Engine dla pracy o kształcie ML, ale szybsze niż CPU. Obsługuje operacje, których Neural Engine nie wspiera.

CPU. Rozwiązanie awaryjne. Powolne dla inferencji ML, ale zawsze dostępne, zawsze obsługujące każdą operację i przewidywalne.

Architektura zunifikowanej pamięci oznacza, że ta sama fizyczna pamięć RAM obsługuje wszystkie trzy³. Wagi modelu, raz załadowane, nie są kopiowane, gdy dyspozycja przesuwa się między celami. Ten fakt architektoniczny zamienia dyspozycję wielocelową z kosztu kopiowania per-warstwa w decyzję planistyczną per-warstwa.

MLModelConfiguration.computeUnits steruje dyspozycją:

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, a decyzja per-operacja jest szybsza niż jakakolwiek heurystyka, którą napisałby programista. Rzadkim powodem nadpisania jest wymuszenie .cpuOnly do testowania spójności wyników (model zachowuje się inaczej na różnych ścieżkach, a test wymaga ścieżki deterministycznej) lub wymuszenie .cpuAndGPU, aby zwolnić Neural Engine dla innego zadania współbieżnego.

Konwersja modelu: zadanie narzędziowe

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

Typowa konwersja PyTorch → Core ML obejmuje trzy kroki:

1. Załadowanie wytrenowanego modelu PyTorch i przełączenie go w tryb inferencji.
2. Trasowanie modelu z przykładowym tensorem wejściowym pasującym do produkcyjnego kształtu wejścia.
3. Konwersja prześledzonego modelu za pomocą coremltools względem docelowej wersji wdrożenia 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.iOS18,
    compute_units=ct.ComputeUnit.ALL,
)
mlmodel.save("MyModel.mlpackage")

Konwersja odbywa się jednorazowo, w środowisku deweloperskim, względem docelowej wersji wdrożenia iOS (minimum_deployment_target). Wynikowy .mlpackage jest tym, co trafia do projektu Xcode. Aplikacja w czasie wykonania nie uruchamia coremltools.

Dwie praktyczne pułapki w konwersji. Po pierwsze, wejścia o dynamicznych kształtach wymagają jawnej obsługi przez ct.RangeDim, ponieważ domyślny statyczny kształt Core ML generuje mało pomocne błędy, gdy aplikacja produkcyjna podaje wejścia o zmiennym rozmiarze. Po drugie, niestandardowe operacje w PyTorch, które nie mają odpowiednika w Core ML, wymagają albo niestandardowej warstwy Core ML (kodu Swift uruchamiającego brakującą operację), albo zmiany architektury modelu w celu usunięcia operacji przed konwersją. Oba podejścia są dobrze udokumentowane⁵.

Budżety opóźnień, które rzeczywiście mają zastosowanie

Trzy budżety opóźnień mają znaczenie dla aplikacji wdrażanych do produkcji:

16 ms (UI 60 fps na żywo). Filtr aparatu w czasie rzeczywistym, scena AR aktualizowana per-klatkę, analizator audio na żywo. Budżet obejmuje wszystko: preprocessing obrazu, inferencję modelu, postprocessing, aktualizację UI. Pasujące modele są zazwyczaj małe (klasy MobileNetV3, poniżej 100 mln parametrów) i działają na Neural Engine.

100 ms (UI interaktywne). Użytkownik wykonuje akcję i czeka na wynik: dotknij, aby zidentyfikować, narysuj, aby rozpoznać, podyktuj, aby przepisać. Budżet jest bardziej wyrozumiały i obsługuje większe modele. Modele językowe poniżej 1 mld parametrów, małe transformery wizualne i większość klasyfikatorów klasy produkcyjnej mieszczą się komfortowo.

1 s+ (tło lub partia). Indeksowanie biblioteki zdjęć, analiza dokumentów, rozgrzewanie modelu przy starcie aplikacji. Większe modele działają, ale oczekiwania użytkownika muszą zostać ustawione przez wskaźnik postępu. LLM Foundation Models działający na urządzeniu mieści się tutaj dla większych operacji w oknie kontekstu.

Budżety to wskazówki, a nie sztywne limity. Właściwym podejściem jest pomiar na urządzeniu docelowym za pomocą os_signpost lub szablonu Core ML w Instruments⁶, a nie poleganie na teoretycznych liczbach z innej maszyny.

Kwantyzacja: kiedy mniejsze znaczy szybsze

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

• Float32 (pełna precyzja). Wartość domyślna dla treningu. Największy, najdokładniejszy, najwolniejszy.
• Float16. Połówkowa precyzja. Mniejszy i szybszy na GPU i NE; utrata dokładności jest zwykle pomijalna dla dobrze uwarunkowanych modeli.
• INT8. 8-bitowa kwantyzacja całkowitoliczbowa z kalibracją. Mniej więcej 4x mniejszy niż Float32, często 2-4x szybszy na NE. Utrata dokładności jest zmienna; dla modeli wizualnych osiągalna jest utrata dokładności top-1 poniżej 1% przy treningu uwzględniającym kwantyzację.
• INT4 i niżej. Agresywna kwantyzacja, którą nowsze wersje Core ML wspierają dla określonych architektur modeli (LLMy, duże modele wizualne). Znaczna utrata dokładności jest kompromisem; technika działa najlepiej w połączeniu z treningiem uwzględniającym kwantyzację specyficzną dla 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 wagi, poniżej którego wagi pozostają w pełnej precyzji. Konwersja działa na istniejącym .mlpackage i tworzy nowy skwantyzowany pakiet; oba mogą być dostarczane obok siebie w pakiecie aplikacji, a aplikacja wybiera, który załadować, na podstawie klasy urządzenia.

Decyzja o kwantyzacji jest per-model: mały klasyfikator może na niej nie skorzystać, ponieważ jego obliczenia są już tanie; duży model językowy korzysta ogromnie, ponieważ jego obliczenia są zdominowane przez mnożenia macierzy na skwantyzowanych wagach. Właściwe podejście to skwantyzować, zmierzyć dokładność na zatrzymanym zbiorze testowym i wdrożyć, jeśli spadek dokładności jest akceptowalny dla danego zastosowania.

Wbudowane modele Apple, które można od razu zastosować

Apple udostępnia kilka wytrenowanych modeli Core ML poprzez stronę Core ML Models⁸. Warte uwagi kategorie:

• Klasyfikacja obrazów: MobileNetV2, ResNet50, warianty SqueezeNet, wszystkie spakowane i gotowe do umieszczenia w VNCoreMLRequest frameworka Vision.
• Detekcja obiektów: YOLOv3, MNIST, warianty CenterNet.
• Estymacja pozy: PoseNet do pozy ciała (alternatywa bazowa dla VNDetectHumanBodyPoseRequest z Vision).
• Segmentacja semantyczna: DeepLabV3 do segmentacji obrazu.
• Rozpoznawanie tekstu: Alternatywy OCR oparte na ML wobec wbudowanych w Vision.

Dla większości aplikacji wytrenowane modele Apple pokrywają prymitywy percepcji (klasyfikuj, wykrywaj, segmentuj) bez wymagania niestandardowego treningu. LLM Foundation Models działający na urządzeniu (omówiony w Foundation Models on-device LLM) jest największym przykładem: LLM o wielu miliardach parametrów, dostarczany jako model Core ML za wysokopoziomowym API Swift, dyspozycjonowany na Neural Engine, dostępny offline.

Szyfrowanie modelu i kwestie App Store

Plik .mlpackage w pakiecie aplikacji jest możliwy do odczytania przez każdego, kto rozpakuje IPA. Dla modeli stanowiących znaczącą własność intelektualną Apple obsługuje szyfrowanie modelu poprzez przepływ pracy Encrypt your Core ML model⁹: klucz szyfrujący jest generowany przez Xcode i zarządzany przez CloudKit, model w pakiecie jest zaszyfrowany, a Core ML odszyfrowuje go w czasie ładowania.

Dla większości aplikacji szyfrowanie jest przesadą. Model wytrenowany na powszechnie dostępnych danych ImageNet nie stanowi wyróżnika konkurencyjnego; szyfrowanie go dodaje złożoność operacyjną bez ochrony czegokolwiek wartościowego. Szyfrowanie należy zarezerwować dla modeli, które reprezentują rzeczywistą inwestycję w dane treningowe lub przewagę konkurencyjną.

Prywatność na urządzeniu: zwycięstwo architektoniczne

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

Dla aplikacji w branżach regulowanych (zdrowie, finanse, edukacja) ten fakt architektoniczny eliminuje całą klasę pracy zgodnościowej. Nie ma zewnętrznego procesora danych, którego trzeba dodać do polityki prywatności. Nie ma punktu końcowego API modelu, który trzeba zweryfikować pod kątem bezpieczeństwa. Nie ma kwestii rezydencji danych, ponieważ dane nigdy się nie przemieszczają.

Format Privacy Manifest¹⁰ kodyfikuje historię prywatności na potrzeby przesłania do App Store: aplikacja, która używa Core ML do inferencji na urządzeniu i niczego więcej, może zadeklarować zerowe udostępnianie danych podmiotom trzecim dla ścieżki inferencji. Proces przesłania jest szybszy, przegląd prywatności jest krótszy, a etykieta wartości odżywczych prywatności widoczna dla użytkownika jest czystsza.

Powiązanie z przepływem agentów

Core ML łączy się z trzema wzorcami, które klaster już omówił:

VNCoreMLRequest frameworka Vision. Niestandardowe modele Core ML działają przez potok Vision z automatycznym preprocessingiem. Wzorzec (omówiony w Vision Framework) jest właściwym sposobem dostarczenia niestandardowego klasyfikatora lub detektora obrazów wewnątrz aplikacji iOS.

LLM Foundation Models działający na urządzeniu. LLM Apple Intelligence to model Core ML za wysokopoziomowym API Swift. Mają zastosowanie te same wzorce dyspozycji (najpierw Neural Engine), kwantyzacji (INT4 dla wag LLM) i budżetu opóźnień (poniżej sekundy dla krótkich generacji). Wpis o Foundation Models omawia API; ten wpis omawia silnik leżący u podstaw.

Narzędzia App Intents używające lokalnego ML. AppIntent, który uruchamia lokalny klasyfikator obrazów lub klasyfikator tekstu, zwraca ustrukturyzowane wyniki do Apple Intelligence bez podróży sieciowej. To połączenie sprawia, że „agentowe Apple” jest faktycznie prywatne; narzędzia agenta działają lokalnie, ponieważ framework to umożliwia.

Kiedy inferencja w chmurze jest właściwym wyborem

Pułapem Core ML jest moc obliczeniowa urządzenia. Trzy przypadki, w których chmura jest właściwa:

Modele zbyt duże, aby umieścić je w pakiecie. LLM z 70 mld parametrów nie zmieści się w pakiecie aplikacji. Dla obciążeń tej skali inferencja w chmurze (lub na-urządzeniu-przez-strumieniowanie-wag, inny wzorzec) jest właściwym narzędziem.

Współdzielony stan między urządzeniami podczas inferencji. Modele, które muszą czytać lub zapisywać współdzieloną bazę danych podczas inferencji (systemy rekomendacji z filtracją kolaboratywną na miliardach rekordów). Czysto lokalny model Core ML tu nie pasuje.

Szybka iteracja modelu. Zespół, który dostarcza aktualizacje modelu codziennie, korzysta z inferencji po stronie serwera, ponieważ wdrożenia nie wymagają cykli przeglądu App Store. Wzorzec Core ML „pakuj-model-w-aplikację” dodaje tarcia do tempa zmian modelu; ten kompromis jest realny.

Wzorzec: chmura wygrywa na skali i szybkości iteracji; Core ML wygrywa na opóźnieniu, koszcie i prywatności.

Co ten wzorzec oznacza dla aplikacji iOS 26+

Trzy wnioski.

1. Należy domyślnie wybierać Core ML dla każdego modelu, który mieści się w pakiecie i daje wynik per-wywołanie, na który użytkownik może zareagować. Klasyfikacja obrazów, detekcja obiektów, klasyfikacja audio, rozpoznawanie gestów, generowanie embeddingów, małe i średnie zadania językowe. Automatyczna dyspozycja frameworka i NPU Apple Silicon dają inferencję od poniżej milisekundy do kilkudziesięciu milisekund bez kosztu.

2. Należy kwantyzować agresywnie, gdy spadek dokładności jest akceptowalny. INT8 jest zwykle bezpieczny; INT4 jest odpowiedni dla dużych modeli, gdzie oszczędności rozmiaru mają znaczenie. Należy mierzyć dokładność na zatrzymanym zbiorze, zamiast ufać, że kwantyzacja jest uniwersalnie bezpieczna.

3. Należy łączyć z Vision i Foundation Models, aby uzyskać pełne lokalne potoki. Core ML to silnik; Vision to API percepcji nad nim; Foundation Models to LLM nad nim. Wpisy klastra Vision i Foundation Models omawiają wyższe powierzchnie.

Pełny klaster Apple Ecosystem: typowane App Intents; serwery MCP; pytanie o routing; Foundation Models; rozróżnienie LLM czasu wykonania vs narzędzi; trzy powierzchnie; wzorzec pojedynczego źródła prawdy; Two MCP Servers; hooki dla rozwoju Apple; Live Activities; kontrakt czasu wykonania watchOS; wnętrze SwiftUI; model myślowy przestrzeni RealityKit; dyscyplina schematu SwiftData; wzorce Liquid Glass; wdrażanie wieloplatformowe; macierz platform; Vision framework; Symbol Effects; o czym odmawiam pisać. Hub znajduje się w Apple Ecosystem Series. Dla szerszego kontekstu iOS-z-agentami-AI zobacz iOS Agent Development guide.

FAQ

Jak Core ML decyduje między Neural Engine, GPU a CPU?

Core ML analizuje każdą operację w grafie modelu i kieruje ją do najszybszego celu obsługującego daną operację. Neural Engine obsługuje wspierane operacje (większość mnożeń macierzy, splotów, atencji) przy najniższym opóźnieniu i poborze mocy. GPU obsługuje operacje, których NE nie wspiera. CPU obsługuje resztę. Decyzja jest per-operacja, automatyczna i szybsza niż ręcznie napisana heurystyka.

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

Niemal zawsze. Automatyczna dyspozycja frameworka jest dobrze dostrojona. Nadpisywać należy do .cpuOnly przy testowaniu spójności wyników (ten sam model zwraca nieco inne wyniki na NE vs CPU z powodu zaokrągleń zmiennoprzecinkowych) lub do .cpuAndGPU, aby zwolnić Neural Engine dla zadania współbieżnego.

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

.mlpackage to nowoczesny format wprowadzony w Xcode 13. Wspiera przechowywane metadane, wiele wariantów modelu dla kompilacji ML Program (mlprogram) oraz toolchain post-iOS 13. .mlmodel to format starszy. Oba nadal ładują się przez MLModel; nowy rozwój powinien używać .mlpackage.

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

Nie ma sztywnego limitu, ale rozmiary pakietów App Store są ograniczone do 4 GB dla pobrania i mają praktyczne limity dla instalacji over-the-air. LLM Foundation Models działający na urządzeniu ma około 3 GB i jest dystrybuowany przez system operacyjny, a nie przez pakiet aplikacji. Dla modeli pakowanych w aplikację poniżej 100 MB jest komfortowe; 100-500 MB jest wykonalne ze strategią ładowania w czasie startu; 500 MB+ najlepiej obsłużyć przez pobranie w tle BGProcessingTask lub zasoby na żądanie.

Jak dowiedzieć się, czy kwantyzacja zaszkodziła dokładności mojego modelu?

Należy zatrzymać zbiór testowy, uruchomić inferencję na oryginalnym modelu Float32 i 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 itd.), zdecydować na podstawie wymagań dokładności aplikacji. Trening uwzględniający kwantyzację (trenowanie modelu z kwantyzacją symulowaną w stracie) zwykle odzyskuje większość utraconej dokładności.

References