R9700: 4 GPUs de 32 GB y un fallo de Linux 7.0

Cuatro GPUs de 32 GB y un fallo del kernel que las deja a medias

Cuatro Radeon AI PRO R9700 de 32 GB detrás de un switch PCIe entregan 128 GB de VRAM accesible con peer-to-peer a 14,0 GB/s por par, y 54,7 GB/s cuando las cuatro copian en anillo al mismo tiempo. Ese es el tipo de rig que hoy compite con instancias cloud para inferencia local, y el que quedó bloqueado por un fallo de asignación de recursos en Linux 7.0.

Un Resizable BAR es la opción de BIOS que permite que el BAR de una tarjeta —el rango del espacio de direcciones físicas de la CPU que se mapea sobre su memoria— sea de 32 GB completos en lugar de los 256 MB por defecto. ROCm, la plataforma de cómputo de AMD, solo activa el peer-to-peer (P2P) entre tarjetas cuando la memoria completa de cada una está mapeada. Sin BAR grande no hay P2P: las copias pasan por la CPU y el rendimiento se derrumba.

El autor del post armó un Broadcom PEX88096 en el único slot x16 de la placa, con cuatro R9700 y dos RTX 3090 detrás. El switch reparte ocho lanes por tarjeta y les permite copiar entre sí sin pasar por la CPU. El problema es de espacio de direcciones: cada BAR de 32 GB ocupa 64 GB del mapa del BIOS. Con las 3090 sumadas, la placa se detenía en la luz blanca de VGA durante el POST.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Por qué Linux 7.0 no puede asignar los BARs?

Con el Resizable BAR apagado, el plan era dejar que Linux hiciera la asignación: fijar el registro de tamaño de cada R9700 en 32 GB, quitar el puerto de CPU del que cuelga el switch y volver a escanear. La teoría era sólida. El kernel, sin embargo, calculó la ventana del switch como la suma plana de sus hijos: cuatro ventanas de 32 GB más 2 MB (el BAR de doorbell, los registros donde el driver avisa que hay trabajo nuevo) más los 288 MB de cada 3090.

El resultado: el kernel le dio al switch una ventana de unos 128,6 GB, pero las cuatro ventanas de las R9700 abarcan 224 GB, porque entre el doorbell de una tarjeta y el inicio de la siguiente hay un hueco de casi 32 GB que la suma no contempla. Dos R9700 recibieron sus BARs y el resto del switch se quedó sin nada. El error, textual:

pci 0000:1b:00.0: bridge window [mem size 0x800200000 64bit pref]: can't assign; no space

La función responsable es pbus_size_mem() en drivers/pci/setup-bus.c, que para cada hijo de un bridge suma su tamaño o su alineación, lo que sea mayor. Cuando el tamaño de cada hijo es múltiplo de su alineación —cierto en BARs normales, que son potencias de dos— no queda hueco. Con una ventana de 32 GB más 2 MB y alineación de 32 GB, ese hueco desaparece del cálculo. El fallo apareció en la versión 7.0.6, y en la prueba de control con el kernel v7.4-rc1 sin parchear entraron tres de las cuatro tarjetas.

No es un caso aislado: Nikolas Britton lo reportó en la lista linux-pci en septiembre, y Ilpo Järvinen, mantenedor de ese código, tiene una serie de 14 parches de corrección de colocación de recursos, en su versión 5 al 6 de noviembre y todavía sin fusionar. El autor la probó y envió su Tested-by. Con el parche, las cuatro R9700 obtienen sus 32 GB.

¿Qué hace falta además del parche del kernel?

Incluso con el parche, la placa necesita algo que fije los tamaños de BAR y vuelva a escanear antes de que carguen los drivers de GPU, porque el resize de amdgpu en tiempo de carga no puede agrandar una ventana en la que ya se apoyan otras tarjetas.

