ローカルで動くマルチモーダルLLM｜OSSモデルと始め方【2026年版】

マルチモーダルLLMをローカルで動かす完全ガイド――セットアップから実務活用まで

「画像も音声も扱えるマルチモーダルLLMを、クラウドに頼らず自社サーバーやPCで動かしたい」――そう考えるエンジニアや企業が急増しています。データプライバシーの確保、API費用の削減、オフライン環境での推論、そして社内RAGとの深い統合。こうした要求に応えるのが、マルチモーダルLLMのローカル実行です。本記事では、ローカル実行の意義から代表モデルの選び方・セットアップ・実務への組み込みまでを、実際にマルチモーダルAIとRAG・ベクトルDBを業務で扱う立場から詳しく解説します。

マルチモーダルの基本概念については マルチモーダルとは何か を、実際のビジネス活用事例は マルチモーダルAI活用事例 を併せてご参照ください。

なぜ「ローカル実行」が選ばれるのか

マルチモーダルLLMをローカルで動かす最大の理由はデータ主権の確保です。医療・法務・製造など機密画像や音声を扱う領域では、外部APIへのデータ送信がそもそも許可されないケースがあります。加えて、クラウドAPIはトークン課金に加えて画像1枚あたりの付加料金が発生するため、高頻度・大量バッチ処理ではコストが膨らみます。

実務での経験から言うと、もう一つ見落とされがちなメリットがレイテンシの安定性です。クラウドAPIはネットワーク輻輳や事業者側の負荷によって応答時間が変動しますが、ローカル推論はハードウェアが固定されている分、レイテンシの予測が立てやすくなります。リアルタイム処理パイプラインを組む際に、この安定性は設計の前提として大きく効いてきます。

• プライバシー・コンプライアンス：画像・音声データが外部に出ない
• コスト最適化：大量推論ではGPUサーバー固定費のほうが安くなる損益分岐点がある
• オフライン・エアギャップ環境：工場・病院・官公庁など
• カスタムファインチューニング：手元でLoRAを当てて業務ドメインに特化できる
• RAG・ベクトルDB統合：ローカルのベクトルDBと直結して低レイテンシの検索拡張推論を実現

ローカル実行に必要なハードウェア要件

マルチモーダルLLMはテキスト専用LLMよりモデルサイズが大きく、画像エンコーダ分のVRAMが追加で必要になります。以下は2025〜2026年時点での目安です。

モデル規模	代表モデル例	最低VRAM目安	推奨GPU	量子化(4bit)時
〜7B	LLaVA-7B, Qwen2-VL-7B, InternVL2-8B	8 GB	RTX 3080/4070	6 GB前後
〜13B	LLaVA-13B, InternVL2-26B(4bit)	16 GB	RTX 3090/4090	10〜12 GB
〜34B	Qwen2-VL-72B(4bit), InternVL2-40B	40 GB	A100 40GB / 2×4090	20〜24 GB
70B以上	Qwen2-VL-72B(full), LLaMA-3.2-Vision-90B	80 GB+	A100 80GB / H100	40〜48 GB

CPUオフロード（llama.cppのGPU/CPU分割推論）を使えばVRAM不足をRAMで補えますが、速度は大幅に低下します。開発・検証用途なら許容範囲ですが、本番バッチ処理には向きません。Apple Silicon（M2 Pro以降）はユニファイドメモリのためVRAM/RAM区別がなく、M3 Max(128GB)なら34Bクラスの量子化モデルを実用速度で動かせます。

2025〜2026年注目のローカル対応マルチモーダルLLM

モデルの網羅的な一覧・スペック比較は マルチモーダルAI一覧 および マルチモーダルAI比較 に詳しくまとめています。ここではローカル実行の観点で特に重要なポイントに絞って解説します。

Qwen2-VL（Alibaba）

7B・72Bのバリアントがあり、日本語の文字認識（OCR）精度が高いのが特徴です。文書画像やスクリーンショットを日本語で解析するユースケースで実績があります。transformersライブラリとvLLMの両方でロードできるため、既存のPythonパイプラインへの組み込みが容易です。

LLaVA / LLaVA-NeXT

マルチモーダルLLMのローカル実行における「リファレンス実装」的な存在です。ollama・LM Studio・llama.cppなど主要なローカル推論ツールほぼ全てでサポートされており、セットアップのハードルが最も低いのが強みです。精度面ではQwen2-VLやInternVLに後れを取るものの、学習コスト・コミュニティの豊富さは随一です。

InternVL2（Shanghai AI Lab）

2B〜76Bまで細かいサイズ展開があり、エッジデバイスから高性能サーバーまでスケールを選べるのが実務上の利点です。2Bモデルはラズベリーパイ相当の非GPUデバイスでも動作するため、IoTカメラとの連携など組み込み用途にも使われています。

LLaMA 3.2 Vision（Meta）

