Tiksliojo derinimo valdymo platformos: daugelio modelių ir daugelio debesų orkestravimas

Įvadas

Įmonėms kuriant ir pritaikant dirbtinio intelekto (DI) modelius, jos susiduria su rimtais sunkumais dėl fragmentacijos. Duomenys, eksperimentai ir modeliai dažnai yra išsklaidyti skirtingose priemonėse ar debesyse, o tai apsunkina darbą. Viename projekte gali būti naudojamas vienas debesis duomenims, kitas – apmokymui, o dar kita paslauga – modelio vykdymui. Dėl tokios sąrankos sudėtinga rinkti duomenis, sekti eigą ir diegti tiksliai suderintus modelius. Neturėdamos centrinio plano, komandos žongliruoja skaičiuoklėmis, daugybe prietaisų skydelių ir individualizuotais scenarijais. To pasekmė – lėti atnaujinimai, klaidos ir iššvaistyti pinigai.

Šiame straipsnyje paaiškinamos šios problemos ir parodoma, kaip gali padėti vieninga valdymo plokštuma. Ši valdymo plokštuma vienoje vietoje tvarko duomenų rinkinių kuravimą, saugumo patikrinimus, eksperimentų stebėjimą ir modelių versijavimą. Ji taip pat valdo politikas (pvz., kas gali patvirtinti naujus modelius) ir būdus, kaip atšaukti blogus pakeitimus. Aptarsime, kaip optimizuoti išlaidas įvairiuose debesyse ir techninėje įrangoje, ir kaip DI platforma gali nustatyti kainodarą, pagrįstą naudojimu. Galiausiai aptarsime įmonės priedus (papildomas funkcijas ir palaikymą) ir tai, kaip partnerystės su modelių tiekėjais ir GPU teikėjais gali sustiprinti platformą.

Fragmentacijos problemos

Duomenų fragmentacija

Įmonės dažnai saugo duomenis daugybėje debesų ar sistemų. Kiekvienas debesis turi skirtingus formatus ir įrankius. Tai sukuria duomenų silosus – izoliuotas informacijos kišenes. Kaip pažymi viena ataskaita, „visur besidauginantys duomenų silosai“ slepia visą jūsų duomenų vaizdą (nam-it.com). Kai duomenys išsklaidyti, ataskaitos ir analizė tampa sudėtingos. Negalite lengvai derinti duomenų ar matyti bendrų tendencijų. Pavyzdžiui, jei apmokymo duomenys yra AWS, o testavimo duomenys – Azure, sunku juos sinchronizuoti. Tai lėtina plėtrą ir didina riziką, kad jūsų DI modelis mokysis iš neteisingų duomenų.

Fragmentuoti įrankiai ir dujotiekiai

Fragmentuoti yra ne tik duomenys, bet ir mašininio mokymosi (MM) įrankiai. Kiekvienas debesies paslaugų teikėjas (pvz., AWS, Azure ar Google Cloud) turi savo MM paslaugas ir API (www.neticspace.com). Naudojant du debesis, gali reikėti dviejų komandų ir prietaisų skydelių rinkinių. Jei apmokote viename debesyje, o diegiate kitame, veiksmai gali labai skirtis. Šis vienodumo trūkumas gali sukelti klaidų perkeliant modelius tarp debesų. Be to, sunku sekti eksperimentus, nes kiekviena komanda gali naudoti skirtingus stebėjimo įrankius ar skaičiuokles. Kaip paaiškino vienas ekspertas, daugelio debesų sąrankos įveda „sudėtingumo integracijos, saugumo ir atitikties srityse“ (www.neticspace.com). Praktiškai tai dažnai reiškia, kad komandos rašo „lipnų kodą“ (glue code) arba naudoja rankinius procesus viskam sujungti, o tai yra lėta ir pažeidžiama.

Neaiškus eksperimentų stebėjimas ir modelių versijos

Eksperimentų stebėjimas yra gyvybiškai svarbus modelio kūrimo procese, tačiau jis dažnai atliekamas fragmentiškai. Duomenų mokslininkai gali išbandyti pataisymą viename užraše, o po to kitą pataisymą – kitoje aplinkoje. Be centralizuotos sistemos sunku sekti, kuris pakeitimas davė geresnius rezultatus. Yra rizika prarasti progresą arba pakartotinai atlikti testus. Taip pat kaupiasi modelių versijos. Galite turėti dešimtis modelio svorių failų, pavadintų, pavyzdžiui, „final_v3_stable_copy2.pt“, skirtinguose aplankuose. Stebėti naujausią versiją – ir kuris duomenų rinkinys bei nustatymai ją sukūrė – tampa košmaru.