La solución es un módulo fuera del árbol del kernel, gpu-rebar-layout, que corre desde el initramfs —el sistema de archivos mínimo con el que arranca el kernel—. Para cada tarjeta que coincide, fija el registro de tamaño del BAR, elimina el root port por encima del switch y vuelve a escanear. Entre el escaneo y la asignación de direcciones recorre cada segmento de bus bajo el switch y sube la alineación de los BARs prefetchables de 64 bits más chicos hasta el tamaño del BAR más grande de ese segmento, agrupando aparte el resto de los BARs de memoria. Así cada ventana de R9700 queda en exactamente 64 GB y cada ventana de 3090 en 512 MB. Cuando cada ventana es múltiplo de su alineación, el asignador del kernel hace el resto.

Después del reinicio, las R9700 quedaron en 160, 224, 288 y 352 GB, con las 3090 justo por encima, y amdgpu reportó la tarjeta completa:

amdgpu 0000:14:00.0: [drm] Detected VRAM RAM=32624M, BAR=32768M

El módulo se apoya en internals del kernel que pueden cambiar en cualquier release, así que el propio autor recomienda leer el README antes de cargarlo. También hay un detalle de configuración: con pci=disable_acs_redir= en los puertos del switch, el P2P entre las R9700 corrió a 14,0 GB/s por par, que es lo que entrega un enlace gen4 de ocho lanes en la práctica.

¿Cuánto cuesta hoy armar un rig así?

El contexto de precios importa porque el hardware de este post no es barato y se está encareciendo. XDA Developers reportó un precio de lanzamiento de US$1.299 para la Radeon AI PRO R9700, con 32 GB de GDDR6, 300 W de TDP y 640 GB/s de ancho de banda. TweakTown había visto listados tempranos cercanos a US$1.250 y describió la tarjeta como una propuesta de alrededor de la mitad del precio de las RTX PRO Blackwell de NVIDIA, con soporte de ROCm 6.3 y diseño de doble slot con cooler tipo blower, pensado justamente para configuraciones multi-GPU.

Ese piso ya se movió. Según Notebookcheck, la R9700 arranca hoy en US$1.700 en Micro Center, un 31% por encima de su lanzamiento, en el marco de una crisis de memoria que también golpeó a la competencia: la Intel Arc Pro B70, lanzada el 25 de marzo a US$949, aparece en listados de marketplace de hasta US$2.399. El mismo medio cita a TrendForce y MyDrivers para señalar que el precio spot de la GDDR6 se triplicó, de unos US$2,50 por gigabyte en el otoño de 2025 a cerca de US$7,50.

El impacto en el bolsillo es directo. StorageReview calculó en su review de julio que cuatro Arc Pro B70 daban 128 GB de VRAM por unos US$3.800 a precio de lista; con los precios actuales esa misma configuración se va por encima de los US$6.000, según Notebookcheck. Y hay pronósticos de que la escasez de memoria dure hasta 2028.

¿Qué significa esto para tu startup?

Si estás evaluando inferencia local en lugar de cloud, este post es un mapa de los obstáculos que no aparecen en las hojas de especificaciones.

Verifica la asignación de BARs antes de comprar la cuarta tarjeta. El cuello de botella no es la VRAM ni los lanes, es el espacio de direcciones del BIOS y cómo lo reparte el kernel. Arranca con dos tarjetas, revisa lspci -vv y el log de arranque, y recién después escala.
Presupuesta el alza de memoria, no el precio de lista. Con la GDDR6 triplicada y pronósticos de escasez hasta 2028, el costo por gigabyte de VRAM de tu rig puede subir entre la cotización y la compra. Fija precios con el proveedor o compra por etapas.
Congela tu kernel y documenta el workaround. El módulo depende de internals que cambian entre releases. Si tu stack de inferencia depende del P2P, fija la versión del kernel y prueba cada actualización en un equipo de staging antes de tocar producción.
Mide el P2P real, no el teórico. Los 14,0 GB/s por par de este rig son lo que entrega un enlace gen4 de ocho lanes en la práctica. Si tu modelo hace all-reduce entre tarjetas, ese número define tu throughput, no los TFLOPs de la ficha técnica.

Y un apunte sobre el proceso: el autor cuenta que Claude escribió el módulo con él, corrió los comandos y los tests por SSH, y ayudó a redactar el post, mientras él hizo el trabajo físico y verificó los números. Es un buen recordatorio de que la IA acelera la parte de escribir código y ejecutar pruebas, pero la validación sigue siendo humana, y en hardware un error de validación se paga con un equipo que no arranca.