8 Minutės
Microsoft, pagal pranešimus, kuria konversijos įrankių rinkinius, leidžiančius paleisti CUDA pagrįstus dirbtinio intelekto (DI) modelius ant AMD GPU. Tikslas – sumažinti inferencijos kaštus ir mažinti priklausomybę nuo NVIDIA CUDA ekosistemos. Toks sprendimas gali pakeisti debesų paslaugų teikėjų GPU pasirinkimus didelio masto inferencijos (modelių vykdymo produkcijoje) aplinkose.
Kodėl Microsoft domisi AMD inferencijai
Debesų paslaugų teikėjai ir hyperscaleriai vis dažniau atskiria modelių mokymą (training) nuo inferencijos (inference). Mokymas dažnai reikalauja greičiausios ir labiausiai optimizuotos įrangos, tačiau inferencijoje – t. y. modelių paleidime produkcijoje – vėl iškyla kaštų ir efektyvumo prioritetai. Microsoft per savo Azure platformą aptarnauja didžiulį kiekį inferencijos užklausų, todėl pigesni AMD AI akceleratoriai gali būti patraukli alternatyva brangesnėms NVIDIA kortoms.
Tačiau ekonomiškumas turi prasmę tik tuo atveju, jei esami CUDA apmokyti modeliai gali veikti ant AMD aparatūros be didelių perrašymų. Pagal ataskaitas, Microsoft kuriami įrankių rinkiniai siekia užpildyti šią spragą: jie konvertuotų arba nukreiptų CUDA skambučius į ROCm suderinamas funkcijas, kad modeliai būtų vykdomi ant AMD GPU.
Tai reiškia, kad įmonės gali bandyti perkelti inferencijos darbo krūvius į pigesnius AMD instancus Azure debesyje, išlaikant esamus modelius ir integracijas kiek įmanoma nepakitusiais. Ši strategija tiesiogiai siejasi su infrastruktūros optimizavimu, GPU debesijos kainodara ir debesų sąnaudų valdymu (cloud cost optimization).
Kaip veikia šie įrankiai — pragmatiškas vertimo sluoksnis
CUDA užraktas (vendor lock-in) nėra lengvai sutramdomas. CUDA ekosistema plačiai priimta, o daugelis produkcinių vamzdynų (production pipelines) priklauso nuo NVIDIA optimizuotų bibliotekų, pvz., cuBLAS, cuDNN ar TensorRT. Vienas iš pragmatiškų sprendimų yra paleidimo laiko (runtime) suderinamumo sluoksnis, kuris užfiksuoja CUDA API kvietimus ir atvaizduoja juos į ROCm ekvivalentus vykdymo metu. Ankstesnės priemonės, tokios kaip ZLUDA, tyrinėjo šį kelią, verčiant kvietimus be būtinybės persikompliuoti visą šaltinį.
Microsoft vidiniai įrankių rinkiniai, kaip pranešama, seka panašiu keliu: konvertuoti arba nukreipti CUDA kvietimus į ROCm arba kitus AMD rinkinį palaikančius sluoksnius. Techninėms sistemoms tai gali reikšti keletą galimų implementacijų: API iškilimų (interception) sluoksnis, dinaminė bibliotekų peradresacija, arba Hipify / LLVM pagrindu veikianti tarpinė kompilacija, kuri pakeičia CUDA specifinius kvietimus į universalesnius ar ROCm suderinamus atitikmenis.
Praktikoje tai apima kelis svarbius komponentus: vieną — CUDA API žemėlapius į ROCm komponentus (pvz., cuBLAS → rocBLAS, cuDNN → MIOpen), antrą — draiverių ir atminties valdymo koordinavimą, trečią — optimizuotų branduolių (kernels) atitikmenų ar jų emuliaciją. Taip pat svarbu integruoti tai su aukšto lygmens ML karkasais (frameworks) — PyTorch, TensorFlow, JAX ir pan. — kad mokymui (training) gunakančius modelius būtų galima kuo sklandžiau paleisti inferencijoje be papildomų modifikacijų modelių architektūroje.
Tokių įrankių techninės galimybės gali būti įvairios: nuo pilnos vartotojo bibliotekos peradresacijos iki kodo transformacijos, kuri pakeičia CUDA specifinius šauksmus į HIP ar ROCm atitiktis. HIP (Heterogeneous-Compute Interface for Portability) yra AMD palaikomas tarpinis sluoksnis, kuris leidžia perrašyti CUDA kodą su mažiau rankinių pakeitimų; kartu yra ir automatinės priemonės (hipify), kurios padeda konvertuoti C++/CUDA kodą į HIP.
Be to, kuriant runtime vertimo sluoksnį, būtina užtikrinti, kad atminties tvarkymas, sinchronizacija, srauto (stream) logika ir asmeniniai optimizavimo modeliai veiktų taip, kad nebūtų reikšmingų našumo nuostolių. Tai reikalauja detalaus testavimo, profiliavimo (profiling) ir dažnai – aparatūros lygiu atliktų optimizacijų kartu su AMD inžinieriais.
Ne viskas sprendžiama vienu mostu — suderinamumo ir našumo įspėjimai
ROCm vis dar bręsta lyginant su ilgalaike CUDA brandu. Ne visi CUDA API kvietimai ar optimizuoti branduoliai turi tikslų vienetą ROCm pasaulyje. Kai kuriais atvejais vertimas gali sumažinti našumą arba netgi sulaužyti sudėtingus darbo krūvius, ypač tuos, kurie priklauso nuo žemo lygio optimizacijų ar specifinių NVIDIA aparatūros savybių (pvz., Tensor Core panašios konstrukcijos arba specializuoti asmeniniai branduoliai).
Todėl Microsoft, matyt, įveda šiuos įrankius atsargiai: juos bando kontroliuojamose aplinkose, taiko fazinį diegimą ir bendradarbiauja su AMD siekdami aparatūros bei draiverių optimizacijų. Tai rodo, kad įmonė bando subalansuoti galimus išlaidų mažinimo privalumus su verslo lygmens stabilumo ir prognozuojamumo reikalavimais, kurių reikalauja duomenų centrai ir klientai.
Be našumo klausimų, yra ir kiti rizikos veiksniai: skaitinių skirtumų (numerical differences) tarp bibliotekų, ne visiška parama mixed-precision režimams (FP16/FP32 arba BF16), bei skirtumai atminties tvarkant labai didelius modelius (model parallel ir tensor sharding sprendimai). Visi šie aspektai gali turėti įtakos modelio tikslumui, latencijai ir galutiniam vartotojo patyrimui.
Ką tai reiškia debesų klientams ir GPU rinkai
- Mažesnės inferencijos išlaidos: jei įrankiai veiks mastu, organizacijos galėtų daugiau inferencijos užduočių perkelti į AMD pagrįstas instancijas ir sumažinti užklausos vieneto kaštą.
- Didesnė tiekėjų įvairovė: patikima CUDA->ROCm konversija sumažintų CUDA užraktą, suteiktų debesų klientams derybinį pranašumą ir lankstumą pasirenkant GPU tiekėją.
- Palaipsnė migracija: tikėtinos fazinės migracijos – pirmiausia paprastesni modeliai ir batch inferencija, o realaus laiko kritinės sistemos gali būti perkeltos vėliau, kai įrankių rinkiniai ir optimizacijos subręs.
Įsivaizduokite galimybę perkelti didžiąją inferencijos dalį į pigesnę aparatūrą be būtinybės perrašyti modelių – tai ir yra pagrindinis pažadas. Tačiau realybė priklausys nuo to, kiek plačiai ROCm sugebės atkartoti CUDA našumo profilį, kiek greitai Microsoft ir AMD uždarys likusius suderinamumo tarpus ir kaip spartus bus įrankių atnaujinimas bei palaikymas.
Priklausomai nuo to, kaip sėkmingai vyks integracija, rezultatas gali paskatinti platesnį heterogeniškų GPU ekosistemos plitimą debesyse. Tai reikštų, kad debesis paslaugų teikėjai, tokie kaip Azure, AWS ar Google Cloud, galėtų pasiūlyti platesnį spektrą GPU instancijų – tiek NVIDIA, tiek AMD – leidžiant klientams rinktis pagal kainos ir našumo santykį.
Verslo perspektyva taip pat įtraukia sutartinius aspektus: didesnė tiekėjų konkurencija gali paveikti kainodarą, suteikti geresnes SLA sąlygas ir paskatinti optimizacijų plėtrą. Tačiau svarbu paminėti, kad daugeliui įmonių svarbus ne tik vienetinės užklausos kaštas, bet ir prognozuojama latencija, atminties talpa, tinklo topologija bei integracijos su egzistuojančiais devops/MLops procesais paprastumas.
Techniniai vadovai ir infrastruktūros inžinieriai turėtų atlikti kruopščius bandymus ir palyginimus (benchmarking), apimančius realius modelius ir darbo krūvius, kad įvertintų migracijos privalumus bei rizikas. Pilnas perėjimas dažnai prasideda nuo hibridinių modelių, kur dalis darbo krūvių lieka NVIDIA, o kitos užklausos – AMD platformose, priklausomai nuo jautrumo našumo ir kainos atžvilgiu.
Ilgalaikėje perspektyvoje tokie įrankiai taip pat gali paskatinti ekosistemos plėtrą: daugiau įrankių optimizavimui, daugiau trečiųjų šalių sprendimų, skirtų konvertavimui ir profiliavimui, bei daugiau AMD orientuotų kūrėjų bendruomenės indėlio. Tai galėtų sumažinti priklausomybę nuo vieno tiekėjo ir padidinti inovacijų tempą GPU srityje.
Galiausiai, Microsoft pastangos atspindi platesnį pramonės pokytį: inferencijos apimtys sparčiai auga, ir efektyvi aparatūra tampa svarbesnė nei bet kada anksčiau. Jei konversijos įrankių rinkiniai pasieks plačią praktinę pritaikomumą, tai gali būti reikšmingas žingsnis link heterogeniškesnės GPU aplinkos debesyje ir platesnio konkurencingumo tarp aparatūros tiekėjų.
Tačiau svarbu pabrėžti: tai nėra magiškas sprendimas, kuris akimirksniu išspręs visas problemas. Tokio tipo branduolinės konversijos reikalauja ilgalaikio darbo, testavimo, palaikymo ir glaudaus bendradarbiavimo tarp programinės ir aparatinės įrangos tiekėjų bei debesų operatorių. Organizacijos, galvojančios apie migraciją, turi parengti aiškią strategiją: pilotai, etapai, testavimo rinkiniai, ir aiškūs metrikų kriterijai, kurie nustatytų, kada perkelti darbalinkes į AMD infrastruktūrą.
Apibendrinant, Microsoft iniciatyva sukurti CUDA->ROCm konversijos įrankius yra ne tik techninis bandymas, bet ir strateginis žingsnis link didesnio kainos ir tiekėjų pasirinkimo debesų dirbtinio intelekto aplinkoje. Sekančiais mėnesiais ir metais verta stebėti, kaip šie įrankiai vystysis, kiek plačiai juos priims Azure klientai ir kaip tai veiks visos GPU rinkos dinamiką.
Šaltinis: wccftech
Palikite komentarą