Los pasillos y el guardia de seguridad: topología PCIe, GPUDirect P2P y ACS

Mon, 08 Jun 2026 06:00:00 +0200

Sigue la serie por debajo del motor. El post de NVLink y NCCL explicó la mesa compartida por la que las GPUs se pasan datos a 450 GB/s. Pero esa mesa solo conecta GPUs entre sí. Todo lo demás —disco, red, el host— viaja por otro bus, el PCIe, y por sus pasillos. El cold start ya rozó esto con GPUDirect Storage; este post abre el plano completo de los pasillos y el guardia que los vigila.

TL;DR

En un nodo de 4×H100 SXM, las GPUs se hablan por NVLink (450 GB/s por sentido, ~7× el PCIe), y para el all-reduce del tensor parallel ese es el camino. Pero el PCIe no desaparece: es por donde entra todo lo demás. Los pesos suben del NVMe por PCIe (el cold start), los datos de otro nodo llegan por la NIC por PCIe (RDMA), y un KV que se mueve entre nodos viaja por PCIe. GPUDirect es la familia que deja que esos bytes vayan directos del dispositivo a la HBM sin rebotar por la RAM del host: P2P (GPU↔GPU), RDMA (GPU↔NIC) y Storage (GPU↔NVMe). El obstáculo es un guardia llamado ACS (Access Control Services): una feature de seguridad del PCIe que por defecto obliga al tráfico peer-to-peer a subir hasta el root complex para inspección, lo que destruye el camino directo y mete un rodeo por la CPU. El IOMMU (VT-d) hace algo parecido si no está en modo passthrough. Desactivarlos da rendimiento; mantenerlos da aislamiento y virtualización —y esa es una decisión real en un entorno ENS—. Este post explica la topología (nvidia-smi topo -m), GPUDirect, por qué ACS e IOMMU rompen el P2P con números, los 10 knobs y la trampa de quitar el guardia sin saber qué vigilaba. Sobre el cluster genérico 4×H100 SXM.

Dónde estás: los pasillos, no la mesa

Imagina la cocina como un edificio. Las estaciones de cocción de élite —las GPUs— están en una sala con una mesa central enorme (NVLink/NVSwitch) por la que se pasan ingredientes a toda velocidad sin levantarse. Esa mesa es para ellas y solo ellas.

Pero el edificio tiene más cosas: la despensa (el almacenamiento NVMe), la puerta de carga (la red, la NIC) y la recepción (la CPU y su RAM). Para llegar a cualquiera de esas, las estaciones no usan la mesa central: usan los pasillos del edificio —el bus PCIe—. Y aquí aparece el personaje del post: en la entrada de cada pasillo hay un guardia de seguridad (ACS) que, por defecto, no deja que dos estaciones se pasen algo directamente por el pasillo: las obliga a subir el paquete a recepción para que lo revisen, y solo entonces baja a destino. Es seguro, pero es un rodeo absurdo cuando las dos estaciones están una al lado de la otra. GPUDirect es el permiso para saltarse ese rodeo; ACS e IOMMU son las razones por las que, a menudo, no puedes.

La topología de un nodo: dos buses, no uno

El error más común es pensar que en un nodo hay “un bus”. Hay (al menos) dos, y hacen cosas distintas:

NVLink / NVSwitch — la malla de alta velocidad GPU↔GPU. En H100 SXM, 18 enlaces × 50 GB/s = 900 GB/s bidireccionales entre dos GPUs cualesquiera, con NVSwitch dando un all-to-all sin contención (NVLink, NVIDIA). Es la mesa compartida.
PCIe Gen5 — el bus de I/O general. Un enlace x16 da 128 GB/s bidireccionales (~64 por sentido) (H100 product brief). Conecta cada GPU con la CPU, la RAM, las NICs y los NVMe. Es el pasillo.

La diferencia es de 7×: NVLink mueve en un segundo lo que el PCIe tarda siete. Por eso el tensor parallel intra-nodo va por NVLink y nadie lo discute. El PCIe importa para lo otro: subir pesos del disco, recibir de la red, mover KV entre nodos.

La herramienta para verlo es nvidia-smi topo -m, que imprime una matriz de cómo está conectado cada par (foro NVIDIA):

 GPU0 GPU1 GPU2 GPU3 NIC0 CPU Affinity NUMA
