ML sistemų talpyklos strategijos saugo iš anksto apskaičiuotus modelio rezultatus arba tarpinius duomenis, kad paspartintų pakartotines užklausas, o skaičiavimas pagal poreikį kiekvieną kartą generuoja naujus rezultatus, prekiaujant greičiu siekiant paprastumo ir mažesnių saugojimo išlaidų.
Iš anksto apskaičiuotas modelio išvesties duomenų, įterpimų ar tarpinių tenzorių saugojimas, siekiant sumažinti perteklinį skaičiavimų skaičių.
Prognozių, funkcijų ar įterpimų skaičiavimas realiuoju laiku, kai tik gaunama užklausa, be iš anksto saugomų rezultatų.
| Funkcija | Talpyklos strategijos ML sistemose | Skaičiavimas pagal poreikį |
|---|---|---|
| Latencijos charakteristikos | Talpyklos įvykių skaičius milisekundžių ir milisekundžių intervalais | Nuo milisekundžių iki sekundžių, priklausomai nuo modelio sudėtingumo |
| Sandėliavimo reikalavimai | Didesnis; talpykloje esantiems artefaktams reikalinga atmintis arba diskas | Minimalus; tik modelio svoriai ir kodas |
| Sąnaudų struktūra | Didesnė bazinė infrastruktūros kaina | Kintamas; keičiasi pagal užklausų kiekį |
| Sudėtingumas | Aukštesnė; reikalinga talpyklos negaliojimo logika | Žemesnė; paprastesnė architektūra |
| Mastelio keitimas esant apkrovai | Puiku; talpykla sugeria srauto šuolius | Prastas; kiekviena užklausa naudoja daug skaičiavimo pajėgumų |
| Prognozavimo šviežumas | Pasenusių rezultatų rizika be tinkamo TTL | Visada naudoja naujausią modelio versiją |
| Tipiniai naudojimo atvejai | Aukšto QPS rekomendacija, paieškos reitingas | Paketinis apdorojimas, mažo srauto API, prototipų kūrimas |
Talpyklos funkcijos slypi tada, kai milisekundės svarbios. „Redis“ pagrindu sukurta talpykla, aptarnaujanti iš anksto apskaičiuotus įterpimus arba modelio išvestis, gali reaguoti greičiau nei per milisekundę, o net ir lengviems neuroniniams tinklams dažnai reikia 10–100 ms. Tačiau talpyklos klaidos sukelia dvigubą nuobaudą: mokate talpyklos paieškos kainą ir visas skaičiavimo išlaidas. Skaičiavimas pagal poreikį siūlo nuspėjamą, nors ir lėtesnį, našumą be šio bimodalinio delsos pasiskirstymo.
Sąnaudų lygtis pasikeičia priklausomai nuo srauto modelių. Talpykloje kaupimas reikalauja išankstinių investicijų į atminties atžvilgiu optimizuotus egzempliorius arba valdomas talpyklos paslaugas, kurios veikia nuolat. Pagal poreikį veikiančios serverio neturinčios funkcijos atrodo pigesnės esant mažam srautui, tačiau gali tapti brangios esant nuolatiniam dideliam srautui. Tokios organizacijos kaip „Netflix“ plačiai publikavo apie tai, kaip kelių pakopų talpyklos naudojimas sumažina jų aptarnavimo išlaidas, palyginti su vien skaičiavimais.
Talpyklos naudojimas sukuria realią operacinę naštą. Jums reikia iškeldinimo politikos, apšilimo procedūrų, atitikties rodiklių stebėjimo ir, ko gero, svarbiausia, negaliojimo strategijų, kai modeliai persikvalifikuoja. Pagal poreikį veikiančios sistemos šį sudėtingumą pakeičia vardan paprasto diegimo. Daugelis komandų, pradedančių nuo mašininio mokymosi aptarnavimo, pasirenka pagal poreikį veikiančias sistemas būtent tam, kad išvengtų šių paskirstytų sistemų iššūkių, o tada selektyviai prideda talpyklą, kai reikia mastelio.
Pasenusios talpyklos kelia subtilių ML tikslumo problemų. Rekomendacijų modelis, permokytas remiantis vakarykščiais duomenimis, gali pateikti kitokius rezultatus nei jo talpykloje esantis pirmtakas. TTL pagrįstas galiojimo pabaigos nustatymas padeda, tačiau įveda atnaujinimo ir vėlavimo kompromisą. Skaičiavimas pagal poreikį natūraliai apeina šį sprendimą, visada iškviečiant dabartinį modelį. Finansinės ir medicininės programos, kurioms keliami griežti teisingumo reikalavimai, kartais renkasi šią garantiją, nepaisant našumo sąnaudų.
Gamybos realybė retai atitinka grynai vadovėlių šablonus. Dauguma brandžių mašininio mokymosi platformų naudoja skaičiavimus pagal poreikį kaip atsarginį sprendimą, kai talpyklos sluoksniai praleidžiami, sukurdamos skaidrų hibridą. Šis metodas leidžia komandoms optimizuoti įprastą atvejį, išsaugant teisingumo garantijas. Iššūkis pereina prie talpyklos raktų, kurie užfiksuotų visus svarbius įvesties variantus, sukūrimo nepadidinant saugyklos reikalavimų.
Talpykla naudinga tik paprastoms paieškos lentelėms ir negali apdoroti sudėtingų ML modelio išvesčių.
Šiuolaikinis mašininio mokymosi kaupimas talpykloje saugo įterptuosius elementus, dėmesio išvestis ir net dalinių skaičiavimų grafikus. Transformatorių išvadų sistemos įprastai kaupia rakto ir reikšmės dėmesio būsenas talpykloje, kad paspartintų autoregresinį generavimą.
Skaičiavimas pagal pareikalavimą visada yra pigesnis, nes nereikia mokėti už nenaudojamos talpyklos infrastruktūrą.
Esant reikšmingam mastui, pertekliniai skaičiavimai dažnai viršija talpyklos infrastruktūros sąnaudas. Debesijos paslaugų teikėjų užklausų kainos už išvadas pagal poreikį gali greitai padidėti, palyginti su rezervuotais talpyklos egzemplioriais.
Talpyklos negaliojimo problema išspręsta taikant standartines TTL strategijas.
ML modeliai kelia unikalių negaliojimo iššūkių. Modelių versijos, funkcijų schemos ir duomenų srautai keičiasi nepriklausomai, todėl sunku apibrėžti, ką reiškia „pasenęs“. Daugelis gamybinių incidentų kyla dėl subtilių talpyklos koherencijos klaidų.
Turite rinktis tik tarp kaupimo talpykloje ir skaičiavimo pagal poreikį.
Hibridinės architektūros gamyboje yra norma. Tokios sistemos kaip „Redis“ palaikomos funkcijų saugyklos su užsakomuoju atsarginiu šaltojo talpyklos įrašais skaidriai sujungia abu metodus.
Serverių neturinčios pagal pareikalavimą veikiančios funkcijos tinka visiems realiuoju laiku vykdomiems mašininio mokymosi (ML) aptarnavimo scenarijams.
Dėl šaltojo paleidimo delsos ir konteinerio gyvavimo ciklo apribojimų serverių nenaudojimas yra problematiškas programoms, jautrioms delsai. Iš anksto pašildyti konteineriai arba dedikuoti išvados serveriai dažnai pranoksta gryną serverių nenaudojimą mašininio mokymosi darbo krūviams.
Rinkitės kaupimo strategijas, kai jūsų reikalavimus lemia delsa ir pralaidumas, ypač didelio srauto rekomendacijų ir paieškos programoms. Rinkitės skaičiavimus pagal poreikį, kai paprastumas, mažesnės infrastruktūros išlaidos arba garantuotas prognozių naujumas yra svarbesni už neapdorotą greitį. Dauguma gamybinių sistemų galiausiai vystosi link hibridinių sistemų, kurios subalansuoja šiuos prioritetus.
„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“ 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ą.
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 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 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.
