Caso práctico: estación de trabajo de IA con 4x RTX 4090

Este artículo documenta un montaje completo encargado por un cliente del ámbito de la investigación que necesitaba una estación de trabajo de inferencia LLM montable en rack, apta para funcionar 24/7 y con suficiente VRAM para alojar modelos de clase 70B sin depender de la nube. Todo lo que aparece aquí está medido sobre el hardware real. Sin estimaciones sintéticas ni cifras de marketing.

El montaje se encargó y se entregó en abril de 2026. Las pruebas de puesta en marcha se ejecutaron el 2026-04-10.

Por qué 4× RTX 4090

El requisito de carga de trabajo estaba claro desde el principio: ejecutar un LLM de 70B cuantizado con una latencia utilizable en peticiones individuales, atender peticiones simultáneas en un entorno de equipo de investigación pequeño y mantenerlo todo en local por motivos de control de los datos. La pregunta era cuántas GPU y de qué tipo.

Un modelo de 70B en INT4 (AWQ o GGUF Q4_K_M) ocupa en la práctica unos 38–40 GB de VRAM. Eso descarta por completo las soluciones de una sola GPU: ni siquiera una RTX 4090 de 24 GB puede alojar el modelo por sí sola. Hacen falta al menos dos, y preferiblemente cuatro, para que el servicio con paralelismo de tensores bajo vLLM tenga margen para la caché KV.

Cuatro tarjetas RTX 4090 suman 96 GB de VRAM total. Es suficiente para cargar un modelo Llama 3.3 70B AWQ INT4 con gpu_memory_utilization=0.80 y disponer aún de un espacio de caché KV apreciable para las peticiones por lotes. También aporta capacidad de cómputo —4× chips de 128 SM funcionando a la vez— que influye en la velocidad de procesamiento del prompt.

La alternativa que se valoró fue 4× RTX Pro 6000 Blackwell, que daría 4× 96 GB = 384 GB de VRAM. Es una categoría completamente distinta: más VRAM de la que necesita cualquier modelo de 70B, pensada para ejecutar varios modelos grandes a la vez o alojar modelos de clase 200B+ con una cuantización razonable. Para esta carga de trabajo —un modelo principal, lotes simultáneos pequeños y presupuesto de estación de trabajo de un solo inquilino— esa capacidad adicional quedaría sin usar y la diferencia de precio es considerable. Las 4× RTX 4090 eran la respuesta correcta para el caso de uso planteado.

En la gama existe también una alternativa de 8× L40. La L40 ofrece 48 GB de VRAM por tarjeta, soporte ECC y está diseñada para carga sostenida de centro de datos. Para este cliente, la carga de trabajo no exigía contratos de fiabilidad de nivel de centro de datos, la ausencia en la L40 de las rarezas de los controladores de gama de consumo era una ventaja menor y el presupuesto no llegaba hasta ahí. Conviene conocerla como vía de ampliación.

Un techo arquitectónico que conviene nombrar de entrada: las tarjetas RTX 4090 no tienen NVLink. Toda la comunicación entre GPU se realiza por PCIe peer-to-peer. Esto es relevante para la inferencia con paralelismo de tensores (se trata en la sección de pruebas) y conviene entenderlo antes de cursar el pedido. Consulte N03 para un tratamiento completo de cuándo importa NVLink y cuándo no.

Especificación del hardware

Algunas notas sobre las elecciones:

CPU. El EPYC 7542 es un chip de 32 núcleos de la generación Rome con 128 MB de caché L3 repartidos en 8 CCD. Para una estación de trabajo de inferencia va sobrado en número de núcleos: no va a saturar 64 hilos solo con inferencia. Donde se gana su sitio es en el presupuesto de líneas PCIe: EPYC Rome aporta 128 líneas PCIe 4.0 desde la CPU, que es la razón por la que se pueden montar cuatro GPU a x16 completo en esta plataforma sin compartir líneas ni recurrir a la bifurcación. La RTX 4090 es un dispositivo PCIe 4.0 x16; hacen falta cuatro ranuras x16 completas, y EPYC las da. Consulte W02 para el detalle de la topología de líneas.

RAM. El sistema se entregó con 512 GB de DDR4 ECC LRDIMM, por encima de los 256 GB especificados inicialmente. La RAM de sistema adicional resulta realmente útil aquí: la carga del modelo desde el NVMe se hace por etapas a través de la RAM del sistema antes de transferirlo a la VRAM y, con modelos más grandes o al alternar entre modelos, 512 GB significan que puede mantener varios conjuntos de pesos en RAM a la vez y evitar lecturas repetidas del NVMe.

