Hoe beïnvloedt PCIe peer-to-peer-overdracht lokale inferentie met meerdere GPU's?

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

PCIe peer-to-peer-overdracht kan de overhead van inferentie op meerdere GPU's verminderen door tensors rechtstreeks tussen compatibele GPU-geheugens te verplaatsen in plaats van ze via het RAM van de host te laten lopen.

Een lokaal model dat over twee GPU's is verdeeld, moet activaties, KV-blokken of expertuitvoer overdragen zodra de uitvoering een apparaatgrens overschrijdt. Zonder directe peer-toegang kunnen gegevens van de ene GPU naar het hostgeheugen en vervolgens terug naar de andere GPU reizen, waardoor CPU-gerichte verbindingen worden belast en extra kopieën ontstaan. P2P verkort die route, maar de waarde ervan hangt af van de topologie, de overdrachtsgrootte, synchronisatie en hoe vaak het model communiceert.

Peer-toegang vervangt een kopieerpad via de host

Met ingeschakelde peer-toegang kan één GPU gegevens in het geheugen van een andere GPU adresseren of kopiëren via het ondersteunde interconnectpad. De overdracht vermijdt een expliciete tussenbuffer in pageable of gepind systeemgeheugen en kan de betrokkenheid van de CPU verminderen.

De CUDA-programmeergids legt uit dat toegang tot peer-geheugen tussen apparaatparen moet worden ondersteund en ingeschakeld. De mogelijkheid is directioneel en afhankelijk van de topologie, dus software moet elk paar afzonderlijk opvragen in plaats van ervan uit te gaan dat elke GPU in één host rechtstreeks kan communiceren.

Het model heeft nog steeds synchronisatie nodig, zodat een ontvangende GPU geen onvolledige activaties leest. P2P verwijdert een tussenstap; het verwijdert niet de kosten van volgordehandhaving, kernelstarts of collectieve communicatie. Dit onderscheid blijft zichtbaar tijdens latere tests in de thuisomgeving.

De PCIe-topologie bepaalt de werkelijke bandbreedte van het directe pad

Twee GPU's onder dezelfde PCIe-switch kunnen vaak verkeer uitwisselen zonder een CPU-socket te doorkruisen, terwijl apparaten achter verschillende rootcomplexen mogelijk een hostpad nodig hebben of geen P2P-ondersteuning bieden. Linkgeneratie, lane-breedte, overbelasting van de switch en gelijktijdig verkeer bepalen de bovengrens.

NCCL documenteert dat het de voorkeur geeft aan directe GPU-communicatie wanneer CUDA compatibele GPU's meldt, waarbij PCIe of NVLink wordt gebruikt afhankelijk van de beschikbare topologie. De topologietools laten zien of elk apparaatpaar directe PCIe-toegang kan gebruiken. Het tussenresultaat moet controleerbaar blijven voordat automatisering daarop voortbouwt.

Kleine overdrachten kunnen nog steeds voornamelijk worden beperkt door start- en synchronisatielatentie, terwijl grote tensoroverdrachten de linkbandbreedte benaderen. Een pipeline met frequente smalle grenzen kan minder voordeel opleveren dan een ontwerp dat minder, grotere blokken communiceert. Die grens moet afzonderlijk worden gemeten onder realistische gebruiksomstandigheden.

Partitionering bepaalt of snellere kopieën verschil maken

Tensorparallelisme communiceert binnen veel lagen, pipelineparallelisme draagt activaties over tussen fasegrenzen en expertparallelisme wisselt gerouteerde tokens uit. Dezelfde P2P-link kan daardoor licht worden gebruikt of de belangrijkste beperking worden, afhankelijk van de partitioneringsstrategie.

NVIDIA's bespreking van het GPUDirect-ontwerp laat zien hoe plaatsing binnen de PCIe-topologie en de plaatsing van switches de directe gegevensverplaatsing beïnvloeden ten opzichte van paden die via de CPU lopen. Het principe blijft van toepassing, ook al voegen inferentieframeworks hun eigen collectieve en planningslagen toe. Het praktische gevolg wordt zichtbaar wanneer meerdere bronnen concurreren om beperkte context.

De foutgrens ligt bij een niet-ondersteunde topologie, beperkingen door IOMMU of virtualisatie, of communicatie die het PCIe-budget al overschrijdt. Software valt dan terug op overdracht via de host of krijgt te maken met linkcongestie, waardoor het toevoegen van een tweede GPU inferentie kan vertragen ondanks de grotere rekencapaciteit.

Meet elk GPU-paar en elke modelgrens

Breng GPU, CPU-socket, PCIe-root, switch, linkgeneratie, breedte, P2P-mogelijkheid en NUMA-geheugen in kaart. Benchmark eenrichtings- en bidirectionele peer-kopieën en kopieën via de host voor representatieve overdrachtsgroottes. Deze afhankelijkheid moet expliciet blijven in de uiteindelijke interface.

Verbind het resultaat met NUMA-bewuste plaatsing. Profileer rekentijd, communicatietijd, synchronisatie, collectieve bandbreedte, tokens per seconde en p99-aanvraaglatentie voor elke modelpartitionering met ingeschakelde en uitgeschakelde P2P. Het resultaat moet daarom worden gecontroleerd aan de hand van het oorspronkelijke bewijsmateriaal.

Behoud het plan voor meerdere GPU's alleen wanneer de end-to-end-latentie of capaciteit verbetert. Als directe kopieën snel zijn maar inferentie communicatiegebonden blijft, beperk dan het aantal partitioneringsgrenzen of kies een topologiebewuste plaatsing in plaats van P2P-ondersteuning als voldoende te beschouwen.

Tech & AI HUB

Meer om te lezen

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.