Mappatura della memoria dei file dei modelli: come le pagine condivise riducono l’uso duplicato della RAM
I file di modello mappati in memoria possono ridurre l’uso duplicato della RAM, perché i processi fanno riferimento alle stesse pagine pulite, supportate dal file, tramite la cache delle pagine del sistema operativo.
Caricare due worker locali per il modello non richiede sempre due copie complete del file dei pesi nella memoria fisica. Con il memory mapping, ogni processo riceve indirizzi virtuali associati agli offset del file e le pagine vengono caricate su richiesta. Il sistema operativo può fornire le stesse pagine pulite a partire da un’unica copia fisica nella cache, mantenendo separato lo stato runtime privato di ciascun processo.
Il memory mapping collega gli indirizzi virtuali agli offset del file
Un file mappato appare nello spazio degli indirizzi di un processo senza che l’applicazione debba leggere l’intero file in un buffer separato nell’heap. L’accesso a una pagina assente genera un page fault; il kernel carica o individua la pagina corrispondente supportata dal file e aggiorna la tabella delle pagine del processo.
Il manuale Linux del memory mapping documenta le mappature MAP_SHARED e MAP_PRIVATE e il rapporto tra gli aggiornamenti delle mappature e l’oggetto sottostante. I pesi dei modelli in sola lettura rimangono comunemente dati puliti supportati dal file, rendendoli idonei al riutilizzo tramite la page cache. Questa distinzione resta importante in condizioni operative domestiche realistiche.
Il demand paging può abbreviare l’avvio e limitare la memoria residente quando viene utilizzata solo una parte del modello. Può anche spostare il costo al primo accesso, perciò i page fault relativi alle pagine fredde e la latenza dello storage possono manifestarsi durante l’inferenza anziché durante una fase di caricamento esplicita.
La page cache può servire più processi contemporaneamente
Due processi possono mappare lo stesso inode del modello e gli stessi offset in spazi di indirizzi virtuali differenti. Quando entrambi leggono la stessa pagina pulita, il kernel può mappare la stessa pagina fisica nella cache in entrambe le tabelle delle pagine. Le mappature virtuali sono separate; i dati residenti sottostanti possono essere condivisi.
La documentazione Linux relativa ai dati di mappatura delle pagine spiega come lo userspace possa esaminare le mappature delle pagine e le informazioni sui page frame, nel rispetto delle restrizioni di accesso. Queste interfacce aiutano a mostrare se regioni virtuali apparentemente separate fanno riferimento a pagine fisiche condivise. Lo stato intermedio dovrebbe rimanere visibile durante le successive attività di diagnosi e revisione.
Per questo motivo, sommare l’RSS per processo può sovrastimare l’uso fisico totale: una pagina condivisa appare residente in ciascun processo. Il proportional set size distribuisce le pagine condivise tra le mappature ed è generalmente più utile per stimare l’impronta complessiva dei worker del modello.
Lo stato privato e le pagine modificate continuano a moltiplicarsi
Le cache KV, le attivazioni, le aree dell’allocator, i buffer del tokenizer e lo stato delle richieste vengono creati per ogni worker o sessione. La scrittura tramite una mappatura privata attiva il copy-on-write, creando una pagina anonima che non può più condividere la copia pulita supportata dal file. Anche versioni differenti del file impediscono il riutilizzo.
Il manuale Linux di smaps classifica le mappature private, condivise, pulite e modificate, oltre a fornire le informazioni smaps per ciascuna mappatura. Queste categorie spiegano perché due worker che condividono i pesi possano comunque mostrare un incremento considerevole della memoria all’aumentare della concorrenza e della lunghezza del contesto.
Il punto fondamentale è che il mapping riduce la duplicazione dei pesi puliti, non la memoria totale dell’inferenza. I file di modello montati in rete possono inoltre produrre una latenza dei page fault instabile, mentre i loader che comprimono o trasformano i dati possono allocare una seconda rappresentazione decompressa, annullando la condivisione prevista.
Confronta un worker con due worker mappati
Parti da una cache fredda, avvia un worker del modello, esegui un prompt fisso e registra il tempo di avvio, i page fault, l’RSS, il PSS e la memoria privata modificata. Avvia un secondo worker identico e ripeti la procedura senza modificare il file del modello o i flag del loader.
Metti in relazione il risultato con i compromessi della compressione descritti nei compromessi della compressione: i file più piccoli favoriscono lo storage, mentre i vantaggi del mapping dipendono dalla rappresentazione effettivamente utilizzata in memoria. Esamina ogni mappatura del modello in smaps invece di affidarti al totale di un singolo processo.
Il test è superato se il secondo worker aggiunge una quantità di memoria dedicata ai pesi molto inferiore rispetto al primo, producendo allo stesso tempo lo stesso output e una latenza a freddo accettabile. Se il PSS quasi raddoppia, verifica l’identità del file, le mappature scrivibili, la decompressione e le copie nascoste prima di concludere che mmap sia inefficace.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Quali fattori determinano l’accuratezza delle citazioni RAG in una knowledge base domestica?
Scopri perché una fonte pertinente può comunque essere una citazione errata, quali fasi della pipeline determinano supporto e copertura e come verificare le affermazioni...
Quali funzionalità consentono di ottenere un output JSON affidabile da un LLM locale?
Scopri quali funzionalità impongono la sintassi JSON, quali proteggono la correttezza semantica e come testare un modello locale con diversi schemi, prompt e casi...
Provenienza dei dati dell’IA locale: perché ogni risposta necessita di un percorso delle fonti tracciabile
Scopri come i percorsi delle fonti rendono verificabili le risposte dell’IA locale, perché le sole citazioni sono incomplete e come testare la provenienza attraverso...