NVMe. El almacenamiento de modelos (2 TB) está en una unidad NVMe PCIe 4.0 de alta velocidad. La velocidad de lectura secuencial importa en el momento de la carga: un archivo de modelo de 38 GB a 4,589 MB/s de lectura secuencial se carga en unos 8–10 segundos. Los tiempos de carga medidos lo confirman: llama.cpp cargó el GGUF Q4_K_M de 70B en 10.8 segundos; vLLM (que además construye grafos CUDA al cargar) tardó 95 segundos.

Fuente de alimentación doble. El chasis utiliza dos fuentes de alimentación ATX. Se trata de un suministro repartido: cada fuente alimenta una parte del sistema, normalmente dos GPU y los componentes de placa asociados. Si falla una fuente, se pierden las GPU de su raíl. Esto no es redundancia N+1; es un reparto de capacidad eléctrica, no un mecanismo de conmutación ante fallos. En sistemas de producción en los que la disponibilidad es contractual, la distinción importa. Consulte W04 para la discusión completa sobre el dimensionado de la fuente de alimentación.

Flujo de aire del chasis. El chasis es de montaje en rack con flujo de aire industrial dirigido de delante hacia atrás. Las GPU no están al aire libre; se sitúan en un canal de aire dirigido, con ventiladores de caja que empujan el aire a través de los disipadores y lo expulsan por la parte trasera. Esto hace que el sistema sea apto para funcionamiento sostenido 24/7 en un entorno de rack. Consulte W05 para el detalle del diseño térmico.

Pila de software

El entorno de Python reside en /home/logic/llm-env/, y los modelos en el NVMe en /mnt/nvme/models/.

Resultados de la puesta en marcha

Referencia de cómputo de GPU

La primera prueba es siempre el cómputo puro: multiplicación de matrices en FP16 (ruta Tensor Core) y FP32. Esto confirma que las tarjetas funcionan correctamente y da una referencia de cómputo con la que comparar las especificaciones nominales.

Como referencia: el pico teórico FP16 en Tensor Core de la RTX 4090 es de ~330 TFLOPS y el FP32 de ~82.6 TFLOPS. Las cifras de la prueba, en torno al 52 % del pico FP16, son las esperables: la medición es un matmul de rendimiento sostenido que no alcanza el pico teórico de un kernel GEMM optimizado a mano. Confirman que los cuatro arrays de Tensor Core funcionan y son consistentes.

La GPU 1 rinde un ~6 % menos en FP16 que las demás. Es la variación normal del silicio dentro del mismo lote. No hay fallo de hardware.

Ancho de banda de memoria de GPU

El ancho de banda de VRAM de 920 GB/s está en línea con la especificación de la RTX 4090 (1,008 GB/s de pico; la diferencia es sobrecarga de la prueba). Esta cifra de ancho de banda es la que importa para el rendimiento de decodificación: cada token generado exige cargar desde la VRAM el conjunto completo de la caché KV y los tensores de pesos, de modo que el ancho de banda fija directamente el techo de velocidad de generación.

La cifra de GPU a GPU (19–22 GB/s por PCIe peer-to-peer) es la restricción arquitectónica relevante para el servicio con paralelismo de tensores. Con NVLink, esta ruta alcanza 900 GB/s. Solo con PCIe se obtiene aproximadamente el 2 % de eso. No es catastrófico para la inferencia —la mayor parte de la comunicación con paralelismo de tensores de un modelo 70B AWQ INT4 repartido entre 4 GPU cabe dentro de lo que PCIe puede manejar—, pero sí reduce la velocidad de decodificación en peticiones individuales frente a un sistema conectado por NVLink. Vea la sección de pruebas más abajo y N03 para la discusión más amplia.

Una anomalía: el ancho de banda de dispositivo a host se midió en 1.4 GB/s, muy por debajo de los ~26 GB/s esperables en PCIe Gen4 x16. Es un comportamiento conocido de CUDA con memoria no anclada. Si su aplicación mueve datos de la GPU al host con frecuencia (por ejemplo, muestreo a partir de los logits de salida en una canalización propia), utilice torch.pin_memory() o reserve búferes anclados de antemano. Las canalizaciones de servicio estándar de vLLM y llama.cpp no activan esta ruta en el bucle crítico.