Svarbi problema yra ir saugumo filtravimas. Apmokymo duomenis reikia valyti (pavyzdžiui, pašalinti asmens duomenis ar toksišką turinį). Dažnai šis filtravimas yra ad-hoc, t. y. vienas inžinierius tai daro rankiniu būdu arba naudodamas paprastus scenarijus. Jei taisyklės keičiasi (galbūt atsiranda nauji privatumo įstatymai), atnaujinti visus dujotiekius yra didelis darbas. Vienu požiūriu, dauguma MM dujotiekių yra „netvarkingi, neišsamūs arba neatitinkantys reikalavimų – keliantys riziką tikslumui, privatumui ir saugumui“ (bigid.com). Tai pabrėžia nuoseklaus duomenų valymo ir saugumo patikrinimų poreikį.

Vieninga valdymo plokštuma

Norėdami išspręsti šias problemas, įsivaizduokite valdymo plokštumą – centrinę sistemą, kuri viską orkestruoja. Ši sistema veikia virš visų debesų ir įrankių, suteikdama vieną sąsają duomenims, eksperimentams, modeliams ir politikoms. Ji veikia kaip smegenys, jungiančios MM darbo eigos dalis. Tokia valdymo plokštuma apimtų:

• Duomenų rinkinių kuravimas: Rinkite ir paruoškite duomenis vienoje vietoje. Vartotojai gali pridėti naujų duomenų rinkinių į bendrą saugyklą. Sistema gali priskirti žymas, padalinti duomenis apmokymui/validavimui ir pašalinti netinkamą turinį. Pavyzdžiui, platforma galėtų naudoti semantinę paiešką, kad rastų atitinkamus duomenis ir automatiškai išvalytų jautrias ar toksiškas dalis (bigid.com). Visi duomenys pereina vienodą dujotiekį, todėl kiekviena komanda naudoja tuos pačius aukštos kokybės įvesties duomenis.
• Saugumo filtravimas: Duomenims patekus į sistemą, jie tikrinami dėl atitikties ir saugumo. Valdymo plokštuma gali naudoti automatizuotus skaitytuvus asmens duomenims, autorių teisių saugomam turiniui ar uždraustoms temoms. Pritaikus šias taisykles įkėlimo metu, užtikrinama, kad visi duomenys yra švarūs. Vieningas filtras padeda komandoms išvengti ad-hoc pataisymų ir palaiko privatumo įstatymus (pvz., BDAR). Jis taip pat gali žymėti visus abejotinus duomenis, kad jų negalima būtų naudoti apmokymui be peržiūros.
• Eksperimentų stebėjimas: Kiekvienas apmokymo vykdymas yra automatiškai registruojamas platformoje. Tai apima duomenų rinkinio versijas, parametrų nustatymus, kodo versijas ir metrikas. Vietoj išsklaidytų užrašų, kiekvienas eksperimentas yra viename prietaisų skydelyje. Tai palengvina vykdymų palyginimą. Tai taip pat reiškia, kad rezultatai neprarandami, kai mokslininkas išeina arba serveris persikrauna.
• Modelių versijavimas: Platforma struktūrizuotai seka modelių versijas. Kiekvieną kartą, kai modelis baigia apmokymą, sistema priskiria versijos numerį ir įrašo metaduomenis. Komandos tada gali atgauti bet kurią versiją kartu su jos detalėmis. Tai panašu į programinės įrangos versijų valdymą, tik modeliams. Sistemos, tokios kaip MLflow, suteikia šią galimybę: ji siūlo sistemingą versijų valdymą, kad „nustotumėte prarasti tai, kas veikia“ (mlflow.org). Gera valdymo plokštuma integruotų tokius įrankius, galbūt net susiejant su „Git“ įsipareigojimais ar „Docker“ atvaizdais.
• Politikos vykdymas: Šis modulis užtikrina, kad būtų laikomasi taisyklių. Pavyzdžiui, jis galėtų užkirsti kelią modelių, kurie naudojo nepatvirtintus duomenis, diegimui. Jis taip pat valdo patvirtinimo darbo eigą: kas turi patvirtinti, kol modelis bus paleistas? Leidimai ir auditai yra registruojami. Pavyzdžiui, „Dataiku“ administratoriai gali reikalauti „suinteresuotųjų šalių patvirtinimo dėl modelių versijų“ prieš diegimą (doc.dataiku.com). Valdymo plokštuma gali automatizuoti šiuos patvirtinimus, siųsti pranešimus recenzentams ir saugoti įrašus apie tai, kas, ką ir kada patvirtino. Jei įdiegtas modelis sukelia problemų, sistema gali grįžti prie ankstesnės patvirtintos versijos, naudodama užregistruotą kilmę.

