LLaVA-OneVision-2: コーデック整合型エンコーダで長尺動画と空間理解を1モデルに統合する
Fully Open Framework for Democratized Multimodal Training
ひと目でわかる
- これは何？
- LLaVA-OneVision 系の 8B マルチモーダルモデル。画像・長尺動画・3D 空間推論を単一アーキテクチャにまとめ、データ、エンコーダ重み、学習コード、ログまでを Apache-2.0 で公開する。評価は lmms-eval の専用ブランチで再現する前提の構成になっている。
- 誰に向いている？
- 自前の動画・空間データでマルチモーダルモデルを再学習したい研究チーム、特に長尺動画のトークン予算に悩んでいる場合は検討対象になる。逆に、画像1枚の VQA を API 経由で済ませたいプロダクトや、GPU を1枚しか持たないチームには過剰で、量子化済みの小型モデルのほうが現実的だ。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
画像1枚のモデルが長尺動画で破綻する理由に手を入れている
オープンなマルチモーダルモデルの多くは、2D の単一画像を前提に設計されている。LLaVA-OneVision-2 が解こうとしているのは、その前提を長尺動画と3D 空間理解に広げたときに生じるトークン予算の枯渇である。README は「prior ViT backbones simply run out of context」と述べ、均一フレームサンプリングでは同じトークン数でカバーできる時間幅が足りなくなると説明している。対象読者は、自前の動画データでモデルを学習し直したい研究チームと、画像・動画・文書をひとつのモデルに集約したいが API 依存を避けたい開発者だ。8B というサイズは、単一ノードの Quick Start が用意されている程度には現実的で、かつフロンティア規模の学習基盤を要求しない範囲に収まっている。
OneVision-Encoder は動きと残差の多いパッチだけを選ぶ
中心にあるのは OneVision-Encoder と OneVision-Encoder-Lang で、README はこれを HEVC スタイルの vision transformer と位置づける。入力モードは画像、均一フレーム動画に加えてコーデックストリームがあり、コーデック入力では動きと残差が多いパッチだけを選択し、密なフレームを疎にサンプリングする。従来の「疎なフレームを密にサンプリングする」発想の逆で、同じトークン予算のもとで時間方向のカバレッジを伸ばす。README の図の説明には、54 トークン予算で均一サンプリングより3倍広い時間範囲をカバーすると記されている。ただしこれは README が示す主張であり、独立した検証結果ではない。モデル本体は LLaVA-OneVision-2-8B-Instruct で、タスク別アダプタを足さずに長尺動画、3D 空間推論、文書・OCR・チャートを同じ重みで扱うと説明されている。
学習パイプラインがデータセット単位で外部に開かれている
このリリースの特徴は、モデル重みだけでなくエンコーダ重み、学習コード、設定ファイル、学習ログまで同梱されている点だ。データセットは4本で、新規の LLaVA-OneVision-2-VideoCaption（高密度な動画キャプション）と LLaVA-OneVision-2-Spatial（3D 空間推論）、1.5 から引き継いだ LLaVA-OneVision-1.5-Mid-Training-85M（8,500万件の概念バランス調整済み中間学習コーパス）と LLaVA-OneVision-1.5-Instruct（指示チューニング混合）である。中間学習コーパスが公開されていることの実務的な意味は大きい。モデルの挙動を自分のドメインに寄せたいとき、ゼロから事前学習するのではなく、この段階から差し替えて再学習する経路が取れる。ただしデータ量が大きいため、ストレージと転送のコストは導入前に見積もる必要がある。
4B 単一ノードの Quick Start と評価再現の分岐
README の目次には Quick Start (4B, single node) の節があり、8B ではなく 4B 構成で単一ノードから入る導線が用意されている。ただし提供された README にはその節の本文が含まれていないため、具体的なコマンドや設定キーはここでは示せない。確認できるのは評価再現の経路のほうで、報告値の評価設定は lmms-eval の llava-onevision2 ブランチに置かれている。そのブランチには評価用のモデルラッパー、ベンチマークとタスクの設定、Docker 環境、薄いランチャースクリプトが含まれ、frames バックエンドと codec バックエンドの両方に対応すると README は説明する。再現手順は同ブランチの README.md にまとまっている。つまり学習側はこのリポジトリ、評価側は lmms-eval の別ブランチ、という2リポジトリ構成を前提にしている。
推論側は vLLM、学習側は NeMo と、経路が分かれている
デプロイの選択肢として README は vLLM の llava_onevision2 モデル実装へのリンクを挙げている。学習・評価の文脈では、1.5 系について NVIDIA NeMo AutoModel のモデルカバレッジへのリンクも示されている。ここは注意点で、vLLM 側の対応は 2 系、NeMo 側の記載は 1.5 系であり、同じツールが両バージョンを等しくカバーしているわけではない。推論を vLLM で回しつつ学習を NeMo で、という構成を取るなら、2 系の学習レシピが NeMo 側に用意されているかを別途確認する必要がある。README からはそこまで読み取れない。
このフレームワークが向かない場面
第一に、画像1枚の分類や VQA をホスト型 API で済ませているプロダクトには不要である。8B の重みを自前でホストする運用コストに見合う利得は、単一画像タスクでは出にくい。第二に、コーデック整合サンプリングの利点は動画に限定される。静止画や文書中心のワークロードでは、OneVision-Encoder のコーデック入力モードを使う理由がない。第三に、評価の再現には lmms-eval の特定ブランチと Docker 環境が前提になる。自前のベンチマークで比較したい場合、この評価スタックをそのまま流用できるとは限らない。そして最も実務的な制約は、README が示す性能の図がすべてリポジトリ内の SVG であり、第三者の追試ではないという点だ。数値を意思決定の根拠にするなら、llava-onevision2 ブランチで自分で回すのが先になる。
1.5 との関係と Apache-2.0 の及ぶ範囲
1.5 は 2025年12月26日付、2.0 は 2026年8月6日付のリリースで、リポジトリは 1.5 のコードを 1.5 ブランチとして残している。つまり 2 系へ移るか 1.5 に留まるかは、データセットとエンコーダの対応関係を含めて選ぶことになる。1.5 には RL レシピが別リポジトリとして公開されており、2 系で同種のレシピが揃っているかは README からは判断できない。ライセンスはリポジトリ全体が Apache-2.0 と明記されているが、これはコードに対する指定である。Hugging Face 上に置かれたモデル重みとデータセットのライセンス条件は別途確認が必要で、Apache-2.0 がそれらに自動的に及ぶとは限らない。学習ログや設定ファイルを社内の派生モデルに同梱する場合も、配布物ごとに条件を確認するのが安全である。
編集部の結論
自前の動画・空間データでマルチモーダルモデルを再学習したい研究チーム、特に長尺動画のトークン予算に悩んでいる場合は検討対象になる。逆に、画像1枚の VQA を API 経由で済ませたいプロダクトや、GPU を1枚しか持たないチームには過剰で、量子化済みの小型モデルのほうが現実的だ。導入前に確認すべきは3点。llava-onevision2 ブランチの lmms-eval で報告値が手元で再現するか、OneVision-Encoder のコーデック入力モードが自分の動画コーデックに対応するか、そして Hugging Face 上のデータセットとエンコーダ重みのライセンス条件が自社の利用形態に合うかである。ここが噛み合わなければ、このフレームワークを選ぶ理由は薄い。
コミュニティノート