Montaje de referencia: un laboratorio de robótica + IA en un solo rack

Los artículos anteriores describen la arquitectura, el stack de software, el presupuesto eléctrico y el diseño de la red. Este le pone precio y lista de materiales a todo ello, a partir de hardware real que Kentino ha entregado y medido, no de una lista teórica sacada de una ficha de marketing.

El destino del despliegue es un laboratorio de investigación o integración que hace funcionar entre uno y cuatro robots junto con inferencia on-premise y capacidad de entrenamiento. Escala media: ni un equipo de aficionado que apenas puede servir un 7B, ni un clúster a hiperescala que exige un equipo de instalaciones. Un entorno de trabajo serio que un grupo de dos a seis personas puede montar, operar y hacer evolucionar sin un DevOps dedicado.

El artículo cubre dos niveles del mismo patrón arquitectónico. El nivel de desarrollo de 4 GPU es donde empiezan la mayoría de los laboratorios. El nivel de producción de 8 GPU es donde acaban tras la primera carga de trabajo real. Las elecciones de hardware son distintas; la arquitectura es idéntica.

Qué muestran los datos de la flota

Kentino ha desplegado una flota de nodos de cálculo de 4 GPU configurados de forma uniforme. Cada unidad lleva la misma especificación: AMD EPYC 7542 (32 núcleos / 64 hilos, 2.9 GHz en boost), 512 GB DDR4 ECC LRDIMM a 2666 MT/s repartidos en ocho módulos, cuatro GPU RTX 4090 (24 GB de VRAM cada una, 96 GB en total), una unidad NVMe de trabajo de 2 TB y un SSD SATA de 512 GB para el sistema operativo. La placa base es la ASRockRack ROMED8-2T/BCM. Ubuntu 24.04 LTS, kernel 6.8.0-generic, controlador NVIDIA 590.48.01, CUDA 13.1/13.2.

Los diez nodos arrojan cifras de benchmark idénticas. No es casualidad: es justo el sentido de una configuración de referencia. Cuando todas las unidades salen con la misma configuración, el benchmark es una especificación, no una ejecución afortunada.

Cálculo en GPU

Multiplicación de matrices FP16 en los tensor cores de las cuatro tarjetas (carga de 8192 × 8192):

La GPU 1 rinde alrededor de un 6% menos que las GPU 0, 2 y 3, dentro de la dispersión normal de la lotería del silicio en tarjetas de consumo. Las cuatro superaron 60 segundos de GPU-burn y de estrés combinado GPU+CPU sin un solo error de cálculo. El margen térmico es cómodo: el umbral de throttling de la RTX 4090 está en 83 °C y la tarjeta más caliente de la flota llegó a 73 °C con carga simultánea de GPU y CPU. No se observó throttling en ningún nodo.

Una nota práctica sobre los límites de potencia: la flota se entrega con límites por tarjeta ligeramente distintos (450 W, 480 W, 500 W según la ranura). Para un uso en producción sostenido, igualar las cuatro a 450 W suaviza el consumo agregado y reduce el desequilibrio entre fuentes. La penalización en TFLOPS de 450 W frente a 500 W es inferior al 2%: no compensa la carga asimétrica de los raíles.

Inferencia con vLLM — Llama 3.3 70B AWQ

Medido con vLLM 0.19.0, tensor_parallel_size=4, gpu_memory_utilization=0.80, max_model_len=2048:

Una salvedad importante: el benchmark utilizó el kernel de cuantización awq, no awq_marlin. La ruta awq_marlin en Ada Lovelace (RTX 4090) es de 2 a 3× más rápida en latencia de petición única. Los despliegues en producción deberían usar awq_marlin o la ruta FP8 con vLLM 0.20+, que reduce aún más la diferencia. Con awq_marlin, la cifra de petición única pasa de ~8 tok/s a unos 16-20 tok/s en estas tarjetas, más en línea con lo que los usuarios experimentan en la práctica. La mejora del rendimiento agregado por lotes es proporcionalmente menor, porque con alta concurrencia el cuello de botella se desplaza del cálculo al ancho de banda de memoria.

Estas cifras corresponden a Llama 3.3 70B en INT4 (AWQ). Un modelo de 7B u 8B en Q4 va de 4 a 6× más rápido por token en el mismo hardware; uno de 13B, unas 2.5× más rápido. La cifra del 70B es la restricción de dimensionamiento relevante para los VLM y los grandes modelos de planificación en robótica.

llama.cpp — un solo usuario, sin concurrencia

Medido con llama-cpp-python 0.3.20 (CUDA/cuBLAS), Llama 3.3 70B Instruct Q4_K_M GGUF, con las cuatro GPU:

llama.cpp carga más rápido (10.8 s frente a 95 s de vLLM) y ofrece mayor velocidad de decodificación para un solo usuario en estas tarjetas, porque no paga el sobrecoste del planificador de batching continuo. El precio es la ausencia de concurrencia: un usuario cada vez. La lectura correcta de estas cifras: llama.cpp en un nodo de 4 GPU le da a un desarrollador un 70B ágil para uso interactivo; vLLM es la opción acertada en cuanto tiene más de un cliente.

Consulte I02 para ver la matriz de decisión completa del stack de servicio. La versión corta: empiece con vLLM en Docker, use la cuantización awq_marlin y pase a llama.cpp solo en equipos de desarrollo de un usuario o en despliegues Jetson.

Ancho de banda de memoria de la GPU

El ancho de banda dispositivo a dispositivo (dentro de la tarjeta) se mantiene constante entre 920.2 y 920.6 GB/s en las cuatro tarjetas, con una diferencia inferior al 0.04%, lo que confirma que la GDDR6X no es la variable aquí. El ancho de banda PCIe de host a dispositivo queda en 26.2-26.3 GB/s, lo que confirma que el enlace Gen4 x16 se negocia por completo bajo carga (en reposo el estado del enlace aparece como Gen1 por el ahorro de energía ASPM: es normal, no un fallo). Las transferencias entre GPU por PCIe (sin NVLink) miden entre 19 y 22 GB/s, el techo esperado para la comunicación directa sobre un complejo raíz PCIe compartido sin NVLink (véase N03 para el contexto).

Almacenamiento NVMe

El ancho de banda secuencial roza el techo de Gen4 x4. Las IOPS aleatorias con profundidad de cola 32 escalan bien: 568K IOPS de lectura están muy por encima de lo que exigen la carga de pesos de un LLM o los patrones de acceso a conjuntos de datos a escala de un solo nodo. Cargar un modelo de NVMe a VRAM lleva entre 10 y 30 segundos según el tamaño; esta unidad no es el cuello de botella.

La configuración de referencia

Lista de materiales — nivel de desarrollo de 4 GPU

El nivel de desarrollo es el punto de partida adecuado para un laboratorio con uno o dos robots, uno o dos modelos activos y algún ajuste fino LoRA ocasional.

Nivel de desarrollo: nodo de cálculo de 4 GPU + switch ToR gestionable + AP de 6 GHz + SAI online de 5 kVA.

Lista de materiales — nivel de producción de 8 GPU

El nivel de producción duplica el número de GPU. El patrón arquitectónico es el mismo; la CPU, la RAM y el chasis escalan en consecuencia para dar soporte a ocho ranuras PCIe a pleno ancho de banda. Una plataforma AMD EPYC Genoa o Turin aporta el presupuesto de líneas PCIe necesario para 8 ranuras x16 sin compromisos de bifurcación (véase W02).

Nota: el complemento de NIC de 25 GbE solo es viable en chasis de 8 GPU. El chasis de 4 GPU no tiene espacio libre en las ranuras para una tarjeta de red adicional: los puertos 10 GbE integrados de la ROMED8-2T/BCM son el límite práctico en el nivel de 4 GPU (véanse N01 y las reglas de la página de producto).

Almacenamiento más allá del nodo de cálculo

Para el nivel de desarrollo, un NAS de 4 bahías con 4× discos de 16 TB ofrece 48 TB utilizables en RAID-5, suficiente para un año de datos de episodios en un laboratorio con 2 robots. Conéctelo a 10 GbE al switch ToR; no lo ponga en la misma interfaz que el tráfico de los robots.

Energía y refrigeración del rack

Según I04:

Los datos de las pruebas de estrés de la flota confirman que el nodo de 4 GPU consume ~1,914 W a plena carga de GPU, con las cuatro tarjetas en su límite de potencia. Si se suman la CPU (~120 W sostenidos), el NVMe y los ventiladores, el nodo se sitúa en torno a 2.1-2.2 kW sostenidos.

Instalación eléctrica para el nivel de desarrollo: una acometida trifásica de 400 V y 16 A es el mínimo; 32 A trifásicos dan margen para crecer. Los cables de las fuentes, en dos fases distintas. Consulte I04 y P02 para el esquema de cableado. Para el nivel de producción (10 kW de rack completo) necesita una acometida trifásica de 400 V y 32 A con al menos 15 kW de capacidad de refrigeración.

Dimensionado del SAI: dimensione solo para el servidor, no para los robots. Para el nivel de desarrollo, un SAI online de doble conversión de 5 kVA es el mínimo sensato. Para el nivel de producción, 10 kVA. Especifique siempre online de doble conversión. Consulte P05.

