- Authors
- Name
- Youngju Kim
- @fjvbn20031
- はじめに: トークンがすべての入口だ
- 画像トークン化: パッチとVQ
- 音声トークン化: 離散コーデック
- 動画フレームサンプリング
- 統合列の構成: インターリービング
- トークン爆発と圧縮
- コンテキストコスト
- 動的解像度と任意アスペクト比
- 多次元位置エンコーディングを詳しく
- トークン予算の計画
- モダリティ別トークン密度の比較
- VQコードブックの実際の動作
- アダプタ設計のトレードオフ
- インターリービングの落とし穴: 順序と整列
- トークン化結果のキャッシュと再利用
- 比較: トークン化・圧縮方式
- 落とし穴とトラブルシューティング
- おわりに
- 参考資料
はじめに: トークンがすべての入口だ
LLMはトークンを食べトークンを吐きます。テキストだけを扱うときは、トークナイザが文字列をサブワードトークンへ分割すれば終わりでした。しかし画像を理解するモデル、音声を聞くモデル、動画を見るモデルを作るには、一つの問いが生じます。「画像を、音声を、動画を、どうトークンへ変えて同じ列に入れるのか」。
この問いがマルチモーダルLLM設計の核心です。マルチモーダルモデルのバックボーンは多くの場合Transformerで、Transformerはトークン(埋め込みベクトル)の列を入力として受けます。ですからすべてのモダリティを最終的に「トークン列」へ変換する必要があります。変換方式によってモデルの能力、コスト、精度が変わります。
本記事では、画像・音声・動画をトークンへ変える方法、それらをテキストと一つの列へインターリーブする方法、そしてトークン数が爆発するときの圧縮戦略まで扱います。前の記事で整列と融合の原理を見たなら、本記事はその融合が実際の入力レベルでどう実装されるかという話です。
画像トークン化: パッチとVQ
画像をトークンへ変える道は大きく二つです。
パッチ埋め込み方式
ViT(Vision Transformer)が代表です。画像を固定サイズのパッチ(例: 14x14 ピクセル)に格子分割し、各パッチを線形射影してベクトルにします。そのベクトル一つが「ビジュアルトークン」になります。パッチトークンは連続埋め込みで、コードブックはありません。
パッチトークン化(概念)
画像 H x W x 3
-> パッチ分割 (p x p)
-> パッチ数 = (H/p) x (W/p)
-> 各パッチ -> 線形射影 -> ベクトル(D 次元)
-> ビジュアルトークン列 (N_patch x D)
例: 224x224 画像, p=14 -> 16 x 16 = 256 トークン
448x448 画像, p=14 -> 32 x 32 = 1024 トークン
解像度が上がるとトークン数は二乗で増えます。これが後述するトークン爆発の第一の原因です。
VQ(ベクトル量子化)方式
VQ-VAE/VQGAN系は画像を離散コードへ量子化します。エンコーダが画像を潜在格子にし、各位置ベクトルをコードブックの最近接コードへ置換します。すると画像が「離散トークンIDの格子」となり、テキストトークンのように整数インデックスで表現されます。
VQ 画像トークン化(概念)
画像 -> エンコーダ -> 潜在格子 (h x w x D)
各位置ベクトルをコードブックの最近接コードへ量子化
-> コードインデックス格子 (h x w), 各値 in {0..K-1}
-> flatten -> 離散トークン列
利点: テキストと同じ「離散語彙」に統一 -> 生成モデルに有利
欠点: 量子化損失、コードブック崩壊(collapse)の危険
パッチ方式は理解型VLMで、VQ方式は統合生成(画像生成を含む)モデルでよく使われます。両者を混ぜる設計もあります。
音声トークン化: 離散コーデック
音声は時間軸の連続信号です。これをトークンにするには時間をフレームへ切り、各フレームを離散単位へ量子化します。ニューラル音声コーデック(neural audio codec)がこの役割を担います。
コーデックエンコーダが波形を一定フレームレートの潜在表現へ圧縮し、残差ベクトル量子化(residual vector quantization)で複数のコードブックにまたがって離散化します。結果は時間フレームごとに複数のコードからなるトークンストリームです。
音声離散コーデック(概念)
波形(サンプルレート高) -> コーデックエンコーダ -> フレーム表現(低フレームレート)
各フレームを RVQ で多層量子化
-> フレームあたりコード Q 個(階層的)
-> [t=1: c1..cQ][t=2: c1..cQ]... 離散音声トークンストリーム
特徴: フレームレートとコードブック数がビットレート/品質を決める
毎秒トークン数はテキストよりはるかに多くなりうる
核心の落とし穴は音声トークンの密度です。1秒の音声が数十~数百トークンになりやすく、長い音声はコンテキストを急速に消費します。フレームレートと量子化階層数を慎重に決めます。
動画フレームサンプリング
動画は画像の列なのでトークン数が最も爆発しやすいです。30fpsの映像10秒なら300フレームで、フレームあたり数百トークンなら数万トークンです。そのためフレームサンプリングが必須です。
動画トークン化戦略(概念)
元: 30fps x 長さ
-> フレームサンプリング(例: 1~2 fps へダウンサンプル)
-> キーフレーム/シーン転換を優先選択(任意)
-> 各フレームをパッチトークン化
-> 時間区切りトークン挿入(フレーム境界を表示)
-> 時空間トークン列
追加圧縮: 隣接フレームトークンの併合/プーリングで冗長を除去
サンプリングは情報損失とコストのトレードオフです。速い動きを見るならフレームレートを上げる必要があり、その分トークンが増えコストが上がります。
統合列の構成: インターリービング
各モダリティをトークンにしたら、一つの列へ編む必要があります。テキストとビジュアルトークンをプレースホルダ位置に挟み込むインターリービング(interleaving)が一般的です。
インターリーブ入力構成(概念)
ユーザー入力:
"次の画像を説明して [IMG] そしてこの音も [AUDIO]"
トークン列へ展開:
[txt: 次の画像を説明して]
[IMG_START][v1 v2 ... v256][IMG_END]
[txt: そしてこの音も]
[AUD_START][a1 a2 ... aM][AUD_END]
LLMはこの単一列をまとめて注意処理する。
重要なのは、プレースホルダ1枠が実際には数百トークンへ展開される点です。テキストプロンプトでは1~2トークンでも、展開されるとコンテキストの大部分を占めます。
モダリティ埋め込みと区切りトークン
モデルが「このトークンがどのモダリティ由来か」を知ると処理に有利です。そのため二つの仕掛けを使います。
- 区切り(特殊)トークン: 画像の開始/終了、音声の開始/終了を表す特殊トークンで境界を明示します。
- モダリティ埋め込み: トークン埋め込みにモダリティ種別を表す学習埋め込みを足し、同じ位置でも出所を区別します。
位置情報も重要です。画像は2D空間位置を、動画は時間+空間位置を持つべきです。最近のVLMは任意解像度を扱うため、多次元の回転位置(例: M-RoPE系)で時間・縦・横の座標を同時にエンコードします。
位置エンコーディングの次元(概念)
テキスト: 1D 位置(順序)
画像: 2D 位置(行, 列)
動画: 3D 位置(時間, 行, 列)
多次元 RoPE: 各軸を分割して回転位置でエンコード
-> 任意解像度/長さに柔軟
トークン爆発と圧縮
マルチモーダルで最も現実的な問題はトークン数です。Transformerの注意コストは列長に二乗で増えるため、ビジュアルトークンが多いと計算とメモリが急増します。そこで圧縮が核心技術になります。
トークンプルーニング(token pruning)
重要度の低いトークンを捨てます。注意スコアや学習されたスコアでトークンの情報量を推定し、背景のような重要度の低いパッチトークンを除去します。層を経るごとに段階的に減らす方式が一般的です。
トークン併合(token merging)
似たトークンをまとめて一つにします。隣接または埋め込みが似たトークンを平均/加重和で併合すると、情報を比較的保ちながら個数を減らせます。
Q-Former系の圧縮
learnable query を置き、ビジュアル特徴を key/value とする交差注意で情報を少数のクエリトークンへ凝縮します。入力パッチ数に関係なく、固定された少数のトークンだけがLLMへ渡ります。
Q-Former系の圧縮(概念)
ビジュアルパッチ特徴 (N_patch x D) <- 多い(例: 1024)
|
learnable query (Q x D) <- 少ない(例: 32~64)
|
交差注意: query がパッチを参照し情報を凝縮
|
圧縮済みビジュアルトークン (Q x D) -> LLM 入力
効果: LLMが見るビジュアルトークンを 1024 -> 64 へ削減
注意: 過圧縮は細部(小さな文字, OCR)の損失
圧縮は万能ではありません。OCRや細かなチャート読みのように細部が重要な課題では、過度の圧縮が性能を下げます。課題特性に合わせて圧縮強度を調整します。
コンテキストコスト
トークン数はすなわちコストです。三つの側面を見ます。
- 計算コスト: 注意は列長に二乗、FFNは線形。ビジュアルトークンが多いとプリフィル(prefill)段階の計算が大きく増えます。
- メモリコスト: KVキャッシュはトークン数に比例。長いマルチモーダル入力はKVキャッシュメモリを急速に消費します。
- 遅延/料金: API課金と遅延がトークン数に直結します。高解像度画像を無造作に入れるとコストが急騰します。
トークン数がコストに与える影響(概念)
ビジュアルトークン N_v 増加 ->
- prefill FLOPs: 注意 O((N_v + N_t)^2) 項が増加
- KVキャッシュメモリ: O(N_v + N_t) 増加
- TTFT(最初のトークン遅延): prefill が長く -> 増加
対応: 解像度上限、動的解像度、圧縮(プルーニング/併合/Q-Former)
実務では入力解像度ポリシー(上限, 動的調整)、圧縮強度、キャッシュを併せて設計します。同じ精度ならトークンを減らす方がほぼ常に有利です。
動的解像度と任意アスペクト比
現実の画像は正方形ではありません。横長のパノラマ、縦長の文書スキャン、小さなアイコンまで、アスペクト比と大きさはまちまちです。固定解像度(例: 224x224)へ強制リサイズするとアスペクト比が崩れ情報が歪みます。特に文書やチャートのようにテキストが密な画像は、強制リサイズで文字がつぶれやすいです。
最近のVLMは任意解像度(naive dynamic resolution)を支援します。元のアスペクト比を保ちながらパッチ格子を動的に構成し、その結果ビジュアルトークン数が画像ごとに変わります。このため位置エンコーディングも任意格子を扱える必要があります。
固定解像度 vs 動的解像度(概念)
[固定] すべての画像を 224x224 へ強制リサイズ
-> アスペクト歪み、小さな文字がつぶれる
-> トークン数は常に同一(予測しやすい)
[動的] 元のアスペクト比を保持、パッチ格子が可変
-> 歪み少、文書/チャートに有利
-> トークン数が画像ごとに変わる(予測しにくい)
折衷: 最小/最大トークン上限を設けその範囲で動的調整
動的解像度は品質に有利ですが、トークン数の変動が大きくなりメモリ計画とバッチングを難しくします。そこで通常は最小/最大トークン上限を設け、その範囲内でのみ動的に調整します。
多次元位置エンコーディングを詳しく
位置エンコーディングはモダリティごとに次元が異なります。テキストは1D、画像は2D、動画は3Dの位置が必要です。単一の1D位置だけでは、画像の空間構造や動画の時間構造を適切に表現できません。
回転位置エンコーディング(RoPE)を多次元へ拡張するとこの問題を解けます。埋め込み次元を複数のグループに分け、各グループに異なる軸(時間/縦/横)の位置を回転でエンコードします。すると一つのトークンが時間・空間座標を同時に担えます。
多次元 RoPE の分割(概念)
埋め込み次元 D を三区画に分割:
[ 時間軸回転 | 縦軸回転 | 横軸回転 ]
D_t D_h D_w
各トークンの (t, h, w) 座標を該当区画に回転でエンコード
-> テキスト(tのみ), 画像(h,w), 動画(t,h,w)を統一枠で処理
-> 任意解像度/長さへの外挿に柔軟
この方式の利点は、学習時に見ていない解像度や長さにも比較的よく一般化することです。ただし学習分布と推論分布が大きく異なると外挿が崩れることがあるため、学習段階で多様な解像度を十分に露出するのがよいです。
トークン予算の計画
マルチモーダル入力を扱う際はトークン予算(budget)を明示的に計画すべきです。テキストだけを数えるのと違い、ビジュアルトークンが展開され予算を急速に消費するからです。
トークン予算の計算(概念)
総コンテキスト上限 = C (例: 32768)
入力トークン = テキストトークン + ビジュアルトークン(展開後) + 特殊トークン
出力余裕 = C - 入力トークン
点検:
- ビジュアルトークンをプレースホルダではなく「展開後」の値で計算したか
- 複数画像の合計を足したか
- 出力長のための余裕を残したか
超過時の対応: 解像度を下げる、圧縮を強化、画像数を制限
実務バグの多くは、プレースホルダを1トークンと勘違いして予算を誤ることから来ます。常に展開後の長さで計算する習慣が重要です。
モダリティ別トークン密度の比較
同じ1秒、同じ1枚でも、モダリティによってトークン密度が大きく異なります。この感覚を持っていると、コストとコンテキストを直感的に見積もれます。
おおよそのトークン密度(概念、モデル/設定依存)
テキスト 1段落(約100単語) -> 約130 トークン
画像 中解像度1枚 -> 数百トークン
画像 高解像度文書1枚 -> 数千トークン
音声 1秒の音声 -> 数十トークン
動画 1秒(サンプリング後) -> 数百~数千トークン
含意: 動画 > 高解像度画像 > 音声 > テキスト の順で密度が大きい
長い映像はコンテキストを最も速く消費
この表は正確な数値ではありませんが、相対的な規模感を与えます。映像と高解像度画像がコンテキストの主な消費者だと覚えておくと設計が容易になります。
VQコードブックの実際の動作
VQトークン化をさらに深く見てみましょう。コードブックはK個の学習されたベクトル(コード)で構成されます。量子化とは、エンコーダが作った各位置ベクトルを、コードブックで距離が最も近いコードへ置換することです。
VQ量子化のステップ(概念)
エンコーダ出力 z(位置ごとのベクトル)
コードブック E = [e_0, e_1, ..., e_{K-1}]
各 z について:
最近接コードインデックス = argmin_k 距離(z, e_k)
量子化出力 = e_{最近接}
学習:
- エンコーダはコードへ近づくように
- コードブックは使われたコードが入力平均へ向かうように
- ストレートスルー(straight-through)で勾配を伝達
VQの宿痾はコードブック崩壊(collapse)です。一部のコードだけが選ばれ続け残りが死んでしまい、表現の多様性が減ります。これを防ぐためコードブック再起動(dead codeの再初期化)、指数移動平均(EMA)更新、コミットメント損失などを使います。コードブック活用率(どれだけ多くのコードが実際に使われるか)を監視することが重要です。
アダプタ設計のトレードオフ
ビジョン特徴をLLM空間へ移すアダプタ(プロジェクタ)には設計の選択肢が複数あります。それぞれトークン数と情報保存の間で異なる均衡を持ちます。
アダプタ種別の比較(概念)
[線形/MLP プロジェクタ]
パッチ特徴を位置ごとにLLM次元へ射影
トークン数 = パッチ数(圧縮なし)
利点: 単純, 情報保存が良い
欠点: パッチが多いとトークンも多い
[Q-Former系(learnable query)]
少数クエリで情報を凝縮
トークン数 = クエリ数(固定, 圧縮)
利点: トークン数の制御が容易
欠点: 過圧縮時に細部損失, 学習が難しい
[プーリング/併合ベース]
隣接パッチトークンをまとめてダウンサンプル
中程度の圧縮
実務の選択は課題特性次第です。OCR・文書のように細部が重要なら圧縮の少ない線形/MLP側が、一般的なシーン理解のように要約で十分ならQ-Former系が有利になりえます。多くの最新VLMは単純なMLPプロジェクタ + 動的解像度の組合せで良い結果を出すこともあります。
インターリービングの落とし穴: 順序と整列
インターリービングではトークンの順序と整列が微妙ながら重要です。同じ情報でも配置順が異なるとモデルは異なる解釈をします。
インターリービング順序の影響(概念)
[画像が先]
[IMG ...][質問テキスト]
-> モデルが画像を先に見て質問に答える
[質問が先]
[質問テキスト][IMG ...]
-> 質問の文脈の上で画像を解釈
含意: 順序が注意の流れと結果に影響
学習分布と一貫した順序を使うのが安全
また複数画像を入れるときは、各画像にインデックスやラベルを付けて「最初の画像」「二番目の画像」を明確に指せるようにするとよいです。区切りトークンとともにこうしたラベリングがマルチ画像推論の精度を高めます。
トークン化結果のキャッシュと再利用
ビジュアルトークン化は高価です。ビジョンエンコーダの順伝播とプロジェクタ計算が入るからです。しかし同じ画像が複数回現れる状況(マルチターン対話、同一文書の反復質問、人気画像)では、トークン化結果をキャッシュして再利用できます。
ビジュアルトークンのキャッシュ(概念)
キャッシュキー = ハッシュ(画像バイト + 前処理パラメータ)
前処理パラメータ: 目標解像度, 正規化設定 など
リクエスト -> キー計算
ヒット: キャッシュ済みビジュアルトークンを即使用(エンコーダをスキップ)
ミス: エンコード後に結果を保存
注意:
- 前処理パラメータをキーから漏らすと誤ったトークンを再利用
- メモリ/ディスク上限と失効ポリシーが必要
キャッシュはトークン化自体を減らしませんが、反復コストを大きく削減します。特にトークン数の多い高解像度画像を繰り返し処理するときに効果が大きいです。キャッシュキー設計では前処理パラメータを必ず含め、誤った再利用を避けます。
比較: トークン化・圧縮方式
| 項目 | 方式 | 利点 | 欠点 |
|---|---|---|---|
| 画像 | パッチ(ViT) | 連続表現、理解型に強い | 解像度に比例しトークン増加 |
| 画像 | VQ 離散 | テキストと語彙統一、生成に有利 | 量子化損失、コードブック崩壊 |
| 音声 | 離散コーデック(RVQ) | 統一された離散トークン | 毎秒トークン密度が高い |
| 圧縮 | プルーニング | 単純、効果的 | 重要トークン損失の危険 |
| 圧縮 | 併合 | 情報保存的 | 実装が複雑 |
| 圧縮 | Q-Former | 固定の少数トークン | 過圧縮時に細部損失 |
落とし穴とトラブルシューティング
- プレースホルダ展開の見落とし: プレースホルダ1枠が数百トークンへ展開されるのを忘れると、コンテキスト予算の計算が狂います。常に展開後の長さで計算してください。
- 区切りトークンの欠落/衝突: モダリティ境界トークンが欠けると、モデルがテキストとビジュアルを混同しかねません。
- 解像度の暴走: 高解像度画像をそのまま入れてトークンが爆発すると、遅延とコストが急騰します。動的解像度/上限を設けてください。
- 過圧縮: OCR・小型物体・チャートで細部が消えます。課題ごとに圧縮強度を変えてください。
- 音声/動画の長さ: 長さに比例してトークンが線形増加します。サンプリングレートとチャンク分割戦略が必要です。
- 位置エンコーディングの不一致: 学習と推論の解像度/フレームレートが大きく異なると、位置の一般化が崩れることがあります。
おわりに
マルチモーダルLLMは結局「すべてをトークンへ変える」技術の上に立っています。画像はパッチまたはVQで、音声は離散コーデックで、動画はサンプリング後にパッチでトークン化されます。これらのトークンを区切りトークンとモダリティ埋め込みで標識し、テキストとインターリーブして一つの列を作ります。
最大の実務課題はトークン爆発です。プルーニング、併合、Q-Former系の圧縮でトークンを減らしつつ、OCRのような細部課題では過圧縮を警戒すべきです。トークン数はすなわち計算・メモリ・料金なので、解像度ポリシーと圧縮を併せて設計することがコスト効率の鍵です。次の記事では、こうして作られたマルチモーダル入力を実際にサービングする際に生じる新たな課題を扱います。