画像を読めるローカルモデル：写真や画面を見せて質問する方法と、必要なメモリは「本体のファイル＋画像用の部品＋画像トークンの分」

3行でいうと

画像を読めるモデルは、Gemma 4、Qwen3.8-27B、Ministral 3、Devstral Small 2などが公式カードで確認できます。
Ollamaは ollama run gemma4 ./image.png ... のように、画像のパスを添えるだけで質問できます。
画像は「トークン」に変換され、会話の長さを使います。Gemma 4は1枚あたり70〜1120トークンを選べます。
メモリは、本体のファイル、画像用の補助部品、画像トークンの分の3つで見ます。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書やモデルカードを読んでまとめたものです。メモリの数字は、公開されているファイルの大きさと設定ファイルからの、僕らの計算を含みます。

先に結論

写真や画面を見せて「これは何か」「ここに何と書いてあるか」を聞くには、「画像も読めるモデル」を選びます。英語ではVLM（Vision-Language Model）と呼ばれます。文章だけのモデルに画像を渡しても、読んでもらえません。

見立てです。32GBメモリのMacで最初に試すなら、Gemma 4の12B（ファイル約7〜8GB）か、Ministral 3の標準版（約6GB）のような、軽いものから始めるのが安全だと思います。うまく動いてから、Gemma 4の26B A4B（約15〜16GB）やQwen3.8-27B（約16〜18GB）に進むと、メモリ不足で止まったときの原因を切り分けやすいはずです。

前提：言葉の整理

画像も読めるモデル（VLM）：文章を扱う本体に、画像を読み取る部品（ビジョンエンコーダ）がついたモデルです。たとえばMistralのMinistral 3 8Bは、言語モデル8.4Bに、0.4Bの視覚の部品がついた構成だとカードに書かれています。
画像トークン：画像を、文章と同じ「トークン」（AIが数える単位）に直したものです。画像1枚が、数百から数千トークン分の長さを使います。つまり、会話の長さの枠（コンテキスト長）を消費します。
mmproj：llama.cppの用語で、画像を言語モデルにつなぐ部品のファイルです。本体とは別のファイルになっている配布が多く、その分のメモリも要ります。
量子化：ファイルを小さくする圧縮です。「4ビット」は、1つの数を約4ビットで持ちます。

画像の渡し方：道具ごと

Ollama

Ollamaの公式文書（Vision）の例は、次のとおりです。公式文書の例です。この記事では、実行していません。

ollama run gemma4 ./image.png what is in this image?

API（他のソフトからAIを呼ぶ窓口）では、メッセージに images という配列を付けます。ソフトウェア開発キット（SDK）ではファイルのパス、URL、生のデータが使え、REST APIでは、base64という文字列に直した画像データを渡す、と書かれています。

Ollamaのモデル一覧（ライブラリ）では、画像に対応するモデルに「vision」の印が付いています。gemma4、qwen3.8、devstral-small-2には付いており、qwen3-coder-nextには付いていません。

LM Studio

LM Studioの公式文書には、画像入力の説明が2か所あります。

REST API：チャットの命令の入力に、type が image の項目を付け、data_url にbase64の画像データを入れます。
Pythonの開発キット：「VLM（画像も読めるモデル）」を lms.llm(...) で選び、prepare_image() で画像を準備して、.respond() に渡します。文書の例では、lms get qwen2-vl-2b-instruct で小さな画像対応モデルを入れています。

モデル一覧のAPIでは、画像対応のモデルの type が vlm になります。LM Studioのモデルのページには、Gemma 4とQwen3.8のどちらも「vision input（画像入力）」に対応と書かれています。

アプリの画面で、チャットに画像を添える手順は、僕らが読んだ公式文書では確認できませんでした。画面の操作は、版によっても違うはずなので、手元の画面で確かめてください。

llama.cpp

llama.cppの公式文書（Multimodal）によると、画像・音声・動画の入力に対応しています。サーバーのREADMEは、マルチモーダル対応を「現在は実験的な機能」と書いています。

