OlmoEarth v1.1：より効率的なリモートセンシングモデルファミリーの登場

2026 年 5 月 19 日 ガブリエル・ツェング - Ai2 [Models](https://huggingface.co/collections/allenai/olmoearth)[Tech Report](https://allenai.org/papers/olmoearth_v1_1)[Code](https://github.com/allenai/olmoearth_pretrain) 私たちは 2025 年 11 月に OlmoEarth (v1) をリリースしました。それ以来、パートナーたちはマングローブの変化の追跡から森林減少の要因の分類、数日間で国規模の作物タイプマップの作成に至るまで、幅広いタスクでこれを利用しています。また、展開規模を国家、大陸、そして地球規模へと拡大してきました。すべてのリリースは、私たちのミッションに近づけるものです：人々と地球を守るために活動する組織やコミュニティへ、最先端の AI を届けることです。 [OlmoEarth](https://olmoearth.allenai.org/) が衛星画像を処理して数万から数十万平方キロメートルにわたる予測を行う際、効率性が実現可能な範囲を決定します。データのエクスポート、前処理、推論（inference）、後処理を含む OlmoEarth の運用全体ライフサイクルにおいて、計算リソースが圧倒的に最大の費用となります。より効率的なモデルとは、OlmoEarth Platform 上でより多くのパートナーをサポートできることを意味し、また自環境で OlmoEarth を実行する誰もが、この技術をより迅速に、かつ低コストで活用できるようになることを意味します。 そのため私たちは [OlmoEarth v1.1](https://huggingface.co/collections/allenai/olmoearth) を構築しました：研究ベンチマークとパートナーと共に構築したタスクの組み合わせにおける OlmoEarth v1 の性能を維持しつつ、計算コストを最大で**3 倍**削減する新しいモデルファミリーです。 ## シーケンス長を短縮することで効率性を向上させる OlmoEarth モデルは、現在の機械学習において支配的なアーキテクチャの一つであるトランスフォーマー（transformer）ベースのモデルです。リモートセンシングデータを処理するには、まずそれをモデルが取り込める一連のトークン（token）に変換する必要があります。 トランスフォーマーベースのモデルにおける効率性を制御する重要なレバーは 2 つあります。**モデルサイズ**（そのため、ユーザーが計算リソース予算に合ったサイズを選べるよう、私たちはモデルファミリーをリリースしています）と**トークンシーケンス長**です。計算コストはトークンシーケンス長の二乗に比例して増加するため、わずかな短縮でもモデル実行コストを実質的に削減できます。 ## トークンの設計 これはトランスフォーマーベースのリモートセンシングモデルにとって重要な問いを提起します：**トークンは何を表すべきか**？ 私たちが処理する一般的なモダリティである Sentinel-2 画像を例に挙げましょう。Sentinel-2 の入力データは、高さ（H）と幅（W：それぞれ緯度方向および経度方向のピクセル数を表す）、時間次元（T）、そして 12 個の Sentinel-2 チャネルを持つテンソル [H, W, T, D=12] となります。 現在、私たちはデータを**解像度ベースのパッチ**に分割しています。具体的には、ある空間パッチサイズ p を選び、全体の Sentinel-2 画像を p x p のパッチに分割します： 各パッチに対して、**解像度ごと・時刻ごとに 1 つのトークン**を作成します。したがって、2 つの時刻を持つ Sentinel-2 入力の場合、パッチあたり 6 トークン（2 時刻 × 3 解像度：10m、20m、60m）が生成されます。 全体として、[H, W, T, D=12] の Sentinel-2 入力は、H/p x W/p x T x 3 トークンを生み出します。 Sentinel-2 データを処理する際、解像度ごとに固有のトークンを使用するのは一般的な手法です。[Galileo](https://arxiv.org/abs/2502.09356) や [SatMAE](https://arxiv.org/abs/2207.08051) はこのアプローチを採用しており、特に SatMAE ではこれを行うことで著しく優れた結果を示しています。しかし、これは普遍的な手法ではありません。[CROMA](https://arxiv.org/abs/2311.00566) は解像度に関わらずすべてのバンドに対して単一のトークンしか使用しないモデルです。トークン数は乗算的に蓄積するため、解像度を単一のトークンに集約することで、事前学習、ファインチューニング、推論のすべてにおいて**3 分の 1 のトークン数**となり、実質的なコスト削減が可能になります。 このように単純にトークンを結合すると、性能が著しく低下します。具体的には、リモートセンシングモデルの一般的なベンチマークタスクである m-eurosat kNN で 10 パーセントポイント（ppt）もの低下が見られます。私たちは、Sentinel-2 のバンドを異なるトークンに分離することが、OlmoEarth が重要なクロスバンド間の関係をモデル化しやすくしているという仮説を立てています。 性能への悪影響なくトークンを統合するためには、事前学習の regimen（訓練計画）を変更する必要がありました。これらの変更の詳細については、当社の論文で詳しく説明しています。 ## 開発者向け その結果、少ないリソースでより多くのことができるモデルファミリーが生まれました。あらゆるサイズにおいて、OlmoEarth v1.1 は OlmoEarth v1 よりも最大 3 倍のコスト効率が高く、OlmoEarth を運用するすべてのチームにとって、頻繁な惑星規模の地図更新をより手頃なものにします。もしあなたが元の OlmoEarth ファミリーからモデルを使用しているなら、OlmoEarth v1.1 を試してみてください。計算リソースを 3 分の 1 で済ませながら OlmoEarth v1 と同様のパフォーマンスを提供しますが、いくつかの性能低下（回帰）も確認されています（詳細は技術レポートをご覧ください）。あなたのタスクに適合する場合は、ファインチューニングや推論時に顕著な速度向上を実感できるはずです。 ## 研究者向け 事前学習済みリモートセンシングモデルには多くの自由度があり、研究が難しい場合があります。パフォーマンスが変化した際、それはアーキテクチャ（構造）なのか、データセットなのか、それとも事前学習アルゴリズム（pre-training algorithm）の影響なのでしょうか？ 私たちは OlmoEarth v1.1 を OlmoEarth v1 と同じデータセットでトレーニングしました。そのため、両者の違いは手法の変更による効果のみを抽出したものです。これがリモートセンシング用のモデルを事前学習する際の科学原理の理解を深めることに寄与することを願っています。 ## 始め方 OlmoEarth v1.1 の [重み](https://huggingface.co/collections/allenai/olmoearth) と [トレーニングコード](https://github.com/allenai/olmoearth_pretrain)、さらに Base、Tiny、Nano モデル用の重みもご覧ください。 最新の Ai2 ニュースに関する月次アップデートを受け取るには購読してください。

OlmoEarth v1.1：より効率的なリモートセンシングモデルファミリーの登場

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト