Skip to main content

VGGT Architecture

VGGT の architecture を一言で言えば、「multi-view image を共通の token 列として扱い、一つの大きな transformer に通す」という構成です。Task 別の専用 head は最小限にとどめ、共通の transformer body が geometry の重い推論を担当します。

Tokenization​

各 image は、patch ごとに token へ分割されます。Vision Transformer や DINO 系と同じ発想です。

このとき、view ごとの position information と、view 自体を区別する情報が token に埋め込まれます。これによって、transformer は「どの view のどの patch か」を区別しながら attention できます。

Shared transformer backbone​

VGGT の backbone は、view 横断で動く一つの transformer です。Self-attention によって、

  • 同じ view 内の patch 間の依存
  • 異なる view の patch 間の対応

の両方を同時に学習します。前者は image 単体の geometry を理解するために、後者は multi-view consistency を取るために重要です。

軽量な task head​

Camera、depth、point map、point track のそれぞれには、軽量な head が付きます。重い推論は共通 backbone で済ませ、head は出力 format への変換を担当します。

この設計には次の利点があります。

  • 各 task が共通の representation を共有するため、multi-task が互いに supervise する形になる。
  • View 数が変わっても、同じ backbone を使い回せる。
  • Camera と depth と point map が一貫した推論から得られる。

入力 view 数のスケール​

VGGT は、one image、few images、hundreds of images のいずれも扱えるよう設計されています。Token 数は view 数に比例して増えるため、大量 view のときは memory と attention の効率化が重要になります。

実装では、必要に応じて view を grouping したり、cross-attention の構造を工夫したりして、scalability を保ちます。

Architecture が意味すること​

VGGT の architecture から読み取れる重要な点は、「geometry が image の中で局所的に閉じていない」という前提です。Depth、camera、matching はすべて view 間の関係に依存するため、view 横断の attention を持つ transformer は自然な選択肢になります。

数式で見る cross-view attention​

VGGT の backbone は、複数 view の patch token を一つの transformer で同時に処理します。View ii の patch token を Hi∈RP×d\mathbf{H}_i\in\mathbb{R}^{P\times d} とすると、全 view を concat した token 列 H=[H1;…;HN]\mathbf{H}=[\mathbf{H}_1;\ldots;\mathbf{H}_N] に対して self-attention が走ります。

Attn(H)=softmax(HWQWK⊤H⊤d)HWV\mathrm{Attn}(\mathbf{H})=\mathrm{softmax}\left(\frac{\mathbf{H}\mathbf{W}_Q\mathbf{W}_K^\top \mathbf{H}^\top}{\sqrt{d}}\right)\mathbf{H}\mathbf{W}_V

この attention は、view 内の空間関係と view 間の対応の両方を同じ機構で扱います。

計算量は token 数に対して二乗で増えるため、現実的には intra-view attention と inter-view attention を交互に挿入する factorized 構造がよく使われます。

O((NP)2d)  →  O(NP2d)+O(N2Pd)O((NP)^2 d)\;\to\;O(NP^2 d)+O(N^2 P d)

この式の気持ちは、「すべての view・patch を一気に attention するのは高価なので、空間方向と view 方向を分けて処理することで、token 数が増えても扱える形にする」というものです。

関連ページ​

主なソース​