ステータス：実測（2026-10-29から10-30、24GBのコンシューマー向けGPU1枚）。 数値はいずれも直接測定した生データ（ページごとの出力原文、測定ログ、採点スクリプト）から取得しました。論文の数値は原文を開いて確認した表・節の番号とともに記載し、測定できなかったものは「未実測」、原文から見つからなかったものは「未確認」と表記します。インストールで経験したこととセキュリティに関するメモは 第2部にまとめています。
目次
- 1. 何をなぜ測定したのか
- 2. 3つのエンジンはどのように異なって読み取るか
- 3. テスト文書と採点
- 4. 結果：精度、速度、メモリ
- 5. 実際の出力比較
- 6. なぜこれほど遅いのか、そしてこの数値で語ってはならないこと
- 7. どれを選ぶべきか
- 8. 限界
- 参考
1. 何をなぜ測定したのか
OCR（光学的文字認識）は、写真やスキャンされたページから文字を抽出する作業です。古い方式は2つの段階からなります。まずページから行のある場所を見つけ出し（検出）、見つかった行を1つずつ切り出して文字として読み取ります（認識）。最近では画像を丸ごと見てMarkdownを直接書き出す ビジョン言語モデル （VLM、画像を入力として受け取る言語モデル）が文書OCRのリーダーボードの上位を占めています。
今回選んだエンジンは3つです。3つとも同じ会社（Baidu）の系列から出ていますが、ページを読み取る方式が互いに異なります。
| エンジン | 1行 | 私たちが使用したバージョン |
|---|---|---|
| PP-OCRv5 韓国語 | 古典的な検出＋認識パイプライン。小さな専用モデルが2つ | PaddleOCR 3.7.0、検出 PP-OCRv5_server_det、認識 korean_PP-OCRv5_mobile_rec |
| PaddleOCR-VL-1.6 | レイアウトモデルがページを要素ごとに切り分け、0.9B VLMが要素ごとに読み取る | PaddleOCR 3.7.0、 PaddleOCR-VL-1.6 |
| Unlimited-OCR-2 | 画像を視覚トークンに圧縮し、3B MoEデコーダーが複数のページを一度に読み取る | baidu/Unlimited-OCR-2（2026-10-27公開）、Transformers 4.52.1 |
なぜ直接測定しなければならなかったのか。文書OCRの代表的なベンチマークに韓国語が存在しないためです。
- OmniDocBench（CVPR 2025、arXiv 2412.07626）のv1.0は981ページですが、英語290、簡体字中国語612、混合79ページとなっています（表S3）。韓国語のページはありません。 著者も「ほとんどすべてのアルゴリズムが中国語よりも英語でスコアが高い」と記述しています（§5.1）。言語によって順位が変動する可能性があるということです。
- 複数ページ文書用の MPDocBench（arXiv 2605.22100、433文書、3,246ページ）と MarathonDocBench（100文書、103ページから300ページ）も英語と中国語だけです。
- エンジンの側の根拠も薄弱です。PaddleOCR-VL 1.0の論文は 切り出された1行 単位の社内テストで韓国語の編集距離0.052を報告しており（表6a）、1.5・1.6版の論文には韓国語の評価がありません。PP-OCRv5韓国語認識モデルは公式ドキュメントに「韓国語の文字画像5,007枚で精度88.0%」とあるだけで、論文の数値はありません。Unlimited-OCRの1・2作目のレポートには「Korean」という単語が一度も登場しません。
そこで疑問は3つです。韓国語文書において3つのうちどれが最も正確か。どれほど速く、メモリはどれくらい消費するのか。そして間違えるときは どのように 間違えるのか。
2. 3つのエンジンはどのように異なって読み取るか
PP-OCRv5 韓国語はページの構造を認識していません。検出器が行のボックスを見つけ出し、認識器が行ごとに文字を出力します。出力は行のテキストを上から下に繋げたものです。PaddleOCR 3.0の技術レポート（arXiv 2507.05595、§2.1）によると、このシリーズは全体で0.07B、100MB未満です（レポートのデフォルトモデル基準であり、韓国語認識モデルのサイズは未確認です）。
PaddleOCR-VL は作業を2つに分けます（1.0の論文 arXiv 2510.14528、§2.1）。レイアウトモデル（1.5版以降はPP-DocLayoutV3）が「どこに何がどのような順序で存在しているか」を決定すると、0.9B VLM（NaViT方式の動的解像度エンコーダー＋ERNIE-4.5-0.3B）が切り出された要素1つの内容だけを読み取ります。 VLMがページ全体を一度に確認することはありません。1.6版（arXiv 2606.03264）は構造をそのまま維持し、データと事後学習のみを変更しました。モデルが間違えやすかったサンプル（チェックポイント8個と歪み16種で予測が分かれるもの、古文書・レアな文字）を選んで補強し、CPT、SFT、GRPO強化学習を順番に行いました（§3、§4）。
Unlimited-OCR-2 の骨組みはDeepSeek-OCR（arXiv 2510.18234）の「光学的圧縮」です。エンコーダー（DeepEncoder）が1024×1024の画像を256個前後の視覚トークンに16分の1に縮小し、3B MoE（Mixture of Experts、トークンごとに一部の専門家のみを使用する）デコーダーがテキストを記述します。第2作目のレポート（Hugging Face公開のPDF、p.5-7）で追加されたのが SR-SWA（Sparse Reference Sliding Window Attention）です。デコーダーが次のトークンを出力する際、すべてのページの視覚トークンをすべて参照するのではなく、そのページのブロックいくつかと言直前の出力のみを参照します。私たちが受け取った設定値で計算すると、リモート12ブロック×32 ＋ ローカル128 ＝ 512トークンとなり、モデルカードの「512 tokens」と一致します。ページが増加しても1ステップあたりの計算量が増加しないようにするための仕組みです。
2つのVLMの学習データにも興味深い繋がりがあります。Unlimited-OCR-2の疑似正解（人間の代わりに他のモデルが作成した正解）はMinerU2.5-Proと PaddleOCR-VL-1.6 から抽出しました（第2作目のレポート p.8）。今回の比較における2つのVLMは、教師と生徒の関係でもあります。
3. テスト文書と採点
正解が分かっている文書を作成した
実際のスキャン文書は、正解の文字を人間が1文字ずつ入力する必要があります。そのため、逆のアプローチを取りました。正解の文字をあらかじめ決定し、その文字を使ってページを描画しました。 本文はTT Labの技術学習ノートからハングルの比率が40%を超える段落を抽出し、A4サイズ（150dpi、1240×1754ピクセル）にApple SD Gothic Neoフォント1つで描画しました。60ページは次のように分類しました。
| バンドル | ページ | 作成方法 | 正解の文字数（正規化後） |
|---|---|---|---|
| 通常の本文 | 8 | 1段組本文、26pxの文字 | 9,833 |
| ぼやけたコピー | 8 | 通常の本文8ページにガウスぼかし → 1.5度回転 → 0.6倍に縮小 → JPEG品質35 | 9,833 |
| 韓国語の表 | 4 | ヘッダーが韓国語の6列23行の格子状の表 | 2,285 |
| 長い文書 | 40 | 異なる段落40ページ、24pxの文字 | 48,878 |
ぼやけたコピーは通常の本文と 文字が全く同じです。 そのため、同じエンジンの2つのバンドル間の差分がそのまま「画質が悪化して発生したエラー」となります。
採点：文字エラー率（CER）の2つの種類
CER（Character Error Rate）とは、正解を出力に変換するために必要な最小限の編集（文字の挿入・削除・置換）回数を、正解の文字数で割った値です。 1%であれば、100文字に1文字の割合で間違えていることを意味します。編集距離はMyers（1999）のビットマップ並列アルゴリズムによって求めました。
エンジンごとに出力の形式が異なるため、まず 正規化を行います。UnicodeのNFKCで統一し、Markdownの記号（#, *, | など）とHTMLタグ、モデルが付与する座標表現を削除し、 スペースと改行をすべて取り除きます。 空白や改行はレイアウトによって変化するため、文字の順序のみを比較します。
そして、CERを2回算出します。
- 全体CER：正規化された文字のすべて。かぎ括弧「」、中黒・、ピリオド、カンマなどの句読点が含まれます。
- 文字のみCER：ハングル・英字・数字のみを残して測定した値。
両者を分けた理由は、エンジンごとに 句読点を扱う習慣が大きく異なるためです。1つの数値にまとめると、「句読点を頻繁に脱落させるエンジン」と「ハングルを誤って読み取るエンジン」が同じスコアに見えてしまいます。検索インデックスのように文字さえ合っていればよい用途と、人間がそのまま読む文書を作成する用途では、それぞれ異なる数値を確認する必要があります。
採点の罠：座標を消去しないとCERが16%
Unlimited-OCR-2の出力には、ブロックごとに座標が付与されます。例えば次のような形式です。
<BLOCK>text[71, 96, 900, 160]<FORK>우리에게 의미는 「언젠가 휴대폰 안에서 …
最初の採点プログラムは <…> タグのみを削除し、 text[71, 96, 900, 160] を残しました。その結果、通常の本文のCERの中央値が 16.3%（ページごとに13.9%から17.5%）となりました。座標用の正規表現をもう1つ追加すると、 0.80% になりました。ぼやけたコピーは16.95% → 1.99%、表は8.38% → 0.17%となります（同じ出力、同じ正解で再計算）。20倍の差が1つの出力形式から生じたことになります。VLMの出力を採点する際は、まず出力原文の数ページを自分の目で読み、正規化ルールを整えるのが順序というものです。
4. 結果：精度、速度、メモリ
| エンジン | バンドル | ページ | 全体CER（中央値） | 全体CER（最大値） | 文字のみCER（中央値） | 秒/ページ | 最大GPUメモリ |
|---|---|---|---|---|---|---|---|
| PP-OCRv5 韓国語 | 通常の本文 | 8 | 1.52% | 2.37% | 0.33% | 0.36 | 2.27 GiB |
| ぼやけたコピー | 8 | 4.47% | 4.89% | 1.23% | 0.20 | 2.27 GiB | |
| 韓国語の表 | 4 | 0.00% | 0.00% | 0.00% | 0.30 | 2.27 GiB | |
| 長い文書（ページごと、40ページ） | 40 | 1.41% | 0.49% | 0.34 | 2.27 GiB | ||
| PaddleOCR-VL-1.6 | 通常の本文 | 8 | 0.48% | 1.71% | 0.28% | 13.81 | 5.80 GiB |
| ぼやけたコピー | 8 | 1.51% | 2.68% | 0.83% | 14.04 | 5.80 GiB | |
| 韓国語の表 | 4 | 0.00% | 0.00% | 0.00% | 8.59 | 5.90 GiB | |
| 長い文書（ページごと、40ページ） | 40 | 0.53% | 0.37% | 14.39 | 5.80 GiB | ||
| Unlimited-OCR-2 | 通常の本文 | 8 | 0.80% | 0.98% | 0.75% | 31.07 | 6.85 GiB |
| ぼやけたコピー | 8 | 1.99% | 3.25% | 1.76% | 30.91 | 6.85 GiB | |
| 韓国語の表 | 4 | 0.17% | 0.71% | 0.19% | 21.52 | 6.85 GiB | |
| 長い文書（10ページを一度に） | 10 | 2.72% | 2.01% | 38.07 | 7.59 GiB | ||
| 長い文書（20ページを一度に） | 20 | 2.59% | 2.00% | 41.21 | 8.81 GiB |
読み方。中央値はページごとに算出したCERを並べたときの中央の値であり、8ページのように偶数の場合は上側の値（5番目）を使用しました。長い文書は1つの塊として採点するため
値が1つだけです。時間は予熱用の1ページを除いて測定した平均であり、長い文書は全体時間をページ数で割りました。メモリは各フレームワークの割当機が
記録した最大値（PyTorch・Paddleの max_memory_allocated）のため、 nvidia-smi に表示される値より小さくなります。13個の束すべてで失敗したページはありませんでした。
図で注目すべき点は3つあります。
PaddleOCR-VL-1.6が4つの束すべてにおいて最も正確でした。 一般的な本文全体のCER 0.48%は、1,230文字ほどのページで6文字前後を 間違えた程度です。表はPP-OCRv5とともに4ページすべて0%でした。
句読点を除くと順位が変わります。 全体CERではUnlimited-OCR-2（0.80%）がPP-OCRv5（1.52%）よりも優れています。ところが文字数だけで見ると PP-OCRv5が0.33%、Unlimited-OCR-2が0.75%と逆転します。かすれたコピーではより顕著です。全体CERはPP-OCRv5が4.47%と3つの中で最も 悪いですが、文字のみのCERは1.23%でUnlimited-OCR-2（1.76%）よりも優れています。PP-OCRv5の誤りの大部分は 句読点であり、Unlimited-OCR-2の 誤りの大部分は 文字です。図で2点間の棒が長いほど、句読点の誤りが多いことを意味します。Unlimited-OCR-2には棒がほとんどありません。
複数ページを一度に読み取ると、Unlimited-OCR-2の誤りが約3倍に増えました。 同じ長い文書の最初の10ページを対象に比較すると、PaddleOCR-VL-1.6は 0.58%、PP-OCRv5は1.53%ですが、Unlimited-OCR-2は2.72%です（最初の10ページの数値は40ページの出力を正解の10ページの末尾に合わせて切り出して再計算したもので、40ページ全体に 同じ方法を適用すると表の0.53%・1.41%がそのまま得られます）。1ページずつ読み取る場合（一般的な本文0.80%）との違いは解像度モードに起因します。1ページの場合は タイルに分割して詳細に確認するGundamモードで、複数ページの場合はページごとに視覚トークンが273個のBaseモードで読み取ります。第5節で実際の例を確認します。
速度は桁違いです。一般的な本文1ページに対して、PP-OCRv5は0.36秒、PaddleOCR-VL-1.6は13.81秒（約38倍）、Unlimited-OCR-2は31.07秒（約 86倍）かかりました。1時間に単純換算すると1万ページ、約260ページ、約116ページです。かすれたコピーでPP-OCRv5の方が速いこと（0.20秒）は、画像が 0.6倍と小さいためです。メモリはPP-OCRv5が2.27 GiB、PaddleOCR-VL-1.6が5.80 GiB、Unlimited-OCR-2は重みだけで6.32 GiBであり、1ページで6.85 GiB、 10ページで7.59 GiB、20ページで8.81 GiBとページ数に応じて増加しました。24GBのカードであれば3つとも余裕があります。
ただし、2つのVLMの時間軸は 我々の実行方式の時間であり、モデルの限界ではありません。理由は第6節で説明します。
5. 実際の出力比較
数字の背後にある実際の出力を確認します。以下の2つの図は同じ2ページの同じ位置を示しています。上部はエンジンが受け取った画像をピクセルそのままに配置した断片であり、 下部は3つのエンジンの出力を正解の位置に合わせて配置したものです。このページは誤りのタイプが満遍なく含まれているため選定しました（一般的な本文2ページのCERは PaddleOCR-VL-1.6が0.09%、Unlimited-OCR-2が0.26%、PP-OCRv5が1.57%であり、束の中央値よりやや良好なページです）。
稀なパッチム：「쟀（ジェ）」は3つとも一度も正しく読み取れなかった
「쟀습니다（ジェソッタ／測った）」は「재다（ジェダ／測る）」の過去形であり、一般的な本文の8ページ目に7回登場します。 3つのエンジンすべてが7回とも間違えました。 クリーンな一般的な本文においても同様です。
| 「쟀」を何として読み取ったか | 一般的な本文（7回） | かすれたコピー（7回） |
|---|---|---|
| PP-OCRv5 韓国語 | 졌 7 | 괜 4、겠 3 |
| PaddleOCR-VL-1.6 | 잤 6, 챙 1 | 졌 2, 채 2, 잤 1, 짧 1, 챗 1 |
| Unlimited-OCR-2 | 잤 2, 잿 2, 썼 1, 겠 1, 잦 1 | 겠 3, 쪼 2, 켜 1, 챙 1 |
PP-OCRv5 は綺麗な画像では常に「졌」と読み取りました。認識器は定められた文字辞書の中からのみ答えを選びますが、「쟀」がその辞書にない場合、このように最も似ている文字に一貫して置き換わります（辞書に実際にないのかどうかは未確認です）。2つのVLMは答えが散らばっています。似た形の文字の中で、言語モデルがより頻繁に見かける方に傾いているように見えます。日常文書にめったに出てこないパッチム（子音字母）であるため、3つのエンジンの学習データに少なかった可能性が高いです。
似た文字は他にもあります。「힙」（「읽힙니다（読み取らせます）」、「밝힙니다（明らかにします）」、「힙 메모리（ヒップメモリ）」）は通常の本文に5回出てきますが、Unlimited-OCR-2 は5回すべて「힘（ヒム）」や「립（リプ）」と読み取り、PaddleOCR-VL-1.6 はすべて正解し、PP-OCRv5 は1回間違えました。「씁니다（書きます）」の「씁」は Unlimited-OCR-2 のみ「씽（シン）」と読み取りました（通常の本文3回中2回、かすんだコピー3回すべて）。逆に「랠리（ラリー）」の「랠」は PP-OCRv5（「앨」）と PaddleOCR-VL-1.6（「램」、「랄」）が間違え、Unlimited-OCR-2 は綺麗な画像の方で正解しました。珍しい文字ではどのエンジンも安全ではなく、エンジンごとに弱い文字が異なります。
意味が逆転するエラー：「없습니다（ありません） → 있습니다（あります）」
Unlimited-OCR-2 は「없」を「있」と読み取りました。通常の本文に「없」が14回出てきますが、そのうちの2回であり、かすんだコピーでも同じ2回です。図の例は「なぜそうなっているのかを教えてくれるメッセージも ありません」が「メッセージも あります」になったものです。CER（文字誤り率）としては1,150文字中1文字、0.09ポイントに過ぎませんが、文の意味は正反対になります。2つの Paddle エンジンは14回すべて正解しました。
このエラーは文字の形だけでは説明が難しいです。「없」と「있」はパッチムの形がかなり違います。視覚的な根拠が弱いとき、デコーダーの言語知識がより一般的な方に偏ることで生じるエラーのようです。PP-OCRv6の論文（arXiv 2606.13108）も、VLM系OCRのこのような「ハルシネーション」を問題として挙げています。契約書や検査結果のように、否定語1つが重要な文書であれば、VLMの出力は人間がチェックするワークフローを前提にする必要があります。
句読点：PP-OCRv5 は鍵括弧を変更し、かすれていると消去する
PP-OCRv5 の全体的なCERを引き上げたのは、ほぼすべて句読点です。エラーのタイプを数えてみると（正規化された文字を揃えて異なる箇所をカウント）、通常の本文で 「 を ' に変えたものが46回、 」 を ] に変えたものが42回でした。かすんだコピーでは変更する代わりに 消去していました。 ピリオドの削除60回、「 の削除39回、カンマの削除38回、カンマをピリオドに変更したものが36回、」の削除30回、中黒・の削除28回です。小さくかすんだ点は、検出段階で文字として捉えられていないようです。
2つのVLMも句読点を間違えますが、回数ははるかに少ないです。PaddleOCR-VL-1.6 はかすんだコピーで 「 を ‘ や ' に変えたものが18回、Unlimited-OCR-2 はかすんだコピーで中黒の削除が18回、「 を ' に変えたものが11回で最も多かったです。
採点システム側の小さな欠陥も1つ挙げておきます。正解のダッシュ – を3つのエンジンすべてハイフン - として読み取りましたが、正規化処理がハイフンをマークダウンの記号とみなして削除するため、「ダッシュの削除」としてブロックごとに4回ずつカウントされました。厳密にはダッシュをハイフンに変更したものであり、3つのエンジンに同じように適用されるため、順位は変わりません。
複数ページモードにおける解像度の低下
Unlimited-OCR-2 が長い文書の10ページを一度に読み取った出力には、1ページずつ読み取る際には見られないエラーが混ざっています。「늘어납니다（増えます） → 놀아납니다（いいように遊ばれます）」、「체감（体感） → 채갑」、「멘션（メンション） → 댄선」、「가벼운（軽い） → 바뀌온」、「댓글（コメント） → 덧글」（3回）、「랠리（ラリー） → 뭘리」といったものです。1文字ではなく2、3文字が一緒に崩れ、形の似た別の単語に置き換わります。同じページを1ページずつ読み取った PaddleOCR-VL-1.6 の最初の10ページのCERは 0.58% でした。
原因は論文ですでに指摘されています。DeepSeek-OCRの表3において、画数の詰まった中国語は、同じ Base モードでの編集距離が英語の約4倍（0.205対0.054）であり、トークンを増やした Gundam モードで 0.097 に改善されます。Unlimited-OCRの第1弾レポート（arXiv 2606.23050、§5.4）でも、40ページを超える文書のエラーの大部分は Base モードで小さな文字が読めなかったこと によって生じたと記載されています。韓国語もパッチムのある四角い形をした文字であるため、中国語側に近いです。我々の結果はその説明と一致しています。1ページあたりの視覚トークンが273個に減ると、24pxの韓国語のパッチムが潰れてしまいます。
6. なぜこのように遅いのか、そしてこの数値で語ってはならないこと
Unlimited-OCR-2 の1ページあたり30秒という速度は、論文の速度とはかけ離れています。しかし、両者の数値は 性質が異なります。
論文の数値は同時スループットです。 Unlimited-OCR 第1弾の 5,580 TPS（秒間トークン数、§5.2）は同時リクエスト512件の合計であり、第2弾の表4における 1,315 TPS はバッチサイズ16の場合です。1つのリクエストあたりに換算すると、それぞれ約11、約82トークン/秒になります。第2弾の図6(b)のステップあたり約3.8ms はバッチサイズ3で測定された値です。3つの数値すべてにおいてハードウェアは明かされていません（未確認）。我々の環境は バッチサイズ1で秒間37.9トークン、1ステップ26.4ms でした（通常の本文8ページの出力9,426トークンを248.6秒で割った値）。
ハードウェアの影響は大きくありません。 バッチサイズ1のデコーディングでは、ステップごとに重みをメモリから読み込む必要があるため、メモリ帯域幅にボトルネックが生じます。モデルカードでテストされた A800 80GB の帯域幅は 1,935 GB/s（公式仕様）であり、我々の GPU は約 936 GB/s で、その差は約2.1倍です。アクティブパラメータ約 0.57B を bf16（2バイト）で読み込むと、1ステップあたり約 1.14 GB となるため、我々の GPU でも理論上は1ステップあたり約 1.2ms が下限となります（推定）。実測値の 26ms はその20倍を超えています。ボトルネックはハードウェアではなく 実行パスです。
Transformersのパスは「高速テスト用」です。 モデルカードがそのように案内しており、サービングには SGLang が推奨されます。受け取ったリモートコード（revision 5632329a）を
読んでみるとその理由がわかります。トークンを1つずつ生成する Python のループであり、CUDA graph がありません。MoE のレイヤーごとに tokens_per_expert.cpu() で GPU と CPU が
同期し、デコーディングアテンションは選択されたブロックのみを計算するのではなく、キャッシュ全体を fp32 にコピーして密行列積を行った後にマスクで隠します。結果はスパースアテンションと同じですが、計算は密です。そのため、20ページの束は10ページの束の2.16倍の時間がかかりました（出力トークンは1.96倍）。1ステップが 27.7ms から 30.6ms へと約 10% 長くなった分です。
SR-SWA が保証するのは「1ステップが一定である」ということです。 合計時間は出力トークン数に比例するため、ページ数に線形に増加するのが正常です。 SR-SWA が防ぐのは全体アテンションの二乗増加であり、第2部の図 6(b) でその差が大きく開くのは50ページから100ページ以上にかけてです（100ページで全体アテンション約 26.7ms 対 SR-SWA 約 3.9ms、図から目視で読み取った値）。今回の10・20ページの測定では、SR-SWA の利点を検証できません。
PaddleOCR-VL も同様の状況です。 我々は vLLM や FastDeploy サーバーを使用せず、Paddle の動的グラフで1ページずつ順番に読み取りました。v1.0 の論文の表 13 は、A100 1枚に 512個の PDF を詰め込んで FastDeploy で 1.62 ページ/秒、vLLM で 1.35 ページ/秒を報告しています。付録の表 A2・v1.5版の表 A8 には、普及型コンシューマー GPU での 0.36 から 0.54 ページ/秒もあります。今回の 0.07 ページ/秒（13.81秒）とは10倍以上の差があります。これもバッチ処理のスループットであるため、単純に比較することはできません。
したがって、この結果から言えるのは できない ことがあります。
- 「Unlimited-OCR-2 は PaddleOCR-VL-1.6 よりも2倍遅い」：両方の VLM とも推奨されるサービングパスを使用していません。サービングエンジンにおける速度の差は未計測です。
- 「PP-OCRv5 は VLM よりも90倍速い」：従来型パイプラインの速度は我々の条件に合致していますが、VLM 側の数値はバッチ 1 かつサービングエンジンなしのパスでの値です。
- 「Unlimited-OCR-2 が最も不正確である」：今回のテストでは1段落の本文の文字だけを確認しました。このモデルが強みとしているのは、ページをまたぐ表や段落、見出しの階層構造です。 自己報告されている MPDocBench 84.59（第2部 p.10 表 1）は、同じベンチマークを第三者が測定した PaddleOCR-VL-1.5 の 80.80（MPDocBench 論文の表 2）よりも高くなっています （測定者が異なり、入力方式が同じかは未確認です）。構造に関する指標は我々は測定していません。
- 「繰り返しエラーがなかった」：著者の評価設定では n-gram 繰り返しブロック（サイズ 35）を有効にしていますが、我々は無効にしました。今回の60ページではループは見られませんでしたが、設定が異なります。
7. 何を選ぶべきか
我々の実測が及ぶ範囲内でのみ推奨します。韓国語の1段落の本文、グリッド状の表、24GB GPU 1枚、バッチ 1 を基準としています。
| 行いたいこと | 選ぶべきもの | 根拠と注意点 |
|---|---|---|
| 多くのページを素早く、検索インデックス用 | PP-OCRv5 韓国語 | 1ページあたり 0.36秒、2.27 GiB。文字のみ CER 0.33%（かすれたコピー 1.23%）。鍵括弧や句点が変わったり消えたりする |
| 人間が読む結果、かすれたスキャン | PaddleOCR-VL-1.6 | 4つの束すべてで最も正確（通常 0.48%、かすれ 1.51%）。我々のパスでは1ページあたり 14秒、大量処理の場合は vLLM・FastDeploy サービングを別途測定すること |
| ページをまたぐ表・段落、長い本 | 我々の実測では判断保留 | Unlimited-OCR-2 は文字の正確性において3つの中で最も弱く（複数ページモードで 2.6%台）、構造上の利点は測定していない。SGLang のパスで別途測定すること |
| 否定語や数字が重要な文書 | どのエンジンであれ 要校正が前提 | 「쟀（測定した）」は3つとも7回すべて間違えており、VLM は「없（ない） → 있（ある）」のように意味を逆転させることがある |
従来型パイプラインと VLM を組み合わせる方法もあります。まず PP-OCRv5 ですべてを読み取ってインデックスを作成し、人間が読むページや信頼性の低いページのみ PaddleOCR-VL-1.6 で再度読み取るという方式です。この組み合わせの効果は未計測です。
8. 制限事項
- 合成文書であること。 正解を知るために文字を1つのフォントで描画しており、かすれ・回転・縮小・JPEG も合成です。紙の質感、歪み、影、手書き、多段組み、印影といった実際のスキャンにおける困難さはありません。実際のスキャンにおける結果は未計測です。
- 表がシンプルであること。 セルの結合がないグリッド状の表が4ページであり、表の構造（TEDS）は測定せずセルの文字をつなげて比較しました。
- サンプルが小さいこと。 束ごとに4ページから8ページであり、中央値は8ページ中の5番目の値です。0.1パーセントポイント単位の差は1ページで覆る可能性があります。
- 単一のハードウェア、時分割であること。 24GB の GPU 1枚を他の作業と共有しており、その影響は個別に測定していません。
- サービングエンジンを使用していないこと。 Unlimited-OCR-2 は Transformers のパス（bf16、torch 2.14）、PaddleOCR 系は PaddleOCR 3.7.0 と paddlepaddle-gpu 3.4.0（cu129）による独自の推論です。
- n-gram の繰り返しブロックを無効にしたこと（Unlimited-OCR-2、
no_repeat_ngram_size=0). - Unlimited-OCR-2 の40ページの束は測定が途中で中断したため、 10ページと20ページのみです。他の2つのエンジンの長い文書は40ページをページごとに読み取りました。
- 本文の出処。 テストの段落は我々の勉強ノートから取ったものであり、その中にはこのブログに公開された記事も含まれています。エンジンの学習データに同じ文章が含まれているかは未確認です。
- メモリの数値はアロケーター基準であること。 フレームワークが事前に確保する分や CUDA コンテキストは除外されているため、実際のカードの占有量はさらに大きくなります。
ちょっとした一言。 「쟀습니다（測定しました）」を3つのエンジンが21回読み取って、21回すべて間違えました。卓球のボールの速度を測ったと書こうとして寝たと書かれたら困りますよね！ そのため、OCR の結果は1つの数値で選ぶのではなく、何をどのように間違えるかまで確認して選びます。
参考文献
原文はいずれも 2026-10-30 にアクセスして確認しました。arXiv は HTML 版であるため、ページ番号の代わりに節・表番号を記載しています。
- Unlimited OCR Works, arXiv 2606.23050: https://arxiv.org/abs/2606.23050
- Unlimited OCR Works 2（レポート PDF、arXiv 番号なし）: https://huggingface.co/baidu/Unlimited-OCR-2/blob/main/Unlimited-OCR-2.pdf
- Unlimited-OCR-2 モデルカード: https://huggingface.co/baidu/Unlimited-OCR-2
- DeepSeek-OCR, arXiv 2510.18234: https://arxiv.org/abs/2510.18234
- DeepSeek-OCR 2, arXiv 2601.20552: https://arxiv.org/abs/2601.20552
- PaddleOCR-VL, arXiv 2510.14528: https://arxiv.org/abs/2510.14528
- PaddleOCR-VL-1.5, arXiv 2601.21957: https://arxiv.org/abs/2601.21957
- PaddleOCR-VL-1.6, arXiv 2606.03264: https://arxiv.org/abs/2606.03264
- PaddleOCR 3.0 Technical Report, arXiv 2507.05595: https://arxiv.org/abs/2507.05595
- PP-OCRv6, arXiv 2606.13108: https://arxiv.org/abs/2606.13108
- PP-OCRv5 多言語認識モデル（公式ドキュメント）: https://www.paddleocr.ai/latest/en/version3.x/algorithm/PP-OCRv5/PP-OCRv5_multi_languages.html
- OmniDocBench, arXiv 2412.07626、リポジトリとリーダーボード: https://github.com/opendatalab/OmniDocBench
- MPDocBench-Parse, arXiv 2605.22100: https://arxiv.org/abs/2605.22100
- MarathonDocBench: https://huggingface.co/datasets/baidu/MarathonDocBench
- A800 80GB PCIe 仕様（Lenovo Press）: https://lenovopress.lenovo.com/lp1813-thinksystem-nvidia-a800-80gb-pcie-gen4-gpu
- Myers, 「A fast bit-vector algorithm for approximate string matching based on dynamic programming」, Journal of the ACM, 1999