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

Wat is embedding-drift en wanneer moet een private zoekindex opnieuw worden opgebouwd?
Ontcijfer model-, preprocessing-, corpus- en queryverschuivingen; maak onderscheid tussen monitoring en incompatibiliteit; en bepaal wanneer een private index opnieuw moet worden opgebouwd.

Wat is compatibiliteit van tokenizers en waarom kan het wisselen van modellen daardoor misgaan?
Decodeer woordenschatidentiteit, semantiek van speciale tokens, chattemplates, tokens in de cache, adapters en compatibiliteitscontroles voor het lokaal wisselen van modellen.

Wat is modelresidentie en wanneer moet een lokale AI-service gewichten geladen houden?
Ontcijfer gewichtsresidentie, cacheniveaus, koude starts, uitzetting, multiplexing, geheugendruk en wanneer een thuis-AI-service warm moet blijven.

