はじめに: なぜビジョン言語モデルか
テキストのみを扱っていた LLM が画像も理解し始めたことで、文書解析、チャート読解、UI 自動化、ロボティクスといった領域が一気に開かれました。しかし LLM は本質的にトークン列を次トークン予測で処理するモデルです。画像のような 2 次元のピクセル格子データを、どうやってテキストトークンと同じ平面に載せられるのでしょうか。
核心となる考え方はシンプルです。画像を小さな断片に分割し、各断片をベクトルに変換し、そのベクトルを LLM が扱う埋め込み空間に整列させるのです。そうすれば、画像断片の一つひとつがまるで単語トークンのように振る舞います。本記事では、その変換過程をビジョンエンコーダ、プロジェクタ、LLM デコーダという 3 つの部品に分けて深く見ていきます。
この構造を正しく理解すれば、なぜあるモデルは高解像度文書に強く、別のモデルはトークンコストが爆発するのか、任意解像度処理がなぜ難しい問題なのかが自然に見えてきます。
テキストモデルと何が違うか
純粋なテキスト LLM は入力がすでにトークンです。トークナイザが文字列を整数 ID の系列に変え、埋め込みテーブルが各 ID をベクトルにマッピングすれば終わりです。しかし画像にはトークナイザがありません。ピクセルを直接整数 ID へマッピングする表が存在しません。
そこでビジョン LLM はトークナイザの代わりにビジョンエンコーダというニューラルネットワークを置きます。これが核心的な違いです。テキストはルックアップテーブルでトークンを得ますが、画像は学習されたエンコーダを通して連続的な特徴ベクトルを得ます。このベクトルがビジュアルトークンの役割を果たします。
テキスト経路: 文字列 -> トークナイザ(ルックアップ) -> トークン ID -> 埋め込み -> ベクトル
画像経路: ピクセル -> ビジョンエンコーダ(ニューラルネット) -> 連続特徴 -> プロジェクタ -> ベクトル
二つの経路の終点は同じです。どちらも LLM が扱える同じ次元のベクトル系列へ収束します。違いは出発点だけです。この観点をつかめば、ビジョン LLM が結局テキスト LLM に画像入力経路を一つ追加したものだと分かります。
核心原理: 3 つの部品で見るビジョン LLM
現代のビジョン言語モデル(VLM)の多くは、3 つの構成要素から成ります。
1. **ビジョンエンコーダ**: 通常は ViT 系。画像を受け取り、視覚的特徴ベクトルの系列へ変換します。
2. **ビジョン言語プロジェクタ / アダプタ**: ビジョンエンコーダの出力次元を LLM の埋め込み次元へ合わせ、意味的に整列します。線形層、MLP、あるいは Q-Former 系の圧縮モジュールが使われます。
3. **LLM デコーダ**: テキストトークンと投影されたビジュアルトークンを 1 つの系列として受け取り、次トークンを予測します。
全体のデータフローは次のようになります。
[画像]
|
v
[パッチ分割] --> パッチを平坦化して埋め込み
|
v
[ViT ビジョンエンコーダ] --> 視覚特徴の系列
|
v
[プロジェクタ / アダプタ] --> LLM 次元へ投影 (+ 圧縮)
|
v
[ビジュアルトークン] + [テキストトークン] --> 1 つの系列にインターリーブ
|
v
[LLM デコーダ] --> 自己回帰的にテキスト生成
このスタックは端から端まで一緒に学習されることもあれば、ビジョンエンコーダを凍結したままプロジェクタと LLM だけを学習することもあります。学習戦略は別記事で扱い、ここでは推論時にデータがどう流れるかに集中します。
深掘り 1: 画像をパッチからトークンへ
パッチ分割とパッチ埋め込み
ViT の出発点は画像を固定サイズのパッチに分割することです。たとえば 224 x 224 の画像を 14 x 14 ピクセルのパッチに分けると、横 16 個、縦 16 個、合計 256 個のパッチができます。各パッチはピクセル値を平坦化したのち線形投影を経て、1 つの埋め込みベクトルになります。
テンソルの shape で追うと次のようになります。
入力画像: B x 3 x H x W (バッチ, チャネル, 高さ, 幅)
パッチ分割後: B x N_patch x (P*P*3) (P はパッチ一辺のピクセル数)
パッチ埋め込み後: B x N_patch x D (D はビジョンエンコーダの hidden dim)
ここで N_patch は (H / P) x (W / P) で計算されます。224 x 224 の画像にパッチサイズ 14 を使うと N_patch は 256 になります。この時点で画像はすでに系列になっており、以降はテキストトークン列と同じくトランスフォーマー層を通過します。
位置情報とトランスフォーマーエンコーディング
パッチを平坦化すると 2 次元の空間情報が失われるため、ViT は位置埋め込みを加えます。その後、複数層のセルフアテンションと FFN を通り、各パッチが周囲のパッチの情報を吸収します。出力は入力と同じ長さの系列で、各位置が視覚的に豊かになった特徴ベクトルになります。
ViT 内部のアテンションはテキストトランスフォーマーと同じスケールド・ドットプロダクト形式です。
attention(Q, K, V) = softmax(QK^T / sqrt(d_k)) V
Q, K, V はパッチ特徴から線形投影で得たクエリ、キー、バリューであり、d_k は各ヘッドの次元です。マルチヘッドで複数の部分空間の関係を同時に学習します。
ビジュアルトークン数こそコスト
この段階で重要な直観を 1 つ。ビジュアルトークンの数は画像解像度に比例します。解像度を 2 倍にするとパッチ数は約 4 倍になり、LLM が処理すべき系列長もそれだけ伸びます。LLM のアテンションは系列長に対して 2 乗で高くつくため、ビジュアルトークン数を減らすことはコストに直結します。プロジェクタが単に次元を合わせるだけでなくトークンを圧縮することがあるのはこのためです。
深掘り 2: プロジェクタ — ビジョンと言語をつなぐ橋
ビジョンエンコーダの出力次元は LLM の埋め込み次元と異なることがあり、意味空間も整列していません。プロジェクタはこの隔たりを埋めます。大きく 2 つの系統があります。
線形 / MLP プロジェクタ
最もシンプルな方式です。ビジョンエンコーダが出した各視覚特徴を線形層または 2 層 MLP で LLM 次元へ投影します。トークン数はそのまま保たれます。
ビジョンエンコーダ出力: B x N_v x D_vis
線形/MLP 投影後: B x N_v x D_llm (トークン数 N_v 維持, 次元のみ D_vis -> D_llm)
- 利点: 構造が単純で、視覚情報を損失なくそのまま伝えます。
- 欠点: トークン数が減らないため高解像度で系列が長くなりコストが大きくなります。
LLaVA 系がこの単純な MLP 方式を普及させました。実装が容易で性能も良く、広く使われています。
Q-Former 系の learnable query 圧縮
もう一つの系統は学習可能なクエリベクトルを置き、クロスアテンションで視覚特徴から情報を引き出して固定数のトークンへ圧縮する方式です。BLIP-2 の Q-Former が代表例です。
学習クエリ: B x N_q x D (N_q は 32 など固定, パッチ数と無関係)
ビジョン特徴(キー/バリュー): B x N_v x D_vis
クロスアテンション: クエリがビジョン特徴から情報を吸収
出力: B x N_q x D_llm (N_v -> N_q へ圧縮)
- 利点: ビジュアルトークンを固定の少数へ圧縮するため LLM 系列が短くなりコストが削減されます。
- 欠点: 圧縮過程で細かな視覚情報が失われることがあり、精密な OCR や文書理解では不利になりえます。
圧縮型は自然画像のキャプショニングのように大きな絵が重要なタスクに向き、非圧縮型(MLP)は小さな文字や表を読む文書タスクに有利な傾向があります。
深掘り 3: ビジュアルトークンを LLM へ注入する
プロジェクタを通過したビジュアルトークンは、いまや LLM の埋め込み空間の上にあります。これをテキストと 1 つの系列に編み込むことをインターリーブと呼びます。
インターリーブの基本形
チャット入力で画像が入る位置に特殊なプレースホルダトークンを置き、LLM に入れる直前にその位置をビジュアルトークン群に置換します。
元の系列: [テキスト...] [IMG_PLACEHOLDER] [テキスト...]
置換後: [テキスト...] [v1][v2]...[vN] [テキスト...]
こうして作られた統合系列は、LLM から見ればただ 1 つの長い埋め込み系列です。セルフアテンションがテキストトークンとビジュアルトークンを区別なく一緒に見て、質問テキストが画像の特定領域を指すように学習されます。
複数画像や画像テキスト混在文書も同じ原理で処理されます。画像が現れる順にビジュアルトークンブロックを挟み込めばよいのです。
マルチ画像: [テキスト] [img1 トークン群] [テキスト] [img2 トークン群] [テキスト]
因果マスクとビジュアルトークン
LLM デコーダは因果(causal)マスクを使い、各位置が自分より前のトークンだけを見るようにします。ビジュアルトークンもこのマスク規則に従います。つまり画像の後に来るテキストは画像トークンを参照できますが、画像トークン自体は通常その前の文脈だけを見ます。一部のモデルは画像トークン間に双方向アテンションを許し、1 つの画像内ではすべてのパッチが互いを見られるようにします。これは実装ごとの設計選択です。
深掘り 4: 任意解像度処理
初期の VLM は入力画像を固定サイズ(例: 336 x 336)へ強制リサイズしていました。それでは横長の文書や小さな文字がつぶれて情報が失われます。最近のモデルは任意解像度をそのまま扱おうとします。
Qwen2-VL の naive dynamic resolution
Qwen2-VL は画像を固定サイズに強制せず、元の解像度に比例する数のビジュアルトークンを動的に生成します。大きい画像はより多くのトークンで、小さい画像はより少ないトークンで表現されます。おかげで縦横比と細かなディテールが保存され、文書やチャートの理解に有利になります。
小さい画像(例: 448x448): 少数のビジュアルトークン
大きい画像(例: 1568x1568): 多数のビジュアルトークン
横長の文書: 元の比率を維持, 横方向のパッチ数が多くなる
実務では最小/最大トークン数に上限を設け、大きすぎる画像が文脈を爆発させないよう調整します。
M-RoPE: マルチモーダル回転位置エンコーディング
位置エンコーディングも問題です。テキストは 1 次元の順序を持ちますが、画像は 2 次元の格子です。Qwen2-VL は M-RoPE(Multimodal Rotary Position Embedding)を導入し、位置を時間、高さ、幅という複数の成分へ分解します。テキストトークンはこれらの成分が同じ値を共有し、画像トークンは高さと幅の成分が 2 次元座標を反映します。
テキストトークン: (t, t, t) 3 成分が同じ位置インデックス
画像トークン: (t, h, w) 高さ/幅成分が格子座標を反映
これにより 1 つのモデル内で 1 次元テキストと 2 次元画像の位置を一貫して表現でき、動画のように時間軸が加わる場合へ自然に拡張できます。
比較テーブル: プロジェクタの設計選択
| 項目 | 線形 / MLP プロジェクタ | Q-Former 系圧縮 |
| --- | --- | --- |
| トークン数 | パッチ数をそのまま維持 | 固定の少数へ圧縮 |
| 視覚情報の保存 | 高い, ほぼ無損失 | 圧縮過程で一部損失 |
| LLM 系列長 | 長い, コスト大 | 短い, コスト削減 |
| 文書/OCR 適性 | 有利 | 相対的に不利 |
| 自然画像キャプショニング | 適合 | 適合 |
| 実装の複雑さ | 低い | 高い |
| 代表例 | LLaVA 系 | BLIP-2 Q-Former |
| 項目 | 固定解像度 | 任意解像度(dynamic) |
| --- | --- | --- |
| 入力処理 | 固定サイズへリサイズ | 元の比率/解像度を保存 |
| 小さい文字/ディテール | 損失リスク | よく保存 |
| トークン数 | 一定 | 画像サイズに比例, 可変 |
| 文書/チャート理解 | 弱い | 強い |
| 文脈コスト | 予測可能 | 上限管理が必要 |
深掘り 5: 数字で追うトークン予算
抽象的な説明だけではコスト感覚がつかめないので、具体的な数字で追ってみます。パッチサイズ 14、ビジョンエンコーダ hidden dim 1024 を仮定します。
ケース A: 一般写真 896 x 896
横パッチ数 = 896 / 14 = 64
縦パッチ数 = 896 / 14 = 64
ビジュアルトークン数 = 64 x 64 = 4096
ケース B: 横長の文書 1568 x 784
横パッチ数 = 1568 / 14 = 112
縦パッチ数 = 784 / 14 = 56
ビジュアルトークン数 = 112 x 56 = 6272
ケース C: サムネイル 224 x 224
横/縦パッチ数 = 16 x 16
ビジュアルトークン数 = 256
ここで一つ明確になります。同じモデルでも入力画像サイズによってビジュアルトークンが 256 個から 6000 個以上まで揺れます。マルチターン対話に画像が複数入ると文脈の大半をビジュアルトークンが占めることもあります。そのため多くのモデルが 2 x 2 パッチ統合のようなダウンサンプリングをビジョンエンコーダの後に置き、LLM へ渡すトークン数を 4 分の 1 に減らします。
パッチ統合(2x2)の例
ビジョンエンコーダ出力: 64 x 64 = 4096 トークン
2x2 統合後: 32 x 32 = 1024 トークン (4 つを 1 つに統合)
このダウンサンプリングはディテールを少し犠牲にする代わりに LLM 系列を大きく減らします。文書のように小さな文字が重要な場合は統合の強度を下げ、一般写真のように大きな絵が重要なら積極的に減らすなど、タスクに合わせて調整します。
深掘り 6: ViT エンコーダの選択と事前学習
ビジョンエンコーダはどんな ViT でもよいわけではなく、通常は大規模な画像テキスト対照学習で事前学習されたエンコーダを持ってきます。テキストと対にして学習されたビジョンエンコーダはすでに言語とある程度整列した視覚表現を出すため、後続のプロジェクタの負担が減ります。
- **対照事前学習エンコーダ**: 画像とキャプションを同じ空間へ引き寄せるよう学習したエンコーダ。意味的に豊かな表現を与えます。
- **高解像度適応**: 文書タスクが重要なら、エンコーダを高解像度入力に合わせて追加適応させる段階を置きます。
- **最終層 vs 中間層**: どの層の特徴をプロジェクタへ渡すかも選択肢です。最終層は意味的で、中間層はより細かな視覚情報を含む傾向があり、タスクによって組み合わせることもあります。
エンコーダの品質が VLM 全体の性能の上限をある程度決めます。エンコーダが小さな文字を区別できなければ、後の LLM がいくら賢くてもその情報を復元できません。だから文書・OCR を狙うならエンコーダ段階の解像度と表現力に特に気を配るべきです。
深掘り 7: 複数画像と動画への拡張
単一画像を処理する原理はそのまま複数画像と動画へ拡張されます。
- **複数画像**: 各画像を独立にビジュアルトークン化したのち、登場順にテキストとインターリーブします。モデルはどのテキストがどの画像を指すかを位置で区別します。
- **動画**: フレームを一定間隔でサンプリングして各々をビジュアルトークンに変え、時間軸の位置成分を加えて順序を与えます。M-RoPE の時間成分がここで自然に使われます。
動画処理の流れ
[フレーム1][フレーム2]...[フレームT] --> 各々ビジュアルトークン化
|
v
時間成分 t=1,2,...,T を付与 --> フレーム順序を保存
|
v
[質問テキスト] + [フレームトークン群] --> LLM デコーダ
動画はフレーム数に比例してトークンが爆発するため、フレームサンプリング間隔とフレームあたり解像度を一緒に調整してトークン予算を管理するのが核心です。長い動画ほどフレームをまばらに抜き、短くディテールが重要な動画は密に抜くといった折衷が必要です。
実務の観点: 推論時に何を気にするか
ビジョン LLM をサービスに載せるとき、まずぶつかるのはビジュアルトークンコストです。高解像度文書 1 枚が数千トークンを占めることがあり、テキストのみのときより文脈が速く埋まります。
- **トークン上限の設定**: 任意解像度モデルは画像あたりの最大トークン数を制限し、文脈と遅延を制御します。
- **解像度とコストのトレードオフ**: 小さい文字を読むには解像度を上げる必要がありますが、その分トークンが増えてコストと遅延が大きくなります。タスク要件に合わせて均衡点を取ります。
- **トークンプルーニング**: 重要度の低いビジュアルトークンを推論中に間引いて系列を短くする研究が活発です。情報損失と速度の均衡が鍵です。
- **画像前処理の一貫性**: 学習時と同じパッチサイズ、正規化、リサイズ規則を推論でも守らないと性能低下を招きます。
ビジュアルトークンは LLM デコーディングとともに KV キャッシュを占めます。したがってマルチターン対話で同じ画像を繰り返し参照すると、キャッシュが累積してメモリ圧迫が大きくなりえます。prefix キャッシュの再利用や画像埋め込みのキャッシュで緩和できます。
深掘り 11: サービングの観点の追加考慮
ビジョン LLM を実際にサービングするときはテキスト LLM サービングと異なるいくつかのディテールが加わります。
- **画像前処理コスト**: デコード・リサイズ・正規化も時間を食います。大きな画像が多いと前処理がボトルネックになりえるため、別ワーカーに分離するかキャッシュします。
- **可変長バッチ**: 画像サイズがまちまちでリクエストごとに系列長が異なります。連続バッチング(continuous batching)とよく合わせてこそ処理量が出ます。
- **ビジュアルトークン KV キャッシュ**: 同じ画像をマルチターンで繰り返し参照するなら、そのビジュアルトークンの KV をキャッシュして再計算を避けられます。
- **プリフィルの比重**: ビジュアルトークンは通常プリフィル段階で一度に処理されます。画像が大きいとプリフィルが長くなり最初のトークンまでの遅延が増えます。
ビジョン LLM サービングパイプライン
[リクエスト: 画像 + テキスト]
|
v
[画像前処理] (別ワーカー可能)
|
v
[ビジョンエンコーダ + プロジェクタ] プリフィルでビジュアルトークン生成
|
v
[LLM プリフィル + デコード] 連続バッチングでまとめて処理
|
v
[応答ストリーミング]
核心は画像経路が追加されることでプリフィルコストと前処理コストがテキスト専用より大きくなる点です。画像サイズ上限, 前処理の分離, キャッシュがサービング効率の主要なつまみです。
落とし穴とトラブルシューティング
- **解像度の不一致**: 学習時に見たことのない極端なアスペクト比や超高解像度画像で品質が急落しえます。入力サイズをモデルが耐える範囲へ正規化してください。
- **プレースホルダ数の不一致**: インターリーブ時にプレースホルダトークン数と実際のビジュアルトークン数がずれると系列整列が壊れます。前処理パイプラインで必ず数を検証してください。
- **圧縮モデルのディテール損失**: Q-Former 系でトークンを強く圧縮すると小さな文字や表セルがつぶれます。OCR 精度が重要なら非圧縮または高解像度経路を検討してください。
- **位置エンコーディング前提の違反**: 動画や複数画像入力で位置成分の計算が学習前提とずれると空間推論が乱れます。モデルが推奨する前処理ルーチンに従うのが安全です。
- **正規化統計の不一致**: ビジョンエンコーダが期待する平均/標準偏差で正規化しないと特徴が歪みます。モデルカードの前処理仕様を確認してください。
深掘り 7.5: 画像前処理のディテール
ビジュアルトークンの品質はモデルに入る前の前処理で半分決まります。よく見落とされますが結果に大きく影響する段階です。
- **リサイズ補間**: 画像をパッチ格子に合わせるにはサイズ調整が必要です。補間方式(バイリニア, バイキュービックなど)によって小さな文字の鮮明さが変わります。
- **正規化**: ビジョンエンコーダは特定の平均・標準偏差で正規化された入力を期待します。この統計がずれると特徴が歪み性能が落ちます。
- **パディングと比率**: 正方形でない画像を扱うとき、パディングで埋めるか、比率を維持して動的トークンを使うかを選びます。
- **色空間**: RGB チャネル順序や色空間が学習と異なると微妙な誤りが生じます。
前処理チェックリスト
[ ] 学習と同じリサイズ規則
[ ] 学習と同じ正規化統計 (平均/標準偏差)
[ ] チャネル順序の一致 (RGB)
[ ] パッチサイズで割り切れるサイズ
[ ] 縦横比の処理方式の一致
このチェックリストのどれか一つでもずれると、モデルは同じ重みを使っても学習時より悪い結果を出します。デバッグ時にモデルより前処理を先に疑えという格言がビジョン LLM で特に有効です。
深掘り 8: 融合方式 — インターリーブ vs クロスアテンション
ここまではビジュアルトークンをテキストと同じ系列に挟み込むインターリーブ(またはデコーダ融合)方式を中心に説明しました。しかしビジョンと言語を混ぜる方法はこれだけではありません。大きく 2 つの系統に整理できます。
方式 A: インターリーブ(デコーダ融合)
ビジュアルトークンをテキストトークンと同じ入力系列に挿入
LLM のセルフアテンションが両者を一緒に処理
代表: LLaVA 系, Qwen2-VL 系
方式 B: クロスアテンション融合
LLM レイヤーの間にクロスアテンションブロックを挿入
テキストはセルフアテンション, 画像情報はクロスアテンションで注入
代表: 一部のゲート付きクロスアテンション構造
- **インターリーブ**: 実装が単純で LLM 構造をほぼそのまま使います。ただしビジュアルトークンが文脈長を直接占めます。
- **クロスアテンション**: 画像情報を別経路で注入するためテキスト系列長を伸ばしません。代わりに LLM 内部に追加ブロックが入り構造が複雑になります。
最近のオープンモデルの多くは単純さと強力さを理由にインターリーブ方式を選ぶ傾向があります。しかし文脈コストの大きい高解像度・動画ではクロスアテンション式注入の利点が見直されることもあります。正解はなく、タスクのトークン予算と実装制約によって変わります。
深掘り 9: よく混同される概念の整理
- **ビジュアルトークンとテキストトークンは同じ埋め込み空間か?**: プロジェクタを通過した後は同じ次元の空間にあります。だから LLM が両者を 1 つの系列として処理できます。ただし意味的整列は学習で作られます。
- **ビジョンエンコーダは OCR そのものか?**: いいえ。ビジョンエンコーダは視覚特徴を出すだけで、文字を明示的に読むわけではありません。文字読み能力は LLM とともに学習データで育てられます。
- **トークンを圧縮すると常に損か?**: タスクによります。大きな絵が重要なら圧縮が効率的で、小さな文字が重要なら損です。
- **解像度を上げると常に良いか?**: ディテールは良くなりますがトークンとコストが増え、学習分布を外れる超高解像度ではむしろ品質が落ちることがあります。
- **位置エンコーディングがなぜ重要か?**: 画像は 2 次元の空間情報が核心ですが、トークンへ平坦化するとその情報が消えます。位置エンコーディングがその空間関係を復元します。
これらの概念を明確にしておくと、新しい VLM の技術レポートを読むときどんな設計選択をしたかを素早く把握できます。
深掘り 9.5: モデル選択のための意思決定ガイド
ここまで見た設計軸を実際のモデル選択にどうつなげるか整理します。タスクの性格によって優先順位が変わります。
タスク別の推奨方向
レシート/文書 OCR -> 高解像度 + 非圧縮(MLP)プロジェクタ + 任意解像度
一般画像キャプショニング -> 中解像度 + 圧縮許容, コスト効率優先
チャート/表分析 -> 高解像度 + 構造化出力を学習したモデル
マルチ画像推論 -> トークン効率(圧縮またはパッチ統合)を重視
動画理解 -> フレームサンプリング + 時間位置エンコーディング対応
このガイドは出発点にすぎず、実際には候補モデルをいくつか自分のデータで直接評価するのが最も確実です。ベンチマークスコアは平均的な傾向を示すだけで、自分の文書・自分の画像での挙動は直接測ってみないと分かりません。
判断の核心となる三つの質問を投げてみてください。第一に、小さな文字や細かなディテールが重要か。そうなら解像度と非圧縮経路を優先します。第二に、一つのリクエストに画像が何枚入るか。多ければトークン効率がコストを左右します。第三に、出力が自由テキストか構造化形式か。構造化が必要ならその形式で学習されたモデルを選ぶべきです。
深掘り 10: 全体像を描き直す
最後に、ここまでの部品を 1 つの大きな図にまとめ直します。
[原本画像]
| 前処理: リサイズ/正規化 (学習と同一)
v
[パッチ分割 + パッチ埋め込み] B x N_patch x D_vis
| 位置埋め込みを加える
v
[ViT ビジョンエンコーダ: セルフアテンション x L層] B x N_patch x D_vis
| (任意) 2x2 パッチ統合でダウンサンプル
v
[プロジェクタ: MLP または Q-Former] B x N_v x D_llm
| プレースホルダ位置に挿入
v
[統合系列: テキスト + ビジュアルトークン] インターリーブ
| M-RoPE などで位置付与, 因果マスク
v
[LLM デコーダ: セルフアテンション x M層]
| 次トークン予測
v
[出力: テキスト / 座標 / 構造化]
この 1 枚の流れがビジョン LLM のすべてです。各段階でどんな設計を選んだかがモデルの性格を決めます。エンコーダの解像度, プロジェクタの圧縮有無, 位置エンコーディング方式, 融合戦略 — この 4 つのつまみを回しながら数多くの変種が作られます。
おわりに
ビジョン LLM の核心は、結局のところ画像をトークンへ変換する処理にあります。ViT が画像をパッチ系列にし、プロジェクタがそれを LLM の言語空間へ整列し、インターリーブがテキストとビジュアルトークンを 1 つの流れに編み込みます。そこに任意解像度や M-RoPE のような仕掛けが加わり、モデルは文字がびっしりの文書からワイドなチャートまで柔軟に扱えるようになりました。
設計選択は常にトレードオフです。トークンを圧縮すれば安くなるがディテールを失い、解像度を上げればよく読めるがコストが大きくなります。自分のタスクが何を最も重視するかを知れば、どの構造のモデルを選ぶべきかも明確になります。次の記事ではこの構造をどう学習させるか、入力と出力をどう教えるかを扱います。
参考資料
- Qwen2-VL: Enhancing Vision-Language Model's Perception (arXiv: 2409.12191) — [arxiv.org/abs/2409.12191](https://arxiv.org/abs/2409.12191)
- Attention Is All You Need (arXiv: 1706.03762) — [arxiv.org/abs/1706.03762](https://arxiv.org/abs/1706.03762)
- FlashAttention: Fast and Memory-Efficient Exact Attention (arXiv: 2205.14135) — [arxiv.org/abs/2205.14135](https://arxiv.org/abs/2205.14135)
- Qwen 公式リポジトリ — [github.com/QwenLM](https://github.com/QwenLM)
- Hugging Face Transformers ドキュメント — [huggingface.co/docs](https://huggingface.co/docs)
- PyTorch 公式ドキュメント — [pytorch.org](https://pytorch.org)
- vLLM ドキュメント(マルチモーダルサービング含む) — [docs.vllm.ai](https://docs.vllm.ai)
- vLLM リポジトリ — [github.com/vllm-project/vllm](https://github.com/vllm-project/vllm)
현재 단락 (1/225)
テキストのみを扱っていた LLM が画像も理解し始めたことで、文書解析、チャート読解、UI 自動化、ロボティクスといった領域が一気に開かれました。しかし LLM は本質的にトークン列を次トークン予測で...