Waardoor loopt het geheugenverbruik van een lokale modelserver tussen verzoeken door steeds verder op?

Het geheugen van een lokale modelserver neemt meestal geleidelijk toe doordat caches en allocators herbruikbare blokken vasthouden, hoewel onbegrensde verwijzingen of native lekken echte groei kunnen veroorzaken.

Na elk verzoek aan een homeserver kan een dashboard laten zien dat het RAM- of VRAM-gebruik stijgt zonder terug te keren naar het oorspronkelijke basisniveau. De runtime kan KV-blokken, prefix-items, kernels, grafieken, werkruimten en vrijgegeven tensorblokken voor hergebruik bewaren. Variabele promptlengtes kunnen pools fragmenteren, terwijl logging, sessies, afbeeldingsbuffers of extensies objecten onbeperkt vasthouden. Daarom vereisen deze mechanismen verschillend bewijs en verschillende limieten.

Caching-allocators reserveren vrijgegeven blokken voor hergebruik

GPU-frameworks vermijden dure apparaatallocaties door vrijgegeven blokken in een pool binnen het proces te bewaren. Applicatietensors kunnen verdwenen zijn, terwijl de driver de gereserveerde pool nog steeds rapporteert als geheugen dat door de modelserver wordt gebruikt. Dit onderscheid blijft zichtbaar tijdens latere tests in huis.

Een analyse van de allocator legt uit hoe gecachete GPU-geheugenblokken CUDA-blokken afrondt, splitst, samenvoegt en in de cache opslaat. Het kenmerk is dat het toegewezen tensorgeheugen na een verzoek afneemt, terwijl het gereserveerde geheugen hoog blijft en bij latere verzoeken opnieuw wordt gebruikt.

Dit plateau is niet automatisch een lek. Het wordt schadelijk wanneer de pool voorkomt dat een andere service geheugen kan toewijzen of blijft groeien bij herhaalde verzoeken met dezelfde vorm nadat de opwarmfase is voltooid. Het tussenresultaat moet inspecteerbaar blijven voordat automatisering wordt toegepast.

Servercaches en verzoekvormen vergroten de beoogde werkset

KV-caches groeien mee met de actieve context, prefixcaches bewaren herbruikbare prompts en gecompileerde grafieken of kernels dekken waargenomen batchvormen. Nieuwe contextlengtes, modaliteiten en concurrencyprofielen kunnen tussen verzoeken nieuwe items toevoegen. Die grens moet afzonderlijk worden gemeten onder realistische bedrijfsomstandigheden.

Onderzoek naar geheugenfragmentatie bij LLM's identificeert fragmentatie tussen geheugenruimten voor activaties en KV-caches bij het aanbieden van LLM's. Deze observatie verklaart waarom de totale capaciteit kan toenemen, zelfs wanneer geen enkel actief verzoek groot is. Het praktische gevolg wordt zichtbaar wanneer meerdere bronnen concurreren om beperkte context.

Registreer het aantal cache-items en de vormklassen. Groei die stopt nadat de werkbelasting is gestabiliseerd, is begrensde opwarming; groei die evenredig is aan het totale aantal verzoeken of unieke sessie-ID's wijst op ontbrekende verwijdering. Deze afhankelijkheid moet expliciet blijven in de uiteindelijke interface.

Vastgehouden CPU-objecten en native buffers veroorzaken echte geleidelijke groei

Verzoekgeschiedenissen, streamingwachtrijen, metrieklabels, tokenizeruitvoer, geüploade afbeeldingen, vastgezette hostbuffers en extensieallocaties kunnen na voltooiing nog steeds worden vastgehouden. GPU-snapshots kunnen stabiel lijken terwijl de RSS van het proces blijft stijgen. Het resultaat moet daarom worden vergeleken met het oorspronkelijke bewijs.

Een praktisch onderzoek naar toegewezen versus gereserveerd geheugen maakt onderscheid tussen signalen voor toegewezen geheugen, gereserveerd geheugen en procesgeheugen. Dit gelaagde beeld voorkomt dat een probleem met vasthouden aan de CPU ten onrechte wordt gediagnosticeerd als gedrag van de GPU-allocator. Dit onderscheid blijft zichtbaar tijdens latere tests in huis.

De foutgrens is een eenmalige stijging gevolgd door een stabiel hoogwaterniveau. Noem het pas een lek wanneer gecontroleerde, identieke verzoeken blijvende groei van vastgehouden geheugen veroorzaken nadat cachelimieten, garbagecollection en verwachte pools zijn meegerekend.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Maak een curve van geheugenretentie per verzoek

Speel honderden identieke verzoeken opnieuw af en test daarna gemengde lengtes en modaliteiten, terwijl je toegewezen en gereserveerde GPU-bytes, KV- en prefix-items, de grafiekcache, vastgezette geheugenruimte, de RSS van het proces, aantallen objecten, aanvraagsessies, herstarts van workers en snapshots van de allocator registreert.

Gebruik geheugenreservering na een verzoek om bewuste reservering na een verzoek te onderscheiden. Herhaal dit met elke optionele cache, extensie, uploadroute en metrieklabel afzonderlijk uitgeschakeld, terwijl het model en de concurrency gelijk blijven. Het tussenresultaat moet inspecteerbaar blijven voordat automatisering wordt toegepast.

Accepteer begrensde opwarming die binnen het opgegeven geheugenbudget een plateau bereikt. Voeg verwijdering toe wanneer de kardinaliteit van de cache zonder voordeel groeit, normaliseer verzoekvormen wanneer fragmentatie overheerst en isoleer een echt lek pas nadat stacks van vastgehouden allocaties naar een eigenaar wijzen.