Centralizuodama šias funkcijas, valdymo plokštuma pašalina daug rankinio darbo. Ji suteikia vieną bendrą vaizdą į projektus. Komandoms nereikia atskirų skaičiuoklių ar „gentinių žinių“. Pavyzdžiui, jei duomenų mokslininkas pereina į kitą debesį arba prisijungia naujas komandos narys, jis tiesiog naudoja valdymo plokštumos sąsają. Platforma skatina nuoseklumą ir palengvina vadovams geriausios praktikos diegimą.

Išlaidų optimizavimas debesyse ir techninėje įrangoje

Dirbtinio intelekto vykdymas keliuose debesyse gali būti brangus. Kiekvienas debesis ir kiekvienas GPU tipas turi savo kainą. Be priežiūros vienas projektas gali palikti didžiulius klasterius tuščiai veikti arba mokėti didelius GPU įkainius pagal pareikalavimą.

Išmani platforma turėtų optimizuoti išlaidas. Tai gali apimti:

• Automatinis mastelio keitimas ir tinkamas dydžio parinkimas: Platforma gali stebėti naudojimą ir paleisti arba išjungti išteklius. Ji gali pradėti nuo kelių GPU ir pridėti daugiau tik tada, kai reikia. Automatiškai pritaikius mastelį pagal faktinį apkrovimą, išvengiama perteklinio aprūpinimo. Tai panašu į debesies paslaugų teikėjų patarimus: naudokite įrankius (AWS Cost Explorer ir kt.) ir mastelio keitimo taisykles, kad išvengtumėte iššvaistymo (www.neticspace.com).
• Momentiniai (spot) ir rezervuoti instancai: Daugelį debesies GPU galima gauti su nuolaida, jei jie naudojami lanksčiai. Platforma galėtų bandyti naudoti momentinius instancus (pigiau, bet gali būti nutraukti) nekritiniams darbams. Nuspėjamiems darbo krūviams ji galėtų pasiūlyti rezervuotus instancus. Kitaip tariant, ji derina GPU pirkimo galimybes, kad sumažintų išlaidas.
• Daugelio debesų paskirstymas: Kai kurie debesys gali pasiūlyti pigesnį GPU laiką arba nemokamus kreditus. Valdymo plokštuma gali palyginti kainas tarp skirtingų tiekėjų. Pavyzdžiui, jei AWS GPU yra užimti arba brangūs, ji gali vykdyti užduotį GCP arba specializuotame GPU debesyje. „Turion“ tinklaraštis siūlo tokius modelius kaip „active-active across clouds“, kad būtų išvengta užrakinimo ir būtų naudojamos geriausios kainos (turion.ai).
• Optimizuotas planavimas: Dideliems modeliams užduoties padalijimas tarp mažesnių GPU arba darbo paskirstymas gali būti efektyvesnis. Platforma gali nuspręsti, kokia techninė įranga yra geriausia. Kaip nustatė vienas mokslinis straipsnis, išmanus apmokymo darbo krūvių orkestravimas gali sumažinti DI infrastruktūros išlaidas 40–70% vien architektūros pasirinkimų dėka (hub.stabilarity.com). Tai apima tokius sprendimus kaip GPU skaidymas arba užduočių laikas.
• Finansų operacijų (FinOps) valdymas: Galiausiai, norint sekti išlaidas, reikalingas išlaidų modelis. Platforma galėtų rodyti išlaidų prietaisų skydelius pagal projektą ar komandą. Įspėjimai galėtų pranešti, kai viršijami biudžetai. Ši finansinė priežiūra užtikrina, kad išlaidos neaugtų nepastebimai.

Kartu šios funkcijos padeda įmonėms gauti maksimalų DI skaičiavimo pajėgumą už savo pinigus. Vietoj to, kad kiekviena komanda optimizuotų atskirai, valdymo plokštuma koordinuoja visos įmonės mastu. Ji gali integruotis su debesies atsiskaitymo API, kad automatiškai priskirtų išlaidas kiekvienai komandai ar projektui.

Valdymas: patvirtinimai ir atšaukimai

