Varför reserverar en lokal AI-runtime minne efter en begäran?

En lokal AI-körmiljö reserverar minne efter en begäran så att framtida tensorer kan återanvända enhetsblock utan upprepade kostnader för allokering och synkronisering.

Det synliga resultatet kan se ut som en minnesläcka: GPU-beräkningen sjunker till noll, svaret är färdigt, men processen använder fortfarande merparten av acceleratorns minne. En del av minnesavtrycket kan bestå av aktiva modellvikter eller KV-tillstånd, medan en annan del tillhör en cacheallokator, en exekveringskontext, en graffångst, ett biblioteksarbetsutrymme eller en policy för att hålla modellen aktiv. Avsnitten nedan skiljer aktiva allokeringar från återanvändbara reservationer och visar när beständigt minne är normalt, slösaktigt eller ett tecken på en verklig läcka.

Enhetsallokering är tillräckligt kostsam för att cachelagras

Tensorer som skapas vid begäran skapas och frigörs upprepade gånger. Att lämna tillbaka varje block till drivrutinen kan orsaka synkronisering och göra att nästa begäran måste bygga upp samma minneslayout igen.

PyTorchs CUDA-allokator skiljer cachelagrade allokatorblock från tensorer som fortfarande är aktivt allokerade.

Att behålla lediga block i processen förbättrar svarstiden vid upprepade begäranden, men en annan AI-tjänst kan inte använda dessa byte förrän allokatorn lämnar tillbaka dem till drivrutinen.

Allokerat, reserverat och ledigt enhetsminne är olika mätvärden

Allokerat minne tillhör aktiva tensorer. Reserverat minne hanteras av körmiljöns allokator och kan innehålla både aktiva allokeringar och för närvarande oanvända, återanvändbara block.

En körmiljö kan därför visa ett gap i reserverat minne även efter att tillfälliga tensorer har förstörts.

Enhetsverktyg som nvidia-smi rapporterar processens drivrutinssynliga minnesavtryck, inte vilka block som logiskt sett är lediga i ramverket.

Modell- och körmiljötillstånd kan avsiktligt förbli varmt

Processen kan behålla modellvikter, tokenizer-tillstånd, kärnor, exekveringsgrafer och accelerator­kontexter redo, eftersom nästa begäran annars skulle innebära en kallstart.

ZimaSpaces förklaring av modellnärvaro visar varför en varm tjänst använder minne även när ingen användare för närvarande genererar token.

Detta är en avsiktlig avvägning mellan kapacitet och svarstid. Minnet är inaktivt ur beräkningsperspektiv men fortfarande värdefullt som färdigt tillstånd.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Fragmentering kan göra reserverade block svåra att återanvända

En pool kan totalt sett innehålla tillräckligt många oanvända byte, samtidigt som blockstorlekarna inte passar nästa begäran. Variabla promptar, bildstorlekar, batcher och modellbyten kan skapa ett fragmenterat reservationsmönster.

GMLake studerar fragmentering i allokatorer som orsakas av oregelbundna allokeringsstorlekar.

I så fall är det kvarhållna minnet varken aktivt användbart eller tillgängligt för andra processer, och en omstart av processen kan tillfälligt återställa en renare layout.

Mät om minnesavtrycket stabiliseras eller växer

Kör samma fasta begäran upprepade gånger och registrera allokerat minne, reserverat minne, KV-cache, modellvikter och enhetsfritt minne efter varje slutförande.

Ett stabilt högt vattenmärke tyder på normalt cachelagrings- eller håll-kvar-beteende. Ett minnesavtryck som växer för varje identisk begäran och aldrig återanvänder gamla block tyder på en läcka, en obegränsad cache, en kvarhållen session eller variationer i arbetsbelastningen.

Testa kontroller för att frigöra cache först efter att du har bekräftat vilket tillstånd de tar bort. Att tömma oanvända allokatorblock avlastar inte aktiva modellvikter, och att läsa ur modellen kan försämra svarstiden.

För en hemserver med flera tjänster bör du definiera en minnesbudget och en inaktivitetspolicy för varje körmiljö, så att en tjänsts reservation inte i det tysta hindrar en annan från att starta.