Hoe beïnvloedt NUMA-localiteit AI-inferentie met meerdere GPU's thuis?

NUMA-localiteit beïnvloedt inferentie wanneer CPU-threads, hostgeheugen en GPU’s communiceren via niet-lokale domeinen in plaats van dicht bij hun PCIe-pad te blijven.

Een AI-thuisserver met twee sockets kan twee grote RAM-pools en meerdere GPU’s als één machine beschikbaar maken, maar de toegang is niet uniform. Een worker die op de ene socket wordt ingepland, kan tensors voorbereiden in geheugen dat aan de andere socket is gekoppeld, voordat deze naar een GPU onder een andere PCIe-root worden overgedragen. De impact hangt af van modelplaatsing, staging in het hostgeheugen, tensorparallel verkeer, de topologie van de interconnects, batching en de vraag of de workload wordt begrensd door berekeningen of overdrachten.

NUMA verandert één geheugenpool in toegang die afhankelijk is van afstand

In een NUMA-systeem heeft elke CPU-socket of elk rekendomein geheugen dat dichter bij sommige cores ligt dan bij andere. Software kan de gecombineerde capaciteit adresseren, maar toegang op afstand moet via een interconnect verlopen. Dat pad heeft doorgaans een andere latentie en beschikbare bandbreedte dan lokaal geheugen.

NUMA-topologie beïnvloedt ook GPU-DMA, omdat hostpagina’s zich ver van het PCIe-rootcomplex van de GPU kunnen bevinden. CPU-planning en geheugenplaatsing zijn afzonderlijke beslissingen, en een virtuele machine ziet mogelijk niet automatisch de hosttopologie die nodig is om deze op elkaar af te stemmen.

Het effect is klein wanneer het verkeer naar het hostgeheugen gering is vergeleken met de GPU-berekeningen. Het neemt toe tijdens het laden van modellen, CPU-offload, tokenisatie, kopieën naar gepinde buffers, frequente synchronisatie of workloads die buiten het VRAM-geheugen vallen. NUMA-capaciteit garandeert geen NUMA-localiteit.

GPU-plaatsing voegt een tweede topologie toe aan het modelpad

Meerdere GPU’s kunnen zijn aangesloten op verschillende CPU-sockets, PCIe-switches of partities op de chip. Een tensor die tussen twee accelerators wordt verplaatst, kan gebruikmaken van een directe peerverbinding, een speciale GPU-link, een PCIe-switch of een route via het hostgeheugen en een sprong tussen sockets. Deze paden zijn niet gelijkwaardig.

Onderzoek naar GPU’s met meerdere partities laat zien dat niet-uniforme toegang en communicatie tussen partities contention en kernel-latentie kunnen versterken. Plaatsingsstrategieën verschillen voor data die globaal, gedeeltelijk of uitsluitend binnen één werkgroep of partitie wordt gedeeld.

Modelpartitionering moet de topologie volgen waarover het meeste herhaalde verkeer loopt. Aangrenzende lagen of attentionstatus die over een trage grens worden verdeeld, kunnen bij elk token communiceren, terwijl een minder communicatieve verdeling afstand mogelijk beter verdraagt. Alleen GPU’s tellen zonder hun verbindingen in kaart te brengen verbergt de relevante relatie.

First-touch en threadmigratie kunnen een beoogde indeling verstoren

Besturingssystemen plaatsen geheugen vaak dicht bij de thread die elke pagina voor het eerst aanraakt. Als de initialisatie op de ene socket draait en inferentieworkers later op een andere worden uitgevoerd, kunnen de pagina’s op afstand blijven. Migratie door de scheduler kan CPU-voorbereidingsthreads ook weghalen bij het geheugen en de GPU die ze bedoeld waren te bedienen.

NUMA-bewustzijn verbindt lokale geheugenbanken met de CPU-sockets die er het efficiëntst toegang toe hebben. CPU-threads vastzetten zonder de geheugentoewijzing te regelen, of geheugen vastzetten zonder de GPU daarop af te stemmen, lost slechts een deel van het pad op.

Een stabiele indeling kan CPU-affiniteit, geheugenbeleid, apparaattoewijzing en een topologiebewuste processtart vereisen. Containers en virtuele machines voegen nog een extra toewijzingslaag toe. Het doel is niet om alles blind vast te zetten, maar om paden met veel verkeer tussen producent, buffer en consument binnen het dichtstbijzijnde praktische domein te houden.

Localiteit is vooral belangrijk tijdens specifieke inferentiefasen

Het laden van modellen legt de nadruk op verplaatsingen van opslag naar host en van host naar GPU. Prefill verwerkt veel prompttokens en kan grotere matrixbewerkingen gebruiken, terwijl decode herhaaldelijk één of enkele tokens verwerkt en gevoelig kan worden voor geheugenbandbreedte, synchronisatie en overhead voor het starten van kernels. NUMA-effecten kunnen daardoor binnen één verzoek veranderen.

NUMA-effecten in GPU’s laten zien dat plaatsingsbewuste planning attention kan verbeteren door werk af te stemmen op geheugendomeinen en hergebruik van caches. De les is beperkter dan een universele snelheidsverbetering: de winst ontstaat waar het deelpatroon van de kernel overeenkomt met de topologiebewuste mapping.

Een benchmark die alleen het gemiddelde aantal tokens per seconde rapporteert, kan een hoge latentie tot het eerste token of slechte schaalbaarheid bij een specifieke batch verbergen. Registreer laadtijd, prefill-doorvoer, latentie tussen tokens, GPU-linkverkeer, NUMA-toegang op afstand en CPU-geheugenbandbreedte afzonderlijk.