AI factory en México: qué infraestructura necesita tu cluster GPU antes del primer H100 que conectes

Un cluster GPU de 1\text{ MW} consume entre 3 y 5 veces más energía por rack que uno de CPU, exige refrigeración líquida en más del 80\% de sus racks y requiere una red de cero pérdidas. Perder 12\text{ horas} de entrenamiento por una falla cuesta entre 50,000\text{ y }300,000\text{ USD} en cómputo desperdiciado, más las penalizaciones de SLA.

Este artículo desglosa los 5 subsistemas críticos de una AI factory en México (power, cooling, red, storage y operación) y los 3 errores más comunes en producción.

Lo que un cluster GPU te pide diferente a un cluster CPU

La carga térmica, la densidad de red, y los patrones de uso son distintos. Lo que funciona para 200 racks de servidores de propósito general no funciona para 20 racks de GPU. Tres diferencias técnicas que tienes que entender antes de diseñar:

• Densidad de potencia: Un rack de CPU típico opera a 8\text{–}15\text{ kW}, mientras uno de GPU H100/B200 exige 40\text{–}80\text{ kW} (y hasta 130\text{ kW} en la siguiente generación). Esto redimensiona el diseño eléctrico, el cooling y el soporte estructural del piso falso.
• Perfil térmico: A diferencia de un CPU (150\text{–}300\text{ W} variables), un GPU H100 consume 700\text{ W} al 80\text{–}95\% de duty cycle sostenido por días. El cooling debe dimensionarse para el peor caso continuo, no para el promedio.
• Latencia de red: Entrenar en 256 GPUs exige comunicación peer-to-peer <5\,\mu\text{s}. Ethernet tradicional no alcanza; se requiere InfiniBand NDR/XDR o NVLink Switch System para evitar que un entrenamiento de 4 días se extienda a 4 semanas.

Los 5 subsistemas críticos (y qué dimensionar en cada uno)

1. Power: de la acometida al rack

Para un cluster GPU de 1 MW, lo que se necesita en el lado eléctrico:

• Acometida CFE: Media tensión con transformador dedicado y 1.2\text{–}1.5\text{ MVA} de capacidad contratada para absorber picos de arranque de 1\text{ MW} de carga IT.
• UPS de doble conversión: Dimensionado a 1.5\times la carga sostenida para absorber el ramp-up de los jobs, con 10\text{–}15\text{ minutos} de autonomía y baterías de litio (menor TCO a 7 años).
• Generador diésel: Autonomía mínima de 12\text{ horas} a plena carga (cumpliendo Uptime Tier III/IV y TIA-942), dimensionado al percentil 99 de pico y con pruebas mensuales con banco de carga para evitar wet stacking.
• PDU y redundancia: PDUs monitored + switched redundantes (2 por rack) y fuentes de poder redundantes en cada servidor.

2. Cooling: líquido, no aire

Por encima de 25 kW por rack, el aire deja de ser eficiente. Para clusters GPU típicos (40-80 kW por rack), el cold plate de direct liquid cooling sobre CPU+GPU+memoria es la única arquitectura viable. Tres decisiones de diseño:

• Closed-loop vs open-loop: en zonas con estrés hídrico (Querétaro, Monterrey, CDMX) closed-loop con dry cooler es obligatorio. En zonas frías con agua barata, open-loop con torre de enfriamiento puede ser más barato en CAPEX, pero el TCO a 7 años favorece closed-loop por el ahorro de agua.
• CDU redundancy: al menos 2 CDUs en N+1 por cluster, con capacidad cada una para sostener 100% de la carga IT del cluster en falla simple. Eso duplica el CAPEX en CDU pero elimina el SPOF que te puede tumbar un entrenamiento de 4 días.
• Temperatura de suministro: agua a 18-22°C en el lazo primario, con delta-T de 8-10°C. Más caliente reduce eficiencia del CDU, más fría desperdicia energía en el dry cooler.

3. Red: InfiniBand o nada para entrenamiento

La red del cluster GPU es el subsistema que más frecuentemente se subdimensiona, porque los brochures hablan de “InfiniBand NDR 400G” sin explicar que se necesitan 3 a 5 puertos por nodo para topologías all-to-all eficientes.

• Para 256 GPUs en 32 servidores (8 GPUs por servidor), la topología es típicamente fat-tree de 2 niveles con 32 spines y 32 leaves, o dragonfly+. Eso requiere 8 puertos NDR por servidor para la red de GPU y 2 puertos para la red de management.
• Para inferencia a escala (más de 1000 GPUs), la topología cambia a 3 niveles fat-tree, con mayor oversubscription entre tiers. Aquí la decisión entre InfiniBand y 800G Ethernet es más discutible; InfiniBand sigue ganando en latencia pero Ethernet es más barato y tiene mejor ecosistema para data center general.
• Para sitios donde la inferencia es el caso de uso dominante, un diseño híbrido (InfiniBand para entrenamiento + Ethernet 100G/200G para inferencia) puede cerrar mejor el TCO que un cluster todo-InfiniBand.

