多言語OCRベンチマーク：精度はHunyuanとQwen、スループットはPaddleがリード

モデルと参照資料：

• PaddleOCR PP-OCRv5 — 選択した言語認識器に応じて有効パラメータ数310万〜530万。ポリゴンと信頼度を返すモバイル向け検出・認識OCR。
• EasyOCR — 言語リーダーに応じて有効パラメータ数2,460万〜7,460万。CRAFT検出とPyTorch認識により領域と信頼度を返す。
• docTR — 評価した事前学習済みpredictorは2,640万パラメータ。構造化領域と信頼度を返す2段階PyTorch文書OCR。
• GLM-OCR — 13.3億パラメータ。プレーンテキストとMarkdown抽出のため、Transformers生成で評価した視覚言語OCR。
• Granite Docling 258M — 2億5,750万パラメータ。レイアウト位置を含むDocTagsを生成する小型Transformers文書変換モデル。
• HunyuanOCR — 11.2億パラメータ。テキストスポッティング、文書解析、意味的文書タスクを扱うOCR専用の視覚言語生成モデル。
• Qwen3-VL-8B-Instruct — 87.7億パラメータ。多言語OCRとMarkdown抽出に用いた汎用視覚言語生成モデル。
• Surya OCR 2 — 6億8,620万パラメータ。領域座標付きのテキストまたはHTMLを生成するレイアウト対応Transformersモデル。

数値はダウンロードサイズではなく、評価時に有効だったチェックポイントの重みを表します。従来型OCRの合計は、そのページで読み込んだ検出器と言語別認識器の組み合わせです。生成モデルは公開チェックポイントのテンソル数を使用しています。

概要

同一の900ページで8つのオープンOCRシステムを評価しました。データは5言語、6種類の画像で構成され、各「言語×画像種類」のセルに30ページあります。すべてのシステムを1台のNVIDIA RTX PRO 6000 Blackwell Max-Q GPU上で実行し、CPUへのフォールバックを厳格に禁止しました。

すべての条件で勝つモデルはありません。HunyuanOCRは平均文字誤り率（CER）0.1637で観測上の最小値を記録し、QwenOCRも0.1651で実質的に並びました。PaddleOCRは、0.145秒のウォーム推論p50、実測268 wall pages/min、ポリゴンと信頼度という、低レイテンシかつ座標付きの最も強い構成を示しました。

精度上位の差は、このサンプルでは統計的に決定的ではありません。一方、導入コストと出力仕様の差は明確です。HunyuanのピークVRAMは96,358 MiB、Qwenは21,010 MiBでしたが、Paddleは4 GiB未満で有用な座標情報を返しました。そのため、単一の総合スコアで勝者を作るのではなく、精度、レイテンシ、リソース、出力切り捨て、出力機能を分けて報告します。

評価方法

本ベンチマークは均衡したページグリッドを使い、テキスト精度と運用指標を分けて測定します。

ページセット

ソースの内訳は、制御レンダリング548ページ、制御劣化50ページ、MDPBench由来の公開実データ195ページ、Wikimedia Commonsのライセンス付きWeb実データ107ページです。900ページすべてを運用指標に使用しました。テキスト精度は独立した正解テキストを持つページだけで算出し、評価対象モデルの出力を正解として再利用することはありません。

推論プロンプトセット

検出・認識型システムは自然言語の指示を受け取らないため、PaddleOCR、EasyOCR、docTRには画像と言語設定済みのリーダーを入力しました。生成型システムには「要約せず、見える文字をすべて読順どおりに転記する」という同じ目的を与えつつ、各モデル固有の出力形式を使用しました。

実行条件

