Comparthing Logo
mlopsci-cdmašininis mokymasisdevopsdebesų infrastruktūramodelio diegimas

MLOps kanalai ir tradicinė programinės įrangos CI/CD

MLOps kanalai išplečia tradicinius CI/CD procesus, pridėdami modelio mokymo, patvirtinimo ir stebėjimo etapus, pritaikytus mašininio mokymosi darbo eigoms. Nors tradicinis CI/CD daugiausia dėmesio skiria kodo diegimui, MLOps tvarko duomenų versijavimą, eksperimentų stebėjimą ir modelio poslinkio aptikimą per visą mašininio mokymosi gyvavimo ciklą.

Akcentai

  • MLOps prie kodo versijos kūrimo prideda duomenų ir modelių versijavimą, spręsdamas mašininio mokymosi išskirtinius atkuriamumo iššūkius.
  • Tradicinis CI/CD testuoja deterministinę logiką, o MLOp turi patvirtinti statistinio modelio elgseną ir duomenų kokybę.
  • MLOps srautai apima automatinius perkvalifikavimo paleidiklius, pagrįstus dreifo aptikimu – tai funkcija, kurios nėra standartiniame CI/CD.
  • Skaičiavimo reikalavimai labai skiriasi: MLOps dažnai reikia prieigos prie GPU mokymui, o tradicinis CI/CD veikia standartiniuose serveriuose.

Kas yra MLOps kanalai?

Išsamios darbo eigos, skirtos mašininio mokymosi modeliams kurti, diegti ir stebėti gamybinėje aplinkoje.

  • MLOps kanalai apima duomenų versijų kūrimą, funkcijų inžineriją ir modelio perkvalifikavimą kaip pagrindinius etapus kartu su kodo diegimu.
  • Tokios priemonės kaip „Kubeflow“, „MLflow“ ir „SageMaker Pipelines“ organizuoja visą mašininio mokymosi gyvavimo ciklą nuo eksperimentavimo iki gamybos.
  • Modelių stebėjimas MLOps sistemoje seka prognozių, duomenų ir koncepcijų poslinkius, kad nustatytų, kada reikia permokyti.
  • Atkuriamumas yra pagrindinis tikslas, pasiekiamas stebint eksperimentus su parametrais, metrikomis ir artefaktais.
  • MLOps kanalai paprastai veikia „Kubernetes“ arba debesijos infrastruktūroje, kad apdorotų skaičiavimo reikalaujančius mokymo darbo krūvius.

Kas yra Tradicinė programinė įranga CI/CD?

Automatizuoti srautai, kurie kuria, testuoja ir diegia programos kodą, taikydami nuolatinės integracijos ir nuolatinio teikimo praktikas.

  • Tradicinis CI/CD dėmesys sutelktas į versijų kontrolę, automatizuotą testavimą ir artefaktų diegimą programos kode.
  • Populiarūs įrankiai yra „Jenkins“, „GitHub Actions“, „GitLab CI“, „CircleCI“ ir „Azure DevOps“.
  • Vamzdynų struktūra paprastai atitinka kūrimo, testavimo ir diegimo etapus su atšaukimo mechanizmais nepavykusiems leidimams.
  • Testavimas daugiausia dėmesio skiria vienetiniams testams, integracijos testams ir ištisiniams testams, atliekamiems su deterministine programos logika.
  • Diegimo tikslai paprastai yra serveriai, konteineriai arba serverių neturinčios funkcijos, o ne modelius aptarnaujantys galiniai taškai.

Palyginimo lentelė

