Unngå skjulte farer: Navigering i 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 spesielt sant i klassiske oppgaver som klassifisering, regresjon og anomalioppdaging.

Når du er klar til å løse noen av dine forretningsproblemer med ML, må du vurdere hvor dine ML-modeller vil kjøres. 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 krever GPT-modeller (som er kjent fra ChatGPT) moderne GPU-er, så forbrukerenheter er utenfor spørsmål. På den andre siden er det ganske dyrt å vedlikeholde infrastrukturen, og hvis en forbrukerenhet kan kjøre modellen din, hvorfor betale mer? I tillegg kan det også være noen privatskapsproblemer der 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 kan gå galt?

Plattformbegrensninger

Minnebegrensninger

iOS-enheter har langt 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 til å drepe appen for å sikre at operativsystemet forblir responsivt. Dette betyr at du bare kan regne med å ha 2-3 GB tilgjengelig minne for neuralt nettverksinferens.

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

Nettverkslag (operasjoner) støtte

De fleste ML- og neurale nettverk kommer fra kjente dyplearningsrammer og konverteres deretter til CoreML-modeller med Core ML Tools. CoreML er en inferensmotor skrevet av Apple (AAPL ) som kan kjøre forskjellige modeller på Apple-enheter. Lagene er godt optimert for maskinvaren og listen over støttede lag er ganske lang, så dette er et utmerket utgangspunkt. Likevel, finnes det også andre alternativer som Tensorflow Lite.

Den beste måten å se hva som er mulig med CoreML er å se på noen allerede konverterte modeller med visningsverktøy som Netron. Apple listar noen av de offisielt støttede modellene, men det finnes også samfunnsdrevne modellzoologier. 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 implementasjon hvis du har en erfaren ingeniør som er kjent med å skrive GPU-kode.

Overhodet, 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 nettverksdefinisjonen i din DL-ramme eller Core ML Tools-konverteringskildekode for å generere en gyldig CoreML-modell uten å måtte skrive en tilpasset lag for CoreML-inferens.

Validering

Inferensmotorfeil

Det finnes ingen måte å teste alle mulige kombinasjoner av lag, så inferensmotoren vil alltid ha noen feil. For eksempel, er det vanlig å se at dilaterte konvolusjoner bruker for mye minne med CoreML, sannsynligvis indikerer en dårlig skrevet implementasjon med en stor kernel padet med nuller. En annen vanlig feil er feilaktig modellutgang for noen modellarkitekturer.

I dette tilfelle, kan rekkefølgen av operasjoner være en faktor. Det er mulig å få feilaktige resultater avhengig av om aktivering med konvolusjon eller den ressiduelle 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 desktopversjon. For denne testen, er det nyttig å ha minst en semi-trent modell tilgjengelig, ellers kan den numeriske feilen akkumuleres for dårlig tilfeldig initierte modeller. Selv om den endelige trenede modellen vil fungere fint, kan resultater være ganske forskjellige mellom enheten og desktop for en tilfeldig initiert modell.

PresisjonsTap

iPhone bruker halv-presisjonsnøyaktighet omfattende for inferens. Mens noen modeller ikke har noen merkbare nøyaktighetsnedgradering på grunn av færre biter i flytende punktrepresentasjon, kan andre modeller lide. Du kan approksimere presisjonsTapet ved å evaluere modellen din på desktop med halv-presisjon og beregne en testmetrik 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årdvareriforer. De nyeste har forbedret Neural Engine-prosessorer som kan heve den totale ytelsen betydelig. De er optimert for bestemte operasjoner, og CoreML kan inteligent distribuere arbeid mellom CPU, GPU og Neural Engine. Apple GPU-er har også forbedret 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 forbedre ytelsen dramatisk. En annen faktor å vurdere er at noen ganger kan en modell som utfører dårligere på en desktop 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 verktøy kalt Instruments med en mal for CoreML-modeller som kan gi en mer omfattende innsikt i hva som bremser modellinferensen din.

Konklusjon

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