Peenhäälestamise haldusplatvormid: mitmemudeliline ja mitmepilveline orkestratsioon

Sissejuhatus

Kui ettevõtted loovad ja kohandavad tehisintellekti mudeleid, seisavad nad silmitsi tõeliste probleemidega, mis tulenevad fragmentatsioonist. Andmed, eksperimendid ja mudelid asuvad sageli erinevates tööriistades või pilvedes, muutes töö keeruliseks. Üks projekt võib kasutada andmete jaoks ühte pilve, treeningu jaoks teist ja mudeli käitamiseks kolmandat teenust. Selline seadistus muudab andmete kogumise, edenemise jälgimise ja peenhäälestatud mudelite juurutamise segaseks. Ilma tsentraalse plaanita žongleerivad meeskonnad arvutustabelite, mitme armatuurlaua ja kohandatud skriptidega. Tulemuseks on aeglased uuendused, vead ja raisatud raha.

Käesolev artikkel selgitab neid kitsaskohti ja näitab, kuidas ühtne juhtimisplatvorm saab aidata. See juhtimisplatvorm haldab andmestike kureerimist, ohutuskontrolle, eksperimentide jälgimist ja mudelite versioonimist ühes kohas. Samuti haldab see poliitikaid (näiteks kes saab uusi mudeleid heaks kiita) ja võimalusi halbade muudatuste tagasipööramiseks. Käsitleme, kuidas optimeerida kulusid pilvede ja riistvara vahel ning kuidas tehisintellekti platvorm saab seadistada kasutusel põhineva hinnakujunduse. Lõpuks arutame ettevõtte lisandmooduleid (lisafunktsioonid ja tugi) ning kuidas partnerlused mudeli- ja GPU-tarnijatega saavad platvormi võimendada.

Fragmentatsiooni kitsaskohad

Andmete fragmentatsioon

Ettevõtted salvestavad andmeid sageli paljudes pilvedes või süsteemides. Igal pilvel on erinevad formaadid ja tööriistad. See loob andmesalved – isoleeritud teabetaskud. Nagu üks aruanne märgib, “andmesalvede paljusus kõikjal” varjab teie andmete tervikpilti (nam-it.com). Kui andmed on laiali, muutuvad aruandlus ja analüüs keeruliseks. Te ei saa hõlpsasti andmeid kombineerida ega üldisi trende näha. Näiteks kui treeningandmed on AWS-is ja testimisandmed Azure'is, on neid raske sünkroonis hoida. See aeglustab arendust ja suurendab riski, et teie tehisintellekti mudel õpib valedest andmetest.

Fragmenteeritud tööriistad ja protsessid

Mitte ainult andmed, vaid ka masinõppe tööriistad on fragmenteeritud. Igal pilveteenuse pakkujal (nagu AWS, Azure või Google Cloud) on oma masinõppe teenused ja API-d (www.neticspace.com). Kahe pilve kasutamine võib tähendada kahte käskude ja armatuurlaudade komplekti. Kui treenite ühes pilves ja juurutate teises, võivad sammud olla üsna erinevad. See ühtsuse puudumine võib põhjustada vigu mudelite pilvede vahel liigutamisel. Samuti muudab see eksperimentide jälgimise keeruliseks, sest iga meeskond võib kasutada erinevaid jälgimissüsteeme või arvutustabeleid. Nagu üks ekspert selgitas, toovad mitme pilve seadistused kaasa “keerukuse integreerimises, turvalisuses ja vastavuses” (www.neticspace.com). Praktikas tähendab see sageli, et meeskonnad kirjutavad kõige ühendamiseks liimkoodi või kasutavad käsitsiprotsesse, mis on aeglane ja habras.

Ebaselge eksperimentide jälgimine ja mudelite versioonid

Eksperimentide jälgimine on mudelite arenduses elutähtis, kuid seda tehakse sageli osade kaupa. Andmeteadlased võivad testida üht muudatust ühes märkmikus, seejärel proovida teist muudatust teises keskkonnas. Ilma tsentraliseeritud süsteemita on raske jälgida, milline muudatus andis paremaid tulemusi. On oht kaotada tehtud töö või korrata teste. Samamoodi kuhjuvad mudelite versioonid. Teil võib olla kümneid mudelite kaalude faile nimedega nagu “final_v3_stable_copy2.pt” erinevates kaustades. Uusima versiooni – ja millise andmestiku ning seadetega see toodeti – jälgimine muutub õudusunenäoks.

