視覚言語検索は8~12GB程度のVRAMから開始できますが、信頼性の高い下限は、モデルサイズ、量子化、画像トークン、コンテキスト長、同時実行数によって決まります。
コンパクトな7Bクラスの量子化モデルは8GBのGPUに読み込める場合がありますが、複数の高解像度画像と長いチャット履歴を同時に処理すると失敗することがあります。検索では、別の画像エンコーダーやリランカーを使用する場合もあります。容量は、ディスク上に表示されるモデルファイルのサイズだけでなく、想定する最も負荷の高いクエリパターンにおける実行時のピーク割り当てまで含めて考える必要があります。
重みが決めるのは下限であり、ピークではない
理論上の重みメモリは、パラメータ数にパラメータあたりのビット数を掛けて算出します。70億パラメータを4ビットで表すと、スケール、メタデータ、フレームワークのバッファー、量子化されていない層を含める前で約3.5GBです。画像エンコーダーは、モデルとは別に存在する場合も、モデルに統合されている場合もあります。
GPUメモリの構成要素を実用的に説明する際は、モデルの重みをKVキャッシュ、アクティベーション、実行時のオーバーヘッドから分けて考えます。そのため、ファイルサイズだけでは推論に必要なメモリを過小評価してしまいます。
量子化によって重みの常駐メモリは削減できますが、すべての割り当てが同じ割合で小さくなるわけではありません。視覚投影、一時的なアテンションバッファー、一部のカーネルは16ビット精度のままになることがあります。かろうじて読み込める程度のモデルでは、実際の画像クエリに対応する余裕がありません。
画像はトークンと実行時状態に変換される
視覚エンコーダーは画像をパッチに分割またはリサンプリングし、その後、視覚トークンを言語モデルに渡します。画像の枚数が増えたり、受け入れ可能な解像度が高くなったり、動的タイリングを使用したりすると、トークン数は増加します。これらのトークンによってアテンション処理の負荷が増え、自己回帰処理の段階ではKVキャッシュの需要も拡大します。
視覚指示チューニングに関する研究は、学習された視覚表現を介して画像と言語モデルがどのように接続されるかを示しています。どれだけの視覚特徴がコンテキストに入るかは、アーキテクチャと前処理によって決まります。
複数の検索をバッチ処理すると、重みが共有されていても、アクティブな画像およびテキストの状態が倍増します。そのため、8~12GBの層はコンパクトな単一ユーザー検索に適している一方、16~24GBあれば、より大きなモデル、複数の画像、同時リクエストに対応する余裕が増えます。
VRAMの推奨値が当てはまらなくなるケース
共有メモリシステム、CPUオフロード、エンコーダーの分割、ディスクベースの埋め込み検索では、制約条件が変わります。オフロードによって少ないVRAMでモデルを実行できる場合がありますが、レイテンシは増加します。事前計算した画像埋め込みを使えば、クエリごとに説明を生成する場合より、実行時の視覚処理を大幅に減らせます。
KVキャッシュの割り当てに関する議論は、重みが収まっていても、コンテキスト長とKVキャッシュの割り当てによって、より小さな上限を設定せざるを得なくなる場合があることを示しています。マルチモーダル入力では、同じ予算がさらに厳しくなります。
また、これらの範囲は、勾配とオプティマイザー状態が必要になるトレーニングやファインチューニングには当てはまりません。ここで示しているのは推論のみです。VRAMを増やしても、画像埋め込み、OCR、メタデータの統合、評価が不十分であれば、検索の精度が保証されるわけではありません。
代表的な画像クエリでVRAMのピークを検証する
使用する量子化モデル、エンコーダー、リランカーを読み込み、1枚の画像、複数の画像、高解像度、長い履歴を使った代表的なクエリを実行します。予定している同時実行数で繰り返しテストし、割り当て済みおよび予約済みのVRAM、メモリ不足の発生、初回トークンのレイテンシ、画像処理時間を記録します。
合成した空白入力ではなく、クリエイターが扱う画像やスクリーンショットを反映した画像パイプラインの帯域幅データセットでテストします。事前計算した経路とリアルタイムエンコードの経路は分けて検証してください。
有効な最悪条件のクエリが、容量の約80~85%未満に収まるVRAM層を選択します。画像エンコードだけで急増する場合は、そのエンコーダーを別の場所に移すか、埋め込みを事前計算します。KVキャッシュが大部分を占める場合は、より大きな視覚モデルが必要だと判断する前に、コンテキストや同時実行数を制限します。
テック&AIハブ
もっと読む

ローカルRAGの検索品質を測定し、再現率・適合率・引用カバレッジを解釈する方法
ローカルRAGのテストセットを構築し、主要な検索指標を算出し、それらのトレードオフを解釈し、回答の主張が引用された根拠によって裏付けられているかを監査する。

サンプリングレートが同じ場合、センサー数の増加に伴ってスマートホームの機能計算がより重要になるのはなぜですか?
デバイス数の増加に伴うセンサーごとおよびセンサー間の計算処理を追跡し、非線形な融合コストを特定して、自動化処理に遅延が生じる前に特徴量パイプラインのベンチマークを実施します。

同じクエリ量でも、ドキュメントライブラリが拡大するとRAG評価コストが重要になるのはなぜか?
ユーザークエリを増やさずにコーパスの拡大がRAG評価の工数を増加させる理由と、層別テストによってコストをリスクに応じて抑えられる仕組みを理解する。

