Gpudirect on lo0 — Blog Técnico

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.

La puerta de la cocina que el maître no miró: NUMA de red, Cilium eBPF y DRANET, la cuarta pata del pinning

Sat, 06 Jun 2026 12:00:00 +0200

Cuarta entrega —coda— de “por debajo del motor”. La serie cerró con tres patas de la localidad: el cable entre GPUs, el host a mano y la orquestación declarativa del kubelet. Pero el maître del último post sentaba al grupo mirando CPU, memoria y GPU, y nunca preguntó por qué puerta entran los platos. Esa puerta es la NIC. Aquí está la cuarta pata.

TL;DR

El Topology Manager admite un pod en single-numa-node si sus CPUs, su memoria y su GPU caben en el mismo NUMA node. La NIC no entra en esa cuenta: el kubelet no tiene un Hint Provider para la tarjeta de red. En un nodo de inferencia con red a 200/400 Gb/s —el caso de disaggregated serving, donde el KV-cache viaja por RDMA entre el pool de prefill y el de decode— una NIC en el socket equivocado hace que cada paquete cruce la UPI/QPI, exactamente el “NUMA remoto” que la serie combate por el lado de cómputo, pero por la puerta de la red. Y hay un segundo frente: el softirq (NET_RX) que procesa el datapath corre en la CPU que atiende la IRQ de la NIC; si esa CPU es uno de los cores que isolcpus/reserved-cpus dieron en exclusiva a vLLM, el softirq le roba ciclos y mete jitter en la cola de p99. Cilium eBPF sustituye dos piezas de RKE2 —kube-proxy (por load balancing eBPF/XDP) y el CNI por defecto Canal (por datapath nativo)— y su propia guía de tuning te manda matar irqbalance y fijar las IRQ de la NIC: una cuarta lista que alinear junto a isolcpus y reserved-cpus. El estado del arte 2026 cierra el hueco por arriba: netkit (kernel ≥6.8, overhead de namespace a cero), BIG TCP (super-paquetes de 192k para 100Gb/s+), host-routing (bypass de iptables), y sobre todo DRA/DRANET, el driver de red que por fin co-programa GPU y NIC NUMA-locales en el mismo PCIe root, habilitando GPUDirect RDMA con +59,6% de bus bandwidth en all_gather y +58,1% en all_reduce. Sobre un cluster genérico RKE2 con nodos 4×H100 SXM.

Dónde estás: el plano de red que la trilogía no abrió

La analogía: la puerta por la que entran los platos

Vuelve al restaurante del post anterior. El maître —el Topology Manager— sentó al grupo de ocho en una sola mesa (un NUMA node) porque cabían los comensales (CPUs), los cubiertos (memoria) y la botella reservada (la GPU). Mesa perfecta. Pero el maître nunca miró dónde está el pase de cocina: la puerta por la que entra y sale cada plato.

Esa puerta es la NIC. Por ahí entra el prompt, salen los tokens, y —en disaggregated serving— circula el KV-cache que el pool de prefill manda al de decode. Si la mesa está en la sala de la izquierda (socket 0) pero el pase de cocina está en la de la derecha (socket 1), cada plato cruza el restaurante entero (la UPI/QPI), una y otra vez, por mucho que la mesa esté impecablemente puesta. El comensal no nota la mesa perfecta: nota que el plato llega tarde y frío.

Y hay un detalle más fino: el camarero que cruza la sala con los platos (el softirq que procesa los paquetes) es uno de los comensales sentados. Si el maître le asignó una silla en exclusiva para comer tranquilo (un core aislado por isolcpus para vLLM) pero el restaurante lo pone también a hacer de camarero de la puerta lejana, ese comensal no come: se pasa la cena cruzando la sala. El jitter aparece justo donde creías haber comprado calma.

La trilogía niveló tres patas de la mesa: el cable, el host y la orquestación. La cuarta —por qué puerta entran los platos y quién los lleva— no la nivela ningún manager del kubelet. Hasta 2026.

El hueco: por qué el Topology Manager no mira la NIC

