OlmoEarth 플랫폼: 행성 규모 지리공간 추론 인프라 해부

Hugging Face Blog에 Allen AI(Ai2)가 OlmoEarth 플랫폼의 엔지니어링 아키텍처를 설명하는 글을 게시했다. 약 10TB의 다중모달 위성 데이터로 사전학습된 지구 관측 파운데이션 모델군을 대륙 규모로 추론하기 위한 인프라 설계 과정을 다룬다.

무엇이 새로운가

OlmoEarth 플랫폼은 추론 작업을 데이터 수집·전처리(CPU, 고 I/O), 모델 추론(GPU), 후처리(CPU) 세 단계로 분리하여 GPU가 모델 포워드 패스에만 집중하도록 설계됐다. 실행 레이어인 OlmoEarth Run은 지리적 영역을 파티션 단위로 분할하고, 파티션을 다시 윈도우로 세분화하여 독립적으로 병렬 처리한다. 북미 전역 산불 위험 지도를 생성한 사례에서는 피크 시 약 19,600 CPU와 994 GPU를 동시에 투입해 직렬 기준 4,737시간 분량의 연산을 약 30.5시간 벽시계 시간으로 줄였다고 밝혔다. 외부 STAC API 과부하를 피하기 위해 자체 메타데이터 인덱스를 유지하며, AWS Open Data SNS 알림이나 주기적 폴링으로 업데이트한다. 출력 포맷으로는 Zarr, GeoTIFF, GeoJSON을 지원하고, 인접 파티션 간 오버랩을 후처리 단계에서 보정해 이음새 없는 래스터를 만든다.

설정 파일에 어떤 의미인가

이 글은 플랫폼 내부 아키텍처 설명에 가깝고, 사용자가 직접 작성하는 설정 파일(YAML, TOML 등)이나 SDK 구성 방식에 대해서는 구체적으로 다루지 않는다. 파티션 크기, 출력 해상도, 모델 크기, 이미지 캐싱 여부 등이 “작업별 조절 가능한 노브”라고 언급되지만, 실제 설정 키나 CLI 플래그는 공개되지 않았다. 따라서 현재 시점에서 설정 파일 차원의 마이그레이션이나 breaking change를 논하기는 어렵다. 공식 문서나 SDK가 별도로 공개되면 설정 작성 관점에서 다시 정리할 필요가 있다.

다음 단계 제안

지리공간 ML 파이프라인을 직접 운영하거나 검토 중인 팀이라면, 원문에서 CPU/GPU 단계 분리 패턴과 메타데이터 인덱스 자체 운영 전략을 읽어볼 가치가 있다. 특히 STAC 카탈로그 대량 쿼리 시 외부 API 부하를 어떻게 회피하는지, 파티션 오버랩 보정 방식 등은 유사한 분산 래스터 처리 시스템에 참고할 만하다. OlmoEarth 모델 자체는 오픈 모델로 공개되어 있으므로, 자체 인프라를 갖춘 팀은 모델만 먼저 실험해 볼 수도 있다.

---

원문 전체 보기: The OlmoEarth Platform: Geospatial inference at planetary scale (Hugging Face Blog)