En infraestructura de IA, la electricidad dejó de ser un servicio invisible detrás de una API. Capacidad de red, densidad, cooling, carbono, agua, aceleradores y tiempos de interconexión determinan dónde corre el software y qué tan rápido escala.
La IEA estima unos 485 TWh consumidos por centros de datos en 2025 y proyecta cerca de 950 TWh en 2030, con instalaciones de IA creciendo más rápido. El Departamento de Energía de EE. UU. indica que la carga nacional podría duplicarse o triplicarse para 2028. Esto no significa priorizar carbono sobre fiabilidad; significa que capacity planning no puede asumir compute ilimitado en cualquier lugar.
Una región puede ofrecer APIs cloud y tener cuotas de aceleradores, interconexión eléctrica limitada, stress de red, restricciones de cooling o plazos largos. La arquitectura debe modelarlo antes de elegir active-active, frecuencia de retraining, geografía de inference o prometer elasticidad ilimitada.
Power Usage Effectiveness compara energía total con energía del equipo de TI. Ayuda a medir cooling e infraestructura, pero no revela si el compute produce trabajo útil, si la red es intensiva en carbono, cuánta agua usa ni el carbono de hardware infrautilizado. La encuesta 2025 de Uptime Institute muestra poco cambio del PUE medio por sexto año, ocultando variación por edad, tamaño, clima y región.
Software necesita un conjunto: PUE, Carbon Usage Effectiveness, Water Usage Effectiveness, utilización, Wh por request o job, intensidad temporal y geográfica, calidad y unidad funcional. Software Carbon Intensity de Green Software Foundation, ISO/IEC 21031:2024, organiza carbono operativo e incorporado por unidad funcional.
La computación más limpia suele ser la que no ocurre. Usa caché, deduplicación, batching, modelos menores, cuantización, retrieval antes de modelos grandes, límites de tokens, menos retries, mejor utilización y elimina réplicas idle. Esto reduce energía, coste y presión de capacidad.
Carbon-aware scheduling viene después de eficiencia y corrección. Mover un job a una región más limpia puede empeorar si duplica datasets, mantiene clusters calientes, aumenta red, reduce utilización o añade overhead de resiliencia. Calcula todo el límite del sistema.
| Workload | Restricciones rígidas | Flexibilidad útil | Arquitectura consciente de energía | Fallo a evitar |
|---|---|---|---|---|
| Inference interactiva | Latencia, disponibilidad, privacidad, calidad y capacidad regional. | Model tier, batching, caché, speculative execution y features opcionales. | Enruta primero por SLO; usa semantic cache, batching, fallback eficiente y límites de token. | Enviar usuarios a otro continente por carbono y aumentar latencia, retries y réplicas. |
| Batch inference | Deadline, residencia, modelo aprobado e inputs. | Horario, región, paralelismo, instancia y checkpoint. | Desplaza tiempo o región contabilizando datos; pausa en checkpoints cuando capacidad se restrinja. | Perder el plazo porque carbono se volvió objetivo rígido. |
| Entrenamiento | Topología, bandwidth, checkpoints, fault tolerance y reproducibilidad. | Ventana, cluster, precisión, batch size, curriculum y early stopping. | Maximiza utilización, usa ventanas de capacidad, checkpoint seguro y detén experimentos sin valor. | Optimizar PUE mientras GPUs esperan datos, sincronización o jobs fallidos. |
| Retraining y evaluación | Freshness, release gate, datos representativos y compliance. | Frecuencia, muestra, candidatos, tiempo y localización. | Dispara por drift significativo, reutiliza features y embeddings y evalúa por etapas. | Retrenar por calendario sin cambio material. |
| Pipelines de datos | Llegada, consistencia, SLA downstream y residencia. | Micro-batch, compactación, región y tier. | Reduce scans, particiona bien, compacta en ventanas favorables y acerca compute a datos. | Mover terabytes para ahorrar poco compute en otro lugar. |
| Backups y mantenimiento | RPO, RTO, durabilidad y retención. | Ventana, compresión, verificación y tier. | Programa trabajo flexible en periodos más limpios o menos restringidos sin romper recovery. | Posponer validación hasta hacer inútil el backup. |
| CI y desarrollo | Feedback crítico, reproducibilidad y seguridad. | Jobs opcionales, pruebas nocturnas, previews y runners. | Cachea dependencias, cancela builds superados, hiberna previews y desplaza suites exhaustivas. | Mantener todos los ambientes y runners acelerados encendidos. |
Carbon Aware SDK de Green Software Foundation permite desplazamiento temporal y geográfico según intensidad. Google Cloud y Microsoft recomiendan el patrón cuando los requisitos lo permiten. Carbono es una señal entre SLO, precio, cola, capacidad, datos, agua, seguridad y prioridad.
Usa forecasts con incertidumbre y fallback. El scheduler debe conocer último inicio posible, distancia máxima, budget de transferencia, regiones aprobadas, calidad mínima, coste de checkpoint y cuándo ignorar la señal. Datos stale no pueden abandonar producción.
Clientes cloud rara vez reciben joules directos por request. Usa proxies transparentes: segundos de acelerador, CPU, memoria, storage, red, utilización, informes del provider, métricas de instalación e intensidad regional. Declara incertidumbre.
Asocia budgets a productos y workloads. Reporta por unidad funcional: inference exitosa, mil documentos, training completado o cliente activo. Un total menor puede ocultar menor demanda; una unidad mejor puede ocultar rebound por volumen. Mide ambos.
Cuando energía o aceleradores escasean, el software necesita demand shaping: encolar jobs, bajar model tier, reducir contexto, pausar batch, rechazar experimentos, negociar deadlines o servir caché. Son contratos de producto y API.
Expón clases interactive, deadline batch, interruptible y best effort. Permite declarar calidad mínima, deadline, residencia y caché. El scheduler puede hacer tradeoffs legítimos.
Construiría un control plane de placement que conecte contratos con inventario de aceleradores, colas, coste, intensidad, PUE, agua, datos, benchmarks y fiabilidad. Optimizaría dentro de restricciones y registraría por qué decidió.
La vista mostraría trabajo útil por accelerator-hour, energía y emisiones con incertidumbre, caché, idle, restricciones regionales, riesgo de deadline, agua y efecto marginal de cambios.
Arquitectura consciente de energía no es “ejecutar todo en la región más verde”. Reduce demanda, preserva requisitos rígidos, expone flexibilidad, optimiza el sistema completo y mide energía frente a outcomes útiles. La electricidad se vuelve restricción arquitectónica cuando el software puede responder de forma segura.
Artículo sobre energía de data centers como restricción de arquitectura, incluyendo scheduling de IA, caché, model routing, placement regional, carbono, agua y capacidad.