mlx-vlmでGemma 4を動かしてわかったこと — Vision OCRの限界とハイブリッド戦略

前回の記事では mlx-lm でGemma 4を動かし、OpenClawとの組み合わせで64GBメモリの限界を確認した。今回はその続きで、mlx-vlm（Vision Language Model対応版） を使ってGemma 4のマルチモーダル能力をテストした結果をまとめる。

結論から言うと、テキスト処理は実用レベルだが、画像認識（Vision OCR）は4bit量子化では全く使い物にならなかった。 そこから導き出したのが、テキストはローカルLLM、PDF/画像はClaudeに任せる「ハイブリッド戦略」だ。

---

mlx-lmとmlx-vlmは別物

まず前提の整理。この2つは別パッケージだ。

パッケージ	用途	Vision
mlx-lm	テキストのみのLLM	非対応
mlx-vlm	マルチモーダルモデル（画像+テキスト）	対応

Gemma 4はマルチモーダルモデルなので、画像を扱いたいなら mlx-vlm が必要。v0.4.3でGemma 4のDay-0サポートが入っている。

サーバーの起動方法はほぼ同じ。

# mlx-vlm のインストール
pip install -U mlx-vlm

# サーバー起動
mlx_vlm.server \
  --model mlx-community/gemma-4-31b-it-4bit \
  --port 11434 \
  --max-kv-size 8192

APIもOpenAI互換（POST /v1/chat/completions）なので、クライアント側の変更は不要。

---

テキスト処理: Gemma 4 31B Denseは優秀

まずテキスト処理の結果から。Markdownドキュメントの要約・タグ付けをGemma 4 31B 4bitに投げてみた。

テスト内容: 日本語のMarkdownファイル（お出かけスポットリスト）を渡して、要約・タグ生成を依頼。

結果:

{
  "summary": "横浜市周辺で、5歳と8歳のお子様と一緒に雨の日でも楽しめる屋内施設をまとめたリストです。",
  "tags": ["横浜市", "子連れお出かけ", "雨の日", "屋内施設", "神奈川県"]
}

• 要約は日本語で自然
• タグも日本語で的確
• 生成速度: 24.7 tok/s
• メモリ: 19.2 GB

26B A4B（MoE版）だと英語タグになりがちだったが、31B Denseは日本語の品質が明らかに上。速度は1/4に落ちるが、非同期バッチ処理なら問題にならない。

テキスト処理に関しては、Gemma 4 31B Dense 4bitは実用レベル。

---

Vision OCR: 4bit量子化では壊滅的

ここからが本題。PDFや画像からテキストを抽出するVision OCR能力をテストした。

テスト1: 出産準備品リスト（テキストベースPDF）

PDFを画像化して、mlx-vlm Vision APIに送信。

結果:

{
  "summary": "この文書は、様々なキャラクターやアニメに関連するキーワードがリストアップされた...",
  "text_content": "• ˙\n• ˙\n• ˙\n（数百行の繰り返し）"
}

完全に誤認識。 出産準備品リストを「アニメキャラクターのキーワードリスト」と判定。テキスト抽出は • ˙ の繰り返し。日本語を一文字も読めていない。

テスト2: 学校の成績表（手書き含むスキャンPDF）

結果:

{
  "summary": "The image contains a collection of fragmented text elements...",
  "text_content": "EMMA is a sweet girl who loves to play with her friends.（同じ文を70回以上繰り返し）"
}

一部の英語テキストは認識したが、同じ文を延々とリピートするだけで、テーブルの評価データは全く抽出できず。

テスト3: 自動車保険の契約書（日本語PDF）

結果:

{
  "summary": "The provided image is a collection of various common legal, insurance, and contractual phrases...",
  "text_content": "(about own duty)（同じフレーズを数百回繰り返し）"
}

31B Denseでも26B A4Bと同じ症状。4bit量子化するとVision能力が根本的に劣化する。

比較: 同じPDFをClaude -pで処理

