Hur påverkar PCIe peer-to-peer-överföring lokal inferens med flera GPU:er?

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.

PCIe peer-to-peer-överföring kan minska inferensoverhead för flera GPU:er genom att flytta tensorer direkt mellan kompatibla GPU-minnen i stället för att mellanlagra dem via värddatorns RAM.

En lokal modell som är uppdelad mellan två GPU:er måste överföra aktiveringar, KV-block eller expertutdata när körningen passerar en enhetsgräns. Utan direkt peer-åtkomst kan data färdas från en GPU till värdminnet och sedan tillbaka till den andra, vilket belastar länkarna mot CPU:n och lägger till kopieringar. P2P förkortar den vägen, men nyttan beror på topologi, överföringsstorlek, synkronisering och hur ofta modellen kommunicerar.

Peer-åtkomst ersätter en värdmellanlagrad kopieringsväg

När peer-åtkomst är aktiverad kan en GPU adressera eller kopiera data i en annan GPU:s minne via den stödda sammankopplingsvägen. Överföringen undviker en uttrycklig mellanlagringsbuffert i sidbart eller pinnat systemminne och kan minska CPU:ns medverkan.

CUDA-programmeringsguiden förklarar att peer-minnesåtkomst måste stödjas och aktiveras mellan enhetspar. Funktionen är riktad och topologiberoende, så programvara bör kontrollera varje par i stället för att anta att alla GPU:er i en värd kan kommunicera direkt.

Modellen behöver fortfarande synkronisering så att en konsument-GPU inte läser ofullständiga aktiveringar. P2P tar bort ett mellanlagringssteg, men inte kostnader för ordning, kärnstart eller kollektiv kommunikation. Denna skillnad förblir synlig under senare tester i hemmiljö.

PCIe-topologin avgör den direkta vägens faktiska bandbredd

Två GPU:er under samma PCIe-switch kan ofta utbyta trafik utan att passera ett CPU-socket, medan enheter bakom olika rotkomplex kan behöva en värdväg eller förlora P2P-stöd. Länkens generation, banbredd, switchens överbeläggning och samtidig trafik sätter gränsen.

NCCL dokumenterar att det föredrar direkt GPU-kommunikation när CUDA rapporterar kompatibla GPU:er, med PCIe eller NVLink beroende på tillgänglig topologi. Dess topologiverktyg visar om varje enhetspar kan använda direkt PCIe-åtkomst. Mellanresultatet måste förbli inspekterbart innan automatisering följer efter.

Små överföringar kan fortfarande domineras av start- och synkroniseringslatens, medan stora tensoröverföringar närmar sig länkens bandbredd. En pipeline med frekventa smala gränser kan ge mindre vinst än en konstruktion som kommunicerar färre och större block. Den gränsen bör mätas separat under realistiska driftsförhållanden.

Partitioneringen avgör om snabbare kopieringar spelar någon roll

Tensorparallellism kommunicerar inom många lager, pipelineparallellism överför aktiveringar mellan steggränser och expertparallellism utbyter routade token. Samma P2P-länk kan därför användas sparsamt eller bli den huvudsakliga begränsningen beroende på partitioneringsstrategin.

NVIDIAs diskussion om GPUDirects utformning visar hur placering av PCIe-topologi och switchplacering påverkar direkt dataförflyttning jämfört med värdmellanlagrade vägar. Principen gäller även om inferensramverk lägger till egna lager för kollektiv kommunikation och schemaläggning. Den praktiska konsekvensen blir synlig när flera källor konkurrerar om ett begränsat kontextutrymme.

Felgränsen utgörs av topologi som inte stöds, begränsningar från IOMMU eller virtualisering, eller kommunikation som redan överskrider PCIe-budgeten. Programvaran faller då tillbaka på värdmellanlagring eller drabbas av länkkonkurrens, och att lägga till en andra GPU kan göra inferensen långsammare trots större beräkningskapacitet.

Mät varje GPU-par och modellgräns

Kartlägg GPU, CPU-socket, PCIe-rot, switch, länkens generation, bredd, P2P-kapacitet och NUMA-minne. Benchmarka enkelriktade och dubbelriktade peer-kopieringar samt värdmellanlagrade kopieringar för representativa överföringsstorlekar. Detta beroende bör förbli uttryckligt i det slutliga gränssnittet.

Koppla resultatet till NUMA-medveten placering. Profilera beräkningstid, kommunikationstid, synkronisering, bandbredd för kollektiv kommunikation, token per sekund och p99-fördröjning för varje modellpartition med P2P aktiverat och inaktiverat. Resultatet måste därför kontrolleras mot de ursprungliga beläggen.

Behåll planen för flera GPU:er endast när latensen från början till slut eller kapaciteten förbättras. Om direkta kopieringar är snabba men inferensen fortfarande är kommunikationsbunden, minska antalet partitionsövergångar eller välj en topologimedveten placering i stället för att behandla P2P-stöd som tillräckligt.

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.