Il problema: raddoppiare le risorse senza dimezzare l’attesa
Un’impresa vuole ridurre il tempo di risposta di un modello AI. Il calcolo sembra divisibile: se una macchina impiega dodici millisecondi, due dovrebbero impiegarne sei. Ma i dispositivi devono scambiarsi risultati intermedi, attendersi e ricomporre la risposta. Quel tempo può consumare tutto il vantaggio. La domanda di questo articolo è concreta: quanto lavoro deve esserci perché dividere il modello su due dispositivi renda davvero più rapida la stessa operazione?
Costruiremo prima un piccolo calcolo distribuibile, poi un bilancio dei tempi e infine una soglia di convenienza. Chi non ricostruisce ogni formula può seguire tre domande: che cosa dividiamo, che cosa deve viaggiare e quanto tempo risparmiamo davvero? Tutti i tempi seguenti sono parametri ipotetici di un modello aritmetico eseguito in Python. Non abbiamo usato due GPU, misurato una rete o riprodotto un benchmark; non attribuiamo queste prestazioni a prodotti o installazioni EL-AI.
Dividere un modello non significa duplicarlo
Nel parallelismo sui dati, più copie del modello lavorano su esempi diversi; durante l’addestramento devono anche coordinare gli aggiornamenti. Nel parallelismo del modello, invece, la stessa operazione coinvolge parti distribuite della rete. Qui studiamo quest’ultimo caso a livello di matrici, detto parallelismo tensoriale. Un tensore è un insieme multidimensionale di numeri: una matrice è il caso con due dimensioni. La distinzione conta perché aumentare le richieste elaborate al secondo non equivale a ridurre l’attesa di una singola richiesta.
Prendiamo una rete minima: un vettore riga x, una matrice A che produce quattro valori intermedi, una funzione ReLU che sostituisce i negativi con zero, e una matrice B che produce due uscite. Questa funzione non è un modello linguistico addestrato: serve a vedere dove nasce la comunicazione. Le dimensioni sono x: 1 × 2, A: 2 × 4, B: 4 × 2. I numeri sono senza unità fisica.
Separiamo le prime due colonne di A dalle ultime due e, coerentemente, le prime due righe di B dalle ultime due. Il dispositivo 1 calcola ReLU([1,1]) e ottiene il contributo finale [1,1]. Il dispositivo 2 calcola ReLU([0,4]) e ottiene [−4,8]. Sommare i contributi restituisce [−3,9], esattamente l’uscita originale. La somma deve avvenire da qualche parte: se ogni dispositivo necessita dell’uscita completa per il passo successivo, entrambi devono riceverla. Un’operazione collettiva all-reduce combina i contributi e rende disponibile il risultato a tutti i partecipanti.
Non possiamo spostare liberamente quella somma attraverso una funzione non lineare. Per esempio ReLU(2 − 3) vale zero, mentre ReLU(2) + ReLU(−3) vale due. Perciò la scelta di righe e colonne da dividere cambia i punti in cui è obbligatorio comunicare. L’esempio precedente verifica l’equivalenza algebrica con interi Python; con numeri in virgola mobile, ordine delle somme e precisione possono introdurre differenze numeriche. Una distribuzione corretta va controllata anche per la qualità del risultato, non soltanto per la velocità.
Un bilancio dei tempi con unità esplicite
Ora lasciamo le matrici piccole e modelliamo una fase di lavoro più ampia. Chiamiamo S il tempo non divisibile e C il tempo divisibile su un dispositivo. Con due dispositivi identici, il tempo ideale di questa seconda parte sarebbe C/2. Introduciamo η, un’efficienza locale: con η = 0,8 ogni metà lavora all’80% dell’efficienza ideale assunta. Il tempo diventa C/(2η). η non è una probabilità né l’utilizzo GPU letto su un cruscotto: riassume qui gli effetti delle dimensioni dei calcoli e dell’implementazione, lasciando fuori la comunicazione contata separatamente.
Q è il numero di comunicazioni serializzate della fase; ℓ è il costo fisso di avvio di ciascuna, V i byte trasferiti lungo il percorso critico effettivo di ciascuna e B la banda effettiva in byte al secondo. H è quindi il tempo complessivo di comunicazione. V non coincide necessariamente con i byte logici del tensore: un algoritmo collettivo può inviare più pezzi o più volte. Q e V vanno ricavati dalla configurazione reale. La formula assume comunicazioni uguali, nessuna sovrapposizione con il calcolo, assenza di altri concorrenti e nessuna coda di richieste.
| Parametro ipotetico | Valore |
|---|---|
| S | 0.8 ms |
| C | 12 ms |
| η | 0.8 |
| Q | 4 |
| ℓ | 0.03 ms |
| V | 2 000 000 bytes |
| B | 10 GB/s = 10¹⁰ bytes/s |
Usiamo gigabyte decimali: dieci miliardi di byte al secondo, non gigabit e non gibibyte. Ogni trasferimento costa 2.000.000 / 10.000.000.000 secondi, cioè 0,2 ms, più 0,03 ms di avvio. Quattro trasferimenti costano H = 0,92 ms. La parte parallela richiede 12/(2 × 0,8) = 7,5 ms. Otteniamo T₁ = 12,8 ms e T₂ = 9,22 ms: un’accelerazione T₁/T₂ di circa 1,388, non due. Questi numeri verificano le ipotesi della tabella, non descrivono una scheda esistente.
Derivare il punto di pareggio
Per decidere se conviene dividere, chiediamo T₂ minore di T₁. S compare in entrambi e si cancella. Restano il risparmio del calcolo e il costo H. Portando i termini dalla stessa parte otteniamo la condizione seguente. Leggerla in parole è semplice: la frazione di calcolo che risparmiamo deve valere più della comunicazione che aggiungiamo.
Con η = 0,8, il fattore fra parentesi è 0,375. La soglia vale 0,92/0,375 = 2,45333 ms. Se C è esattamente quel valore, i tempi coincidono; per avere vantaggio deve superarlo. Con C = 1 ms, mantenendo le altre ipotesi, un dispositivo richiede 1,8 ms e due ne richiedono 2,345. Più risorse producono più attesa. Se η è al massimo 0,5, il denominatore non è positivo: la divisione non risparmia nemmeno calcolo, e una comunicazione positiva rende impossibile accelerare in questo modello.
Ridurre la banda effettiva a 1 GB/s, lasciando C a 12 ms, porta H a 8,12 ms e T₂ a 16,42 ms: anche il lavoro più grande diventa lento. A 50 GB/s H scende a 0,28 ms e T₂ a 8,58 ms. Una banda infinita eliminerebbe V/B ma non i quattro costi di avvio. Questo distingue il problema dei messaggi grandi, spesso sensibile alla banda, da quello di molti messaggi piccoli, per cui il costo fisso può dominare. Raggruppare messaggi può aiutare ma può anche ritardare la disponibilità dei dati: non è un miglioramento gratuito.
Attesa, produttività ed efficienza non sono la stessa cosa
L’accelerazione è T₁/T₂; l’efficienza parallela rispetto a due dispositivi è quella quantità divisa per due. Nel caso di base vale circa 0,694. Non significa che il 30,6% dell’energia venga sprecato: stiamo confrontando tempi e numero di risorse, non misurando potenza. Inoltre i due dispositivi restano impegnati insieme per completare la fase. Se il modello entra su una sola scheda e arrivano richieste indipendenti, due copie separate possono aumentare la capacità del servizio; il confronto con il modello diviso richiede carico, code e vincoli di memoria, esclusi da questo calcolo.
Anche S merita attenzione. Non cambia la soglia di pareggio perché è uguale nei due casi, ma riduce il vantaggio relativo. Se S sale a 100 ms, con C = 12 ms e banda 10 GB/s, i tempi diventano 112 e 108,42 ms: circa 1,033 volte più veloce. Ottimizzare una parte già piccola dell’attesa complessiva può avere un effetto quasi invisibile per l’utente. Se la distribuzione introduce ulteriore lavoro seriale, quel nuovo costo va aggiunto a T₂ e la soglia peggiora; non possiamo cancellarlo come se fosse comune.
Sovrapporre non significa far sparire la comunicazione
Un sistema può comunicare alcuni risultati mentre calcola altro. Per capire il massimo vantaggio ipotizzabile, immaginiamo due blocchi completamente sovrapponibili: uno di durata C/(2η), l’altro H. Il tempo combinato non può essere inferiore al maggiore dei due. Otteniamo un limite ideale inferiore S + max[C/(2η),H], che nel caso base vale 8,3 ms invece di 9,22. È un limite ottimistico, non una previsione: un calcolo che dipende da un risultato non ancora ricevuto deve aspettare, e il traffico può competere per memoria o risorse di esecuzione.
Aumentare il batch, cioè elaborare più esempi insieme, può rendere i calcoli locali più efficienti, ma cambia anche i dati da comunicare e l’attesa per formare il gruppo. Non basta moltiplicare C lasciando invariati gli altri parametri se il sistema reale cambia anche V e η. Analogamente, passare da due a quattro dispositivi modifica algoritmo collettivo, topologia, numero di messaggi e dimensioni locali. Il nostro grafico varia C mantenendo il resto fisso per isolare una causa, non per promettere quella curva a ogni carico reale.
Dalla derivazione alla misura verificabile
Il codice allegato non usa librerie distribuite: calcola la rete intera e le due parti con liste di interi, verifica l’uguaglianza e valuta le formule temporali. Il frammento finale stampa l’uscita [−3,9] e i tempi dei sei casi salvati nel JSON. La curva è una griglia deterministica, senza seed casuale. Non abbiamo misurato il tempo di Python per chiamarlo tempo di una GPU: sarebbe un confronto diverso e fuorviante.
Una verifica su hardware dovrebbe fissare modello, precisione numerica, dimensioni degli input, dispositivi, collegamenti, driver e versioni software. Occorre separare avvio e riscaldamento dalle ripetizioni stabili, aspettare il completamento effettivo delle operazioni asincrone e osservare la traccia di calcolo e comunicazione. Media, mediana e percentili rispondono a domande diverse; una latenza media più bassa può nascondere code lunghe. Il piano è descritto per rendere falsificabile l’analisi, ma queste misure non sono state eseguite.
Megatron-LM, versione arXiv 4 del 13 marzo 2020, descrive partizioni coordinate delle matrici e comunicazioni nei blocchi Transformer. I suoi esperimenti di scalabilità variano anche la dimensione del modello. Non misurano quindi lo stesso confronto a lavoro fisso costruito qui; non ne trasferiamo percentuali al nostro esempio.
La documentazione PyTorch descrive all-reduce e gli strumenti di profiling delle comunicazioni. È un riferimento per osservare un’implementazione reale, non una prova che la nostra formula riproduca automaticamente tutti i backend o che le chiamate asincrone eliminino le dipendenze.
La stessa formula può guidare una domanda alla rete
Finora abbiamo chiesto quanto calcolo serva. Possiamo rovesciare la domanda: fissato il lavoro, quale banda effettiva minima renderebbe utile dividerlo? Isoliamo V/B nella disuguaglianza precedente. Per evitare ambiguità dimensionali, in questa derivazione esprimiamo C e ℓ in secondi, V in byte e B in byte al secondo. Il risultato è una soglia sulla banda effettiva della specifica comunicazione, non sul numero pubblicitario di una porta.
D è il tempo che possiamo spendere nel trasferimento dei byte di ciascuna comunicazione dopo aver pagato l’avvio. Con C = 0,012 s e gli altri parametri di base, D vale 0,001095 s. La banda deve quindi superare circa 1,82648 GB/s. Se D è nullo o negativo, nessuna banda finita può bastare: il solo costo fisso degli avvii ha già consumato il margine. Questo spiega perché sostituire un collegamento con uno teoricamente più largo non risolva ogni rallentamento. La misura necessaria è quella del percorso completo, con le stesse dimensioni di messaggio e lo stesso algoritmo.
Possiamo isolare anche η. Quando C supera H, serve η maggiore di C/[2(C − H)]. Con C = 12 ms e H = 0,92 ms, la soglia è circa 0,54152. Se invece C = 1 ms, la soglia sale a 6,25: impossibile sotto la nostra ipotesi di efficienza al massimo unitaria. Nemmeno eliminare ogni inefficienza locale renderebbe vantaggiosa quella configurazione. Le due soglie descrivono lo stesso bilancio da punti di vista diversi e permettono di evitare ottimizzazioni che, anche riuscendo perfettamente, non cambierebbero la decisione.
Risposta alla domanda iniziale
Due dispositivi accelerano la stessa fase solo se il calcolo risparmiato supera i costi aggiunti. Il nostro esempio rende questa frase controllabile: con le ipotesi dichiarate servono più di 2,45333 ms di calcolo divisibile; a 12 ms otteniamo circa 1,388 volte la velocità. La soglia cambia con banda, avvio, efficienza e dipendenze. Dividere può essere necessario per far entrare un modello in memoria anche senza accelerarlo, ma è un obiettivo diverso. Prima di scegliere un’infrastruttura, bisogna quindi distinguere capacità, tempo di risposta e costo, e misurare il percorso che conta per gli utenti.
Bibliografia e riproducibilità
PyTorch — Distributed communication package: all_reduce and profiling collective communication.
from experiment import run
r = run()
print(r['matrix']['full'])
for case in r['cases']:
print(round(case['one_ms'], 6), round(case['two_ms'], 6),
round(case['speedup'], 6))
Codice, dati e istruzioni · JSON. Calcoli didattici eseguiti con Python 3.14.0; figure con Matplotlib 3.11.2. Analisi con assistenza AI, senza dichiarare peer review o revisione umana. Copertina originale ImageGen, illustrativa: non documenta persone, sedi o installazioni EL-AI. Fonti consultate il 4 ottobre 2026.