De verborgen gevaren vermijden: niet-overduidelijke valkuilen in ML op iOS

Hebt u ML nodig?

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

Wanneer u klaar bent om sommige van uw bedrijfsproblemen met ML op te lossen, moet u overwegen waar uw ML-modellen zullen draaien. Voor sommigen is het zinvol om een serverinfrastructuur uit te voeren. Dit heeft het voordeel dat uw ML-modellen privé blijven, zodat het voor concurrenten moeilijker is om bij te benen. Bovendien kunnen servers een bredere variëteit aan modellen draaien. Bijvoorbeeld, GPT-modellen (bekend geworden met ChatGPT) vereisen momenteel moderne GPUs, dus consumentenapparaten zijn uitgesloten. Aan de andere kant is het onderhoud van uw infrastructuur behoorlijk duur, en als een consumentenapparaat uw model kan draaien, waarom meer betalen? Bovendien kunnen er ook privacyproblemen zijn waarbij u geen gebruikersgegevens naar een externe server kunt sturen voor verwerking.

Stel echter dat het zinvol is om de iOS-apparaten van uw klanten te gebruiken om een ML-model te draaien. Wat kan er misgaan?

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 doden 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 geheugengebruik. Echter, er is ook onderzoek beschikbaar over manieren om te optimaliseren voor snelheid en geheugenvoetafdruk, dus u kunt ofwel minder veeleisende modellen zoeken of er zelf een trainen.

Netwerklaag (operaties) ondersteuning

De meeste ML- en neurale netwerken komen uit bekende diepe leerframeworks en worden vervolgens omgezet in CoreML-modellen met Core ML Tools. CoreML is een inferentie-engine geschreven door Apple (AAPL ) die verschillende modellen op Apple-apparaten kan draaien. De lagen zijn goed geoptimaliseerd voor de hardware en de lijst met ondersteunde lagen is behoorlijk lang, dus dit is een uitstekend startpunt. Echter, andere opties zoals Tensorflow Lite zijn ook beschikbaar.

De beste manier om te zien wat er mogelijk is met CoreML, is om naar enkele reeds omgezette modellen te kijken 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 voortdurend, dus het is nuttig om naar de broncode van Core ML Tools te kijken als startpunt. Bijvoorbeeld, als u een PyTorch-model wilt omzetten, kunt u proberen de noodzakelijke 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. Niettemin kunt u 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-converter 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 die is gepad met nullen. Een andere veelvoorkomende bug is onjuiste modeluitvoer voor sommige modelarchitecturen.

In dit geval kan de volgorde van operaties een factor zijn. Het is mogelijk om onjuiste resultaten te krijgen, afhankelijk van of activatie met convolutie of de resterende verbinding 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 nuttig om ten minste een semi-getraind 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 behoorlijk verschillen tussen het apparaat en de desktop voor een willekeurig geïnitialiseerd model.

Precisieverlies

iPhone gebruikt half-precisie-accuraatheid uitgebreid voor inferentie. Terwijl sommige modellen geen enkele 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 half-precisie en een testmetriek voor uw model te berekenen. Een nog betere methode is om het uit te voeren op een daadwerkelijk apparaat om te zien of het model zo nauwkeurig is als bedoeld.

Profiling

Verschillende iPhone-modellen hebben gevarieerde hardware-mogelijkheden. De recentste modellen hebben verbeterde Neural Engine-verwerkingseenheden die de algehele prestaties aanzienlijk kunnen verbeteren. Ze zijn geoptimaliseerd voor bepaalde operaties en CoreML kan intelligent werk distribueren tussen CPU, GPU en Neural Engine. Apple-GPU’s 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 factor om te overwegen is dat soms een model dat slechter presteert op een desktop, in werkelijkheid 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 diepgaander inzicht kan geven in wat uw modelinferentie vertraagt.

Conclusie

Niemand kan alle mogelijke valkuilen voorzien bij het ontwikkelen van ML-modellen voor iOS. Echter, er zijn 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 vroeg om ervoor te zorgen dat uw model correct werkt en aan uw bedrijfsvereisten voldoet, en volg de bovenstaande tips om succes zo snel mogelijk te garanderen.