Lokale AI-NUMA-localiteit: waarom geheugenplaatsing de aanvoersnelheid van de accelerator verandert

NUMA-localiteit verandert de aanvoersnelheid van een accelerator, omdat preprocessing en overdrachten op de host sneller verlopen wanneer CPU-threads, geheugenpagina’s en het apparaat een nabijgelegen pad delen.

In een thuiswerkstation met meerdere sockets kan elke CPU-kern al het RAM aanspreken, maar de toegangskosten zijn niet overal gelijk. Een GPU of andere accelerator is meestal via de PCIe-rootcomplex van één socket aangesloten. Als preprocessing op een andere node draait en buffers daar worden toegewezen, kunnen gegevens eerst de socketinterconnect passeren voordat ze het apparaat bereiken, wat extra contention en variabele latentie veroorzaakt.

NUMA maakt de afstand tot het hostgeheugen zichtbaar

Een NUMA-systeem verdeelt CPU’s en geheugen over nodes met verschillende toegangsafstanden. Linux wijst een pagina doorgaans toe aan de node die lokaal is voor de CPU die de pagina voor het eerst aanraakt. De plaatsing van threads tijdens het laden van een model of het voorbereiden van invoer kan daardoor bepalen waar grote buffers fysiek worden opgeslagen.

De documentatie over NUMA-geheugenbeleid van Linux beschrijft beleid voor taken, VMA’s, gedeeld geheugen, binding, voorkeur en interleaving. Ook wordt vermeld dat beleid voornamelijk invloed heeft op pagina’s die worden toegewezen nadat het beleid is ingesteld, waardoor de initialisatievolgorde belangrijk is. Dit onderscheid blijft belangrijk onder realistische omstandigheden in huiselijke omgevingen.

Voor lokale inferentie kan het kritieke pad bestaan uit tokenisatie, het decoderen van afbeeldingen, tensorvoorbereiding, gepinde buffers en overdrachten naar het apparaat. Plaatsing op afstand voegt een knelpunt aan de hostzijde toe, zelfs wanneer de accelerator zelf ongebruikte reken capaciteit meldt. De tussenstatus moet tijdens latere diagnose en beoordeling zichtbaar blijven.

PCIe-topologie koppelt een accelerator aan specifieke CPU-nodes

Het kortste pad van host naar apparaat loopt normaal gesproken via de CPU-socket waarvan het rootcomplex de accelerator beheert. Door de CPU-threads van de worker en het toewijzingsbeleid te binden aan die omgeving, kunnen de bandbreedte en variatie verbeteren, vooral wanneer grote invoeren of frequente overdrachten de verbinding zwaar belasten.

De CUDA NUMA-richtlijnen van NVIDIA bevatten NUMA-aanbevelingen en waarschuwen dat automatische balancering GPU-toepassingen in sommige gevallen kan vertragen. Ze raden aan de topologie te inspecteren en het beleid af te stemmen op de werkelijke node, in plaats van uit te gaan van nodenummers.

Plaatsing is een grafenprobleem, geen regel waarbij node nul het snelst is. De juiste koppeling hangt af van de bedrading van het moederbord, de IOMMU-configuratie, andere apparaten en de vraag of meerdere workers dezelfde geheugenkanalen of PCIe-verbindingen belasten.

Binding kan nadelig zijn wanneer de workload meer dan één node gebruikt

Door geheugen strikt aan één node te binden, kunnen de bandbreedte of capaciteit daarvan opraken terwijl andere nodes ongebruikt blijven. Een pipeline kan een GPU bij de ene socket gebruiken, maar ook een capturekaart, NVMe-apparaat of tweede accelerator bij een andere. Eén plaatsingskeuze kan overdrachten optimaliseren, maar preprocessing of opslag vertragen.

Het GPU-affinityproject van NVIDIA koppelt processen aan CPU-kernen die bij GPU’s horen en merkt op dat de juiste affinity de prestaties kan stabiliseren. De verschillende modi laten zien waarom bereiken voor unieke, aaneengesloten, socket- en NUMA-bereiken geschikt zijn voor verschillende workloads met meerdere processen.

De foutgrens ontstaat wanneer een benchmark voor één apparaat wordt veralgemeend naar de hele server. Bind niet blind op systemen met geïntegreerd geheugen, machines met één node of pipelines die meerdere apparaten omvatten; meet end-to-endlatentie, bandbreedte en contention onder de beoogde gelijktijdigheid.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Benchmark de topologie, niet alleen de accelerator

Breng CPU-nodes, geheugencapaciteit, PCIe-apparaten en de lokalisatie van accelerators in kaart. Voer dezelfde inferentieworkload uit met standaardplaatsing, binding alleen van CPU’s, binding alleen van geheugen en afgestemde binding van CPU’s plus geheugen. Noteer de bandbreedte van host naar apparaat, de plaatsing van pagina’s, tokens per seconde en p95-latentie.

Als modelshards uit netwerkopslag komen, zoals bij netwerkopslag voor modellen, splits dan de leestijd van bestanden op van de plaatsing van pagina’s en de overdracht naar het apparaat. Gebruik voor elke run dezelfde gegevens in het cachegeheugen en herhaal de test vervolgens met het beoogde aantal gelijktijdige workers om contention op de geheugenkanalen zichtbaar te maken.

Pas binding alleen toe als de afgestemde topologie de herhaalbare end-to-endresultaten verbetert zonder een andere service uit te hongeren. Als de winst na het opwarmen verdwijnt of bij gelijktijdigheid omslaat in verlies, laat de plaatsing dan flexibel of isoleer alleen de threads en buffers die kritiek zijn voor overdrachten.