Arkitektur för checkpoints och modelllagring i lokala AI-miljöer

Varför traditionell lagring inte räcker för AI-arbetsbelastningar

En enskild modell med 7 miljarder parametrar i full precision upptar ungefär 28 GB. Att träna den modellen producerar checkpoints var hundrade steg — varje checkpoint av samma storlek. En finjusteringskörning med 20 sparade checkpoints förbrukar 560 GB innan du räknar med optimerartillstånd, som kan tredubbla storleken per checkpoint. Skala detta till flera team som kör experiment med olika modeller, och en organisation kan enkelt ackumulera tiotals terabyte av modellartefakter på veckor.

Traditionella företagslagrings- och backupsystem designades för databaser, dokument och applikationsdata. De optimerar för små slumpmässiga läsningar, inkrementella backuper av ändrade block och deduplicering av texttunga data. Modellcheckpoints är motsatsen: massiva enskilda filer, skrivna sekventiellt med hög genomströmning, med binärt innehåll som motstår deduplicering.

Att behandla modelllagring som en eftertanke leder till träningsjobb som stannar medan de väntar på checkpoint-skrivningar, lagringssystem som fylls upp oväntat och återställningsprocesser som tar timmar när de behöver ta minuter.

Lagringsnivåer för modellens livscykelfaser

Inte alla modellartefakter har samma åtkomstmönster. En nivåindelad lagringsstrategi matchar prestanda med behov och undviker att betala för snabb lagring som innehåller kall data.

Het nivå: aktiv träning och servering. Checkpoints som skrivs under träning och modeller som laddas för inferens behöver lagring med hög genomströmning och låg latens. NVMe SSD:er direkt anslutna till GPU-noder eller parallella filsystem som Lustre, BeeGFS eller GPFS ger den genomströmning — typiskt 5-20 GB/s — som behövs för att skriva checkpoints utan att stanna träningen.

Ljummen nivå: senaste experiment och staging. Avslutade träningskörningar, kandidatmodeller under utvärdering och adaptrar som väntar på distribution lever på nätverksansluten lagring med måttlig genomströmning. Objektlagringslösningar som MinIO erbjuder S3-kompatibla API:er med rimlig prestanda och möjlighet att skala kapacitet oberoende av beräkning.

Kall nivå: arkivering och regelefterlevnad. Äldre modellversioner som behålls för reproducerbarhet, revision eller rollback lever på den billigaste tillgängliga lagringen. Bandbibliotek, högdensitetsdiskkluster eller djupt komprimerad objektlagring fungerar här. Regulatoriska krav inom branscher som finans och hälsovård kan kräva att modellartefakter sparas i åratal.

Automatisera nivåmigration baserat på policyer. En checkpoint bör flyttas från het till ljummen när träningskörningen slutförs, och från ljummen till kall efter en konfigurerbar retentionstid (30-90 dagar är typiskt).

Versioneringsstrategier som skalar

Modellversionering är inte samma sak som kodversionering. Git och liknande verktyg designades för textdiffar mätta i kilobyte. Modellfiler är binära blobbar mätta i gigabyte. Att lagra modellcheckpoints i Git — även med Git LFS — skapar repos som är plågsamma att klona, långsamma att fråga och dyra i lagring.

Specialbyggda modellregister hanterar detta bättre. MLflows modellregister, DVC (Data Version Control) och LakeFS erbjuder versionsspårning med metadata, härstamning och taggning utan att kräva fullständiga kopior av varje version. DVC lagrar specifikt versionsmetadata i Git medan den faktiska binära datan hålls i en konfigurerbar backend.

Designa ditt versionsschema kring vad du faktiskt kommer att behöva hämta. En praktisk metod tilldelar varje modellartefakt en sammansatt nyckel: modellnamn/basversion/adapternamn/träningskörnings-id/checkpointsteg. Denna hierarki stöder vanliga frågor som att hämta den senaste adaptern för en viss modell.

Lagra metadata tillsammans med varje version: träningskonfiguration, datasetidentifierare, utvärderingsmått, använd hårdvara och Git-commit för träningskoden. Denna metadata är liten och hör hemma i en databas eller ett register, inte inbäddad i modellfilen.

Optimering av checkpoint-skrivning

