Het vermijden van verborgen gevaren: navigeren door niet-evidente valkuilen in ML op iOS

Hebt u ML nodig?

Machine learning is uitstekend in het herkennen van patronen. Als u erin slaagt een schone dataset voor uw taak te verzamelen, is het meestal alleen een kwestie van tijd voordat u een ML-model met superieure prestaties kunt bouwen. Dit is vooral waar in klassieke taken zoals classificatie, regressie en anomaliedetectie.

Wanneer u klaar bent om enkele van uw bedrijfsproblemen met ML op te lossen, moet u overwegen waar uw ML-modellen zullen worden uitgevoerd. Voor sommigen is het zinvol om een serverinfrastructuur uit te voeren. Dit heeft het voordeel dat uw ML-modellen privé blijven, waardoor het voor concurrenten moeilijker is om in te halen. Bovendien kunnen servers een breder scala aan modellen uitvoeren. Bijvoorbeeld, GPT-modellen (bekend geworden met ChatGPT) vereisen momenteel moderne GPUs, dus consumentenapparaten zijn uitgesloten. Aan de andere kant is het onderhouden van uw infrastructuur vrij kostbaar, en als een consumentenapparaat uw model kan uitvoeren, waarom meer betalen? Bovendien kunnen er ook privacyproblemen zijn waarbij u geen gebruikersgegevens naar een externe server kunt verzenden voor verwerking.

Laat ons echter aannemen dat het zinvol is om de iOS-apparaten van uw klanten te gebruiken om een ML-model uit te voeren. Wat kan er mis gaan?

Platformbeperkingen

Geheugenbeperkingen

iOS-apparaten hebben veel minder beschikbaar videogeheugen dan hun desktop-tegenhangers. Bijvoorbeeld, de recente Nvidia RTX 4080 Ti heeft 20 GB aan beschikbaar geheugen. iPhones daarentegen hebben videogeheugen dat gedeeld wordt met de rest van het RAM in wat ze “unified memory” noemen. Ter referentie, de iPhone 14 Pro heeft 6 GB aan RAM. Bovendien, als u meer dan de helft van het geheugen toewijst, is iOS zeer waarschijnlijk om de app te stoppen om ervoor te zorgen dat het besturingssysteem responsief blijft. Dit betekent dat u alleen kunt rekenen op 2-3 GB aan beschikbaar geheugen voor neurale netwerkinferentie.

Onderzoekers trainen hun modellen meestal om de nauwkeurigheid te optimaliseren boven geheugenverbruik. Er is echter ook onderzoek beschikbaar over manieren om te optimaliseren voor snelheid en geheugenvoetafdruk, dus u kunt ofwel minder veeleisende modellen zoeken of zelf een model trainen.

Netwerklaag (operaties) ondersteuning

De meeste ML- en neurale netwerken komen van bekende deep learning-frameworks en worden vervolgens omgezet in CoreML-modellen met Core ML Tools. CoreML is een inferentiemotor geschreven door Apple die verschillende modellen op Apple-apparaten kan uitvoeren. De lagen zijn goed geoptimaliseerd voor de hardware en de lijst met ondersteunde lagen is vrij lang, dus dit is een uitstekend startpunt. Er zijn echter ook andere opties zoals Tensorflow Lite beschikbaar.

De beste manier om te zien wat mogelijk is met CoreML is om te kijken naar enkele reeds omgezette modellen met behulp van viewers zoals Netron. Apple vermeldt enkele van de officieel ondersteunde modellen, maar er zijn ook community-gedreven modelzoos. De volledige lijst met ondersteunde operaties verandert constant, dus het bekijken van de broncode van Core ML Tools kan nuttig zijn als startpunt. Bijvoorbeeld, als u een PyTorch-model wilt omzetten, kunt u proberen de benodigde laag hier te vinden.

Bovendien kunnen bepaalde nieuwe architectuur handgeschreven CUDA-code bevatten voor sommige van de lagen. In dergelijke situaties kunt u niet verwachten dat CoreML een vooraf gedefinieerde laag biedt. U kunt echter uw eigen implementatie bieden als u een ervaren ingenieur heeft die vertrouwd is met het schrijven van GPU-code.

Al met al is het beste advies hier om uw model zo vroeg mogelijk om te zetten naar CoreML, zelfs voordat u het traint. Als u een model heeft dat niet meteen is omgezet, is het mogelijk om de neurale netwerkdefinitie in uw DL-framework of de broncode van de Core ML Tools-omzetter te wijzigen om een geldig CoreML-model te genereren zonder dat u een aangepaste laag voor CoreML-inferentie hoeft te schrijven.

Validatie

Inferentie-engine bugs

Er is geen manier om elke mogelijke combinatie van lagen te testen, dus de inferentie-engine zal altijd enkele bugs hebben. Bijvoorbeeld, het is gebruikelijk om te zien dat gedilateerde convoluties te veel geheugen gebruiken met CoreML, waarschijnlijk aangegeven door een slecht geschreven implementatie met een grote kernel met nulwaarden. Een andere veelvoorkomende bug is onjuiste modeluitvoer voor sommige modelarchitecturen.

In dit geval kan de volgorde van operaties een rol spelen. Het is mogelijk om onjuiste resultaten te krijgen, afhankelijk van of activatie met convolutie of de restverbinding eerst komt. De enige echte manier om te garanderen dat alles goed werkt, is om uw model te nemen, het uit te voeren op het beoogde apparaat en het resultaat te vergelijken met een desktopversie. Voor deze test is het handig om ten minste een halfgetraind model beschikbaar te hebben, anders kan de numerieke fout accumuleren voor slecht willekeurig geïnitialiseerde modellen. Zelfs als het uiteindelijke getrainde model goed werkt, kunnen de resultaten heel verschillend zijn tussen het apparaat en de desktop voor een willekeurig geïnitialiseerd model.

Precisieverlies

iPhone gebruikt halfprecisie-accuraatheid uitgebreid voor inferentie. Terwijl sommige modellen geen merkbare nauwkeurigheidsafname hebben vanwege minder bits in de floating point-representatie, kunnen andere modellen hieronder lijden. U kunt het precisieverlies benaderen door uw model te evalueren op de desktop met halfprecisie en een testmetriek voor uw model te berekenen. Een nog betere methode is om het uit te voeren op een echt apparaat om te zien of het model zo nauwkeurig is als bedoeld.

Profiling

Verschillende iPhone-modellen hebben verschillende hardwaremogelijkheden. De nieuwste hebben verbeterde Neural Engine-verwerkingseenheden die de algehele prestaties aanzienlijk kunnen verbeteren. Ze zijn geoptimaliseerd voor bepaalde operaties en CoreML kan intelligent werk verdelen tussen CPU, GPU en Neural Engine. Apple GPUs zijn ook verbeterd in de loop van de tijd, dus het is normaal om fluctuerende prestaties te zien over verschillende iPhone-modellen. Het is een goed idee om uw modellen te testen op minimaal ondersteunde apparaten om maximale compatibiliteit en aanvaardbare prestaties voor oudere apparaten te garanderen.

Het is ook de moeite waard om te vermelden dat CoreML sommige van de tussenliggende lagen en berekeningen in-place kan optimaliseren, wat de prestaties aanzienlijk kan verbeteren. Een ander punt om te overwegen is dat soms een model dat slechter presteert op een desktop, eigenlijk sneller inferentie kan doen op iOS. Dit betekent dat het de moeite waard is om enige tijd te besteden aan het experimenteren met verschillende architectuur.

Voor nog meer optimalisatie heeft Xcode een mooi Instruments-hulpmiddel met een sjabloon speciaal voor CoreML-modellen dat een dieper inzicht kan geven in wat uw modelinferentie vertraagt.

Conclusie

Niemand kan alle mogelijke valkuilen voorzien bij het ontwikkelen van ML-modellen voor iOS. Er zijn echter enkele fouten die kunnen worden vermeden als u weet waar u naar moet kijken. Begin met het omzetten, valideren en profileren van uw ML-modellen zo vroeg mogelijk om ervoor te zorgen dat uw model correct werkt en aan uw bedrijfsvereisten voldoet, en volg de tips die hierboven zijn uiteengezet om succes zo snel mogelijk te garanderen.