Oluline probleem on ka ohutusfiltreerimine. Treeningandmeid on vaja puhastada (näiteks isikuandmete või mürgise sisu eemaldamine). Sageli on see filtreerimine ad-hoc, mis tähendab, et üks insener teeb seda käsitsi või lihtsate skriptidega. Kui reeglid muutuvad (võib-olla uued privaatsusseadused), on kõigi protsesside uuendamine suur töö. Ühe vaatenurga kohaselt on enamik masinõppe protsesse “segased, mittetäielikud või mittenõuetekohased — seades ohtu täpsuse, privaatsuse ja ohutuse” (bigid.com). See rõhutab vajadust järjepideva andmete puhastamise ja ohutuskontrolli järele.

Ühtne juhtimisplatvorm

Nende probleemide lahendamiseks kujutage ette juhtimisplatvormi — tsentraalset süsteemi, mis orkestreerib kõike. See süsteem asub kõigi pilvede ja tööriistade kohal, pakkudes ühtset liidest andmetele, eksperimentidele, mudelitele ja poliitikatele. See toimib ajust, mis ühendab masinõppe töövoo osi. Selline juhtimisplatvorm hõlmaks:

• Andmestiku kureerimine: Andmete kogumine ja ettevalmistamine ühes kohas. Kasutajad saavad lisada uusi andmestikke jagatud hoidlasse. Süsteem saab rakendada silte, jagada andmeid treeninguks/valideerimiseks ja eemaldada halba sisu. Näiteks võiks platvorm kasutada semantilist otsingut asjakohaste andmete leidmiseks ja automaatselt eemaldada tundlikud või mürgised osad (bigid.com). Kõik andmed läbivad ühtse protsessi, nii et iga meeskond kasutab samu kvaliteetseid sisendeid.
• Ohutusfiltreerimine: Süsteemi sisenedes kontrollitakse andmete vastavust ja ohutust. Juhtimisplatvorm võib kasutada automatiseeritud skannereid isikuandmete, autoriõigustega kaitstud sisu või keelatud teemade jaoks. Nende reeglite jõustamisega üleslaadimise ajal tagab see, et kõik andmed on puhtad. Ühtne filter aitab meeskondadel vältida ad-hoc parandusi ja toetab privaatsusseadusi (nagu GDPR). Samuti saab see märgistada kõik kahtlased andmed, nii et neid ei saa ilma ülevaatamiseta treeninguks kasutada.
• Eksperimentide jälgimine: Platvorm logib automaatselt iga treeningkorra. See hõlmab andmestiku versioone, parameetrisätteid, koodiversioone ja mõõdikuid. Hajutatud märkmike asemel asub iga eksperiment ühel armatuurlaual. See teeb jooksude kõrvuti võrdlemise lihtsaks. See tähendab ka, et tulemused ei lähe kaduma, kui teadlane lahkub või server taaskäivitub.
• Mudelite versioonimine: Platvorm jälgib mudelite versioone struktureeritud viisil. Iga kord, kui mudel lõpetab treeningu, määrab süsteem versiooninumbri ja salvestab metaandmed. Seejärel saavad meeskonnad hankida mis tahes versiooni koos selle üksikasjadega. See on nagu tarkvara versioonikontroll, kuid mudelite jaoks. Süsteemid nagu MLflow pakuvad seda võimalust: see pakub süstemaatilist versioonikontrolli, nii et te “lõpetate toimivate asjade kadumise jälgimise” (mlflow.org). Hea juhtimisplatvorm integreeriks sellised tööriistad, võimalusel isegi linkides Giti kinnituste või Dockeri kujutistega.
• Poliitika jõustamine: See moodul tagab reeglite järgimise. Näiteks võib see takistada mudelite juurutamist, mis kasutasid heakskiitmata andmeid. Samuti haldab see heakskiitmisprotsessi: kes peab enne mudeli käivitamist sellele allkirja andma? Lubadused ja auditid logitakse. Dataiku puhul saavad administraatorid näiteks nõuda “huvirühmade heakskiitu mudelite versioonidele” enne juurutamist (doc.dataiku.com). Juhtimisplatvorm saab neid allkirjastamisi automatiseerida, saata teavitusi ülevaatajatele ja pidada arvestust selle kohta, kes mida ja millal heaks kiitis. Kui juurutatud mudel tekitab probleeme, saab süsteem logitud päritolu abil taastada eelmise versiooni.

