ベンチマーク

OlMo Hybrid完全解説|SSM×Transformerの技術と性能

OlMo Hybrid完全解説|SSM×Transformerの技術と性能

この記事の結論

AI2が発表したOlMo Hybridは、Gated DeltaNetとTransformerを3:1で組み合わせた7Bパラメータのオープンソースモデル。同等性能をトークン49%削減で達成する技術的背景と実装方法を解説します。

「Transformerは万能」――そう思っていた時期が、正直あった。

ところが2026年3月5日、AI2(Allen Institute for AI)が発表したOlMo Hybridは、その前提に揺さぶりをかけた。Transformerのattention層の75%をGated DeltaNetと呼ばれる線形RNNに置き換え、同等の精度をトークン49%削減で達成する。7Bパラメータのフルオープンソースモデルだ。Apache 2.0ライセンスで、重み・コード・学習データ・中間チェックポイントまですべて公開されている。

この記事では、OlMo Hybridのアーキテクチャ、ベンチマーク結果、そして開発者がこのモデルから何を読み取るべきかを整理する。


何が発表されたのか

AI2は2026年3月5日、OlMo Hybridを発表した。ポイントは3つ。

  • アーキテクチャ: OlMo 3 7Bのsliding-window attention層の75%をGated DeltaNet(GDN)に置き換えた「3:1ハイブリッド」構造
  • データ効率: MMLUで同等精度をトークン49%削減で達成(約2倍のトークン効率)
  • 完全オープン: Apache 2.0ライセンス。ベースモデル、Instruct版、Think版の3バリアントをHugging Faceで公開

学習には512基のGPU(NVIDIA H100 → 途中からHGX B200に移行)を使い、6兆トークンで事前学習している。学習基盤はLambdaが提供した。

項目 OlMo 3 7B OlMo Hybrid 7B
学習トークン数 5.93T 5.50T
レイヤー数 32 32
Hidden Size 4,096 3,840
Attention Heads 32 30(うち75%をGDNに置換)
コンテキスト長 65,536 65,536
ライセンス Apache 2.0 Apache 2.0

Gated DeltaNetの仕組み ― なぜattentionを置き換えられるのか

ここが技術的に最も面白い部分だ。

従来のTransformerは、全トークン間の関係を計算するself-attentionが強力な反面、シーケンス長に対して計算量が二次的に増える。これに対しGated DeltaNet(GDN)は、線形RNNの一種で、シーケンス長に対して線形にスケールする。

GDNのコアは2つのメカニズムの組み合わせにある。

  1. ゲート機構: 不要な情報を素早く忘却する適応的メモリ制御
  2. デルタルール: 必要な情報を精密に上書き更新する学習ルール

要するに、「何を覚えて何を忘れるか」をトークンごとに動的に判断する仕組みだ。ICLR 2025で発表された論文(参照日: 2026-03-13)によれば、Mamba2やDeltaNetを複数のベンチマークで上回っている。

OlMo Hybridでは、このGDNレイヤーを3層置いた後に標準的なmulti-head attention層を1層挟む「3:1パターン」で全32層を構成する。つまり24層がGDN、8層がattentionだ。

なぜ完全にGDNにしないのか? 筆者の理解では、attentionは「過去の特定トークンを正確に参照する」タスクでGDNより強い。ハイブリッドにすることで、GDNの効率性とattentionの精密な検索能力を両立させている。

以下のコードで、Hugging Face上のOlMo Hybridを試せる。

# 動作環境: Python 3.10+, transformers>=5.3.0
# pip install transformers torch

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("allenai/Olmo-Hybrid-7B")
tokenizer = AutoTokenizer.from_pretrained("allenai/Olmo-Hybrid-7B")

prompt = "AIエージェントの設計で最も重要なことは"
inputs = tokenizer(prompt, return_tensors="pt", return_token_type_ids=False)
outputs = model.generate(**inputs, max_new_tokens=200, do_sample=True, temperature=0.7, top_p=0.9)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

動作環境: Python 3.10+, transformers>=5.3.0, PyTorch 2.x

ベンチマーク結果 ― 数字で見るOlMo Hybridの実力

Hugging Faceのモデルカード(参照日: 2026-03-13)に記載されているベースモデル(事前学習済み)のスコアを整理した。

ベンチマーク OlMo 3 7B OlMo Hybrid 7B 差分
MMLU STEM 59.7 64.6 +4.9
ARC MC 89.2 90.8 +1.6
HellaSwag RC 77.7 79.0 +1.3
BBH 37.3 41.7 +4.4
MBPP 43.6 50.3 +6.7
HumanEval 49.1 49.0 -0.1
DROP 71.5 72.9 +1.4
Winogrande RC 85.7 86.2 +0.5

注目すべきはBBH(+4.4)MBPP(+6.7)の伸びだ。推論と実装力で明確な改善が見られる。一方、HumanEvalはほぼ同等(-0.1)で、全てのタスクでHybridが勝つわけではない。正直にお伝えすると、Deepmind Math(16.8 vs 17.1)やMMLU Pro MC(23.4 vs 23.7)ではわずかに後退している。数学的推論の一部タスクではattentionの精密さが効いているのかもしれない。

