PDFをMarkdownにしたい。数式や表も崩さず取り込みたい。できれば手元のPCで動かしたい。

そんな用途でOCRを探すと、PaddleOCR、GLM-OCR、DeepSeek-OCR、MinerU……と候補が次々に出てきます。そこにBaiduのUnlimited-OCRも加わりました。

名前だけを見ると「無制限に読める」「新しいから最も高精度」と期待してしまいますが、実際に公式資料を読むと、注目するべき点はもう少し具体的でした。

この記事では、公開モデルの仕様、提供形態、ライセンス、同じ評価セットの公開ベンチマークを比較します。私のPCで全モデルを動かした実測記事ではありません。確認日は2026年10月13日です。

1. Unlimited-OCRは、モデル・研究とクラウドAPIを分けて見る

Unlimited-OCRはBaiduが公開している文書解析モデルです。公式リポジトリでは2026年6月22日に発表したと記載され、コードとモデルの重みが公開されています。論文 Unlimited OCR Works のarXiv初投稿も6月22日です。公式GitHub、論文の公開履歴

一方、Baidu Cloudには、このモデルを使った文書解析APIがあります。10月12日更新の公式資料では、期間限定の無料提供と、個人の実名認証で200ページ、企業の実名認証で1,000ページの無料テスト枠が案内されています。APIは非同期で、PDFは最大500ページまでとされています。Baidu Cloud公式API資料

ここで混同しやすいのが、次の3つです。

対象	意味
公開モデル	重みをダウンロードして、自分の環境で推論する
論文の長文処理	複数ページをまとめて入力し、長い出力を生成する研究上の機能
Baidu Cloud API	サービス側が提供する受付・解析・結果取得の仕組み

APIが500ページを受け付けることは、ローカルモデルが500ページを1回で読み切れる保証ではありません。 また、資料の更新日を、そのままモデルの初公開日と読むこともできません。

「Unlimited」という名前から、永久無料・利用回数無制限と判断するのも早計です。クラウドの無料枠と、公開モデルを自分で動かす計算費用は別に考える必要があります。

2. Unlimited-OCRの注目点は、長い出力でのメモリの増え方

Unlimited-OCRは、DeepSeek-OCRを出発点に、デコーダーのAttentionをReference Sliding Window Attention（R-SWA） へ置き換えたモデルです。論文表記では総パラメータ3B、活性化パラメータ0.5B。すべてのパラメータを毎回計算する構成とは異なります。Unlimited OCR論文

通常のAttentionでは、生成が長くなると、過去の生成内容を保持するKVキャッシュも増えます。R-SWAは入力側の参照を残しつつ、生成側では直近の一定範囲を保持します。入力を固定したとき、出力の伸長に伴うKVキャッシュの増大を抑えるのがポイントです。

ただし、「文書を何ページ増やしてもGPUメモリが変わらない」という意味ではありません。入力の画像、モデルの重み、前処理などにもメモリが必要です。

論文には40ページ以上の内部評価もありますが、標準の最大長は32K。公式の複数ページ推論例も最大長32,768を指定しています。文字密度や画像条件によって収まるページ数は変わるので、名前どおりの無限処理と受け取らないほうがよさそうです。論文の長文評価、公式推論例

3. 比較するのは「文字認識」だけではない

文書OCRを使うとき、本文の文字が正しいだけでは足りないことがあります。二段組の読み順、数式のLaTeX化、表の結合セルなどが崩れると、後から修正する手間が増えます。

今回の中心は、文書画像から本文・数式・表などを構造化するモデルです。名前の近いPaddleOCRでも、PP-OCRシリーズとPaddleOCR-VLシリーズは役割を区別します。

PaddleOCR公式では、PP-OCRv6は文字検出・認識向けの軽量モデルとして、PaddleOCR-VL-1.6は文書解析向けのVLMとして紹介されています。PP-OCRv6は2026年6月11日、VL-1.6は5月28日の公開です。用途が違うため、以下の文書解析スコアにPP-OCRv6を無理に並べません。PaddleOCR公式の更新情報

4. 公開仕様と提供方法を比較

ここでは、中心となるモデルと、その周辺のツールを整理します。パラメータ数だけでは、必要なVRAMや処理時間は決まりません。

