Como a Plataforma OlmoEarth da AI2 Alcança Speedup de 155x em Inferência Geoespacial em Escala Planetária

Por Que Inferência de Satélite é Difícil

A maioria dos modelos de ML ingere alguns megabytes e retorna um resultado em milissegundos. A inferência de observação da Terra (EO) opera em uma escala completamente diferente: um único job de fine-tuning de um modelo de fundação pode mover terabytes de dados e rodar por horas. As entradas abrangem múltiplas bandas espectrais, tipos de sensores e passos temporais em grandes áreas geográficas. Elas vêm de provedores diferentes com projeções e resoluções variadas, e frequentemente incluem observações ausentes ou obscurecidas por nuvens. A saída é ela mesma um mapa—cada predição deve permanecer precisamente alinhada com a mesma grade de coordenadas que suas vizinhas.

Até a aquisição de dados pode dominar o tempo de execução. Jobs de predição frequentemente passam mais tempo baixando e preparando imagens do que rodando o modelo em si. Pipelines eficientes precisam lidar com I/O de alto volume enquanto fornecem compute para reprojeção e reamostragem. Este é o desafio central que a Plataforma OlmoEarth foi construída para resolver.

Insight chave: Trate engenharia de dados como cidadã de primeira classe, não como reflexão tardia. O modelo é apenas uma parte do pipeline.

A Arquitetura de Três Estágios: Hardware Certo para a Tarefa Certa

Como a aquisição e preparação de dados frequentemente dominam o tempo de execução, atribuir esse trabalho às GPUs desperdiçaria o hardware mais caro. A plataforma divide cada job em três estágios, cada um combinado com um perfil de hardware distinto:

A plataforma distribui esses estágios por muitas máquinas enquanto mantém as GPUs totalmente utilizadas. Data loaders multiprocesso alimentam continuamente cada GPU, e as saídas concluídas fluem diretamente para o blob storage.

Uma Requisição, Centenas de Workers, Milhares de Processos

O OlmoEarth Run (a camada de execução) divide a região geográfica em partições dimensionadas para instâncias de compute individuais, depois subdivide essas partições em janelas menores processadas independentemente. Partições adjacentes se sobrepõem levemente; a sobreposição é reconciliada durante a montagem para que nenhuma emenda apareça no raster final.

Uma área do tamanho de um estado pode se tornar ~100 partições; uma execução em escala continental pode se tornar milhares. Como as partições são independentes, o mesmo estágio pode rodar em milhares de instâncias simultaneamente.

Números do mundo real: Um mapa de risco de incêndio cobrindo toda a América do Norte usou ~19.600 CPUs e 994 GPUs em paralelo, com throughput de rede excedendo 168 GB/s. Isso reduziu um estimado de 4.737 horas de compute serial para cerca de 30,5 horas de tempo de parede—um speedup de 155×.

O fan-out não é ilimitado. Mais workers pressionam as cotas de cloud, então o paralelismo é um botão por execução. Outros trade-offs ajustáveis incluem resolução de saída (volume de dados vs. detalhe), tamanho do modelo (tempo de GPU vs. acurácia) e cache de imagens brutas (storage vs. velocidade em execuções repetidas).

# Exemplo: lógica conceitual de particionamento (não é código real do OlmoEarth)
def partition_region(bbox, max_workers):
    """Divide uma bounding box em partições de área aproximadamente igual."""
    # Simplificado: assume região quadrada para ilustração
    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

Dica pro: Ao construir pipelines geoespaciais em larga escala, sempre projete para idempotência e reentrância. Falhas são a norma, não a exceção.

Encontrando e Buscando os Pixels Certos (e Lidando com Falhas)

Dada uma região e intervalo de tempo, a plataforma deve determinar quais cenas de satélite usar. Isso significa identificar o que foi capturado, onde e quando, entre provedores com catálogos, formatos e atrasos de publicação diferentes. Os critérios de seleção dependem da fonte: para imagens ópticas como Sentinel-2, cenas com menos nuvens são preferidas; para radar de abertura sintética, canais de polarização podem importar mais.

A plataforma depende de catálogos STAC públicos e padrões abertos onde possível. Mas um job grande pode gerar milhares de consultas de metadados de uma vez—muito mais do que serviços externos como as APIs STAC da ESA ou do Microsoft Planetary Computer foram projetados para lidar concorrentemente. Para evitar sobrecarregar esses serviços, o OlmoEarth mantém seu próprio índice de metadados, atualizado conforme novas imagens são publicadas. Para datasets hospedados no AWS Open Data, notificações SNS disparam atualizações; caso contrário, polling ocorre a cada poucos minutos. Cada entrada do índice armazena metadados da cena e ponteiros para todos os locais onde os pixels estão disponíveis. Em tempo de execução, a plataforma seleciona a melhor fonte e realiza leituras em janela contra formatos otimizados para cloud (COG, Zarr), recuperando apenas os bytes necessários para uma dada partição.

Lidando com Falhas em Escala

A plataforma é projetada para se recuperar automaticamente. Cada tarefa provisiona dinamicamente uma VM rodando um container Docker que recupera parâmetros, executa o trabalho, retorna resultados e desliga. Como cada tarefa é reentrante e idempotente, falhas intermitentes são tratadas com segurança ao reexecutar. O sistema distingue erros retentáveis de fatais, faz fallback para provedores alternativos quando disponível, e usa um processo de monitoramento separado para detectar e reiniciar runners travados.

Melhores práticas para publicar dados EO (derivadas de provedores que tornaram este workflow mais fácil):

• Notificações baseadas em fila quando novas imagens ficam disponíveis
• Armazenamento em grandes plataformas cloud sem limites de taxa bespoke
• Formatos otimizados para cloud que suportam leituras ranged

Cuidado crítico: Esta arquitetura assume infraestrutura cloud confiável e pode não ser viável para organizações com orçamentos limitados ou restrições on-premise. A plataforma é atualmente operada no Google Cloud, embora o design suporte multi-cloud e implantações on-prem.

Conclusão & Próximos Passos

A Plataforma OlmoEarth da AI2 demonstra que operacionalizar modelos de fundação geoespaciais requer tanto rigor de engenharia quanto desenvolvimento de modelo. As principais lições:

• Separe preocupações por perfil de hardware (CPU para I/O, GPU para inferência) para maximizar utilização.
• Particione agressivamente e projete cada tarefa para ser idempotente e reentrante.
• Mantenha seu próprio índice de metadados para evitar sobrecarregar APIs externas.
• Trate falhas como esperadas e construa recuperação automática desde o dia um.

A plataforma atualmente roda inferência em escala continental em ~1 dia a frações de centavo por km². O roadmap inclui execuções automatizadas de modelo, alertas de detecção de mudança, ferramentas agênticas, arquiteturas mais rápidas, mais modalidades (dados meteorológicos, novos sensores), embeddings em escala global e implantação multi-cloud/on-prem.

Para times construindo sistemas similares, a maior lição é investir em pipelines de dados cedo—eles dominarão seu tempo de execução e seus custos. Comece com uma região pequena, meça onde o tempo é gasto e otimize o gargalo primeiro.

Leitura adicional:

• Como o Blog Oficial do Python Migrou do Blogger para Git: Um Estudo de Caso em Infraestrutura Open Source
• Como a Meta Usa Otimização Bayesiana para Projetar Misturas de Concreto em Escala

Fonte: Post do blog OlmoEarth Platform