Perché l’avvio a freddo dei modelli di IA domestici dipende dalla disposizione dello storage?

L’avvio a freddo di un modello di IA domestico dipende dalla disposizione dello storage, perché il runtime deve individuare, leggere, decodificare, mappare e trasferire ogni peso necessario prima dell’inferenza.

Due copie dello stesso modello possono avviarsi a velocità diverse quando una è già memorizzata nella cache NVMe locale e salvata in un formato ottimizzato per il caricamento, mentre l’altra si trova su una condivisione di rete, su un filesystem frammentato, in un archivio compresso o in una directory di shard organizzati male. Il percorso a freddo comprende anche i file del tokenizer, la configurazione, l’inizializzazione del runtime, l’allocazione dell’acceleratore e la prima esecuzione. Le sezioni seguenti separano la larghezza di banda grezza dello storage dalla disposizione del checkpoint, così i ritardi di avvio possono essere ricondotti alla fase corretta.

L’avvio a freddo è una catena di fasi di storage e runtime

Un modello non è pronto quando il processo apre semplicemente il primo file. Il runtime deve individuare i metadati del checkpoint, creare la struttura del modello, leggere i byte dei pesi, deserializzare o mappare i tensori, allocare la memoria di destinazione, trasferire i dati e inizializzare i kernel o i grafi di esecuzione.

La ricerca sull’inferenza serverless identifica il caricamento durante l’avvio a freddo come una parte importante del ritardo che precede la disponibilità di un servizio LLM. La fase più lenta varia in base alle dimensioni del modello, al formato, al livello di storage, alla memoria dell’host e al percorso verso l’acceleratore.

Un SSD veloce può ridurre i tempi di lettura senza modificare quelli della deserializzazione, delle copie della CPU, del trasferimento alla GPU o del riscaldamento dei kernel. Misura il tempo a ogni passaggio invece di trattare l’intera pausa come un unico benchmark del disco.

La posizione determina se i pesi arrivano dalla cache, dalla LAN o dal disco

I pesi memorizzati su NVMe locale possono essere letti senza la latenza di rete o la coda di un altro server. Un modello su SMB, NFS, object storage o su un disco esterno lento aggiunge il comportamento del trasferimento e della cache remota prima ancora che inizi il caricamento locale.

Una ricerca recente sui modelli memorizzati nella cache dei nodi mostra che mantenere localmente gli artefatti di grandi dimensioni può rendere gli avvii successivi delle repliche molto meno dipendenti da nuove distribuzioni remote. Su un home server, lo stesso principio distingue un primo download da un avvio locale ripetuto.

Locale non significa sempre caldo. Un riavvio, l’espulsione dalla cache, il rimontaggio del filesystem o una lettura massiva concorrente possono costringere l’avvio successivo a recuperare nuovamente dalla memoria fisica la maggior parte delle pagine del modello.

L’articolo di ZimaSpace sull’espulsione dei modelli tratta il confine correlato della memoria: quando un modello non è più residente, la richiesta successiva deve ricostruire lo stato di esecuzione rapido.

Il formato del checkpoint controlla la deserializzazione e le operazioni di copia

Un checkpoint può essere un unico file contiguo ottimizzato per il caricamento, diversi shard di tensori con un indice, un archivio compresso oppure una serializzazione specifica del framework che ricostruisce oggetti Python e metadati dei tensori.

ServerlessLLM utilizza la lettura sequenziale dei checkpoint per ridurre il sovraccarico dell’avvio a freddo. Una disposizione che supporta letture dirette di grandi dimensioni e una collocazione prevedibile dei tensori spreca meno tempo in operazioni su piccoli metadati e nella ricostruzione intermedia.

Lo sharding può ridurre il picco di RAM dell’host perché viene gestito uno shard alla volta, ma un numero eccessivo di file piccoli aumenta le ricerche nelle directory, le aperture, i seek e l’elaborazione degli indici. La dimensione ottimale degli shard dipende dal parallelismo del loader e dal filesystem sottostante.