Funkcija MLOps kanalai Tradicinė programinė įranga CI/CD
Pagrindinis dėmesys Modelio gyvavimo ciklas ir duomenų darbo eigos Programos kodo diegimas
Pagrindiniai etapai Duomenų patvirtinimas, mokymai, vertinimas, diegimas, stebėsena Sukurti, išbandyti, įdiegti
Versijų kūrimas Kodas, duomenys, modeliai ir funkcijos Tik kodas ir konfigūracija
Testavimo metodas Modelio tikslumo, šališkumo, poslinkio ir duomenų kokybės testai Vienetiniai, integravimo ir regresiniai testai
Stebėjimo poreikiai Prognozių poslinkis, duomenų poslinkis, modelio našumas Programos veikimo laikas, klaidos, delsa
Atkuriamumas Eksperimento stebėjimas naudojant parametrus ir artefaktus Kurti artefaktus iš versijuoto kodo
Skaičiavimo reikalavimai GPU/TPU prieiga mokymo darbo krūviams Standartinės versijos serveriai ir bėgikai
Įprasti įrankiai MLflow, Kubeflow, SageMaker, Vertex AI Jenkins, „GitHub“ veiksmai, „GitLab CI“
Atsiliepimų ciklas Nuolatinis perkvalifikavimas, pagrįstas naujais duomenimis Iteraciniai leidimai, pagrįsti naudotojų atsiliepimais

Išsamus palyginimas

Vamzdynų struktūra ir etapai

Tradiciniai CI/CD srautai eina gana tiesiniu keliu: kodas yra patvirtinamas, integruojamas į artefaktus, išbandomas ir diegiamas gamybinėje aplinkoje. MLOps srautai ant šio pagrindo sukuria papildomus etapus, įskaitant duomenų patvirtinimą, funkcijų inžineriją, modelio mokymą ir modelio vertinimą. Šie papildomi žingsniai atspindi realybę, kad mašininio mokymosi sistemos priklauso nuo duomenų kokybės ir modelio elgsenos, o ne tik nuo kodo teisingumo.

Versijų kūrimas ir atkuriamumas

Tradiciniame CI/CD versijų kūrime daugiausia dėmesio skiriama šaltinio kodui ir konfigūracijos failams, kurių pakanka norint atkurti kompiliaciją. MLOps reikalauja daug daugiau: komandos turi versuoti duomenų rinkinius, sekti, kurie duomenys buvo įtraukti į mokymą, registruoti hiperparametrus ir saugoti modelio artefaktus. Be šios disciplinos atkurti modelio rezultatus tampa beveik neįmanoma, todėl eksperimentų stebėjimo įrankiai, tokie kaip MLflow, tapo pagrindine MLOps praktikos dalimi.

Testavimas ir patvirtinimas

Programinės įrangos CI/CD remiasi deterministiniais testais, kai įvesties duomenys pateikia nuspėjamus rezultatus. MLOps testavimas iš esmės skiriasi, nes modeliai yra statistinės sistemos. Komandos prideda testus duomenų schemos patvirtinimui, modelio teisingumui, prognozavimo tikslumui fiksuotuose rinkiniuose ir šališkumo aptikimui. Modelis gali išlaikyti visus tradicinius testus, tačiau vis tiek suprastėti gamyboje, jei pasikeičia įvesties duomenų pasiskirstymas.

Stebėjimas ir priežiūra

Tradiciniai srautai stebi programų būklę pagal tokius rodiklius kaip klaidų dažnis, atsako laikas ir procesoriaus naudojimas. MLOps stebėjimas apima dar daugiau, sekdamas modeliui būdingus signalus, tokius kaip prognozių poslinkis, funkcijų paskirstymo pokyčiai ir tolesnės verslo metrikos. Aptikus poslinkį, srautas gali inicijuoti automatinį perkvalifikavimą – tai, ko tradicinei integracijos / atkūrimo sistemai retai reikia.

Infrastruktūra ir skaičiavimai

Standartinis CI/CD veikia nedideliuose kompiliavimo serveriuose, nes kodo kompiliavimui ir testavimui retai reikia didelių skaičiavimų. MLOps srautams dažnai reikalingi GPU arba TPU mokymui, taip pat keičiamo dydžio saugykla duomenų rinkiniams, kurie gali siekti terabaitus. Štai kodėl dauguma MLOps platformų yra sukurtos naudojant „Kubernetes“ arba valdomas debesijos paslaugas, kurios gali teikti specializuotą aparatinę įrangą pagal poreikį.

Komandos įgūdžiai ir kultūra

