Unlimited-OCR解説｜AI OCRで数十ページを一括処理するBaiduのOSSとKVキャッシュ固定の仕組み

紙の資料をテキストにするAI OCRは、この1年で「1ページの画像を渡すと整形済みのMarkdownが返ってくる」ところまで来ました。ただし、そこには全ツール共通の暗黙の前提があります——処理はページ単位だという前提です。100ページのPDFを読ませるとき、私たちはfor文で100回モデルを呼び、そのたびにモデルの記憶はリセットされています。Baiduが公開した baidu/Unlimited-OCR は、この前提そのものを外そうとしているAI OCRモデルです。数十ページを1回の推論（forward pass）でまとめて読み切る、という設計になっています。

この記事ではAI OCRモデルとしてのUnlimited-OCRを解説します。大規模言語モデル全般の前提知識は LLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版 をご覧ください。

Unlimited-OCRとは：AI OCRを「1ページずつ」から「一括」に変えるモデル

Unlimited-OCRは、Baidu Inc. が2026年6月22日に公開した文書解析向けのAI OCRモデルです。技術レポート「Unlimited OCR Works」（arXiv:2606.23050）と同時に、モデルの重みがMITライセンスでHugging Faceに置かれました。リポジトリの説明文は “Welcome the Era of One-shot Long-horizon Parsing”——「一括・長距離パースの時代へ」と読める一文で、この記事で扱う論点はほぼこの1行に集約されています。

まず、数字で実体を押さえます。以下はいずれも2026年7月25日にGitHub API・Hugging Face APIから取得した値です。

スター約1.9万に対してリリースもタグも0件、という並びに違和感を覚えるかもしれません。READMEには “Release” という見出しの箇条書きがありますが、中身は「vLLMが対応した」「ModelScopeに載った」「ms-swiftで学習できるようになった」といったエコシステム統合の履歴であって、バージョン番号を切ったリリースではありません。実際、GitHub上のタグは1つも切られていません。バージョンを固定して運用したい場合は、Hugging Faceのリビジョン（コミットハッシュ）を指定する形になります。

リポジトリの中身は12ファイルしかない

もうひとつ、着手前に知っておくと事故が減る事実があります。GitHubリポジトリのファイルツリーを取得すると、エントリは全部で12件しかありません。内訳は次のとおりです。

・assets/long-horizon-ocr.gif（約80MB。冒頭に置いたデモ動画の元素材）
・wheel/sglang-0.0.0.dev11416+g92e8bb79e-py3-none-any.whl（約12MB。SGLangの開発版ホイール）
・Unlimited-OCR.pdf（約450KB。技術レポート本体）
・infer.py（約11KB。バッチ推論スクリプト）
・README.md / LICENSE / CONTRIBUTING.md / .gitignore
・assets/Unlimited-OCR.png / assets/baidu.png と、assets / wheel の2ディレクトリ

つまり、モデル本体の実装コードはGitHubリポジトリに入っていません。modeling_unlimitedocr.py や deepencoder.py といった実装は、すべてHugging Face側のモデルリポジトリに置かれており、trust_remote_code=True を付けてロードしたときに初めて取得・実行されます。GitHubの★数だけを見て「実装を読んでから判断しよう」とクローンすると、READMEとバッチスクリプトしか出てこないので面食らいます。読むべきコードはHugging Face側にあります。

なぜ従来のAI OCRは長い文書で失速するのか

Unlimited-OCRの設計を理解するには、まず「何が困っていたのか」を押さえるのが近道です。技術レポートの問題設定は明快です。

LLMをデコーダに使うend-to-end OCRは、言語の事前分布を活かせるため認識精度が上がります。しかし出力トークンが伸びるにつれてKVキャッシュが積み上がり、メモリ消費が増え、生成速度が落ちていきます。レポートはこれを人間と対比して、人間は本を数百ページ書き写しても効率が落ちない、と指摘します。

この制約があるため、現行のOCRモデルはページ単位のfor文という回避策を取っています。1ページ処理したらメモリを完全にリセットし、次のページへ。技術レポートはこの方式を、外部スケジューラが管理する「エンジニアリング上の回避策」であって、連続した長い処理を細切れの短いタスクに分断してしまっている、と評価しています。