同じ成績表PDFをClaude -pに渡した結果:

# Green Valley International School
## Student Report Card
- **Student**: Yuki Tanaka
- **Class**: Kindergarten

## Evaluation
### Math
| Skill | Term 1 | Term 2 |
|---|---|---|
| Counts forward to 10 | G | O |
| Recognises different shapes | G | VG |
...

全テーブルが正確にMarkdownに変換され、手書きコメントも完全に読み取れた。処理時間48秒。

---

なぜ4bit量子化でVisionが壊れるのか

推測だが、Vision Encoderの重みが量子化に対して特に脆弱なのだと思う。テキスト処理（Language Model部分）は4bitでもそこそこ保たれるが、画像認識（Vision Encoder → Projection → LM）の経路は精度の劣化が致命的になる。

8bit版なら改善する可能性はあるが、31B 8bitだとメモリが約34GBで、64GBマシンではKVキャッシュとの兼ね合いがタイトになる。

---

ハイブリッド戦略: テキストはローカル、画像はClaude

ここから導き出したのが、ファイルタイプでAIバックエンドを切り替える「ハイブリッド戦略」だ。

ファイルタイプ	処理先	理由
テキスト / Markdown	Gemma 4 31B（ローカル）	高品質・高速・無料
PDF / 画像 / ドキュメント	Claude -p	Vision OCR能力が圧倒的
動画 / 音声	メタデータのみ	AI処理なし

この戦略のポイント:

1. テキスト処理はローカルで十分。 Gemma 4 31Bの日本語品質は実用レベルで、API課金が不要
2. PDF/画像はClaudeに任せる。 4bit量子化のVision OCRは使い物にならない。Claudeのサブスク内で処理する方が確実
3. 切り替えは自動。 ファイルタイプで判定するだけなので、ユーザーが意識する必要がない

---

PDF処理の実践: pdftotext + LLM vs Vision vs Claude

PDFの処理方法も3パターンテストした。

方式	速度	品質	コスト
pdftotext + Gemma 4	8秒	実用十分	無料
Gemma 4 Vision	41秒	使えない	無料
Claude -p	36秒	最高	サブスク内

テキスト埋め込みPDFなら pdftotext で抽出してからGemma 4に投げるのが最速・最安。ただし テーブル構造が崩れる 問題がある。

スキャンPDFやテーブルが重要な文書はClaude -pが圧倒的。テーブルをMarkdown形式で正確に変換してくれる。

---

メモリ使用量

64GBのMac Studioでの実測値。

コンポーネント	メモリ
Gemma 4 31B 4bit	19.2 GB
Gemma 4 26B A4B 4bit	16.5 GB
Atlas API + Watchdog	ごく少量
macOS + その他	約10 GB

31B 4bitでもメモリに余裕がある。前回のOpenClaw + 8bitモデルで45GB超に膨らんだのとは大違い。用途をテキスト処理に絞れば、64GBで十分に実用的。

---

まとめ

発見	詳細
mlx-vlmはmlx-lmの上位互換	Vision対応。サーバーAPIは同じ
テキスト処理は実用レベル	31B Dense 4bitは日本語品質が良い
Vision OCRは4bitでは壊滅	同じ文のリピート、日本語読めない
ハイブリッド戦略が最適解	テキスト→ローカル、画像→Claude
64GBで十分に運用可能	用途を絞ればメモリに余裕がある

前回は「64GBでは重いエージェントには足りない」という結論だったが、今回の発見は**「用途を正しく切り分ければ64GBでも十分に実用的」**ということだ。全部をローカルでやろうとせず、得意分野で分担させる。これが現時点でのベストプラクティスだと思う。

---

使った環境

• マシン: Mac Studio M4 Max 64GB
• MLXサーバー: mlx-vlm v0.4.3
• モデル: mlx-community/gemma-4-31b-it-4bit / gemma-4-26b-a4b-it-4bit
• テキストLLM: Claude -p（サブスク内）