In che modo la località NUMA influisce sull’inferenza AI domestica con più GPU?

La località NUMA influisce sull’inferenza quando i thread della CPU, la memoria dell’host e le GPU comunicano attraverso domini non locali invece di rimanere vicini al relativo percorso PCIe.

Un server AI domestico con due socket può esporre due ampi pool di RAM e diverse GPU come un’unica macchina, ma l’accesso non è uniforme. Un worker pianificato su un socket può preparare tensori nella memoria collegata all’altro prima di trasferirli a una GPU sotto un diverso root complex PCIe. L’impatto dipende dal posizionamento del modello, dallo staging sull’host, dal traffico del parallelismo dei tensori, dalla topologia delle interconnessioni, dal batching e dal fatto che il carico sia limitato dal calcolo o dai trasferimenti.

NUMA trasforma un unico pool di memoria in un accesso dipendente dalla distanza

In un sistema NUMA, ogni socket della CPU o dominio di calcolo dispone di memoria più vicina ad alcuni core che ad altri. Il software può indirizzare la capacità combinata, ma un accesso remoto deve attraversare un’interconnessione. Questo percorso presenta solitamente latenza e larghezza di banda disponibile diverse rispetto alla memoria locale.

La topologia NUMA influisce anche sul DMA delle GPU, perché le pagine dell’host possono trovarsi lontano dal root complex PCIe della GPU. La pianificazione della CPU e il posizionamento della memoria sono decisioni separate, e una macchina virtuale potrebbe non rilevare automaticamente la topologia dell’host necessaria per allinearle.

L’effetto è ridotto quando il traffico di memoria dell’host è minimo rispetto al calcolo della GPU. Aumenta durante il caricamento del modello, l’offload sulla CPU, la tokenizzazione, le copie in buffer bloccati, le sincronizzazioni frequenti o i carichi che superano la VRAM. La capacità NUMA non garantisce la località NUMA.

Il posizionamento delle GPU aggiunge una seconda topologia al percorso del modello

Più GPU possono essere collegate a socket CPU, switch PCIe o partizioni sul package differenti. Un tensore che si sposta tra due acceleratori può utilizzare un percorso peer-to-peer diretto, un collegamento GPU dedicato, uno switch PCIe oppure un percorso che coinvolge la memoria dell’host e un passaggio tra socket. Questi percorsi non sono equivalenti.

La ricerca sulle GPU multipartitsione rileva che l’accesso non uniforme e la comunicazione tra partizioni possono amplificare la contesa e la latenza dei kernel. Le strategie di posizionamento differiscono per i dati condivisi globalmente, parzialmente o solo all’interno di un singolo workgroup o di una singola partizione.

Il partizionamento del modello dovrebbe seguire la topologia che trasporta il traffico più frequente. Posizionare layer adiacenti o lo stato dell’attenzione oltre un confine lento può richiedere comunicazioni a ogni token, mentre una suddivisione con meno comunicazioni può tollerare la distanza. Contare le GPU senza mappare i relativi collegamenti nasconde la relazione più importante.

Il parallelismo dei tensori può rendere la località un costo per ogni token

L’inferenza con parallelismo dei tensori divide le operazioni all’interno di un layer tra più GPU e combina i risultati parziali tramite operazioni collettive. Ciò può consentire di gestire modelli più grandi e utilizzare una maggiore capacità di calcolo, ma la comunicazione si ripete attraverso molti layer e token. Un percorso remoto diventa quindi un costo ricorrente, anziché una penalizzazione una tantum del caricamento del modello.

Il parallelismo dei tensori funziona al meglio quando i collegamenti tra acceleratori e il posizionamento degli shard supportano la sincronizzazione richiesta. Aggiungere una GPU oltre un confine NUMA o PCIe più debole può aumentare la capacità, ma offrire un incremento del throughput inferiore a quello suggerito dal numero di dispositivi.

Il parallelismo dei dati o il posizionamento a livello di richiesta possono essere migliori quando i modelli entrano singolarmente nelle GPU e le richieste possono rimanere locali. Il parallelismo dei tensori diventa necessario quando un modello non può entrare in un singolo dispositivo, ma le dimensioni del batch, la frequenza delle operazioni collettive e l’interconnessione determinano se la capacità aggiuntiva migliora anche la velocità.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Il first-touch e la migrazione dei thread possono compromettere un layout pianificato

I sistemi operativi spesso collocano la memoria vicino al thread che accede per primo a ciascuna pagina. Se l’inizializzazione viene eseguita su un socket e i worker dell’inferenza eseguono successivamente le operazioni sull’altro, le pagine possono rimanere remote. Anche la migrazione gestita dallo scheduler può spostare i thread di preparazione della CPU lontano dalla memoria e dalla GPU che avrebbero dovuto servire.

La consapevolezza NUMA collega i banchi di memoria locali ai socket della CPU che vi accedono in modo più efficiente. Vincolare i thread della CPU senza controllare l’allocazione della memoria, oppure vincolare la memoria senza allineare la GPU, risolve solo una parte del percorso.

Un layout stabile può richiedere affinità della CPU, criteri per la memoria, assegnazione dei dispositivi e avvio dei processi consapevole della topologia. Container e macchine virtuali aggiungono un ulteriore livello di mappatura. L’obiettivo non è vincolare tutto alla cieca, ma mantenere i percorsi ad alto volume tra produttore, buffer e consumatore all’interno del dominio pratico più vicino.

La località è più importante in fasi specifiche dell’inferenza

Il caricamento del modello enfatizza il movimento dallo storage all’host e dall’host alla GPU. Il prefill elabora molti token del prompt e può utilizzare operazioni matriciali più ampie, mentre il decode avanza ripetutamente di uno o pochi token e può diventare sensibile alla larghezza di banda della memoria, alla sincronizzazione e all’overhead di avvio dei kernel. Gli effetti NUMA possono quindi cambiare durante una stessa richiesta.

Gli effetti NUMA della GPU mostrano che una pianificazione consapevole del posizionamento può migliorare l’attenzione allineando il lavoro ai domini di memoria e al riutilizzo della cache. La conclusione è più circoscritta di un miglioramento universale: il vantaggio emerge quando il modello di condivisione del kernel corrisponde alla mappatura consapevole della topologia.

Un benchmark che riporta solo i token medi al secondo può nascondere una latenza elevata del primo token o uno scaling inefficiente con un determinato batch. Registra separatamente il tempo di caricamento, il throughput del prefill, la latenza tra i token, il traffico sui collegamenti delle GPU, gli accessi NUMA remoti e la larghezza di banda della memoria della CPU.