Satellite inference на геоданных упирается в I/O, разнородные источники и масштаб. Разбираем, как OlmoEarth Platform решает это на уровне архитектуры и исполнения.
Проблема начинается там, где классические ML-пайплайны перестают масштабироваться. В satellite inference входные данные — не мегабайты, а терабайты. Один запуск может включать разные сенсоры, спектральные каналы и временные срезы. Источники разнородны: разные проекции, разрешения и неполные наблюдения из-за облачности. При этом выход — это карта, где каждая точка должна быть точно выровнена по координатной сетке. На практике деградация начинается не в модели, а в data pipeline: скачивание и подготовка данных занимают больше времени, чем сам inference. Это превращает I/O в основной bottleneck и делает неэффективным использование GPU.
В OlmoEarth Platform сделали прагматичный выбор: разделили pipeline на стадии и сопоставили их с разным железом. CPU обрабатывает загрузку, репроекцию и ресэмплинг. GPU занят только inference. Такой декомпозицией снимается конфликт между дорогими вычислениями и тяжёлым I/O. Это компромисс между сложностью orchestration и эффективностью использования ресурсов. Дополнительно вводится параметризация: можно регулировать степень параллелизма, разрешение выходных данных и размер модели. Это позволяет балансировать стоимость, latency и точность под конкретную задачу.
Реализация опирается на агрессивный параллелизм и изоляцию задач. Географическая область делится на партиции, каждая из которых обрабатывается отдельным worker. Далее партиции разбиваются на окна, которые модель обрабатывает независимо. Это устраняет межзадачные зависимости и позволяет масштабироваться до тысяч инстансов. Перекрытие соседних партиций устраняет артефакты на границах при сборке итогового растра. В одном из запусков использовались десятки тысяч CPU и почти тысяча GPU с сетевым throughput более 168 GB/s. Такой fan-out даёт значительное сокращение wall-clock времени, но упирается в квоты облака, поэтому уровень параллелизма становится управляемым параметром.
Отдельный класс проблем — поиск и доставка данных. Satellite inference требует точного выбора сцен: где, когда и с каким качеством. Например, для оптических данных важна минимальная облачность, для SAR — поляризация. Публичные STAC-каталоги дают стандартный интерфейс, но не выдерживают burst-нагрузку от тысяч параллельных запросов. В платформе это обошли через собственный metadata index, который обновляется по событиям (SNS) или через polling. Это превращает нагрузку на внешние сервисы из всплесков в равномерный поток. В рантайме используются windowed reads из форматов вроде COG и Zarr, что исключает скачивание целых сцен. Читаются только нужные байты под конкретное окно. Это критично для снижения latency и нагрузки на сеть.
Устойчивость к сбоям встроена в модель исполнения. Каждая задача идемпотентна и reentrant. Если источник недоступен, данные неполные или задача падает, система делает retry или переключается на альтернативного провайдера. Runner запускается в отдельной VM, выполняет задачу и завершается. Отдельный мониторинг отслеживает зависшие процессы и перезапускает их. На этом масштабе сбои — не исключение, а нормальное состояние системы, и архитектура это учитывает.
Результаты показывают, что такой подход позволяет выполнять continent-scale satellite inference примерно за сутки, обрабатывая десятки терабайт данных с низкой стоимостью на квадратный километр. Точные метрики качества моделей не раскрываются, но акцент явно смещён на эффективность исполнения и доступность для организаций без сильных инженерных команд.
В более широком контексте это отражает тренд: geospatial ML смещается от экспериментов к эксплуатационным системам. Основная сложность уже не в обучении моделей, а в их операционализации — доставке данных, масштабировании inference и обеспечении надёжности. OlmoEarth Platform — пример эволюционного подхода, где архитектура подчинена физике данных, а не только модели.