長文コンテキストでの圧倒的優位性

ハイブリッドアーキテクチャの真価は、長文処理で最も明確になる。

AI2の公式ブログ(参照日: 2026-03-13)によれば、64kトークンのRULERベンチマークで以下の結果が出ている。

  • OlMo Hybrid(DRoPE): 85.0
  • OlMo Hybrid(YaRN): 76.9
  • OlMo 3 7B(YaRN): 70.9

DRoPE(Dynamic Rotary Position Embedding)との組み合わせで、OlMo 3比+14.1ポイントの差がつく。GDNはシーケンス長に対して線形にスケールするため、推論時のスループットとメモリ効率も大幅に改善される。AI2は「75%の推論効率改善」と表現しているが、これはタスクや実装に依存するため、自分の環境で検証することを強く推奨する。

スケーリング則 ― 70Bではさらに差が広がる予測

OlMo Hybridの技術報告書で最も興味深いのは、スケーリング則の分析だ。

AI2のチームは、ハイブリッドモデルのトークン節約係数がパラメータ数に応じて成長することを示した。

  • 1Bパラメータ: 約1.3倍のトークン効率
  • 7Bパラメータ: 約2倍のトークン効率(49%削減)
  • 70Bパラメータ(予測): さらに高いトークン効率が期待される(7B時点のトレンドから外挿)

1Bから7Bへのスケーリングで効率が大幅に向上しており、この傾向が続けば70B以上でもハイブリッド化の恩恵は拡大すると考えられる。ただし70Bはあくまで予測値であり、実際に学習して検証されたわけではない点に注意が必要だ。

推論効率の観点では、Gemini 3.1 Flash-Liteも低コスト・高速推論で注目されており、用途に応じたモデル選択がますます重要になっています。

開発者が知っておくべきこと

OlMo Hybridは研究モデルであり、GPT-4oやClaude Opus 4と直接競合するプロダクションモデルではない。だが、AIエージェント開発者にとっていくつか見逃せないポイントがある。

1. 長文処理の効率化はエージェントに直結する

AIエージェントは大量のコンテキスト(会話履歴、ツール出力、ドキュメント)を処理する。GDNベースのハイブリッドアーキテクチャは、推論コストを抑えながら長いコンテキストを扱える可能性がある。まだ7Bでの検証段階だが、AIエージェント構築のコスト構造を変えるかもしれない。

2. Apache 2.0の完全オープンは実験しやすい

重み、コード、学習データ、中間チェックポイントまで全て公開されている。以下のように量子化して手元で動かせる。

# 8bit量子化で推論(VRAM削減)
# 動作環境: Python 3.10+, transformers>=5.3.0, bitsandbytes
# pip install transformers bitsandbytes accelerate

from transformers import AutoModelForCausalLM
import torch

model = AutoModelForCausalLM.from_pretrained(
    "allenai/Olmo-Hybrid-7B",
    torch_dtype=torch.float16,
    load_in_8bit=True  # bitsandbytesが必要
)

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

3. Instruct版とThink版が使い分けられる

AI2は3つのポストトレーニングバリアントを公開している。

バリアント 用途 Hugging Face
Olmo-Hybrid-7B ベースモデル(ファインチューニング用) リンク
Olmo-Hybrid-Instruct-SFT-7B 指示追従(チャット、タスク実行) リンク
Olmo-Hybrid-Think-SFT-7B 推論タスク(CoT、数学) リンク

商用モデルではGPT-5.2 Thinkingが専門家レベルの推論を実現しており、オープンソースモデルとの性能差がどう推移するかが注目点です。

この先どうなるか

OlMo Hybridが示したのは、純粋なTransformerアーキテクチャが唯一の正解ではないという事実だ。

GDNのような線形RNNとattentionのハイブリッド化は、推論コスト・長文処理・データ効率の3点でメリットがある。今後、70B以上のスケールでの検証が進めば、商用モデルにもハイブリッドアーキテクチャが波及する可能性は高い。

一方で、まだ解決されていない問題もある。GDNは過去の特定トークンを正確に検索するタスクでは弱い(だからこそattention層を残している)。また、7Bスケールでの検証にとどまっており、32Bや70Bでの実証データはまだない。

筆者の見立てでは、2026年後半にはMeta、Google、あるいはAI2自身が32B以上のハイブリッドモデルを発表するだろう。AIエージェント開発者としては、ハイブリッドアーキテクチャの動向を追いつつ、今のうちにOlMo Hybridで長文コンテキスト処理の実験を始めておくのが賢明だ。

AIエージェント構築の全体像についてはAIエージェント構築完全ガイドで体系的にまとめているので、あわせて参照してほしい。

参考・出典


あわせて読みたい:


ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。

この記事はAIgent Lab編集部がお届けしました。

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

この記事をシェア

X Facebook LINE

※ 本記事の情報は2026年3月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。

関連記事