155배 속도 향상과 대륙 규모 추론의 실현

북미 전역의 산불 위험 지도를 생성하는 데 필요한 4,737시간의 직렬 연산을 30.5시간으로 단축해 155배의 속도 향상을 달성했다. 이 결과로 대륙 규모의 지리 공간 추론을 약 하루 만에 완료하는 것이 가능해졌다. OlmoEarth 플랫폼은 모델의 파인튜닝(Fine-tuning)과 평가 단계를 넘어 실제 대규모 추론을 수행하기 위해 구축된 인프라다. 단일 프로세스로 처리했을 때 수개월이 걸릴 작업을 하루 단위로 줄여 분석 주기를 단축했다.

연산 피크 타임에는 CPU 19,600개와 GPU 994개를 병렬로 투입했다. 네트워크 처리량은 초당 168GB를 초과하는 수준으로 유지되었다. 각 작업 단계를 독립적인 파티션으로 나누어 수천 개의 컴퓨팅 인스턴스에서 동일한 단계를 동시에 실행함으로써 직렬 처리의 한계를 극복했다. 하드웨어 자원을 병렬화하여 처리 시간을 실제 경과 시간인 월클락 타임(Wall-clock time) 기준으로 압축한 결과다.

수십 테라바이트에 달하는 위성 이미지 데이터를 처리하면서 제곱킬로미터당 비용을 1페니 미만으로 억제했다. 플랫폼은 사용자가 지정한 지리적 영역과 시간 범위에 따라 모델에 공급할 위성 장면을 자동으로 결정한다. 서로 다른 제공자의 카탈로그와 데이터 포맷, 게시 지연 시간을 분석하여 최적의 데이터를 추출한다.

데이터 선정 기준은 위성 종류에 따라 다르게 적용된다. 센티넬-2(Sentinel-2) 이미지의 경우 구름이 가장 적은 장면을 우선 선택하며, SAR(Synthetic Aperture Radar) 데이터는 가용한 편파 채널을 기준으로 선별한다. 이러한 전처리 과정 후 대규모 병렬 연산을 수행해 추론의 정확도와 속도를 확보한다.

시스템 안정성을 위해 자동 복구 메커니즘을 도입했다. 각 단계의 작업과 지리적 파티션마다 러너 도커(Runner Docker)를 구동하는 가상 머신을 동적으로 할당한다. 특정 인스턴스에서 오류가 발생하더라도 전체 파이프라인을 중단하지 않고 해당 단위의 작업을 자동으로 재시작해 연산의 완결성을 보장한다.

GPU 효율을 극대화하는 하드웨어 프로필 3단계 분리

GPU는 연산 속도가 빠르지만 시간당 비용이 높다. OlmoEarth 플랫폼은 자원 낭비를 막기 위해 전체 공정을 데이터 준비, 모델 추론, 결과 병합의 3단계 하드웨어 프로필로 분리했다. 데이터 준비와 결과 병합은 CPU가 담당하고, 실제 모델 추론만 GPU가 수행한다. 고비용 자원인 GPU가 단순한 데이터 읽기나 쓰기 같은 I/O(입출력) 작업에 시간을 허비하지 않도록 역할을 나눈 구조다.

데이터 획득과 준비 단계의 I/O 부하는 모두 CPU에 할당했다. 위성 이미지 같은 대용량 파일을 클라우드에서 불러오고 전처리하는 과정은 순수 연산보다 데이터 이동 시간이 더 많이 소요된다. 이 과정을 GPU에서 처리하면 연산 장치가 데이터를 기다리는 유휴 시간이 발생한다. 플랫폼은 멀티프로세스 데이터 로더를 운용해 CPU가 미리 데이터를 읽어 큐에 쌓아두면 GPU가 이를 즉시 소모하는 구조로 설계했다.

모델 추론이 완료된 출력물은 다시 CPU 영역으로 넘어가 결과 병합 과정을 거친다. 생성된 결과물은 로컬 디스크 임시 저장을 생략하고 블롭 스토리지(Blob Storage)로 직접 스트리밍된다. 데이터를 메모리에서 저장소로 즉시 전송해 디스크 쓰기 병목 현상을 제거했다. CPU가 결과물을 저장소로 보내는 동안 GPU는 대기 시간 없이 다음 데이터 윈도우의 추론 연산에 즉시 투입된다.

이러한 3단계 분리 구조는 GPU 유휴 시간을 없애 연산 효율을 높인다. 데이터 로더가 CPU에서 다음 데이터를 준비하고, GPU가 이를 받아 추론하며, 동시에 이전 결과물을 CPU가 저장소로 보내는 파이프라인이 병렬로 작동한다. 각 단계가 독립적으로 실행되므로 특정 단계의 I/O 지연이 전체 시스템 정지로 이어지지 않으며, GPU는 텐서 연산이라는 고성능 작업에만 집중해 전체 처리량을 극대화한다.

STAC 표준 기반의 자체 메타데이터 인덱싱 구조

대규모 추론 작업 시 발생하는 수천 건의 메타데이터 쿼리는 외부 서비스의 동시 요청 처리 한계를 초과한다. OlmoEarth는 STAC(SpatioTemporal Asset Catalog) 공개 표준을 활용하지만, ESA나 Microsoft Planetary Computer의 STAC API에만 의존할 경우 속도 제한으로 파이프라인이 중단된다. 특히 수만 개의 윈도우를 동시에 처리하는 병렬 구조에서는 API 요청 횟수가 급증해 외부 서비스의 자원 제한으로 작업이 강제 종료될 수 있다. 이는 대륙 규모 데이터 처리 인프라의 가장 큰 병목 지점이다.

