Waarom kan GPU-geheugenfragmentatie een lokaal AI-model blokkeren?

Fragmentatie van GPU-geheugen kan een lokaal AI-model blokkeren wanneer vrije capaciteit is opgesplitst in gebieden die niet kunnen voldoen aan het volgende allocatiepatroon van de runtime.

De fout treedt vaak op na het wisselen van modellen, het wijzigen van contextlengtes, het gelijktijdig uitvoeren van beeld- en taalwerklasten of het verwerken van aanvragen waarvan tijdelijke tensors groter en kleiner worden. Monitoring kan ongebruikt VRAM tonen, terwijl de allocator nog steeds geen grote werkruimte, modelshard of uitbreiding van de KV-cache kan plaatsen zonder bestaande blokken vrij te geven of opnieuw te ordenen. In de onderstaande secties wordt onderscheid gemaakt tussen een werkelijk capaciteitstekort en allocatorfragmentatie. Ook wordt uitgelegd waarom het opnieuw starten van de runtime er tijdelijk voor kan zorgen dat hetzelfde model weer past.

Totale hoeveelheid vrij VRAM is niet hetzelfde als bruikbare allocatieruimte

Een geheugenmonitor rapporteert de totale capaciteit, maar een allocator moet aanvragen afhandelen via de blokken en virtuele mappings die hij beheert. Meerdere kleine vrije gebieden kunnen samen groter zijn dan de gevraagde omvang en toch onbruikbaar zijn wanneer een aaneengesloten allocatieregel geldt.

Een analyse van LLM-operaties beschrijft deze mismatch van vrij geheugen, waarbij KV-caches en variabele tensors gaten achterlaten die kleiner zijn dan de volgende aanvraag. De zichtbare OOM-fout gaat dus zowel over de indeling als over het totale aantal bytes.

Stuurprogramma’s en frameworks kunnen apparaatvrij, gereserveerd, toegewezen en inactief geheugen ook verschillend rapporteren. Vergelijk de weergave van de runtime-allocator met het gebruik op apparaatniveau in plaats van op één totaalcijfer te vertrouwen.

Veranderende tensoromvang creëert na verloop van tijd gaten

AI-werklasten wijzen herhaaldelijk tensors van verschillende omvang toe en geven deze weer vrij voor prompts, batches, afbeeldingsafmetingen, attention-werkomgevingen en tijdelijke conversies. Een caching-allocator houdt blokken vast voor hergebruik, omdat ze telkens teruggeven aan het stuurprogramma veel tijd kost.

Onderzoek van GMLake laat zien dat onregelmatige allocaties op splitsing gebaseerde geheugenpools kunnen verslechteren en aanzienlijke fragmentatie in grote modellen kunnen veroorzaken. Exact dezelfde omvang hergebruiken is efficiënt; herhaaldelijk splitsen en samenvoegen van niet-passende groottes is moeilijker.

Een thuisserver waarop van model wordt gewisseld, is bijzonder kwetsbaar omdat runtimes voor taal, diffusie, beeld en spraak zeer verschillende blokvormen van dezelfde GPU aanvragen.

Fragmentatie kan zich opstapelen zonder geheugenlek. Elke allocatie kan uiteindelijk aan de pool worden teruggegeven, terwijl de vorm van de pool slecht blijft aansluiten op de volgende workload.

Een groeiende KV-cache maakt inferentiefragmentatie dynamisch

LLM-gewichten zijn na het laden relatief stabiel, terwijl de KV-cache groeit met het aantal actieve gebruikers, de promptlengte en het aantal gegenereerde tokens. Aanvragen worden ook op verschillende momenten voltooid, waardoor ongelijkmatige gebieden vrijkomen.

PagedAttention is ontwikkeld om KV-cachefragmentatie te verminderen door de status van aanvragen in kleinere blokken op te slaan, in plaats van één groot aaneengesloten gebied te reserveren voor een onbekende uiteindelijke sequentielengte.

Dit probleem verschilt van fragmentatie in de algemene tensor-allocator van het framework, maar beide kunnen tegelijkertijd optreden. Een gepagineerde KV-manager kan modelwerkomgevingen of allocaties die eigendom zijn van een ander proces niet automatisch compacteren.

De bespreking van gelijktijdige contexten door ZimaSpace laat zien waarom een model dat voor één gebruiker past, een geheugenlimiet kan overschrijden wanneer meerdere gesprekken zich gelijktijdig uitbreiden.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Gereserveerd geheugen kan de fout op een lek laten lijken

Framework-allocators houden vaak vrijgegeven blokken vast om latere aanvragen sneller af te handelen. Apparatuurgereedschappen tellen deze blokken als door het proces gebruikt, zelfs wanneer het huidige model niet in alle blokken actieve tensors heeft.

Een praktische OOM-gids maakt onderscheid tussen gereserveerd geheugen en de vereisten van het actieve model en de cache. Een groot verschil kan wijzen op herbruikbare allocatorblokken, fragmentatie of een workload waarvan de piek hoger lag dan de huidige toestand.

Het wissen van een cache kan sommige blokken aan het stuurprogramma teruggeven, maar kan geen actieve gewichten, actieve KV-status, de context van een ander proces of een werkruimte vrijmaken die door de volgende bewerking nodig is.

Stabiele allocatievormen en paging verminderen terugkerende fouten

Reproduceer de fout met één model, een vaste contextlimiet, een vaste batchgrootte en zonder concurrerende AI-services. Leg toegewezen en gereserveerd geheugen op procesniveau vast, evenals vrij geheugen op apparaatniveau, de grootste aanvraag en de reeks workloads die aan de OOM-fout voorafging.

vAttention gebruikt toewijzing via virtueel geheugen om aaneengesloten virtuele KV-ruimte te scheiden van fysieke allocatie. Vergelijkbare benaderingen met paging en gesegmenteerde allocatie verminderen de afhankelijkheid van één fysiek aaneengesloten gebied.

Praktische maatregelen voor een thuisserver zijn onder meer VRAM-reserve aanhouden, het wisselen van modellen beperken, stabiele limieten voor context en batches gebruiken, services via één runtime coördineren en een gefragmenteerd proces tijdens onderhoud opnieuw starten in plaats van nadat een gebruikersaanvraag is mislukt.

Als een schone herstart er niet voor zorgt dat het model past, is het primaire probleem waarschijnlijk werkelijke capaciteit en niet opgehoopte fragmentatie. Verklein het model, de geheugengrootte van de kwantisering, de context, de batch of concurrerende allocaties.