A100 80GBでOSS VLMのマルチモーダルRAGを比較：A4000 16GBでは起動できなかった理由

はじめに

最近、オープンソースのLLM/VLMの選択肢がかなり増えてきました。

テキスト生成だけでなく、画像を入力できるVLMも増えており、PDFの図表やマニュアル画像をそのままRAGに使えるのではないか、という期待も高まっています。

前回の記事では、PDFに含まれる図表をRAGで扱うために、テキスト抽出、OCR、画像Embeddingなど複数の方法を比較しました。その中で、mode4gのようにページ全体を画像として扱う構成では、検索方式だけでなく、最終的に回答を生成するVLMの性能も重要になることが分かりました。

techblog.heroz.jp

また、別の記事では、A4000 16GB環境で日本語RAG用のOSS LLMを比較しました。テキストRAGでは、A4000 16GBのような比較的安価なGPUでも、gpt-oss 20Bのように実用的に動かせる候補が見えてきました。

(記事リンク)

では、同じようにOSS VLMを使って、マルチモーダルRAGも安価なGPUで動かせるのでしょうか。

結論から言うと、今回の条件ではかなり難しい結果でした。

テキストRAGではA4000 16GBでも現実的なOSS LLMがありましたが、今回試したOSS VLMは、A4000 16GBではどのモデルも起動できませんでした。そのため、今回は社内のA100 80GB環境を使い、vLLMでOSS VLMを起動して比較しています。

今回の記事では、前回と同じデータセットA〜C、同じmode4g構成を使い、回答生成側だけをOSS VLMに差し替えた場合に、どの程度マルチモーダルRAGが成立するのかを見ていきます。

評価条件

前回記事との関係

今回の検証は、前回のPDF図表RAG評価の続編です。

前回は、PDFに含まれる図表をRAGで扱うために、以下のような複数の方式を比較しました。

モード

概要

mode1

テキスト抽出のみ

mode2

OCRテキスト化

mode3

OCR＋画像併用

mode4v

画像Embedding（Voyage）

mode4c

画像Embedding（Cohere）

mode4g

画像Embedding（Gemini）

今回は、その中からmode4gを固定して使います。

つまり、検索側は前回の高精度寄り構成に固定し、回答生成側のVLMだけを差し替えて比較します。

データセット

評価データセットは、前回と同じデータセットA〜Cを使用しました。

データセット

問題数

特徴

データセットA

24問

図解のみで構成される難易度の高いケース

データセットB

30問

テキストと図表が混在するケース

データセットC

20問

図とテキストが併記されたマニュアル形式のケース

評価方法

評価は前回と同様に、主に「情報の網羅性」の観点で行いました。

模範回答に含まれる情報がどの程度含まれているか、不要な情報が追加されていないかを1〜5点で評価しています。各質問に対する回答生成と評価は1回ずつ行い、評価には LLM-as-a-Judge を用いました。評価モデルは Claude Sonnet 4.5 です。

LLM-as-a-Judge の評価は回答の長さや表現、評価ごとのばらつきの影響を受ける可能性があるため、小さなスコア差だけで厳密な順位を判断するのではなく、応答時間、VRAM使用量、日本語遵守も合わせて見る方針にしました。

なお、応答時間も集計していますが、今回はデータセットごとの画像サイズの影響も大きいため、本文では主な判断軸を評価スコア、日本語安定性、VRAM使用量に絞っています。

実行環境

前回のテキストRAG評価では、Ollamaを使ってOSS LLMを起動しました。

一方で、今回はVLMを扱うため、vLLMのOpenAI-compatible APIを使っています。vLLMは、1つのプロセスで1つのベースモデルを起動し、OpenAI互換APIとして呼び出す形で利用しました。

A4000 16GBでも試しましたが、今回対象としたOSS VLMはどれも起動できませんでした。そのため、評価はA100 80GB環境で実施しています。

本記事は、同一条件に厳密にモデルサイズや実装条件を揃えたモデル研究というより、A100 80GB環境で実際にvLLMから利用できたOSS VLMを動かした実用寄りの比較として見てください。

なお、ここでのVRAM使用量は、今回実際にvLLMで起動した条件での値です。量子化版の利用、コンテキスト長、画像枚数、画像解像度を変えれば、より小さいGPUで動かせる可能性はあります。本記事では、今回のmode4g評価をそのまま回す実用寄りの条件として比較しています。

評価対象モデル

今回評価したモデルは以下です。

本文中では、読みやすさを優先して Qwen、Kimi、GLM のような表示名で統一します。正式なモデル名は、今回実際にvLLMで起動したHugging Faceのモデル名に合わせています。

表示名

正式モデル名

GPT-5.5

gpt-5.5

Qwen

Qwen/Qwen3-VL-8B-Instruct

Kimi

moonshotai/Kimi-VL-A3B-Thinking-2506

GLM

zai-org/GLM-4.6V-Flash

Gemma

google/gemma-4-E4B-it

Ministral

mistralai/Ministral-3-14B-Reasoning-2512

Phi

