「画像も読めるローカルAI(VLM)は、日本語で実際どこまで使えるのか」——OCR・数える・チャート読み・表の抽出を、当サイトのRTX A6000で5つのVLMに実測させました。速度・VRAM・電力と、日本語画像タスクの正答をまとめます。

30秒でわかる結論

  • 合成タスク(印刷文字・単純図形=易しめ)では qwen3-vl系・gemma系が全員満点。qwen3-vl:2bは2Bで満点かつ約268 tok/s(最速)、VRAMも9.5GB。
  • 実写(工事・林業・木口・駅看板OCR)で差がつき、総合力は gemma4:26b:傾いた看板の駅名・紹介文・距離の数字まで完璧で約122 tok/s(詳細は下の「実写・ドメイン編」)。
  • qwen3-vl:2bは2Bで健闘(実写4/5)だが、複雑な看板OCRはタイムアウト=密なOCRは一段上のモデルが要る
  • 英語専用のmoondreamは合成も実写も日本語0点で全滅。qwen3-vl:8bが林業写真を中国語で返す言語ドリフトも観測=日本語で確実に返させるには検証が要る。
  • 現場の精度には汎用VLMより「ドメインFT」:汎用VLMで"読める"ことと、業務で"使える精度"は別物。当サイトの丸太検出はファインチューニングで本数recall 0.42→0.95まで上がった(自作FT実例)。

計測条件

  • 機材:RTX A6000 48GB(ollama 0.31.1・全モデル ollama ps で100% GPU常駐を確認)
  • タスク:日本語の画像8問(OCR日本語/OCR英数/数える/色と順序/チャート読み/数値表示/表抽出/式読解)を正解が既知の合成画像で作成し、temperature 0・2回目を採用
  • 指標:生成速度 tok/s・TTFT・VRAM(ollama ps・64K文脈込み)・推論時電力(nvidia-smi)・正答(0/0.5/1)

速度・VRAM・電力(A6000実測)

モデル種別速度 tok/sTTFTVRAM電力tok/s/W
qwen3-vl:2b小型VLM268約260ms9.5GB211W1.27
gemma4:26bMoE VLM122約230ms18GB227W0.54
qwen3-vl:8b中型VLM104約650ms15GB273W0.38
gemma3:27b密VLM33約660ms17GB281W0.12
moondream:1.8b英語tiny(日本語不可)約80ms1.2GB※
ローカルVLMの生成速度(tok/s・A6000実測・日本語画像タスク)
  • qwen3-vl:2b(小型・合成8タスク満点)268
  • gemma4:26b(MoE・満点)122
  • qwen3-vl:8b(満点)104
  • gemma3:27b(密・満点だが遅い)33

qwen3-vl:2bが最速(268 tok/s)で合成8タスク満点。密27Bのgemma3は33で約8倍遅い。moondreamは速いが日本語で全滅(0/8)のため除外。※合成タスクは易しめで、実写では差が開く見込み。

VRAMはollama既定の64K文脈込み(※moondreamのみ2K文脈で1.2GBと条件が異なる)。2BのVLMでも画像エンコーダ+文脈で約9.5GBは要る(同サイズのテキストLLMより大きい)=「小型VLM=省VRAM」ではない点に注意。

合成タスクの正答(8問)

モデル正答備考
qwen3-vl:2b8/82Bで満点
gemma4:26b8/8丁寧な日本語
qwen3-vl:8b8/8表抽出がきれい
gemma3:27b8/8正答するが遅い(33 tok/s)
moondream:1.8b0/8日本語で空回答・中国語化

moondreamの失敗例:「測量士補 第0123号」→「中央顶層」、「42.5 kg」→「インターバー」、数える・色・チャートは空回答。英語では動作するモデルですが、日本語のOCR・読解は現状使えません

見どころ

  • 2Bで満点の衝撃:qwen3-vl:2b は印刷OCR・数える・チャート・式読解を27Bと同じく全問正答し、速度は約8倍。やさしいタスクなら小型VLMで十分という強い結果。
  • 英語専用tinyの落とし穴:moondream は速いが日本語で全滅。日本語で使うなら「小ささ」より「日本語対応」で選ぶ
  • VRAMは文脈長で膨らむ:どれも64K文脈込みで9.5〜18GB。載るかは必要VRAM早見表動くか診断で確認を。
  • 合成タスクの限界:印刷文字・単純図形は易しく、実VLMはほぼ満点。実写では実際に差が開いた(下の「実写・ドメイン編」)。手書き野帳・丸太の実カウント・ハザード判定など当サイトの本命moatは、追って実測する。

実写・ドメイン編(ネット公開画像で追試)

合成タスクは易しく全員満点だったので、Wikimedia Commonsの実写4枚(CC/PD)で追試しました。正解は目視で確定しています。

  • 工事現場:重機で道路舗装を割って撤去する現場
  • 林業:森の木道を丸太積載トラックが通る古い白黒写真(1937年)
  • 木口/断面:巨大な木の輪切り(年輪)=丸太計測の中核
  • 駅看板OCR:JR西大山駅の看板(「JR日本最南端の駅」「西大山」、東京1,550キロ等の距離表。傾き・退色あり)
易しいベンチでは差が出ない — 実写で本当の差が見える

合成タスク(印刷文字・単純図形)

実VLMは全員満点(8/8)=順位がつかない

qwen3-vl / gemma … すべて 100%

実写(工事・林業・木口・看板OCR)

順位が割れる

gemma4 5 > qwen3-vl:8b 4.5 > 2b 4 > gemma3 3.5 > moondream 0