El mecanismo del post 3 es un coordinador (Topology Manager) que consulta a tres Hint Providers: CPU Manager, Memory Manager y Device Manager (el plugin de GPU). Cada uno dice en qué NUMA node puede satisfacer su parte; el coordinador calcula la intersección y admite o rechaza.

El problema es de censo: la NIC clásica no es un “device” del Device Manager. Una tarjeta Ethernet/InfiniBand estándar la gestiona el CNI y el kernel, no se pide en el resources: del pod como nvidia.com/gpu, y por tanto no emite hint NUMA. El Topology Manager alinea CPU+memoria+GPU y deja la NIC donde el hardware la puso, que puede ser el otro socket. El maître tiene tres ayudantes y le falta el cuarto: el que sabe por qué puerta entran los platos.

Esto no importaba cuando la red de un nodo eran 10/25 Gb/s y el cuello de botella estaba en otro sitio. Importa ahora, con dos cargas que saturan la red del nodo:

Disaggregated serving. El KV-cache que viaja entre el pool de prefill y el de decode se mueve por RDMA. Son transferencias grandes, sensibles a latencia y ancho de banda, que en multinodo salen por la NIC.
Colectivos NCCL multinodo. Cuando el tensor/pipeline parallel cruza el límite del nodo, los all-reduce/all-gather ya no van por NVLink sino por GPUDirect RDMA sobre la NIC.

En ambos, dónde está la NIC respecto a la GPU y a los cores del pod decide el rendimiento. Y eso el kubelet, por sí solo, no lo coordina.

El datapath de red bajo NUMA: IRQ, softirq y DMA

Para ver por qué la localidad de la NIC pesa, hay que mirar el camino de un paquete que llega:

Tres hechos del kernel que la analogía comprime:

La IRQ tiene afinidad. Cada cola de la NIC dispara una interrupción que el kernel atiende en una CPU concreta (/proc/irq/<n>/smp_affinity). El procesamiento pesado se difiere a un softirq (NET_RX/NET_TX), que corre en esa misma CPU. Si irqbalance está suelto, las va migrando de forma no determinista —veneno para el p99.
El softirq compite con el pod. Si la IRQ cae en un core que isolcpus reservó para vLLM, el NET_RX de esa cola le roba ciclos al modelo. La señal en /proc/softirqs: una columna de NET_RX que se dispara en una sola CPU. Es el mismo jitter del post 2, entrando por la red.
El DMA tiene origen NUMA. La NIC escribe el paquete por DMA en la RAM del socket de su PCIe root. Si el consumidor (el hilo del pod) está en el otro socket, lee cruzando la UPI/QPI. RFS (Receive Flow Steering) intenta llevar el procesamiento a la CPU del consumidor, pero no puede teletransportar la NIC al otro socket.

Un número, con su salvedad

Pongamos un nodo de 2 sockets, NIC de 400 Gb/s = 50 GB/s en el PCIe root del socket 0, y un pod de decode pinneado al socket 1. Si la NIC satura, esos ~50 GB/s de tráfico de recepción cruzan la UPI hacia el socket 1. Un enlace UPI 2.0 ronda los ~20–40 GB/s por dirección y enlace según generación; aun con varios enlaces, 50 GB/s de tráfico de red a contracorriente se comen una fracción nada despreciable del presupuesto inter-socket —el mismo presupuesto por el que ya compiten los accesos remotos a memoria del pod y, si hay multinodo, el KV-cache de la disaggregation. No doy un “X% de degradación” cerrado porque depende de generación de CPU, número de enlaces UPI, MTU y patrón de tráfico; sin esa metodología, cualquier cifra exacta es marketing.

Lo que sí está medido con metodología pública es el efecto agregado de alinear GPU y NIC: el proyecto DRANET reporta +59,6% de bus bandwidth en all_gather y +58,1% en all_reduce (colectivos NCCL) cuando la NIC asignada es NUMA-local a la GPU frente a no serlo. Esa es la magnitud del hueco que el Topology Manager dejaba abierto.

Qué sustituye Cilium eBPF de RKE2 (y por qué toca esta historia)

