Waarom reserveert een lokale AI-runtime geheugen na een verzoek?

Een lokale AI-runtime reserveert geheugen na een verzoek, zodat toekomstige tensors apparaatblokken opnieuw kunnen gebruiken zonder de herhaalde allocatie- en synchronisatiekosten te betalen.

Het zichtbare resultaat kan op een geheugenlek lijken: de GPU-berekening valt terug naar nul, het antwoord is voltooid, maar het proces neemt nog steeds het grootste deel van het acceleratiergeheugen in beslag. Een deel van die voetafdruk kan bestaan uit actieve modelgewichten of KV-status, terwijl een ander deel toebehoort aan een caching-allocator, uitvoeringscontext, grafiekopname, bibliotheekwerkruimte of keep-alivebeleid van het model. In de onderstaande secties wordt onderscheid gemaakt tussen actieve allocaties en herbruikbare reserveringen. Ook wordt uitgelegd wanneer permanent gereserveerd geheugen normaal of verspild is, of wijst op een echt lek.

Apparaatallocatie is duur genoeg om te cachen

Tensors voor afzonderlijke verzoeken worden herhaaldelijk aangemaakt en vrijgegeven. Elk blok teruggeven aan de driver kan synchronisatie veroorzaken en ervoor zorgen dat het volgende verzoek dezelfde geheugenindeling opnieuw moet opbouwen.

PyTorch’s CUDA-allocator maakt onderscheid tussen gecachete allocatorblokken en tensors die actief gealloceerd blijven.

Het binnen het proces houden van vrije blokken verbetert de latentie bij herhaalde verzoeken, maar een andere AI-service kan die bytes pas gebruiken nadat de allocator ze aan de driver heeft vrijgegeven.

Gealloceerd, gereserveerd en apparaatvrij geheugen zijn verschillende meetwaarden

Gealloceerd geheugen behoort toe aan actieve tensors. Gereserveerd geheugen wordt beheerd door de runtime-allocator en kan zowel actieve allocaties als momenteel ongebruikte, herbruikbare blokken bevatten.

Een runtime kan daardoor zelfs nadat tijdelijke tensors zijn vernietigd een verschil in gereserveerd geheugen tonen.

Apparaattools zoals nvidia-smi rapporteren de voor de driver zichtbare voetafdruk van het proces, niet welke blokken binnen het framework logisch vrij zijn.

Model- en runtimestatus kan bewust actief blijven

Het proces kan modelgewichten, tokenizerstatus, kernels, uitvoeringsgrafieken en acceleratorcontexten gereed houden, omdat het vrijgeven daarvan het volgende verzoek tot een koude start zou maken.

De uitleg van ZimaSpace over modelresidentie laat zien waarom een actieve service geheugen gebruikt, zelfs wanneer momenteel geen gebruiker tokens genereert.

Dit is een bewuste afweging tussen capaciteit en latentie. Vanuit het perspectief van berekeningen is het geheugen inactief, maar als gereedstaande status blijft het waardevol.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Fragmentatie kan ervoor zorgen dat gereserveerde blokken slecht herbruikbaar zijn

Een pool kan in totaal genoeg ongebruikte bytes bevatten, terwijl de blokgroottes niet overeenkomen met het volgende verzoek. Variabele prompts, afbeeldingsvormen, batches en modelwissels kunnen een gefragmenteerd reserveringspatroon veroorzaken.

GMLake onderzoekt allocatorfragmentatie die wordt veroorzaakt door onregelmatige allocatiegroottes.

In dat geval is het behouden geheugen noch actief nuttig, noch beschikbaar voor andere processen. Een herstart van het proces kan tijdelijk een schonere indeling herstellen.

Meet of de voetafdruk stabiliseert of groeit

Voer hetzelfde vaste verzoek herhaaldelijk uit en registreer na elke voltooiing het gealloceerde geheugen, gereserveerde geheugen, de KV-cache, modelgewichten en het apparaatvrije geheugen.

Een stabiele hoge waterstand wijst op normaal cache- of keep-alivegedrag. Een voetafdruk die bij elk identiek verzoek groeit en oude blokken nooit opnieuw gebruikt, wijst op een lek, een onbegrensde cache, een behouden sessie of variatie in de werklast.

Test regelingen voor het vrijgeven van de cache pas nadat is vastgesteld welke status ze verwijderen. Het legen van ongebruikte allocatorblokken laadt actieve modelgewichten niet uit, en het uitladen van het model kan de responstijd verslechteren.

Stel voor een thuisserver met meerdere services per runtime een geheugenbudget en inactiefbeleid vast, zodat de reservering van de ene service niet ongemerkt verhindert dat een andere service start.