Waardoor laadt een lokale AI-runtime dubbele modelkopieën?
Dubbele modelkopieën ontstaan wanneer afzonderlijke processen, replica’s, sessies of apparaatcontexten één geladen gewichtsallocatie niet kunnen delen.
Een thuis-AI-server kan ongeveer twee keer zoveel RAM of VRAM gebruiken als verwacht nadat je een webinterface, achtergrondworker, spraakdienst, documentindexeerder of tweede API-eindpunt hebt toegevoegd. Het modelbestand op schijf kan enkelvoudig blijven, terwijl meerdere runtime-objecten onafhankelijke gewichten, geconverteerde tensors, vooraf verpakte kernels, caches en apparaatcontexten bevatten. Sommige duplicatie is onbedoeld; andere kopieën zijn bewust aangemaakte replica’s voor gelijktijdige verwerking, isolatie of parallelle uitvoering.
Eén modelbestand kan meerdere onafhankelijke runtime-objecten opleveren
Laden vanaf hetzelfde pad betekent niet dat twee applicaties naar één model in het geheugen verwijzen. Elke runtime-instantie kan het checkpoint parseren en eigen tensors alloceren.
De inferentierichtlijnen van Google Cloud maken onderscheid tussen configuraties die één modelkopie per proces of per virtuele machine laden.
Als het geheugengebruik in stappen ter grootte van het model toeneemt wanneer het aantal workers stijgt, is replicatie van instanties de belangrijkste oorzaak. Kleinere toenames wijzen eerder op caches, allocators of uitvoeringscontexten per worker.
Webservers en jobworkers starten vaak afzonderlijke processen
Een frontendserver, wachtrijconsument, planner, transcriptiedienst en RAG-worker kunnen elk de modellader importeren, ook als ze deel uitmaken van één Compose-stack.
Procesisolatie geeft elke service een eigen adresruimte. CPU-pagina’s kunnen soms worden gedeeld via mechanismen van het besturingssysteem, maar gewone frameworkobjecten en GPU-allocaties vormen niet automatisch één gedeelde modelservice.
De duplicatie volgt proces-ID’s en servicegrenzen. Als het stoppen van één container ongeveer één modelkopie vrijgeeft, stuurde de container verzoeken niet alleen door naar een centrale runtime.
Serverreplica’s zijn bewust afzonderlijke kopieën
Autoscalingsystemen verhogen de doorvoer door meer replica’s te starten. Een replica is een onafhankelijke worker die verzoeken kan verwerken wanneer andere workers bezet zijn.
Ray Serve definieert replica’s als afzonderlijke kopieën die in aparte actorprocessen draaien.
Geheugengroei die gelijke tred houdt met verkeerspieken of autoscalinggebeurtenissen is opzettelijke replicatie, geen geheugenlek. De oorzaak is het gekozen concurrentiemodel, ook als het later enige tijd duurt voordat extra replica’s worden afgebouwd.
Meerdere inferentiesessies kunnen initialisatoren en vooraf verpakte gewichten dupliceren
Een applicatie kan binnen één proces meerdere sessies aanmaken voor verschillende threads, eindpunten, profielen of uitvoeringsproviders.
ONNX Runtime documenteert het delen van allocators, initialisatoren en vooraf verpakte gewichten tussen sessies, omdat afzonderlijke sessies anders extra geheugen gebruiken.
Als één proces meerdere sessieobjecten beheert en het geheugengebruik toeneemt wanneer elke sessie wordt geïnitialiseerd, bevindt de dubbele toestand zich binnen de applicatie en niet tussen containers.
Forking garandeert geen gedeelde acceleratorgewichten
Een bovenliggend proces kan een model laden voordat het workers aanmaakt en daardoor CPU-pagina’s lijken te delen via copy-on-write. Initialisatie van accelerators en veranderlijke runtime-status maken die aanname ingewikkelder.
De multiprocessingrichtlijnen van PyTorch leggen uit dat tensors mechanismen voor gedeeld geheugen tussen processen kunnen gebruiken, maar dat delen een expliciet compatibel ontwerp vereist.
Een worker die het model naar de GPU verplaatst, gewichten wijzigt, een cache opbouwt of na het starten wordt geïnitialiseerd, kan een nieuwe kopie alloceren, zelfs als de oorspronkelijke CPU-checkpointpagina’s werden gedeeld.
Afzonderlijke CUDA-contexten voegen apparaattoestand per proces toe
Twee processen die één GPU gebruiken, werken normaal gesproken met afzonderlijke CUDA-contexten, tenzij een speciale deelarchitectuur wordt gebruikt.
NVIDIA merkt op dat meerdere CUDA-applicatieprocessen doorgaans meerdere contexten met geheugenoverhead aanmaken.
Contextoverhead is op zichzelf geen tweede volledig model, maar kan samengaan met gedupliceerde gewichten, kernels, werkruimten en caches. Een geheugentoename die kleiner is dan de checkpointgrootte kan daarom nog steeds door procesduplicatie worden veroorzaakt.
Twee runtime-instanties op één GPU reserveren elk afzonderlijk geheugen
Een dashboard kan één modelserver starten terwijl een automatiseringsservice een tweede start, waarbij beide naar hetzelfde checkpoint en apparaat verwijzen.
vLLM documenteert dat GPU-geheugengebruik een limiet per instantie is en geeft als voorbeeld twee instanties die de capaciteit van één GPU verdelen.
Als elk eindpunt een eigen listener, logboek, planner en KV-cache heeft, zijn de twee processen onafhankelijke inferentie-engines. Een gedeelde modelmap voorkomt dubbele downloads, maar niet dubbele runtime-allocaties.
Herlaadacties kunnen een oud proces naast het nieuwe actief laten
Hot reloaders, supervisors, rolling updates, mislukte afsluitingen en herstarts na gezondheidscontroles kunnen een vervanging starten voordat de oude worker zijn model vrijgeeft.
Deze oorzaak verschijnt als een tijdelijk of blijvend paar vrijwel identieke processen met verschillende starttijden. Verzoeken kunnen alleen het nieuwere proces bereiken, terwijl het oudere RAM of VRAM blijft vasthouden.
Het artikel van ZimaSpace over waarom je AI-runtimestatus van modelbestanden moet scheiden verduidelijkt de grens: één checkpointcache kan veel implementaties bedienen, maar de servicetopologie bepaalt nog steeds hoeveel geladen kopieën er bestaan.
Veelgestelde vragen
Betekent één modelbestand op schijf dat er maar één kopie in het RAM staat?
Nee. Meerdere processen of sessies kunnen hetzelfde bestand onafhankelijk lezen en hun eigen tensors, caches en uitvoeringsstatus alloceren.
Is elke extra kopie een geheugenlek?
Nee. Replica’s, tensorparallelle workers, fallback-runtimes en geïsoleerde services kunnen bewust extra toestand alloceren. Een lek groeit zonder overeenkomstig actief runtime-object.
Kunnen containers automatisch één GPU-model delen?
Nee. Containers kunnen toegang hebben tot hetzelfde apparaat en dezelfde bestanden, maar hebben een gedeeld serverproces of een expliciet ontwerp voor communicatie tussen processen nodig om één geladen modelallocatie opnieuw te gebruiken.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Welke functies maken een vertrouwensgrens voor thuis-AI rond gevoelige bestanden mogelijk?
Een vertrouwensgrens voor thuis-AI combineert versleuteling van gegevens in rust, rechten volgens het principe van minimale bevoegdheden, sandboxing tijdens runtime en retrieval met beperkte...
Waardoor krijgen vaak bewerkte bestanden voorrang in privézoekresultaten?
Vaak bewerkte bestanden krijgen een hogere ranking wanneer elke update versheid, chunks, versies of interactiesignalen toevoegt zonder te normaliseren op basis van de bron.
Waardoor verwarren slimme-aanwezigheidsmodellen gasten met bewoners?
Gasten kunnen op bewoners lijken wanneer het systeem activiteitspatronen in het huishouden waarneemt, maar geen stabiel identiteitssignaal heeft voor de persoon die deze veroorzaakt.