RKE2 trae por defecto Canal (Flannel + Calico) como CNI y kube-proxy (reglas iptables/IPVS) para el balanceo de Services. Cambiar a Cilium (cni: cilium en /etc/rancher/rke2/config.yaml) sustituye ambas piezas por un datapath eBPF:

Pieza de RKE2	Qué hace	Qué pone Cilium eBPF
`kube-proxy` (iptables/IPVS)	balanceo de Services	LB en eBPF; con `kubeProxyReplacement=true`, y aceleración en XDP (capa de driver)
Canal (Flannel+Calico)	overlay VXLAN + NetworkPolicy	datapath nativo (`routingMode=native`), NetworkPolicy L3/L4 y L7 en eBPF
veth por pod	par de interfaces del namespace	netkit (kernel ≥6.8): overhead de namespace ~0
recorrido iptables del host	hooks netfilter	host-routing eBPF: bypass de iptables y de la parte alta del stack

Hasta aquí es networking puro y no toca los resource managers del kubelet: Cilium no asigna CPUs exclusivas ni emite hints NUMA de cómputo. Los diez knobs del post 3 siguen idénticos pongas Canal o Cilium.

Pero Cilium sí entra en la cuarta pata por dos puertas. La primera: su propia guía de tuning recomienda, literalmente, “matar irqbalance y fijar las IRQ de la NIC a CPUs específicas para máximo aislamiento de la carga”, además del perfil tuned network-latency, el governor performance y CONFIG_PREEMPT_NONE. Es decir: el datapath eBPF rinde de verdad solo si coordinas la afinidad de IRQ —y esa afinidad tiene que apuntar a los cores housekeeping (reserved-cpus), nunca a los aislados. Aparece así una cuarta lista que mantener coherente con isolcpus y reserved-cpus:

isolcpus = 2-31,34-63 # cores exclusivos para vLLM (host, post 2)
reserved-cpus = 0-1,32-33 # housekeeping del kubelet (post 3)
IRQ affinity = 0-1,32-33 # NIC IRQs → SOLO housekeeping (este post)
 # nunca 2-31: ahí el softirq robaría al modelo

La segunda puerta: netkit + host-routing + BIG TCP reducen cuántas veces el paquete cruza el stack y el namespace, lo que amortigua (no elimina) el coste del cruce NUMA. BIG TCP arma super-paquetes de hasta 192k (frente a 64k) para 100Gb/s+; menos travesías del stack es menos trabajo de softirq en el core, y por tanto menos presión sobre el presupuesto inter-socket. Es la analogía del continuous batching aplicada al stack de red: amortizar un coste fijo sobre lotes mayores.

Perfil de rendimiento de Cilium (estado 1.19, kernel ≥6.8)

# Helm, perfil de rendimiento recomendado (resumen de la tuning guide)
helm install cilium cilium/cilium --version 1.19.4 \
 --namespace kube-system \
 --set routingMode=native \
 --set bpf.datapathMode=netkit \  # overhead de namespace ~0 (kernel >=6.8)
 --set bpf.masquerade=true \
 --set kubeProxyReplacement=true \  # sustituye kube-proxy de RKE2
 --set enableIPv4BIGTCP=true \  # super-paquetes 192k (NIC mlx5/ice)
 --set enableIPv6BIGTCP=true \
 --set bpf.distributedLRU.enabled=true \# mapas BPF per-CPU: menos contención de spinlock
 --set bpf.mapDynamicSizeRatio=0.08 \
 --set bpfClockProbe=true

# Verificación dentro de un pod de Cilium:
cilium status --verbose | grep -E "Device Mode|Host Routing|BIG TCP|XDP"
# Device Mode: netkit · Host Routing: BPF · IPv4 BIG TCP: enabled · XDP Acceleration: Native

Salvedad escéptica: netkit y BIG TCP son beta y exigen kernel ≥6.8 y NICs concretas (mlx4/mlx5/ice). No son in-place: cambian fundamentos del datapath y obligan a reiniciar pods o, mejor, a aplicarlos por per-node config solo en nodos nuevos. Para un cluster ENS en producción, eso es una ventana de mantenimiento, no un helm upgrade a ciegas.

El estado del arte 2026: DRA y DRANET, el maître que por fin mira la puerta

