Quel est l’impact des transferts PCIe pair à pair sur l’inférence locale multi-GPU ?

Le transfert pair à pair via PCIe peut réduire la surcharge d'inférence multi-GPU en déplaçant directement les tenseurs entre les mémoires de GPU compatibles au lieu de les faire transiter par la RAM de l'hôte.

Un modèle local réparti sur deux GPU doit transférer des activations, des blocs KV ou des sorties d'experts chaque fois que l'exécution franchit la limite entre les appareils. Sans accès direct entre pairs, les données peuvent passer d'un GPU à la mémoire de l'hôte, puis revenir vers l'autre, ce qui sollicite les liaisons avec le processeur et ajoute des copies. Le P2P raccourcit ce chemin, mais sa valeur dépend de la topologie, de la taille des transferts, de la synchronisation et de la fréquence des communications du modèle.

L'accès entre pairs remplace un chemin de copie passant par l'hôte

Lorsque l'accès entre pairs est activé, un GPU peut adresser ou copier des données dans la mémoire d'un autre GPU via la liaison d'interconnexion prise en charge. Le transfert évite un tampon intermédiaire explicite dans la mémoire système paginable ou épinglée et peut réduire l'intervention du processeur.

Le guide de programmation CUDA explique que l'accès à la mémoire d'un pair doit être pris en charge et activé entre chaque paire d'appareils. La capacité est directionnelle et dépend de la topologie ; les logiciels doivent donc interroger chaque paire plutôt que supposer que tous les GPU d'un même hôte peuvent communiquer directement.

Le modèle a toujours besoin d'une synchronisation afin qu'un GPU consommateur ne lise pas des activations incomplètes. Le P2P supprime une étape de mise en tampon ; il ne supprime ni l'ordonnancement, ni le lancement des noyaux, ni les coûts de communication collective. Cette distinction reste visible lors des tests ultérieurs en environnement domestique.

La topologie PCIe détermine la bande passante réelle du chemin direct

Deux GPU situés sous le même commutateur PCIe peuvent souvent échanger du trafic sans traverser un socket de processeur, tandis que des appareils placés derrière des complexes racine différents peuvent nécessiter un chemin passant par l'hôte ou perdre la prise en charge du P2P. La génération de la liaison, sa largeur, la sursouscription du commutateur et le trafic simultané fixent la limite supérieure.

NCCL indique qu'il privilégie la communication directe entre GPU lorsque CUDA signale des GPU compatibles, en utilisant PCIe ou NVLink selon la topologie disponible. Ses outils de topologie indiquent si chaque paire d'appareils peut utiliser un accès PCIe direct. Le résultat intermédiaire doit rester vérifiable avant toute automatisation.

Les petits transferts peuvent rester dominés par la latence de lancement et de synchronisation, tandis que les transferts de grands tenseurs approchent la bande passante de la liaison. Un pipeline comportant de nombreuses frontières étroites peut donc gagner moins qu'une conception qui communique moins de blocs, mais plus volumineux. Cette frontière doit être mesurée séparément dans des conditions d'exploitation réalistes.

Le partitionnement détermine l'importance de copies plus rapides

Le parallélisme tensoriel communique au sein de nombreuses couches, le parallélisme par pipeline transfère les activations entre les frontières d'étapes et le parallélisme des experts échange les jetons acheminés. La même liaison P2P peut donc être peu sollicitée ou devenir la principale limite selon la stratégie de partitionnement.

La présentation de NVIDIA sur la conception de GPUDirect montre comment le placement selon la topologie PCIe et le positionnement des commutateurs influencent le déplacement direct des données par rapport aux chemins passant par l'hôte. Ce principe s'applique même si les frameworks d'inférence ajoutent leurs propres couches de communication collective et de planification. La conséquence pratique apparaît lorsque plusieurs sources se disputent un contexte limité.

La limite d'échec correspond à une topologie non prise en charge, à des restrictions liées à l'IOMMU ou à la virtualisation, ou à des communications qui dépassent déjà le budget PCIe. Le logiciel revient alors à une mise en tampon via l'hôte ou subit une contention sur la liaison, et l'ajout d'un deuxième GPU peut ralentir l'inférence malgré une capacité de calcul supérieure.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Mesurez chaque paire de GPU et chaque frontière du modèle

Cartographiez les GPU, le socket du processeur, la racine PCIe, le commutateur, la génération et la largeur de la liaison, la capacité P2P et la mémoire NUMA. Évaluez les copies entre pairs dans un sens et dans les deux sens, ainsi que les copies passant par l'hôte, pour des tailles de transfert représentatives. Cette dépendance doit rester explicite dans l'interface finale.

Reliez le résultat au placement tenant compte de la NUMA. Analysez le temps de calcul, le temps de communication, la synchronisation, la bande passante collective, le nombre de jetons par seconde et la latence p99 des requêtes pour chaque partition du modèle, avec P2P activé puis désactivé. Le résultat doit donc être vérifié par rapport aux éléments de preuve initiaux.

Ne conservez le plan multi-GPU que si la latence de bout en bout ou la capacité s'améliore. Si les copies directes sont rapides mais que l'inférence reste limitée par les communications, réduisez le nombre de franchissements entre partitions ou choisissez un placement tenant compte de la topologie plutôt que de considérer la prise en charge du P2P comme suffisante.