AWS tõi TorchNeuroni avalikku beetasse: PyTorchi portimine Trainiumile lihtsustub

AWS avas PyTorchi kasutajatele lihtsama tee oma Trainiumi kiipidele. TorchNeuron lisab riistvara PyTorchi taustsüsteemiks, mistõttu saab toetatud koodi suunata seadmele „neuron”. PyTorchi 19. oktoobri tehniline teade kirjeldas järgmiseks päevaks kavandatud väljalaset; AWS-i 20. oktoobri teadaanne kinnitab, et avalik beeta käivitati.

Seega on uudise staatus 21. oktoobriks muutunud: tegu ei ole enam ainult eelteatega, kuid ka mitte pika tootmisajalooga stabiilse lahendusega. Esialgne tugi hõlmab eager-režiimi, torch.compile’i ja kohandatud kernelite jaoks Neuron Kernel Interface’i. PyTorchi teates on samas selge loetelu funktsioonidest, mida esimene väljalase ei toeta.

Reuters käsitleb sammu katsena vähendada Nvidia tarkvaraökosüsteemi eelist. Arendaja jaoks on konkreetsem küsimus, kas uue riistvara proovimine nõuab vähem ümberkirjutamist. Buildrya analüüsis tuleks järgmine otsus teha mudeli portimise töö, väljundite kvaliteedi ja kogu töökoormuse hinna põhjal.

Tuttav liides vähendab esimest üleminekutõket

Mudeli käivitamine teisel kiibil tähendab tavaliselt mitut eraldi ülesannet: koodi tööle saamist, tulemuse kontrollimist ja jõudluse häälestamist. TorchNeuron püüab eelkõige lihtsustada neist esimest. Sama raamistik ja tuttavad arendustööriistad võivad vähendada uut keskkonda õppimiseks kuluvat aega.

See on oluline ka siis, kui ettevõte ei plaani kohe kogu taristut vahetada. Väiksema algkuluga katse võimaldab saada päris võrdlusandmeid enne suurt lepingut või migratsiooni. Läbirääkimisjõudu annab kasutatav alternatiiv, mille sobivus on mõõdetud, mitte üksnes nimekiri turul olevatest kiipidest.

Samas pole PyTorchi liides ja konkreetse kiibi täitmiskäitumine üks ja sama asi. Kohandatud operatsioon, sõltuvus või kerneli eeldus võib siduda rakenduse senise platvormiga. Esimene edukas näide ei tõenda kogu mudelipargi ühilduvust.

Avalik beeta nõuab mudelipõhist ühilduvuskaarti

PyTorchi teates loetletud puuduvate funktsioonide seas on dünaamilised ja sümboolsed kujud, hõredad tensorid ning mitu muud operatsiooniklassi. Need piirangud ei tähenda, et tavapärane mudel tingimata ebaõnnestub. Need tähendavad, et mudeli tegelikud operatsioonid tuleb võrrelda toetatud võimalustega.

Piloot peaks alustama sõltuvuste ja kohandatud kernelite inventuurist. Seejärel saab eristada mudelid, mis töötavad seadmemäärangu muutmisega, mudelid, mis vajavad väikest kohandust, ning mudelid, mille portimine nõuab eraldi arendust. Selline kaart on otsustajale kasulikum kui üks edukas demonstratsioon.

Ka muudetud koodiridade arv on üksnes osaline mõõdik. Väike muudatus võib nõuda pikka valideerimist, kui see puudutab numbrilist täpsust või hajutatud treeningut. Seetõttu tuleks logida ka veaotsingule, testimisele ja dokumenteerimisele kulunud inseneritunnid.

Tööle minek ja tulemuste võrdsus on eri kontrollid

Kui mudel käivitub veata, tuleb järgmisena kontrollida väljundeid. Treeningu puhul võib võrrelda õppimiskõveraid ja lõplikku kvaliteeti; inferentsi puhul ülesande täpsust, stabiilsust ning lubatud numbrilist erinevust. Sobiv kriteerium sõltub rakendusest ja tuleb kokku leppida enne tulemuste nägemist.

Täpselt sama juhusliku tekstiväljundi nõudmine ei pruugi olla mõistlik, kuid ärilise vastuvõtukriteeriumi muutmine platvormide vahel rikuks võrdluse. Dokumenditöötluse mudel peab eraldama samad olulised väljad, otsingulahendus leidma vajaliku info ning koodimudel läbima samad sisulised kontrollid. Kiirem vale tulemus ei ole jõudlusvõit.

Hajutatud töö puhul tasub kontrollida ka taastumist katkestusest ja tulemuste korratavust. Tootmiskulu mõjutab, kui tihti tuleb pikk jooks uuesti alustada või sekkuda selle taastamisse. Ühildumine raamistikuga ei vabasta süsteemi neist töökindlusnõuetest.

Kiibi tunnihind ei näita portimise tasuvust

Kuluvõrdlus peaks hõlmama arvutusaega, andmete liigutamist, salvestust, vaba võimsuse ootamist ja inseneritööd. Ülemineku ühekordne kulu tuleb eristada igakuisest säästust. Vastasel juhul võib lühike hinnavõrdlus varjata seda, et väike töökoormus ei teeni migratsiooni kunagi tagasi.

Samuti tuleb võrrelda sama teenindustaset. Läbilaske maksimum ei pruugi sobida rakendusele, mis peab vastama kiiresti ka koormuse tippudes. Katse peaks seetõttu kasutama realistlikke sisendeid ja mõõtma nii tavapärast kui ka aeglasemate päringute latentsust.

Praegused teadaanded ei anna alust kinnitada ühegi Eesti ettevõtte konkreetset kokkuhoidu. Selle arvutamiseks oleks vaja tema mudelit, kasutusmahtu, lepingutingimusi ja piirkondlikku võimsust. Buildrya hinnangul on beeta kõige väärtuslikum just sellise ettevõttesisese võrdluse käivitajana.

Avatud lähtekood ei taga riistvarast sõltumatust

Apache 2.0 litsents lihtsustab tarkvara uurimist ja kasutamist, kuid mudeli töövoog võib ikkagi sõltuda platvormi teenustest. Teisaldatavust tuleks hinnata kogu lahenduses: mudelikood, andmed, treeningu kontrollpunktid, profileerimine ja kasutuselevõtu tööriistad. Ühe kihi avatus ei muuda teisi automaatselt vahetatavaks.

Eesti ja Euroopa meeskondadele, kes juba kasutavad AWS-i, võib praktiline samm olla ühe esindusliku mudeli piiratud katse. Esmalt tuleks määrata edukuse kriteerium, eelarve ja lõpetamistingimus. Alles seejärel on mõistlik otsustada, kas laiendada kasutust või jätta alternatiiv tulevaste versioonide ootele.

Edaspidi tasub jälgida toetatud operatsioonide lisandumist ja korduvaid tootmiskogemusi. Beeta tegelikku väärtust näitab see, kas eri meeskonnad saavad oma mudelid tööle mõistliku ajaga ning säilitavad kvaliteedi. Pressiteate „üks muudatus” on katse lähtekoht, mitte migratsiooni lõpparuanne.