• システムごとにロックされた1つのuv環境と固定されたモデルリビジョンを使用。
• 各モデル固有のCUDA経路で推論。PaddleOCRはPaddlePaddle GPU経由のPaddleOCR.predict()、EasyOCRはEasyOCR.Reader.readtext()、docTRはPyTorch経由のocr_predictor()、GLM-OCR、Granite Docling、HunyuanOCR、QwenOCR、Surya OCR 2はHugging Face Transformers経由の自己回帰generate()を使用。
• 固定したPython MLスタックは、PaddleOCR 3.6.0とPaddlePaddle GPU 3.3.1、EasyOCR 1.7.2、python-doctr 1.0.1、Surya OCR 0.21.1、PyTorch 2.11.0とtorchvision 0.26.0、Transformers 5.10.2〜5.12.1（およびHunyuan互換の固定リビジョン）、Accelerate 1.13.0〜1.14.0、Pillow 10.4.0〜12.2.0。
• 1回の実行につき1つの永続プロセスを使用。モデル読み込みは1回だけ記録し、ウォーム推論のパーセンタイルから除外。
• バッチ処理や並列処理を行わない、1ページずつの逐次推論。
• CUDAを必須とし、CPUへの自動フォールバックを禁止。
• 生成デコードは決定的に実行し、新規トークンを1,024に制限。EOSトークンなしで上限に達した場合は切り捨てとして計上。
• GPUとプロセスのリソースを各ページの前後でサンプリング。

指標

• 完了と切り捨て： 成功ページ、失敗、タイムアウト、生成上限に達した出力。↑ 完了 ↓ 失敗・切り捨て
• CER： Unicode NFKCおよび言語別の正規化後に、文字編集距離を正解文字列長で割った値。↓ 低いほど良い
• NormEDとテキスト類似度： 予測と正解の長い方で割った編集距離と、その1 − NormEDで表す類似度。↓ NormED ↑ 類似度
• レイテンシ： コールドロード、ウォーム推論p50/p95、エンドツーエンドp50/p95。↓ 低いほど良い
• スループット： 実測したページ単位のオーケストレーション負荷を含む、成功ページのwall pages/min。↑ 高いほど良い
• リソース： ピークVRAM、プロセスツリーRAM、GPU使用率とボード消費電力の平均・ピーク。↓ ピークメモリ
• エネルギー： プロセス開始前のアイドルサンプルを差し引いた、ページ当たりのアクティブGPUボードWh。↓ 低いほど良い
• 出力仕様： プレーンテキスト、Markdown・HTML・DocTags、ボックス、信頼度、オーバーレイ、出力された読順。
• 公式構造指標： ソース忠実な195ページのサブセットにおけるMDPBenchのテキスト編集距離、数式CDM、表TEDS、読順編集距離。↓ テキスト・読順の編集距離 ↑ CDM・TEDS

結果

まず全体の精度と速度のトレードオフを示し、続いて言語、画像種類、ドメインシフト、切り捨て、公式構造スコア、GPUコストの順に結果を見ます。CERが低くても、低レイテンシ、座標付き出力、文書構造の信頼性が同時に得られるとは限らないため、これらの軸は分けて扱います。

全体の精度、完了率、速度

最初の図は、ページ単位の平均CERとウォーム推論p50を並べたものです。左下ほど望ましい結果です。続く表では、2軸の図だけでは示せない完了数、正規化編集距離、生成上限への到達数を補います。

CERは、ページごとに文字編集距離を正解文字列長で割った値の平均です。挿入文字数が正解文字数を上回るページでは1.0を超えることがあります。正規化編集距離（NormED）は予測と正解の長い方で割るため、0から1の範囲に収まります。

docTRは、速度だけで判断できない理由を示しています。標準の認識器は非常に高速でしたが、語彙がラテン文字向けであり、CJK文字やデーヴァナーガリー文字の大部分を表現できませんでした。

言語別精度

この分割では、言語と文字体系が変わっても全体順位が維持されるかを確認します。各言語は6種類すべての画像にまたがる180ページを集計しています。

Hunyuanは英語（0.1457）、韓国語（0.0889）、ヒンディー語（0.2264）で観測上最小のCERを記録しました。日本語はQwen（0.1425）、中国語はGLM（0.1264）が首位でした。ただし、上位モデルと2位モデルをペア比較した95%ブートストラップ区間は、すべてゼロをまたいでいます。したがって、これらは方向性を示す首位です。

