OlmoEarth es una plataforma que lleva modelos de observación terrestre desde el experimento hasta la producción a escala continental y planetaria. ¿Suena a ciencia ficción? No lo es: ya se usa para mapas de riesgo de incendios, monitoreo de deforestación y seguridad alimentaria, y está pensada para equipos que no pueden mantener una gran infraestructura de ML por su cuenta.
Qué es la OlmoEarth Platform
Los modelos OlmoEarth son modelos fundamentales de observación de la Tierra, preentrenados con unos 10 terabytes de datos satelitales multimodales. Son modelos abiertos útiles, pero el valor real viene al integrarlos en un flujo de trabajo operativo: etiquetado, fine-tuning, evaluación y, sobre todo, inferencia masiva.
Ai2 ha aprovechado su experiencia operando plataformas como Skylight y EarthRanger para diseñar una infraestructura que responde a problemas reales: costos, latencia, consistencia geográfica y verificación de resultados. En pocas palabras, no basta con tener un buen modelo; hay que hacer que funcione todos los días para socios con recursos limitados.
Arquitectura y diseño de ejecución
OlmoEarth separa cada trabajo en tres etapas, emparejadas con el tipo de hardware más eficiente:
- Data acquisition y preprocessing (CPU, alto I/O): buscar, reproyectar, alinear y normalizar imágenes; escribirlas en formatos optimizados para carga rápida.
- Inference (GPU): ejecutar la pasada hacia adelante del modelo y volcar salidas mínimamente procesadas a almacenamiento.
- Postprocessing (CPU): ensamblar ventanas en mapas coherentes, aplicar máscaras y exportar a
Zarr,GeoTIFFoGeoJSON.
Esta separación evita que GPUs hagan trabajo que las CPUs resuelven mejor. Para mantener los GPUs ocupados, multiprocesos alimentan continuamente cada GPU y los resultados fluyen a almacenamiento en blob.
OlmoEarth Run: particiones y ventanas
El motor de ejecución, OlmoEarth Run, divide una región en particiones pensadas para instancias individuales y luego en ventanas procesables independientemente. ¿Por qué ventanas? Porque cada ventana es una pasada del modelo; si una parte falla, el resto sigue trabajando.
En un ejemplo real, una corrida continental usada para generar un mapa de riesgo de incendios en Norteamérica llegó a 19,600 CPUs y 994 GPUs en paralelo, con 168 GB/s de throughput. Eso redujo unas 4,737 horas de cómputo serial a 30.5 horas de tiempo de reloj, un aceleramiento de 155×.
Pero ojo: el fan-out tiene límites. Las cuotas de nube, el presupuesto y el tamaño de modelo condicionan cuánto paralelismo puedes desplegar. Elegir resolución, tamaño de modelo y políticas de caché es una decisión de producto y costo.
Índices, datos y acceso eficiente
Uno de los cuellos de botella clásicos en geoespacial es simplemente conseguir y preparar la imagen. OlmoEarth resuelve esto con su propio índice de metadatos que se actualiza cuando aparecen nuevas escenas. Para datasets en AWS Open Data, reciben notificaciones SNS; cuando no hay stream, pollean índices upstream cada pocos minutos.
El índice guarda metadatos y punteros a todas las ubicaciones de píxeles. En tiempo de ejecución, la plataforma hace lecturas en ventanas sobre formatos optimizados como COG o Zarr, trayendo solo los bytes necesarios en vez de descargar escenas completas. Esto reduce I/O y acelera el preprocesamiento.
Buenas prácticas para publicar datos de observación terrestre: notificaciones de nueva imagen, almacenamiento en clouds principales sin limits extraños, y formatos cloud-optimizados que permitan ranged reads.
El índice también alimenta herramientas de anotación: puedes servir mosaicos de Sentinel-1, Sentinel-2, Landsat o NISAR mediante el mismo sistema de lecturas por ventana sin una canalización de ingestión separada.
Tolerancia a fallos y orquestación
A escala planetaria, fallos son la norma, no la excepción. OlmoEarth gestiona cada tarea como reentrante e idempotente: cada tarea instancia una VM con un runner en Docker que ejecuta, devuelve resultados y se apaga. Si algo falla, el sistema reintenta, cambia a proveedores alternos si están disponibles o marca errores fatales cuando corresponda.
También hay monitoreo que detecta runners estancados y reinicia tareas. Esto, junto con retries y fallback, transforma la fragilidad de la nube en resiliencia operativa.
Tradeoffs: precisión, costo y velocidad
Todo sistema distribuido grande tiene decisiones de diseño que impactan resultados y presupuesto:
- Resolución vs volumen de datos: más detalle = más datos = más costo.
- Tamaño del modelo vs tiempo GPU: modelos grandes suelen ser más precisos pero consumen más GPU por ventana.
- Caché de escenas vs almacenamiento: guardar copias acelera corridas repetidas pero consume espacio.
Ajustar estos parámetros depende del caso de uso y del presupuesto. ¿Necesitas un mapa diario de incendios o una evaluación detallada trimestral para investigación? La respuesta define la configuración.
Desafíos técnicos clave y soluciones aplicadas
- Heterogeneidad de fuentes: distintos proveedores, proyecciones y canales requieren reproyección y alineamiento robustos.
- Dominio de I/O en el tiempo de ejecución: la plataforma realiza windowed reads y optimiza la preparación para que GPUs no pierdan tiempo esperando datos.
- Límites de APIs públicas: para no saturar STAC APIs externas, mantienen un índice local que se actualiza con streams o polling.
- Ensamblaje sin costuras: particiones solapan y al montar el raster final se reconciliarán solapes para evitar seams.
Técnicamente, soluciones como lecturas por rango en COG/Zarr, indexación propia, runners idempotentes y monitoreo automatizado son las que reducen el riesgo en producción.
Hoja de ruta y mejoras futuras
Entre las prioridades que publicaron están:
- Corridas automáticas: programar inferencias o dispararlas al llegar nueva imagen.
- Detección de cambio y alertas: convertir rasters en alertas accionables para usuarios.
- Herramientas agentic: bajar la barrera técnica para usuarios sin equipos de ML avanzados.
- Modelos más rápidos: investigar arquitecturas que reduzcan tiempo GPU por ventana.
- Nuevas modalidades: integrar datos meteorológicos (ERA-5) y sensores adicionales.
- Embeddings a escala: precomputar embeddings globales para acelerar muchos casos de uso y reducir la necesidad de pasar por el modelo completo.
- Run anywhere: soporte multi-cloud y despliegues en cuentas de socios.
Reflexión final
OlmoEarth no es solo un modelo: es una ingeniería de sistemas pensada para transformar modelos geoespaciales en productos operativos que organizaciones con recursos limitados puedan usar. Si trabajas en conservación, respuesta a desastres o seguridad alimentaria, esto reduce la brecha entre investigación y acción.
Si estás empezando con proyectos geoespaciales, toma nota de dos cosas prácticas: indexa tus metadatos y piensa en I/O antes que en GPU. La mayor parte del tiempo y dinero en estos sistemas se gasta moviendo y preparando datos, no en la inferencia en sí.
Fuente original
https://huggingface.co/blog/allenai/olmoearth-infrastructure