分断されて何が困るのか。技術レポートは、ページをまたいだ文脈——たとえば表がページをまたいで続いている、見出しの階層が前ページから継続している、といった情報が毎回失われる点を問題にしています。ページごとに独立して読ませる限り、モデルは「いま自分が文書のどこを読んでいるか」を知りません。

人間が本を書き写すときの注意の向け方

技術レポートが設計の出発点に置いているのは、人間が本を書き写す行為の観察です。文字を1つ書き写すとき、私たちは①原本、②直前に書いたばかりのごく一部、③次に書く文字——の3点に注意を向けており、すでに書き終えた全文を毎回見返してはいません。

この観察は、既存のattention機構のどれとも一致しない、というのがレポートの主張です。全履歴を参照するフルattentionとも違いますし、線形attentionとも違います。線形attentionでは視覚（参照）トークンが再帰的な状態更新を受けるため、視覚特徴が徐々にぼやけて認識精度が落ちてしまうからです。この「原本ははっきり見えたまま、書いた内容だけが柔らかく忘れられていく」という非対称性を、そのまま機構に落としたのが次節のR-SWAです。

R-SWAの仕組み：AI OCRのKVキャッシュを固定長に保つ

R-SWA（Reference Sliding Window Attention）は、生成される各トークンが参照する範囲を次の2つに限定します。

・参照トークンは全部見る：画像から作られた視覚トークンとプロンプトは、常に全件attentionの対象になる
・出力トークンは直近n個だけ見る：デフォルトは n = 128。それより古い自分の出力は見ない

重要なのは、視覚トークンを状態遷移から除外している点です。通常のスライディングウィンドウattention（SWA）では、窓から外れた情報は状態に畳み込まれて徐々に劣化していきます。原本の画像がぼやけていくのと同じことが起きるわけです。R-SWAは視覚トークンを窓の外に出さず常に全件参照するため、この劣化が起きません。「Reference（参照）」という接頭辞はここに由来します。

KVキャッシュの管理は、容量 m + n のキューとして実装されます（m は参照トークン数、n は窓幅）。新しいトークンが生成されるたび、キュー内の (m+1) 番目のKVが追い出されます。したがって、何トークン生成してもKVキャッシュのサイズは一定です。メモリ使用量も1トークンあたりの計算量も、生成が進んでも増えません。

この設計は、公開されているconfig.jsonの値と一致します。実際に取得したconfig.jsonには sliding_window_size: 128 があり、レポートが言うデフォルト窓幅と一致します。同時に use_mla: false となっており、ベースであるDeepSeek-V2系のMLA（Multi-head Latent Attention）は使われていません。attention層がまるごとR-SWAに置き換わっている、という説明と整合します。

モデル構成：エンコーダは継承、デコーダを差し替え

構成要素を上から見ていきます。

DeepEncoder（視覚エンコーダ） はDeepSeek-OCRから引き継いだ部品です。窓attentionのViT（SAM系）と全体attentionのCLIP系を縦続きにすることで、画像トークンを16倍に圧縮します。技術レポートは、エンコーダの圧縮率がモデルの上限を左右すると説明しています。圧縮が足りずprefixトークンが長くなりすぎると、デコード速度も実効的なデコード長も頭打ちになるためです。多ページを一度にprefillしたいUnlimited-OCRにとって、高い圧縮率は前提条件になります。config.jsonでは vision_config.model_name: deeplip_b_l、image_size: 1024、sam_vit_b と clip-l-14-224 の2系統が確認できます。

projector は入力2048次元を1280次元へ写す線形層です（projector_type: linear）。

デコーダ はMoE構成のLLMで、技術レポートの表記は 3B-MoE-A570M——総パラメータ約3Bのうち、推論時に活性化するのは約570Mという意味です（レポート本文とベンチマーク表では 3B-A0.5B と表記）。config.jsonの実値は n_routed_experts: 64 / num_experts_per_tok: 6 / n_shared_experts: 2 / num_hidden_layers: 12 / hidden_size: 1280 / vocab_size: 129280。この12層すべてのattentionがR-SWAに置き換わっています。

活性パラメータが570M程度に抑えられている点は、実運用でのコストに直結します。重みファイル自体は6.67GBありますが、1トークン生成あたりに動く計算量は総パラメータ3Bのモデルとしては小さくなります。

ベンチマーク実測値とDeepSeek-OCRからの系譜