Todos los enlaces PCIe se confirmaron a Gen4 x16 (16 GT/s) bajo carga. En reposo, el controlador aplica el ahorro de energía ASPM y los enlaces bajan a Gen1 (2.5 GT/s): es normal y no indica un fallo de cableado ni de riser.

Almacenamiento NVMe

Son cifras sólidas de NVMe para una unidad PCIe 4.0 de gama de consumo/prosumidor. Para el servicio de modelos, el número relevante es la lectura secuencial: 4,589 MB/s significan que un modelo de 38 GB se carga en RAM en aproximadamente 8–9 segundos antes de cualquier transferencia a VRAM. Los 568K IOPS aleatorios son más relevantes si ejecuta una canalización de recuperación (RAG, almacén vectorial) en la que la carga de trabajo son muchas lecturas aleatorias pequeñas: esta unidad lo soporta sin convertirse en el cuello de botella.

Inferencia con vLLM — Llama 3.3 70B AWQ INT4

Esta es la prueba central. Modelo: casperhansen/llama-3.3-70b-instruct-awq. Servicio: vLLM 0.19.0 con tensor_parallel_size=4, max_model_len=2048, gpu_memory_utilization=0.80.

La velocidad de decodificación de 8.0 tok/s en petición individual necesita contexto. vLLM 0.19.0 ejecutó el modelo AWQ con el kernel awq , no con awq_marlin. El kernel awq_marlin es la ruta más rápida para AWQ en GPU Ada Lovelace (RTX 4090) y Blackwell: las notas de la prueba indican que no se seleccionó durante esta puesta en marcha, y se espera que la mejora sea de 2–3× en la velocidad de decodificación de peticiones individuales. Con awq_marlin, el mismo modelo sobre el mismo hardware debería alcanzar aproximadamente 16–24 tok/s en flujo único.

Los 179.3 tok/s agregados con 32 peticiones simultáneas son la cifra más relevante para producción. Es lo que verá como salida combinada del sistema un equipo pequeño que ataque el endpoint a la vez. El batching continuo de vLLM hace que las peticiones simultáneas amorticen la caché KV y el cálculo de atención en todo el lote, y por eso 32× usuarios no producen 32× latencia.

Los 2,043 ms de latencia en una petición de 16 tokens son el suelo de TTFT (tiempo hasta el primer token) con vLLM en esta configuración. Para casos de uso interactivos (chat, asistencia de código), es un valor más bien lento. El factor principal es la sobrecarga de scatter/gather del paralelismo de tensores entre cuatro GPU por PCIe: cada paso de prefill exige un AllReduce entre las cuatro tarjetas a través del bus PCIe. Con NVLink serían unos 50–100 ms de TTFT; con PCIe P2P a 20 GB/s se alarga más. Este es el coste directo de la arquitectura sin NVLink en peticiones individuales sensibles a la latencia (vea N03).

llama.cpp — Llama 3.3 70B Q4_K_M GGUF

Modelo: Llama-3.3-70B-Instruct-Q4_K_M.gguf. Backend: llama-cpp-python 0.3.20 con CUDA/cuBLAS, todas las capas descargadas en la GPU.

llama.cpp ofrece unos 20 tok/s en decodificación de flujo único, mejor que la cifra actual de vLLM con AWQ, y se explica porque la ruta de kernel basada en cuBLAS de llama.cpp funciona bien con la cuantización Q4_K_M. llama.cpp no admite el batching simultáneo de varias peticiones como lo hace vLLM, así que esos 20 tok/s son un techo por sesión, no capacidad agregada. Para flujos de trabajo interactivos de un solo usuario, llama.cpp a 20 tok/s es una velocidad de lectura cómoda para salida en inglés.

La velocidad de procesamiento del prompt de 1,568 tok/s es alta. Mide la rapidez con la que el modelo ingiere el prompt (fase de prefill). Un prefill rápido importa cuando se ejecuta un modelo con prompts de sistema largos o con contexto documental. A 1,568 tok/s, un contexto de documento de 4,000 tokens se procesa en menos de 3 segundos antes de que empiece la generación.

Para la economía y la comparación con las alternativas en la nube, consulte T01 (tok/s por euro) y T02 (coste por millón de tokens en local frente a la nube).

Para qué sirve cada uno de los dos motores

Prueba de estrés — Carga sostenida

Se ejecutaron tres pruebas de estrés de 60 segundos para verificar la estabilidad térmica y eléctrica a carga máxima: burn solo de GPU, burn solo de CPU y burn combinado de GPU+CPU.