モデルサイズと同じくらい設定が重要です。PaddleとEasyOCRは言語別にリーダーを切り替えましたが、評価したdocTRチェックポイントはラテン文字向けでした。Hunyuanは130以上の言語での学習を報告し、Qwen3-VLは広範な多言語文書の事前学習を報告しています。GLMの公開多言語評価にはヒンディー語が記載されておらず、今回の実行ではヒンディー語180ページ中136ページが上限に達しました。

画像種類別精度

言語構成を一定に保ち、文書形式ごとにページをまとめた結果です。各カテゴリは150ページで、きれいな文字認識と、レイアウト、手書き、スクリーンショット、劣化画像への対応を分けて確認できます。

単純な印刷文書はPaddle（0.1650）、複雑なレイアウト（0.2716）、表・フォーム（0.1650）、制御された手書き（0.0095）はHunyuanが首位でした。スクリーンショット・UI（0.0423）とカメラ撮影・劣化画像（0.3014）はQwenが首位でした。複雑なレイアウトと劣化画像ではHunyuanとQwenがほぼ並び、6カテゴリすべてで上位モデルと2位モデルのブートストラップ区間がゼロをまたぎました。

アーキテクチャの違いが参考になります。従来型の検出・認識OCRは、きれいにローカライズされた文字で強く、ページ全体を見るVLMの文脈はレイアウトとシリアライズに役立ちます。手書き結果は制御データの比率が高いため、複数の書き手による自然な手書き全般へ一般化すべきではありません。

制御データと実データのドメインシフト

ベンチマークの楽観性を可視化するため、制御レンダリングページと、MDPBench由来の公開実データを比較します。両群は対応する同一ページではなくソース別に層化されているため、この図は因果的な劣化量ではなく、導入時に関係するドメイン差を測ります。

195ページのMDPBench由来の公開実データでは、すべてのシステムが大幅に悪化しました。HunyuanはCER 0.057から0.477、Qwenは0.051から0.523、GLMは0.141から0.519、Paddleは0.152から0.587へ上昇しました。これは対応ページを使った実験ではなくソース別の比較ですが、レンダリングページが実運用精度を過大評価することを明確に示しています。

トークン上限の影響

生成型OCRでは、1,024トークンの上限に達した応答が、ページ全体ではなく途中までの転記である可能性があります。この図は完了した出力と上限到達出力を分け、集計CERの中に隠れがちなデコード上限の影響を示します。

生成型システムは決定的デコードで実行しました。すべてのモデルで、上限到達ページのCERは完了ページより約0.40高くなりました。Suryaは507ページ、Graniteは468ページで上限に達しており、順位を確定するには公式の高上限再実行が必要です。Qwenは222ページ、Hunyuanは184ページ、GLMは263ページで上限に達しました。

実ページと推論結果

以下はMDPBench由来のページocr900v2_en_tables_forms_10です。画像をクリックするとフル解像度で確認できます。

元ページ

PaddleOCRの座標オーバーレイ

赤い領域はPaddleOCRの推論JSONから直接生成したもので、手作業で再作成していません。

Paddleは有用な座標を検出しましたが、表を一列の読順に平坦化したためセル同士の関係が失われました。生成モデルは表構造をより忠実に再構成しましたが、信頼度や座標付き領域は出力しませんでした。プレーンCERと文書構造は別の指標として扱う必要があります。

MDPBench公式評価器によるクロスチェック

MDPBench由来の195ページを、固定した公式評価器に入力しました。これはサブセットの結果であり、リーダーボードへの提出結果ではありません。表見出しの矢印は各公式指標の望ましい方向を示します。

このサブセットでは、Hunyuanがテキスト編集距離、表TEDS、読順で首位、GLMが数式CDMで首位でした。Qwenはテキストと表でHunyuanに近い結果でした。