-hf（Hugging Faceから取得）で、対応モデルを指定すると、mmprojも自動で取得されます。止めるには --no-mmproj です。
自分でファイルを用意するなら、-m で本体、--mmproj で補助ファイルを指定します。
補助ファイルは、既定でGPUに載せます。止めるには --no-mmproj-offload です。
画像1枚あたりのトークン数は、--image-min-tokens と --image-max-tokens で調整できます（解像度が可変のモデルだけ）。

公式文書は、OCR（画像の文字を読む）専用のモデルは、決まった形の指示文で学習されているので、各モデルの案内を見るよう注意しています。

候補になるモデル

公式カードで見た、画像対応モデルの一覧

モデル	画像	文脈の長さ	ライセンス	出どころ
Gemma 4（E2B、E4B、12B、26B A4B、31B）	全サイズで対応。E2B・E4B・12Bは音声も	E2B・E4Bは128K、ほかは256K	Apache 2.0	Googleのカード
Qwen3.8-27B	画像と動画に対応	262,144トークン	Apache 2.0	Qwenのカード
Ministral 3（3B、8B、14B）	対応（視覚部品0.4B：8Bの場合）	256K	Apache 2.0	Mistralのカード
Devstral Small 2（24B）	対応	256K（Ollamaの表示は384K）	Apache 2.0	Mistralのカード
Muse Glimmer 30B（Meta）	画像を入力できる。1枚あたり最大4,096トークン	131,072以上	Apache 2.0	Metaのカード

音声の扱いは、モデルごとに違います。Muse Glimmerのカードは、音声の入出力には対応しない、と書いています。

ファイルの大きさ（目安）

モデル	大きさ	出どころ
Gemma 4 E2B	4.6GB（標準タグ）／LM Studioで4.20GB	Ollama／LM Studio
Gemma 4 E4B	6.6〜9.5GB（タグによる）／5.90GB	Ollama／LM Studio
Gemma 4 12B	7.7〜8.0GB／7.40GB。Google公式のQ4_0版は本体6.98GB＋画像用0.18GB	Ollama／LM Studio／Hugging Face
Gemma 4 26B A4B	16〜19GB／15.60GB。Google公式のQ4_0版は本体14.44GB＋画像用1.19GB	同上
Gemma 4 31B	19〜20GB／19.00GB。Google公式のQ4_0版は本体17.65GB＋画像用1.2GB	同上
Qwen3.8-27B	標準タグ18GB／16.10GB	Ollama／LM Studio
Ministral 3	3Bが3.0GB、14Bが9.1GB、標準タグ（latest）が6.0GB	Ollama
Devstral Small 2	標準タグ15GB	Ollama
Muse Glimmer 30B	4ビット相当で、言語モデルが20GB未満	Metaのカード

「～」は、同じモデルでも版（量子化の違い）によって幅があるという意味です。数字はサイトごとに少しずれます。

Gemma 4

Googleのカードは、Gemma 4をテキストと画像を扱うモデルと説明し、「物体の検出、文書やPDFの読み取り、画面やUIの理解、グラフの理解、OCR（多言語を含む）、手書きの認識」を挙げています。画像の縦横比や解像度は可変です。

使い方のコツも書かれています。

プロンプトでは、画像を文章より前に置く。
画像の細かさは「ビジュアルトークンの予算」で決まり、選べる値は70、140、280、560、1120です。分類や説明には小さい値、OCRや文書の読み取りや小さい文字には大きい値を勧めています。

成績表のMMMU Pro（画像を使う難問のテスト）は、31Bが76.9%、26B A4Bが73.8%、12Bが69.1%です（Googleの測定）。

Qwen3.8-27B

Qwenのカードは、画像と動画の理解に対応するモデルと説明し、文書や図、長い動画まで挙げています。ファイルは約16〜18GBで、32GBのMacでは余裕が小さい部類です。

Ministral 3とDevstral Small 2

Mistralの2つです。Ministral 3は、3B、8B、14Bの3つの大きさがあります。8Bのカードは「FP8で12GBのVRAMに収まり、さらに量子化すればもっと小さくなる」と書き、画像を使うときは、縦横比を1:1に近づけ、細長すぎる・横長すぎる画像は切り取るよう勧めています。