GPU0 X NV18 NV18 NV18 PXB 0-47 0
GPU1 NV18 X NV18 NV18 PXB 0-47 0
GPU2 NV18 NV18 X NV18 SYS 48-95 1
GPU3 NV18 NV18 NV18 X SYS 48-95 1

La leyenda es la que importa: NV18 = 18 enlaces NVLink (la mesa); PXB = cruza switches PCIe pero no el host; PHB = pasa por el host bridge; NODE = mismo NUMA, cruzando PCIe; SYS = cruza el interconnect entre sockets (el peor caso, atraviesa NUMA). Que GPU0↔NIC0 sea PXB y GPU2↔NIC0 sea SYS te dice exactamente qué GPU debe atender el tráfico de esa NIC —la 0, sin cruzar NUMA—. Esto enlaza directo con el post de NUMA y el de NUMA de red: la afinidad PCIe es la afinidad NUMA.

GPUDirect: saltarse la recepción

Sin GPUDirect, mover un dato de la NIC (o el NVMe) a la GPU hace un rodeo obligatorio: dispositivo → RAM del host → GPU. Ese rebote por la RAM consume ancho de banda de la CPU, gasta copias y añade latencia. GPUDirect elimina el rebote dejando que el dato vaya directo del dispositivo a la HBM. Tres sabores:

GPUDirect P2P — GPU↔GPU por PCIe (cuando no hay NVLink entre ellas, o para tráfico que no usa la mesa).
GPUDirect RDMA — GPU↔NIC: la tarjeta de red escribe directa en la HBM. Es lo que hace viable el multi-nodo eficiente (NCCL sobre InfiniBand/RoCE).
GPUDirect Storage (GDS) — GPU↔NVMe: el disco escribe directo en la HBM, sin buffer de host. Es la palanca del cold start.

En un nodo SXM, el tráfico GPU↔GPU del tensor parallel no usa P2P por PCIe: usa NVLink. Por eso GPUDirect importa sobre todo en los bordes del nodo: la red (RDMA, para multi-nodo) y el disco (GDS, para arranque). Ahí es donde ACS hace daño.

El guardia: por qué ACS e IOMMU rompen el P2P

ACS (Access Control Services) es una feature de seguridad del PCIe pensada para virtualización y aislamiento: garantiza que un dispositivo no pueda leer/escribir directamente en otro sin que el root complex lo medie. Para conseguirlo, fuerza las transacciones peer-to-peer a subir hasta el root complex y volver a bajar (best practices GDS, NVIDIA). Es exactamente lo contrario de lo que GPUDirect quiere: el camino directo deja de serlo.

El IOMMU (VT-d en Intel, equivalente en AMD) traduce direcciones y aísla dispositivos. Si está activo y no en modo passthrough, también redirige el tráfico P2P por el root complex, con el mismo efecto: rendimiento por los suelos o, en casos extremos, hangs (troubleshooting NCCL).

Resumido sin rodeos (Giraud, debugging P2P): ACS fuerza el paso por el root para comprobaciones de seguridad; IOMMU lo fuerza para aislamiento y virtualización. Ambos rompen el objetivo del P2P (comunicación directa sin intermediarios) y añaden overhead. Si no necesitas esa seguridad/virtualización en ese path, desactivarlos recupera el rendimiento. La receta operativa para máximo rendimiento de GPUDirect: ACS off en los switches del camino e IOMMU en passthrough (iommu=pt) o desactivado.

Las matemáticas que importan: cuánto cuesta el rodeo

Pongamos un SWAP de KV de 5 GB (preemption del scheduler que manda KV a host, o transferencia entre nodos en serving desagregado):

Camino	BW efectivo	Tiempo de 5 GB
NVLink (GPU↔GPU intra-nodo)	~450 GB/s	~11 ms
PCIe Gen5 x16 directo (P2P, ACS off)	~55 GB/s	~91 ms
PCIe vía root complex (ACS on)	~25-30 GB/s*	~170-200 ms

* El rodeo por el root no solo “añade latencia”: satura el ancho de banda del host bridge, contiende con otro tráfico y, según la topología, puede caer bastante por debajo del directo. La cifra es de orden, para mostrar la magnitud del problema, no un benchmark.

La lectura: en el camino que sí usa PCIe (red, disco, swap), tener ACS on puede duplicar o triplicar el tiempo. Y si ese tiempo está en el camino crítico —un cold start, un swap de preemption, un all-reduce inter-nodo— se nota en la latencia que ve el usuario. Lo que no arregla desactivar ACS: el tráfico que ya iba por NVLink (TP intra-nodo). Ahí ACS es irrelevante.