Stack de software sobre bare metal

Stack de software: Ubuntu y controlador NVIDIA fijados → toolkit de contenedores → vLLM + llama.cpp + nginx + monitorización.

Fijar el controlador no es negociable. La flota funciona con el controlador 590.48.01; apt-mark hold nvidia-driver-590 es lo primero que se hace tras instalar el sistema operativo en bare metal. Un apt-get upgrade desatendido que se trae un controlador más nuevo ha roto la inferencia en producción exactamente tantas veces como cabría esperar. Consulte L01 para el procedimiento completo.

La monitorización no es opcional. Los datos de la flota muestran que la GPU 3 de un nodo tuvo errores PCIe AER corregibles (RxErr + BadTLP) durante las pruebas: corregidos automáticamente por el hardware, pero visibles en los contadores de DCGM. Sin monitorización, esto aparece semanas después como «errores raros de inferencia de vez en cuando». Configure DCGM y establezca una alerta para los errores ECC corregibles por encima de una tasa de referencia. Consulte L05 para el stack de Prometheus + Grafana.

Variantes de dimensionamiento

El nivel de desarrollo de 4 GPU: qué puede ejecutar realmente

96 GB de VRAM total (4× 24 GB) con TP=4:

El VLM de 72B no encaja con holgura en 4× 24 GB a INT4: las cuentas salen justas, pero las ventanas de contexto por encima de 4K lo desbordan. O bien usa la variante VLM de 32B, o bien sube al nivel de 8 GPU o a un nodo de 4× RTX Pro 6000 Blackwell (96 GB de VRAM cada una) para la clase de 72B. Consulte W07 para la discusión sobre VRAM y tamaño de modelo.

El nivel de desarrollo cubre: un modelo de inferencia de 70B sirviendo de 1 a 3 clientes robot simultáneos, un VLM (clase 32B) para consultas visuales y algún ajuste fino LoRA ocasional sobre un modelo base más pequeño. Eso cubre el 80% de los casos de uso de un laboratorio de robótica en 2026.

El nivel de producción de 8 GPU: el margen adicional

192 GB de VRAM total (8× 24 GB):

El nivel de 8 GPU abre además la puerta al servicio simultáneo de varios modelos: un LLM de 70B en 4 GPU y un VLM de 32B en las otras 4, atendiendo desde una sola máquina a una flota mixta de robots con requisitos de modelo distintos. En el nivel de 4 GPU esto exige un cambio de modelo con una parada de entre 30 y 120 s por cambio.

Nota sobre TP=8 para un 70B: TP=8 sobre comunicación directa PCIe (sin NVLink) escala peor que TP=4 × PP=2 con concurrencias superiores a 8, porque el coste de comunicación del all-reduce crece con el grado de paralelismo de tensores. Los datos del benchmark sitúan el ancho de banda entre GPU por PCIe en 19-22 GB/s: suficiente para TP=4, pero el all-reduce con TP=8 y lotes grandes satura esos enlaces. La configuración recomendada para un 70B en 8× 4090 es TP=4 × PP=2, tal y como se muestra en I02.

Distribución del rack

El nodo de cálculo va siempre por debajo del switch y del SAI: el flujo de aire de delante hacia atrás exige que el aire frío entre por el frontal del rack (pasillo frío o impulsión del aire acondicionado de la sala), atraviese el servidor y salga al pasillo caliente por la parte trasera. Consulte W05 e I04 para la disciplina de flujo de aire.

El host de salto es una máquina de 1U o de formato reducido con salida de vídeo, que se utiliza para la puesta en marcha inicial, la instalación de controladores y el mantenimiento cuando el servidor principal no es accesible por red. No necesita GPU. Una estación de trabajo de segunda mano o un pequeño 1U con 16 GB de RAM y un SSD Gen3 bastan.

Lo que esta configuración no es

No es un servidor de GPU de sobremesa metido en una caja de rack. El montaje en torre de sobremesa al aire —GPU sobre tarjetas riser, sin caja, ventiladores apuntando al techo— no es lo que aquí se describe. Los montajes de sobremesa están bien para desarrollo; no están homologados para funcionamiento continuo 24/7 ni ofrecen el flujo de aire dirigido de delante hacia atrás que mantiene las GPU a una temperatura de trabajo estable durante semanas.

No es un clúster NVLink. La RTX 4090 (clase consumo/estación de trabajo) no tiene NVLink. Las transferencias entre GPU van por PCIe a 19-22 GB/s, no a 900 GB/s. Esto basta para servir inferencia con TP=4 y es una limitación real para el entrenamiento con TP=8. Si su carga de trabajo es entrenamiento distribuido intensivo de un modelo de 70B o superior, la RTX Pro 6000 Blackwell (con NVLink en su edición multi-GPU) o una plataforma con NVSwitch cambian las cuentas, pero también el precio. Consulte N03.