Burn de GPU (multiplicación de matrices FP16 al 100 %, 60 s)

Cero errores de cálculo en las cuatro GPU. Las temperaturas subieron desde una base de ~28°C hasta una meseta estable hacia el segundo 40. La GPU 2 fue la que más calentó, a 72°C: es la tarjeta más caliente del canal de aire del chasis en esa posición. El umbral de limitación térmica de la RTX 4090 es de 83°C; la temperatura máxima medida (72°C) deja un margen de 11°C. El sistema no limitó el rendimiento en ningún momento.

Los límites de potencia estaban fijados en valores distintos en las cuatro tarjetas (480 W, 450 W, 500 W, 480 W). Es una inconsistencia menor que conviene normalizar: nvidia-smi -pl 480 -i 0,1,2,3 (o el límite que corresponda) para fijar topes consistentes antes del uso en producción.

Burn combinado de GPU + CPU (las 4 GPU + 64 hilos de CPU a la vez, 60 s)

Añadir 64 hilos de CPU al 100 % de carga redujo los TFLOPS agregados de las GPU solo un 0.6 %. El EPYC 7542 consume unos 200 W de TDP a plena carga; el sistema combinado funcionaba a aproximadamente 2.1–2.2 kW en total. Todas las temperaturas se mantuvieron dentro del margen: la GPU 2 alcanzó un máximo de 73°C bajo carga combinada, todavía 10°C por debajo del umbral de limitación.

La carga media llegó a 55+ durante la fase de burn de CPU (lo esperable con 64 hilos). El sistema se mantuvo totalmente estable en todo momento; sin incidencias térmicas, sin errores de cálculo y sin kernel panics.

Esto confirma que el sistema es apto para cargas de trabajo de inferencia sostenidas 24/7 en las que la CPU también está ocupada (preprocesado, tokenización, sobrecarga de la infraestructura de servicio).

Lo que funcionó bien

La plataforma EPYC. El presupuesto de líneas PCIe queda realmente resuelto. Las cuatro tarjetas RTX 4090 funcionan a Gen4 x16 completo bajo carga (confirmado en el apartado 04d , comprobación del estado PCIe). Sin bifurcación ni ranuras degradadas. Algunos montajes con AMD Ryzen y cuatro GPU dejan dos o más ranuras a x8; en EPYC Rome no ocurre.

RAM. 512 GB son holgados. Durante la carga del modelo en llama.cpp, el archivo GGUF de 38 GB se mapea en memoria; disponer de 512 GB significa que puede ejecutar varios procesos junto al servidor LLM sin competir por la memoria.

Velocidad secuencial del NVMe. 4,589 MB/s de lectura secuencial mantienen cortos los tiempos de carga. En un flujo de trabajo de iteración de modelos —cargar, probar, cambiar de modelo— esto suma a lo largo del día.

Comportamiento térmico. Temperatura sostenida en el peor caso de 73°C (GPU 2, burn combinado) con 10°C de margen. En una carga de inferencia típica, las GPU no funcionarán al 100 % de utilización de forma continua —la decodificación está limitada por el ancho de banda de VRAM, no por el cómputo—, así que las temperaturas reales de operación serán más bajas que el pico de la prueba de estrés.

Evaluación de prompt a 1,568 tok/s en llama.cpp. Esta cifra nos sorprendió para bien. La ruta de prefill con cuBLAS sobre cuatro 4090 es rápida. Las aplicaciones de contexto largo se benefician de ello.

Lo que nos sorprendió

El kernel AWQ equivocado en vLLM. La prueba se ejecutó con el kernel awq en lugar de awq_marlin. La suite de puesta en marcha lo seleccionó automáticamente a partir de la configuración del modelo en ese momento. Con awq_marlin, se espera que el rendimiento en peticiones individuales salte de 8 tok/s a 16–24 tok/s. Es una corrección de configuración de software, no una limitación de hardware: verifique la cadena del método de cuantización de vLLM al preparar el servicio en producción.

Ancho de banda D2H. El dispositivo a host a 1.4 GB/s nos pilló por sorpresa en el análisis inicial. Es un comportamiento de CUDA con memoria no anclada, no un fallo de PCIe. Para las pilas de servicio estándar (vLLM, llama.cpp) no importa. Para código de inferencia propio que mueva tensores a la CPU para posprocesado, utilice asignaciones de memoria anclada.