Tradicinį CI/CD daugiausia valdo programinės įrangos inžinieriai ir DevOps komandos. MLOps reikalauja duomenų mokslininkų, mašininio mokymosi inžinierių ir operacijų personalo bendradarbiavimo, nes procesas apima tyrimus, eksperimentus ir diegimą gamyboje. Šis kultūrinis pokytis dažnai yra svarbesnis nei patys įrankiai, kai organizacijos pritaiko MLOps praktikas.

Privalumai ir trūkumai

MLOps kanalai

Privalumai

  • + Visas gyvavimo ciklo aprėptis
  • + Eksperimento pakartojamumas
  • + Automatinis dreifo aptikimas
  • + Duomenų ir modelių versijų kūrimas

Pasirinkta

  • − Didesnės infrastruktūros išlaidos
  • − Staigesnė mokymosi kreivė
  • − Sudėtingesnė orkestruotė
  • − Reikalingas komandinis bendradarbiavimas

Tradicinė programinė įranga CI/CD

Privalumai

  • + Subrendusi įrankių ekosistema
  • + Paprastesnis vamzdynų projektavimas
  • + Mažesnės skaičiavimo išlaidos
  • + Gerai suprantama geriausia praktika

Pasirinkta

  • − Nėra vietinio modelio stebėjimo
  • − Trūksta duomenų versijų
  • − Ribotas eksperimentų stebėjimas
  • − Neskirta perkvalifikavimo ciklams

Dažni klaidingi įsitikinimai

Mitas

MLOps yra tiesiog CI/CD su papildomais žingsniais.

Realybė

MLOps iš esmės keičia duomenų srautų projektavimo būdą, nes modeliai yra statistiniai artefaktai, kurie laikui bėgant blogėja. Sraigtų srautas turi atsižvelgti į duomenų kokybę, modelio versijavimą ir nuolatinį perkvalifikavimą, kuriems tradicinis CI/CD niekada nebuvo sukurtas.

Mitas

Mašininiam mokymuisi galite naudoti tradicinius CI/CD įrankius, tokius kaip „Jenkins“, be jokių pakeitimų.

Realybė

Nors „Jenkins“ gali organizuoti mokymo užduotis, jai trūksta vietinės paramos eksperimentų stebėjimui, modelių registrams ir dreifo stebėjimui. Dauguma komandų arba smarkiai išplečia „Jenkins“, arba naudoja specialias MLOps platformas, kad užpildytų šias spragas.

Mitas

Kai modelis yra įdiegtas, darbas atliekamas.

Realybė

Įdiegtų modelių našumas mažėja, nes realaus pasaulio duomenys atitolsta nuo mokymo paskirstymų. MLOps srautai apima stebėjimo ir perkvalifikavimo ciklus būtent todėl, kad modelio priežiūra yra nuolatinė atsakomybė, o ne vienkartinis įvykis.

Mitas

MLOps vamzdynai visiškai pakeičia DevOps praktikas.

Realybė

MLOps remiasi DevOps, o ne jį pakeičia. Pagrindinės praktikos, tokios kaip infrastruktūra kaip kodas, automatizuotas testavimas ir nuolatinis diegimas, išlieka būtinos. MLOps tiesiog prideda prie šių pamatų mašininio mokymosi specifinius sluoksnius.

Mitas

Daugiau duomenų visada pagerina modelio našumą gamyboje.

Realybė

Be tinkamo duomenų patvirtinimo ir kokybės patikrinimo, nauji duomenys gali sukelti triukšmą, šališkumą ar pasiskirstymo pokyčius, kurie kenkia modelio tikslumui. MLOps srautai apima duomenų patvirtinimo etapus, specialiai skirtus šioms problemoms aptikti prieš jas apmokant.

Dažnai užduodami klausimai