11B・90Bのビジョン対応モデル。Metaのオープンウェイトポリシーにより商用利用可能な範囲が広く、ollamaでの対応も早かったです。英語中心の設計ですが、多言語ファインチューニングのベースとして採用されています。

Phi-3.5-Vision（Microsoft）

4.2Bと小型ながら画像理解の質が高く、VRAM 6GBのコンシューマGPUで実用的に動くのがポイント。オンプレミス環境でGPUを増やせない場合の現実的な選択肢です。

主要なローカル推論フレームワークとセットアップ方法

ollama ― 最速で試すならこれ

ollama（ollama.com）はモデルのダウンロード・実行を1コマンドで完結させるツールです。LLaVA・LLaMA3.2-Visionなど主要マルチモーダルモデルに対応しています。

vLLM ― 本番バッチ処理向け高スループット推論

vLLMはPagedAttentionによる効率的なKVキャッシュ管理で、同一GPUでの同時リクエスト処理スループットが大幅に向上します。vllm serve Qwen/Qwen2-VL-7B-Instruct のようなコマンドでOpenAI互換のAPIサーバーが立ち上がるため、既存のクラウドAPI向けコードをほぼそのまま流用できます。実務でのRAGパイプラインへの統合に最も使いやすいフレームワークです。

llama.cpp ― VRAM不足環境のCPUオフロード

C++実装で依存ライブラリが少なく、量子化（GGUF形式）による4bit/8bit推論が可能です。GPU/CPU間でレイヤーを分割する--n-gpu-layersオプションにより、VRAMが足りない環境でもマルチモーダルモデルをある程度動かせます。Pythonからはllamacpp-pythonバインディングを使います。

LM Studio ― GUIで手軽に試す

GUI操作でモデルのダウンロード・切り替えができる開発者向けツールです。技術検証や非エンジニアへのデモに適しています。バックエンドはllama.cppベースです。

マルチモーダルLLMのローカル推論パイプライン設計

ローカルで動かすだけでなく、実務システムに組み込む際のアーキテクチャ設計が重要です。以下は、画像＋テキストの問い合わせをRAGで拡張してローカルLLMに渡すパイプラインの概要です。

画像の前処理と解像度管理

ローカル推論でボトルネックになりやすいのが画像の前処理です。多くのマルチモーダルLLMは内部でViTベースの画像エンコーダを通しており、入力解像度を上げるほどVRAM消費と推論時間が増加します。Qwen2-VLのDynamic Resolutionのような仕組みを持つモデルは、画像内容に応じて自動でパッチ数を調整しますが、それでも高解像度の工業図面や医療画像を扱う際は事前のリサイズ戦略が必要です。

実務での推奨は「まず896×896前後にリサイズして推論し、詳細が必要な領域だけクロップして再推論する」二段階アプローチです。この方法でVRAMとレイテンシのバランスを取っています。

マルチモーダルRAGとローカルベクトルDBの統合

画像を含むドキュメントをRAGで検索可能にする際、テキストチャンクのベクトル化だけでなく画像の埋め込みベクトル化も必要です。CLIP系のローカルモデル（open_clip等）でローカルに画像を埋め込み、ChromaやQdrant、PGVector（PostgreSQL拡張）などのローカル対応ベクトルDBに格納します。

LangChain・LlamaIndexはどちらもローカルLLMとの統合をサポートしており、ollamaバックエンドやvLLMのOpenAI互換APIエンドポイントをそのまま指定できます。データが外部に一切出ないフルローカルRAGパイプラインの構築は、2024年以降かなり現実的なコストで実現可能になりました。

量子化と精度トレードオフ

ローカル実行でハードウェア制約を緩和する最も一般的な手段が量子化です。精度と速度・VRAM消費のトレードオフを以下に整理します。

量子化方式	VRAM削減率目安	精度低下	推奨用途
FP16（半精度・無量子化）	基準	なし	精度最優先・A100/H100環境
INT8（8bit）	約50%削減	極小	本番推論・コンシューマGPU
INT4（4bit / GPTQ/AWQ）	約75%削減	小〜中	VRAM制約環境・開発検証
GGUF Q4_K_M（llama.cpp）	約75%削減	小〜中	CPUオフロード・Apple Silicon
2bit（AQLM等）	約87%削減	大	実験用・超省メモリ環境

マルチモーダルモデルの場合、言語モデル部分は4bit量子化しても影響が小さい一方、画像エンコーダ（ViT部分）は量子化の影響を受けやすいという特性があります。AWQ/GPTQを使う際は、ビジョンエンコーダをFP16のまま残してLLM側だけ量子化するオプションを持つ実装（BitsAndBytesのload_in_4bit等）を選ぶと精度低下を最小限に抑えられます。

ファインチューニング（LoRA）でドメイン特化させる

ローカル実行のもう一つの強みは、手元でファインチューニングしてモデルを業務ドメインに特化できる点です。フルパラメータ更新は非現実的でも、LoRA（Low-Rank Adaptation）を使えばコンシューマGPU1枚で数時間〜1日程度のファインチューニングが可能です。

