ML in a Box: Analyzing Containerization Practices in Open Source ML Projects
Dit artikel presenteert de eerste grootschalige empirische studie van 1.993 open-source ML Dockerfiles, die onthult dat hoewel containers verschillende rollen vervullen in ML-workflows, ze vaak groot en inefficiënt zijn door frequente rebuilds getriggerd door experimentatie, wat leidde tot de identificatie van zeven specifieke refactoring-patronen om de build-efficiëntie te verbeteren en de voetafdruk te verkleinen.
Oorspronkelijk artikel vrijgegeven aan het publieke domein onder CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je voor dat je een chef-kok bent die een enorme, hightech keuken runt. In de wereld van Machine Learning (ML) zijn je "recepten" code, je "ingrediënten" data en modellen, en je "keuken" is een container. Een container is als een zelfvoorzienende, draagbare keukenbox die alles bevat wat je nodig hebt om een specifiek gerecht te bereiden, zodat het overal hetzelfde smaakt, of je nu kookt in New York, Tokio of op een ruimteschip.
Lange tijd wisten mensen dat deze keukenboxen nuttig waren. Maar niemand wist echt hoe groot ze waren, hoe lang het duurde om ze in te pakken, of hoe vaak de chefs de hele box weg moesten gooien en opnieuw moesten beginnen, alleen maar omdat ze een enkel potje kruiden hadden vervangen.
Een team van onderzoekers besloot in 1.993 van deze ML-keukenboxen van 392 verschillende projecten te gluren om te zien wat er echt aan de hand was. Hier is wat ze vonden, geserveerd met een zijstapje van de realiteit.
De grootte van de "Keukenboxen": Het is een big deal
Eerst hebben ze de boxen gewogen. Je zou denken dat een container licht en vlot is, maar deze ML-boxen zijn reuzen.
- Gemiddeld weegt een container 10,27 GB. Dat is alsof je een hele bibliotheek aan encyclopedieën in je rugzak draagt, alleen maar om een broodje te maken.
- De "Training"-boxen (waar de AI leert) zijn het zwaarst, met een gemiddelde van 17,25 GB. Sommige van deze monsters halen zelfs de 125 GB!
- De "Inference"-boxen (waar de AI gewoon het werk doet) zijn kleiner, rond de 1,72 GB, maar nog steeds niet bepaald broekzakformaat.
En het inpakken van deze boxen? Dat kost tijd. De gemiddelde "cold build" (het inpakken van een box vanaf nul) duurt 8,84 minuten. Voor de grote trainingsboxen kan het meer dan 14 minuten duren. Dat is een lange tijd wachten om te zien of je code werkt.
Het "Oeps"-moment: Waarom we boxen weggooien
Hier komt het lastige deel. In een normale keuken pas je bij een nieuw recept gewoon de instructies aan. Maar in de ML-wereld werkt de keuken volgens een strikt "laag"-systeem. Stel je voor dat je een toren van blokken bouwt. Als je de kleur van het derde blok verandert, moet je het derde, vierde, vijfde blok en alle blokken tot aan de top eraf halen, zelfs als de bovenste blokken helemaal niet zijn veranderd.
De onderzoekers ontdekten dat 44,4% van alle wijzigingen die ontwikkelaars aan hun projecten aanbrachten, een totale rebuild van de container triggerde. Dat betekent dat ze bijna de helft van de tijd al dat harde werk weggooiden en weer bij af begonnen.
Wat veroorzaakte de rebuild?
Het was meestal niet het recept zelf (de Dockerfile). Het waren de ingrediënten!
- 96,4% van de rebuilds gebeurde omdat iemand een bestand veranderde dat in de box werd gekopieerd (zoals een dataset of een codebestand).
- Slechts 1,1% van de rebuilds kwam door een wijziging in de werkelijke instructies over hoe de box gebouwd moet worden.
De Verspilling: 70% van het werk is voor niets
Dit is het droevigste deel van het verhaal. Wanneer de "laag-toren" breekt, probeert de keuken de blokken die ze al gebouwd hebben te hergebruiken. Maar de onderzoekers ontdekten dat 71% van het werk verspild was.
- Denk er zo over na: Je besteedt 10 minuten aan het bouwen van een toren van blokken. Je stoot de derde blok om. Je probeert de eerste twee blokken te hergebruiken, maar dan moet je de rest van de toren opnieuw opbouwen. Uiteindelijk heb je slechts ongeveer 30% van je inspanning hergebruikt. De andere 70% was gewoon het opnieuw doen van werk dat je al had gedaan.
Waarom gebeurt dit?
Het hangt ervan af wat je aan het veranderen bent.
- Als je de experiment aanpast (het brein of de data van de AI verandert), is de kans het grootst dat je de toren breekt. Dit gebeurt 46% van de tijd voor trainingsboxen.
- Als je de infrastructuur bijwerkt (zoals de leidingen of de elektriciteit van de keuken), verbreek je bijna altijd de toren en verlies je bijna al je voortgang.
Het goede nieuws: Slimme chefs vonden kortroutes
Ondanks de chaos ontdekten de onderzoekers dat sommige slimme chefs deze problemen al aan het oplossen waren. Ze keken naar de "beste" keukens (die de minste tijd verspillen) en vonden 7 specifieke trucs die zij gebruikten om de verspilling te stoppen. Dit zijn geen gissingen; het zijn echte wijzigingen die ontwikkelaars hebben doorgevoerd en die daadwerkelijk werkten.
Hier zijn de 7 trucs:
- Pak de boodschappen niet in: In plaats van enorme datasets in de box te kopiëren, vertel je de box gewoon waar hij ze kan vinden wanneer hij begint te koken.
- Pak het model niet in: Hetzelfde geldt voor het AI-model zelf. Bak het niet in de box; laad het van buitenaf wanneer het nodig is.
- Verplaats het zware werk: Als je een groot model moet downloaden, doe dat dan vroeg in het recept. Op die manier blijft de grote download gecached (opgeslagen) als je later een klein bestand wijzigt.
- Splits de keuken: Als je een box nodig hebt voor zowel CPU's als GPU's, maak dan niet één gigantische box met alles erin. Maak twee kleinere, gespecialiseerde boxen.
- Kies de juiste tools: Installeer niet de "GPU-versie" van een tool als je alleen de "CPU-versie" nodig hebt. Het bespaart een enorme hoeveelheid ruimte.
- Verplaats de vluchtige zaken: Als je vaak je configuratiebestanden aanpast, zet deze dan na de grote installaties in het recept, zodat ze de zware lagen niet breken.
- Download niet de hele geschiedenis: Wanneer je code van het internet haalt, download dan niet de volledige geschiedenis van het project. Pak alleen de laatste snapshot.
De essentie
Het paper zegt niet dat deze problemen "opgelost" zijn. Het zegt dat ML-containers op dit moment enorm, traag en fragiel zijn. Ontwikkelaars verspillen een enorme hoeveelheid tijd (ongeveer 70% van hun rebuild-inspanning) omdat ze te veel spullen in de box stoppen en de cache te vroeg verbreken.
Maar het goede nieuws is dat we weten hoe we het kunnen oplossen. Door deze 7 trucs te gebruiken, kunnen teams hun containers kleiner en hun builds sneller maken. Het is geen magie; het is gewoon betere organisatie. De onderzoekers hebben dit alles gemeten door de boxen daadwerkelijk te bouwen en de minuten te tellen, dus we weten dat deze cijfers echt zijn. De volgende keer dat je een machine learning-project ziet, onthoud dan: het gaat niet alleen om de code; het gaat ook om hoe je de keuken inpakt.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.