Att skriva en 30 GB checkpoint till disk medan GPU:er sitter inaktiva är ett direkt slag mot träningsgenomströmningen. Vid en skrivhastighet på 2 GB/s tar en enskild checkpoint-skrivning 15 sekunder. Över en träningskörning med checkpoints var 500:e steg summerar detta till timmar av bortkastade GPU-timmar.

Asynkron checkpointing löser detta genom att överlappa checkpoint-skrivningar med fortsatt träning. Träningsprocessen kopierar modelltillståndet till värdminne (CPU RAM), återupptar sedan träningen omedelbart medan en bakgrundstråd skriver från värdminne till lagring. PyTorchs distribuerade checkpointing-modul och ramverk som DeepSpeed stöder asynkrona skrivningar nativt.

För distribuerad träning över flera GPU:er eller noder, använd fragmenterad checkpointing. Istället för att samla hela modelltillståndet till en enda nod och skriva en stor fil, skriver varje nod sin egen fragment parallellt. PyTorchs FSDP (Fully Sharded Data Parallel) producerar fragmenterade checkpoints som standard.

Inkrementell checkpointing skriver bara de parametrar som ändrats sedan senaste checkpoint. För finjusteringskörningar där de flesta parametrar är frusna (LoRA, till exempel) kan de ändrade parametrarna vara mindre än 1% av den totala modellstorleken, vilket gör checkpoint-skrivningar nästan omedelbara.

Återställning och katastrofscenarier

Modelllagringsarkitektur måste hantera tre felscenarier: träningsavbrott, inferensnodfel och katastrofal lagringsförlust.

För träningsavbrott — hårdvarufel, OOM-krascher, strömavbrott — bestämmer checkpoint-frekvensen återställningskostnaden. Checkpointing var 500:e steg innebär att förlora som mest 500 träningssteg vid omstart. Beräkna tidskostnaden för förlorade steg och balansera den mot checkpoint-skrivningsoverhead.

För inferensnodfel handlar återställningsfrågan om hur snabbt du kan ladda en modell på en ersättningsnod. En 7B-modell i 16-bitars precision tar 10-30 sekunder att ladda från NVMe-lagring, men flera minuter att hämta från nätverkslagring. Att förstadiera modeller på inferensnoder — genom att hålla en lokal kopia av den aktiva modellen på varje nods lokala lagring — reducerar failover-tid.

För katastrofal lagringsförlust är replikering svaret. Replikera den ljumna nivån till ett andra lagringssystem, helst i en separat feldomän. MinIO stöder inbyggd replikering. För den kalla nivån gäller standardpraxis för företagsbackup — men verifiera att ditt backupsystem kan hantera de filstorlekar som är involverade.

Testa återställning regelbundet. Kör en övning där du återställer en modell från kall lagring och serverar inferens från den. Mät total tid och verifiera att den återställda modellen producerar identiska utdata som originalet. Återställningsprocesser som aldrig testats är återställningsprocesser som inte fungerar.

Att sammanföra allt

Modelllagring är infrastruktur som antingen möjliggör eller begränsar dina AI-operationer. En väldesignad lagringsarkitektur låter team träna utan avbrott, distribuera med tillförsikt och återhämta sig snabbt från fel. En försummad arkitektur skapar flaskhalsar som saktar ner träning, komplicerar distribution och riskerar dataförlust.

Börja med grunderna: mät din nuvarande checkpoint-skrivgenomströmning, inventera dina modellartefakter och deras storlekar, och implementera nivåindelad lagring med automatiserade livscykelpolicyer. Lägg till versionering genom ett modellregister med korrekt metadata. Optimera checkpoint-skrivningar med asynkrona och fragmenterade tekniker. Testa dina återställningsprocedurer innan du behöver dem.

Investeringen skalas med dina AI-ambitioner. En organisation som kör enstaka finjusteringsexperiment kan klara sig med en enkel NFS-delning och manuell versionering. En organisation som driver flera modeller i produktion över flera team behöver den fullständiga arkitekturen som beskrivs här. Matcha sofistikeringen i din lagring med mognaden i dina AI-operationer, och planera för tillväxt.

Utvald bild av Steve A Johnson på Unsplash.