Vision-Language Model (VLM) GPU別ベンチマーク 2026年版:Qwen 2.5-VL / Llama 4 Maverick / Pixtral を RTX 5090・Mac Studio で動かす実測 tok/sec
Qwen 2.5-VL / Llama 4 Maverick / Pixtral など主要VLM(マルチモーダルLLM)を RTX 5090・PRO 6000・Mac Studio M3 Ultra・Strix Halo で動かしたときの画像トークン数・prefill 時間・生成 tok/sec・VRAM 使用量を整理。画像入力 = 数千トークンの prefill が支配的という構造から、テキストLLMとは別の判断軸でGPUを選ぶ必要がある理由を、解像度別に解説します。
- #VLM
- #Vision-Language Model
- #Qwen 2.5-VL
- #Llama 4 Maverick
- #Pixtral
- #マルチモーダルLLM
- #RTX 5090
- #Mac Studio
- #ローカルLLM
- #GPUベンチマーク
本記事は Amazon.co.jp および各販売店のアフィリエイトリンクを含む場合があります。推奨は性能・コスパ・実機ベンチマーク基準で編集判断しており、提供記事は受け付けていません。詳細は プライバシーポリシー をご覧ください。
結論:VLM(Vision-Language Model)はテキスト LLM と同じ感覚で GPU を選ぶと外します。画像 1 枚で数千トークンの prefill が支配的になるため、decode 速度より prefill compute(Tensor Core の FLOPS)と TTFT で選ぶべきです。RTX 5090(32GB)は 7B〜32B 級 VLM + 中解像度画像までが快適帯。RTX PRO 6000 Blackwell(96GB)は 72B 級 VLM + 高解像度+複数画像まで単体で扱える唯一の現実解。Mac Studio M3 Ultra(192GB)は巨大 VLM が「乗る」が、prefill が遅く長文+高解像度では TTFT が秒〜十秒級に伸びる弱点があります。Strix Halo は 96GB 割当でモデル容量は確保できますが、prefill compute では NVIDIA に劣ります。
ローカル LLM の GPU 選定情報はテキスト推論を前提にしたものが大半で、VLM(マルチモーダル LLM)固有の挙動は空白地帯です。本記事は Qwen 2.5-VL / Llama 4 Maverick / Pixtral など 2025〜2026 年の主要 VLM を、RTX 5090 / PRO 6000 / Mac Studio / Strix Halo で動かしたときの公開ベンチ報告を横断集約し、「VLM ではなぜ判断軸が変わるか」「自分の用途ならどの GPU を選ぶか」を整理します。
iris-lab の自前実測ではなく、公開ベンチと r/LocalLLaMA / Hugging Face Discussions / vLLM Blog 等の報告を横断したスナップショットです。具体数値はあくまでレンジとして読んでください。
VLM の前提:画像 = 数千トークンの prefill
テキスト LLM の prefill(プロンプト処理)が「入力文字列をトークン化して KV を作る」プロセスなのに対し、VLM の prefill には ビジョンエンコーダ通過 + 画像トークンの KV 構築 が加わります。
主要 VLM の画像トークン消費の目安は次の通りです。
| 解像度 | 画像トークン目安(モデル依存) |
|---|---|
| 512x512 | 256〜600 |
| 1024x1024 | 1,000〜2,000 |
| 2048x2048 | 3,500〜5,000+ |
Qwen 2.5-VL は動的解像度(画像サイズに応じてトークン数が変動)で、Pixtral も画像を 16x16 のパッチに分割した上でアスペクト比を保つ方式です。1024x1024 の画像 1 枚 ≒ テキスト 1,500 トークン分 と見積もると、長文+画像複数枚の入力が数万トークン規模になることが直感できます。
この「画像入力 = 大量 prefill」という構造から、VLM では decode(生成 tok/sec)より prefill 時間と TTFT(最初のトークンまでの秒数)が体感を支配します。prefill は compute 律速・decode はメモリ帯域律速という詳細は「ローカルLLM プロンプト処理(prefill)速度 GPU別ベンチマーク 2026年版」で扱っています。VLM はこの prefill 問題が極端化したケースだと考えると理解しやすいです。
主要 VLM の前提(2026年版)
2025〜2026 年時点で個人〜小規模法人が触れる主要 VLM は次のラインナップです。
| モデル | サイズ | 特徴 | Q4 重み目安 |
|---|---|---|---|
| Qwen 2.5-VL 7B | 7B | 軽量・動的解像度・OCR強い | 約 5GB |
| Qwen 2.5-VL 32B | 32B | 7B と 72B の中間、実用ライン | 約 18〜20GB |
| Qwen 2.5-VL 72B | 72B | OSS VLM の最上位帯、GPT-4o 級 | 約 40〜43GB |
| Llama 4 Maverick | 17B active / 400B total MoE | 128 expert MoE、長文 128K+ | FP8 約 400GB / Q4 約 200GB |
| Pixtral 12B | 12B + 400M vision encoder | Mistral 製、128K context | 約 7GB |
| Pixtral Large | 124B | 高精度・大規模商用向け | 約 70GB |
| Gemma 3 27B | 27B(画像対応) | Google 製、軽量〜中量級 | 約 16GB |
| InternVL 2.5 | 8B〜78B | 中国系 OSS、文書・チャート強い | サイズ別 |
Llama 4 Maverick は MoE(128 expert)で 17B active / 400B total という変則的な構造です。アクティブパラメータは 17B でも、全 expert の重みを VRAM に乗せる必要があるため、FP8 で約 400GB、Q4 級でも 200GB が必要です。1 枚の消費者向け GPU では到底乗らず、Mac Studio M3 Ultra 512GB か RTX PRO 6000 を複数枚束ねる構成が前提になります。
Pixtral 12B は 400M パラメータのビジョンエンコーダ + 12B 言語モデルで、128K context・最大 2,000 画像/バッチを謳う長文+多画像向けです。Qwen 2.5-VL 72B と並んで OSS VLM の主力です。
GPU 別の「VLM 実用帯」マトリクス
主要 GPU・SoC が「どの VLM をどの解像度で実用的に回せるか」を、公開ベンチ報告のレンジで整理します。実用的とは TTFT が「ちょっと待てば返ってくる」=10 秒以内、生成 tok/s が 10 以上、を目安にします。
| GPU / SoC | VRAM | 7B(512px) | 32B(1024px) | 72B(1024px) | Maverick / Pixtral Large |
|---|---|---|---|---|---|
| RTX 5090 | 32GB | ◎ TTFT < 1s, 70〜100 tok/s | ○ TTFT 1〜2s, 30〜45 tok/s | × VRAM 不足 | × |
| RTX 4090 | 24GB | ○ TTFT 1〜2s, 50〜70 tok/s | △ Q3 で押し込み | × | × |
| RTX PRO 6000 Blackwell | 96GB | ◎ TTFT < 1s, 80〜110 tok/s | ◎ TTFT 1〜2s, 40〜55 tok/s | ○ TTFT 2〜4s, 18〜28 tok/s | △ Pixtral Large 単体可 |
| Mac Studio M3 Ultra 192GB | 192GB | △ TTFT 2〜4s, 25〜40 tok/s | △ TTFT 5〜10s, 12〜18 tok/s | △ TTFT 10〜20s, 8〜12 tok/s | △ 乗るが TTFT 数十秒級 |
| Mac Studio M3 Ultra 512GB | 512GB | 同上 | 同上 | 同上 | ○ Maverick が乗る、ただし prefill 遅い |
| MacBook Pro M4 Max 128GB | 128GB | △ TTFT 3〜6s, 20〜30 tok/s | △ TTFT 8〜15s, 8〜12 tok/s | × 容量ギリギリ | × |
| Strix Halo(96GB 割当) | 96GB | ○ TTFT 2〜3s, 30〜45 tok/s | △ TTFT 5〜8s, 15〜20 tok/s | △ TTFT 10〜15s, 8〜12 tok/s | × |
数字は短文プロンプト(〜2K text + 1 画像)、Q4_K_M ベース、llama.cpp / vLLM / mlx 系での公開報告のレンジです。プロンプトが長い・画像が複数になるほど、TTFT は線形以上に伸びます。
読み取り方を整理します。
- RTX 5090(32GB) は 7B〜32B VLM + 中解像度なら最速帯。72B はそもそも乗らないので、無理に押し込まず素直に 32B 級で運用するのが現実解
- RTX PRO 6000 Blackwell(96GB) は VLM では最も穏当な選択。72B + 1024 級の画像をシングル GPU で扱える唯一の量産品
- Mac Studio M3 Ultra は「巨大 VLM が物理的に乗る」のは強み。だが prefill が遅いため、長文+高解像度のエージェント用途では TTFT がストレスになる
- Strix Halo(96GB 割当) はモデル容量は確保できるが、prefill compute では NVIDIA に劣る。VLM ではテキスト LLM 以上に NVIDIA との差が広がる
解像度を上げると何が起きるか
解像度を 512 → 1024 → 2048 と上げたときの prefill 時間の伸び方は、GPU 種別で性格が分かれます。Qwen 2.5-VL 32B を例にレンジで示します。
| 解像度 | 画像トークン目安 | RTX 5090 TTFT | M3 Ultra TTFT | PRO 6000 TTFT |
|---|---|---|---|---|
| 512x512 | 〜600 | 0.3〜0.5s | 1.5〜3s | 0.3〜0.6s |
| 1024x1024 | 1,500〜2,000 | 0.8〜1.5s | 4〜8s | 0.7〜1.2s |
| 2048x2048 | 3,500〜5,000 | 2〜4s | 12〜25s | 1.8〜3.5s |
RTX 5090 / PRO 6000 は解像度を 4 倍にしても TTFT は 3〜5 倍程度 で済むのに対し、Mac Studio は 解像度 4 倍で TTFT が 6〜10 倍 に膨らみます。これが VLM で Apple Silicon が苦しくなる構造の正体です。CUDA コアの生スループットが画像トークンの prefill で効くため、unified memory で容量を稼げる Mac の利点を、prefill compute の差が打ち消してしまいます。
M5 世代の Apple Silicon は専用の Neural Accelerator で prefill を最大 4 倍高速化したと公表されており、この弱点を埋めにきています。M5 Ultra(2026 年中後半予想)世代が出れば、Mac は VLM でも実用域に入る可能性があります。
用途別の判断軸
VLM を選ぶ前に「自分の用途は短文+1 画像か、長文+複数画像か」を見極めるのが先です。
単発の画像理解(チャート読み・OCR・要約)
入力は「短いテキスト + 画像 1 枚」が中心。prefill は数千トークン規模で済み、TTFT より生成 tok/s のほうが体感に効きます。
- Qwen 2.5-VL 7B / 32B + RTX 5090 が最もコスパが良い帯
- 32GB あれば 32B Q4 が快適に乗り、OCR 精度や図表理解は 72B にやや劣る程度
- 32B でも MMMU・ChartQA 系のベンチで実用十分のスコアが出ている
長文+複数画像のエージェント(ドキュメント理解・コードレビューUI)
入力が数万トークン+画像複数になり、prefill が支配的になる用途。
- RTX PRO 6000 Blackwell(96GB) で 32B〜72B VLM を回すのが穏当
- VRAM 余裕が大きいため KV キャッシュも詰めず長文に強い
- Mac Studio は「乗るが遅い」ため、エージェント用途には合わない
最大規模(Pixtral Large / Llama 4 Maverick)
400B 級 MoE / 124B のような巨大 VLM を触りたい用途。
- Mac Studio M3 Ultra 512GB か、RTX PRO 6000 を複数枚 が現実解
- Mac は乗る代わりに遅い、NVIDIA 複数枚は速い代わりに電源・ケース・冷却が話の中心になる
- ここまで来ると個人ユースより小規模法人の研究用途の領域
テキスト LLM 側との対比は「Llama 3.3 70B GPU別トークン/秒 2026年版」、画像「生成」側との対比は「SDXL / Flux 画像生成 GPU別ベンチマーク 2026年版」で扱っています。画像理解(VLM)・画像生成(SDXL/Flux)・テキスト推論(Llama)の 3 つは、同じ GPU でも要求するリソースが大きく違うため、自分の主用途に合わせて GPU を選ぶのが最短です。
バッチ複数画像時のスケーリング
VLM をバッチ処理(複数画像を一度に渡す)で回すと、prefill 時間は画像数にほぼ線形で増えます。RTX 5090 / Qwen 2.5-VL 32B で 1024 画像を 1 枚→4 枚→16 枚と増やしたときの目安は、TTFT が 1s → 3〜4s → 12〜16s 程度のレンジで報告されます。
vLLM の continuous batching を使うと、複数リクエストの prefill を交互に処理してスループットを稼げますが、単一リクエストの TTFT は短縮できません。「同じ画像群を 1 度に処理したい」用途では、PRO 6000 のような prefill 速度が出る GPU が効く ということになります。
バックエンド別の補足
- vLLM:Maverick など MoE モデルへの対応が v0.8.3 以降に入り、本番サービング向けに最適。CUTLASS-based GroupedGEMM カーネルで MoE の prefill を高速化
- llama.cpp:Qwen 2.5-VL / Pixtral / Gemma 3 など主要 VLM への対応が 2026 年前半までに揃った。CPU / 各種 GPU で動く汎用性が強み
- mlx-vlm:Apple Silicon 専用。M3/M4 で Qwen 2.5-VL / Pixtral / Gemma 3 を最適化済み。Mac Studio で VLM を試すならまずこれ
- TensorRT-LLM:NVIDIA 専用、prefill 速度を最大化したい本番用途向け
ランタイムごとの性能差はテキスト LLM と同様で、「ローカルLLM実行ツール比較 2026年版」の枠組みがそのまま VLM にも当てはまります。
まとめ:VLM はテキスト LLM と「別の物差し」で GPU を選ぶ
- VLM の体感は decode tok/s ではなく prefill 時間と TTFT で決まる
- 画像 1 枚で 1,000〜2,000 トークン、2048 級なら 4,000+ トークンの prefill が乗る
- RTX 5090(32GB) = 7〜32B VLM + 中解像度の最速帯
- RTX PRO 6000 Blackwell(96GB) = 72B + 高解像度+複数画像までシングルで扱える唯一の現実解
- Mac Studio M3 Ultra = 巨大 VLM が乗るが prefill が遅い、長文+高解像度では TTFT がストレス
- Strix Halo = 96GB 割当でモデル容量は確保できるが、prefill compute で NVIDIA に劣る
- 用途を「単発画像理解か、エージェントか、最大規模か」で見極めてから GPU を選ぶ
VLM はテキスト LLM の延長で語られがちですが、prefill が支配的になる時点で判断軸が変わります。「decode は速いが prefill が遅いマシン」 は短文+1 画像までは使えるのに、長文+複数画像で急に実用に乗らなくなる。この落差を知ったうえで、自分の主用途に合わせて GPU を選んでください。
入手先・関連商品
当サイトは Amazon.co.jp アソシエイト・プログラムに参加予定です。下記リンク経由で購入された場合、紹介料を受け取ることがあります。読者の負担は増えません。リンクは記事評価とは独立しており、編集判断には影響しません。
速度重視・7〜32B VLM 帯
- NVIDIA GeForce RTX 5090 を Amazon.co.jp で見る：7〜32B VLM + 中解像度を最速で回す本命。VLM で迷ったらまずこれ
業務・72B VLM + 複数画像帯
- NVIDIA RTX PRO 6000 Blackwell を Amazon.co.jp で見る：96GB で 72B VLM + 高解像度+複数画像をシングルで扱える唯一級。エージェント用途の本命
巨大モデル・unified memory 帯
- Apple Mac Studio M3 Ultra を Apple公式サイトで見る：Pixtral Large / Maverick まで「乗せる」ことができる。prefill 遅さを許容できる研究・検証向け
あなたに合うPCを診断する
用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。
→ 診断スタート
関連記事
- ローカルLLM プロンプト処理(prefill)速度 GPU別ベンチマーク 2026年版:prefill が VLM でなぜ効くかの理論編
- Llama 3.3 70B GPU別トークン/秒 2026年版:テキストLLM側との比較
- SDXL / Flux 画像生成 GPU別ベンチマーク 2026年版:画像「生成」側との対比
- ローカルLLM実行ツール比較 2026年版:vLLM / llama.cpp / mlx の使い分け
- メモリ帯域幅(GB/s)がローカルLLMの tok/sec を決める仕組み 2026年版:decode 律速側の理論
よくある質問
- VLM とテキストLLM で何が変わりますか?
- 入力に画像が加わる分、prefill(プロンプト処理)に必要なトークン数が桁違いに増えます。テキスト LLM なら数百〜2,000 トークンで済む入力が、1024x1024 の画像 1 枚で 1,000〜2,000 トークン、2048x2048 の高解像度なら 4,000 トークン以上が一気に乗ります。decode(生成 tok/sec)より prefill 時間と TTFT(最初のトークンまでの秒数)が体感を支配するようになり、メモリ帯域より prefill compute(Tensor Core の FLOPS)が効くケースが増えます。
- VLM を動かすのに必要な VRAM はテキスト LLM より多い?
- 重みとしては多くなく、ビジョンエンコーダ(数百MB〜数GB)が上乗せされる程度です。Pixtral 12B のビジョンエンコーダは約 400M パラメータ、Qwen 2.5-VL 系も同程度のオーバーヘッドで、テキスト LLM とほぼ同じ VRAM 帯で動きます。一方で画像トークンが入る分、KV キャッシュは膨らみます。1024x1024 画像 1 枚で KV が数百 MB〜1GB 単位で増える計算になり、長文+画像複数枚を扱うエージェント用途では VRAM 余裕が必要です。
- Apple Silicon の Mac Studio で大きな VLM は動かせる?
- 「乗る」ことは可能ですが、prefill が遅いため実用性は限定的です。M3 Ultra の 192GB Unified Memory なら Pixtral Large 124B や Llama 4 Maverick(FP8 約 400GB は 512GB モデルが必要)を物理的にロードできますが、画像入力の prefill は compute 律速で、CUDA コアを多数積む NVIDIA に大きく劣ります。短文+1 画像なら何とか待てる速度ですが、複数画像や 2048 級の高解像度を渡すと TTFT が秒〜十秒級になり、エージェント用途では実用に乗りません。
- RTX 5090 32GB で Qwen 2.5-VL 72B は動きますか?
- Q4_K_M(約 40〜43GB)では単体では乗りません。32B モデルなら Q4_K_M(約 18〜20GB)で快適、画像 1〜2 枚であれば KV キャッシュ込みで余裕があります。72B を回したいなら RTX PRO 6000 Blackwell(96GB)か、2 枚構成、または Q3 級まで落として 32GB に押し込む選択になりますが、Q3 は VLM では画像認識精度の劣化が大きく実用的ではありません。VLM で 72B 級を素直に動かすなら 48GB 以上が現実的な目安です。