ドキュメントタスクにおける Gemma 4 E4B vs Qwen3.5-4B：Qwenがベンチマークを制すが、副スコアは別の物語を語る

結果はこちらです： https://www.idp-leaderboard.org/

両方をIDP Leaderboard（OlmOCR Bench、OmniDocBench、IDP Core）で実行しましたが、見出しの数字は面白い部分ではありません。

トップラインのスコア：

ベンチマーク	Gemma 4 E4B	Qwen3.5-4B
OlmOCR	47.0	75.4
OmniDoc	59.7	67.6
IDP Core	55.0	74.5

Qwenが3つすべてで勝っています。OlmOCRでは差が28ポイント。はい決まり、って感じですよね？

でも、そう簡単ではありません。IDP Coreを掘り下げます：

サブタスク	Gemma 4 E4B	Qwen3.5-4B
OCR（生のテキスト認識）	74.0	64.7
KIE（構造化抽出）	11.1	86.0
Table	55.0	76.7
VQA	65.3	72.4

Gemmaは文書からのテキスト読み取りがQwenより得意です。ただし、読み取った内容を使って構造化されたものを何かしら行うことはできません。KIEの崩れ（11.1 vs 86.0）は視覚の失敗というより、スキーマで定義された出力に対する指示追従の失敗です（少なくとも私はそう推測しています）。

OlmOCRでも同じ傾向です。GemmaはH&F（手書き/図表）で48.4を取っていますが、Qwenは47.2でほぼ同点です。とはいえ最も難しい視覚サブセットでは。けれどMulti-Colは37.1 vs 79.2です。マルチカラムのレイアウトには、ピクセルレベルの読み取りだけでなく、構成的な空間推論が必要です。

Gemmaファミリー内で見ると、E2B（2.3B相当）からE4B（4.5B相当）へのギャップは大きいです。OlmOCRは38.2 → 47.0、OmniDocは43.3 → 59.7。小さいバリアントを検討しているなら、知っておく価値があります。

実務上の要点：

エンドツーエンドの抽出パイプラインを回しているなら、このサイズではQwen3.5-4Bのほうがまだ良い選択です。ただし、別のモデルに渡す前に文書を前処理していて、構造化出力よりも生のテキストの忠実性を重視するなら、Gemmaの知覚（perception）の品質は過小評価されています。

Gemmaは手書き認識の点では実際にもっと良いかもしれません。というのも、OCRタスクがそれに似ているからです（例：このベンチマークのOCRタスクの1つを確認してみてください： https://www.idp-leaderboard.org/explore/?model=Nanonets+OCR2%2B&benchmark=idp&task=OCR&sample=ocr\_handwriting\_3)

そして最後に、GemmaはVQAベンチマークにおいてQwenに匹敵する推論のパワーハウスだと感じました。

もう一つのGemmaの観点：E2BとE4Bには、音声入力がモデルの重みにネイティブに組み込まれています。別パイプラインは不要です。エッジで音声＋文書のワークフローを作っている人にとって、このサイズ帯では他にそういうものはありません。

今のところの本当にある問題：26BのMoEバリアントは、5060 Ti 16GBでQwen 35B-A3Bの60+ tok/sに対して約11 tok/sです。同じハードです。ルーティングのオーバーヘッドは現実的にあります。Dense 31Bはより予測可能です（デュアルのコンシューマGPUで約18〜25 tok/s）。ただ、MoEの速度差は無視しにくいです。

実際の文書ワークロードでこれらを動かしている人はいますか？構造化プロンプトでKIEのギャップが埋まるのか、それとももっと本質的なものなのか気になります。