Che cos'è lo sharding dei modelli e perché è importante per i limiti di memoria dell'IA domestica?

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Lo sharding del modello distribuisce lo stato necessario del modello su più dispositivi, consentendo di caricare ed eseguire anche un modello che supera la memoria di un singolo acceleratore.

Per un server AI domestico, la domanda importante non è se un checkpoint sia arrivato come diversi file, ma se i pesi, i livelli, i tensori o altri elementi dello stato usati durante l'esecuzione siano effettivamente distribuiti su dispositivi diversi. Lo sharding può trasformare un requisito di memoria impossibile per una singola GPU in una distribuzione fattibile su più dispositivi, ma gli shard devono comunque scambiarsi dati o trasferire il lavoro tra le varie fasi; perciò la larghezza di banda dell'interconnessione, lo squilibrio tra i dispositivi e il supporto del runtime diventano i limiti successivi.

Lo sharding del runtime distribuisce lo stato del modello tra i dispositivi

Un modello in esecuzione contiene tensori che devono essere disponibili quando vengono eseguiti i relativi livelli. Lo sharding modifica la disposizione, in modo che dispositivi diversi possiedano porzioni diverse invece di replicare l'intero stato ovunque.

Un tensore distribuito può usare il posizionamento di un tensore suddiviso, assegnando le dimensioni distribuite a una griglia di dispositivi invece di archiviarle in modo identico su ogni rank.

Il vantaggio diretto è una minore quantità di memoria occupata su ciascun dispositivo. Il costo a livello di sistema è che nessun dispositivo possiede più tutti i dati necessari per ogni operazione, quindi il coordinamento diventa parte dell'inferenza.

Gli shard del checkpoint non equivalgono a un modello in esecuzione suddiviso

I repository di modelli di grandi dimensioni spesso dividono un checkpoint in molti file, così da poterlo scaricare e caricare in modo incrementale. Questa scelta di impacchettamento, da sola, non determina dove risiedono i tensori dopo che il runtime ha completato il caricamento.

Lo sharding a livello di file e il posizionamento durante l'esecuzione restano separati, perché un caricatore può combinare checkpoint suddivisi con la distribuzione su più dispositivi.

Un utente domestico può quindi vedere decine di shard `.safetensors` sul disco mentre il runtime tenta comunque di collocare il modello completo su una sola GPU. Al contrario, un runtime può ripartizionare un checkpoint in una diversa disposizione su più dispositivi durante il caricamento.

La pianificazione della capacità dovrebbe esaminare la mappa effettiva dei dispositivi e le allocazioni residenti dopo l'avvio, invece di presumere che il numero di file nel repository riveli la topologia dell'inferenza.

Lo sharding introduce comunicazione o passaggi tra le fasi

Quando un dispositivo produce valori necessari a un altro shard, i dati devono attraversare un'interconnessione oppure essere sincronizzati tramite un'operazione collettiva. Il traffico esatto dipende dal fatto che il runtime suddivida i tensori all'interno dei livelli, collochi intervalli diversi di livelli su dispositivi diversi oppure raccolga lo stato suddiviso solo quando necessario.

Le diverse strategie di inferenza su più dispositivi bilanciano in modo diverso i modelli di comunicazione e il posizionamento in memoria.

Per questo due GPU con una quantità complessiva di VRAM sufficiente possono comunque eseguire un modello lentamente. Il trasferimento delle attivazioni o la sincronizzazione dei risultati parziali possono diventare il fattore dominante quando PCIe o un altro collegamento è molto più lento della memoria locale dell'acceleratore.

I dispositivi non omogenei possono trasformare uno shard nel collo di bottiglia

Un server domestico eterogeneo può combinare GPU con dimensioni della memoria, velocità di calcolo, ampiezza dei collegamenti o generazioni diverse. Una suddivisione matematicamente uniforme può comunque lasciare che sia il dispositivo più lento o con meno memoria a determinare il ritmo dell'intera richiesta.

Gli strumenti per il posizionamento dei livelli e l'offload devono quindi rispettare la capacità effettiva dei dispositivi, invece di presumere la presenza di hardware simmetrico. L'esecuzione distribuita del modello esplicita usa una configurazione del parallelismo invece di un'astrazione automatica della memoria aggregata.

Una disposizione pratica può assegnare più livelli a una GPU più grande oppure mantenere i componenti sensibili alla latenza sul percorso più veloce. L'obiettivo non è avere lo stesso numero di shard, ma un percorso critico bilanciato che rientri nella capacità di ogni dispositivo.

Misura la memoria per dispositivo, l'utilizzo, il tempo di trasferimento e gli intervalli di inattività usando lo stesso prompt. Uno shard che attende continuamente o ricorre allo spill indica che sono la topologia, non la VRAM aggregata teorica, a limitare le prestazioni.

Lo sharding del modello è innanzitutto uno strumento per rendere possibile l'uso della memoria

Lo sharding è più utile quando il modello non suddiviso non entra affatto in un singolo dispositivo. Una volta che il modello può essere caricato, l'ottimizzazione si sposta sul costo dell'interconnessione, il batching, il posizionamento della cache KV e la valutazione di un modello più piccolo o quantizzato che potrebbe essere più semplice.

Una specifica strategia di calcolo è l'inferenza con parallelismo dei tensori; lo sharding del modello è il problema più ampio del posizionamento, che chiede quale stato necessario debba risiedere su quale dispositivo.

Non considerare la VRAM aggregata come un'unica memoria trasparente. Lo sharding può far cooperare memorie separate, ma ogni runtime applica comunque regole di posizionamento e costi di comunicazione che determinano l'utilità della distribuzione risultante.

Domande frequenti

Un checkpoint suddiviso equivale a un modello in esecuzione suddiviso?

No. Gli shard del checkpoint dividono i file per l'archiviazione o il caricamento; lo sharding durante l'esecuzione determina su quale dispositivo risiede ciascuna parte dello stato del modello durante l'inferenza.

Lo sharding del modello equivale al parallelismo dei tensori?

No. Il parallelismo dei tensori è un modo per eseguire un modello suddiviso, dividendo le operazioni sui tensori; lo sharding comprende anche strategie di posizionamento per livelli, fasi, parametri o altri elementi.

Due GPU da 12 GB forniscono automaticamente un'unica memoria utilizzabile da 24 GB?

No. Un runtime deve suddividere esplicitamente il modello e la comunicazione, lo stato duplicato, la cache KV e il margine di memoria necessario per ciascun dispositivo riducono la capacità complessiva realmente utilizzabile.

Hub Tecnologico e AI

Altro da leggere

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.