Lo que cierra el hueco de raíz no es Cilium —es el mecanismo de admisión que el kubelet no tenía para la NIC: Dynamic Resource Allocation (DRA), beta desde Kubernetes 1.32 y con avances en cada release hasta la 1.36 (mayo 2026). DRA generaliza el modelo de “devices” más allá de la GPU: un driver descubre el hardware, publica ResourceSlices con sus atributos —incluida la topología NUMA y el PCIe root— y el scheduler resuelve ResourceClaims que pueden exigir afinidad entre dispositivos.

DRANET (proyecto kubernetes-sigs) es el driver DRA de red. Descubre las NICs (incluidas las RDMA-capaces), las anuncia como ResourceSlices, y vía NRI las inyecta en el namespace del pod —compatible con el CNI que ya tengas, Cilium incluido. La pieza clave para esta historia: combinado con el NVIDIA GPU DRA driver, permite co-programar GPU y NIC que comparten PCIe root (la relación que NVIDIA llama NODE), que es justo la condición de GPUDirect RDMA. El maître por fin tiene su cuarto ayudante: "¿hay una NIC NUMA-local a esta GPU?".

El ResourceClaimTemplate usa selectores CEL para pedir exactamente esa alineación:

# Pedir una NIC RDMA NUMA-local a la GPU asignada (esquema ilustrativo DRANET/DRA)
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaimTemplate
metadata:
 name: gpu-nic-numa-aligned
spec:
 spec:
 devices:
 requests:
 - name: rdma-nic
 deviceClassName: dra.net  # NICs publicadas por DRANET
 constraints:
 - requests: ["rdma-nic"]
 matchAttribute: "dra.net/pcieRoot" # misma raíz PCIe que la GPU
 # → habilita GPUDirect RDMA sobre camino NUMA-local

Por qué importa para inferencia, no para “AI training” abstracto: en disaggregated serving, RDMA es lo que mueve el KV-cache entre el pool de prefill y el de decode con la latencia que el TTFT exige; y en multinodo, GPUDirect RDMA sustituye al NVLink como medio del colectivo. Alinear GPU+NIC en el mismo PCIe root es lo que convierte un “RDMA que funciona” en un “RDMA que rinde” —los +60% de bus bandwidth de DRANET.

Estado y salvedades: DRA es beta (gates a habilitar a mano), DRANET es joven (proyecto SIG, en evolución) y la oferta gestionada existe sobre todo en cloud (GKE managed DRANET en preview, AKS para RDMA). Para on-premise ENS es camino, no producto cerrado: el valor hoy es entender que la cuarta pata ya tiene mecanismo estándar OSS, y empezar a pilotarlo en un nodo de laboratorio, no meterlo en producción crítica este trimestre.

Cómo se conecta con el resto del stack

Con el host (post 2). La afinidad de IRQ de la NIC es una tercera lista que casar con isolcpus y reserved-cpus. Las IRQ van a housekeeping; los cores aislados, intactos. Descoordinarlas mete por la puerta de la red el jitter que isolcpus echó por la de cómputo.

Con la orquestación (post 3). DRA es la extensión natural del Topology Manager: el mismo principio de “admite solo si encaja en el NUMA node” llevado a la NIC. Donde el Device Manager dejaba la red fuera del censo, DRANET la mete.

Con el interconnect (post 1). Dentro del nodo manda NVLink; al cruzar el límite del nodo, GPUDirect RDMA sobre la NIC es el medio del colectivo. La política NUMA del kubelet garantiza que GPU y CPUs comparten socket; DRANET añade que la NIC también —y solo entonces el RDMA va por el camino corto.

Con disaggregated serving. El KV-cache prefill→decode es el tráfico que más castiga una NIC mal ubicada. La cuarta pata es lo que hace que separar prefill y decode no se pague en latencia de transferencia.

Con capacity planning. El dimensionado gana una dimensión: no basta con “GPUs por nodo y cores por NUMA node”; hay que contar cuántas NICs NUMA-locales a GPU tiene el chasis. Un nodo con 4 GPUs y una sola NIC en el socket 0 tiene dos GPUs “lejos de la puerta”.

