ByteDance Lanceは3Bで画像と動画の理解・生成・編集をまとめたApache 2.0モデル

ByteDance ResearchのLanceがHugging Faceに出ていた。
3Bのアクティブパラメータで、画像と動画の理解、生成、編集を同じ枠組みに入れたモデルだ。
ライセンスはApache 2.0。モデルカードでは、Python 3.10以上、CUDA 12.4以上、推論用GPUは40GB以上のVRAMが必要と書かれている。

手元のM1 MaxやRTX 4060 Laptopで軽く試すタイプではない。
ただ、画像生成モデル、動画生成モデル、VLMを別々に立てる構成とはアプローチが違う。
FastAPI・Chroma・Open WebUI・Ollamaでマルチモーダル日本語RAGをM1 Maxで組んだときは、検索、画像説明、最終回答を別モデルに分けた。
Lanceはその分担を共通アーキテクチャの統合モデルに集約した研究実装だ。

1つのCLIに6タスクを通す

GitHubのREADMEでは、inference_lance.sh からタスクを切り替える形になっている。
対応タスクは t2i、t2v、image_edit、video_edit、x2t_image、x2t_video。
テキストから画像、テキストから動画、画像編集、動画編集、画像理解、動画理解を同じコードパスで呼ぶ。

flowchart TD
    Text[テキスト] --> Context[共有された<br/>マルチモーダル文脈]
    Image[画像] --> Context
    Video[動画] --> Context
    Context --> Understand[理解系<br/>画像QA・動画QA]
    Context --> Generate[生成系<br/>画像・動画生成]
    Context --> Edit[編集系<br/>画像・動画編集]

プロジェクトページの説明では、テキスト、画像、動画の文脈を共有された系列として扱い、理解と生成の経路は別エキスパートに分ける。
理解側には意味理解用のViTトークン、生成側にはノイズなしとノイズありのVAE潜在表現を使う。
さらにモダリティ対応RoPEで異種の視覚トークン同士の干渉を減らす構成になっている。

動画編集のデモでは背景置換、物体追加、人物の動作変更、スタイル変更まで同じモデルカード上に並んでいる。
動画理解の例では、動作回数、移動方向、映像内の不自然な現象、料理手順の短い説明を返している。

3Bなのにベンチマーク上は動画側が強い

Lanceは3Bのまま、マルチタスク学習の組み方でベンチマークを伸ばしている。
モデルカードと論文ページによると、128基以内のA100 GPU予算でスクラッチから学習した。
3Bというサイズだけ見ると軽量だが、ローカルで軽いという意味ではない。40GB VRAM要求なので、実行環境はA100、L40S、A6000、H100あたりが現実的になる。

公開ベンチマークでは、画像生成のGenEVALで総合0.90。
同じ表ではQwen-Imageが0.87、FLUX.1-devが0.82、統合モデルのTUNAが0.90なので、Lanceは統合モデル側の上位に並ぶ。
DPG-Benchは総合84.67で、Qwen-Imageの88.32やTUNAの86.76より低いが、関係理解の項目は93.38と高い。

動画生成のVBenchでは、統合モデル群でLanceが総合85.11。
TUNA 1.5Bの84.06、Show-o2 2Bの81.34より上に出ている。
生成専用モデルも含めた表ではWan2.1-T2V 14Bが83.69、Hunyuan Videoが83.43なので、3Bの統合モデルが生成専用の14Bモデルを上回る結果になっている。

一方で、画像理解のデモには誤りもある。
Hugging Faceのモデルカード上では、皆既日食の説明で地球の影に触れるような不正確な記述が載っている。
理解系はベンチマークの表だけでは精度の傾向がつかめず、サンプル出力まで見て初めて癖が出てくる。
VLMとしての回答品質は、Qwen2.5-VLやQwen3-VL系と同じ入力で出力を並べると差が出る。

RAG用Embeddingとは別の統合

