Hur håller CPU-avlastning stora modeller igång på en hemmaserver?
CPU-avlastning håller en överdimensionerad modell igång genom att lagra en del av dess vikter i systemets RAM-minne i stället för att kräva att hela modellen får plats i acceleratorns minne.
På en AI-server hemma kan detta göra en modell som inte kan laddas på ett enda GPU-kort till en användbar lokal tjänst. Avvägningen är tydlig: belastningen på VRAM minskar, men CPU-minne, PCIe- eller sammankopplingstrafik och ibland CPU-körning blir en del av inferensvägen. Avlastning är först och främst en kapacitetsteknik och endast en prestandateknik när minneshierarkin är tillräckligt snabb.
En överdimensionerad modell misslyckas när den snabba enheten inte kan rymma dess nödvändiga tillstånd
En lokal modell behöver utrymme för vikter samt KV-cache, aktiveringar, temporära buffertar och reserverat körtidsutrymme. Om acceleratorn inte kan hålla det nödvändiga residenta tillståndet kan laddningen misslyckas innan någon användbar inferens börjar.
Hugging Face Accelerate behandlar inferens med stora modeller som ett problem med att fördela modellvikter över tillgängliga minnesnivåer. CPU-avlastning lägger till systemets RAM-minne som en långsammare lagringsnivå för modellens tillstånd.
Modellen blir körbar eftersom mindre av den måste ligga kvar i VRAM samtidigt, inte för att acceleratorn har fått mer fysiskt minne.
Avlastade vikter ligger kvar i systemets RAM tills deras lager behövs
En körtidsmiljö kan hålla utvalda parametertensorer på CPU:n medan det aktuella lagret eller den aktuella gruppen av lager är aktiv på GPU:n. När körningen går vidare överförs de vikter som behövs till acceleratorn, och äldre vikter kan flyttas tillbaka eller tas bort från enhetens minne.
DeepSpeed ZeRO-Inference kan hålla modellvikter i CPU- eller NVMe-minne och strömma dem lager för lager till GPU:n. Detta minskar acceleratorns maximala minnesanvändning, men gör samtidigt viktöverföringen till en del av körningen.
Placeringen av lager kan också vara statisk: vissa lager ligger kvar på CPU:n och körs där, medan andra stannar på GPU:n. Båda strategierna byter minnesbelastning på enheten mot långsammare minnes- och överföringsvägar.
PCIe- eller enhetligt minnesvägen blir en del av varje token
Om vikter måste färdas över PCIe under framåtkörningen hamnar överföringens fördröjning och bandbredd direkt i inferensens kritiska väg. En modell som får plats helt i VRAM kan återanvända residenta vikter med enhetens bandbredd; en avlastad modell kan behöva hämta stora tensorer upprepade gånger.
PyTorch dokumenterar låst värdminne och överföringsbeteende mellan CPU och GPU, vilket visar varför förflyttning mellan värd och enhet är ett separat prestandaområde från GPU-beräkningar.
Det är därför CPU-avlastning kan omvandla en krasch på grund av slut på minne till en fungerande men långsammare modell. Kapaciteten löses först; genomströmningen kan minska kraftigt.
Mer system-RAM utökar kapaciteten men garanterar inte högre hastighet
Det krävs tillräckligt med RAM för den avlastade delen samt operativsystemet, sidcache, containrar, databaser och andra tjänster på hems server. När modellen börjar använda växlingsutrymme kan en långsam konfiguration bli opraktisk.
Linux dokumenterar minnesåtervinning och växlingsutrymme som en del av systemets minneshierarki. En avlastad modell konkurrerar med alla andra processer om samma RAM-budget.
En hemsserver som också kör en NAS, fotoindexering och en mediedatabas bör ha ordentligt med marginal i stället för att dimensionera RAM-minnet enbart efter modellfilens storlek.
Kvantisering och avlastning löser olika delar av problemet med att få modellen att rymmas
Kvantisering minskar antalet byte som vikterna använder, vilket kan minska både GPU- och CPU-minnets användning och reducera överföringsvolymen. Avlastning ändrar var dessa byte finns under körningen.
NVIDIA NeMo dokumenterar FP8-, INT8- och INT4-kvantisering för lägre modellminnesanvändning. En kvantiserad modell kan få plats helt på GPU:n och undvika avlastning; en större modell kan fortfarande behöva båda teknikerna.
Rätt ordningsföljd är att först avgöra vilken precision och modellkvalitet som är acceptabel, och därefter välja placering. Att avlasta en onödigt stor representation kan slösa bandbredd.
Använd CPU-avlastning när det är viktigare att köra modellen än att maximera genomströmningen
Det tydligaste användningsfallet är en lokal modell som används ibland och överskrider VRAM-kapaciteten men ändå ger acceptabel svarstid när en del av dess tillstånd ligger i RAM. Det är mindre attraktivt för interaktiva tjänster med flera användare, där varje token upprepade gånger måste färdas över en långsam länk.
ZimaSpaces guide till minnes- och acceleratordimensionering för AI-NAS utgör planeringslagret: avlastning bör betraktas som en kapacitetslösning i reserv inom den samlade arbetsbelastningen på hems server.
Mät VRAM-användning, RAM-användning, mängden byte som överförs mellan värd och enhet, tid till första token, antal utgående token per sekund och påverkan på andra självhostade tjänster. En konfiguration som tekniskt sett laddar modellen men tvingar fram växling eller gör NAS:en långsam är inte en användbar lösning.
ZimaSpaces förklaring av modellens minnesnärvaro och bortträngning beskriver den närliggande avvägningen: när acceleratorminne frigörs ökar kapaciteten för annat arbete, men nästa begäran kan behöva betala för laddning eller överföring igen.
Vanliga frågor
Slår CPU-avlastning ihop RAM och VRAM till en enda snabb minnespool?
Nej. Körtidsmiljön kan placera modellens tillstånd över båda nivåerna, men CPU-RAM och GPU-VRAM har olika bandbredd och fördröjning. Överföringarna mellan dem kan bli den främsta flaskhalsen i inferensen.
Blir en avlastad modell snabbare om jag lägger till mer RAM?
Endast om systemet för närvarande har ont om RAM, använder växlingsutrymme eller inte kan hålla det avsedda avlastade tillståndet resident. Extra outnyttjat RAM eliminerar inte kostnaderna för PCIe eller CPU-körning.
Är avlastning till SSD samma sak som CPU-avlastning?
Nej. Diskavlastning lägger till en ännu långsammare lagringsnivå när RAM-minnet inte räcker till. Det kan utöka kapaciteten ytterligare, men modellens sidor måste färdas genom lagringen och vanligtvis systemminnet innan körningen på acceleratorn.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Kan hemkameror synkronisera händelser utan molnbaserade tidstjänster?
En mekanismorienterad förklaring av kameratid utan moln, dess avvägningar kring delade resurser, tre vanliga frågor om frågefanout och ett praktiskt verifieringsprotokoll.
Kan en lokal AI-tjänst upptäcka skadade modellager före inferens?
En mekanismfokuserad förklaring av detektering av korruption i modellagret, dess avvägningar kring delade resurser, tre vanliga frågor om frågefan-out och ett praktiskt verifieringsprotokoll.
Kan ett RAG-system återställas utan att generera om alla embeddingar?
En mekanismförst förklaring av RAG-återställning utan ombäddning, dess avvägningar kring delade resurser, tre vanliga frågor om frågefanout och ett praktiskt verifieringsprotokoll.
