Undgå de skjulte farer: Navigation i ikke-åbenlyse fælder i ML på iOS

Har du brug for ML?

Maskinlæring er fremragende til at spotte mønstre. Hvis du kan samle en ren dataset til din opgave, er det normalt kun et spørgsmål om tid, før du kan bygge en ML-model med overmenneskelig præstation. Dette er særligt sandt i klassiske opgaver som klassifikation, regression og afvigelsesdetektion.

Når du er klar til at løse nogle af dine forretningsproblemer med ML, må du overveje, hvor dine ML-modeller vil køre. For nogle giver det mening at køre en server-infrastruktur. Dette har fordelen af at holde dine ML-modeller private, så det er sværere for konkurrenter at følge med. Oven i det kan servere køre en bred vifte af modeller. For eksempel kræver GPT-modeller (lavet berømt med ChatGPT) i øjeblikket moderne GPU’er, så forbrugerenheder er udelukket. På den anden side er det ret dyrt at vedligeholde din infrastruktur, og hvis en forbrugerenhed kan køre din model, hvorfor betale mere? Derudover kan der også være bekymringer om privatliv, hvor du ikke kan sende brugerdata til en fjernserver til behandling.

Men lad os antage, at det giver mening at bruge dine kunders iOS-enheder til at køre en ML-model. Hvad kan gå galt?

Platformbegrænsninger

Hukommelsesbegrænsninger

iOS-enheder har langt mindre tilgængelig videohukommelse end deres desktop-modstykke. For eksempel har den nyeste Nvidia RTX 4080 Ti 20 GB tilgængelig hukommelse. iPhone-enheder har derimod videohukommelse, der deles med resten af RAM’en i det, de kalder “unified memory”. For reference har iPhone 14 Pro 6 GB RAM. Desuden er det meget sandsynligt, at iOS vil lukke appen for at sikre, at operativsystemet forbliver responsivt, hvis du allokerer mere end halvdelen af hukommelsen. Dette betyder, at du kun kan regne med at have 2-3 GB tilgængelig hukommelse til neuralt netværksinference.

Forskere træner normalt deres modeller for at optimere nøjagtighed over hukommelsesbrug. Der er dog også forskning tilgængelig om måder at optimere for hastighed og hukommelsesaftryk, så du kan enten lede efter mindre krævende modeller eller træne en selv.

Netværkslag (operationer) support

De fleste ML- og neurale netværk kommer fra velkendte dybtlæringrammer og konverteres derefter til CoreML-modeller med Core ML Tools. CoreML er en inference-motor skrevet af Apple (AAPL ), der kan køre forskellige modeller på Apple-enheder. Lagene er godt optimeret for hardwaren, og listen over understøttede lag er ret lang, så dette er et fremragende udgangspunkt. Der er dog også andre muligheder som Tensorflow Lite.

Den bedste måde at se, hvad der er muligt med CoreML, er at se på nogle allerede konverterede modeller med visningsværktøjer som Netron. Apple listar nogle af de officielt understøttede modeller, men der er også fællesskabsdrevne model-zooer. Listen over understøttede operationer ændrer sig konstant, så det kan være hjælpsomt at se på Core ML Tools kildekode som udgangspunkt. For eksempel, hvis du ønsker at konvertere en PyTorch-model, kan du prøve at finde det nødvendige lag her.

Derudover kan visse nye arkitekturer indeholde håndskrevet CUDA-kode for nogle af lagene. I sådanne situationer kan du ikke forvente, at CoreML leverer et foruddefineret lag. Alligevel kan du levere din egen implementering, hvis du har en dygtig ingeniør, der er fortrolig med at skrive GPU-kode.

Samlet set er det bedste råd her at prøve at konvertere din model til CoreML tidligt, selv før du træner den. Hvis du har en model, der ikke blev konverteret med det samme, er det muligt at ændre neuralt netværksdefinitionen i din DL-ramme eller Core ML Tools-konverteringskildekode for at generere en gyldig CoreML-model uden behov for at skrive en brugerdefineret lag til CoreML-inference.

Validering

Inference-motorfejl

Der er ingen måde at teste alle mulige kombinationer af lag, så inference-motoren vil altid have nogle fejl. For eksempel er det almindeligt at se, at dilated konvolutioner bruger for meget hukommelse med CoreML, sandsynligvis på grund af en dårligt skrevet implementering med en stor kernel padet med nulle. En anden almindelig fejl er forkert modeloutput for visse modelarkitekturer.

I dette tilfælde kan ordenen af operationer være en faktor. Det er muligt at få forkerte resultater afhængigt af, om aktivering med convolution eller den residuelle forbindelse kommer først. Den eneste virkelige måde at garantere, at alt fungerer korrekt, er at tage din model, køre den på den ønskede enhed og sammenligne resultatet med en desktop-version. Til dette test er det hjælpsomt at have mindst en semi-trænet model til rådighed, ellers kan den numeriske fejl akkumuleres for dårligt tilfældigt initialiserede modeller. Selv om den endelige trænede model vil fungere fint, kan resultaterne være ret forskellige mellem enheden og desktoppen for en tilfældigt initialiseret model.

Præcisions-tab

iPhone bruger halvpræcision præcision omfattende til inference. Mens nogle modeller ikke har nogen bemærkbar nøjagtighedsdegradering på grund af færre bit i flydende punkt-repræsentation, kan andre modeller lide under det. Du kan approksimere præcisions-tab ved at evaluere din model på desktoppen med halvpræcision og beregne en test-metrik for din model. En endnu bedre metode er at køre den på en virkelig enhed for at finde ud af, om modellen er lige så nøjagtig, som det var tiltænkt.

Profiling

Forskellige iPhone-modeller har forskellige hardware-kapaciteter. De nyeste har forbedret Neural Engine-processorenheder, der kan forhøje den samlede præstation betydeligt. De er optimeret til bestemte operationer, og CoreML kan intelligent distribuere arbejde mellem CPU, GPU og Neural Engine. Apple GPU’er har også forbedret sig over tid, så det er normalt at se fluktuerende præstationer på tværs af forskellige iPhone-modeller. Det er en god idé at teste dine modeller på minimalt understøttede enheder for at sikre maksimal kompatibilitet og acceptabel præstation for ældre enheder.

Det er også værd at nævne, at CoreML kan optimere bort nogle af de mellemste lag og beregninger på stedet, hvilket kan forbedre præstationen betydeligt. En anden faktor at overveje er, at en model, der præsterer dårligere på en desktop, faktisk kan gøre inference hurtigere på iOS. Dette betyder, at det er værd at bruge noget tid på at eksperimentere med forskellige arkitekturer.

Til endnu mere optimering har Xcode et nice Instruments-værktøj med en skabelon specifikt til CoreML-modeller, der kan give en mere omfattende indsigt i, hvad der langsommere din model-inference.

Konklusion

Ingen kan forudse alle mulige fælder, når man udvikler ML-modeller til iOS. Der er dog nogle fejl, der kan undgås, hvis man ved, hvad man skal lede efter. Start med at konvertere, valider og profilere dine ML-modeller tidligt for at sikre, at din model vil fungere korrekt og tilpasse sig dine forretningskrav, og følg de råd, der er nævnt ovenfor for at sikre succes så hurtigt som muligt.