対象	公開モデル／規模	公式に案内される使い方	ライセンス表記
Unlimited-OCR	`baidu/Unlimited-OCR`／3B	Transformers、vLLM、SGLangでの推論。Baidu Cloud APIも提供	コード・モデルともMIT表記
PaddleOCR-VL-1.6	`PaddlePaddle/PaddleOCR-VL-1.6`／0.9B	PaddleOCRの文書解析パイプライン、Transformersなど	モデルはApache-2.0
GLM-OCR	`zai-org/GLM-OCR`／0.9B	公式SDK、vLLM、SGLang、Ollama／MLX向けガイド。クラウドAPIも提供	モデルはMIT。コードとレイアウト解析はApache-2.0
DeepSeek-OCR	`deepseek-ai/DeepSeek-OCR`	公式READMEでTransformers／vLLMとPDF処理例を案内	公式リポジトリはMIT
DeepSeek-OCR 2	`deepseek-ai/DeepSeek-OCR-2`／3B	公式READMEでTransformers／vLLMとPDF処理例を案内	モデル・リポジトリはApache-2.0表記
MinerU2.5-Pro	`opendatalab/MinerU2.5-Pro-2605-1.2B`／1.2B	`mineru-vl-utils`などでレイアウト検出と領域認識を実行	モデルカードはApache-2.0

根拠：Unlimitedモデルカード、Unlimited公式GitHub、PaddleOCR-VL-1.6モデルカード、GLM-OCR公式GitHub、DeepSeek-OCR公式GitHub、DeepSeek-OCR 2公式GitHub、DeepSeek-OCR 2モデルカード、MinerU2.5-Proモデルカード

DeepSeek-OCRの初公開は2025年10月20日、OCR 2の発表は2026年1月27日と公式READMEに記載されています。MinerUの上記モデルは5月21日の公開です。GLM-OCRの技術報告は3月11日にarXivへ初投稿されていますが、論文投稿日とモデルの初公開日は区別します。DeepSeekの発表履歴、MinerUモデルの更新情報、GLM技術報告の履歴

MinerUはツール本体とモデルを区別する

MinerUという名前は、モデル単体だけでなく、PDFやOffice文書を解析するツール全体にも使われます。今回の精度表に載せるのはMinerU2.5-Proという評価対象で、最新ツール全体のあらゆる処理モードを評価した数字ではありません。

確認時点のツール本体はMinerU Open Source Licenseで、Apache 2.0を土台に追加条件があります。一方、上記Proモデルカードの表記はApache-2.0です。組み込むときは、使用するコード・モデルの版ごとに確認します。MinerU公式、ツール本体のライセンス

5. 精度はOmniDocBenchの同じ表で比較する

以下は評価元の公式READMEにあるOmniDocBench v1.6_fullの公開値から、主要な8モデルを抜き出したものです。数式と表の数値は小数第2位へ丸めています。各社が別条件で発表した数字を寄せ集めたランキングではありません。 OmniDocBench公式評価表

モデル	総合 ↑	本文の編集距離 ↓	数式CDM ↑	表TEDS ↑
TeleOCR	96.91	0.0267	96.59	96.82
OvisOCR2	96.47	0.0265	97.49	94.58
PaddleOCR-VL-1.6	96.34	0.0326	97.53	94.76
MinerU2.5-Pro	95.75	0.0360	97.45	93.42
GLM-OCR	95.22	0.0440	97.18	92.83
Unlimited-OCR	94.00	0.0394	95.72	90.21
MinerU-2.5	93.04	0.0450	95.77	87.88
DeepSeek-OCR 2	90.25	0.0500	91.84	83.89

本文の編集距離は小さいほど良く、ほかの3列は大きいほど良い指標です。総合は、本文の編集距離を変換した値、数式CDM、表TEDSの平均です。「総合96.91」は、文字を96.91％正しく読めるという意味ではありません。

この表では、総合はTeleOCR、本文はOvisOCR2、数式はPaddleOCR-VL-1.6が最も良い値です。Unlimited-OCRはGLM-OCRより本文の編集距離が小さい一方、数式・表では下回ります。用途を決めてから列を見ると、総合点だけでは見えなかった違いが分かります。

また、MinerU2.5-ProとMinerU-2.5は別の評価対象です。評価元のモデル一覧では、それぞれMinerU2.5-Pro-2605-1.2BとMinerU2.5-2509-1.2Bを参照しています。同じ名前の系列でも、版を省略すると比較が曖昧になります。評価対象の一覧

TeleOCRとOvisOCR2にも公開モデルがあります。導入する際には、この表から性能を推測するだけでなく、それぞれの推論手順を確認してください。TeleOCRモデルカード、OvisOCR2モデルカード

6. Unlimited-OCRの「SOTA」は、比較範囲を読む

Unlimited-OCR論文のTable 1は、比較対象をend-to-endのVLMモデルに絞っています。v1.5ではUnlimited-OCRが93.23、DeepSeek-OCRが87.01、DeepSeek-OCR 2が89.17という結果です。v1.6ではUnlimited-OCRの自己報告値は93.92です。Unlimited OCR論文・Table 1