4. Storage: separado, rápido, y dimensionado para checkpoint

Un job de entrenamiento de LLM hace checkpoint cada 30 minutos a 2 horas. Para un modelo de 70B parámetros, cada checkpoint pesa entre 140 GB y 280 GB. Si el storage no es capaz de escribir el checkpoint en menos de 5 minutos, el job se cuelga esperando I/O y pierdes utilization de GPU.

• Storage de alta performance paralelo (Lustre, GPFS o BeeGFS) con throughput mínimo de 10 GB/s lectura y 5 GB/s escritura por servidor de GPU.
• Storage de capacidad separado (no en el mismo tier) para datasets y modelos guardados. Aquí se tolera menor performance a cambio de menor costo por TB.
• Backup del storage con política de retención definida y probada. Esto es compliance y disaster recovery, no performance. RPO y RTO del cluster se definen aquí, no en el lado de cómputo.

5. Operación: el factor humano que casi nadie dimensiona

Un cluster GPU requiere perfiles de operación distintos a un cluster CPU tradicional. El equipo que lo opera necesita entender scheduling de jobs (Slurm, Kubernetes con GPU operator), gestión de fallas de GPU (que son más frecuentes que fallas de CPU), y troubleshooting de la red InfiniBand. Si contratas a operadores de DC general, vas a tener 3 a 6 meses de aprendizaje con indisponibilidad durante ese proceso.

Los 3 errores más caros en AI factories en México

1. Dimensionar el cooling para el promedio, no para el peak sostenido. En entrenamiento de modelos grandes, el duty cycle de GPU es 90%+ durante horas. Si dimensionas el CDU y el dry cooler para 70% de carga promedio, el percentil 95 a 99% del job va a throttle. El job se hace 30% más lento y la factura de energía sube porque el sistema de cooling compensa con más bombeo. Dimensionar para el peak sostenido, no para el promedio.
2. Subestimar el impacto del aire exterior en el dry cooler. En Monterrey o Querétaro, una ola de calor de 3 días a 42°C de bulbo seco pone al dry cooler en su peor momento de capacidad. Si el dry cooler no está dimensionado para esos 3 días con margen, el cluster throttle o se apaga. La práctica correcta es dimensionar para el percentil 99.5 de temperatura exterior de los últimos 5 años, no para el promedio.
3. Olvidar que la red InfiniBand requiere personal certificado. La red de GPU es el subsistema con más fallas no detectadas en producción (cables dañados, switches con firmware desactualizado, problemas de routing en fat-tree). Sin personal que entienda la red, las fallas se diagnostican mal y se resuelven en horas, no en minutos. Esto es un costo de personal que típicamente no está en el CAPEX pero aparece en el OPEX desde el día 1.

El veredicto

Un AI factory en México no se diseña replicando lo que AWS o Microsoft hicieron en Virginia; se diseña entendiendo qué necesita realmente un job de entrenamiento, qué puede fallar en producción, y cuál es el costo real de la indisponibilidad. La infraestructura mínima para un cluster GPU competitivo en 2026 es: acometida dedicada, UPS con margen para picos, generador Tier III/IV, dry cooler con closed-loop, CDU redundante, InfiniBand NDR o 800G Ethernet, storage de alta performance para checkpoint, y un equipo de operación con experiencia específica en redes GPU. La inversión típicamente cierra financieramente para organizaciones que tienen demanda sostenida de entrenamiento o inferencia a escala; para uso esporádico, conviene un cluster en la nube, no propio.

Fuentes

1. NVIDIA — DGX SuperPOD Architecture Reference (cluster GPU design, networking, storage) — https://docs.nvidia.com/dgx-superpod/
2. ASHRAE TC 9.9 — Thermal Guidelines for Data Processing Environments (5th Edition, 2021, liquid cooling) — https://ashrae.org/technical-resources/ai-data-center-framework/energy-and-thermal-efficiency
3. InfiniBand Trade Association — InfiniBand Architecture Specification (NDR/XDR 400G/800G) — https://www.infinibandta.org/ibta-specification/
4. Uptime Institute — Data Center Site Infrastructure Tier Standard (Tier Classification System) — https://uptimeinstitute.com/resources/asset/tier-classification-system
5. TIA-942-B-2023 — Telecommunications Infrastructure Standard for Data Centers (high-density power and cooling) — https://tiaonline.org/standards/