レイテンシとスループット

この図は、OCR精度とは独立して運用速度を比較します。推論パーセンタイルは1回だけのモデル読み込みを除外し、wall throughputは逐次実行で測定したページ単位のエンドツーエンド負荷を含みます。塗りつぶし点がp50、輪郭点がp95で、すべての値を各マークの横に記載しています。

メモリとGPUボードエネルギー

ピークVRAMは対象GPUにモデルが収まるかを決め、アクティブエネルギーは推論中のページ当たりGPUボード処理量を示します。これらは1ページずつ・バッチなしの構成で得た値であり、データセンター全体の消費電力として解釈すべきではありません。

エネルギーは、各推論区間でサンプリングしたGPUボード電力を台形積分して算出しました。コールドロード、CPUとホストの電力、冷却、バッチ処理の効果は含まず、コンセントで測ったコストではありません。

出力仕様

精度指標は転記結果を評価しますが、本番システムでは表示方法や元ページへの対応付けも重要です。この機能マトリクスは、評価したモデル経路におけるプレーンテキスト・構造化テキストと、座標・信頼度の出力を区別します。

テキストのみを取り込むRAGと、クリックした箇所を強調表示する文書ビューアでは、CERが同じでも最適なモデルは異なります。座標と信頼度は、二次的な表示機能ではなく、本番導入の主要要件です。

導入時の解釈

• 座標と信頼度を備えた高速多言語テキスト： 評価した中ではPaddleOCRが最も強いベースラインです。p50は0.145秒、wall pages/minは268、VRAMは小さく、CERは0.2509でした。
• 観測上最小のプレーンテキスト誤り： HunyuanOCRとQwenOCRが最上位層です。平均CERはHunyuanが低く、NormEDとスクリーンショット・劣化画像の観測結果はQwenが強い結果でした。
• 小型の生成OCR： GLM-OCRはピークVRAM 6.4 GiBでCER 0.2299、中国語では観測上最良でしたが、評価したベースモデル経路ではボックスを返しません。
• 構造化HTML OCR： SuryaOCRは、期待される出力長に生成予算を合わせるまで、代表CERだけで評価できません。
• 最高速度： docTRは対象文字体系に対応する認識器を設定した場合にのみ有力です。今回の標準チェックポイントは5言語対応ではありません。

実運用では、最初に座標付きPaddleOCRを実行し、信頼度、言語、レイアウト、表の信号から行単位OCRでは不十分と判断したページだけをページ単位VLMへ送るカスケード構成が考えられます。

制約

1. データセットの66.4%は制御コンテンツであり、すべてのシステムが公開実データで悪化しました。
2. 独立した正解テキストがないページはランタイム指標に含めますが、テキスト精度には含めません。
3. 各「言語×画像種類」セル30ページで大きな効果は確認できますが、小さな順位差を証明することはできません。
4. 1,024トークン上限はSuryaとGraniteに特に不利です。
5. CERは構造や座標を完全には評価せず、ランタイム測定は1台のGPUでの1ページ逐次推論に限られます。

次の研究方向

結論

本ベンチマークは、単一のOCRスコアでは隠れる3つの導入上の選択を分けて示しました。

PaddleOCRは、低レイテンシで座標を返す最も強いベースラインです。HunyuanOCRとQwenOCRは、ページ全体の推論が重要な条件で観測上最小のテキスト誤りを示しますが、計算量とメモリのコストは大幅に高くなります。GLM-OCRは、特に中国語で強い小型の生成モデルです。Surya、Granite、docTRは、現在の行を最終的な能力順位として読む前に、生成上限、語彙、パイプライン設定を修正する必要があります。

中心的な結果は、1つのシステムがすべてのページで勝つというものではありません。言語、文書構造、出力仕様、GPU予算によって最適なモデルは変わり、制御環境のOCR精度は公開実データでの評価の代わりにはなりません。

評価用リファレンス

• MDPBenchデータセット