一方、前節の評価元の公開表ではUnlimited-OCRは94.00です。論文の自己報告値と評価元の掲載値は、出典を分けて扱います。 違いの原因をこの数字だけから推測することはできません。

ここから「Unlimited-OCRがすべてのOCRで1位」と結論づけるのは、比較範囲を広げすぎです。レイアウト解析と領域認識を組み合わせるGLM-OCRのような構成も含めて、実際に使うシステムとして比較する必要があります。GLMの技術報告は、その2段階構成を説明しています。GLM-OCR技術報告

さらに、v1.5とv1.6の値も直接混ぜません。 異なる評価セットや処理条件の数字を一列に並べると、「新モデルが古いモデルをどれだけ超えたか」を誤読しやすくなります。

7. ローカルとAPIの選び方

ローカル推論の利点は、文書の扱いと実行環境を自分で管理できることです。APIは、GPUや推論サーバーを自分で用意する手間を減らせます。ただし、この2つは同じモデル名でも、前処理やサービス上の制限が一致するとは限りません。

Unlimited-OCRのBaidu Cloud APIは、タスクを送信してIDを受け取り、結果を取得する仕組みです。ローカルのinfer_multi呼び出しと同じ使い勝手・制限だと考えず、サービスの入力条件を確認します。Baidu Cloud API仕様

GLM-OCRは、公式SDKでクラウドAPIとセルフホストの両方を案内しています。API資料ではPDF・画像を扱い、日本語も対応言語に含まれています。ただし、対応言語に載っていることは、日本語資料で他モデルより高精度という証拠ではありません。GLM-OCR公式SDK、公式API概要

手元のGPUで動くかを判断するときは、次の条件を揃えて確認したいところです。

使用するモデルの正確な版と量子化の有無
入力画像の解像度とページ数
最大生成長、バッチ数、同時処理数
前処理・レイアウト解析・結果整形を含む処理時間
GPUメモリのピークと、結果が途中で切れた割合

公開資料にあるtokens/sと、自分が気になる「PDFを投入してMarkdownが完成するまでの秒数」は別の指標です。今回は同じGPUで実測していないため、PCでの速度順位や最低VRAMを断定しません。

8. 日本語の教材で使うなら、まだ確かめたいことがある

OmniDocBenchは幅広い文書解析の比較に使えますが、この表だけで、日本語の縦書き・ルビ・手書き答案の順位までは決められません。 公式の属性説明も、英語・簡体字中国語・その混在を中心に記述されています。OmniDocBenchの評価属性

例えば、勉強用のPDFを取り込むなら、私なら次のような小さな評価セットを作ります。これは今後の検証案で、実施済みの結果ではありません。

資料の種類	確認したい点
日本語の横書き本文	誤字、句読点、段落の欠落
縦書き・ルビ付きのページ	読み順、本文とルビの混入
数学・物理の問題	分数、添字、ギリシャ文字、LaTeXの再現
結合セルを含む表	行列構造、単位、セル内の文字
手書き答案	消し跡、訂正、文字と数式の区別
10〜40ページのPDF	ページ欠落、繰り返し、出力上限、所要時間

本文の誤りと、数式・表の崩れは分けて記録します。数値だけでなく、失敗したページの例も残すと、次に同じ用途で使う人が判断しやすくなります。

9. 私なら、こう候補を絞る

ここまでの公開仕様と評価を踏まえた、私の選び方です。手元の資料での性能を保証するものではありません。

目的	最初に比較したい候補	理由
数式入り教材を構造化したい	PaddleOCR-VL-1.6、GLM-OCR	数式を含む文書解析の公開評価と、公式の導入方法を確認しやすい
長いPDFをまとめて処理したい	Unlimited-OCRと、ページ単位で処理する構成	長い出力を扱う設計が、自分の資料で役立つかを調べたい
公開ベンチの上位を試したい	TeleOCR、OvisOCR2も追加	BaiduとGLMの二択にせず、候補の取りこぼしを減らしたい
PDFからMarkdown／JSONまで整えたい	MinerU	モデルだけでなく、変換ツール全体の使い勝手も評価したい
軽量な文字認識が目的	PP-OCRv6なども別に検討	ページ全体の構造化が本当に必要か、先に整理したい

Unlimited-OCRを調べて面白かったのは、OCRの進化が「1ページの精度を上げる」だけでなく、「長く読み続けるときの計算をどう抑えるか」にも向かっていることです。

どのOCRが最適かは、本文・数式・表のどれを重視するか、ローカルで動かすか、どれくらい長い文書を扱うかで変わります。公開ベンチで候補を絞り、自分の資料で確かめるところまでをセットにして選びたいと思います。