Wat is modelresidentie en wanneer moet een lokale AI-service gewichten geladen houden?

Modelresidentie betekent dat modelgewichten tussen verzoeken door in het geheugen van de host of accelerator blijven, zodat de volgende inferentie een deel van of al het laadwerk kan overslaan.

Een thuisassistent die om de paar minuten wordt gebruikt, werkt heel anders wanneer een model van acht gigabyte in het GPU-geheugen blijft staan dan wanneer het telkens opnieuw uit de opslag moet worden gelezen. Residentie kan op verschillende niveaus bestaan: bestandssysteemcache, toegewezen hostpagina's, vastgezette RAM of VRAM die klaarstaat voor kernels. Door gewichten warm te houden, wordt de opstartvertraging verminderd, maar er wordt schaarse geheugenruimte gereserveerd en mogelijk voorkomen dat andere modellen of workloads worden uitgevoerd.

Residentie beschrijft waar herbruikbare modelstatus blijft staan

Een koud model bestaat alleen in de opslag en moet vóór inferentie worden gelezen, toegewezen, getransformeerd en gekopieerd. Host-residente gewichten voorkomen leesbewerkingen uit de opslag, terwijl accelerator-residente gewichten ook de overdracht van host naar apparaat en het initialisatiepad van de runtime vermijden. Dit onderscheid blijft zichtbaar tijdens latere tests in huis.

NVIDIA's analyse van modelstreaming scheidt het laadpad van het model van overdrachts- en initialisatiewerk, en laat zien waarom de locatie van gewichten bij veel koude starts bepalend is. Een warm proces heeft mogelijk nog steeds initialisatie van de tokenizer, grafiek, adapter of cache nodig. Het tussenresultaat moet controleerbaar blijven voordat automatisering het overneemt.

Residentie is niet hetzelfde als een actief verzoek. Een model kan geladen blijven zonder KV-cache of gebruikersgegevens, klaar om verzoeken te verwerken terwijl het geheugen en enige achtergrondbronnen gebruikt. Die grens moet afzonderlijk worden gemeten onder realistische bedrijfsomstandigheden.

Warmte bestaat binnen een geheugenhiërarchie

Het besturingssysteem kan modelpagina's in de paginacache behouden nadat een proces is afgesloten, geheugenmapping kan pagina's vertraagd inladen en een serveerproces kan tensors in RAM of VRAM bewaren. Elk warmer niveau verlaagt doorgaans de latentie, terwijl het een meer beperkte bron gebruikt.

ServerlessLLM onderzoekt gelaagd modelladen in opslag, hostgeheugen en GPU-geheugen en plant het laden om de kosten van koude starts te verlagen. De hiërarchie verklaart waarom een model dat ogenschijnlijk is uitgeladen, snel kan herstarten totdat cache- druk ervoor zorgt dat de pagina's worden verwijderd.

Quantisatie verlaagt het aantal bytes dat nodig is voor residentie en kan ervoor zorgen dat meerdere gespecialiseerde modellen naast elkaar bestaan. Het kan ook uitvoeringskernels en kwaliteit veranderen, dus geheugenbesparing mag niet worden beschouwd als een gratis capaciteitsverhoging. Het praktische gevolg wordt zichtbaar wanneer meerdere bronnen concurreren om beperkte context.

Uitzettingsbeleid zet geheugendruk om in opstartvertraging

Een service kan veelgebruikte modellen resident houden en koudere modellen verwijderen op basis van recent gebruik, voorspelde vraag, prioriteit of laadkosten. Routering met meerdere modellen vereist toelatingsregels, zodat achtergrondwerk het spraakmodel dat onmiddellijk moet antwoorden niet verdringt.

FlexGen demonstreert offloading van gewichten tussen GPU, CPU en opslag voor inferentie met beperkte middelen. Hoewel het op doorvoer is gericht, maakt het de belangrijkste afweging duidelijk: het verplaatsen van gewichten tussen niveaus bespaart schaars geheugen, maar brengt overdrachts- en planningskosten met zich mee.

De foutgrens is geheugendruk die swapping, OOM-herstarts of een uitzettingslus veroorzaakt. Te veel gewichten geladen houden kan elk model trager en minder betrouwbaar maken dan het bewust warm houden van een kleinere actieve set. Deze afhankelijkheid moet expliciet blijven in de uiteindelijke interface.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Stel residentie in op basis van hergebruikafstand en geheugenmarge

Meet voor elk model de opstarttijd bij een koude, host-warme en accelerator-warme start en leg vervolgens het verzoekinterval, het aantal laadbytes, het VRAM- en RAM-gebruik, het inactieve energieverbruik, het aantal uitzettingen en de vraag van concurrerende workloads vast. Het resultaat moet daarom worden gecontroleerd aan de hand van het oorspronkelijke bewijsmateriaal.

Vergelijk het opstartmechanisme met opstarten via geheugenmapping. Speel een week aan aankomsten af met verschillende keep-alivevensters en prioriteiten, inclusief pieken, lange perioden van inactiviteit en gelijktijdige modelverzoeken. Dit onderscheid blijft zichtbaar tijdens latere tests in huis.

Houd een model resident wanneer de vermeden laadlatentie en hergebruikfrequentie het beschermde geheugen rechtvaardigen. Verwijder het wanneer de gereserveerde capaciteit wachtrijen of thrashing veroorzaakt en behoud een noodmarge voor de KV-cache en tijdelijke toewijzingen.