¿Por Qué la Inferencia Satelital es Difícil?
La mayoría de los modelos de ML ingieren unos megabytes y devuelven un resultado en milisegundos. La inferencia de observación de la Tierra (EO) opera a una escala completamente diferente: un solo job de fine-tuning de un modelo de fundación puede mover terabytes de datos y correr por horas. Las entradas abarcan múltiples bandas espectrales, tipos de sensores y pasos temporales en grandes áreas geográficas. Vienen de proveedores diferentes con proyecciones y resoluciones variadas, y frecuentemente incluyen observaciones ausentes u oscurecidas por nubes. La salida es ella misma un mapa—cada predicción debe permanecer precisamente alineada con la misma cuadrícula de coordenadas que sus vecinas.
Incluso la adquisición de datos puede dominar el tiempo de ejecución. Los jobs de predicción a menudo pasan más tiempo descargando y preparando imágenes que corriendo el modelo en sí. Los pipelines eficientes deben manejar I/O de alto volumen mientras proporcionan compute para reproyección y remuestreo. Este es el desafío central que la Plataforma OlmoEarth fue construida para resolver.
Insight clave: Trata la ingeniería de datos como ciudadana de primera clase, no como una ocurrencia tardía. El modelo es solo una parte del pipeline.
La Arquitectura de Tres Etapas: Hardware Correcto para la Tarea Correcta
Como la adquisición y preparación de datos a menudo dominan el tiempo de ejecución, asignar ese trabajo a las GPUs desperdiciaría el hardware más caro. La plataforma divide cada job en tres etapas, cada una emparejada con un perfil de hardware distinto:
| Etapa | Hardware | Responsabilidad |
|---|---|---|
| Adquisición y preprocesamiento de datos | CPU, alto I/O | Obtener, reproyectar, alinear, normalizar imágenes; escribir en formato de carga rápida |
| Inferencia | GPU | Ejecutar forward pass del modelo; escribir salidas mínimamente procesadas al storage |
| Postprocesamiento | CPU | Unir salidas por ventana; aplicar máscaras/reescalado; exportar a Zarr, GeoTIFF, GeoJSON |
La plataforma distribuye estas etapas a través de muchas máquinas mientras mantiene las GPUs totalmente utilizadas. Data loaders multiproceso alimentan continuamente cada GPU, y las salidas completadas fluyen directamente al blob storage.
Una Requisición, Cientos de Workers, Miles de Procesos
OlmoEarth Run (la capa de ejecución) divide la región geográfica en particiones dimensionadas para instancias de compute individuales, luego subdivide esas particiones en ventanas más pequeñas procesadas independientemente. Particiones adyacentes se superponen ligeramente; la superposición se reconcilia durante el ensamblaje para que ninguna costura aparezca en el raster final.
Un área del tamaño de un estado puede convertirse en ~100 particiones; una ejecución a escala continental puede convertirse en miles. Como las particiones son independientes, la misma etapa puede correr en miles de instancias simultáneamente.
Números del mundo real: Un mapa de riesgo de incendio cubriendo toda América del Norte usó ~19,600 CPUs y 994 GPUs en paralelo, con throughput de red excediendo 168 GB/s. Esto redujo un estimado de 4,737 horas de compute serial a cerca de 30.5 horas de tiempo de pared—un speedup de 155×.
El fan-out no es ilimitado. Más workers presionan las cuotas de cloud, así que el paralelismo es un botón por ejecución. Otros trade-offs ajustables incluyen resolución de salida (volumen de datos vs. detalle), tamaño del modelo (tiempo de GPU vs. precisión) y caché de imágenes crudas (storage vs. velocidad en ejecuciones repetidas).
# Ejemplo: lógica conceptual de particionamiento (no es código real de OlmoEarth)
def partition_region(bbox, max_workers):
"""Divide una bounding box en particiones de área aproximadamente igual."""
# Simplificado: asume región cuadrada para ilustración
side = int(max_workers ** 0.5)
lat_step = (bbox['max_lat'] - bbox['min_lat']) / side
lon_step = (bbox['max_lon'] - bbox['min_lon']) / side
partitions = []
for i in range(side):
for j in range(side):
partitions.append({
'min_lat': bbox['min_lat'] + i * lat_step,
'max_lat': bbox['min_lat'] + (i + 1) * lat_step,
'min_lon': bbox['min_lon'] + j * lon_step,
'max_lon': bbox['min_lon'] + (j + 1) * lon_step,
})
return partitions
Tip pro: Al construir pipelines geoespaciales a gran escala, siempre diseña para idempotencia y reentrancia. Las fallas son la norma, no la excepción.
Encontrando y Obteniendo los Pixels Correctos (y Manejando Fallas)
Dada una región e intervalo de tiempo, la plataforma debe determinar qué escenas satelitales usar. Eso significa identificar qué fue capturado, dónde y cuándo, entre proveedores con catálogos, formatos y retrasos de publicación diferentes. Los criterios de selección dependen de la fuente: para imágenes ópticas como Sentinel-2, se prefieren escenas con menos nubes; para radar de apertura sintética, los canales de polarización pueden importar más.
La plataforma depende de catálogos STAC públicos y estándares abiertos donde sea posible. Pero un job grande puede generar miles de consultas de metadatos a la vez—mucho más de lo que servicios externos como las APIs STAC de la ESA o del Microsoft Planetary Computer fueron diseñados para manejar concurrentemente. Para evitar sobrecargar esos servicios, OlmoEarth mantiene su propio índice de metadatos, actualizado conforme se publican nuevas imágenes. Para datasets hospedados en AWS Open Data, notificaciones SNS disparan actualizaciones; de lo contrario, polling ocurre cada pocos minutos. Cada entrada del índice almacena metadatos de la escena y punteros a todos los lugares donde los pixels están disponibles. En tiempo de ejecución, la plataforma selecciona la mejor fuente y realiza lecturas en ventana contra formatos optimizados para cloud (COG, Zarr), recuperando solo los bytes necesarios para una partición dada.
Manejando Fallas a Escala
La plataforma está diseñada para recuperarse automáticamente. Cada tarea provisiona dinámicamente una VM corriendo un contenedor Docker que recupera parámetros, ejecuta el trabajo, devuelve resultados y se apaga. Como cada tarea es reentrante e idempotente, las fallas intermitentes se manejan de forma segura al reejecutar. El sistema distingue errores reintentables de fatales, hace fallback a proveedores alternativos cuando está disponible, y usa un proceso de monitoreo separado para detectar y reiniciar runners atascados.
Mejores prácticas para publicar datos EO (derivadas de proveedores que hicieron este workflow más fácil):
- Notificaciones basadas en cola cuando nuevas imágenes están disponibles
- Almacenamiento en grandes plataformas cloud sin límites de tasa bespoke
- Formatos optimizados para cloud que soportan lecturas ranged
Cuidado crítico: Esta arquitectura asume infraestructura cloud confiable y puede no ser viable para organizaciones con presupuestos limitados o restricciones on-premise. La plataforma se opera actualmente en Google Cloud, aunque el diseño soporta multi-cloud y despliegues on-prem.
Conclusión & Próximos Pasos
La Plataforma OlmoEarth de AI2 demuestra que operacionalizar modelos de fundación geoespaciales requiere tanto rigor de ingeniería como desarrollo de modelo. Las lecciones clave:
- Separa preocupaciones por perfil de hardware (CPU para I/O, GPU para inferencia) para maximizar utilización.
- Particiona agresivamente y diseña cada tarea para ser idempotente y reentrante.
- Mantén tu propio índice de metadatos para evitar sobrecargar APIs externas.
- Trata las fallas como esperadas y construye recuperación automática desde el día uno.
La plataforma actualmente corre inferencia a escala continental en ~1 día a fracciones de centavo por km². El roadmap incluye ejecuciones automatizadas de modelo, alertas de detección de cambio, herramientas agénticas, arquitecturas más rápidas, más modalidades (datos meteorológicos, nuevos sensores), embeddings a escala global y despliegue multi-cloud/on-prem.
Para equipos construyendo sistemas similares, la mayor lección es invertir en pipelines de datos temprano—dominarán tu tiempo de ejecución y tus costos. Empieza con una región pequeña, mide dónde se gasta el tiempo y optimiza el cuello de botella primero.
Lectura adicional:
- Cómo el Blog Oficial de Python Migró de Blogger a Git: Un Estudio de Caso en Infraestructura Open Source
- Cómo Meta Usa Optimización Bayesiana para Diseñar Mezclas de Concreto a Escala
Fuente: Post del blog OlmoEarth Platform