マルチモーダルLoRAの基本的な進め方

1. データ準備：画像＋テキストの教師データをJSON Lines形式で用意。最低でも200〜500サンプル、理想は1,000以上
2. ライブラリ選定：LLaMA-Factory・Axolotl・Swift（ms-swift）がマルチモーダルLoRAに対応しており、設定ファイルベースで扱いやすい
3. LoRAターゲット層の指定：言語モデル側のattention層（q_proj/v_proj等）をターゲットに。ビジョンエンコーダは凍結するのが一般的
4. 学習実行：bf16混合精度・gradient checkpointingを有効化してVRAM効率を上げる
5. マージまたはアダプターのみ保存：本番運用ではベースモデル＋LoRAアダプターの分離保存が管理しやすい

製造業の品質検査や医療画像の所見分類など、クラウドAPIに出せない特定ドメイン画像でのLoRAファインチューニングは、ローカル実行と組み合わせることで初めて成り立つユースケースです。

セキュリティと運用管理の注意点

ローカル実行はデータが外部に出ない分、セキュリティの責任がすべて自社に移る点を忘れてはなりません。

• モデルの出所確認：Hugging Faceからダウンロードする際は、公式組織アカウントからのモデルであることを確認。コミュニティ製の量子化モデルは信頼できるユーザーのものを選ぶ
• 推論サーバーのネットワーク分離：vLLMやollamaのAPIサーバーはデフォルトで認証なしのため、本番環境では必ずリバースプロキシ（nginx等）でアクセス制限を設ける
• 入力バリデーション：画像入力経由のプロンプトインジェクション攻撃（画像内に命令を埋め込む手法）への対策として、入力の前処理と出力のフィルタリングを実装する
• モデルバージョン管理：MLflowやDVC等でモデルのバージョン・量子化設定・LoRAアダプターを管理し、ロールバックできる体制を整える
• GPU監視：nvidia-smiやPrometheus + nvidia_gpu_exporterでVRAM使用率・温度・スループットを継続監視する

実務での活用シーン別おすすめ構成

ユースケース	推奨モデル	推奨フレームワーク	ポイント
文書・帳票OCR＋理解	Qwen2-VL-7B（INT8）	vLLM	日本語OCR精度が高い
製造ライン画像検査	InternVL2-8B＋LoRA	vLLM / transformers	ドメインLoRAで精度向上
社内ナレッジRAG（画像含む）	LLaVA-13B or Qwen2-VL-7B	LlamaIndex＋ollama	フルローカルRAGパイプライン
エッジ・IoTデバイス	InternVL2-2B or Phi-3.5-Vision	llama.cpp	VRAM 4GB以下でも動作
開発・プロトタイピング	LLaVA-7B（4bit）	LM Studio / ollama	最短セットアップ時間

クラウドAPIとの使い分け基準

ローカル実行が万能ではないことも重要な認識です。GPT-4o・Gemini 1.5 Pro・Claude 3.5 Sonnetなどクラウドトップモデルとの性能差は、特に複雑な多段推論・長いコンテキストウィンドウ・最新情報へのアクセスで依然として存在します。以下の基準で使い分けを判断することを推奨します。

• ローカル一択：機密画像・音声を扱う／オフライン必須／大量バッチで単価を下げたい／ドメイン特化LoRAが必要
• クラウドAPIが優位：最高品質の推論が必要／開発初期のプロトタイプ／GPUリソースが確保できない／マルチモーダルの種類（動画・音声合成等）が多岐にわたる
• ハイブリッド：機密度の低いデータはクラウドAPI、機密データはローカルと振り分けるルーティング設計

まとめ

マルチモーダルLLMのローカル実行は、2025〜2026年時点で開発者が手の届く現実的な選択肢になっています。要点を整理します。

• データプライバシー・コスト・レイテンシ安定性の観点でローカル実行の優位性がある
• 7Bクラスの量子化モデルならRTX 3080〜4070（VRAM 8GB）で実用推論が可能
• ollamaは最速セットアップ、vLLMは本番バッチ、llama.cppはVRAM不足対策という使い分けが基本
• Qwen2-VL・InternVL2・LLaMA3.2-Vision・Phi-3.5-Visionがローカル用途の主要モデル
• RAG統合はvLLMのOpenAI互換APIとローカルベクトルDBの組み合わせで実現しやすい
• LoRAファインチューニングにより業務ドメイン特化が可能
• セキュリティ・運用管理の責任が自社に移る点を必ず設計に織り込む

マルチモーダルAIの活用事例・適用ビジネスシーンについては マルチモーダルAI活用事例 を、主要モデルの性能・機能比較の詳細は マルチモーダルAI比較 をご参照ください。

関連記事

• マルチモーダル 意味
• マルチモーダルai 事例
• マルチモーダルai 一覧
• マルチモーダルai 比較
• マルチモーダルai 無料
• マルチモーダルai 仕組み
• マルチモーダルrag
• マルチモーダルai できること