Con la observabilidad. Lo que confirma que la cuarta pata está bien puesta no es un dashboard de aplicación: es /proc/softirqs (¿NET_RX concentrado en housekeeping?), nvidia-smi topo -m (¿relación NODE/PHB GPU↔NIC?) y los contadores de la NIC. Encaja con la observabilidad GPU con DCGM: la GPU “al 60% sin razón” puede ser el host esperando paquetes que cruzan el socket.

Trampas y cosas que no son lo que parecen

Creer que cambiar a Cilium “ya optimiza la red”. Cilium eBPF sustituye a kube-proxy y Canal y rinde mejor de serie, pero el despliegue por defecto prioriza compatibilidad, no rendimiento. Sin irqbalance desactivado, sin IRQ fijadas a housekeeping y sin netkit/host-routing, dejas la mayor parte de la mejora en la mesa. La doc de Cilium lo dice; mucha gente no lee la tuning guide.

Fijar las IRQ de la NIC a cores aislados. El error simétrico del knob 6 del post 3: si pones la afinidad de IRQ sobre isolcpus, el softirq NET_RX le roba ciclos a vLLM justo en los cores que aislaste para que nadie lo molestara. Las IRQ van a reserved-cpus, siempre.

Asumir que el Topology Manager ya alinea la NIC. No lo hace: la NIC clásica no es un Hint Provider. Si necesitas localidad NIC↔GPU, hoy el mecanismo es DRA/DRANET, no una política del kubelet. Esperar a que single-numa-node lo resuelva es esperar a algo que no está en su diseño.

Meter DRA/DRANET en producción ENS este trimestre. Es beta y joven. El movimiento sensato es pilotarlo en un nodo de laboratorio, medir all_reduce/all_gather con y sin alineación, y decidir con datos. La cifra del +60% es de un entorno concreto; reprodúcela en el tuyo antes de prometerla.

BIG TCP / netkit sin leer los requisitos. Kernel ≥6.8, NICs mlx4/mlx5/ice, sin túnel ni cifrado para BIG TCP, y nada de in-place: obliga a reiniciar pods o a per-node config. En un cluster con IPsec o con NICs no soportadas, parte de esto no aplica. Verifica cilium status --verbose antes de dar por hecho que está activo.

Confundir el datapath eBPF (kernel) con el agente Cilium (pod). cilium-agent es un DaemonSet Burstable que debe vivir en housekeeping (lo cubre system-reserved). Pero el procesamiento del datapath corre en softirq, gobernado por la afinidad de IRQ del host, no por reserved-cpus. Son dos cosas distintas; pinear bien el pod no pinea el softirq.

Conclusión

La serie “por debajo del motor” perseguía una idea: el rendimiento que parece un problema del motor (vLLM lento) o del modelo (cuantización) es, demasiadas veces, un problema de localidad en una capa más baja. La trilogía cubrió tres: el cable (NVLink no usado), el host (NUMA remoto, jitter) y la orquestación (pinning que no ocurrió). Faltaba la cuarta: la red. El Topology Manager sienta al pod en una mesa NUMA perfecta y nunca pregunta por qué puerta entran los platos ni quién los lleva. En un nodo a 25 Gb/s daba igual; en uno a 400 Gb/s con KV-cache cruzando por RDMA, esa puerta decide el TTFT y el ancho de banda del colectivo. Cilium eBPF sustituye kube-proxy y Canal por un datapath que rinde —si coordinas la afinidad de IRQ con isolcpus/reserved-cpus, una cuarta lista que alinear—, y DRA/DRANET aporta por fin el censo que faltaba: co-programar GPU y NIC NUMA-locales en el mismo PCIe root, con la magnitud de mejora (+60% de bus bandwidth NCCL) que mide lo grande que era el hueco. Bajar de nivel no es esnobismo: es que la causa raíz vivía, una vez más, una capa por debajo de donde mira el dashboard.

Ver también

