Hur påverkar NUMA-lokalitet AI-inferens med flera GPU:er i hemmet?

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

NUMA-lokalitet påverkar inferens när CPU-trådar, värdminne och GPU:er kommunicerar över icke-lokala domäner i stället för att hålla sig nära sin PCIe-sökväg.

En AI-server för hemmet med två socklar kan exponera två stora RAM-pooler och flera GPU:er som en enda maskin, men åtkomsten är inte enhetlig. En arbetstråd som schemaläggs på den ena sockeln kan förbereda tensorer i minne som är anslutet till den andra innan de överförs till en GPU under en annan PCIe-rot. Effekten beror på modellplacering, mellanlagring i värdminnet, trafik för tensorparallellism, interconnect-topologi, batchstorlek och om arbetsbelastningen är beräknings- eller överföringsbegränsad.

NUMA omvandlar en enda minnespool till avståndsberoende åtkomst

I ett NUMA-system har varje CPU-sockel eller beräkningsdomän minne som ligger närmare vissa kärnor än andra. Programvara kan adressera den sammanlagda kapaciteten, men en fjärråtkomst måste gå över en interconnect. Den sökvägen har vanligtvis en annan fördröjning och tillgänglig bandbredd än lokalt minne.

NUMA-topologi påverkar även GPU-DMA eftersom värdsidor kan ligga långt från GPU:ns PCIe-rotkomplex. CPU-schemaläggning och minnesplacering är separata beslut, och en virtuell maskin ser inte automatiskt den värdtopologi som krävs för att anpassa dem.

Effekten är liten när värdminnestrafiken är obetydlig jämfört med GPU-beräkningarna. Den ökar under modellinläsning, CPU-avlastning, tokenisering, kopiering till pinnade buffertar, frekvent synkronisering eller arbetsbelastningar som överskrider VRAM-kapaciteten. NUMA-kapacitet garanterar inte NUMA-lokalitet.

GPU-placering lägger till en andra topologi i modellens sökväg

Flera GPU:er kan vara anslutna till olika CPU-socklar, PCIe-switchar eller partitioner på samma kapsling. En tensor som flyttas mellan två acceleratorer kan använda en direkt peer-sökväg, en särskild GPU-länk, en PCIe-switch eller en rutt som innefattar värdminne och ett hopp mellan socklar. Dessa sökvägar är inte likvärdiga.

Forskning om GPU:er med flera partitioner visar att icke-enhetlig åtkomst och kommunikation mellan partitioner kan förstärka konkurrens om resurser och fördröjningen hos kärnor. Strategierna för placering skiljer sig åt beroende på om data delas globalt, delvis eller endast inom en arbetsgrupp eller partition.

Modellpartitioneringen bör följa den topologi som transporterar den mest återkommande trafiken. Intilliggande lager eller attention-tillstånd som placeras över en långsam gräns kan kommunicera vid varje token, medan en mindre kommunikationsintensiv uppdelning kan tåla avståndet. Att räkna GPU:er utan att kartlägga deras länkar döljer den relevanta relationen.

Tensorparallellism kan göra lokalitet till en kostnad per token

Inferens med tensorparallellism delar upp operationer inom ett lager över flera GPU:er och kombinerar delresultaten genom kollektiva operationer. Det kan göra det möjligt att köra större modeller och utnyttja mer beräkningskraft, men kommunikationen upprepas över många lager och token. En fjärrsökväg blir därför en återkommande kostnad i stället för en engångskostnad vid modellinläsning.

Tensorparallellism fungerar bäst när acceleratorlänkarna och shard-placeringen stöder den synkronisering som krävs. Att lägga till en GPU över en svagare NUMA- eller PCIe-gräns kan öka kapaciteten, men ge en mindre genomströmningsökning än vad antalet enheter antyder.

Dataparallellism eller placering på begärandenivå kan vara bättre när modellerna får plats separat och begäranden kan hållas lokala. Tensorparallellism blir nödvändig när en modell inte får plats på en enda enhet, men batchstorleken, frekvensen för kollektiva operationer och interconnect avgör om den ökade kapaciteten även förbättrar hastigheten.

Första åtkomst och trådmigrering kan bryta en avsedd layout

Operativsystem placerar ofta minne nära den tråd som först läser från eller skriver till varje sida. Om initieringen körs på den ena sockeln och inferensarbetarna senare körs på den andra, kan sidorna förbli fjärranslutna. Schemaläggarmigrering kan också flytta CPU-trådar för förberedelser bort från det minne och den GPU som de var avsedda att betjäna.

NUMA-medvetenhet kopplar lokala minnesbanker till de CPU-socklar som använder dem mest effektivt. Att binda CPU-trådar utan att styra minnesallokeringen, eller att binda minne utan att anpassa GPU:n, löser bara en del av sökvägen.

En stabil layout kan kräva CPU-affinitet, minnespolicy, enhetstilldelning och en topologimedveten processstart. Containrar och virtuella maskiner lägger till ytterligare ett mappningslager. Målet är inte att binda allt blint, utan att hålla producent-, buffert- och konsumentsökvägar med hög trafik inom den närmaste praktiskt möjliga domänen.

Lokalitet är viktigast under vissa inferensfaser

Modellinläsning betonar förflyttning från lagring till värd och från värd till GPU. Prefill bearbetar många prompttoken och kan använda större matrismultiplikationer, medan decode upprepade gånger avancerar en eller några få token och kan bli känslig för minnesbandbredd, synkronisering och omkostnaden för att starta kärnor. NUMA-effekterna kan därför förändras under en och samma begäran.

NUMA-effekter i GPU:er visar att placeringsmedveten schemaläggning kan förbättra attention genom att anpassa arbetet till minnesdomäner och återanvändning av cache. Lärdomen är mer avgränsad än en universell hastighetsökning: vinsten uppstår där kärnans delningsmönster stämmer överens med den topologimedvetna mappningen.

Ett riktmärke som endast rapporterar genomsnittligt antal token per sekund kan dölja långsam tid till första token eller dålig skalning vid en viss batchstorlek. Registrera separat inläsningstid, prefill-genomströmning, fördröjning mellan token, trafik på GPU-länkar, fjärråtkomster till NUMA-minne och CPU:ns minnesbandbredd.

Teknik- och AI-hubb

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.