microsoft/Phi-4-reasoning-vision-15B

GPT-5.5は、OSS VLMではなく比較用のクラウドモデルとして入れています。今回の主眼は、OSS VLMを実務的なマルチモーダルRAGの回答生成に使えるかどうかです。

結果と考察

評価スコア

まず、データセットA〜Cにおける評価スコアです。

データセット

GPT-5.5

Qwen

Kimi

GLM

Gemma

Ministral

Phi

データセットA

2.71

2.25

1.58

1.96

1.38

2.13

1.67

データセットB

3.07

2.23

1.93

2.67

1.53

2.73

2.00

データセットC

4.00

3.50

2.30

3.25

2.55

3.00

2.15

データセットA〜Cの評価スコア

全体としては、Qwen、GLM、Ministral が上位グループに入りました。

その中で、今回まず試す候補として見やすかったのは Qwen です。データセットA〜Cを通して大きく崩れにくく、日本語回答も安定していました。

GLMやMinistralも上位グループに入っていますが、この記事では「どれを最初に試すか」という観点で、Qwenを中心に見ていきます。

データセットAは図解中心のため、OSS VLMにも難しかった

データセットAは、今回の中でも特に難しい結果になりました。

理由として大きいのは、データセットAが図解中心のタスクであることです。検索された画像の中から、手順、位置関係、部品の向き、矢印の意味などを読み取り、それをもとに回答する必要があります。

データセットBやデータセットCでは上位グループに入るモデルでも、データセットAではスコアが伸びにくくなっています。

前回の記事では、データセットAのような図解中心のタスクでは、Claude Sonnet 4.5 でもスコアが伸びにくい傾向がありました。今回の結果を見ると、OSS VLMでも、少なくとも一部のケースでは Claude Sonnet 4.5 を上回る結果が出ています。

もちろん、これはOSS VLMがクラウドVLM全般を上回るという意味ではありません。前回の比較でも、クラウドVLMの中で図解中心タスクへの向き不向きは分かれていました。今回見えてきたのは、図解中心のRAGではモデルごとの得意不得意が大きく、OSS VLMにも試す価値があるという点です。

非日本語文字の混入はKimiで目立った

日本語RAGでは、回答の主言語が日本語であることに加えて、回答中に不自然な非日本語文字が混じらないことも重要です。

今回は、回答の主言語が日本語であっても、中国語・簡体字・ハングルなどが不自然に混入した割合を集計しました。

モデル

データセットA

データセットB

データセットC

Qwen

0.00%

0.00%

0.00%

Kimi

45.83%

26.67%

40.00%

GLM

25.00%

3.33%

0.00%

Gemma

0.00%

0.00%

0.00%

Ministral

0.00%

3.33%

5.00%

Phi

0.00%

3.33%

0.00%

非日本語文字の混入率

この観点で目立ったのは Kimi でした。複数のデータセットで非日本語文字の混入が多く、日本語RAGの回答としてそのまま使うには注意が必要です。

一方で、Qwen は今回の範囲では非日本語文字の混入が見られませんでした。Qwenを第一候補として見た理由は、評価スコアだけでなく、この日本語安定性も含めたものです。

なお、非日本語文字の集計では、最終回答としてユーザーに返す本文を対象にし、内部のthinking相当の出力は除外しました。

最大の壁はVRAMだった

今回もっとも大きかったのは、GPUメモリの壁です。

imageVRAM (GB)

テキストRAGでは、A4000 16GBでも評価、応答時間、日本語遵守、VRAM使用量を見ながら、安価なGPUでどこまで成立するかを比較できました。

一方で、VLMでは前提が変わります。画像入力を扱うため、モデル本体だけでなく、画像エンコーダや画像トークン、長いコンテキストを扱うためのメモリも必要になります。

そのため、OSS VLMによるマルチモーダルRAGは、精度だけでなく、利用可能なGPUに収まるかを最初に確認する必要があります。今回の結果では、ここがテキストRAGとの一番大きな違いでした。

まとめ

今回は、A100 80GB環境でOSS VLMを起動し、マルチモーダルRAGの回答生成モデルとして比較しました。

検索方式は前回の記事と同じmode4g固定、データセットも同じデータセットA〜Cを使用しています。前回との違いは、回答生成側をクラウドVLMではなくOSS VLMにした点です。

今回の条件でまず試す候補は Qwen でした。QwenはデータセットA〜Cを通して大きく崩れにくく、非日本語文字の混入も見られませんでした。

一方で、データセットAのような図解中心のタスクは、OSS VLMにとってもまだ難しい結果でした。画像を入力できることと、図解を正しく理解してRAG回答に使えることは別問題です。

また、今回もっとも大きかったのはGPUメモリの壁です。テキストRAGではA4000 16GBでも現実的なOSS LLMがありましたが、VLMでは同じ環境では起動できず、A100 80GBで評価する必要がありました。

OSS VLMによるマルチモーダルRAGは可能性が見えてきています。ただし、現時点ではGPUメモリや運用環境を含めて慎重に設計する必要がある、というのが今回の結論です。