La compressione sacrifica capacità di storage in cambio di lavoro aggiuntivo per la CPU durante l’avvio. Può essere utile quando lo storage è molto lento, ma penalizzante quando un SSD veloce deve attendere la decompressione e le copie in memoria.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Il memory mapping cambia il momento in cui le pagine entrano nella RAM

Un loader eager può allocare un grande buffer nell’host e leggere una parte consistente o l’intero checkpoint prima di copiare i tensori altrove. Un loader con memory mapping crea mappature virtuali e consente al sistema operativo di caricare nella RAM le pagine del file tramite page fault quando vengono utilizzate.

La ricerca e i moderni sistemi di caricamento utilizzano il caricamento con memory mapping per evitare di duplicare l’intero artefatto nella memoria anonima. Questo può ridurre il picco di RAM e permettere a processi ripetuti di riutilizzare le pagine tramite la cache del filesystem.

Il memory mapping non elimina la latenza dello storage. Sposta le letture al momento dei page fault, quindi la prima inferenza può comunque subire rallentamenti se le pagine necessarie non sono state caricate o precaricate.

Il prefetch sequenziale può aiutare un modello che utilizza la maggior parte dei pesi in ordine, mentre l’accesso casuale a esperti o componenti multimodali può rendere meno prevedibile il modello dei page fault.

Il caricamento parallelo aiuta solo quando il percorso di storage ha margine disponibile

Più thread del loader o stream di copia verso la GPU possono sovrapporre lettura, decodifica e trasferimento. Possono però anche trasformare una singola lettura ordinata in diversi flussi concorrenti che saturano un SSD lento, un bridge USB, una condivisione di rete o il percorso dei metadati del filesystem.

I risultati tecnici di NVIDIA sullo streaming concorrente dei pesi mostrano che il miglioramento dipende congiuntamente dal design del caricamento e dalla scelta dello storage. Il parallelismo è utile quando sorgente e destinazione possono sostenerlo senza far crescere eccessivamente le code.

Un home server potrebbe inoltre servire contenuti multimediali, scrivere backup, analizzare file o eseguire database sullo stesso pool. Questi carichi modificano la latenza dell’avvio a freddo anche se la directory del modello non cambia.

La cache calda e il riutilizzo dei pesi possono dominare gli avvii ripetuti

Il primo avvio dopo il boot può leggere ogni byte del modello dallo storage, mentre il secondo beneficia della cache delle pagine del filesystem, della memoria GPU mantenuta o di un runtime che conserva i pesi pronti per il riutilizzo.

Tangram accelera l’avvio tramite il riutilizzo dei pesi nella memoria GPU. La lezione più ampia per un home server è che “avvio a freddo” deve specificare quali cache e processi sono stati svuotati prima del test.

Non confrontare un modello subito dopo un’altra esecuzione a caldo con un modello diverso dopo un riavvio. Definisci separatamente gli stati a freddo, con filesystem caldo, con runtime caldo e con acceleratore caldo.

Analizza la disposizione con un test ripetibile in stato freddo

Registra le dimensioni del modello, il numero di file, le dimensioni degli shard, il filesystem, le opzioni di mount, il dispositivo di storage, il percorso di rete, la modalità del loader, la RAM dell’host, la memoria dell’acceleratore e l’I/O concorrente. Poi misura il tempo necessario per l’individuazione dei metadati, la lettura nell’host, la deserializzazione, il trasferimento al dispositivo, l’inizializzazione del runtime e il primo token.

Gli studi di FlowLoader analizzano la cache locale dei modelli perché la posizione del checkpoint e la sovrapposizione delle pipeline possono ridurre l’avvio da secondi o minuti. Il guadagno effettivo dipende dal fatto che il vero collo di bottiglia sia lo storage, le copie o l’inizializzazione.

Ripeti il test dopo aver svuotato la cache del filesystem, dopo una normale esecuzione a caldo e durante un traffico NAS rappresentativo. Il divario risultante mostra se saranno utili una modifica della disposizione, un livello locale più veloce, un numero inferiore di shard, il memory mapping o una policy di mantenimento in memoria.