AI infrastructure para data center: qué cambia en power, cooling y red cuando entrenas LLMs

Cuando un data center pasa de correr cargas de inferencia o workloads generales a entrenar modelos grandes de IA, las suposiciones de diseño que tenías dejan de funcionar. La densidad de rack se multiplica, los tiempos de carga útil cambian, y los picos de consumo se vuelven eventos recurrentes. Esto es lo que cambia operativamente — y lo que tienes que rediseñar si tu cliente te pide hospedar entrenamiento de LLMs.

Power: de 7 kW a 70 kW por rack

Un servidor tradicional de 1U consume 200-400W. Un servidor GPU de entrenamiento (NVIDIA H100 en configuración DGX) consume 5-10 kW por nodo y un rack lleno de ellos llega a 70-100 kW. Esa densidad requiere tres cambios: circuito dedicado de alta amperaje por rack, UPS dimensionado para la nueva carga pico, y generador con capacidad de respuesta ante la rampa de consumo del entrenamiento. El breaker de un rack de GPU denso debe ser 3-Phase 100A o más — muy distinto a los 30A típicos de racks convencionales.

Cooling: por qué el aire deja de funcionar

A 70 kW por rack, el sistema de aire convencional simplemente no mueve suficiente calor. La capacidad de extracción térmica de un CRAC unit típico es 20-30 kW por unidad. Para racks de GPU, necesitas dos rutas: (a) liquid cooling directo al chip (DLC) para los hotspots, donde el CDU lleva el calor al exterior; o (b) rear-door heat exchangers que complementan el enfriamiento por aire. La opción (a) tiene mayor capex inicial pero reduce el consumo del cooling 30-40%. La opción (b) es más barata pero requiere más espacio en el pasillo y no maneja picos tan eficientemente.

Red: de 10 GbE a 200+ GbE

El entrenamiento distribuido de LLMs requiere mover terabytes de gradientes entre GPUs en cada step de entrenamiento. Una red de 10 GbE convencional es el cuello de botella inmediato. Las opciones reales son: 100 GbE (InfiniBand HDR) o 200/400 GbE (NDR, Quantum-2). Esto no es un upgrade de switch — es una arquitectura de red completamente distinta con cabling de fibra óptica monomodo, switches de alta densidad, y una topología leaf-spine que minimice latencia. Migrar de 10 GbE a 200 GbE es típicamente un proyecto de 6-12 meses y $500k-2M MXN dependiendo del tamaño.

Los picos de consumo que nadie anticipa

Los workloads de entrenamiento tienen un patrón de consumo único: alto consumo durante el step de cómputo (forward + backward pass) y bajo consumo durante data loading y checkpointing. Eso significa que el data center ve oscilaciones de 30-50% del consumo total en ciclos de segundos. El UPS debe responder a esas oscilaciones sin transferir a batería (lo que degradaría las baterías rápidamente). El generador debe estar dimensionado para sostener el pico, no solo el promedio. Y el contrato con CFE debe contemplar la demanda máxima real, no el promedio — porque CFE cobra por demanda pico, no por consumo total.

El layout físico cambia

Los racks de GPU no se mezclan bien con racks de almacenamiento o de servidores generales. El calor y el ruido de los ventiladores de GPUs hacen que un pasillo mixto sea problemático para mantenimiento. La tendencia es separar físicamente: un 'AI cluster' en una zona del DC con su propio CDU/cooling, su propia red de alta velocidad, y su propio circuito de UPS. Esto permite operar la zona de IA con prácticas distintas (más alta densidad, diferente cadencia de mantenimiento) sin afectar al resto del DC.

El factor energético: dónde se concentra el consumo

En un cluster de entrenamiento típico, la distribución de energía se ve así: 65-75% en las GPUs, 8-12% en CPUs del host, 5-8% en memoria y SSD, 5-10% en networking (switches, transceivers ópticos), y el resto en cooling, PSU y pérdidas. Cuando optimizas para entrenamiento de IA, la GPU es tu mayor levier — pero también tu mayor fuente de calor. Por eso el cooling se vuelve el cuello de botella operativo: si no extraes el calor de las GPUs rápido, los throttling mechanisms bajan la frecuencia y tu step time se degrada.

Diferencia entre training e inference

Vale la pena reiterar la distinción porque los pitches comerciales la confunden. Training es el proceso de ajustar los pesos del modelo usando grandes datasets — consume mucho cómputo y energía, típicamente en ciclos de horas a semanas. Inference es usar un modelo ya entrenado para responder a prompts — consume mucho menos, típicamente milisegundos a segundos por respuesta. Un DC puede hospedar inference sin rediseñar (1-3 kW por servidor, compatible con la mayoría de arquitecturas). Training requiere el rediseño completo descrito en este artículo. Si tu cliente dice 'queremos hacer AI' y tiene un DC de 500 kW, pregúntale si quiere entrenar o solo correr inference. Las implicaciones técnicas y de inversión son completamente distintas.

Cuándo NO hospedar entrenamiento de LLM

Si tu DC actual no tiene al menos 2 MW de capacidad eléctrica disponible y 1 MW de cooling, el costo de habilitar el sitio para entrenamiento supera el de migrar el workload a un operador hyperscale. La inferencia de modelos entrenrados (inference) sí puede hospedarse en DCs medianos — consume 1-3 kW por servidor y es compatible con la mayoría de las arquitecturas actuales. Pero el training, no. Esa distinción es la que más se confunde en los pitches comerciales.

Recomendación práctica

Antes de firmar un contrato de hosting para entrenamiento de LLM, pide a tu proveedor tres documentos: (a) layout específico de la zona de IA con su CDU y su red dedicada; (b) capacidad eléctrica y de cooling disponible para esa zona, con picos declarados; (c) el histórico de capacidad y uptime del segmento, no del DC completo. Si el proveedor no puede entregar esos tres documentos, el proyecto no se ejecuta bien.

Fuentes

1. NVIDIA — HGX data center platform (GPU density reference) — https://www.nvidia.com/en-us/data-center/hgx/
2. Vertiv — homepage — https://www.vertiv.com/
3. Uptime Institute — AI infrastructure considerations (industry report) — https://uptimeinstitute.com/ai-services/ai-infrastructure-advisory
4. NVIDIA — DGX platform (training infrastructure) — https://www.nvidia.com/en-us/data-center/dgx-platform/