Nende funktsioonide tsentraliseerimisega eemaldab juhtimisplatvorm suure osa käsitsitööst. See pakub projektidest ühtset ja terviklikku vaadet. Meeskondadel ei ole vaja eraldi arvutustabeleid ega vaikimisi teadmisi. Näiteks kui andmeteadlane vahetab pilvi või liitub uus meeskonnaliige, kasutab ta lihtsalt juhtimisplatvormi liidest. Platvorm soodustab järjepidevust ja muudab juhtidel parimate tavade jõustamise lihtsamaks.

Kulude optimeerimine pilvede ja riistvara vahel

Tehisintellekti käitamine mitmes pilves võib osutuda kulukaks. Igal pilvel ja igal GPU tüübil on oma maksumus. Ilma järelevalveta võib üks projekt jätta suured klastrid tühikäigul pöörlema või maksta kõrgeid nõudepõhiseid GPU-tasusid.

Nutikas platvorm peaks optimeerima kulusid. See võib hõlmata:

• Automaatne skaleerimine ja õige suuruse valik: Platvorm saab jälgida kasutust ja ressursse vastavalt vajadusele käivitada või peatada. See võib alustada mõne GPU-ga ja lisada neid ainult vajadusel. Automaatselt tegeliku koormuse järgi skaleerides välditakse ülemääraseid varusid. See sarnaneb pilveteenuse pakkujate nõuannetega: kasutage tööriistu (AWS Cost Explorer jne) ja skaleerimisreegleid, et vältida raiskamist (www.neticspace.com).
• Kohapealsed ja reserveeritud instantsid: Paljud pilve GPU-d on paindlikul kasutamisel saadaval soodsamalt. Platvorm võiks proovida kasutada kohapealseid instantsid (odavamad, kuid neid saab katkestada) mittekriitiliste tööde jaoks. Ettearvatavate töökoormuste puhul võiks see pakkuda reserveeritud instantsid. Teisisõnu, see segab GPU ostuvõimalusi kulude kärpimiseks.
• Mitmepilveline paigutus: Mõned pilved võivad pakkuda odavamat GPU aega või tasuta krediite. Juhtimisplatvorm saab võrrelda hindu teenusepakkujate vahel. Näiteks kui AWS GPU-d on hõivatud või kallid, võib see käivitada töö GCP-s või spetsialiseeritud GPU pilves. Turion blogi soovitab mustreid nagu “aktiivne-aktiivne pilvede vahel”, et vältida lukustumist ja kasutada parimaid hindu (turion.ai).
• Optimeeritud ajastamine: Suurte mudelite puhul võib töö jagamine väiksemate GPU-de vahel või töö jaotamine olla tõhusam. Platvorm saab otsustada parima riistvara üle. Nagu üks uurimisartikkel leidis, saab treeningtöökoormuste nutika orkestratsiooniga vähendada tehisintellekti infrastruktuuri kulusid ainuüksi arhitektuurivalikute abil 40–70% võrra (hub.stabilarity.com). See hõlmab otsuseid, nagu GPU partitsioneerimine või tööde ajastus.
• FinOps juhtimine: Lõpuks on kulude jälgimiseks vaja kulude mudelit. Platvorm võiks näidata armatuurlaudu kulutuste kohta projekti või meeskonna kohta. Hoiatused võiksid hoiatada eelarve ületamise korral. See finantsjärelevalve tagab, et kulud ei kasva märkamatult üle pea.

Koos aitavad need funktsioonid ettevõtetel oma rahaga maksimaalselt tehisintellekti arvutusvõimsust saada. Selle asemel, et iga meeskond optimeeriks eraldi, koordineerib juhtimisplatvorm kogu ettevõtte ulatuses. See võib integreerida pilve arveldus-API-dega, et automaatselt kulusid igale meeskonnale või projektile tagasi arveldada.

Juhtimine: heakskiidud ja tagasipööramised

Suurtes organisatsioonides ei ole tehisintellekti mudeli juurutamine pelgalt tehniline akt; see nõuab juhtimist. Enne mudeli käivitamist peavad inimesed võib-olla üle vaatama selle toimivuse ja ohutuse. Samamoodi, kui midagi läheb valesti, peaks süsteem kiiresti naasma ohutusse olekusse.

