百度がUnlimited OCR 2を公開：1リクエストで100ページ超を解析、SR-SWAと独自推論スタックでまず何を検証すべきか

MarkTechPostの2026年10月26日の報道によれば、百度は3.34BパラメータのUnlimited OCR 2を公開した。重みはMITライセンスで公開され、SR-SWAによりアテンションを固定の参照セットに圧縮して1リクエストで数百ページの解析を可能にし、自社報告ではMarathonDocBenchで77.1点を記録したという。

公開 2026/10/27更新 2026/10/28

主な変更

MarkTechPostの2026年10月26日の報道によれば、百度は超長文書向けのOCR視覚言語モデルUnlimited OCR 2を公開した。重みはMITライセンスの下でHugging Faceに公開され、コードはGitHubで管理されており、2026年6月のUnlimited-OCRの後継となる。報道によれば規模は3.34Bパラメータで、活性化パラメータ数は非公開、最大位置長は131,072トークン。BF16の重みは約6.7GBで、百度は単一のNVIDIA A800-80GB上でテストした。構造はDeepSeek-OCRのスタイルを踏襲し、SAM ViT-BとCLIP-Lのエンコーダを12層の混合エキスパートデコーダに接続し、各トークンを64のエキスパートのうち6つにルーティング、さらに2つの共有エキスパートを加える。中核の変更点はSR-SWA（疎参照スライディングウィンドウアテンション）で、テキストと視覚の間のアテンションを固定の作業参照セットに圧縮する。報道はモデルカードの例として512トークンの規模を挙げ、設定では128トークンの局所ウィンドウと32トークンのブロックでのtop-16選択を組み合わせるとしている。報道によればこれにより各デコードステップの遅延とメモリ使用量は文書の増加に対してほぼ一定になるが、画像エンコードと総実行時間はページ数とともに増加する。マルチページモードでは1ページあたり273の画像トークンを消費する。ベンチマークについて、報道は百度が公開のMPDocBench-Parse（433文書、3,246ページ）とMarathonDocBench（数百ページ）でテストしたとし、MarathonDocBenchの公開版は見つからなかったとしている。百度のリーダーボード図表によれば、Unlimited OCR 2はMPDocBenchで84.6、MarathonDocBenchで77.1を記録し、比較モデルは後者で最高33.7、前世代のUnlimited-OCRはMarathonDocBenchで0.0だった。すべての数値は百度の自己申告で、報道によれば1枚の図表画像としてのみ提示されている。サブ項目で最も低いのは見出し階層（TEDS）で、MarathonDocBenchでは48.2。表の項目はMPDocBenchの87.8から74.8に下がる。実行方法について、モデルカードはTransformersを簡易テスト用に挙げ（inferは単一ページ、infer_multiは1リクエストで全ページを解析）、サーバ側では報道が言う上流のSGLangではなく百度のカスタムwheel版SGLangを使用する。読み込みにはtrust_remote_code=Trueが必要で、リポジトリ内のPythonコードが実行される。報道はまた、百度の例がウィンドウごとに10ページをスケジュールし前のウィンドウのKV末尾を再利用すること、ウィンドウが小さいほどピークメモリは下がるがページ間の統合は弱くなること、デフォルトのbias設定が462MiBの割り当てを引き起こしメモリ不足につながる可能性があるという警告にも触れている。報道はGitHubリポジトリのコードがどのライセンスかを明らかにしていない。

開発者への影響

開発者にとっての意味は何層かに分かれ、その多くは依然として自ら検証する必要がある。第一層はVRAMとページ数上限の見積もり方が変わることだ。報道の説明によれば、SR-SWAは1ステップのデコードコストをページ数に対して線形に増加させないため、固定のVRAM予算の下では、1リクエストのページ数を制限する主な要因はアテンションの二次関数的増大ではなく、画像エンコードのコスト、KV末尾の占有、ウィンドウのスケジューリングへと移る可能性が高い。これは書籍、申請書類、年次報告書のような高ページ数・低対話のオフラインバッチ処理には実質的な意味がある。ただし報道は同時に、総実行時間は依然としてページ数とともに増えると明言しているため、ページごとの高速応答を求めるオンライン用途での利点は限られる。第二層は推論スタックのロックインリスクだ。サービスの経路は百度のカスタムwheel版SGLangであり、報道はこれを「上流のSGLangではなく」と表現しており、個別に保守が必要なベンダー固有のブランチであることを示している。チームの既存イメージ、バージョン固定、ロールバックの流れが汎用推論フレームワークを前提に組まれている場合、導入は追跡すべき依存が1本増えることを意味する。モデルカードはTransformers経路も挙げており、機能検証の入口にはなるが、本番サービス向けの選択肢ではない。第三層はライセンスと安全性の区別だ。重みはMITライセンスで公開されており、これはライセンス面での寛容な許諾であって「重みのみ公開」と混同してはならない。ただし報道は重みのライセンスのみを述べ、GitHubリポジトリのコードのライセンスには触れていないため、コードの再利用をそのままMITとして扱うべきではない。またMITが及ぶのは許諾の範囲であり、trust_remote_code=Trueで読み込まれるコードの安全性を保証するものではない。後者はリポジトリ内のPythonコードをプロセス内で実行するため、監査要件のある環境では通常、まずコードレビューと隔離実行が必要になる。第四層は評価の基準だ。報道によればMPDocBenchでは各社の項目別差は非常に小さく、例としてテキスト項目は94.8対94.3、数式項目は89.4対89.2で、差は主に数百ページのMarathonDocBenchに集中している。したがって選定の判断は総合スコアの順位ではなく、自社文書のページ数分布に基づくべきだ。見出し階層48.2と長文書の表74.8という2つの弱点は、章ツリーや表の取り込みの下流品質に直結するため、自社サンプルで個別に測定する必要がある。

