Waarom starten gecontaineriseerde AI-modellen opnieuw op, zelfs wanneer de host vrije geheugenruimte meldt?
Gecontaineriseerde AI-modellen kunnen opnieuw starten ondanks vrij hostgeheugen, omdat hun cgroup-, accelerator- of supervisorlimieten beperkter zijn dan het RAM-overzicht van de hele machine.
Een dashboard voor een homeserver kan meerdere vrije gigabytes tonen terwijl een inferentiecontainer verdwijnt en terugkomt met een nieuwe proces-ID. De container kan zijn eigen geheugenlimiet bereiken, een healthcheck tijdens het terugwinnen van geheugen niet doorstaan, het GPU-geheugen uitputten of afsluiten na een allocatiefout. Een herstartbeleid maakt van die lokale fout een ogenschijnlijk spontane herstart van het model.
De container heeft een andere geheugenlimiet dan de host
Linux-control groups houden het geheugen van een geselecteerde procesgroep bij en beperken dit. Een container kan memory.max of een runtime-limiet bereiken terwijl er voor de kernel nog RAM beschikbaar is op de host. Het vrije geheugen van de hele machine geeft daarom niet de allocatielimiet weer die voor die service wordt afgedwongen.
Een gedetailleerde uitleg van cgroup-geheugenboekhouding maakt onderscheid tussen anoniem geheugen, toegewezen bestanden en cache die aan een control group wordt toegerekend. Die boekhouding laat zien waarom vanuit schijf toegewezen gewichten, tijdelijke modelbuffers en pagecache het budget van een container kunnen verbruiken, zelfs wanneer een eenvoudige RSS-weergave van processen kleiner lijkt.
Limieten kunnen ook genest zijn: een modelcontainer kan zich binnen een compose-service, systemd-slice, virtuele machine of orkestratiegroep bevinden. De nauwste actieve grens kan reclaim of een out-of-memory-kill veroorzaken voordat de fysieke host bijna volledig is uitgeput.
Geheugendruk kan healthchecks vertragen vóór een OOM-kill
Naarmate de limiet wordt benaderd, kan de kernel cache terugwinnen, geheugen scannen en allocaties afremmen. Het model kan actief blijven, maar te traag reageren voor een healthprobe. Daardoor kan de supervisor het beëindigen en een vervanging starten zonder een OOM-kill op containerniveau te registreren.
Het framework voor pressure stall information meet tijdverlies doordat taken wachten op geheugen-, CPU- of I/O-druk, in plaats van alleen naar gebruik te kijken. Pressure stall information verklaart waarom vrije bytes en de responsiviteit van een service tijdens agressief reclaimen uiteen kunnen lopen.
Het laden van AI-modellen veroorzaakt pieken met een grillig verloop: deserialisatie kan tijdelijk gecomprimeerde en uitgepakte gewichten in het geheugen houden, kwantisatie kan tijdelijke werkruimte alloceren en parallelle workers kunnen buffers dupliceren. De stabiele geheugengrootte na het laden onderschat daarom de korte piek die samenvalt met de mislukte probe.
GPU-fouten en herstartbeleid kunnen zich voordoen als een OOM op de host
Host-RAM-statistieken sluiten dedicated VRAM normaal gesproken uit. Een model kan een GPU-allocatie niet uitvoeren omdat gewichten, KV-cache, kernels en een andere workload de accelerator bezetten. Vervolgens kan het afsluiten met een applicatiefout terwijl de host nog steeds veel systeemgeheugen rapporteert.
Richtlijnen voor resourcebeheer maken onderscheid tussen geheugenlimieten van containers en een geheugentekort op knooppuntniveau. Ze leggen uit dat limieten worden afgedwongen door de runtime en de kernel, niet door het label voor vrij geheugen op het dashboard. De herstart wordt vervolgens bepaald door het herstartbeleid van de workload, niet door de geheugenmeting zelf.
De foutgrens is aannemen dat elke nieuwe container-ID een OOM-gebeurtenis bewijst. Image-updates, time-outs van watchdogs, handmatige redeployments, apparaatresets en applicatiecrashes veroorzaken hetzelfde zichtbare symptoom. De afsluitreden, kernel-log, cgroup-events en GPU-fouten moeten overeenkomen voordat je geheugen als oorzaak aanwijst.
Koppel de afsluitreden aan elke geheugenlimiet
Reproduceer het laden van één model terwijl je containergeheugen.current, geheugen.max, geheugen.events, proces-RSS en toegewezen bestanden, MemAvailable op de host, totalen van pressure stalls, GPU-geheugen, latency van de healthprobe, procesafsluitcode en het aantal herstarts van de supervisor op één klok registreert.
Gebruik conflicten tussen containers als context en herhaal de test vervolgens met hetzelfde model onder een hogere containerlimiet, een uitgeschakeld herstartbeleid en zonder concurrerende acceleratorworkload. Wijzig per test slechts één grens, zodat een geslaagde herstart de oorspronkelijke fout niet verbergt.
Classificeer de gebeurtenis als cgroup-OOM, globale OOM, GPU-allocatiefout, beëindiging door een healthcheck of afsluiting door de applicatie voordat je limieten aanpast. Als de piek legitiem is, houd dan voldoende marge aan. Als een probe een model beëindigt dat door reclaimen vertraagt maar wel gezond is, pas dan de timing van de probe aan zonder echte vastlopers te verbergen.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Hoe geeft een geheime broker een AI-agent inloggegevens zonder ze in prompts bloot te stellen?
Volg workloadidentiteit, beleid, tokenuitgifte, requestinjectie, redactie, vervaldatum en intrekking binnen een secretless-architectuur voor een lokale AI-agent.
Hoe beperkt een tool-sandbox de neveneffecten van AI-agenten?
Ontdek hoe isolatie, bevoegdheidspoorten, wegwerpstatus, uitgaand verkeerbeheer, quota's en auditlogs de neveneffecten van AI-agenten beperken zonder te bewijzen dat acties veilig zijn.
Hoe produceert constrained decoding schema-geldige JSON?
Begrijp schema-compilatie, tokenmaskering, parserstatus, ondersteunde subsets, latentie, afkapping en waarom structurele geldigheid geen correcte waarden garandeert.