La tensión real: rendimiento vs aislamiento (y ENS)

Aquí el post se pone serio, porque la receta “desactiva ACS e IOMMU” tiene un coste que en un entorno regulado no es gratis. ACS e IOMMU existen por una razón: aislar dispositivos. En un nodo bare-metal dedicado a inferencia, sin virtualización ni multi-tenancy, no aíslas nada que importe y desactivarlos es razonable. Pero:

Si haces passthrough de GPU a VMs o usas contenedores con aislamiento fuerte, el IOMMU es necesario —no es opcional—.
En un escenario multi-tenant donde varias cargas comparten nodo, ACS aporta una garantía de que un dispositivo no fisgonea a otro.
En ENS (ver controles técnicos), el aislamiento de cargas y la trazabilidad de accesos pueden ser requisitos; desactivar el aislamiento del bus para ganar 80 ms es una decisión que hay que justificar y documentar, no un tuneo silencioso.

La salida de diseño, cuando necesitas las dos cosas: mantén el aislamiento donde lo exige el compliance y diseña para que el camino caliente no dependa del P2P por PCIe. Concretamente, en un nodo SXM, el grueso del tráfico crítico (TP) ya va por NVLink y no le afecta ACS. Para la red, dedica una NIC por GPU en su mismo switch PCIe (PXB) y usa GPUDirect RDMA solo en el path que controlas. Para el disco, cachea pesos en NVMe local. Así no pagas la elección entre rendimiento y aislamiento: la evitas en el path que importa.

Los 10 knobs

#	Knob	Qué controla	Coste / riesgo
1	ACS off (switches del path)	rodeo por root del P2P	pierdes aislamiento de bus
2	`iommu=pt` / off	redirección P2P por root	rompe passthrough a VM si off
3	`nvidia-smi topo -m`	auditar la topología real	— (siempre conviene)
4	`p2pBandwidthLatencyTest`	medir P2P de verdad	— (verifica antes de asumir)
5	colocación de NIC	mismo switch PCIe que la GPU	SYS si cruza NUMA
6	colocación de NVMe	NUMA-local a la GPU	H2D cruzando UPI
7	`nvidia-peermem` (GDR)	habilita RDMA a HBM	driver/kernel correctos
8	PCIe gen/lanes (x16)	ancho del pasillo	GPU en x8 silencioso
9	relaxed ordering / ASPM	latencia y energía PCIe	jitter si mal configurado
10	persistence mode	evita reinit del path	GPU ociosa pagada

Cómo se conecta con el resto del stack

Con NVLink y NCCL. El post de NVLink cubre la mesa GPU↔GPU; este cubre el otro bus, el que conecta con disco, red y host. Son complementarios: ACS afecta al PCIe, no al NVLink.

Con el cold start. GPUDirect Storage del post disco→HBM es GPUDirect sobre el path de almacenamiento; ACS on lo estrangula igual que estrangula el P2P.

Con NUMA. La afinidad PCIe de topo -m es la afinidad NUMA del post del host; colocar NIC y NVMe en el NUMA correcto evita el camino SYS.

Con la red. La colocación de NIC y GPUDirect RDMA es el tema del post de NUMA de red; el mismo principio de “saca a la CPU del medio”.

Con PagedAttention y el scheduler. El SWAP de preemption (scheduler) mueve bloques de KV por PCIe; por eso V1 prefiere RECOMPUTE y por eso este bus importa.

Con el disaggregated serving. Transferir KV entre pools en serving desagregado viaja por PCIe→NIC→PCIe; ACS y la colocación deciden si es viable.

Con ENS. El aislamiento del bus es un control técnico; ver controles ENS/42001/AI Act.

Trampas y cosas que no son lo que parecen

“Desactiva ACS en todas partes, va más rápido.” En un nodo dedicado, vale. En uno con virtualización, multi-tenancy o requisitos de aislamiento (ENS), estás quitando un control de seguridad. La decisión correcta es por path y documentada, no global y silenciosa.

“NVLink y PCIe son el mismo bus, más o menos.” No. Son dos buses con 7× de diferencia y propósitos distintos. El TP va por NVLink; el disco, la red y el host van por PCIe. Confundirlos lleva a “optimizar” ACS para un tráfico que ni siquiera pasa por PCIe.