技術レポートはOmniDocBenchのv1.5とv1.6で評価しています。v1.5はDeepSeek-OCRを含む「定番モデル」の公式値が揃っているためベースライン比較に、v1.6はテスト画像が296枚多い最新版で、現行SOTAとの比較に使われています。

主要な指標を抜き出すと次のようになります。編集距離（Edit）は低いほど良く、それ以外は高いほど良い指標です。

ベースラインのDeepSeek-OCRに対して、総合で +6.22、テキスト編集距離で −0.035、表TEDSで +5.96 という差分です。技術レポートは、この改善が「わずか200万件のPDF文書データでの継続学習」で得られたと述べています。

最新版のv1.6では総合93.92で、レポートはこれをend-to-end SOTAと表現しています。ただしここは慎重に読む必要があります。同じ表のQianfan-OCRが93.90で、差は0.02しかありません。しかもQianfan-OCRもBaiduのモデルです。項目別に見ると、表TEDSはQianfan-OCRの90.53に対しUnlimited-OCRは90.16で下回っており、読み順編集距離も0.129とv1.5の0.045から悪化しています。v1.6の総合首位は実質的に同着と読むのが妥当で、「全項目で最良」ではありません。

DeepSeek-OCRからの系譜は、ファイル構成にも表れている

技術レポートは冒頭からDeepSeek-OCRをベースラインとして明示しており、READMEの謝辞でもDeepSeek-OCR・DeepSeek-OCR 2・PaddleOCRに言及しています。この系譜は、公開されているファイル構成からも確認できます。

・config.jsonの language_config.architectures が ["DeepseekOCRForCausalLM"]
・auto_map が modeling_deepseek.DeepseekV2Model / DeepseekV2ForCausalLM を指している
・Hugging Face上のファイルに configuration_deepseek_v2.py と modeling_deepseekv2.py が同梱されている
・SGLang経由で推論するとき、リクエストに DeepseekOCRNoRepeatNGramLogitProcessor というDeepSeek-OCR由来のlogit processorをそのまま渡す

つまりUnlimited-OCRは、DeepSeek-OCRのエンコーダと全体骨格を受け継ぎ、デコーダのattention機構を入れ替えたモデルだと、公開物から読み取れます。技術レポート自身がそう説明しているので、隠された事実というわけではありませんが、「独自のOCRモデルがゼロから登場した」わけではない点は押さえておくとよいでしょう。

なお、このlogit processorが必要な理由も設計と関係しています。長い出力では同じフレーズを繰り返すループに陥りやすく、READMEのサンプルはいずれも no_repeat_ngram_size=35 を指定しています。窓幅も単一画像では128、複数ページでは1024と使い分けられています。長距離パースを成立させるには、モデル構造だけでなくデコード時のガードも併用されている、と読むのが正確です。

動かし方：transformers・vLLM・SGLangの3経路

公式が案内している実行経路は3つあります。いずれもNVIDIA GPUが前提です。

READMEのTransformers手順は、Python 3.12.3 + CUDA 12.9 でテスト済みと明記されており、torch==2.10.0 / transformers==4.57.1 / pymupdf==1.27.2.2 などのバージョンが列挙されています。まず1枚の画像を読ませる最小の手順は次のとおりです。

import torch
from transformers import AutoModel, AutoTokenizer

model_name = 'baidu/Unlimited-OCR'
tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)
model = AutoModel.from_pretrained(
    model_name,
    trust_remote_code=True,
    use_safetensors=True,
    torch_dtype=torch.bfloat16,
)
model = model.eval().cuda()

# gundam モード: base_size=1024, image_size=640, crop_mode=True
model.infer(
    tokenizer,
    prompt='<image>document parsing.',
    image_file='your_image.jpg',
    output_path='your/output/dir',
    base_size=1024, image_size=640, crop_mode=True,
    max_length=32768,
    no_repeat_ngram_size=35, ngram_window=128,
    save_results=True,
)

単一画像には2つのモードがあります。gundam は image_size=640 に crop_mode=True を組み合わせて画像を分割しながら読むモード、base は image_size=1024 で分割せずに読むモードです。密度の高いページはgundam、単純なページはbaseが基本の使い分けになります。

複数ページを一括で読ませるのが、この記事の本題である長距離パースです。ここは infer_multi を使い、プロンプトも Multi page parsing. に変わります。READMEによればマルチページはbaseモードのみで、窓幅（ngram_window）も128から1024に上がります。

import os, tempfile, fitz  # PyMuPDF

def pdf_to_images(pdf_path, dpi=300):
    doc = fitz.open(pdf_path)
    tmp_dir = tempfile.mkdtemp(prefix='pdf_ocr_')
    mat = fitz.Matrix(dpi / 72, dpi / 72)
    paths = []
    for i, page in enumerate(doc):
        out = os.path.join(tmp_dir, f'page_{i+1:04d}.png')
        page.get_pixmap(matrix=mat).save(out)
        paths.append(out)
    doc.close()
    return paths

model.infer_multi(
    tokenizer,
    prompt='<image>Multi page parsing.',
    image_files=pdf_to_images('your_doc.pdf', dpi=300),
    output_path='your/output/dir',
    image_size=1024,
    max_length=32768,
    no_repeat_ngram_size=35, ngram_window=1024,
    save_results=True,
)

PDFは直接読み込めないため、PyMuPDFでページを画像化してから渡す形になります。READMEのサンプルは300 dpiです。

サーバとして立てる場合は、vLLMの公式レシピとDockerイメージが用意されています。GPU世代でイメージが分かれている点に注意してください。

# デフォルト（CUDA 13.0）
docker pull vllm/vllm-openai:unlimited-ocr

# Hopper世代のGPU向け（CUDA 12.9）
docker pull vllm/vllm-openai:unlimited-ocr-cu129

infer.py は「一括読み」ではなくページ並列である

ここは実装を読まないと取り違えやすい箇所です。リポジトリ同梱の infer.py は、SGLangサーバを自動起動して画像ディレクトリやPDFを処理するバッチスクリプトで、READMEには次のように案内されています。

python infer.py --pdf ./examples/document.pdf --output_dir ./outputs --concurrency 8 --image_mode gundam

一見すると「PDFを一括パースするスクリプト」に読めます。しかし329行の実装を読むと、--pdf の引数説明は “each page is converted and sent as one concurrent request”——各ページを個別のリクエストとして並列送信するとあります。実際に build_jobs() はページごとに1ジョブを作り、出力も <prefix>_page_0001.md のようにページ単位で書き出します。定数も PROMPT = "document parsing."（単一ページ用）、NGRAM_WINDOW = 128（単一ページ用の窓幅）です。

長距離パースを試したい場合は、infer_multi（Transformers）か、SGLangのOpenAI互換APIに Multi page parsing. プロンプトと複数画像を渡す経路を使います。READMEのSGLang節にはそのサンプルも載っています。同じリポジトリの中に「速く回す道」と「一括で読む道」が別々に用意されている、と理解しておくと迷いません。

なお infer.py はリトライ処理（502で最大5回）とサーバのヘルスチェックを持っており、REQUEST_TIMEOUT = 1200 と長めのタイムアウトが設定されています。大量ページを流す前提の作りになっています。

MinerU型パイプラインとの使い分けと、無料で使える範囲

「AI OCRを導入したい」という要望に対して、Unlimited-OCRが常に最適解になるわけではありません。層が違うツールと比較しておきます。

「OCRを無料で使いたい」という観点では、Unlimited-OCRはMITライセンスで重みまで公開されているため、ライセンス費用はかかりません。ただし無料なのはソフトウェアであって、計算資源は別です。bfloat16の重みだけで約6.67GBあり、これに加えて実行時にはKVキャッシュ・アクティベーション・複数ページ分のprefillぶんのVRAMが必要になります。実際の必要VRAMは投入ページ数・同時実行数・モードによって変わるため、手元の環境で確認するのが確実です。手持ちのGPUで動くLLMの当たりを付ける方法は llmfit完全ガイド：今のPCで動くローカルLLMを1コマンドで判定するツール が参考になります。

すぐ手元のPDFをMarkdownにしたいだけであれば、パイプライン型のほうが早く目的に着きます。取り込み層の選択肢は MinerUでRAGの文書取り込みを高精度化｜PDF・表・数式をLLM対応Markdownに変換 にまとめてあります。逆に、自前の処理系にOCRエンジンとして組み込みたい、長い文書をページ分割せずに読ませたい、という要件ならUnlimited-OCRが候補に入ります。

