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

[記事一覧に戻る](https://huggingface.co/blog) - シーケンス長を短縮することで効率性を向上させる - トークンの設計 - 開発者向け - 研究者向け - はじめに 🧠 モデル：[https://huggingface.co/collections/allenai/olmoearth](https://huggingface.co/collections/allenai/olmoearth) | 📄 テクニカルレポート：[https://allenai.org/papers/olmoearth_v1_1](https://allenai.org/papers/olmoearth_v1_1) | 💻 コード：[https://github.com/allenai/olmoearth_pretrain](https://github.com/allenai/olmoearth_pretrain) 私たちは 2025 年 11 月に OlmoEarth (v1) をリリースしました。それ以来、パートナーはマングローブの変化の追跡から森林減少の原因の分類、数日間で国規模の作物タイプマップの作成に至るまで、幅広いタスクでこのモデルを適用してきました。また、展開規模も国家レベル、大陸レベル、そしてグローバルレベルに拡大されています。すべてのリリースは、私たちのミッションである「人々と地球を守るために活動する組織やコミュニティへ最先端の AI を届ける」ことに一歩ずつ近づいています。 [OlmoEarth](https://olmoearth.allenai.org/) が衛星画像を処理して数万から数十万平方キロメートルにわたる予測を行う際、効率性が実現可能な範囲を決定づけます。データのエクスポート、前処理、推論、後処理を含む OlmoEarth の運用全体ライフサイクルにおいて、計算リソースのコストが圧倒的に最も高くなります。より効率的なモデルであれば、OlmoEarth Platform 上でより多くのパートナーをサポートでき、また自環境で OlmoEarth を実行する個人や組織も、この技術をより迅速に、かつ低コストで活用できるようになります。 そのため、私たちは **[OlmoEarth v1.1](https://huggingface.co/collections/allenai/olmoearth)** を構築しました。これは、研究ベンチマークやパートナーと共同で構築したタスクの組み合わせにおいて OlmoEarth v1 の性能を維持しつつ、計算コストを最大 **3 倍**削減する新しいモデルファミリーです。 ## シーケンス長を短縮して効率化を図る OlmoEarth モデルはトランスフォーマーベースのモデルであり、現在の機械学習において支配的なアーキテクチャの一つです。リモートセンシングデータを処理するには、まずそれをモデルが取り込める *トークン* のシーケンスに変換する必要があります。 トランスフォーマーベースのモデルにおける効率を制御する 2 つの重要なレバーがあります。**モデルサイズ**（これが私たちがモデルファミリーとしてリリースする理由であり、ユーザーは自身の計算予算に合ったサイズを選べるようにするため）と**トークンシーケンス長**です。計算コストはトークンシーケンス長の二乗に比例して増加するため、わずかな削減でもモデル実行コストを有意に低下させることができます。 *MACs（Multiply-Accumulate Operations：乗算加算演算）とは、1 回のモデル順伝播に必要な計算量を推定する指標です。一般的に 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 入力の場合、1 パッチあたり 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 ポイントもの低下が見られます。私たちは、Sentinel-2 のバンドを異なるトークンに分離することが、OlmoEarth が重要なクロスバンド間の関係をモデル化しやすくしているという仮説を立てています。 パフォーマンスに影響を与えることなくトークンをマージするには、事前学習の regimen（訓練手順）を変更する必要がありました。これらの変更の詳細については論文で説明しています。 ## 開発者向け その結果、より少ないリソースでより多くのことができるモデルファミリーが生まれました。あらゆるサイズにおいて、OlmoEarth v1.1 は OlmoEarth v1 よりも最大 3 倍コストを抑えられ、OlmoEarth を運用するすべてのチームにとって、頻繁な地球規模の地図更新がより手頃になります。もしあなたが元の OlmoEarth ファミリーからモデルを使用しているなら、OlmoEarth v1.1 を試してみてください。計算リソースを 3 分の 1 で済ませながら OlmoEarth v1 と同様のパフォーマンスを提供しますが、いくつかの性能低下（regressions）も確認されています（詳細は技術レポートをご覧ください）。あなたのタスクに適合する場合は、ファインチューニングや推論時に著しい速度向上が期待できます。 ## 研究者向け 事前学習済みリモートセンシングモデルには多くの自由度があり、研究が困難です。パフォーマンスに変化が生じた場合、それはアーキテクチャ（構造）のせいなのか、データセットのせいなのか、それとも事前学習アルゴリズムのせいなのか？ OlmoEarth v1.1 は OlmoEarth v1 と同じデータセットでトレーニングを行っているため、両者の違いは手法の変更による効果のみを抽出したものです。リモートセンシング用の事前学習モデルを開発する際の科学的原理の理解が深まることを願っています。 ## 始め方 OlmoEarth v1.1 の[重み](https://huggingface.co/collections/allenai/olmoearth)と[トレーニングコード](https://github.com/allenai/olmoearth_pretrain)、さらに Base、Tiny、Nano モデル用の重みもご確認いただけます。

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

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

関連記事

調べる

選ぶ

サイト