¿Cómo afecta la transferencia entre pares de PCIe a la inferencia local con varias GPU?

La transferencia PCIe entre pares puede reducir la sobrecarga de inferencia en configuraciones multi-GPU al mover tensores directamente entre las memorias de GPU compatibles, en lugar de hacerlos pasar por la RAM del sistema.

Un modelo local dividido entre dos GPU debe transferir activaciones, bloques KV o salidas de expertos cada vez que la ejecución cruza el límite entre dispositivos. Sin acceso directo entre pares, los datos pueden viajar de una GPU a la memoria del sistema y luego regresar a la otra, consumiendo enlaces que conectan con la CPU y añadiendo copias. P2P acorta esa ruta, pero su valor depende de la topología, el tamaño de la transferencia, la sincronización y la frecuencia con la que se comunica el modelo.

El acceso entre pares reemplaza una ruta de copia con paso por el sistema

Con el acceso entre pares habilitado, una GPU puede direccionar o copiar datos en la memoria de otra GPU mediante la ruta de interconexión compatible. La transferencia evita un búfer de rebote explícito en la memoria del sistema, ya sea paginable o fijada, y puede reducir la intervención de la CPU.

La guía de programación de CUDA explica que el acceso a la memoria entre pares debe ser compatible y estar habilitado entre cada par de dispositivos. La compatibilidad es direccional y depende de la topología, por lo que el software debe consultar cada par en lugar de asumir que todas las GPU de un mismo sistema pueden comunicarse directamente.

El modelo aún necesita sincronización para que una GPU consumidora no lea activaciones incompletas. P2P elimina un paso de almacenamiento intermedio; no elimina los costes de ordenamiento, lanzamiento de kernels ni comunicación colectiva. Esta distinción seguirá siendo visible durante las pruebas domésticas posteriores.

La topología PCIe determina el ancho de banda real de la ruta directa

Dos GPU situadas bajo el mismo conmutador PCIe a menudo pueden intercambiar tráfico sin atravesar un socket de CPU, mientras que los dispositivos ubicados detrás de complejos raíz diferentes pueden requerir una ruta a través del sistema o perder la compatibilidad con P2P. La generación del enlace, el ancho del enlace, la sobresuscripción del conmutador y el tráfico simultáneo determinan el límite máximo.

NCCL documenta que prefiere la comunicación directa entre GPU cuando CUDA informa de que las GPU son compatibles, utilizando PCIe o NVLink según la topología disponible. Sus herramientas de topología muestran si cada par de dispositivos puede utilizar el acceso PCIe directo. El resultado intermedio debe seguir siendo inspeccionable antes de automatizar el proceso.

Las transferencias pequeñas pueden seguir estando dominadas por la latencia de lanzamiento y sincronización, mientras que las transferencias grandes se aproximan al ancho de banda del enlace. Una canalización con límites estrechos y frecuentes puede obtener menos beneficios que un diseño que comunique menos bloques, pero más grandes. Ese límite debe medirse por separado en condiciones operativas realistas.

La partición determina si las copias más rápidas importan

El paralelismo de tensores comunica datos dentro de muchas capas, el paralelismo de canalización transfiere activaciones entre los límites de las etapas y el paralelismo de expertos intercambia tokens enrutados. Por tanto, el mismo enlace P2P puede utilizarse poco o convertirse en el principal factor limitante, según la estrategia de partición.

El análisis de diseño GPUDirect de NVIDIA muestra cómo la ubicación de la topología PCIe y de los conmutadores afecta al movimiento directo de datos en comparación con las rutas que pasan por la CPU. El principio se aplica aunque los frameworks de inferencia añadan sus propias capas de comunicación colectiva y planificación. La consecuencia práctica aparece cuando varias fuentes compiten por un contexto limitado.

El límite de fallo se encuentra en una topología no compatible, restricciones del IOMMU o de la virtualización, o una comunicación que ya supera el presupuesto de PCIe. En ese caso, el software vuelve a utilizar el almacenamiento intermedio en el sistema o sufre contención del enlace, y añadir una segunda GPU puede ralentizar la inferencia pese a disponer de mayor capacidad de cálculo.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Mide cada par de GPU y cada límite del modelo

Mapea la GPU, el socket de CPU, la raíz PCIe, el conmutador, la generación del enlace, el ancho, la capacidad P2P y la memoria NUMA. Compara las copias entre pares en una y dos direcciones con las copias que pasan por el sistema, utilizando tamaños de transferencia representativos. Esta dependencia debe seguir siendo explícita en la interfaz final.

Conecta el resultado con la ubicación compatible con NUMA. Perfila el tiempo de cálculo, el tiempo de comunicación, la sincronización, el ancho de banda colectivo, los tokens por segundo y la latencia p99 de las solicitudes para cada partición del modelo, con P2P habilitado y deshabilitado. Por tanto, el resultado debe comprobarse frente a las pruebas originales.

Mantén el plan multi-GPU solo cuando mejore la latencia de extremo a extremo o la capacidad. Si las copias directas son rápidas, pero la inferencia sigue limitada por la comunicación, reduce los cruces entre particiones o elige una ubicación que tenga en cuenta la topología, en lugar de considerar suficiente la compatibilidad con P2P.