No son fuentes redundantes. La configuración de doble fuente es una entrega de energía repartida: la fuente A alimenta las GPU 0 y 1 (más la placa base) y la fuente B alimenta las GPU 2 y 3. Si falla la fuente A, pierde dos GPU y la placa base. No hay conmutación automática. Esto es una doble fuente honesta: equilibra la carga de los raíles y reduce el riesgo de punto único frente a una sola fuente grande, pero no es redundancia N+1. Consulte W04.

No es una alternativa a la nube para todo. Si la carga de trabajo principal de su laboratorio es una llamada a un modelo diez veces al día, las cuentas de TCO no justifican el on-premise. Esta configuración se amortiza frente al gasto en API en la nube cuando se ejecuta inferencia sostenida para varios clientes, se hace ajuste fino con regularidad o se opera bajo requisitos de residencia de datos. Consulte T02 para las cuentas detalladas.

Por qué estas elecciones concretas

AMD EPYC 7542 como CPU anfitriona. Un EPYC de 32 núcleos aporta 128 líneas PCIe 4.0 desde la propia CPU, suficientes para 4 GPU a x16 sin bifurcación, además de una NIC, el almacenamiento y un conmutador PCIe para ampliaciones. EPYC es la plataforma estándar para servidores de IA multi-GPU a esta escala por una razón: un Intel Xeon con el mismo número de núcleos ofrece menos líneas PCIe, lo que obliga a aceptar compromisos de bifurcación en configuraciones de 4 GPU o más. Consulte W02 para el cálculo de líneas.

512 GB de RAM del sistema. La flota se entrega con 512 GB (8× 64 GB), por encima de los 256 GB nominales de la especificación. Es intencionado: la carga de modelos grandes al arrancar el contenedor, la precarga de conjuntos de datos para entrenamiento y la caché de páginas del sistema operativo consumen RAM que la VRAM no puede aportar. Con vLLM y el espacio de intercambio de la caché KV activado, la RAM del sistema es directamente utilizable como desbordamiento: 4 GB de swap por GPU requieren 16 GB de margen de RAM del sistema. 512 GB dan ese margen y dejan sitio para Isaac Sim, que puede mantener entre 10 y 30 GB de estado de simulación en la RAM del sistema durante el entrenamiento de políticas.

NVMe de trabajo de 2 TB. El benchmark muestra 4,589 MB/s de lectura secuencial, suficiente para cargar un modelo de 70B en FP8 (~75 GB) en menos de 20 segundos. Para un laboratorio que cambia de modelo con frecuencia (flujo de desarrollo, pruebas A/B de stacks de inferencia), el tiempo de carga importa. Un SSD SATA más lento duplica o triplica ese tiempo en cada cambio.

Flujo de aire del rack de delante hacia atrás. El error más habitual en los primeros montajes: la orientación de sobremesa (entrada lateral, salida superior y trasera) no funciona en un rack cerrado. El nodo de cálculo debe usar un flujo de aire dirigido acorde con la convención de pasillo frío / pasillo caliente del rack. Consulte I01 y W05.

La valoración honesta del hardware de 2026

Esta es una configuración de referencia de mayo de 2026. La RTX 4090 no es la GPU más reciente del catálogo de Kentino: la RTX 5090 (32 GB de VRAM, arquitectura Blackwell, sm_120) y la RTX Pro 6000 Blackwell (96 GB de VRAM) están disponibles y cambian de forma notable el cálculo de VRAM por tarjeta. Un nodo de 4 GPU con RTX Pro 6000 Blackwell ofrece 384 GB de VRAM, suficiente para alojar con holgura Qwen 2.5 VL 72B en FP8 sobre cuatro tarjetas, a un coste por tarjeta proporcionalmente mayor.

Lo que no cambia entre generaciones es el patrón arquitectónico. Anfitrión AMD EPYC, multi-GPU por PCIe, chasis de delante hacia atrás, doble fuente, Ubuntu 24.04, vLLM en Docker, Prometheus y exportador DCGM. Ese patrón se ha mantenido durante dos generaciones de GPU y sobrevivirá a la siguiente. La lista de piezas se abarata y se acelera; el patrón se mantiene.

---

Esto forma parte de la Kentino Wiki, una serie de referencia sobre computación de IA, robótica y los sistemas que las conectan. Comentarios y correcciones son bienvenidos en info@kentino.com.