Devstral Small 2は、コーディング用に作られたモデルですが、カードの更新点に「画像を分析できる」とあります。画面の見た目を見せて、コードを直させる使い方が考えられます（見立てです）。

Muse Glimmer 30B

Metaのモデルで、Hugging Face上の作成日は2026年8月9日です。カードは「スクリーンショット、グラフ、文書を会話の中で読める」と説明し、4ビット相当に圧縮すると言語モデルが20GB未満で、24GBまたは32GBの範囲に、KVキャッシュや視覚の部品とともに収まる、と書いています。ライセンスはApache 2.0です。

必要なメモリの考え方

メモリに載るものは、次の4つです。

本体：ファイルの大きさとほぼ同じです。
画像用の補助部品：数百MBから1GB強です（Gemma 4のGoogle公式版で0.18〜1.2GB）。
画像の分のKVキャッシュ：画像トークンの数に比例して増えます。
文章の会話の分。

僕らの計算です。Devstral Small 2の設定ファイルは、層数40、KVヘッド数8、ヘッド次元128です。16ビットのKVキャッシュは、1トークンあたり160KiBになります。画像1枚が4,096トークンなら、約0.67GBです。Gemma 4の最大予算（1,120トークン）なら、同じ式で約0.18GBです。ただし、これは別のモデルの設定ファイルを使った例えで、Gemma 4そのものの値ではありません。

見立てです。画像1枚の分は、本体に比べると小さく見えます。ただし、画像を何枚も渡す、動画をコマに分けて渡す、文書のPDFを何ページも渡す、といった使い方では、トークンが何万にもなりえます。このときは、コンテキスト長の設定と、メモリの関係（別の記事で扱います）が効いてきます。

Ollamaの公式文書によると、VRAMが24GiB未満の環境では、既定のコンテキスト長が4kです。僕らの計算です。4,096トークンの枠に、Gemma 4で最大の予算（1,120トークン）の画像を1枚入れると、枠の約4分の1を画像が使います。何枚か渡す前に、長さを上げる必要があるかもしれません。ただし、AppleシリコンでのVRAMの扱いは、公式文書では確認できていません。

選び方・判断の基準

見立てです。

目的が「文字を読む」なら：Gemma 4の高いビジュアルトークン予算、またはOCR専用モデルを検討する。llama.cppの文書にも、OCR専用モデルの案内がある。
目的が「写真の説明・分類」なら：小さい予算でも足りる可能性が高い。軽いモデルから始める。
メモリが16GBなら：4B〜12B級が中心。32GBなら26B〜27B級まで視野に入る。
仕事で使うなら：ライセンスと、画像の中の個人情報の扱いを先に決める。

よくあるつまずき

文章用のモデルに画像を渡している：Ollamaの一覧の「vision」の印、LM Studioの「vision input」の表示を確かめます。
画像より後ろに質問を置いて、うまく答えない：Gemma 4のカードは、画像を先に置くよう勧めています。
補助ファイルが足りない：llama.cppで -m を使う場合、--mmproj を付け忘れると、画像が読めません。-hf なら自動で取得されます。
細かい文字が読めない：予算を上げるか、画像を切り取って文字の部分を大きく見せます。
画像を何枚も渡して、途中で止まる：コンテキスト長の枠を超えています。枚数を減らすか、長さを上げます。

気をつけること

この記事は、実際に使って確かめた記録ではありません。読み取りの精度や速さは、確かめていません。
ファイルの大きさは、Ollama、LM Studio、Hugging Faceの表示から読んだ値で、サイトや版によって違います。
成績表（MMMU Proなど）は、Googleなど各社が自分で測った値で、モデル同士の優劣を示すものではありません。
Ollamaのコンテキスト長の既定値は、VRAMの量による表と、FAQの4096トークンという記述で食い違っています。実際の値は手元で確かめてください。
顔や個人情報を含む写真は、ローカルで動かす場合も、保存先や共有の設定に注意してください。Ollamaの公式FAQは、ローカルで動かす限り、プロンプトやデータは運営側に見えない、と書いています。
モデルの公開状況や、Ollamaの配布名・サイズは、変わることがあります。2026年10月22日に読み直した内容です。

出典

更新履歴

2026年10月25日 書き方を直しました。
- 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した