Sentence Transformers v5.4でテキスト・画像・音声・動画の統合Embeddingが可能にでは、検索用の統合インターフェースを扱った。
あれは入力をベクトルに落として検索するための統合で、最終的な回答や画像生成は別モデルが担当する。

Lanceは画像や動画を読んで回答し、必要なら生成や編集まで同じモデルで進める。
Embeddingモデルが検索のインターフェースを統合するのに対し、Lanceは制作ワークフロー全体を1本のモデルに収めている。

ただし、現時点の実用面では分離構成のほうが扱いやすい場面が多い。
Embeddingは軽量モデルで回し、画像理解はVLM、最終回答はLLM、画像生成はComfyUIやAPIに逃がす。
この分け方なら、ローカルのメモリ制約や品質差に合わせて部品を入れ替えられる。
Lanceの40GB VRAM要求は、この分離構成を統合モデル1本に集約した結果だ。

触る前に見るファイル

GitHubには benchmarks/、config/、data/、modeling/、inference_lance.py、inference_lance.sh が置かれている。
モデル重みはHugging Faceから落として downloads/ に置く前提。
Gradioデモは python lance_gradio_t2v_v2t.py --gpus 0 --server-port 7860 で起動する形になっている。

推論パラメータは inference_lance.sh 側で変える。
デフォルトではノイズ除去ステップが30、CFGスケールが4.0、動画フレーム数が50、動画解像度プリセットが480p。
最大フレーム数は121と書かれている。

試すなら、Hugging Faceのモデルカードにあるサンプルと同じプロンプト形式から入る。
README側でも、入力プロンプトは提供例の形式に合わせるよう書かれていた。
画像生成や動画生成のモデルは、同じ意味でもプロンプトの言い回しで崩れ方が変わる。
Lanceもそこは例外ではなさそうだった。

RunPodで動かすならどのGPUか

手元のM1 MaxやRTX 4060 Laptopでは動かないので、クラウドGPUの出番になる。
RunPodで立てる場合のVRAM・ストレージ・費用感を試算した。

重みファイルのサイズ

Hugging Faceリポジトリの合計は約57.4GB。
画像モデルと動画モデルは別の重みファイルになっていて、両方落とすと以下の構成になる。

コンポーネント	サイズ
Lance_3B（画像モデル）	24.7 GB
Lance_3B_Video（動画モデル）	28.4 GB
Qwen2.5-VL-ViT	1.34 GB
Wan2.2 VAE	2.82 GB

画像だけ試すなら Lance_3B + ViT + VAE で約28.9GB。
動画まで含めると Lance_3B_Video + ViT + VAE で約32.6GB。
両方落とすなら約57.3GB。
PyTorch+CUDA 12.4のPython環境が別に4〜6GB使うので、ディスクは最低でも70GB、余裕を見て100GBのボリュームを確保しておく。

VRAM試算

モデルカードの要件は40GB以上。
重みをbf16でVRAMに載せたときの内訳を概算すると、画像モデルの場合で静的な重みだけで約28.9GB。
推論時にはKVキャッシュと中間アクティベーションが数GB乗るので、実際の消費は35〜40GBあたりになる。

動画モデルは重みが28.4GBと大きく、50フレームのデコードでアクティベーションも増える。
静的重み+ViT+VAEで約32.6GB、推論中は40GB前後まで伸びる見込みだ。
A100 40GBだとギリギリかOOMの境界で、動画生成は厳しい。

量子化（int8やint4）のワークフローは現時点で提供されていない。
requirements.txt に bitsandbytes は入っているが、ドキュメントに量子化手順の記載はなく、自前で試すことになる。

RunPodのGPU候補

40GB以上のVRAMを積んだGPUで、RunPodで選べる現実的な候補は4つ。
価格はCommunity Cloud（空きがあれば安い代わりにプリエンプトされる可能性あり）の目安。

