Elegir una región para IA no es una decisión basada solo en latencia. La capacidad de la red eléctrica, el agua de refrigeración, los aceleradores disponibles, las rutas de red, las normas de datos y la recuperación determinan si una carga puede servirse con previsibilidad. La arquitectura debe ubicar cada tarea donde se cumplan sus restricciones y objetivos.
El análisis de 2026 de la IEA sobre Asia Oriental estudia cómo el crecimiento de centros de datos afecta la demanda eléctrica y la planificación de redes; su perspectiva de 2025 también destacó el crecimiento proyectado del Sudeste Asiático. Son escenarios, no garantías para un mercado o proveedor. Para ingeniería, el mensaje es verificar capacidad con proveedores y empresas eléctricas, no suponer que una región cloud anunciada tiene energía, agua o aceleradores ilimitados.
En un clúster de IA, la computación utilizable no equivale al número de aceleradores instalados. La entrega eléctrica, el margen térmico, la densidad de racks, el mantenimiento y los límites de red pueden reducir capacidad disponible. Pregunte qué está comprometido y qué es solo plan, cómo se reservan recursos y qué ocurre durante recortes o mantenimiento. En software, exponga cuotas y capacidad al scheduler, aplique admisión y permita interrupción o checkpoint de lotes cuando el framework lo admita.
Una afirmación regional de energía renovable no demuestra que cada carga use electricidad libre de carbono a toda hora. Si estimaciones de emisiones guían la ubicación, registre fuente, granularidad temporal, límite geográfico y método contable. Separe las afirmaciones comerciales de las mediciones operativas y su incertidumbre.
La refrigeración depende de la instalación y el clima. Las métricas de agua pueden tener límites y periodos distintos; un buen WUE no describe por sí solo el estrés hídrico local, la fuente de agua ni su disponibilidad estacional. Solicite datos de la instalación cuando existan y diferencie agua directa de refrigeración del agua asociada a la generación eléctrica. La eficiencia y flexibilidad pueden reducir presión, pero no sustituyen permisos locales ni consulta comunitaria.
La inferencia cercana al usuario puede reducir latencia de red, mientras el entrenamiento quizá necesite capacidad sostenida en otro sitio. Un failover puede incumplir residencia o no soportar el mismo modelo. Defina regiones elegibles por clase de datos antes de diseñar recuperación. Prompts, embeddings, checkpoints, logs y backups pueden tener sensibilidad y retención diferentes.
| Carga | Prioridad de ubicación | Control técnico |
|---|---|---|
| Inferencia interactiva | Latencia de cola, capacidad local, política de datos | Enrutamiento regional, cola acotada y respaldo probado. |
| Entrenamiento/ajuste | Capacidad sostenida, acceso a datos, energía | Checkpoints, interrupción y planificación de cuotas. |
| Embeddings/análisis batch | Coste, throughput, ubicación de datos | Ventanas flexibles, batching e idempotencia. |
| Control y auditoría | Disponibilidad, acceso administrativo y recuperación | Dominios de fallo separados y restauración probada. |
Modele elegibilidad como política: clase de datos, contrato, base regulatoria, nivel de servicio y recuperación. El servicio filtra límites obligatorios y optimiza entre pools elegibles por latencia, coste, capacidad y señales de sostenibilidad. Registre la razón de cada decisión. Si ninguna región cumple, falle claramente o aplace; no envíe datos de forma silenciosa a un sitio prohibido.
La abstracción entre proveedores debe ser práctica. Estandarice metadatos, health checks, reintentos y telemetría, pero conserve la compatibilidad específica de hardware y modelos. Una interfaz genérica que oculte límites puede crear portabilidad ficticia. Ensaye failover y verifique cuotas, identidad, secretos, imágenes y recuperación de datos en destino.
Mida solicitudes exitosas por kWh o por hora de acelerador cuando sea fiable, junto con calidad, p95/p99, coste, espera de cola, reintentos, cancelación y disponibilidad regional. Para agua y carbono, anote método y cobertura en vez de fingir precisión. Compare cargas equivalentes e incluya capacidad ociosa y fallos cuando el método lo permita.
Mantendría un catálogo con sensibilidad de datos, clase de latencia, aceleradores, checkpoints y objetivo de recuperación. Un registro regional guardaría capacidades probadas, cuotas, latencia observada, datos energéticos e hídricos publicados y elegibilidad. El scheduler elegiría solo regiones conformes; la telemetría mediría resultados. La incertidumbre de capacidad aparecería como rango y estado de reserva, no como cifra estática.
Ubicar centros de datos de IA en Asia es una decisión conjunta de infraestructura y software. Considere finitas la energía y refrigeración, local el contexto del agua, limitada la latencia como único objetivo y obligatorias las reglas de datos. Integre enrutamiento regional, cargas flexibles, observabilidad y recuperación probada. Un mapa de calor inicia el análisis, pero la evidencia de carga e infraestructura local debe decidir el despliegue.
Nota editorial: Capacidad regional, servicios y divulgaciones cambian. Este artículo propone un marco técnico, no un ranking ni una garantía sobre países o proveedores cloud.