Wie beeinflusst die PCIe-Peer-to-Peer-Übertragung die lokale Inferenz mit mehreren GPUs?

PCIe-Peer-to-Peer-Übertragungen können den Overhead bei der Inferenz mit mehreren GPUs reduzieren, indem Tensoren direkt zwischen kompatiblen GPU-Speichern verschoben werden, anstatt sie über den Host-RAM zu übertragen.

Ein lokales Modell, das auf zwei GPUs aufgeteilt ist, muss Aktivierungen, KV-Blöcke oder Expertenausgaben übertragen, sobald die Ausführung eine Gerätegrenze überschreitet. Ohne direkten Peer-Zugriff können Daten von einer GPU in den Host-Speicher und anschließend zurück zur anderen GPU übertragen werden. Dadurch werden CPU-seitige Verbindungen belastet und zusätzliche Kopiervorgänge verursacht. P2P verkürzt diesen Pfad, sein Nutzen hängt jedoch von Topologie, Übertragungsgröße, Synchronisierung und der Kommunikationshäufigkeit des Modells ab.

Peer-Zugriff ersetzt einen hostbasierten Kopierpfad

Bei aktiviertem Peer-Zugriff kann eine GPU über den unterstützten Verbindungsweg Daten im Speicher einer anderen GPU adressieren oder kopieren. Die Übertragung vermeidet einen expliziten Zwischenspeicher im auslagerbaren oder gepinnten Systemspeicher und kann die CPU-Beteiligung reduzieren.

Der CUDA Programming Guide erklärt, dass der Zugriff auf den Peer-Speicher zwischen Geräte-Paaren unterstützt und aktiviert sein muss. Die Fähigkeit ist gerichtet und von der Topologie abhängig. Daher sollte die Software jedes Paar abfragen, anstatt anzunehmen, dass jede GPU in einem Host direkt mit jeder anderen kommunizieren kann.

Das Modell benötigt weiterhin eine Synchronisierung, damit eine Consumer-GPU keine unvollständigen Aktivierungen liest. P2P entfernt einen Zwischenschritt, nicht jedoch Kosten für Reihenfolge, Kernel-Starts oder Kollektivkommunikation. Dieser Unterschied bleibt bei späteren Tests im Haushalt sichtbar.

Die PCIe-Topologie bestimmt die tatsächliche Bandbreite des direkten Pfads

Zwei GPUs unterhalb desselben PCIe-Switches können Daten häufig austauschen, ohne einen CPU-Sockel zu durchqueren. Geräte hinter unterschiedlichen Root-Komplexen benötigen dagegen möglicherweise einen Host-Pfad oder verlieren die P2P-Unterstützung. Link-Generation, Lane-Breite, Switch-Überbelegung und gleichzeitiger Datenverkehr bestimmen die Obergrenze.

NCCL dokumentiert, dass es direkte GPU-Kommunikation bevorzugt, wenn CUDA kompatible GPUs meldet, und abhängig von der verfügbaren Topologie PCIe oder NVLink verwendet. Die Topologie-Tools zeigen, ob jedes Geräte-Paar direkten PCIe-Zugriff nutzen kann. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung darauf aufbaut.

Kleine Übertragungen können weiterhin von Start- und Synchronisierungslatenz dominiert werden, während große Tensor-Übertragungen sich der Link-Bandbreite annähern. Eine Pipeline mit häufigen, schmalen Grenzen kann weniger profitieren als ein Design, das weniger, dafür größere Blöcke überträgt. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.

Die Partitionierung bestimmt, ob schnellere Kopiervorgänge relevant sind

Tensor-Parallelismus kommuniziert innerhalb vieler Schichten, Pipeline-Parallelismus überträgt Aktivierungen zwischen Stufengrenzen, und Experten-Parallelismus tauscht weitergeleitete Tokens aus. Daher kann derselbe P2P-Link je nach Partitionierungsstrategie nur gering ausgelastet sein oder zum Hauptlimit werden.

Die Diskussion zum GPUDirect-Design von NVIDIA zeigt, wie sich die Platzierung in der PCIe-Topologie und die Switch-Platzierung auf direkte Datenbewegungen im Vergleich zu hostbasierten Pfaden auswirken. Das Prinzip gilt auch dann, wenn Inferenz-Frameworks eigene Kollektiv- und Scheduling-Schichten hinzufügen. Die praktische Folge zeigt sich, wenn mehrere Quellen um begrenzten Kontext konkurrieren.

Die Fehlergrenze liegt bei nicht unterstützter Topologie, IOMMU- oder Virtualisierungsbeschränkungen oder bei Kommunikation, die das PCIe-Budget bereits überschreitet. Die Software fällt dann auf Host-Staging zurück oder leidet unter Link-Überlastung, und das Hinzufügen einer zweiten GPU kann die Inferenz trotz höherer Rechenkapazität verlangsamen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Jedes GPU-Paar und jede Modellgrenze messen

Erfassen Sie GPU, CPU-Sockel, PCIe-Root, Switch, Link-Generation, Breite, P2P-Fähigkeit und NUMA-Speicher. Benchmarken Sie unidirektionale und bidirektionale Peer-Kopien sowie hostbasierte Kopien mit repräsentativen Übertragungsgrößen. Diese Abhängigkeit sollte in der finalen Schnittstelle ausdrücklich erhalten bleiben.

Verknüpfen Sie das Ergebnis mit NUMA-bewusster Platzierung. Erstellen Sie für jede Modellpartition mit aktiviertem und deaktiviertem P2P ein Profil von Rechenzeit, Kommunikationszeit, Synchronisierung, Kollektivbandbreite, Tokens pro Sekunde und p99-Anfragelatenz. Das Ergebnis muss daher anhand der ursprünglichen Belege überprüft werden.

Behalten Sie den Multi-GPU-Plan nur bei, wenn sich die End-to-End-Latenz oder die Kapazität verbessert. Wenn direkte Kopien zwar schnell sind, die Inferenz jedoch weiterhin kommunikationsgebunden bleibt, reduzieren Sie die Anzahl der Partitionsübergänge oder wählen Sie eine topologiebewusste Platzierung, anstatt P2P-Unterstützung als ausreichend zu betrachten.