GPU	VRAM	価格帯（目安）	備考
A6000	48 GB	$0.76/hr前後	コスパ重視ならこれ。画像モデルは余裕、動画モデルも収まる
L40S	48 GB	$0.74/hr前後	A6000とほぼ同価格帯。Ada Lovelace世代で推論速度はやや速い
A100 80GB SXM	80 GB	$1.64/hr前後	VRAM余裕あり。動画モデルでも安心
H100 80GB SXM	80 GB	$3.49/hr前後	最速だが割高。短時間で終わらせたいとき

A100 40GBは画像モデルなら動く可能性はあるが、動画モデルではOOMリスクが高い。
L40SかA6000の48GBが費用対効果の落としどころになる。

セットアップ時間とセッション費用

RunPodでPodを立てた後、最初の作業はモデル重みのダウンロードとPython環境構築になる。
Hugging Faceから57GBを落とすのに、RunPodのネットワーク帯域にもよるが20〜40分程度。
pip install で70以上のパッケージをビルドするのにさらに10〜15分。
初回セットアップだけで30分〜1時間かかる。

2回目以降はネットワークボリュームに重みを置いておけばダウンロード不要になる。
ボリュームストレージはRunPodで$0.07/GB/月なので、100GBのボリュームを1か月維持して$7。

テストセッションの費用感としては、L40Sで3時間触って約$2.2。
初回セットアップを含めて4時間なら約$3。
Gradioデモを立てて画像生成と動画生成を一通り試す程度なら、この範囲に収まる。

`inference_lance.sh` のNUM_GPUS

inference_lance.sh には NUM_GPUS パラメータがあり、デフォルトは1。
RunPodでマルチGPU構成のPodを立てれば複数GPUに分散できる。
ただし、1枚で48GB以上のGPUを使えるなら分散の必要はない。
マルチGPU分散はA100 40GB×2のような構成で40GBの壁を回避する場合に使う。

「統合モデル」なのに重みが2つに分かれている

重みファイルの表を見ると、Lance_3B（画像モデル、24.7GB）とLance_3B_Video（動画モデル、28.4GB）は別のチェックポイントだ。
画像系タスクにはLance_3Bを、動画系タスクにはLance_3B_Videoを読み込む。
ViTとVAEは共有しているが、Transformer本体の重みは別になっている。

Qwen系列は最初から別モデルとして出している。
理解がQwen2.5-VL、画像生成がQwen-Image、動画がWan2.2。
名前もリポジトリも分かれていて、それぞれ独立にバージョンが上がる。
重みが別なのは見た目から分かるし、組み合わせて使う前提だ。

Lanceは「統合マルチモーダルモデル」と銘打っているが、1つの重みファイルで画像も動画も全タスクこなす構成にはなっていない。
統合されているのはアーキテクチャと学習パイプラインの部分だ。
テキスト・画像・動画のトークンを同じTransformerに通し、マルチタスク学習でタスク間の性能を底上げする設計で、推論スクリプトやCLIオプションも共通になっている。

ただ、重みが2つに分かれている時点で、ダウンロードして環境を組む体験はQwen方式と大きく変わらない。
画像も動画も使いたければ57GB分の重みを落とす。

推論でも、画像系タスク（t2i、image_edit、x2t_image）は Lance_3B を、動画系タスク（t2v、video_edit、x2t_video）は Lance_3B_Video をロードする。
画像理解から動画生成に流すような連続ワークフローでは、途中でチェックポイントの載せ替えが入る。
80GBのA100でも57GBの重みを同時にVRAMに展開するのは無理なので、タスクをまたぐたびに再ロードが要る。

Qwen方式で Qwen-Image から Wan2.2 にリレーするのと、インフラ側の手間は変わらない。
Lanceの「統合」が掛かっているのは学習フェーズだ。
画像と動画を同一Transformerでマルチタスク学習した結果、表現の転移でベンチマークが伸びている。
推論側に降りてくるのは、その学習効果を反映した2本の別チェックポイントだ。