In che modo il parallelismo delle pipeline distribuisce i livelli del modello tra gli acceleratori IA domestici?
Il parallelismo della pipeline distribuisce un modello tra più acceleratori AI domestici assegnando diversi gruppi di livelli a fasi sequenziali sui dispositivi e trasferendo tra loro le attivazioni.
Questo metodo è utile quando un modello profondo è troppo grande per un singolo acceleratore, ma può essere suddiviso in gruppi di livelli che rientrano nella capacità di più dispositivi. A differenza del parallelismo tensoriale, ogni fase possiede livelli completi anziché frammenti della stessa matrice. Il principale compromesso consiste nel ridurre la quantità di pesi residenti su ciascun dispositivo, a fronte del trasferimento delle attivazioni, dello sbilanciamento tra le fasi e dei tempi di inattività della pipeline.
Il parallelismo della pipeline suddivide un modello profondo in fasi sequenziali di livelli
Un trasformatore ha un ordine naturale: i livelli iniziali elaborano l’input prima che possano essere eseguiti quelli successivi. Il parallelismo della pipeline raggruppa sezioni contigue di questa profondità e assegna ogni sezione a un acceleratore diverso.
Il runtime di pipelining di PyTorch suddivide un modello in partizioni eseguite come fasi sequenziali su dispositivi diversi. Ogni dispositivo memorizza solo i parametri della fase assegnata.
Questo può ridurre la memoria del modello necessaria su ciascun dispositivo, consentendo di eseguire un modello che non entrerebbe in una singola GPU domestica.
Le attivazioni avanzano da una fase alla successiva
Dopo che la GPU 0 ha terminato i propri livelli, invia l’attivazione dello stato nascosto alla GPU 1. Questo dispositivo applica il gruppo di livelli successivo e inoltra un’altra attivazione, finché la fase finale produce i logits o un altro output del modello.
vLLM-Omni descrive il parallelismo della pipeline come la suddivisione dei blocchi del trasformatore in fasi sequenziali tra le GPU. Nel normale percorso di propagazione in avanti, solo le attivazioni ai confini devono attraversare le fasi adiacenti.
A differenza del parallelismo tensoriale, i dispositivi non elaborano insieme una singola matrice all’interno dello stesso livello. Ciascuno gestisce livelli diversi.
Una singola richiesta attraversa comunque le fasi in ordine
Per un token o un microbatch, le fasi successive non possono iniziare finché non ricevono l’attivazione necessaria dalla fase precedente. Semplicemente distribuire quattro gruppi di livelli su quattro GPU non rende una richiesta sequenziale quattro volte più veloce.
La guida di NVIDIA sul parallelismo definisce il PP come la suddivisione verticale dei livelli del modello in base alla profondità. La dipendenza seriale lungo la profondità rimane.
Il vantaggio immediato può quindi essere la capacità anziché la latenza. Il throughput migliora quando il runtime riesce a sovrapporre diverse parti del lavoro tra le fasi.
I microbatch riempiono la pipeline, consentendo a più fasi di lavorare contemporaneamente
Una pipeline diventa efficiente quando l’input viene suddiviso in microbatch o quando più elementi di inferenza possono occupare contemporaneamente fasi diverse. Mentre la fase 2 elabora un microbatch, la fase 1 può iniziare quello successivo.
La guida di Hugging Face sul parallelismo spiega che l’esecuzione della pipeline utilizza microbatch per ridurre i tempi di inattività della pipeline. Lo stesso principio di utilizzo si applica ogni volta che un runtime di inferenza riesce a sovrapporre attività indipendenti.
La generazione interattiva di token per un singolo utente offre meno parallelismo naturale, perché ogni nuovo token dipende dall’output del token precedente. Le richieste raggruppate o il traffico multiutente possono offrire più opportunità per mantenere occupate le fasi.
Tempi di esecuzione non uniformi creano bolle e rendono dominante la fase più lenta
Se una fase contiene più livelli, hardware più lento o operazioni particolarmente onerose, la fase successiva aspetta l’input e quella precedente finisce per aspettare che si liberi spazio. Questi periodi di inattività sono le bolle della pipeline.
Il motore della pipeline di DeepSpeed pone l’accento sulla suddivisione dei livelli del modello in fasi della pipeline. Bilanciare il calcolo tra le fasi è quindi importante quanto bilanciare i byte dei parametri.
In una configurazione domestica con acceleratori diversi, è possibile assegnare intenzionalmente meno livelli a una GPU più lenta, ma la capacità di memoria, le dimensioni delle attivazioni e i trasferimenti supportati tra i dispositivi limitano questa disposizione.
Il parallelismo della pipeline scambia la capacità per i pesi con il trasferimento delle attivazioni e la pianificazione
Il PP è interessante quando il modello è profondo e può essere suddiviso in gruppi di livelli che rientrano nei singoli dispositivi. Comunica le attivazioni ai confini anziché utilizzare le frequenti operazioni collettive interne ai livelli tipiche del parallelismo tensoriale, ma paga il prezzo delle dipendenze seriali e delle bolle.
La guida di ZimaSpace sulla concorrenza AI domestica multiutente è pertinente, perché una maggiore quantità di lavoro simultaneo può contribuire a riempire la pipeline, aumentando al contempo il carico su KV e sulla pianificazione.
Misura la memoria per fase, il tempo di esecuzione di ogni fase, il tempo di trasferimento delle attivazioni, la latenza end-to-end, il throughput e la percentuale di inattività dei dispositivi. Una configurazione che riesce a contenere il modello, ma lascia inattivi metà degli acceleratori, potrebbe richiedere una suddivisione diversa.
La guida di ZimaSpace all’hardware AI locale fornisce il punto di riferimento per la capacità. Il parallelismo della pipeline è un modo per superare il limite di memoria di un singolo dispositivo, ma il suo successo dipende più dal bilanciamento delle fasi che dal solo numero di GPU.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Le telecamere domestiche possono sincronizzare gli eventi senza servizi di sincronizzazione dell’ora nel cloud?
Una spiegazione basata prima di tutto sul meccanismo del tempo della fotocamera senza cloud, dei compromessi legati alle risorse condivise, tre domande frequenti sulla...
Un servizio di IA locale può rilevare i livelli del modello danneggiati prima dell'inferenza?
Una spiegazione della rilevazione della corruzione a livello del modello basata innanzitutto sul meccanismo, dei compromessi legati alle risorse condivise, di tre FAQ sull'amplificazione...
È possibile ripristinare un sistema RAG senza rigenerare ogni embedding?
Una spiegazione di RAG Restore senza re-embedding, incentrata sui meccanismi, dei compromessi legati alle risorse condivise, tre FAQ sull'espansione delle query e un protocollo...