導入と評価の提案

以下は条件付きの提案であり、報道の事実ではない。判断一：SR-SWAで長文書のスループットを取るかどうか。トリガーは1回のタスクがしばしば百ページ以上に達すること。文書が概ね十ページ以内なら、報道ではMPDocBenchの項目別差は小さく、切り替える理由は乏しい。実行可能な判断は、自社コーパスをページ数で2段階（二十ページ以内と百ページ以上）に分け、同じVRAMのマシンでinfer_multiをそれぞれ実行し、1リクエストのピークVRAM、総所要時間、ページあたり所要時間の曲線を記録すること。百ページ段でページあたり時間がページ数とともに明らかに増えるなら、ボトルネックはすでに画像エンコードに移っているので、ウィンドウのページ数を調整すべきで、1リクエストのページ数をさらに増やすべきではない。判断二：推論スタックはまずTransformersか独自SGLangか。前提はチームの既存推論サービスのスタックがベンダーwheelと互換かどうか。イメージとロールバックの流れが独自SGLangを受け入れられないなら、まずTransformersで機能と精度を検証し、単一カードで単位時間に解析できるページ数がバッチ処理のウィンドウを埋められるかを閾値とする。独自wheelを受け入れられるなら、報道が挙げたリスク点で負荷テストを行う。例の10ページを起点にウィンドウを徐々に縮めてピークメモリを観察し、デフォルトbiasによる462MiBの割り当てがメモリ不足を起こさないか確認し、「メモリ不足による失敗がない」ことを通過の必須条件とする。判断三：構造化出力の受け入れ基準は別に設ける。報道では見出し階層は長文書でわずか48.2、表の項目は74.8に下がる。下流が章ツリーや表の取り込みに依存するなら、まず見出し階層と表の注釈付きの自社サンプルを用意し、ページ数別にこの2項目を測定してから、人手による確認や後処理ルールを重ねるか決める。判断四：trust_remote_code=Trueをリリース前チェックに組み込み、隔離環境でまず実行してリポジトリのコードをレビューし、同時に百度にリポジトリコードのライセンス条項を確認してから本番投入を決める。以上の判断はすべて自社の注釈付きデータセットの誤差に基づくべきで、ベンダーの総合スコアに基づくべきではない。

制限と未確認事項

報道の性能数値はほぼすべて百度の自己申告であり、報道によれば1枚のリーダーボード図表画像としてのみ提示され、独立に再現できる評価の詳細はない。MarathonDocBenchは数百ページのベンチマークと説明されているが、報道はその公開版が見つからなかったと明言しているため、77.1や他モデルとの比較は外部で検証できない。活性化パラメータ数は非公開で、実際の推論演算量やスループットをこれに基づいて推算することはできない。報道はBF16での単一カード実行、重み約6.7GBのみを述べており、量子化版には触れていない。より小さいVRAMの機器に配備できるかは現行情報からは判断できない。今回のカタログ確認時点で、Unlimited OCR 2というバージョンはKimiSeekのモデルカタログに現れていない。報道が挙げるTransformersと独自SGLangはモデルリポジトリやベンダー資料による自前で配備する経路であり、このモデルがKimiSeekで提供開始済みであることを意味しない。報道はいかなるベンダーのホスティングサービスや課金方式にも触れていない。後にホスティングサービスが現れた場合、その可用性と価格は公式ドキュメントと価格ページに従うべきで、価格は変わり得る。報道におけるtrust_remote_code=True、デフォルトbiasがメモリ不足を招く可能性、独自SGLangに関する注意はいずれもベンダー資料に由来し、第三者による検証は受けていない。GitHubリポジトリのコードのライセンスも説明が見当たらない。報道が引用する比較モデル名とベンチマークのバージョンは新しく、本文はその自己申告データを伝えるのみで、独立したテストを行ったことを意味しない。