Errores PCIe AER corregidos en la GPU 3. Durante la prueba de vLLM, la GPU 3 (bus c1:00.0) registró errores PCIe corregidos (RxErr + BadTLP). Se corrigieron automáticamente por hardware y no afectaron al cálculo. Causa probable: el asiento del riser PCIe o una renegociación del enlace a velocidad Gen4. La recomendación es monitorizar bajo carga de producción sostenida; si el recuento de errores aumenta, vuelva a asentar el cable riser de la GPU 3. Cero errores durante las propias pruebas de estrés.

Breve caída del enlace de la NIC. La interfaz de red se cayó brevemente y volvió durante la carga de la prueba de GPU (13:38 UTC). Probablemente un transitorio de potencia por el arranque simultáneo de las GPU. En producción, con nvidia-persistenced en ejecución (que mantiene inicializados los contextos de GPU), los transitorios de potencia al inicio de carga son menores. Active nvidia-persistenced como servicio de systemd antes de pasar a producción.

Qué haríamos de otra forma en la v2

Active awq_marlin desde el principio. Verifique la ruta del kernel de cuantización de vLLM durante la puesta en marcha, no después. Añada una comprobación de identidad del kernel al script de puesta en marcha.

Normalice los límites de potencia de las GPU antes de las pruebas. Las cuatro tarjetas se entregaron con límites configurados distintos (480 W, 450 W, 500 W, 480 W). Fijar un límite consistente (nvidia-smi -pl) antes de la primera prueba da cifras más limpias y comparables, y evita el consumo irregular durante el burn combinado.

Incluya una pila de monitorización en la entrega. Prometheus con el exportador DCGM, más Grafana, se monta en unas horas y hace visibles en tiempo real la temperatura de las GPU, el uso de VRAM y las tasas de error de PCIe. Entréguelo como parte de la puesta en marcha estándar en lugar de dejarlo como tarea posterior a la entrega. Consulte L05 para la guía de montaje de la pila.

Fije nvidia-persistenced en el archivo de unidad de systemd durante la instalación del sistema operativo. Es una sola línea, pero se olvida sistemáticamente. Sin ella, la primera carga de GPU tras un periodo de inactividad tarda unos segundos de más y genera el transitorio de potencia que provocó la caída de la NIC.

Ampliación del LVM. El disco del sistema (SATA de 512 GB) tiene solo 100 GB asignados a la partición LVM. Los 374 GB restantes están sin asignar. No hay razón para dejarlo así: lvextend y resize2fs tardan 30 segundos y le devuelven ese espacio para la sobrecarga del sistema, los registros y las capas de Docker.

Valore un segundo NVMe para el almacenamiento de modelos. El único NVMe de 2 TB aloja hoy todos los modelos y se llenará a medida que crezca la biblioteca. Un segundo NVMe de 4 TB en RAID 0 o simplemente como punto de montaje /mnt/nvme2 independiente añadiría flexibilidad y mantendría alto el rendimiento de lectura secuencial en una biblioteca total mayor.

Comparativa: alternativas a este montaje

La carga de trabajo del cliente se podría haber abordado con otro hardware. Esta es una comparación honesta:

Las 4× RTX 4090 con 96 GB son la configuración mínima viable para ejecutar Llama 3.3 70B AWQ INT4 bajo vLLM con un rendimiento por lotes apreciable. No es el techo: un montaje de 8 GPU añade capacidad de forma proporcional. Para un cliente de investigación que quiere una única estación de trabajo dedicada —no un clúster de servicio—, 4× suele ser el punto de partida adecuado.

Ni la configuración de 4× ni la de 8× tienen NVLink entre GPU, lo que significa que la inferencia con paralelismo de tensores opera sobre PCIe. La consecuencia práctica está en la latencia TTFT de las peticiones individuales, no en el rendimiento agregado por lotes. Para una carga de trabajo de tamaño de equipo (decenas de peticiones por hora, no miles), esto no es un factor limitante. Para requisitos de TTFT por debajo de 100 ms, consulte N03 y el razonamiento sobre por qué la gama apunta a multi-GPU conectadas por PCIe en lugar de sistemas con fabric NVSwitch.

Potencia total y planificación eléctrica

Bajo carga de GPU sostenida, la potencia total del sistema fue de aproximadamente 1,900–2,200 W medidos en los raíles de GPU (1,914 W en el burn solo de GPU; ~2,100 W estimados en combinación con CPU, unidades y placa). Tenga en cuenta las pérdidas de eficiencia de la fuente (suponga un 90 %) y planifique un circuito mínimo de 16 A/230 V, preferiblemente de 20 A para tener margen.

