マルチモーダルLLM(画像・動画とテキストを一緒に扱うモデル)は、画像をそのまま読むことはできない。まず画像を細かく分割して視覚トークン(モデルが画像を読むために分割した情報の単位)に変換してから処理する。トークンが多いほど計算とメモリのコストが上がるが、これまでのモデルは画像のあらゆる場所を一様に、同じ密度でトークンに変換していた。
アリババQwenチームと中国科学技術大学などが共同で発表したVisionWeaveは、画像の中で丁寧に見るべき場所(fine-grained、細密)と大まかに見てよい場所(coarse-grained、粗い)を、モデルが自ら切り分けてトークン数を減らす研究だ。この能力は、トークンを減らしていない元モデルを教師とする自己蒸留(self-distillation)で学習する。自己蒸留とは、別途正解ラベルを作る代わりに、元モデルの出力を教師信号として使う方式であり、外部の学習データを使わないという意味ではない。実際の学習には、LLaVA-OneVision・LLaVA-Video-178K・UGroundから抽出した計777Kサンプルを用いている(アブストラクト・§2.4・表2に基づく)。
まず成果から述べると、Qwen3.8-27Bにおいて8つのベンチマークで視覚トークンを平均43.0%削減しながら、元モデルの98.9%の性能を維持した。トークンを50%の固定比率で切り捨てる従来方式は元モデルの88%前後にとどまったが、この二つの数値は削減率の条件そのものが異なるため(VisionWeaveは平均43.0%、比較対象は50%固定)、単純な比較ではない — 削減率を揃えたフェアな比較については後ほど別に扱う。
画像の中の情報は均等に分布していない。文書の細かい文字やボタンの位置は細密に見る必要があるが、単色の背景や空のように平坦な場所は大まかに見ても答えは変わらない。新聞を読むとき、記事本文は一文字ずつ追っても余白は読み飛ばすのと同じだ。あらゆる場所に同じ解像度を使うのは、その余白にまで虫眼鏡を当てるようなものである。
この無駄を減らそうとする従来の解法は、着眼点によって三つに分かれていた。
論文はこれらの弱点を四つに整理している。① 学習時と推論時の挙動が食い違う不一致(training-inference mismatch)、② タスクごとに必要な情報が捨てられてしまう問題、③ 圧縮率が固定で入力ごとに合わせられない問題、④ attention重みを取り出して使ったり、LLM内部でトークンを切り捨てる設計のため、SGLang・vLLMのような実際のサービングエンジンに組み込みにくい問題だ。著者らがFastVとVisionZipを実際に評価してみると、情報が密な文書や、位置を正確に指し示す必要があるグラウンディング(grounding)タスクで、スコアが大きく低下した。
ViCOは発想がVisionWeaveに最も近いが、タイル単位という点が引っかかる。Qwen・Kimiのように画像を元のサイズのまま処理するネイティブ解像度(native-resolution)モデルにはうまく合わず、ディテールが多い領域と平坦な背景が一つのタイルの中に混在していることが多いため、タイル一つに解像度一つでは十分に細かく分けられない。
VisionWeaveは二つの仕組みと一つの学習プロセスから成る。著者らはこの能力を「弾力的な視覚表現の織り込み(elastic visual representation weaving)」と呼ぶ。密な糸と粗い糸を一枚の布に混ぜて織り込むように、二つの解像度のトークンを領域ごとに織り合わせるという意味だ。
(1) 四つのトークンを一つに要約する仕組み — ゲート付き空間プーラー(gated spatial pooler)。 画像を2×2ブロックにまとめる。一つのブロックは、細密なトークン四つとして残すことも、粗いトークン一つに圧縮することもできる。最も単純な圧縮は四つのトークンを平均することだが、VisionWeaveは平均プーリングの状態から学習を始めるよう設計したうえで、ブロック内のどこに重みを置くかを学習で少しずつ調整していく。
(2) 要約してよい場所を選ぶ仕組み — 粒度ルーター(granularity router)。 ブロックごとに「ここを粗くしてよい確率」を付ける。その確率がしきい値(デフォルト0.5)を超えれば粗いトークン一つを、超えなければ細密なトークン四つを使う。
二つの仕組みを請求書のキャプチャに当てはめると次のようになる。金額が書かれた小さな文字のブロックはルーターが細密な四トークンをそのまま残し、何もない背景のブロックはプーラーが粗い一トークンに要約する。こうして選ばれたトークンを混ぜ合わせて一つのシーケンスにし、LLMに渡す。
(3) 元モデルの答えに倣って学ぶプロセス — 自己蒸留。 教師はトークンを減らしていない元モデルの通常の処理結果であり、生徒はトークンを織り混ぜた縮小版だ。生徒が教師と同じ答えを出すように合わせていく。ここで二つの目標が噛み合う。トークンを減らせという圧力と、元モデルの答えを守れという圧力が同時にかかるため、ルーターはやみくもに減らすのではなく「減らしても答えが変わらない場所」を選ぶように学ぶ。
したがって三つの方式の挙動はこう分かれる。プルーニングはトークンを除去するので、後からディテールが必要になっても復元できない。VisionWeaveは捨てる代わりに粗い表現として要約して残す。ViCO式はタイルごとに解像度を選択するが、その単位がタイルのためそれ以上細かくは分けられない。
プーラーは各パッチ特徴をレイヤー正規化(LayerNorm)で整え、チャネルごとにどこへ重みを与えるかをゲート(gate)がスコアリングした後、value netが特徴をもう一度精製する。最終層を0で初期化すればちょうど平均プーリングに戻り、安全な出発点から学習を始められる。粗いトークンは元の四トークンの幾何学的中心に置かれるが、MRoPE座標系の中で位置補間(positional interpolation)によってブロック中心の座標を付与し、粗いトークンと細密なトークンが同じ座標の枠組みを共有するようにする。
ルーターはViTの複数の深さから特徴を引いてきて(序盤の層の低レベルなディテール + 終盤の層の意味)、ブロックごとにクエリを一つ置き、自分のブロックだけを見るローカル(local)と、フレーム全体を見るグローバル(global)のブロックをクロスアテンションで交互に通過させた後、線形ヘッドが確率を出す。
学習は三段階だ。① ルーティングをオフにし、全ブロックを粗くしたままプーラーだけを学習、② プーラーを凍結してルーターだけを学習するが、硬い選択の代わりに微分可能なソフト混合に置き換え、MoEから借りてきたバランス損失(balance loss)で粗いブロックの比率を目標値(80%)に合わせる、③ 推論時に実際に使う硬い混合粒度シーケンスで、プーラーとLLMを一緒にファインチューニング。蒸留はすべてoff-policyであり、教師の上位vocabに対するforward KLを使う。段階③をon-policyに変えてみたものの一貫した利得がなかったため、off-policyを選んだと述べている。
評価モデルはQwen3.5-4BとQwen3.8-27Bの二つ。比較対象はマージ系のVisionZipとプルーニング系のFastVだが、SGLangの中でフェアに測るため、FastVはLLM内部ではなくビジョンエンコーダ直後にトークンを選ぶ変種(FastV†)を使った。
ベンチマークはあえてドメインを広く取った。自然画像(RealWorldQA)、文書・インフォグラフィック(DocVQA, InfoVQA)、GUIグラウンディング(ScreenSpotV2)、視覚ハルシネーション(HallusionBench)、動画内の文字読み取り(VideoOCR)、動画理解(Video-MME, LongVideoBench)の計8つだ。スコアは0〜100のスケールで、DocVQA・InfoVQAはANLS、HallusionBenchはaAcc、残りは各ベンチマーク固有の指標を使う。
この表が測れるものと測れないものを分けておくと、後の数値を混同せずに読める。この実験が測るのは「トークンを減らしたとき正答率がどれだけ下がるか」、すなわち効率-品質のトレードオフだ。ディテールが命の文書・グラウンディングと、冗長性の多い動画を一つの表に入れ、入力の性質によって削減率が変わるのかを見る。逆にこの表だけでは、特定のサービスの実際のコストやレイテンシはわからない。それは後のSGLangサービング実験が担う、別の軸の数値である。
公平性のための設計がもう一つある。「VisionWeaveはトークンをより少なく使いながらスコアも高い」という比較は、削減率そのものが異なるため不公平になりうる。そこで著者らは、FastV†・VisionZipにVisionWeaveが観測した削減率をそのまま与えた比較も追加している(Appendix E.3)。
Qwen3.8-27Bで512トークン/画像の予算、しきい値0.5で回したとき、8ベンチマークの平均トークンを43.0%削減し、元モデルの98.9%の性能を維持した(平均損失1.08%)。より小さいQwen3.5-4Bでは損失が0.90%だった。この数字を二つの問いに分けて読むと核心が見えてくる。
第一に、どの入力でどれだけ減らしたか。 削減率はタスクごとに異なった。
| 入力の性質 | タスク | トークン削減 | 品質 |
|---|---|---|---|
| 文書・インフォグラフィック | InfoVQA / DocVQA | 16.5% / 27.3% | DocVQA 損失1.23% |
| GUIグラウンディング | ScreenSpotV2 | 55.1% | 損失3.17% |
| 動画 | VideoOCR・Video-MME・LongVideoBench | 49.6〜54.2% | 損失0.30%以下 |
ディテールが重要な文書では削減を保守的に、冗長性の多い動画では積極的に減らした。先に見た学習構造 — 「減らしても答えが変わらない場所」を選ぶように学んだルーター — が、入力の性質に応じた異なる選択として現れた結果だ。
第二に、同じ削減率でも品質差は残るか。 残る。50%固定の削減目標で、FastV†・VisionZipのQwen3.8-27B平均損失はそれぞれ11.82%、12.46%で、特にVisionZipはScreenSpotV2で47.88%低下した。同じタスクでVisionWeaveはむしろ55.1%を節約しながら損失を3.17%に抑えた。削減率を揃えた比較(Appendix E.3)でも、VisionWeaveの平均が76.73で、FastV†・VisionZipの70.10・70.33より高かった。少なく使って勝つのではなく、同じ量を使ってもどこを減らすかをより上手に選んで上回る、という意味だ。
削減が実際の速度につながるかも確認した。SGLangに載せたQwen3.8-27Bで、エンドツーエンドのスループットが2.30倍になり、平均TTFT(最初のトークンまでにかかる時間)は54.4%、平均TPOT(トークン一つの生成あたりの時間)は60.6%減った。推論時にしきい値を調整すれば圧縮の強度を変えられる点(§3.5)も、運用で使える操作レバーだ。
解像度・フレーム数を変えながら回した実験でも、単純なダウンサンプリングより一貫して有利だった。一例として、LongVideoBenchで256フレーム上限のVisionWeaveが、128フレーム上限の元モデルより少ないトークンを使いながら1.20点高かった。同じ予算なら、フレームをより多く詰め込みつつ各フレームを弾力的に圧縮するほうがよい、というシグナルだ。
編集注: 論文の「Limitations and Future Works」(Appendix A)は抜粋範囲の外にあるため、著者自身が認めた限界のリストは訳出できなかった。以下は本文・アブストラクトから指摘できる構造的な限界である。
第一に、学習コストが大きい。Qwen3.8-27Bにこの能力を組み込むのに30K A100 GPU時間以上かかった。小さなチームが任意のモデルにそのまま再現するには壁が高い。
第二に、圧縮の単位が2×2ブロックに縛られている。粗いトークンの最小単位がこのブロックなので、ブロックより細かく分けることは設計範囲の外だ。
第三に、入力分布の変化だ。段階②のバランス損失は粗いブロック比率80%を目標とし、段階③の前にはルーターのバイアスをトークン削減率50%を目標に別途オフラインで較正するため、サービスが扱う入力がこの較正時と大きく異なる場合、どれだけ再較正が必要か、推論時にしきい値を回すだけでどこまでカバーできるかは、実際のトラフィックで確認すべき部分である。
第四に、学習が自己蒸留であるため、元モデルの盲点がそのまま引き継がれるリスクがある。これを「元モデルがすでに誤って読んでいる小さな数字の領域で、圧縮後に誤りがさらに増えるか」という確認の問いに変え、導入前に測定しておくのが安全だ。
ONTLEは、小規模事業者・一人の起業家の繰り返し業務を軽くするAI PM派遣型サービスだ。
業務の一場面を取り上げてみよう。AI PMが毎朝、取引先から送られてきた請求書のキャプチャ、ショッピングモールの管理画面ダッシュボード、配送状況の表をマルチモーダルモデルで読み、金額・口座番号・ステータスを抽出する。ここでコスト構造が厄介だ。請求書の小さな数字や管理画面のボタンの位置は少しでも潰れると値が狂うが、同じ画面には巨大な余白や繰り返される表のヘッダーも一緒にある。固定圧縮をかければ数字が間違い、圧縮をかけなければ余白にまでフルトークンを使ってコストはそのままだ。
だからONTLEがこうした手法を導入するときの判断基準は、数値の大きさではなく順序である。まず金額・口座番号の抽出エラーが増えないかを比較し、その許容品質を守る範囲の中でのみ処理時間とコストを評価する。論文の数値は特定のベンチマーク・特定のバックボーンの結果なのでそのまま転用はできないが、「文書は保守的に、冗長性の多い入力は積極的に」という性質は、この検討の枠組みにおいて「自分たちのワークロードがどちら寄りかをまず診断せよ」というチェックポイントとして使える。
論文によれば、SGLangコードとその他の詳細をgithub.com/FFY0/VisionWeave に公開する予定だと述べられています。公開時期・範囲の具体的なスケジュールは、抜粋範囲では確認できません。
粗いトークンは四つのパッチの幾何学的中心、すなわち半整数の座標に置かれます。SGLangのRoPEキャッシュは整数インデックスのためこれを直接は格納できませんが、著者らはすべての位置座標を2倍に拡大し、回転周波数を半分に下げることで回転位相を保存する方式で、既存のカーネルをそのまま再利用しました。プルーニング系が実際のサービングエンジンに適用しにくいと指摘した点を、自ら埋めた形です。