Juhtimisplatvormi halduskiht käsitleb seda järgmiselt:

• Heakskiidu töövoogud: Kui uus mudeliversioon on valmis, saab süsteem selle saata määratud ülevaatajatele. Nendeks võivad olla andmeteadlased, juhid, õigus- või eetikaametnikud. Platvorm võib kuvada mudeli toimivusmõõdikud, andmete päritolu ja riskihindamise. Seejärel saavad ülevaatajad mudeli heaks kiita või tagasi lükata. Dataiku, näiteks, on sisseehitatud “Juurutamise juhtimine”, kus huvirühmad annavad mudelitele oma heakskiidu (doc.dataiku.com). Juhtimisplatvorm logiks need heakskiidud mudeli ajaloo osana. Ükski mudel ei läheks käiku ilma vajalike heakskiitudeta.
• Auditi jäljed: Iga tegevus (andmete üleslaadimine, eksperimendi käivitamine, mudeli muutmine) logitakse ajatempli ja kasutajatunnusega. See auditi jälg on vastavuse jaoks kriitiline. Kui audiitorid küsivad “kes muutis mudelit novembris?”, on vastus vaid ühe kliki kaugusel.
• Tagasipööramised: Kui juurutatud mudel osutub vigaseks või kallutatuks, saab juhtimisplatvorm tagasi pöörduda eelmise heakskiidetud versiooni juurde. Kuna iga mudeliversioon on salvestatud ja logitud, on see lihtne. Platvorm võib halva mudeli de-jurutada ja automaatselt varasema uuesti juurutada. Selles valdkonnas pakutavad lahendused reklaamivad selliseid funktsioone: näiteks iTuring ML Ops lubab “sisseehitatud heakskiite, päritolu, tagasipööramist ja auditi pakette”, et muuta mudelid “turvalisteks, juhitavateks lõpp-punktideks” (ituring.ai). Tagasipöördeloogika sisseviimine tähendab, et isegi kui mudel käitub valesti, saavad inimmeeskonnad teenuse kiiresti taastada.
• Poliitika jõustamine: Lisaks heakskiitudele jõustab juhtimisplatvorm kõrgema taseme poliitikaid. Administraator võib deklareerida, et mudelid ei tohi kasutada teatud andmeid (nt terviseandmeid ilma nõusolekuta). Süsteem kontrollib seda automaatselt. See võib jõustada ka kodeerimisstandardeid protsessides või nõuda andmetele juurdepääsuks krüpteerimisvõtmeid. Need poliitikad muutuvad juhtimisplatvormis koodireegliteks, nii et midagi ei saa kogemata mööda minna.

Juhtimise integreerimisega tagab platvorm, et tehisintellekti tooted mitte ainult ei tööta, vaid vastavad ka ettevõtte reeglitele ja regulatsioonidele. See toob mudeli juurutamisse ettevõttetasandi ranguse.

Hinnakujundus, ettevõtte lisandmoodulid ja partnerlused

Selle keeruka platvormi ehitamine eeldab ärimudeli ja ökosüsteemi üle otsustamist:

• Kasutuspõhine hinnakujundus: Põhiplatvormi eest saab tasu võtta tarbimise alusel. See tähendab, et kliendid maksavad selle eest, mida nad kasutavad: näiteks kasutatud arvutustundide, andmestike salvestusruumi või mudelite juurutamiste arvu eest. See peegeldab suuri pilveteenuseid (AWS, Azure), mis võtavad tasu kasutuskorra alusel. Kasutuspõhine hinnakujundus on tehnoloogiamaailmas populaarne: üks analüüs osutab, et tarbimismudelid on tohutute tulude aluseks (AWS 90 miljardit dollarit, Snowflake IPO 1,4 miljardit dollarit) (ratekit.dev). Tehisintellekti platvormi puhul muudab GPU-tunni või API-kõne eest tasu võtmine kulud läbipaistvaks. Väiksemad idufirmad maksavad vähe, samas kui suuremad ettevõtted skaleerivad üles ja maksavad rohkem. Selline maksa-nii-nagu-kasutad lähenemine võimaldab ettevõtetel platvormi proovida ilma suuremate kohustusteta.
• Ettevõtte lisandmoodulid: Põhiteenusele lisaks saab ettevõtetele müüa lisatasu funktsioone. Need lisandmoodulid võivad hõlmata täiustatud turvalisust (nagu SSO integreerimine või õhukindla pilvetoe), prioriteetset tuge või vastavussertifikaate (SOC 2, ISO 27001). Muud lisandmoodulid võivad olla tasulised pluginad, nt kohandatud ühendused ettevõtte andmeladudega. Ettevõtteklientide hinnakujundus sisaldab sageli kindlat tasu kontohalduse ja kõrgemate kasutusastmete eest.
• Mudelitarnijate partnerlused: Platvorm saab teha koostööd populaarsete mudelitarnijatega (nagu Hugging Face, OpenAI, Anthropic). Näiteks NVIDIA ja Hugging Face tegid koostööd, et võimaldada arendajatel kasutada NVIDIA GPU-sid suuremate keelemudelite peenhäälestamiseks (investor.nvidia.com). Haldusplatvorm võiks sarnaselt integreerida selliste mudelikeskustega, võimaldades kasutajatel sujuvalt mudeleid importida ja nende eest maksta. See toob kasu klientidele, pakkudes neile rohkem eeltreeninguga mudelite valikuid peenhäälestamiseks, ja tarnijatele, pakkudes neile müügikanalit.
• GPU-tarnijate partnerlused: Partnerlus pilve- ja riistvaratarnijatega võib avada allahindlusi või erifunktsioone. Näiteks võib platvorm ehitada spetsiaalsele GPU pilvele (CoreWeave, LambdaLabs) ja pakkuda neid ressursse platvormi kaudu. GPU tootjatel (NVIDIA, AMD) on sageli turuplatsid või stiimulid platvormidele, mis kasutust suurendavad. Ametlike partnerluste sõlmimisega saaks haldusplatvorm pakkuda riistvarakrediite või tagada uusimad GPU-tüübid. Kliendid saavad seejärel parema hinna ja jõudluse.
• Maksete ja tulu jagamine: Integreeritud mudeli- ja riistvarapartnerite puhul võiks platvorm jagada tulu. Kui kasutaja peenhäälestab OpenAI mudeleid platvormi kaudu, võiks osa arvest minna OpenAI-le. Kui nad kasutavad partneri GPU farmi, rendib platvorm need masinad. Kasutuspõhised arvelduslaiendused (nagu Lago või Usage.ai) saavad selle keeruka arvelduse automatiseerida.

Kokkuvõttes ühendaks selle platvormi ümber ehitatud äri maksa-nii-nagu-kasutad hinnakujunduse valikuliste ettevõtteplaanidega. Partnerlused laiendavad võimekust: rohkem mudeleid peenhäälestamiseks ja rohkem GPU valikuid treeninguks. Koos moodustavad need ökosüsteemi, kus platvorm asub tehisintellekti tarnijate ja pilveteenuse pakkujate võrgustiku keskmes.

Kokkuvõte

Mitmepilvelise mitmemudelilise arenduse haldamine on tänapäeval keeruline. Andmed ja tööriistad on fragmenteeritud, kulud paisuvad ja hea juhtimine on raske. Ühtne peenhäälestamise juhtimisplatvorm saab need probleemid lahendada. Tsentraliseerides andmestiku kureerimise, ohutuse, eksperimentide jälgimise ja versioonihalduse, töötavad meeskonnad ühe tõeallikaga. Integreeritud poliitikareeglid tagavad mudelite heakskiidu ja ohutuse. Nutikas ajastamine ja mitmepilvelised strateegiad vähendavad kulusid märkimisväärselt (www.neticspace.com) (hub.stabilarity.com). Lõpuks muudavad kasutusel põhinev hinnakujundus, ettevõtte lisandmoodulid ja partnerlused mudeli-/GPU-tarnijatega platvormi praktiliseks ja skaleeritavaks igas suuruses ettevõtetele.

See lähenemine lihtsustab teadus- ja arendustegevust ning annab otsustajatele kindlustunde. Selle asemel, et žongleerida kümnete skriptide ja kviitungitega, kasutavad organisatsioonid ühtset ja sidusat süsteemi. Tulemuseks on kiirem innovatsioon, madalamad kulud ja tehisintellekti mudelid, mis vastavad poliitikale ja eetikale.