Kuo pagrindinis skirtumas tarp MLOps ir tradicinio CI/CD?
Pagrindinis skirtumas yra apimtis ir paskirtis. Tradicinis CI/CD automatizuoja programos kodo kūrimą, testavimą ir diegimą. MLOps tai išplečia, kad apimtų visą mašininio mokymosi gyvavimo ciklą, įskaitant duomenų patvirtinimą, modelių mokymą, eksperimentų stebėjimą ir nuolatinį našumo stebėjimą. MLOps modelius traktuoja kaip pirmos klasės artefaktus, kuriuos reikia versijuoti ir permokyti, o ne tik kodą, kurį reikia diegti.
Ar galite naudoti „GitHub Actions“ arba „GitLab CI“ MLOps?
Taip, abu gali būti naudojami kaip MLOps darbo eigų orkestravimo sluoksniai. Daugelis komandų naudoja „GitHub Actions“ arba „GitLab CI“, kad paleistų mokymo užduotis, atliktų duomenų patvirtinimą ir diegtų modelius. Tačiau juos paprastai reikia suporuoti su specializuotais įrankiais, tokiais kaip „MLflow“, skirta eksperimentams stebėti, arba modelių registru, kad būtų galima visapusiškai aprėpti MLOps.
Kodėl MLOps srautams reikalingas duomenų versijų kūrimas?
Duomenų versijų kūrimas užtikrina, kad kiekvieną modelį būtų galima atsekti iki tikslaus mokymo metu naudoto duomenų rinkinio. Be jo, atkurti rezultatus tampa beveik neįmanoma, kai duomenys laikui bėgant keičiasi. Tokios priemonės kaip DVC ir lakeFS integruojamos su „Git“, kad būtų galima versuoti didelius duomenų rinkinius kartu su kodu, o tai yra būtina derinant ir audituojant mašininio mokymosi sistemas.
Kuo skiriasi modelio stebėjimas nuo programos stebėjimo?
Programų stebėjimas seka tokius rodiklius kaip delsa, klaidų dažnis ir išteklių naudojimas. Modelių stebėjimas papildo statistinius patikrinimus, tokius kaip prognozių pasiskirstymo poslinkiai, funkcijų dreifas ir tikslumo pablogėjimas paženklintuose pavyzdžiuose. Šie modeliui būdingi signalai padeda aptikti, kada įdiegtas modelis nebeveikia taip, kaip tikėtasi, net jei pagrindinė programa yra sveika.
Kas yra modelio dreifas ir kodėl MLOps tai rūpi?
Modelio dreifas įvyksta, kai laikui bėgant keičiasi įvesties duomenų statistinės savybės arba ryšys tarp įvesties ir išvesties duomenų, todėl prognozės tampa mažiau tikslios. MLOps kanalai stebi dreifą, nes tylus degradavimas yra viena didžiausių gamybinio mašininio mokymosi rizikų. Aptikus dreifą, kanalas gali inicijuoti pakartotinį mokymą su naujais duomenimis.
Ar mažoms komandoms reikia pilnų MLOps procesų?
Nebūtinai. Mažos komandos gali pradėti nuo paprastų praktikų, tokių kaip eksperimentų stebėjimas ir pagrindinis modelių versijų kūrimas, o vėliau, modeliams plečiantis, išplėsti jas iki automatinio perkvalifikavimo ir poslinkio stebėjimo. Tikslas – suderinti gamybos srauto sudėtingumą su gamyboje naudojamų modelių sudėtingumu ir rizika.
Kokį vaidmenį „Kubernetes“ atlieka MLOps?
„Kubernetes“ yra plačiai naudojama MLOps procesuose, nes gali planuoti GPU spartinamus mokymo darbus, keisti išvadų apkrovų mastą ir valdyti sudėtingus kelių pakopų procesus. Tokios platformos kaip „Kubeflow“ yra sukurtos tiesiogiai „Kubernetes“ pagrindu, kad būtų galima valdyti visą mašininio mokymosi gyvavimo ciklą, todėl tai yra įprastas gamybinių MLOps sistemų pagrindas.
Kiek laiko užtrunka įdiegti MLOps praktikas?
Įdiegimo terminai labai skiriasi priklausomai nuo organizacijos brandos ir esamos infrastruktūros. Komandos, turinčios tvirtą „DevOps“ praktiką, dažnai gali pridėti eksperimentų stebėjimą ir modelių registrus per kelias savaites. Visiškai automatizuotų perkvalifikavimo ciklų su poslinkio aptikimu ir valdymu sukūrimas paprastai trunka kelis mėnesius iteracinio darbo.
Ar MLOps skirtas tik gilaus mokymosi modeliams?
Ne, MLOps taikomas bet kokiam gamyboje naudojamam mašininio mokymosi modeliui, įskaitant klasikinius modelius, tokius kaip gradientu sustiprinti medžiai, atsitiktiniai miškai ir logistinė regresija. Bet kuris modelis, kuris naudoja duomenis ir teikia prognozes, gali pasinaudoti versijų kūrimo, stebėjimo ir perkvalifikavimo darbo eigomis, nepriklausomai nuo pagrindinio algoritmo.
Kokie didžiausi iššūkiai diegiant MLOps?
Dažni iššūkiai apima skirtingų įrankių integravimą į nuoseklų procesą, skaičiavimo išlaidų valdymą perkvalifikavimui, duomenų valdymo sukūrimą ir kultūrinio atotrūkio tarp duomenų mokslo ir operacijų komandų mažinimą. Organizacijos dažnai nepakankamai įvertina organizacinius pokyčius, reikalingus kartu su techniniu įgyvendinimu.

