Article
mlx-vlm v0.4.4でGemma 4のVision OCRが復活した, 壊れていたのは4bitではなくバグだった
数日前に書いた前回の記事では, mlx-vlm でGemma 4を動かした結果として, 4bit量子化ではVision OCRが壊滅的 という結論を書いた。
結論から言うと, あれは間違っていた。悪かったのはGemma 4でも4bit量子化でもなく, mlx-vlm v0.4.3 側のバグ だった。
v0.4.4 系に上げて再検証したら, レシートの文字読み取り, 時間割のMarkdown変換, PDF文書の書き起こしまで普通にこなせるようになった。しかもメモリ使用量まで減った。これはかなりでかい。
何が起きていたのか
前回の検証では, コンビニのレシート画像を送っただけなのに, こんな感じの返答が返ってきた。
「インターネット上のミームやジョーク, あるいはエンジニア的な遊び心が含まれた, 非常に特殊な構成の画像です」
いや, ただのレシートだ。
数字や商品名をまったく読めず, 画像全体を「ITジョークのコラージュ作品」みたいに解釈していたので, その時点では「4bitにするとVision Encoderが死ぬのか」と思い込んでいた。
でもGitHubのissueを追うと, 原因はかなりはっきりしていた。
v0.4.3で報告されていたバグ
調べた範囲では, 少なくとも次の不具合がVision品質に直撃していた。
| Issue | 内容 | 影響 |
|---|---|---|
| #906 | Vision特徴量が embed_scale で過大スケーリング |
OCR品質が壊れる |
| #906 | MultimodalEmbedder のnorm順序が不正 |
Vision品質が劣化 |
| #906 | VisionPooler のパディング処理不備 |
プーリング結果が崩れる |
| #912 | sanitize() がweightキーを二重変換 |
量子化モデルの重みが壊れる |
| #943 | 画像パス処理の不具合 | Vision出力が不安定になる |
特に #906 はかなり致命的で, Vision特徴量がまともに渡っていなければ, OCRどころか画像理解全体が崩れても不思議じゃない。
最初は processor_config.json の 224x224 を見て「画像が小さく潰されているのでは」とも疑ったけれど, これは実際には使われていないフォールバック値だった。犯人は別にいたわけだ。
アップデート方法
PyPI版の反映タイミング次第で修正が揃わないことがあるので, 確実に試すならGitHubのmainから入れるのが早い。
pip install git+https://github.com/Blaizzy/mlx-vlm.git
サーバーを再起動すれば反映される。モデルの再ダウンロードは不要だった。
再テストした結果
1. コンビニのレシート
4032x3024のiPhone写真をJPEGに変換して投入。
v0.4.3 では意味不明なミーム解釈だったのに対して, v0.4.4系 では次のような情報をちゃんと拾えた。
- 店名
- 日時
- 合計金額
- 税額
- 商品名の一覧
細かい誤読は少しある。でも「読めない」ではなく「実用になる」側に明確に移った。
2. 小学校の時間割画像
英語と日本語が混ざった時間割表も試した。
結果はかなり良くて, ほぼそのままMarkdownテーブルとして整理できた。こういう構造を保ったまま取りたい文書で使えるのは大きい。
3. 学校の通知PDF
1ページの日本語PDFをJPEG化して入力すると, 見出し, 箇条書き, 表形式の情報までかなりきれいに抽出できた。
つまり少なくとも, 次のあたりはローカル処理でも十分狙える。
- レシート
- 時間割
- 簡単な通知文書
- 1ページ程度のPDF画像化データ
パフォーマンスも良くなった
手元の計測では, 速度はほぼ据え置きか微増だった一方で, prefillとメモリ使用量がかなり改善した。
| 指標 | v0.4.3 | v0.4.4系 | 変化 |
|---|---|---|---|
| Vision品質 | 壊滅 | 実用レベル | 大幅改善 |
| 生成速度 | 24.7 tok/s | 24.3-24.5 tok/s | ほぼ同じ |
| Prefill速度 | 142.7 tok/s | 185.4 tok/s | 約30%改善 |
| ピークメモリ | 33.4 GB | 19.5 GB | 約42%削減 |
33GB台から19GB台に落ちたのはかなりうれしい。64GBマシンなら, ほかの常駐プロセスやエージェントを抱えながらでもだいぶ扱いやすくなる。
前回のハイブリッド戦略は修正が必要
前回の記事では, 「テキストはローカル, 画像はClaude」というハイブリッド戦略を推していた。
その考え方自体はまだ有効だけれど, ローカルで処理できる範囲 は明らかに広がった。
前回の判断
| ファイルタイプ | 処理先 |
|---|---|
| テキスト / Markdown | Gemma 4 |
| PDF / 画像 | Claude |
今回の修正版
| ファイルタイプ | 処理先 |
|---|---|
| テキスト / Markdown | Gemma 4 |
| 画像（レシート, 時間割など） | Gemma 4 |
| 簡単なPDF | Gemma 4 |
| 複雑なPDF, 手書き混在, テーブル大量 | Claude |
要するに, 全部Claude送りにする必要はもうない。
この差は地味に大きい。日常の事務処理や家庭内ドキュメント整理みたいな用途なら, ローカルだけで完結できる場面がかなり増える。
ただしコンテキスト肥大化にはまだ注意
mlx-vlm 自体のバグは直ったけれど, OpenClawのようなエージェント経由で使うと, 今度はコンテキスト長の固定オーバーヘッド が効いてくる。
実際には会話履歴よりも, システムプロンプトやツール定義, 常時読み込むMarkdown群のほうが重いケースがあった。
この環境では, 常時ロードするファイル群を整理して約45KBから13KBまで圧縮した。こういう地味な整理のほうが, 体感性能には効くことも多い。
モデルの性能を疑う前に, 周辺レイヤーを疑ったほうがいい。今回まさにそれだった。
まとめ
今回の結論はかなりシンプルだ。
- Gemma 4のVision OCRが壊れていたわけではない
- 4bit量子化が本質的にダメだったわけでもない
mlx-vlm v0.4.3のバグが主犯だったv0.4.4系では, ローカルVision OCRはちゃんと実用になる
前回の記事を読んで「Gemma 4のVisionは厳しいのか」と思った人がいたら, そこは訂正したい。
ローカルLLMの品質が変なとき, まず疑うべきはモデルの限界ではなく, まわりの実装かもしれない。 たった1行のアップデートで景色が変わること, ほんとにある。
検証環境
- マシン: Mac Studio M4 Max 64GB
- MLXサーバー:
mlx-vlm v0.4.4系（GitHub main） - モデル:
mlx-community/gemma-4-31b-it-4bit - エージェント: OpenClaw v2026.4.5
