Hardware para CFD en 2026: el panorama ha cambiado
Hace cinco años, la respuesta a «¿qué ordenador necesito para CFD?» era simple: cuantos más núcleos de CPU y cuanta más RAM, mejor. Las GPUs eran irrelevantes para la mayoría de solvers. Hoy, en 2026, el panorama es radicalmente distinto. La aceleración por GPU ha pasado de ser una promesa a una realidad de producción: OpenFOAM tiene backends CUDA y ROCm funcionales, ANSYS Fluent GPU solver es competitivo, y cada vez más herramientas de pre y post-procesado aprovechan la GPU. Elegir mal el hardware ya no significa solo simulaciones lentas: significa software que directamente no corre en tu máquina. Esta guía cubre todos los componentes que importan.
CPU: núcleos, frecuencia y la elección entre Intel y AMD
La CPU sigue siendo el corazón de cualquier estación de CFD. La mayoría de solvers — OpenFOAM con simpleFoam/pimpleFoam, SU2, Code_Saturne — escalan bien con el número de núcleos gracias a la descomposición de dominio por MPI (Message Passing Interface). Pero hay un matiz importante: el escalado no es lineal. Añadir el doble de núcleos no reduce el tiempo a la mitad porque las comunicaciones MPI introducen overhead y porque el ancho de banda de memoria compartida se satura cuando demasiados cores compiten por los mismos canales de RAM.
En 2026, la batalla está entre AMD Ryzen Threadripper 8000 / EPYC 9005 y los Intel Xeon W-3500 / Core Ultra 300. La arquitectura Zen 5 de AMD ofrece más núcleos por euro en el rango de 32-64 núcleos, mientras que Intel mantiene ventaja en frecuencia de reloj por núcleo con sus P-cores de la arquitectura Redwood Cove+. Para CFD, la ventaja en frecuencia de Intel se traduce en mejor rendimiento en simulaciones con pocos núcleos y mallas pequeñas, pero AMD domina cuando la malla supera los 10 millones de celdas y puedes permitirte paralelizar agresivamente con MPI.
El punto dulce para el usuario prosumer está en 16-32 núcleos (mallas de 2 a 10 millones de celdas). A partir de 64 núcleos entras en territorio de estación de trabajo profesional, donde el coste por núcleo adicional empieza a decrecer y el cuello de botella se desplaza de la CPU a la memoria y el I/O. Más allá de 128 núcleos, la mayoría de solvers CFD no escalan eficientemente a menos que uses una malla de cientos de millones de celdas con descomposición jerárquica.
¿Importa la caché L3?
Sí, y mucho. La caché L3 es la memoria más rápida a la que accede la CPU, y en CFD, donde los bucles sobre celdas acceden repetidamente a coeficientes de matriz dispersa, una caché L3 generosa reduce drásticamente los fallos de caché. Los AMD con 3D V-Cache (hasta 384 MB de L3 en Threadripper 8000X3D) pueden ofrecer mejoras del 20-30% en simulaciones CFD sobre el mismo chip sin V-Cache adicional, porque los datos de la malla que se reutilizan en cada iteración del solver lineal permanecen en caché. Intel contrarresta con cachés L2 más grandes por P-core (4 MB por core en Xeon W-3500), lo que beneficia cargas de trabajo con alto paralelismo local. Si tu solver está limitado por ancho de banda de memoria — y la mayoría lo están — la V-Cache de AMD es una ventaja real y medible.
RAM: 128 GB es la nueva referencia para trabajo serio
La regla de oro para estimar RAM en CFD es simple: entre 2 y 4 GB de RAM por cada millón de celdas de la malla, dependiendo de si el solver resuelve una ecuación (Spalart-Allmaras) o siete (RANS acoplado con 5 especies químicas). Una malla de 10 millones de celdas puede consumir entre 20 GB (SA, simpleFoam) y 60 GB (combustión con especies, reactingFoam). Y ese número se multiplica si necesitas mantener varios casos en RAM simultáneamente para comparar resultados o si usas descomposición de dominio con copias redundantes.
En 2026, DDR5 es el estándar y la diferencia con DDR4 es sustancial: duplica el ancho de banda máximo teórico (de 25.6 GB/s por módulo a más de 50 GB/s) y permite módulos de mayor densidad (hasta 128 GB por DIMM en configuraciones RDIMM para servidores). Para CFD, el ancho de banda es a menudo más crítico que la latencia: los solvers iterativos recorren millones de celdas en cada paso temporal, y cada acceso a memoria que no está en caché penaliza directamente el tiempo de pared. Una operación de producto matriz-vector disperso — el núcleo de cualquier solver CFD implícito — puede generar más de 100 GB de tráfico de memoria por iteración en una malla de 10 millones de celdas.
El mínimo recomendable en 2026 es 64 GB (DDR5-6000 o superior). La configuración cómoda son 128 GB. Para uso profesional, 256 GB o más. Si trabajas con LES en mallas de más de 50 millones de celdas, 512 GB no es una exageración, es una necesidad. Y recuerda poblar todos los canales de memoria de la placa: un Threadripper con 8 canales DDR5 rinde mucho más con 8 módulos de 16 GB que con 2 módulos de 64 GB, porque el ancho de banda efectivo escala con el número de canales poblados.
# Comprobar la configuración de RAM en Linux
sudo dmidecode -t memory | grep -E "Size|Speed|Type"
# Ejemplo de salida esperada:
# Size: 32 GB
# Speed: 6000 MT/s
# Type: DDR5
#
# Asegúrate de que todos los módulos funcionan a la misma velocidad
# y que el número de módulos coincide con los canales de la CPUAlmacenamiento: NVMe Gen5 y por qué los HDD están muertos para CFD
El almacenamiento es el componente que más se infravalora en una estación de CFD. Cada vez que tu solver escribe datos de campo para postprocesado — típicamente cada 100-500 iteraciones si has configurado un writeInterval razonable — el sistema vuelca gigabytes a disco. Si tu almacenamiento es lento, la simulación se detiene durante segundos o incluso minutos en cada escritura, acumulando horas perdidas en simulaciones largas. En CFD transitorio con paso temporal pequeño y escritura frecuente, el I/O puede representar el 20-30% del tiempo total de pared.
Los NVMe Gen5 (PCIe 5.0) alcanzan velocidades de lectura secuencial superiores a 12 GB/s y escritura superior a 10 GB/s — aproximadamente 20 veces más rápido que un SSD SATA y más de 200 veces más rápido que un HDD mecánico. Para CFD transitorio con escritura frecuente de campos, la diferencia entre NVMe Gen4 y Gen5 puede significar un 10-15% menos de tiempo total de simulación simplemente por la reducción del tiempo de I/O. Los discos duros mecánicos ya no tienen cabida ni siquiera como almacenamiento secundario: el tiempo de acceso aleatorio es tres órdenes de magnitud peor que un NVMe, lo que penaliza cualquier operación de postprocesado que lea archivos de resultados.
La configuración recomendada: un NVMe Gen5 de 1-2 TB para sistema operativo y casos activos (scratch data), y un segundo NVMe Gen4 de 2-4 TB para almacenamiento de resultados y casos archivados. Si trabajas en equipo, un NAS con 10 GbE como almacenamiento compartido para casos de referencia, pero nunca ejecutes simulaciones directamente desde el NAS: copia los casos al NVMe local, ejecuta, y copia los resultados de vuelta.
GPU: el factor diferencial en 2026
La GPU ha pasado de ser un accesorio a ser un componente central en CFD moderno. Pero no todas las simulaciones se benefician. El factor determinante es si tu solver tiene un backend GPU nativo — no basta con que el sistema tenga GPU, el software tiene que estar programado para usarla. Ejecutar un solver CPU en un sistema con una RTX 5090 no acelera nada.
En el ecosistema open-source, la GPU Foundation de OpenFOAM (desarrollada por AMD y el consorcio OpenFOAM) proporciona backends CUDA, ROCm y SYCL que aceleran la resolución de la matriz de presión, la parte más costosa computacionalmente de cualquier simulación incompresible. Las pruebas con la rama develop muestran aceleraciones de 2-4× para mallas de más de 5 millones de celdas comparando una GPU de gama media contra 16 núcleos de CPU en solvers segregados. ANSYS Fluent GPU Solver, más maduro, reporta aceleraciones de 5-8× en configuraciones multi-GPU para casos industriales validados.
El factor limitante real es la VRAM. A diferencia del gaming, donde 12-16 GB de VRAM es generoso, en CFD científico cada celda de la malla consume memoria en la GPU. Una malla de 10 millones de celdas con un solver segregado puede necesitar 8-12 GB de VRAM. Una malla de 50 millones con LES y múltiples especies puede requerir 40-60 GB. Si la malla no cabe en VRAM, la GPU simplemente no puede ejecutar el caso — no hay swapping a RAM del sistema como en CPU, y el fallo es catastrófico.
Para elegir GPU en 2026, estas son las opciones realistas:
- NVIDIA RTX 5080/5090 (24-32 GB VRAM): la opción prosumer. Suficiente VRAM para mallas de hasta ~30 millones de celdas en solver segregado. La arquitectura Blackwell duplica el rendimiento en FP64 respecto a Ada Lovelace, algo relevante para solvers que requieren doble precisión. La RTX 5090 (~2.000 €) ofrece el mejor rendimiento por euro en GPU CFD.
- NVIDIA RTX A-series (A6000 Ada, 48 GB): para mallas de 50-80 millones de celdas. VRAM ECC, soporte oficial de drivers empresariales, y garantía de funcionamiento 24/7. El precio (~5.000 €) se justifica cuando el tiempo de simulación es crítico y no puedes permitirte que un error de memoria no corregido corrompa un caso de 48 horas.
- NVIDIA H100 (80 GB VRAM HBM3): el estándar en clústeres HPC. Ancho de banda de memoria de 3.35 TB/s — aproximadamente 3× más que una RTX 5090. Para LES en mallas de más de 100 millones de celdas, la diferencia de ancho de banda es decisiva. Pero el precio (~25.000 €) y el consumo (~350-700 W) solo tienen sentido en entornos de clúster.
- AMD Radeon Pro W7900 (48 GB): alternativa viable gracias al backend ROCm de OpenFOAM. Menos ecosistema de software que NVIDIA (muchas herramientas de visualización solo soportan CUDA), pero el precio por GB de VRAM es mucho más competitivo.
Si tu solver no soporta GPU, una GPU modesta (RTX 4060, 12 GB) aún se justifica por el ahorro de tiempo en mallado con GPU (cfMesh, snappyHexMesh) y en postprocesado interactivo (Paraview con renderizado GPU). No necesitas una GPU de 2.000 € si no vas a ejecutar el solver en ella, pero sí necesitas al menos una GPU con 8-12 GB para trabajar con visualización de campos de forma fluida.
Cloud vs. on-premise: el punto de equilibrio
¿Compro una estación o alquilo horas en la nube? En 2026, la respuesta depende del volumen de simulación mensual. Las instancias HPC de AWS (hpc7g.16xlarge, 64 vCPUs Graviton4, ~$2.9/hora bajo demanda) ofrecen rendimiento competitivo sin inversión inicial. Azure HBv4 y Google Cloud C4A compiten en prestaciones similares. Pero los costes se acumulan: 40 horas semanales de simulación a ~$3/hora suman ~$6,000 al año — el precio de una estación de trabajo profesional de gama alta que durará 3-4 años.
La nube tiene sentido cuando necesitas picos de cómputo puntuales (una simulación grande al mes), quieres probar configuraciones antes de comprar hardware, o trabajas en un equipo distribuido geográficamente. El on-premise tiene sentido cuando simulas más de 20-25 horas semanales de media, manejas datos sensibles que no pueden salir de tus servidores, o necesitas latencia cero para iteraciones rápidas (mallar, simular, ajustar, repetir en bucle cerrado).
Una estrategia híbrida recomendable: estación prosumer (~5.000 €) para el 80% del trabajo diario (mallas de hasta 10 millones de celdas, simulaciones estacionarias), y burst a cloud para el 20% restante (LES transitorio, barridos paramétricos grandes, optimizaciones). Las instancias spot de AWS pueden reducir el coste en un 60-70% si tu simulación tolera interrupciones con checkpointing.
Presupuestos: tres configuraciones recomendadas para 2026
| Componente | Entrada (~2.000 €) | Prosumer (~5.000 €) | Profesional (~15.000 €) |
|---|---|---|---|
| CPU | AMD Ryzen 9 9900X (12C) | Threadripper 8960X (32C) | Threadripper 8985WX (64C) |
| RAM | 64 GB DDR5-6000 | 128 GB DDR5-6000 | 256 GB DDR5-6000 ECC |
| GPU | RTX 4060 Ti (16 GB) | RTX 5080 (24 GB) | RTX 6000 Ada (48 GB) |
| Almacenamiento | 1 TB NVMe Gen4 | 2 TB NVMe Gen5 + 2 TB Gen4 | 4 TB NVMe Gen5 + NAS 10 GbE |
| Malla máxima típica | ~5 M celdas | ~25 M celdas | ~80 M celdas |
Refrigeración: el componente silencioso que mata el rendimiento
Una simulación CFD grande satura todos los núcleos de CPU al 100% durante 12, 24 o 72 horas ininterrumpidas. Esto no es una carga de trabajo como el gaming, con picos y valles: es una carga térmica constante y brutal. Si la refrigeración no es adecuada, el sistema activa thermal throttling — reduce la frecuencia de reloj para proteger el silicio — y el rendimiento se desploma sin previo aviso. Un Threadripper 8960X con un TDP de 350 W necesita una solución de refrigeración líquida de al menos 360 mm de radiador para mantener las frecuencias de boost durante simulaciones prolongadas.
Olvídate del overclocking para CFD. La prioridad no es la frecuencia máxima, sino la frecuencia sostenida. Un perfil de BIOS conservador con voltajes controlados y límites de temperatura estrictos (máximo 85 °C) produce simulaciones más rápidas a largo plazo que un overclock agresivo que rinde durante las primeras dos horas y luego baja la frecuencia un 30% por calor. Monitoriza con s-tui o lm-sensors durante simulaciones reales para validar que tus temperaturas son estables en régimen permanente. Y recuerda: una GPU con thermal throttling rinde peor que una GPU de gama inferior correctamente refrigerada.
# Monitorizar temperatura y frecuencias durante simulación en Linux
watch -n 2 "sensors | grep -E 'Core|Package|edge'"
# O usar s-tui para monitorización gráfica por terminal
s-tuiChecklist: qué priorizar al montar tu estación de CFD
- RAM primero, siempre. Sin suficiente RAM, la simulación falla o swapea a disco (y entonces el tiempo se multiplica por 100). Calcula cuánta RAM necesitas para tu malla objetivo y añade un 50% de margen. La RAM es la única especificación que no puedes compensar con paciencia.
- Canales de memoria antes que velocidad de reloj. Una CPU con 8 canales DDR5 a 4800 MT/s rinde más en CFD que una con 2 canales a 7200 MT/s. El ancho de banda agregado es lo que cuenta. Puebla todos los canales.
- Núcleos de CPU según tu solver. Comprueba el escalado paralelo de tu solver específico: no todos escalan igual. La mayoría escala bien hasta 32-64 núcleos; más allá, el overhead MPI se come las ganancias. Consulta benchmarks públicos antes de invertir en más cores.
- GPU solo si tu solver la soporta nativamente. No compres una H100 si solo usas OpenFOAM con el backend CPU. Pero si usas ANSYS Fluent GPU o OpenFOAM con CUDA/ROCm, la GPU pasa a ser el componente más importante tras la RAM.
- NVMe Gen5 para scratch, no como lujo. El coste adicional sobre Gen4 es pequeño (~30%) y la mejora en tiempo de I/O se traduce directamente en menos tiempo de pared. Prioriza un Gen5 de 1 TB sobre un Gen4 más grande si el presupuesto está ajustado.
- Refrigeración dimensionada para carga sostenida. El TDP de la CPU es para carga máxima. En CFD, carga máxima es el estado permanente, no un pico. Dimensiona la refrigeración para el 120% del TDP nominal de todos los componentes.