AI data storage ndan arkivat afatgjata nga aksesi i shpejtë
AI data storage duhet të pajtojë dy kërkesa të ndryshme: ruajtjen me kosto të përballueshme të dataset-eve që zgjerohen dhe shpërndarjen e pjesës më të vogël aktive me shpejtësi të mjaftueshme për t'i mbajtur në punë njësitë e përpunimit grafik (GPU). Backblaze ka dokumentuar një arkitekturë me dy tier, në të cilën B2 Cloud Storage mban kopjen afatgjatë të dataset-eve, skedarëve të derivuar dhe checkpoint, ndërsa NVIDIA AIStore mban të dhënat e përdorura shpesh në local storage pranë compute. Një checkpoint është një gjendje e ruajtur e trajnimit që lejon rifillimin ose ripërdorimin e punës më vonë.
Arkitektura pasqyron mënyrën se si projektet e AI përdorin të dhënat. Ekipet mund të ruajnë dataset-et burimore, revision-et e kuruara dhe checkpoint të njëpasnjëshëm, por një job individual lexon vetëm një nëngrup që ndryshon. Kurimi mund t'i rikthehet materialit raw sa herë që ndryshojnë parametrat e tij, disa inxhinierë mund të ripërdorin të njëjtin revision dhe trajnimi mund ta lexojë një revision gjatë shumë epoch, që do të thotë kalime të plota nëpër të dhënat e trajnimit. Mbajtja e të gjithë arkivit pranë GPU-ve mund të jetë e kushtueshme, ndërsa leximi i përsëritur i tij nga remote object storage mund të ndikojë në performancë.
AIStore është një object store open-source dhe scale-out, që do të thotë se mund t'i shpërndajë të dhënat dhe kërkesat në disa makina ndërsa rritet kërkesa. Ai mund të lidhë një bucket B2 në distancë përmes një S3-compatible API, një interface i projektuar për të funksionuar si Amazon S3. Kërkesa e parë për një object e merr atë nga system of record në distancë. Kërkesat pasuese mund të përdorin kopjen lokale në cache për sa kohë që ajo mbetet e disponueshme dhe e vlefshme. Aplikacionet S3 të mbështetura mund të drejtohen te endpoint i AIStore përmes konfigurimit, pa zëvendësuar kodin e tyre të aksesit në storage.
Software-i ofron gjithashtu operacione të orientuara drejt workload të trajnimit. Një job prefetch ngarkon një revision të njohur të dataset-it përpara se të fillojë përpunimi. write-through ruan një kopje lokale dhe ngarkon rezultatin në remote record brenda së njëjtës kërkesë. GetBatch bashkon shumë object të vegjël në një stream të vetëm të renditur, në vend që të dërgojë një kërkesë të veçantë për çdo object. Në arkitekturën me tier, të dhënat udhëtojnë nga B2 përmes AIStore drejt aplikacionit dhe memories së GPU-së për decoding, përgatitjen e batch dhe ekzekutimin e modelit. Rezultatet dhe checkpoint kthehen përmes AIStore në B2.
Backblaze ndërtoi dy workflow shembull për ta demonstruar këtë model. Shembulli i kurimit të videove përdor NVIDIA NeMo Curator, një library open-source dhe të përshpejtuar me GPU për përgatitjen e dataset-eve të mëdha të AI gjenerative. Ekzekutimet e plota bëjnë prefetch të videove burimore, ndërsa ekzekutimet e kufizuara ose ato me prefetch të çaktivizuar i marrin input-et që nuk ndodhen në cache kur nevojiten. Curator prodhon klipe dhe Cosmos-Embed1 embeddings, përfaqësime numerike të përmbajtjes që përdoren nga sistemet AI, dhe më pas i publikon ato përmes AIStore në B2. Ekzekutimet e mëvonshme të kurimit mund të ripërdorin videot e vlefshme që vazhdojnë të mbahen në cache.
Shembulli i trajnimit të robotikës mbulon trainer që kërkojnë një directory të zakonshëm lokal. NVIDIA Isaac GR00T është një model open vision-language-action për aftësitë e robotëve humanoidë. Dataset-et e tij demonstruese përmbajnë shumë skedarë të vegjël, duke përfshirë tabela për çdo episod, video nga kamerat dhe metadata. Shembulli vendos një revision nga AIStore në node-in e GPU-së, e kontrollon atë kundrejt një manifest, që është një inventar i skedarëve të pritshëm, dhe më pas nis trajnimin pa ndryshuar data loader ekzistues. Checkpoint publikohen përmes AIStore në B2. Vendosja sërish e atij revision-i mund të lexojë kopjen në cache në vend që ta marrë nga B2.
Backblaze përcakton pesë rregulla operacionale për t'i mbajtur të pavarur këta tier. Së pari, dimensiononi tier-in e shpejtë për working set të njëkohshëm dhe ripërdorimin e mundshëm, jo për të gjithë arkivin. Ai ka nevojë gjithashtu për hapësirë rezervë të mjaftueshme, në mënyrë që të dhënat e ngarkuara me prefetch të mbeten rezidente derisa të përfundojë staging. Për bucket në distancë, AIStore aktivizon si parazgjedhje politikën least recently used, ose LRU eviction. Ai fillon të heqë të dhënat më të vjetra nga cache kur përdorimi i diskut kalon një high watermark në nivel cluster-i, i cili si parazgjedhje është 90%. Për këtë arsye, operatorët duhet ta caktojnë atë prag sipas workload, në vend që ta trajtojnë si një vlerë të parëndësishme të parazgjedhur.
Së dyti, përdorni prefetch për të dhënat kur koha e parashikueshme e nisjes ka rëndësi. Së treti, trajtojini prefix-et e dataset-it si vendndodhje write-once: çdo revision duhet të marrë një path të ri, si raw/revision-001/, në vend që të modifikohet një revision ekzistues. AIStore mund t'i verifikojë object në cache kundrejt B2 në çdo lexim përmes versioning.validate_warm_get, për ndryshimet out-of-band. Prefix-et unike dhe të pandryshueshme e shmangin këtë kontroll në çdo lexim për revision-et e përfunduara. Për të dhënat që ruhen për auditime ose riprodhueshmëri, B2 Object Lock mund të parandalojë fshirjen e një versioni të kyçur të object gjatë periudhës së tij të ruajtjes.
Së katërti, publikoni një manifest të verifikueshëm me çdo rezultat. Të dy shembujt fillimisht shënojnë një record _SUCCESS.json si pending. Pasi mbërrin çdo object, ata e shënojnë atë si complete dhe regjistrojnë madhësinë dhe SHA-256 të çdo skedari, një vlerë kriptografike që përdoret për të zbuluar nëse një skedar ka ndryshuar. Kur ekziston një manifest i input-it, provenance i output-it mban gjithashtu vlerën hash të tij, në mënyrë që të identifikohet revision-i i dataset-it burimor.
Së pesti, matni veçmas ngarkimin fillestar, leximet nga warm-cache, përpunimin dhe publikimin, sepse çdo fazë reagon ndaj ndryshimeve të ndryshme. Publikimi mund të jetë transferimi më i madh: checkpoint përmbajnë peshat e modelit dhe gjendjen e optimizer, dhe Backblaze thotë se edhe demonstrimi i tij GR00T me 20 hapa mund të publikojë dhjetëra gigabyte. Repository-t e shembujve krahasojnë marrjen e drejtpërdrejtë nga B2 me leximet cold dhe warm nga AIStore. Testet e tyre të integrimit konfirmojnë se leximet warm kryejnë zero kërkesa B2 GET.
Edhe kufijtë e credentials kanë rëndësi. Proceset child të Curator dhe GR00T nuk e marrin key të B2. Target-et e AIStore dhe utilities që lidhen drejtpërdrejt me B2 kanë nevojë për të. Kjo kufizon vendet ku duhet të shpërndahet credential i remote storage, pa ndryshuar workflow S3 të aplikacionit.
Arsyetimi financiar varet nga ripërdorimi. Job që përdorin të njëjtin cluster AIStore mund të konsumojnë të njëjtat object në cache pa i shkarkuar ato në mënyrë të përsëritur. Backblaze thotë se kjo mund të zvogëlojë leximet që llogariten kundrejt kuotës falas të egress të B2, e cila është sa trefishi i storage mesatar mujor. Kompania thotë gjithashtu se egress drejt partnerëve compute, si CoreWeave, është falas pa kufizim. Megjithatë, për një kalim të vetëm sekuencial, stream i drejtpërdrejtë i të dhënave të ndara në shard nga B2 drejt data loader është më i thjeshtë.
AIStore mbetet infrastructure që duhet të operohet nga një ekip. Kubernetes me ais-k8s është një mundësi deployment për production. write-through shton një shkrim lokal përpara çdo upload, megjithëse benchmark-et e NVIDIA tregojnë se kjo overhead zvogëlohet me rritjen e madhësisë së object. Kompromisi është se rezultatet e publikuara mbeten në cache për t'u ripërdorur nga një job tjetër. Operatorët duhet ta krahasojnë këtë përfitim me punën shtesë të upload për çdo workload.
Për organizatat që po shqyrtojnë këtë ndarje të kapacitetit nga performanca, AEU Data ofron cloud dhe data infrastructure evropiane si një mundësi për data layer bazë.