また、GPUを持たずに出力の傾向だけ確かめたい場合は、Hugging Face Spacesに公式のデモが公開されています（READMEのRelease欄によれば2026年6月24日にAK氏が作成したもの）。まずここで自分の文書に近いサンプルを流し、それから環境構築を判断するのが無駄がありません。

速度差が出るのは「出力が長くなってから」

R-SWAの効果がどこで効くのかは、技術レポートの効率分析が具体的です。出力256トークンの時点では、DeepSeek-OCRが7229.32 TPS、Unlimited-OCRが7229.52 TPSでほぼ同値です。短い出力では差が出ません。 差が開くのは出力が伸びてからで、6144トークンではDeepSeek-OCRの5822.87に対しUnlimited-OCRは7847.71となり、レポートは約35%の差と表現しています。

OmniDocBenchでの実測値としては、Baseモードで5580 TPS（512並列）対4951 TPSの+12.7%が挙げられています。レポート自身が「OmniDocBenchの平均文書長は比較的短いため、出力が長くなるほどUnlimited-OCRの優位が顕著になる」と補足しています。裏を返せば、1ページずつ短い出力で使う限り、この設計の利点はほとんど現れません。導入を検討するなら、長い文書をまとめて処理する使い方が前提になります。

「Unlimited」の天井：32Kと40ページ超の精度低下

最後に、名前から受ける印象と実際の制約を突き合わせておきます。技術レポートのLimitation章は、次のように明記しています——有限のコンテキスト長（例えば32K）のもとでは、真に無制限のパースは達成できない。prefill長にも制約されるためだ、と。

これは公開されているconfig.jsonとも一致します。max_position_embeddings は32768で、READMEのサンプルもすべて max_length=32768 を渡しています。DeepEncoderが画像トークンを16倍に圧縮しているとはいえ、ページ数が積み上がればprefillは長くなり、いずれ32Kの枠に収まらなくなります。

精度面でも、ページ数を増やすと相応の劣化があります。技術レポートは小説・文書・論文を2・5・10・15・20・40ページ以上に分けた自前のテストセットで評価しており、各カテゴリ10冊以上を使ったと記載されています。

40ページ以上でも編集距離は0.1069に収まり、Distinct-35は96.90%を保っています。2ページ時点の0.0362と比べると約3倍ですが、数十ページを一括で読ませた結果としては実用の範囲に見えます。技術レポートは、繰り返し誤りの多くが「マルチページ時にDeepEncoderのBaseモード（1024×1024）を使うため、PDF内の小さな文字が判別しにくいこと」に起因しており、R-SWAが長い生成の途中で方向を見失うためではない、と分析しています。解像度側の制約であって、attention機構側の破綻ではないという整理です。

ここは実務上そのまま使える示唆でもあります。細かい文字が多い資料を一括で流すと精度が落ちやすいので、そうした文書はページ単位でgundamモード（分割して読む）を使う、という判断ができます。

まとめ

なお、Baiduは同時期にQianfan-OCRも公開しており、OmniDocBench v1.6では両者が0.02差で並んでいます。R-SWAという機構自体は技術レポートが「OCRに限らずASRや翻訳など、参照ベースで長い依存関係を扱うタスクに適用できる」と述べており、OCRの外へ広がる可能性のほうが本命かもしれません。マルチモーダルなオープンモデル全般の動向は Gemma 4 12B｜エンコーダレス・マルチモーダルで256K文脈を16GBノートで動かすオープンモデル、オープンウェイトのMoEモデルをローカルで動かす話は GLM-5.2 使い方・解説｜Z.aiの744B MoEオープンモデルをローカル運用＋ベンチ比較 でも扱っています。

参照ソース

・baidu/Unlimited-OCR（公式リポジトリ・README） — 実行手順・対応バックエンド・リポジトリ構成（12ファイル）・infer.py の実装
・Unlimited OCR Works（技術レポート・arXiv:2606.23050） — R-SWAの設計、OmniDocBench v1.5/v1.6のスコア、長距離パースの評価（Table 3）、TPS比較（Table 4）、Limitation章
・baidu/Unlimited-OCR（Hugging Face モデルカード） — config.jsonの実値、重みサイズ、likes・ダウンロード数、同梱ファイル一覧
・OmniDocBench（評価ベンチマーク） — 比較表に使われている各モデルの公式スコアの出所