이를 해결하기 위해 OlmoEarth 플랫폼은 자체적인 메타데이터 인덱스를 구축해 운영한다. AWS Open Data 호스팅 데이터셋의 경우 SNS(Simple Notification Service)를 통해 새로운 장면이 게시되는 즉시 인덱스에 반영한다. 실시간 스트림을 제공하지 않는 공급자의 경우에는 시스템이 몇 분 간격으로 상위 인덱스를 폴링(Polling)하여 최신 상태를 유지한다. 이 구조를 통해 요청 폭주를 제거하고 일정한 요청 흐름을 유지함으로써 외부 서비스와의 연결 안정성을 확보한다.

인덱스의 각 항목은 장면 메타데이터와 함께 실제 픽셀 데이터가 저장된 물리적 위치 포인터를 저장한다. 플랫폼은 런타임 시 최적의 데이터 소스를 선택한 뒤 COG(Cloud Optimized GeoTIFF)나 Zarr 같은 클라우드 최적화 포맷을 통해 윈도우 읽기(Windowed reads)를 수행한다. 윈도우 읽기는 전체 파일을 다운로드하는 대신, HTTP 범위 요청을 통해 필요한 바이트 범위만 선택적으로 추출하는 방식이다. 실제 모델 추론에 필요한 극소량의 데이터만 전송받으므로 네트워크 I/O 부하를 낮추고 로딩 속도를 높인다.

OlmoEarth Run의 지리적 파티셔닝 및 윈도우 처리

OlmoEarth Run은 전체 지리적 영역을 개별 컴퓨팅 인스턴스인 워커 크기에 맞춘 파티션으로 분할한다. 워커의 메모리와 연산 능력에 따라 파티션 크기가 결정되며, 분할된 각 파티션은 다시 모델이 한 번에 처리할 수 있는 작은 윈도우 단위로 세분화된다. 각 윈도우는 독립적인 포워드 패스를 거치며, 특정 윈도우의 연산이 다른 윈도우의 완료 상태에 의존하지 않으므로 수천 개의 연산 단위가 동시에 실행된다.

처리 대상 면적에 따라 파티션 규모는 유동적으로 변한다. 미국 주 하나 정도의 면적은 약 100개, 대륙 전체 대상 작업은 수천 개의 파티션으로 확장된다. 이때 인접한 파티션끼리는 경계 부분에 중첩 영역을 두어 데이터 연속성을 확보한다. 최종적으로 픽셀 기반의 격자 이미지로 결과물을 조립하는 과정에서 이 중첩분을 조정해 이미지 간 단절이나 이음새가 나타나지 않도록 처리한다. 이는 분산 컴퓨팅 환경에서 지리적으로 일관된 지도를 생성하는 방법이다.

시스템 운영자는 세 가지 조절 노브를 통해 리소스 투입량과 품질을 결정한다. 출력 해상도 설정은 데이터 처리량과 세부 묘사 수준을 결정하며, 해상도를 높이면 연산 시간이 늘어난다. 모델 크기 설정은 GPU 연산 시간과 추론 정확도 사이의 트레이드오프를 제어한다. 원본 이미지 캐싱 설정은 저장 공간 사용량과 읽기 속도 사이의 효율성을 조정한다. 사용자는 하드웨어 메모리와 허용 처리 시간을 고려해 이 설정값들을 조합함으로써 파이프라인 처리량을 최적화한다.

지리 공간 데이터 제공자를 위한 인프라 권장 기준

앞서 설명한 병렬 추론 효율을 극대화하기 위해서는 데이터 제공자의 배포 방식이 중요하다. 큐 기반의 신규 이미지 알림을 제공하고, 주요 클라우드 플랫폼에 저장하며, 범위 읽기(Ranged reads)를 지원하는 클라우드 최적화 포맷을 사용할 때 추론 속도가 가장 빠르다. 위성 데이터 추론은 단일 작업에서 테라바이트 단위의 데이터를 이동시키므로, 전송 병목을 제거하는 배포 방식이 전체 파이프라인의 속도를 결정한다.

기초 모델(Foundation Model) 학습에는 약 10테라바이트의 멀티모달 위성 데이터가 사용되었다. 이러한 모델은 산림 파괴 모니터링, 식량 안보, 산불 위험 분석과 같이 정밀한 지표 분석이 필요한 서비스로 이어진다. 출력물 자체가 지도 형태이므로 모든 예측 값은 주변 영역과 동일한 투영법과 좌표 그리드에 정밀하게 정렬되어야 하며, 이 과정에서 발생하는 좌표 변환 부하를 최소화하는 것이 중요하다. 다중 센서 데이터를 하나의 좌표계로 통합하는 정밀도가 분석의 정확도를 결정한다.

결과적으로 대규모 위성 데이터 처리 인프라의 효율은 GPU의 단순 연산 성능보다, COG와 Zarr 같은 최적화 포맷을 도입해 불필요한 데이터 이동을 제거하고 I/O 대기 시간을 최소화하는 데이터 배포 구조의 최적화에 달려 있다.

대규모 위성 데이터 처리 인프라의 효율을 결정하는 최종 실행 기준은 GPU의 연산 성능보다, COG(Cloud Optimized GeoTIFF)와 Zarr 같은 클라우드 최적화 포맷을 도입해 불필요한 데이터 이동을 제거하고 I/O 대기 시간을 최소화하는 데이터 배포 구조의 최적화에 있다.