ベンチマークは難しさで結果が変わる。実運用に近い実写で測るのが重要。

モデル実写5タスク実写での傾向
gemma4:26b5/5工事・林業・木口の理解から、看板の駅名・紹介文・距離の数字まで完璧
qwen3-vl:8b4.5/5強いが林業写真の説明を中国語で返した(言語ドリフト)
qwen3-vl:2b4/52Bで健闘。ただし複雑な看板OCRはタイムアウト(密なOCRは苦手)
gemma3:27b3.5/5現場・木口は正確だが看板で「日本最南端」を「九州最南端」と誤読・距離の数字も乱れた
moondream:1.8b0/5実写でも日本語は空回答
実写ドメイン5タスクの正答スコア(A6000実測・0〜5点)
  • gemma4:26b5.0
  • qwen3-vl:8b(林業写真で中国語ドリフト)4.5
  • qwen3-vl:2b(複雑な看板OCRはtimeout)4.0
  • gemma3:27b(看板OCRで誤読)3.5
  • moondream:1.8b(日本語不可)0

合成8タスクは全員満点で差ゼロ。実写(工事・林業・木口・駅看板OCR)で順位が割れた。総合力はgemma4:26b。

わかったこと(合成との違い):
  • 実写は差がつく。合成では全員満点だったが、実写(特に看板の日本語OCR)で順位が明確に割れた。ベンチは易しいと差が出ないという好例。
  • 実写の総合力は gemma4:26b:工事・林業・木口の理解から、傾いた看板の駅名・距離の数字まで完璧。木口(年輪)は日本語が通る4モデル(qwen3-vl系・gemma系)はいずれも正しく認識でき、gemma4はセコイアと樹種まで当てた(moondreamは実写でも空回答)。
  • qwen3-vl:2bは2Bとして驚異的(実写でも4/5)だが、情報量の多い看板OCRはタイムアウト=密なOCRは一段上のモデルが要る
  • 「大きい=正確」ではない:密27Bのgemma3が看板OCRで誤読(日本→九州・数字乱れ)、新しいMoEのgemma4が上回った。
  • 言語ドリフトに注意:qwen3-vl:8bが林業写真を中国語で返した。中国語ベースが漏れるため、日本語固定にはプロンプト指定や検証が要る。
  • “読める”と“業務で使える精度”は別物=ドメインFTが効く:汎用VLMは実写でも工事・林業・木口を"それらしく"説明できるが、丸太の本数を正確に数える・野帳を精密に読むといった現場精度は汎用のゼロショットでは足りないことが多い。当サイトの丸太検出の自作FT(YOLO)では、汎用検出からファインチューニングで本数recall 0.42→0.95まで改善した。構造化出力なら妖怪QLoRAのようにJSON 99.97%も可能。実写でVLMを試して当たりを付け、精度が要る業務はFTで仕上げる——が現実的な設計です。

実写画像の出典(Wikimedia Commons・各CC/PD):Broken concrete roadTruck transportation of logs (1937)Cross section of Sequoia sempervirensNishi-Ooyama station signboard

実際に動くか・必要VRAM

ローカルVLM(画像も見るモデル)で日本語に強いのは?
当サイトのA6000実測では、合成8タスクは qwen3-vl:2b/8b と gemma3:27b・gemma4:26b が全問正答(英語専用moondreamは0/8)。ただし合成は易しく全員満点で、実写(工事・林業・木口・駅看板OCR)で差がつきました。実写5タスクの総合力は gemma4:26b が5/5で最も高く、qwen3-vl:2bは2Bで健闘(4/5)も複雑な看板OCRは苦手でした。
小型VLMはVRAMが少なくて済みますか?
必ずしもそうではありません。qwen3-vl:2bでも画像エンコーダと64K文脈込みで約9.5GB使いました。同サイズのテキストLLMより大きめで、「小型VLM=省VRAM」ではない点に注意です。
moondreamは使えませんか?
英語では動作するモデルですが、当サイトの日本語タスク(OCR・数える・読解)では空回答や中国語化で0/8でした。日本語で使うなら qwen3-vl 系や Gemma 系が現実的です。
どのローカルVLMを選べばいいですか?
実写まで含めた総合力なら gemma4:26b(傾いた看板の日本語OCRまで完璧・約122 tok/s)。軽いタスクで速度を最優先なら qwen3-vl:2b(2Bで健闘・約268 tok/s、ただし複雑OCRは苦手)が目安です。手元で載るかは動くか診断、必要VRAMは早見表で確認できます。
この実測はどこまで信頼できますか?
今回は正解が既知の合成画像に加え、Wikimedia Commonsの実写4枚(5タスク)でも追試済みです。合成は易しく全員満点でしたが、実写では差がつき、言語ドリフトや複雑OCRのタイムアウトも観測しました。実写は小サンプルで、手書き野帳など現場に近い写真での検証は今後の課題です。数値は版・条件で変動します。

精度等について

  • 合成タスクは易しめ、実写・ドメイン編はネット公開画像4枚の小サンプルです。実際のドメイン写真(測量現場・手書き野帳等)や枚数を増やすと結果は変わり得ます。
  • 実写では言語ドリフト(qwen3-vl:8bが中国語化)や密なOCRのタイムアウト(qwen3-vl:2b)が出ました。用途が日本語OCR中心なら、実写で検証してから選ぶのが安全です。
  • moondream は英語では動作するモデルで、本結果は「日本語での実用」に限った評価です。
  • VRAMはollama既定の64K文脈込みの実測値(moondreamのみ2K文脈)で、文脈長・量子化で増減します。qwen3-vl:32b は今回未計測です。数値は版・条件で変動します。