OlmoEarth v1.1: 더 효율적인 지구관측 모델 제품군
이 글은 Hugging Face 블로그의 OlmoEarth v1.1: A more efficient family of models를 한국어로 번역한 글입니다.
OlmoEarth v1.1: 더 효율적인 지구관측 모델 제품군
| 🧠 모델: https://huggingface.co/collections/allenai/olmoearth | 📄 기술 보고서: https://allenai.org/papers/olmoearth_v1_1 | 💻 코드: https://github.com/allenai/olmoearth_pretrain |
우리는 2025년 11월에 OlmoEarth(v1)을 출시했습니다. 그 이후 파트너들이 이를 다양한 작업에 적용해 왔습니다. 맹그로브 변화 추적에서 산림 손실의 원인 분류, 며칠 만에 국가 규모의 작물 유형 맵을 생성하는 등의 작업으로, 배치를 국가, 대륙, 전 세계 영역으로 확장해 왔습니다. 매 릴리스는 사람과 지구를 보호하기 위해 최첨단 AI를 조직과 커뮤니티에 제공한다는 우리의 사명에 한 걸음 더 다가가게 합니다.
OlmoEarth가 수십만에서 수십만 제곱킬로미터에 이르는 영역의 위성 이미지를 처리해 예측을 만들 때, 효율성이 가능성을 좌우합니다. OlmoEarth를 운용하는 전체 라이프사이클—데이터 내보내기, 전처리, 추론, 후처리—에서 계산 비용은 단연 가장 큰 비용입니다. 더 효율적인 모델은 OlmoEarth 플랫폼에서 더 많은 파트너를 지원할 수 있게 하고, 또한 모든 사용자가 직접 OlmoEarth를 실행할 때 이 기술을 더 빠르고 저렴하게 활용할 수 있게 만듭니다.
그것이 바로 우리가 OlmoEarth v1.1을 만든 이유입니다: 파트너들과 함께 구성한 연구 벤치마크와 작업의 혼합에서 OlmoEarth v1의 성능을 유지하면서 계산 비용을 최대 3배까지 줄이는 새로운 모델 계열입니다.
시퀀스 길이 감소로 효율성 향상
OlmoEarth 모델은 오늘날 머신러닝에서 지배적인 아키텍처 중 하나인 트랜스포머 기반 모델입니다. 원격 탐지 데이터를 처리하기 위해 먼저 모델이 받아들일 수 있는 토큰 시퀀스로 변환합니다.
트랜스포머 기반 모델의 효율성을 제어하는 두 가지 중요한 레버는 모델 크기(이것이 사용자가 계산 예산에 맞는 크기를 선택할 수 있도록 모델 패밀리를 출시하는 이유이기도 합니다)와 토큰 시퀀스 길이입니다. 계산 비용은 토큰 시퀀스 길이에 대해 이차적으로 증가하므로, 작은 감소라도 모델 실행 비용을 상당히 줄일 수 있습니다.
MACs(곱-덧셈 연산)은 한 번의 모델 순전파에 필요한 계산량을 추정합니다; MACs가 낮을수록 일반적으로 추론이 더 저렴하고 빠릅니다. y축은 낮을수록 더 나은 평균 순위를 나타내도록 반전되어 있습니다. 축 레이블은 모델 계열과 크기를 표시합니다. 모든 점은 전달된 MAC/랭크 값을 사용합니다.
토큰 설계
트랜스포머 기반 원격 센싱 모델에 대해 중요한 질문이 제기됩니다: 토큰은 무엇을 나타내야 할까요?
처리하는 일반적인 모달리티인 Sentinel-2 영상 예를 들면, Sentinel-2 입력은 높이와 너비를 갖는 텐서(H, W; 위도/경도 픽셀을 나타냄), 시간 차원 T, 그리고 12개의 Sentinel-2 채널([H, W, T, D=12])를 가집니다.
현재 데이터는 해상도 기반 패치로 분할합니다. 구체적으로는 공간 패치 크기 p를 선택하고 전체 Sentinel-2 이미지를 크기 p x p의 패치로 분할합니다:
각 패치마다 시간 단계별, 해상도별로 토큰을 생성합니다. 예를 들어 2 타임스텝의 Sentinel-2 입력은 패치당 6개의 토큰을 생성합니다(2타임스텝 × 3 해상도, 10m, 20m, 60m).
전체적으로 [H, W, T, D=12] Sentinel-2 입력은 H/p × W/p × T × 3 토큰을 생성합니다.
해상도당 고유 토큰을 사용하는 것은 Sentinel-2 데이터를 처리할 때 일반적인 기법입니다—Galileo와 SatMAE도 이 접근 방식을 택하며, SatMAE는 이를 수행할 때 현저한 더 나은 성능을 보입니다. 다만 보편적인 것은 아닙니다: CROMA는 해상도에 관계없이 모든 밴드에 대해 단일 토큰만 사용하는 모델입니다. 토큰 수가 기하급수적으로 증가하기 때문에 해상도를 단일 토큰으로 압축하면 토큰 수가 세 배 감소하고, 사전 학습, 미세 조정 및 추론 전반에 걸친 실질적 절감이 이뤄집니다.
이와 같이 토큰을 단순히 결합하면 성능 저하가 크게 발생합니다. 예를 들어 원격 탐지 모델의 일반적인 벤치마크인 m-eurosat의 kNN에서 약 10포인트(ppt) 하락이 나타납니다. Sentinel-2 밴드를 서로 다른 토큰으로 분리하면 OlmoEarth가 중요한 밴드 간 관계를 모델링하기 쉬워진다고 가정합니다.
성능에 영향을 주지 않고 토큰을 합치려면 사전 학습 방식의 수정을 필요로 했습니다. 이러한 변경 사항은 논문에 자세히 설명되어 있습니다.
개발자를 위한
결과적으로 더 적은 자원으로 더 많은 것을 수행하는 모델 패밀리입니다. 모든 크기에서 OlmoEarth v1.1은 OlmoEarth v1에 비해 최대 삼 배 더 저렴하게 실행되며, OlmoEarth를 실행하는 모든 팀의 지구 규모 지도 갱신을 더 자주 더 저렴하게 만들 수 있습니다. 원래 OlmoEarth 패밀리의 모델을 사용 중이라면 OlmoEarth v1.1을 시도해 보세요. OlmoEarth v1과 유사한 성능을 제공하지만 계산량은 3분의 1에 불가하며, 다만 몇 가지 회귀가 관찰되었다고 밝혔습니다(자세한 내용은 기술 보고서를 참조). 작업에 효과가 있다면 미세 조정과 추론에서 상당한 속도 향상을 경험하실 수 있을 겁니다.
연구자를 위한
사전 학습된 원격 센싱 모델은 자유도가 매우 많아 연구하기 어렵습니다. 성능 변화의 원인이 아키텍처, 데이터셋, 혹은 사전 학습 알고리즘 때문일 수 있습니다.
OlmoEarth v1.1은 OlmoEarth v1과 동일한 데이터셋으로 학습되었으므로 두 모델 간의 차이는 방법론적 변화의 효과를 고립합니다. 원격 센싱 모델의 사전 학습에서 과학적 원리 이해를 넓히는 데 이 연구가 도움이 되기를 바랍니다.
시작하기
OlmoEarth v1.1 weights와 training code를 확인해 보세요. Base, Tiny, Nano 모델의 가중치를 포함합니다.
Grabette: 로봇-조작 데이터를 기록하기 위한 오픈 시스템.
*함께 공유 데이터셋을 구축합니다.*
이 글은 Hugging Face 블로그의 Grabette: an open system to record robot-manipulation data를 한국어로 번역한...
Thinking Machines의 Inkling에 오신 것을 환영합니다
이 글은 Hugging Face 블로그의 Welcome Inkling by Thinking Machines를 한국어로 번역한 글입니다.
파이토치의 프로파일링(3부): 어텐션이 전부다
이 글은 Hugging Face 블로그의 Profiling in PyTorch (Part 3): Attention is all you profile를...
네이티브-스피드 vLLM transformers 모델링 백엔드
이 글은 Hugging Face 블로그의 Native-speed vLLM transformers modeling backend를 한국어로 번역한 글입니다.
LeRobot v0.6.0: 상상하고, 평가하고, 개선하기
이 글은 Hugging Face 블로그의 LeRobot v0.6.0: Imagine, Evaluate, Improve를 한국어로 번역한 글입니다.
Hugging Face와 Cerebras가 Gemma 4를 실시간 음성 AI로 선보입니다
이 글은 Hugging Face 블로그의 Hugging Face and Cerebras bring Gemma 4 to real-time voice...
Hugging Face 모델 페이지에서 Every Eval Ever 결과 보기
이 글은 Hugging Face 블로그의 Featuring Every Eval Ever Results on Hugging Face Model Pages를...
HF Jobs에서 vLLM 서버를 한 명령으로 실행하기
이 글은 Hugging Face 블로그의 Run a vLLM Server on HF Jobs in One Command를...
FFASR Leaderboard 소개: 현실 세계에서의 ASR 벤치마크
이 글은 Hugging Face 블로그의 Introducing the FFASR Leaderboard: Benchmarking ASR in the Real World를...
매주 AI, 오픈 도구, 그리고 휴먼 인 더 루프가 포함된 huggingface_hub 배포
이 글은 Hugging Face 블로그의 Shipping huggingface_hub every week with AI, open tools, and a...
Transformers.js에서 제안된 Cross-Origin Storage API 실험하기
이 글은 Hugging Face 블로그의 Experimenting with the proposed Cross-Origin Storage API in Transformers.js를 한국어로...
Beyond LoRA: 가장 인기 있는 미세조정 기법을 이길 수 있을까?
이 글은 Hugging Face 블로그의 Beyond LoRA: Can you beat the most popular fine-tuning technique?를...
충분히 에이전트적인가요? 자체 도구로 오픈 모델 벤치마킹하기
이 글은 Hugging Face 블로그의 Is it agentic enough? Benchmarking open models on your own...
에이전트 기반 리소스 탐색: 에이전트에게 도구·스킬·다른 에이전트 검색을 맡기다
이 글은 Hugging Face 블로그의 Agentic Resource Discovery: Let agents search를 한국어로 번역한 글입니다.
GitHub CI를 Hugging Face Jobs로 마이그레이션
이 글은 Hugging Face 블로그의 Migrating Your GitHub CI to Hugging Face Jobs를 한국어로 번역한...
오픈 소스 커뮤니티가 에이전틱 RL을 위한 OpenEnv에 힘을 싣다
이 글은 Hugging Face 블로그의 The Open Source Community is backing OpenEnv for Agentic RL를...
PyTorch에서의 프로파일링(Part 1): torch.profiler에 대한 초보자 가이드
이 글은 Hugging Face 블로그의 Profiling in PyTorch (Part 1): A Beginner’s Guide to torch.profiler를...
Reachy Mini를 로컬에서 완전히 실행하기
이 글은 Hugging Face 블로그의 Reachy Mini goes fully local를 한국어로 번역한 글입니다.
PaddleOCR 3.5: Transformers 백엔드를 활용한 OCR 및 문서 파싱 작업 실행
이 글은 Hugging Face 블로그의 PaddleOCR 3.5: Running OCR and Document Parsing Tasks with a...
Hugging Face Transformers 한글화 - 초벌 번역기 사용법
Hugging Face Transformers 문서를 한글로 번역하는 초벌 번역기 사용 방법을 안내하는 가이드입니다. 😊