【要約】日本語OCRモデルSarashina2.2-OCRをMLXへ移植する。モデルカードだけでは分からない実装を追った記録 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がApple Silicon環境でOCRと判定LLMを効率的に動かそうとした際、メモリ管理と実装の複雑さに直面した。既存のtransformers/CUDA構成では、Apple Silicon単体でのリソース最適化が困難であった。具体的には以下の課題が発生した。
- ・mlx-vlmに未収録の独自アーキテクチャ（spatial_reset M-RoPE等）の実装困難さ。
- ・transformers v5の厳格な型検証による、モデルconfigの読み込みエラー。
- ・量子化や演算精度の差により、テキストの完全一致では移植の正当性を判定できない問題。
// Approach
開発者は、モデルの実行時構造をコードレベルで解析し、既存のmlx-vlm実装を拡張する手法を採用した。モデルカードの抽象的な説明ではなく、config.jsonとmodelingファイルを読み解くことで、真の構成を特定した。
- ・Qwen2-VL系ViTとQwen3-VL系deepstackを組み合わせたハイブリッド構成の再現。
- ・PretrainedConfigを継承したパッチ版configによる、型制約の回避。
- ・numpyを用いたspatial_reset M-RoPEの位置ID計算ロジックの移植。
- ・「NG語の生存率」や「商品名の保持」といった、業務上の決定論的な指標による等価性検証。
// Result
開発者は、Apple Silicon環境での実用的なOCR推論環境を構築した。これにより、メモリ制約の厳しいローカル環境でも、高精度なOCRと大規模な判定LLMの共存が可能となった。
- ・4bit量子化モデル（2.8GB）を公開し、M4 Maxで画像1枚あたり平均2.8秒の速度を実現。
- ・決定論的な業務指標において、基準となるbf16モデルと同等の精度を維持。
- ・OCRと判定LLMを同一デバイス上で動かすための、十分なメモリ余地を確保。
Senior Engineer Insight
> モデルカードの記述を鵜呑みにせず、実装コードから真の構造を読み解く姿勢は、高度な移植作業において不可欠である。特に、等価性検証において「完全一致」という指標の罠を回避し、業務的な決定論的指標を採用した点は、実戦的な判断として高く評価できる。メモリ制約の厳しいエッジ環境において、量子化モデルの品質をどう担保するかという問いへの、一つの解を示している。