“El P2P funciona solo, no hay que comprobar nada.” El P2P se desactiva en silencio con ACS/IOMMU activos, y muchas distros los activan por defecto. Comprueba con p2pBandwidthLatencyTest y nvidia-smi topo -m; no asumas que tienes el camino directo solo porque las GPUs están en el mismo nodo.

“IOMMU off siempre, por rendimiento.” Si haces passthrough de GPU a máquinas virtuales, el IOMMU es obligatorio; desactivarlo rompe el passthrough. El modo correcto suele ser passthrough (iommu=pt): mantiene el mapeo necesario sin penalizar el P2P.

“Más lanes PCIe = GPU más rápida.” El PCIe es el camino de I/O, no de cómputo. Una GPU en x8 en vez de x16 tarda más en cargar y en comunicar por PCIe, pero genera tokens a la misma velocidad una vez los pesos están dentro. El daño de x8 está en el cold start y en el multi-nodo, no en el throughput de decode.

“GPUDirect arregla cualquier cuello de I/O.” GPUDirect quita el rebote por la CPU; si tu cuello es el propio dispositivo (NVMe saturado, NIC a tope) o la topología (camino SYS cruzando NUMA), GPUDirect no lo toca. Mide dónde está el cuello antes.

Conclusión

Toda esta serie ha bajado pisos buscando dónde se pierde el tiempo, y este llega al cableado del edificio. La intuición trata el nodo como una caja homogénea donde “las GPUs hablan con todo”; la realidad es que hay dos buses con propósitos opuestos —una mesa de élite para las GPUs (NVLink) y unos pasillos de servicio para todo lo demás (PCIe)— y un guardia de seguridad en los pasillos que, con la mejor intención, obliga a cada paquete a subir a recepción antes de entregarlo. GPUDirect es el permiso para la entrega directa; ACS e IOMMU son las razones legítimas por las que a veces no te lo dan. La lección no es “desactiva el guardia”: es entender qué camino es crítico (casi nunca el que crees) y qué vigilaba el guardia antes de mandarlo a casa. En un nodo dedicado, el camino directo es casi gratis y conviene tomarlo. En uno que comparte cargas o vive bajo ENS, el aislamiento del bus es un control que se sacrifica con justificación o no se sacrifica. El buen diseño no elige entre rendimiento y aislamiento a ciegas: pone el tráfico crítico en la mesa que no necesita guardia, y deja los pasillos para lo que puede esperar.

Ver también

La mesa compartida: NVLink, NVSwitch y NCCL — el bus GPU↔GPU que ACS no toca; complementario a este post.
Del disco a la HBM: cold start — GPUDirect Storage sobre el path de NVMe, estrangulado por ACS igual que el P2P.
NUMA, hugepages y aislamiento de CPU — la afinidad PCIe es la afinidad NUMA; colocar NIC y NVMe en el socket correcto.
NUMA de red, Cilium eBPF y DRANET — colocación de NIC y GPUDirect RDMA, el mismo principio de sacar a la CPU del medio.
PagedAttention y el block manager — el KV que viaja por PCIe cuando se hace SWAP.
El pase: el scheduler step de vLLM — por qué V1 prefiere RECOMPUTE a SWAP (evita el viaje por PCIe).
Disaggregated serving: prefill y decode separados — transferir KV entre nodos pasa por PCIe→NIC→PCIe.
Controles técnicos ENS / ISO 42001 / EU AI Act — el aislamiento del bus como control de seguridad a justificar.

Referencias

NVIDIA, GPUDirect Storage Best Practices Guide (ACS, IOMMU, paths): https://docs.nvidia.com/gpudirect-storage/best-practices-guide/index.html.
NVIDIA, NCCL Troubleshooting (IOMMU/VT-d y P2P): https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting.html.
M. Giraud, Multi-GPU (NVIDIA) P2P capabilities and debugging tips: https://morgangiraud.medium.com/multi-gpu-nvidia-p2p-capabilities-and-debugging-tips-fb7597b4e2b5.
NVIDIA, H100 Product Brief (PCIe Gen5, NVLink 900 GB/s): https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Center/h100/PB-11773-001_v01.pdf.
NVIDIA, GPUDirect RDMA documentation: https://docs.nvidia.com/cuda/gpudirect-rdma/index.html.

P2p on lo0 — Blog Técnico