Nuosprendis

Rinkitės tradicinį CI/CD, kai jūsų pristatomas produktas yra programos kodas su deterministiniu elgesiu ir aiškiai apibrėžtais testais. Rinkitės MLOps srautus, kai jums reikia valdyti mašininio mokymosi modelius, kurių našumas priklauso nuo duomenų kokybės, kuriems reikalingas eksperimentų stebėjimas ir nuolatinis stebėjimas dėl poslinkio ir degradacijos.

Susiję palyginimai

„Kafka“ ir „Flink“ palyginti su apdorojimu atmintyje

„Kafka“ ir „Flink“ sudaro paskirstytą srautinio apdorojimo ekosistemą realaus laiko duomenų srautams, o apdorojimas atmintyje pagreitina analizę, nes duomenys saugomi tik RAM atmintyje – kiekvienas iš jų tenkina iš esmės skirtingus architektūrinius greičio, mastelio ir tvarumo poreikius.

„Netflix“ mašininio mokymosi platforma ir nepriklausomi mašininio mokymosi įrankiai

„Netflix“ vidinė mašininio mokymosi platforma siūlo glaudžiai integruotus, didelio masto įrankius, skirtus transliacijų suasmeninimui, o nepriklausomi mašininio mokymosi įrankiai suteikia mažesnėms komandoms lankstumo ir kontrolės. Pasirinkimas priklauso nuo masto, pritaikymo poreikių ir esamų investicijų į infrastruktūrą.

Adaptyvioji infrastruktūra ir statinė infrastruktūros projektavimas

Adaptyvi infrastruktūra dinamiškai prisitaiko prie kintančių darbo krūvių, naudodama automatizavimą ir mastelio keitimą realiuoju laiku, o statinės infrastruktūros projektavimas remiasi fiksuotais, iš anksto sukonfigūruotais ištekliais. Pasirinkimas priklauso nuo darbo krūvio kintamumo, biudžeto nuspėjamumo ir veikimo brandos jūsų debesijos aplinkoje.

Apkrovos balansavimas mašininio mokymosi sistemose ir paprastas API užklausų tvarkymas

Apkrovos balansavimas mašininio mokymosi sistemose valdo GPU reikalaujančius išvadų ir mokymo darbo krūvius specializuotoje įrangoje, o paprastas API užklausų apdorojimas paskirsto nedidelį HTTP srautą bendrosios paskirties serveriuose. Jie labai skiriasi sudėtingumu, išteklių poreikiu ir maršruto parinkimo išmanumu.

Atsparumas gedimams ir sistemos paleidimas iš naujo

Atsparumas gedimams proaktyviai perkelia darbo krūvius į sveikas sistemas, kol vartotojai nepastebi problemų, o sistemos gedimų atveju iš naujo paleidžiamos sistemos reaktyviai atkuria paslaugas po netikėtų gedimų. Abu metodai siekia palaikyti prieinamumą, tačiau iš esmės skiriasi laiku, architektūros sudėtingumu ir poveikiu vartotojams.