Hardening y secretos del stack LLM soberano: defensa en profundidad — las NetworkPolicy default-deny y el mTLS con Cilium en el hardening del stack.
Los pasillos y el guardia: PCIe, GPUDirect P2P y ACS — el GPUDirect RDMA que DRANET coloca NUMA-local lo rompe el ACS si fuerza el tráfico por el root complex; el bus por debajo de la localidad NIC↔GPU.
El maître que solo te sienta si cabéis en una mesa: resource managers en RKE2 — el post 3, padre directo de éste: el Topology Manager pinnea CPU+memoria+GPU pero no la NIC; aquí se abre esa cuarta pata.
NUMA, hugepages y aislamiento de CPU — el post 2; la afinidad de IRQ de la NIC es una tercera lista que casar con isolcpus y reserved-cpus, y el softirq NET_RX es el mismo jitter entrando por la red.
NVLink, NVSwitch y NCCL — el post 1; al cruzar el nodo, GPUDirect RDMA sobre la NIC sustituye a NVLink, y DRANET es lo que garantiza que ese RDMA va por el camino NUMA-local.
Disaggregated serving: prefill y decode separados — el caso que más castiga una NIC mal ubicada: el KV-cache prefill→decode viaja por RDMA y paga cada cruce de socket.
El stack de inferencia LLM on-premise en siete capas — el edificio completo; la red es el plano que sostiene la inferencia multinodo.
Autoescalado de LLMs en Kubernetes con KEDA — cada réplica nueva no solo pasa por la admisión NUMA del kubelet; con DRA, también por la del ResourceClaim de NIC.
Capacity planning de inferencia on-premise — el sizing gana una dimensión: cuántas NICs NUMA-locales a GPU tiene el chasis, no solo cuántas GPUs.
Entornos mixtos NVIDIA + Intel — la afinidad NUMA NIC↔acelerador se complica cuando el nodo mezcla GPUs, aceleradores y NICs heterogéneas.
Observabilidad GPU con DCGM — cómo confirmar, métrica en mano, que la “GPU al 60%” no es el host esperando paquetes cruzando el socket.
Del disco a la HBM: cold start y carga del modelo — el mismo principio de “saca a la CPU del medio” que aquí da GPUDirect RDMA, aplicado al disco con GPUDirect Storage para cargar pesos directos NVMe→HBM.
SM, CUDA streams y CUDA graphs — bajado un piso más: una vez los datos están en HBM, qué pasa en el silicio que los ejecuta y por qué el decode se vuelve launch-bound.
El contratista con la llave maestra: aislar agentes de IA del workstation al cluster — el otro uso de esta misma capa de kernel: sobre el datapath eBPF de Cilium, Tetragon engancha sus kprobes para observar y matar lo que hace un agente de IA en el cluster. Su runbook trae las TracingPolicy concretas.

Referencias

Cilium, Tuning Guide (netkit, host-routing, BIG TCP, XDP, fijar IRQ y matar irqbalance): https://docs.cilium.io/en/stable/operations/performance/tuning/.
Cilium 1.19 (febrero 2026), Cilium at Ten Years — endurecimiento de cifrado, políticas y observabilidad: https://www.infoq.com/news/2026/02/cilium-119/.
Isovalent, Cilium 1.18 (IPv6, encrypted overlay, ingress bandwidth, policy perf): https://isovalent.com/blog/post/cilium-1-18/.
RKE2, Network Options (Canal por defecto; Cilium con kube-proxy replacement): https://docs.rke2.io/networking/basic_network_options.
Kubernetes, Dynamic Resource Allocation: https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/.
Kubernetes blog, v1.36: More Drivers, New Features, and the Next Era of DRA (mayo 2026): https://kubernetes.io/blog/2026/05/07/kubernetes-v1-36-dra-136-updates/.
DRANET (kubernetes-sigs), driver DRA de red y paper The Kubernetes Network Driver Model (+59,6% all_gather / +58,1% all_reduce): https://github.com/kubernetes-sigs/dranet.
AKS Engineering, Optimizing RDMA performance for AI workloads on AKS with DRANET (abril 2026): https://blog.aks.azure.com/2026/04/01/dranet-rdma-optimization-for-ai-on-aks.
Linux network tuning — IRQ affinity, RSS/RPS/RFS y softirq NUMA: https://andreaskaris.github.io/blog/networking/rss-irq-affinity-and-rps/.