La disposición de doble fuente reparte esto entre dos tomas. Ambas tomas deben estar en circuitos capaces de soportar la carga de forma independiente: si la fuente A alimenta dos GPU a 500 W cada una más 200 W de placa/CPU, eso son 1,200 W en su circuito. Dimensione en consecuencia.

Presupuesto de refrigeración de la sala: trate este sistema como 2.5 kW sostenidos (es conservador e incluye pérdidas de eficiencia y un margen). En una sala de servidores o un armario rack con varios sistemas, la cifra agregada se acumula rápido.

Consulte P01 para las consideraciones de monofásico frente a trifásico y P04 para el dimensionado del magnetotérmico.

Horquilla de precios

Un montaje con esta especificación —plataforma EPYC 7542, 512 GB de RAM ECC, 4× RTX 4090, NVMe de 2 TB, chasis de rack con doble fuente— se sitúa en la horquilla de 18,000–24,000 € sin IVA a precios actuales de componentes, según la elección del chasis, el momento de aprovisionamiento de la RAM y la disponibilidad de GPU. El plazo de entrega es de 10–28 días según la disponibilidad de componentes, y se confirma en el pedido.

Esta horquilla no incluye la instalación, la PDU de rack, la red (switch 10 GbE, cableado) ni ninguna licencia de software. El sistema se entrega con Ubuntu 24.04 LTS preinstalado y el entorno virtual de Python preconfigurado; los pesos de los modelos los aporta usted.

Para qué es adecuado este montaje

• Inferencia LLM para investigación y equipos pequeños. Ejecutar un modelo de 70B para un equipo de 5–15 usuarios. Los 179 tok/s agregados bajo vLLM gestionan las sesiones simultáneas con holgura.
• Evaluación e iteración de modelos. Los tiempos de carga rápidos del NVMe hacen que alternar entre modelos candidatos sea ágil. El presupuesto de líneas PCIe de la plataforma EPYC hace que las cuatro GPU estén siempre a pleno ancho de banda.
• Despliegues con soberanía del dato. Toda la inferencia es local. Ningún token sale del edificio. Es la principal razón no económica para trabajar en local en contextos de investigación.
• Punto de entrada a 70B ajustado al presupuesto. La RTX 4090 es la GPU de consumo con más VRAM disponible. Con 24 GB por tarjeta y cuatro tarjetas, los 96 GB totales le llevan a la clase 70B sin pasar a los precios de las GPU profesionales.

Para qué no es adecuado este montaje

• TTFT por debajo de 100 ms en peticiones individuales. La topología de paralelismo de tensores sobre PCIe P2P impone un suelo al TTFT en modelos grandes. Si necesita una latencia interactiva rápida en modelos de 70B o más, esta arquitectura no es la elección adecuada. Lo que necesita son GPU conectadas por NVLink, lo que supone una clase de hardware completamente distinta (vea N03).
• Ejecutar varios modelos grandes a la vez. Con 96 GB de VRAM total y gpu_memory_utilization=0.80, dispone de unos 77 GB utilizables. Un segundo modelo de 70B INT4 no cabría. Si necesita alojar dos modelos a la vez, pase a una plataforma con más VRAM por GPU o con más GPU.
• Servicio en producción a gran escala. Para cientos de usuarios simultáneos o disponibilidad respaldada por un SLA, esta arquitectura (sin NIC adicionales en un chasis de 4 GPU, nodo único, GPU de consumo con ECC desactivado) no es la base adecuada. Sí lo es el servidor Kentino AI de 8 GPU con L40 o RTX Pro 6000 Blackwell, monitorización adecuada y doble NIC.
• Entrenar modelos grandes. Con 96 GB de VRAM total puede hacer ajuste fino (LoRA, QLoRA) sobre modelos de 70B, pero no entrenarlos con todos los parámetros. En entrenamiento, el presupuesto de VRAM es más ajustado que en inferencia. Si el entrenamiento forma parte del plan de carga de trabajo, téngalo en cuenta.

---

Esto forma parte de la Kentino Wiki, serie C (casos prácticos). Datos del montaje medidos el 2026-04-10. Artículo publicado el 2026-05-15. Las correcciones y mediciones de seguimiento son bienvenidas en info@kentino.com.