Undvik de dolda farorna: Navigera i icke-uppenbara fallgropar i ML på iOS

Behöver du ML?

Maskinlärning är utmärkt på att upptäcka mönster. Om du lyckas samla in en ren dataset för din uppgift, är det vanligtvis bara en tidsfråga innan du kan bygga en ML-modell med övermänsklig prestanda. Detta är särskilt sant i klassiska uppgifter som klassificering, regression och avvikelseupptäckt.

När du är redo att lösa några av dina affärsproblem med ML, måste du överväga var dina ML-modeller kommer att köras. För vissa är det meningsfullt att köra en serverinfrastruktur. Detta har fördelen att dina ML-modeller förblir privata, så det är svårare för konkurrenter att komma ikapp. Utöver detta kan servrar köra en bredare variation av modeller. Till exempel kräver GPT-modeller (som gjorts kända med ChatGPT) för närvarande moderna GPU:er, så konsumentenheter är inte möjliga. Å andra sidan är underhåll av din infrastruktur ganska dyrt, och om en konsumentenhet kan köra din modell, varför betala mer? Dessutom kan det också finnas sekretessproblem där du inte kan skicka användardata till en fjärrserver för bearbetning.

Men låt oss anta att det är meningsfullt att använda dina kunders iOS-enheter för att köra en ML-modell. Vad kan gå fel?

Plattformsbegränsningar

Minnesbegränsningar

iOS-enheter har mycket mindre tillgängligt videominne än deras skrivbordsmotparter. Till exempel har den senaste Nvidia RTX 4080 Ti 20 GB tillgängligt minne. iPhones, å andra sidan, har videominne som delas med resten av RAM-minnet i vad de kallar “unified memory”. För referens har iPhone 14 Pro 6 GB RAM. Dessutom, om du allokerar mer än hälften av minnet, är iOS mycket sannolikt att döda appen för att se till att operativsystemet förblir responsivt. Detta innebär att du bara kan räkna med att ha 2-3 GB tillgängligt minne för neuronnätinference.

Forskare tränar vanligtvis sina modeller för att optimera noggrannhet över minnesanvändning. Men det finns också forskning tillgänglig om sätt att optimera för hastighet och minnesavtryck, så du kan antingen leta efter mindre krävande modeller eller träna en själv.

Nätverkslager (operationer) stöd

De flesta ML- och neuronnät kommer från välkända djupinlärningsramverk och konverteras sedan till CoreML-modeller med Core ML Tools. CoreML är en inferensmotor skriven av Apple (AAPL ) som kan köra olika modeller på Apple-enheter. Lagren är väl-optimerade för hårdvaran och listan över stödda lager är ganska lång, så detta är en utmärkt utgångspunkt. Men andra alternativ som Tensorflow Lite är också tillgängliga.

Det bästa sättet att se vad som är möjligt med CoreML är att titta på några redan konverterade modeller med hjälp av visningsverktyg som Netron. Apple listar några av de officiellt stödda modellerna, men det finns också community-drivna modellzoo. Den fullständiga listan över stödda operationer ändras ständigt, så att titta på Core ML Tools-källkoden kan vara hjälpsamt som en utgångspunkt. Till exempel, om du vill konvertera en PyTorch-modell, kan du försöka hitta det nödvändiga lagret här.

Dessutom kan vissa nya arkitekturer innehålla handskrivna CUDA-koder för vissa av lagren. I sådana situationer kan du inte förvänta dig att CoreML ska tillhandahålla ett fördefinierat lager. Men du kan tillhandahålla din egen implementering om du har en skicklig ingenjör som är bekant med att skriva GPU-kod.

Sammanfattningsvis är den bästa rådan här att försöka konvertera din modell till CoreML tidigt, även innan du tränar den. Om du har en modell som inte konverterades omedelbart, är det möjligt att modifiera neuronnätdefinitionen i ditt DL-ramverk eller Core ML Tools-konverterarens källkod för att generera en giltig CoreML-modell utan att behöva skriva en anpassad lager för CoreML-inferens.

Validering

Inferensmotorbuggar

Det finns inget sätt att testa alla möjliga kombinationer av lager, så inferensmotorn kommer alltid att ha några buggar. Till exempel är det vanligt att se dilaterade konvolutioner som använder för mycket minne med CoreML, vilket troligen indikerar en dåligt skriven implementering med en stor kernel som är paddad med nollor. En annan vanlig bugg är felaktig modellutdata för vissa modellarkitekturer.

I det här fallet kan ordningen på operationerna spela in. Det är möjligt att få felaktiga resultat beroende på om aktivering med konvolution eller den residuala anslutningen kommer först. Det enda riktiga sättet att garantera att allt fungerar korrekt är att ta din modell, köra den på den avsedda enheten och jämföra resultatet med en skrivbordsversion. För detta test är det hjälpsamt att ha åtminstone en semi-tränad modell tillgänglig, annars kan den numeriska felet ackumuleras för dåligt slumpmässigt initierade modeller. Även om den slutliga tränade modellen kommer att fungera bra, kan resultaten vara ganska olika mellan enheten och skrivbordsversionen för en slumpmässigt initierad modell.

Precisionsförlust

iPhone använder halvprecisionsnoggrannhet omfattande för inferens. Medan vissa modeller inte har någon märkbar noggrannhetsförsämring på grund av färre bitar i flyttalsrepresentationen, kan andra modeller lida. Du kan approximera precisionsförlusten genom att utvärdera din modell på skrivbordsversionen med halvprecisionsnoggrannhet och beräkna en testmetrik för din modell. En ännu bättre metod är att köra den på en faktisk enhet för att ta reda på om modellen är lika exakt som avsett.

Profiling

Olika iPhone-modeller har varierande hårdvarukapaciteter. De senaste har förbättrade Neural Engine-bearbetningsenheter som kan höja den övergripande prestandan avsevärt. De är optimerade för vissa operationer, och CoreML kan intelligent distribuera arbete mellan CPU, GPU och Neural Engine. Apple GPU:er har också förbättrats över tiden, så det är normalt att se varierande prestanda över olika iPhone-modeller. Det är en bra idé att testa dina modeller på minimt stödda enheter för att säkerställa maximal kompatibilitet och acceptabel prestanda för äldre enheter.

Det är också värt att nämna att CoreML kan optimera bort vissa av de mellanliggande lagren och beräkningarna på plats, vilket kan förbättra prestandan avsevärt. En annan faktor att överväga är att ibland kan en modell som presterar sämre på en skrivbordsversion faktiskt göra inferens snabbare på iOS. Detta innebär att det är värt att lägga ner lite tid på att experimentera med olika arkitekturer.

För ännu mer optimering har Xcode ett bra Instruments-verktyg med en mall specifikt för CoreML-modeller som kan ge en mer omfattande inblick i vad som bromsar din modellinference.

Slutsats

Ingen kan förutse alla möjliga fallgropar när man utvecklar ML-modeller för iOS. Men det finns några misstag som kan undvikas om du vet vad du ska leta efter. Börja konvertera, validera och profilera dina ML-modeller tidigt för att säkerställa att din modell kommer att fungera korrekt och passa dina affärsbehov, och följ tipsen ovan för att säkerställa framgång så snabbt som möjligt.