33 prosentpoeng mer GPU-utnyttelse kom av rekkefølgen, ikke maskinvaren

53,6 til 87,0 prosent. Det er utnyttelsesgraden på en klynge med åtte GPU-er og 16 treningsjobber, før og etter, i det sterkeste av syv scenarioer Dharma AI har målt og beskrevet i et blogginnlegg på Hugging Face. Prioritetsvektet produksjon mer enn doblet seg i samme test, opp 105,1 prosent. Maskinvaren var den samme, jobbene var de samme. Det eneste som endret seg, var rekkefølgen beslutningene tas i.

Sammenlikningsgrunnlaget er en FIFO-basert planlegger: sanntidsinferens serveres fra en fast reservasjon, alt annet plasseres i den rekkefølgen det kom inn. Kostnaden ligger to steder. Reservasjonen må dimensjoneres etter dagens topp, så en applikasjon som trenger seks GPU-er midt på dagen og to klokka fire om natten, holder alle seks i 24 timer. Og under reell kapasitetskamp avgjør rekkefølgen ikke bare hvem som venter, men hvem som får plass i det hele tatt.

«Rekkefølge er ikke en tiebreaker du bruker etter at kapasitetsspørsmålet er avgjort. Rekkefølge er en kapasitetsbeslutning» — Dharma AI, i blogginnlegget på Hugging Face

Allokatoren behandler sanntidsetterspørsel som en kurve i stedet for et tak, og lar batch-jobber fylle bølgedalene. Straffen for udekket sanntidsetterspørsel er vektet 5 til 10 ganger høyere enn gevinsten ved å gi en GPU til batch-arbeid, og den asymmetrien er hele tjenestenivåpolitikken uttrykt som ett tall. Planen legges over et døgn, men bare inneværende tidssteg forpliktes, og alt kjøres på nytt hver 30. til 60. minutt. Heuristikken svarer på 1 til 2 millisekunder i de fem tettpakkede scenarioene, og 15 millisekunder på 64 GPU-er med 30 jobber.

To av testene svarer på den nærliggende innvendingen. I skalatesten var utnyttelsen identisk, 44,9 prosent begge veier, og like mange jobber ble ferdige, 27 av 30. Likevel leverte allokatoren 15,9 prosent mer prioritetsvektet verdi. Og i en test der alle jobber fikk lik prioritet, altså uten noe prioritetssignal å sortere etter, steg utnyttelsen fra 76,8 til 87,5 prosent. Gevinsten kommer ikke bare av å sortere etter prioritet.

Tallene er Dharma AIs egne, målt i selskapets egne benchmark-scenarioer og ikke etterprøvd av andre. Hele modellen hviler dessuten på at etterspørselsprognosene stemmer. Selskapet bruker 22 variabler i treningsprognosen, blant annet en kategorisk variabel som skiller mellom ti konkrete treningsvarianter, fordi LoRA kutter antall trenbare parametre med opptil 10 000 ganger og GPU-minnet omtrent tre ganger mot full finjustering.

Kjører du din egen klynge, eller bare noen få kort, er poenget likevel overførbart: utnyttelsesgrad alene sier ingenting om hva klyngen faktisk produserer. To oppsett kan fylle nøyaktig like mye GPU-tid, gjøre ferdig like mange jobber, og levere ulikt utbytte, avhengig av hva som fikk plass først.