Baidu（バイドゥ）、長大な文書を一度に読むOCR「Unlimited-OCR 2（アンリミテッドOCR 2）」をMITライセンスで公開約3B、文書が長くなっても遅延とメモリはほぼ一定とうたう

Baidu（バイドゥ）は、OCRモデルの新版「Unlimited-OCR 2（アンリミテッドOCR 2）」をMITライセンスでHugging Faceに公開しました。リリース欄の日付は2026年10月27日です。モデルページの作成日時は2026年10月26日3時57分（UTC、日本時間では同日12時57分）となっています。Baidu自身の説明では、新方式のSR-SWAによって、文書が長くなってもデコード時の遅延とメモリがほぼ一定になり、数十ページ規模のベンチマークと百ページ級のベンチマークの両方で最高性能（SOTA）を達成したとしています。

3行まとめ

1. Baiduが2026年10月27日付で「Unlimited-OCR 2」をMITライセンスで公開。パラメータは約3.34B（33億）、BF16で約6.7GB。
2. 新方式SR-SWAは、注意の対象を512トークンなど固定サイズの参照に絞り、文書の長さによらず遅延とメモリをほぼ一定に保つとBaiduは説明。
3. MPDocBench（数十ページ）とMarathonDocBench（百ページ級）で最高性能と主張。ただし今回確認したページには点数の表がなく、数値は確かめられていない。

本記事の内容は、日本時間10月27日9時台に公式ページで確認したものです。

何が新しくなったのか

Hugging Faceのモデルカードの「What's New in 2」には3点が挙げられています。

• SR-SWA（Sparse Reference Sliding Window Attention）: 長い系列でのテキストと画像の注意のやりとりを、固定サイズの「作業用の参照」（例として512トークン）まで圧縮する。これにより計算量に上限ができ、1ステップごとのデコード遅延とメモリ使用量が文書の長さによらずほぼ一定になる、とBaiduは説明しています。
• 長い文書から「無制限」へ: SR-SWAにより、有限のコンテキストの中で文書の長さに上限なく読み取れるとし、文書が伸びるほど注意計算が二次関数的に増える問題とメモリの壁を事実上なくせる、と書いています。
• 超長文書のSOTA: 数十ページ級のベンチマーク（例としてMPDocBench）と、百ページ級のベンチマーク（例としてMarathonDocBench）の両方で最高性能、としています。

モデルカードの更新履歴には、2026年6月22日に最初のUnlimited-OCRが発表され、DeepSeek-OCR（ディープシークOCR）を一歩先へ進めることを狙った、と書かれています。その後、6月にはvLLM対応とHugging Face Spacesのデモ、7月にはBaidu Cloudでの提供とms-swiftでの学習対応が加わりました。今回の2は、その後継にあたります。

前の版とは何が違うのか

arXivの論文（2606.23050、2026年6月22日提出）は、最初のUnlimited-OCRについての技術報告です。要旨によると、DeepSeek-OCRをベースに、デコーダーの注意層をすべてR-SWA（Reference Sliding Window Attention）に置き換え、デコード中のKVキャッシュを一定に保つ設計でした。標準の最大長32Kのもとで、数十ページの文書を1回の順伝播で書き起こせるとしています。要旨はR-SWAがOCR以外にも、音声認識や翻訳などに使える汎用の注意機構だとも述べています。

今回の2では名前が「R-SWA」から「SR-SWA」（Sparse Reference Sliding Window Attention）に変わっています。ただし、この論文は2の発表より前の2026年6月に提出されたもので、要旨が扱っているのは最初の版のR-SWAです。SR-SWAの詳しい仕組みや、R-SWAとの違いは、今回取得したページからは確認できていません。GitHubのファイル一覧には「Unlimited-OCR-2.pdf」というファイルがありますが、本記事では中身を読めていません。

誰が、どう使えるのか

モデルカードによると、使い方は2通りです。

Transformersで動かす場合。 AutoModel.from_pretrained に trust_remote_code=True を付けて読み込みます。複数ページは infer_multi で、ページ画像を順に渡すと1回のリクエストで解析し、ページをまたいだ文脈も使えるとされています。出力にはページごとに <PAGE> が入ります。1ページだけなら infer を使い、既定では動的タイル分割（gundamモード）で読みます。

SGLangで動かす場合。 カスタム版のSGLang（sglang-0.5.20.dev10+g8d62f5fb9c）のwheelをインストールして、OpenAI互換のAPIで呼び出します。長い文書では10ページ単位の窓で処理する設定が例に挙げられ、窓を小さくするとメモリのピークは下がる一方、窓をまたぐブロックのつながりが悪くなる、と注意書きがあります。PDFはPyMuPDFで画像にしてから渡す例が載っています。

GitHubには infer.py も置かれています。README（GitHubのリポジトリの説明文）によると、BaiduがMPDocBenchやMarathonDocBenchの評価に使ったバッチ用クライアントで、1文書を1リクエストでSGLangサーバーに送ります。

料金は？

重みはゲートなしでダウンロードできる状態で、今回取得したページに料金表は見当たりませんでした。Hugging Faceのページでは、このモデルを提供するInference Providerは0件（「This model isn't deployed by any Inference Provider」）でした。取得時点では、Hugging Face経由で手軽にAPIとして呼ぶことはできず、モデルカードの手順どおり自分でGPUを用意して動かすことになります。更新履歴にはBaidu CloudとModelScopeで提供とありますが、2の提供状況や料金は今回の出典からは分かりません。

Hugging Faceはダウンロード0、GitHubは2.8万スター

日本時間10月27日9時4分の取得時点で、Hugging Faceのモデルページはいいね0、ダウンロード数0という表示でした。一方、GitHubのリポジトリは28.6k stars、3.0k forksで、コミットは20件です。これは初代Unlimited-OCRの時期から続く同じリポジトリの数字で、2に対する反応だけを示すものではありません。筆者は実際にモデルを動かしておらず、本記事の性能に関する記述はすべてBaiduの主張です。

点数も日本語の精度も、今回のページには載っていない

• ベンチマークの点数。 今回取得したHugging Face・GitHub・arXivの本文には、MPDocBenchとMarathonDocBenchの点数、比較対象のモデル名、遅延やメモリの実測値の表は見当たりませんでした。GitHubの評価手順の説明（utils/README.md）と「Unlimited-OCR-2.pdf」は今回読めていないため、そちらに載っている可能性はあります。最高性能という主張は、点数による裏づけを今回の出典では確かめられません。
• 日本語。 タグは multilingual ですが、日本語の精度や対応言語の一覧は今回のページにありません。日本語の縦書きや表の多い帳票で使えるかは、試すまで分かりません。
• 「無制限」の意味。 「無制限」はBaiduの表現です。モデルカードでも、SGLangの設定例では1ページあたりの出力上限が20,000トークンで、10ページ単位の窓で処理する構成が示されています。実際の運用では、メモリや設定による上限があると読むのが安全です。
• 動かすための条件。 検証環境はA800-80GBで、SGLangはBaidu配布のカスタム版wheelを使います。一般的なGPUや、MacなどのCPU・ローカル環境での動作は、今回の出典には書かれていません。また trust_remote_code=True で配布側のコードを実行するため、社内で使う前にコードの確認が必要です。

今回読んだ3つのページ

• Hugging Face: baidu/Unlimited-OCR-2（日本時間2026年10月27日9時4分に確認）
• GitHub: baidu/Unlimited-OCR（同9時4分に確認）
• arXiv: Unlimited OCR Works（2606.23050）（同9時4分に確認。対象は最初の版）

本記事は続報があり次第更新します。