Unngå de skjulte farene: Navigering av ikke-åpenbare fallgruber i ML på iOS

Trenger du ML?

Maskinlæring er utmerket til å oppdage mønster. Hvis du klarer å samle inn en ren datasett for oppgaven din, er det vanligvis bare et spørsmål om tid før du kan bygge en ML-modell med overmenneskelig ytelse. Dette er særlig sant i klassiske oppgaver som klassifisering, regresjon og anomali-opptekting.

Når du er klar til å løse noen av bedriftsproblemine dine med ML, må du vurdere hvor dine ML-modeller skal kjøre. For noen gjør det mening å kjøre en server-infrastruktur. Dette har fordelen av å holde dine ML-modeller private, så det er vanskeligere for konkurrenter å holde pace. I tillegg kan servere kjøre en bredere variasjon av modeller. For eksempel, trenger GPT-modeller (som er berømt med ChatGPT) moderne GPU-er, så forbrukerenheter er utenfor spørsmål. På den andre siden, er det ganske dyrt å vedlikeholde infrastrukturen, og hvis en forbruker-enhet kan kjøre modellen din, hvorfor betale mer? I tillegg kan det også være problemer med personvern hvor du ikke kan sende brukerdata til en fjernserver for prosessering.

Men, la oss anta at det er meningsfullt å bruke kundenes iOS-enheter til å kjøre en ML-modell. Hva kunne gå galt?

Plattform-begrensninger

Minnebegrensninger

iOS-enheter har mye mindre tilgjengelig videominne enn deres desktop-ekvivalenter. For eksempel, har den nyeste Nvidia RTX 4080 Ti 20 GB tilgjengelig minne. iPhone-er på den andre siden, har videominne som deles med resten av RAM-en i det de kaller “unified memory”. For referanse, har iPhone 14 Pro 6 GB RAM. I tillegg, hvis du allokerer mer enn halvparten av minnet, er iOS svært sannsynlig å drepe appen for å sikre at operativsystemet forblir responsivt. Dette betyr at du bare kan regne med å ha 2-3 GB tilgjengelig minne for neuralt nettverks-inferens.

Forskere trener vanligvis modellene sine for å optimere nøyaktighet over minnebruk. Men, det finnes også forskning tilgjengelig på måter å optimere for hastighet og minneavtrykk, så du kan enten søke etter mindre krevende modeller eller trene en selv.

Nettverkslag (operasjoner) støtte

De fleste ML- og neurale nettverk kommer fra kjente dyptelæring-rammeverk og konverteres deretter til CoreML-modeller med Core ML Tools. CoreML er en inferens-motor skrevet av Apple som kan kjøre ulike modeller på Apple-enheter. Lagene er godt-optimalisert for maskinvaren og listen over støttede lag er ganske lang, så dette er et utmerket utgangspunkt. Men, andre alternativer som Tensorflow Lite er også tilgjengelige.

Den beste måten å se hva som er mulig med CoreML er å se på noen allerede konverterte modeller som bruker visningsverktøy som Netron. Apple lister noen av de offisielt støttede modellene, men det finnes også samfunnsdrevne modell-zooer. Listen over støttede operasjoner endres konstant, så å se på Core ML Tools kildekode kan være nyttig som et utgangspunkt. For eksempel, hvis du ønsker å konvertere en PyTorch-modell, kan du prøve å finne den nødvendige lag her.

I tillegg, kan visse nye arkitekturer inneholde håndskrevet CUDA-kode for noen av lagene. I slike situasjoner, kan du ikke forvente at CoreML skal tilby en forhåndsdefinert lag. Likevel, kan du tilby din egen implementering hvis du har en erfaren ingeniør som er kjent med å skrive GPU-kode.

Overordnet, er det beste rådet her å prøve å konvertere modellen din til CoreML tidlig, selv før du trener den. Hvis du har en modell som ikke ble konvertert med en gang, er det mulig å modifisere neuralt nettverks-definisjonen i ditt DL-rammeverk eller Core ML Tools konverter kildekode for å generere en gyldig CoreML-modell uten å måtte skrive en tilpasset lag for CoreML-inferens.

Validering

Inferens-motor-feil

Det finnes ingen måte å teste alle mulige kombinasjoner av lag, så inferens-motoren vil alltid ha noen feil. For eksempel, er det vanlig å se dilaterte konvolusjoner bruke for mye minne med CoreML, sannsynligvis indikerer en dårlig skrevet implementering med en stor kernel padet med nuller. En annen vanlig feil er feil modell-utgang for noen modell-arkitekturer.

I dette tilfelle, kan rekkefølgen av operasjoner være en faktor. Det er mulig å få feil resultater avhengig av om aktivering med konvolusjon eller rest-tilkoblingen kommer først. Den eneste virkelige måten å garantere at alt fungerer korrekt er å ta modellen din, kjøre den på den tiltenkte enheten og sammenligne resultatet med en desktop-versjon. For denne testen, er det nyttig å ha minst en semi-trent modell tilgjengelig, ellers kan den numeriske feilen akkumuleres for dårlig tilfeldig initialiserte modeller. Selv om den endelige trenede modellen vil fungere fint, kan resultatene være ganske forskjellige mellom enheten og desktop-en for en tilfeldig initialisert modell.

Presisjons-tap

iPhone bruker halv-presisjons-nøyaktighet omfattende for inferens. Mens noen modeller ikke har noen merkbare nøyaktighets-degradering på grunn av færre bit i flytende punkt-representasjon, kan andre modeller lide. Du kan approksimere presisjons-tapet ved å evaluere modellen din på desktop-en med halv-presisjon og beregne en test-måling for modellen din. En enda bedre metode er å kjøre den på en faktisk enhet for å finne ut om modellen er like nøyaktig som tiltenkt.

Profiling

Forskjellige iPhone-modeller har varierende hårdvar-kapasiteter. De nyeste har forbedret Neural Engine-prosessorer som kan heve den totale ytelsen betydelig. De er optimalisert for bestemte operasjoner, og CoreML er i stand til å inteligent distribuere arbeid mellom CPU, GPU og Neural Engine. Apple GPU-er har også forbedret seg over tid, så det er normalt å se fluktuasjon i ytelse over forskjellige iPhone-modeller. Det er en god idé å teste modellene dine på minimalt støttede enheter for å sikre maksimal kompatibilitet og akseptabel ytelse for eldre enheter.

Det er også verdt å nevne at CoreML kan optimere bort noen av de mellomliggende lagene og beregningene på plass, som kan drastisk forbedre ytelsen. En annen faktor å vurdere er at noen ganger, en modell som utfører dårligere på en desktop, kan faktisk gjøre inferens raskere på iOS. Dette betyr at det er verdt å bruke litt tid på å eksperimentere med forskjellige arkitekturer.

For enda mer optimalisering, har Xcode et nyttig Instruments-verktøy med en mal for CoreML-modeller som kan gi en mer grundig innsikt i hva som bremser modell-inferensen din.

Konklusjon

Ingen kan forutse alle mulige fallgruber når det gjelder å utvikle ML-modeller for iOS. Men, det finnes noen feil som kan unngås hvis du vet hva du skal se etter. Start med å konvertere, valider og profilere dine ML-modeller tidlig for å sikre at modellen din vil fungere korrekt og møte bedrifts-kravene dine, og følg tipsene ovenfor for å sikre suksess så raskt som mulig.