Vad får en lokal AI-körmiljö att läsa in dubbla modellkopior?
Dubbletter av modeller uppstår när separata processer, repliker, sessioner eller enhetskontexter inte kan dela på en redan inläst viktallokering.
En AI-server hemma kan visa ungefär dubbelt så mycket förväntat RAM eller VRAM efter att ett webbgränssnitt, en bakgrundsworker, en rösttjänst, en dokumentindexerare eller en andra API-slutpunkt har lagts till. Modellfilen på disken kan fortfarande finnas i en enda kopia, medan flera runtime-objekt innehåller oberoende vikter, konverterade tensorer, förpaketerade kärnor, cachar och enhetskontexter. Vissa dubbletter uppstår av misstag, medan andra är avsiktliga repliker som skapats för samtidighet, isolering eller parallell körning.
En modellfil kan skapa flera oberoende runtime-objekt
Att läsa in från samma sökväg innebär inte att två program refererar till samma modell i minnet. Varje runtime-instans kan tolka kontrollpunkten och allokera sina egna tensorer.
Google Clouds vägledning för inferens skiljer mellan konfigurationer som läser in en modellkopia per process eller per virtuell maskin.
Om minnesanvändningen ökar i steg motsvarande modellstorleken när antalet workers ökar, är instansreplikering den främsta orsaken. Mindre ökningar tyder snarare på cachar per worker, allokerare eller körningskontexter.
Webbservrar och jobbworkers startar ofta separata processer
En frontendserver, kökonsument, schemaläggare, transkriberingstjänst och RAG-worker kan alla importera modellinläsaren, även när de ingår i samma Compose-stack.
Processisolering ger varje tjänst sitt eget adressutrymme. CPU-sidor kan ibland delas genom operativsystemets mekanismer, men vanliga ramverksobjekt och GPU-allokeringar blir inte automatiskt en gemensam modellserver.
Dubbletterna följer process-ID:n och tjänstegränserna. Om en container frigör ungefär en modellkopia när den stoppas, vidarebefordrade containern inte bara förfrågningar till en central runtime.
Serveringsrepliker är individuella kopior avsiktligt
Autoskalningssystem ökar genomströmningen genom att starta fler repliker. En replik är en oberoende worker som kan hantera förfrågningar när andra workers är upptagna.
Ray Serve definierar repliker som individuella kopior som körs i separata aktörsprocesser.
Minnestillväxt som följer trafiktoppar eller autoskalningshändelser är avsiktlig replikering, inte en läcka. Orsaken är den valda samtidighetsmodellen, även om det kan ta tid för de extra replikerna att skalas ned igen.
Flera inferenssessioner kan duplicera initierare och förpaketerade vikter
Ett program kan skapa flera sessioner i samma process för olika trådar, slutpunkter, profiler eller körningsleverantörer.
ONNX Runtime dokumenterar delning av allokerare, initierare och förpaketerade vikter mellan sessioner, eftersom separata sessioner annars ökar minnesåtgången.
Om en process äger flera sessionobjekt och minnesanvändningen ökar när varje session initieras, finns det duplicerade tillståndet i programmet snarare än mellan containrar.
Forking garanterar inte delade acceleratorvikter
En föräldraprocess kan läsa in en modell innan workers skapas och till synes dela CPU-sidor genom copy-on-write. Initiering av acceleratorn och föränderligt runtime-tillstånd gör det antagandet mer komplicerat.
PyTorchs vägledning för multiprocessing förklarar att tensorer kan använda mekanismer för delat minne mellan processer, men delning kräver en uttryckligen kompatibel utformning.
En worker som flyttar modellen till GPU:n, ändrar vikter, bygger en cache eller initieras efter spawn kan allokera en ny kopia, även om de ursprungliga CPU-sidorna för kontrollpunkten delades.
Separata CUDA-kontexter lägger till enhetstillstånd per process
Två processer som använder samma GPU arbetar normalt genom separata CUDA-kontexter, såvida inte en särskild delningsarkitektur används.
NVIDIA påpekar att flera CUDA-applikationsprocesser i allmänhet skapar flera kontexter med minnesåtgång.
Kontextåtgången är inte i sig en andra komplett modell, men den kan förekomma tillsammans med duplicerade vikter, kärnor, arbetsytor och cachar. Minnesökningar som är mindre än kontrollpunktens storlek kan därför ändå bero på processduplicering.
Två runtime-instanser på samma GPU reserverar minne oberoende av varandra
En instrumentpanel kan starta en modellserver medan en automatiseringstjänst startar en annan, där båda pekar på samma kontrollpunkt och enhet.
vLLM dokumenterar att GPU-minnesutnyttjande är en gräns per instans och ger exemplet att två instanser delar på kapaciteten hos en GPU.
Om varje slutpunkt har sin egen lyssnare, sina egna loggar, sin egen schemaläggare och sin egen KV-cache, är de två processerna oberoende inferensmotorer. En gemensam modellkatalog förhindrar dubbla nedladdningar, men inte dubbla runtime-allokeringar.
Omladdningar kan lämna en gammal process vid sidan av den nya
Hot reloaders, supervisorer, rullande uppdateringar, misslyckade avstängningar och omstarter efter hälsokontroller kan starta en ersättare innan den gamla workern frigör sin modell.
Denna orsak visar sig som ett tillfälligt eller permanent par av nästan identiska processer med olika starttider. Förfrågningar kan nå endast den nyare processen medan den äldre fortsätter att hålla RAM eller VRAM.
ZimaSpaces artikel om varför man bör separera AI-runtime-tillstånd från modellfiler tydliggör gränsen: en gemensam cache för kontrollpunkter kan betjäna många distributioner, men tjänstetopologin avgör fortfarande hur många inlästa kopior som finns.
Vanliga frågor
Innebär en enda modellfil på disken att det bara finns en kopia i RAM?
Nej. Flera processer eller sessioner kan läsa samma fil separat och allokera egna tensorer, cachar och körningstillstånd.
Är varje extra kopia en minnesläcka?
Nej. Repliker, tensorparallella workers, reservkörningsmiljöer och isolerade tjänster kan avsiktligt allokera ytterligare tillstånd. En läcka växer utan motsvarande aktivt runtime-objekt.
Kan containrar automatiskt dela en modell på samma GPU?
Nej. Containrar kan komma åt samma enhet och filer, men de behöver en gemensam serveringsprocess eller en uttrycklig processöverskridande utformning för att återanvända en enda inläst modellallokering.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Vilka funktioner möjliggör en AI-förtroendegräns i hemmet runt känsliga filer?
En förtroendegräns för AI i hemmet kombinerar kryptering i vila, behörigheter enligt principen om minsta privilegium, sandlådeförsörjning vid körning och avgränsad informationshämtning – ingen...
Vad gör att privata sökresultat prioriterar filer som redigeras ofta?
Filer som redigeras ofta får rankingfördelar när varje uppdatering lägger till färskhet, delar, versioner eller interaktionssignaler utan att normalisera efter källa.
Vad får modeller för närvaro i smarta hem att förväxla gäster med boende?
Gäster kan se ut som boende när systemet observerar aktivitetsmönster i hushållet men saknar en stabil identitetssignal för personen som ger upphov till dem.