Didelėse organizacijose DI modelio diegimas nėra tik techninis veiksmas; tam reikalingas valdymas. Prieš paleidžiant modelį, žmonėms gali reikėti peržiūrėti jo našumą ir saugumą. Be to, jei kažkas nutinka, sistema turėtų greitai grįžti į saugią būseną.

Valdymo plokštumos valdymo lygmuo tai tvarko:

• Patvirtinimo darbo eigos: Kai nauja modelio versija yra paruošta, sistema gali ją nusiųsti paskirtiems recenzentams. Tai gali būti duomenų mokslininkai, vadovai, teisininkai ar etikos pareigūnai. Platforma gali rodyti modelio našumo metrikas, duomenų kilmę ir rizikos vertinimą. Recenzentai tada gali patvirtinti arba atmesti modelį. Pavyzdžiui, „Dataiku“ turi įmontuotą „Diegimo valdymą“ (Deploy Governance), kur suinteresuotosios šalys patvirtina modelius (doc.dataiku.com). Valdymo plokštuma registruotų šiuos patvirtinimus kaip dalį modelio istorijos. Joks modelis nebūtų paleistas be reikiamų patvirtinimų.
• Audito takai: Kiekvienas veiksmas (duomenų įkėlimas, eksperimento vykdymas, modelio pakeitimas) registruojamas su laiko žyma ir vartotojo ID. Šis audito takas yra labai svarbus atitikčiai. Jei auditoriai paklaus „kas pakeitė modelį lapkritį?“, atsakymas yra pasiekiamas vienu paspaudimu.
• Atšaukimai (Rollback): Jei nustatoma, kad įdiegtas modelis yra klaidingas arba šališkas, valdymo plokštuma gali grįžti prie ankstesnės patvirtintos versijos. Kadangi kiekviena modelio versija yra saugoma ir registruojama, tai yra paprasta. Platforma galėtų automatiškai atšaukti blogo modelio diegimą ir iš naujo įdiegti ankstesnį. Sprendimai šioje srityje reklamuoja tokias funkcijas: pavyzdžiui, „iTuring ML Ops“ žada „integruotus patvirtinimus, kilmę, atšaukimus ir audito paketus“, kad modeliai taptų „saugiais, valdomais galiniais taškais“ (ituring.ai). Atšaukimo logikos įdiegimas reiškia, kad net jei modelis veikia netinkamai, žmonių komandos gali greitai atkurti paslaugą.
• Politikos vykdymas: Be patvirtinimų, valdymo plokštuma vykdo aukštesnio lygio politikas. Administratorius gali pareikšti, kad modeliai negali naudoti tam tikrų duomenų (pvz., sveikatos įrašų be sutikimo). Sistema patikrina automatiškai. Ji taip pat gali įdiegti kodavimo standartus dujotiekiuose arba reikalauti šifravimo raktų duomenų prieigai. Šios politikos tampa kodo taisyklėmis valdymo plokštumoje, todėl niekas netyčia nėra apeinamas.

Integruodama valdymą, platforma užtikrina, kad DI produktai ne tik veiktų, bet ir atitiktų įmonės taisykles bei reglamentus. Ji suteikia įmonės lygio griežtumą modelių diegimui.

Kainodara, įmonės priedai ir partnerystės

Kuriant šią sudėtingą platformą, reikia nuspręsti dėl verslo modelio ir ekosistemos:

• Kainodara pagal naudojimą: Pagrindinė platforma gali būti apmokestinama pagal suvartojimą. Tai reiškia, kad klientai moka už tai, ką naudoja: pavyzdžiui, už naudojamas skaičiavimo valandas, duomenų rinkinių saugojimą ar modelių diegimų skaičių. Tai atspindi pagrindines debesies paslaugas (AWS, Azure), kurios apmokestina už naudojimą. Kainodara pagal naudojimą yra populiari technologijų srityje: viena analizė nurodo, kad suvartojimo modeliai yra didžiulių pajamų pagrindas (AWS 90 mlrd. USD, Snowflake IPO 1,4 mlrd. USD) (ratekit.dev). DI platformai apmokestinimas už GPU valandą ar API iškvietimą padaro išlaidas skaidrias. Mažesni startuoliai gali mokėti nedaug, o didesnės įmonės plečiasi ir moka daugiau. Šis „mokėk-kiek-naudoji“ metodas taip pat leidžia įmonėms išbandyti platformą be didelių įsipareigojimų.
• Įmonės priedai: Be pagrindinės paslaugos, įmonėms gali būti parduodamos aukščiausios kokybės funkcijos. Šie priedai gali apimti pažangų saugumą (pvz., SSO integraciją arba „oro tarpo“ debesies palaikymą), prioritetinį palaikymą arba atitikties sertifikatus (SOC 2, ISO 27001). Kiti priedai galėtų būti aukščiausios kokybės įskiepiai, pvz., pasirinktinės jungtys prie įmonės duomenų saugyklų. Įmonės klientų kainodara dažnai apima fiksuotą mokestį už sąskaitų valdymą ir aukštesnius naudojimo lygius.
• Modelių tiekėjų partnerystės: Platforma gali bendradarbiauti su populiariais modelių teikėjais (pvz., Hugging Face, OpenAI, Anthropic). Pavyzdžiui, „NVIDIA“ ir „Hugging Face“ susivienijo, kad leistų kūrėjams naudoti „NVIDIA“ GPU didesniems kalbos modeliams tiksliai derinti (investor.nvidia.com). Valdymo platforma galėtų panašiai integruotis su tokiais modelių centrais, leisdama vartotojams sklandžiai importuoti ir apmokėti modelius. Tai naudinga klientams, suteikiant jiems daugiau iš anksto apmokytų modelių, kuriuos galima tiksliai derinti, ir naudinga tiekėjams, suteikiant jiems pardavimo kanalą.
• GPU tiekėjų partnerystės: Partnerystė su debesų ir techninės įrangos tiekėjais gali atrakinti nuolaidas ar specialias funkcijas. Pavyzdžiui, galima remtis specialiuoju GPU debesiu (CoreWeave, LambdaLabs) ir siūlyti šiuos išteklius per platformą. GPU gamintojai (NVIDIA, AMD) dažnai turi prekyviečių ar paskatų platformoms, kurios skatina naudojimą. Užmezgant oficialias partnerystes, valdymo platforma galėtų siūlyti techninės įrangos kreditus arba garantuoti naujausius GPU tipus. Tada klientai gauna geresnę kainodarą ir našumą.
• Apmokėjimas ir pajamų dalijimasis: Integruotiems modelių ir techninės įrangos partneriams platforma galėtų dalintis pajamomis. Jei vartotojas tiksliai derina „OpenAI“ modelius per platformą, dalis sąskaitos galėtų atitekti „OpenAI“. Jei jie naudoja partnerio GPU ūkį, platforma nuomoja tas mašinas. Naudojimu pagrįsto atsiskaitymo plėtiniai (pvz., Lago ar Usage.ai) gali automatizuoti šį sudėtingą atsiskaitymą.

Apibendrinant, verslas, susijęs su šia platforma, derintų mokėjimo už naudojimą kainodarą su pasirenkamais įmonės planais. Partnerystės plečia galimybes: daugiau modelių tiksliniam derinimui ir daugiau GPU pasirinkimų apmokymui. Kartu tai sudaro ekosistemą, kurioje platforma yra DI tiekėjų ir debesų paslaugų teikėjų tinklo centre.

Išvada

Šiandien sudėtinga valdyti daugelio modelių kūrimą keliuose debesyse. Duomenys ir įrankiai yra fragmentuoti, išlaidos sparčiai auga, o geras valdymas yra sunkus. Vieninga tiksliojo derinimo valdymo plokštuma gali išspręsti šias problemas. Centralizuodamos duomenų rinkinių kuravimą, saugumą, eksperimentų stebėjimą ir versijų valdymą, komandos dirba su vienu patikimu informacijos šaltiniu. Integruotos politikos taisyklės užtikrina, kad modeliai būtų patvirtinti ir saugūs. Išmanus planavimas ir daugelio debesų strategijos smarkiai sumažina išlaidas (www.neticspace.com) (hub.stabilarity.com). Galiausiai, naudojimu pagrįsta kainodara, įmonės priedai ir partnerystės su modelių/GPU teikėjais daro platformą praktiška ir keičiamo dydžio įvairaus dydžio įmonėms.

Šis požiūris supaprastina MTTP (mokslinius tyrimus ir plėtrą) ir suteikia sprendimų priėmėjams pasitikėjimo. Vietoj to, kad žongliruotų dešimtimis scenarijų ir kvitų, organizacijos naudoja vieną nuoseklią sistemą. Rezultatas – spartesnės inovacijos, mažesnės išlaidos ir DI modeliai, kurie atitinka politiką ir etiką.