OCRレイテンシーベンチマーク
p50/p95、スループット、テールスパイク（2026）

3つの指標を1ページで: p50、p95、ページ/分

このページでは、同じ実行の3つの指標を報告しており、それぞれ異なる質問に答えます。 p50（中央値）は、warm_then_scored モードでの定常状態のページあたり推論時間です — スコアリング対象のパスに先立って固定のウォームアップパスが実行され、モデルのロードは除外されます — そのため、「エンジンがすでに実行されている場合、1ページあたりどのくらい高速か？」という質問に答えます。 p95 は、同じ測定の95パーセンタイル値です: ページの5%がこの値より長くかかりました。 1分あたりのページ数 は、モデルの初期化を含むウォールクロックスループットです — バッチジョブと請求対象のGPU時間を左右する数値です。

3つの指標は互換性がなく、一致することは想定されていません。定常状態のp50はモデルのロードを除外します。ウォールクロックのページ/分はそれを含みます。p95は、p50が無視する最初のページ/プリフィル効果とバッチスケジューリングの動作を捉えます。このページのすべてのチャートとテーブルは、どの指標を示しているかを明記しています — 「108.7 ms」（p50、ロードなし）と「449ページ/分」（ウォールクロック、ロードあり）は、docTRに関する2つの異なる事実として扱ってください。矛盾ではありません。

全体で使用される3つの用語: テールレイテンシ は、最も遅い数パーセントのページ（p95以降）の動作です — 単一のページを待つユーザーにとっては、中央値ではなくテールが体験を左右します。 最初のページ/プリフィル効果 は、定常推論の前にモデルまたはパイプラインを準備するための一時的なコストであり、実行の初期サンプルが遅くなる原因となります。 ウォールクロックスループット は、初期化を含む実行のすべてのミリ秒をカウントします。このベンチマークのプロトコルでは、p50/p95は定常状態の測定値であり、ページ/分はウォールクロックです — その差は、初期化とスケジューリングのオーバーヘッドです。

SROIE 2019: ページあたりのレイテンシ中央値ランキング

361件の英語レシートにおいて、従来型の2段階OCRエンジンが高速側を占め、文書解析VLMが低速側に位置しています。しかし、各ファミリー内のばらつきが驚きです。docTR（108.7 ms）は、次の従来型エンジン（PaddleOCR、297.0 ms）より2.7倍高速で、最も遅い2つのエンジンはどちらもVLMです（Unlimited-OCR 1,600.7 ms、Surya2 2,668.0 ms）。一方、最速のVLMであるPaddleOCR-VL（694.3 ms）でも、すべての従来型エンジンより遅い結果となっています。

出典: summary_metrics.csv — latency_p50_ms列、sroie_2019行。docTR 108.7、PaddleOCR 297.0、EasyOCR 413.6、Tesseract 670.9（CPUのみ）、PaddleOCR-VL 694.3、Docling 732.0、Unlimited-OCR 1600.7、Surya2 2668.0。定常状態のレイテンシ、ウォームアップ後にスコアリングする測定モード（モデル読み込み時間は除外）。

表: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute、sroie_2019 行（各361サンプル、8件すべて error_rate 0.0）。p95/p50比はCSV値の除算で算出（例: 3331.3505 / 296.9897 = 11.22）。TesseractはCPUのみで実行（compute_type=cpu）、その他はすべてGPU。定常状態のレイテンシはモデル読み込みを除く。ページ/分は初期化を含む実時間。

アーキテクチャパターンはファミリーレベルでは明確です。従来型エンジンが1〜4位、VLMが5、7、8位を占め、Docling（純粋なOCRエンジンでもVLMでもないパイプライン型パーサー）がその中間に位置します。しかし、各ファミリー内の差は大きい。VLMクラスターは3.8倍（694.3〜2,668.0 ms）、従来型クラスターは6.2倍（108.7〜670.9 ms）に及びます。つまり「VLM」と「従来型」はレイテンシのカテゴリではなく、個々のエンジン設計がファミリー所属よりもはるかに大きな影響を与えることを意味します。

p50は尾部を隠す：エンジン別のp95/p50比

中央値は最悪ケースの予測には不十分です。PaddleOCRのSROIEにおけるp95（3,331.4 ms）はp50（297.0 ms）の11.2倍です。中央値のページが300 ms未満でも、5%のページは3.3秒以上かかりました。インタラクティブなワークロードでは、この比こそが、ユーザーが0.3秒待つか3.3秒待つかを左右します。docTRのp95（281.4 ms）はp50の2.6倍に留まり、安定しています。

そのメカニズムはファーストページ／プリフィル効果です。GPUエンジンは安定した推論の前に一度だけ初期化コストを支払い、バッチスケジューリングが遅いサンプルを直列化することがあります。これはプロトコル固有の動作です。これらのp95値は、このベンチマークの実行パターン（固定テスト分割、ウォームアップ後のスコアリング）を反映したものであり、エンジンの普遍的な特性ではありません。データが示すのは、このプロトコル下での各エンジンの尾部の形状です。PaddleOCRとDoclingはSROIEで長く重い尾部を持ち、docTR、EasyOCR、Unlimited-OCRは中央値に近い尾部を維持しています。

出典：summary_metrics.csvより算出 — latency_p95_ms ÷ latency_p50_ms、sroie_2019行（公開値の除算による比、例：3331.3505 / 296.9897 = 11.22）。PaddleOCR 11.2倍、Docling 4.4倍、docTR 2.6倍、EasyOCR 2.3倍、Tesseract 2.2倍、Surya2 2.2倍、PaddleOCR-VL 1.7倍、Unlimited-OCR 1.6倍。

この比が示さないことに注意してください：p95/p50比が小さいことは速度の主張ではありません。Unlimited-OCRはこのベンチマークで最も小さい尾部（1.6倍）を持ちますが、そのp50（1,600.7 ms）とp95（2,521.9 ms）はどちらもdocTRのp95（281.4 ms）よりはるかに遅い。この比は分布の形状を測るものであり、分布の位置を測るものではありません。2つの数値を合わせて読んでください：遅い中央値の周りの小さい尾部は、依然として遅いのです。

スループットは別の物語を語る：ページ/分 vs p50

エンジンを1分あたりのページ数でランク付けすると、順位は変わります。docTRの449.3ページ/分とSurya2の12.1の差は37倍で、p50の24.5倍の差よりも広いです。しかし、PaddleOCRはp95テールが11.2倍あるものの、依然として79.7ページ/分を維持しています：EasyOCRの124.5に近く、PaddleOCR-VLの68.2やDoclingの56.7を上回ります。遅い中央値と重いテールがあっても、立派なバッチスループットを妨げることはありません。

その整合性は測定基準にあります：ページ/分はモデル初期化とスケジューリングを含むウォールクロックスループットであり、p50は負荷を除いた定常状態の単一ページ推論です。以下の表は、ページ/分をそれが示す1ページあたりの平均ウォールクロック時間（60,000 ÷ ページ/分 — 導出された推定値であり、実測値ではありません）に変換し、p50との差を示しています。PaddleOCRの1ページあたりの暗黙のウォールクロック時間（752.7ミリ秒）は、定常状態のp50（297.0ミリ秒）の2.5倍です；Surya2の（4,940.0ミリ秒）は、そのp50（2,668.0ミリ秒）の1.9倍です。オーバーヘッド — 初期化、スケジューリング、呼び出しごとのパイプラインコスト — はp50だけでは見えず、低いp50が自動的に高いスループットを意味しない理由です。

表: summary_metrics.csv — latency_p50_ms / pages_per_minute、sroie_2019 行。 ウォールクロック ms/ページは算出値です（60,000 ÷ pages_per_minute、例: 60,000 / 79.7130 = 752.7）— 測定されたスループットからの算術計算であり、個別に測定された値ではありません。オーバーヘッド = 算出ウォールクロック ÷ 測定p50。ページ/分はモデル初期化を含むウォールクロック時間、p50はロードを除いた定常状態です。

極端な値に関する2つ目の整合性メモ: 唯一のCPUエンジンであるTesseractは、SROIEで 78.6ページ/分 を維持しており — GPU上のPaddleOCRの79.7とほぼ同等です — そのp50（670.9 ms、CPU）とウォールクロック（763.0 ms）はほぼ同一です。これは、シングルスレッドのCPUエンジンには隠すべき初期化オーバーヘッドがほとんどないためです。そのp95（1,507.0 ms）はp50の2.2×であり — ベンチマークで最もタイトなテールの1つです。CPU対GPUのスループット同等性については、Tesseract vs PaddleOCR で詳細に分析されています。

インタラクティブとバッチ：1,000 ms閾値の読み解き

1ページを待つユーザーにとって、1,000 msは有用な境界線です。応答性を感じられる限界にほぼ相当します。p50で見ると、8エンジンのうち6つがこの閾値を下回ります（SROIE 2019）：docTR（108.7 ms）、PaddleOCR（297.0 ms）、EasyOCR（413.6 ms）、Tesseract（670.9 ms、CPU）、PaddleOCR-VL（694.3 ms）、Docling（732.0 ms）。中央値でこの閾値を超えるのはUnlimited-OCR（1,600.7 ms）とSurya2（2,668.0 ms）のみです。

p95で見ると状況は逆転します。1秒以内に収まるエンジンは2つだけです。docTR（281.4 ms）とEasyOCR（960.4 ms）です。他のすべてのエンジンのテールは閾値を超えます：PaddleOCR 3,331.4 ms、Docling 3,239.8 ms、Unlimited-OCR 2,521.9 ms、Tesseract 1,507.0 ms、PaddleOCR-VL 1,154.3 ms、Surya2 5,872.2 ms（summary_metrics.csv latency_p95_ms、sroie_2019行）。「インタラクティブ」を最悪ケースでも応答性が求められると定義するなら、選択基準となるのは中央値ではなくテールであり、条件を満たすのは2エンジンだけです。

バッチ処理はもう一つの領域であり、エンジン側に有利な経済性をもたらします。モデルの初期化はプロセス/バッチごとに一度だけ支払われるため、逐次処理やバッチ処理では初期化コストがより多くのページに分散されます。バッチサイズが大きくなるにつれて、ページあたりのレイテンシとページあたりのコストは両方とも低下します。これは測定基準（ページ/分は初期化を含み、p50は含まない）から導出された議論であり、新しいベンチマーク実行ではありません。同じ推論とその計算例はコストページの方法に記載されています。

CORD（インドネシアのレシート）：同じ傾向、異なるテール

文書セットを変えてもランキングはほぼ維持されます — docTRが最速で、Surya2が最遅いまま — ですが、言語の変更によってテールの形状が変わります。CORD v2では、Surya2のp95は26,976.9 ms（約27秒）に跳ね上がり、自身のp50（1,485.3 ms）の18.2倍となり、ベンチマーク全体で最も極端なテールイベントとなりました — 一方、SROIEでのテール比はわずか2.2倍でした。言語の内容がテールの挙動を変えます。英語のレシートで安定していたVLMが、インドネシア語のレシートでは30秒近い待ち時間に達することがあります。

CORD v2は、ネストされたフィールド（menu、sub_total、total）を持つインドネシア語のデータセットです。8つのエンジンのいずれも主にインドネシア語でトレーニングされていないため、このデータセットは言語横断的なストレステストとしても機能します。そのレシートはSROIEよりも短く、テキスト密度も低いため、ほとんどのエンジンがここでは高速化します — docTRはp50で100.4 ms（500.4ページ/分）、PaddleOCRはp50で108.2 ms（141.0ページ/分）に低下します。CORDは、このベンチマークでは意図的にSROIEのランキングから分離されています（言語が異なり、グラウンドトゥルースの構造も異なるため）。この表のポイントは、レイテンシが文書セットに応じて変化し、テールが劇的に変動し得るということです。

出典: summary_metrics.csv — latency_p50_ms列、cord_v2行。docTR 100.4、PaddleOCR 108.2、EasyOCR 192.8、PaddleOCR-VL 249.3、Docling 338.0、Tesseract 474.6（CPUのみ）、Unlimited-OCR 608.2、Surya2 1485.3。定常状態のレイテンシ、ウォームアップ後にスコアリング（モデルの読み込み時間は除く）。

表: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute、cord_v2行（各100サンプル）。p95/p50比はCSV値の除算で算出（例: 26976.9306 / 1485.3493 = 18.16）。TesseractはCPUのみで実行。定常状態のレイテンシはモデル読み込みを除外。ページ/分は初期化を含む実時間。

Surya2のCORD p95は26,976.9 msで、ベンチマーク全体で最大のテールイベントです — 中央値が1.5秒のデータセットで、20ページに1ページが約27秒かかりました。参考までに、これはdocTRのCORD p95（235.9 ms）の114倍に相当します。SROIEではほぼ同等だった2つのエンジン（Surya2の2.2倍、Unlimited-OCRの1.6倍のテール比）が、CORDでは大きく乖離しています（18.2倍 vs 2.4倍）— テール挙動はエンジン単体ではなく、エンジンとドキュメントの組み合わせに依存することを示しています。

レイテンシとコストは同じ時計で動く

レンタルGPUはウォールクロック時間で課金されるため、レイテンシとコストは同じ測定値を2回見ているにすぎません：docTRは最速のエンジン（p50 108.7 ms）であり、最も安価（SROIEでcost_per_1000_pages 0.0479）でもあります。一方Surya2は最も遅く（p50 2,668.0 ms）、最も高価（1.0609）です — 同じ割合で同じ傾向です。重量級のVLMは低速かつ高価で、軽量な従来型エンジンは高速かつ安価です。

この相関は完全ではありません。コストはウォールクロックのページ/分（初期化を含む）に従う一方、p50はそれを除外するためです — PaddleOCRのp50（297.0 ms）はEasyOCR（413.6 ms）より高速ですが、PaddleOCRの1,000ページあたりのコスト（0.2214）はEasyOCR（0.1098）の約2倍です。これはウォールクロックスループットが大幅に低いためです（79.7 vs 124.5ページ/分；summary_metrics.csvのcost_per_1000_pages / pages_per_minute、sroie_2019行）。完全なコスト順位、コスト計算式、およびその背景にある計算は、関連ページ「OCR Cost per 1,000 Pages」に記載されています — このページではレイテンシに焦点を当て、その相関関係のみを参照します。

よくある質問

ページあたり最速のOCRエンジンはどれですか？

docTRがこのベンチマークで最速でした：SROIE 2019でページあたり108.7 msのp50と281.4 msのp95（summary_metrics.csvのlatency_p50_ms / latency_p95_ms、doctr/sroie_2019行）で、449.3ページ/分を維持しました。最も遅かったSurya2は、p50で24.5倍遅く（2,668.0 ms）、スループットでは37倍遅かった（12.1ページ/分）です。

GPUでの1ページあたりの一般的なOCRレイテンシはどのくらいですか？

RTX 4090、SROIE 2019のレシート（summary_metrics.csv latency_p50_ms、sroie_2019行）において、8つのオープンソースエンジン間でp50（中央値）が1ページあたり108.7 ms（docTR）から2,668.0 ms（Surya2）の範囲であり、同一ハードウェア上で24.5倍の差があります。定常状態、ウォームアップ後、スコアリング済みで、モデルのロード時間は除外しています。同じエンジンをCORD v2で実行した場合、p50は100.4 msから1,485.3 msの範囲です。

OCRのp95レイテンシがp50よりもはるかに高いのはなぜですか？

最初のページ/プリフィル効果とバッチスケジューリングの動作によるものです。GPUエンジンは一度だけのプライミングコストを支払い、遅いサンプルは直列化される可能性があるため、最も遅い5%のページ（第95パーセンタイルの定義上）は中央値から大きく離れます。PaddleOCRのSROIE p95（3,331.4 ms）はp50（297.0 ms）の11.2倍ですが、docTRのp95（281.4 ms）はp50のわずか2.6倍です（summary_metrics.csv latency_p95_ms / latency_p50_ms、sroie_2019行）。p95値はプロトコル固有であり、このベンチマークの実行パターンを反映したもので、普遍的なエンジンの特性ではありません。

OCRレイテンシと1分あたりのページ数が一致しないのはなぜですか？

これらは異なる測定値だからです。ページ/分は、モデルの初期化とスケジューリングを含むウォールクロックスループットであり、p50はモデルのロードを除外した定常状態の1ページあたりの推論時間です。SROIEでは、PaddleOCRのp50（297.0 ms）は純粋な定常状態で1分あたり約200ページを意味しますが、測定されたスループットは1分あたり79.7ページであり、1ページあたりのウォールクロック時間は752.7 msで、p50の2.5倍です（summary_metrics.csv latency_p50_ms / pages_per_minute、paddleocr/sroie_2019行）。バッチジョブの場合はページ/分を基準に計画し、インタラクティブな待機時間の場合はp50とp95を基準に計画してください。

インタラクティブ使用に適したOCRレイテンシはどのくらいですか？

テールで1,000 ms未満が実用的な基準です。SROIEでは、8つのエンジンのうち6つがp50で1秒未満を維持しています（docTR 108.7、PaddleOCR 297.0、EasyOCR 413.6、Tesseract 670.9、PaddleOCR-VL 694.3、Docling 732.0 ms）が、p95を1秒未満に維持しているのはdocTR（281.4 ms）とEasyOCR（960.4 ms）のみです（summary_metrics.csv latency_p50_ms / latency_p95_ms、sroie_2019行）。最悪のケースでも応答性を感じさせる必要がある場合はp95が決定し、典型的なケースで十分な場合はp50が決定します。

なぜ1つのOCRエンジンはレシートで27秒もかかったのか？

Surya2のCORD v2におけるp95は26,976.9 ms（約27秒）で、自身のp50（1,485.3 ms）の18.2倍、ベンチマーク全体で最大のテールイベントでした（summary_metrics.csvのlatency_p95_ms / latency_p50_ms、surya2/cord_v2行）。SROIEでのテールは2.2倍と穏やかだったため、このスパイクはエンジンとCORDの組み合わせに固有のものです。言語コンテンツとスケジューリングが中央値だけでなくテールの挙動を変えたのです。

Tesseract OCRはGPUなしでも十分速いですか？

CPU上で、TesseractはSROIE 2019で78.6ページ/分を維持し、p50は670.9 msでした。GPUベースの従来エンジンよりは遅いものの、スループットでは3つのVLMすべて（PaddleOCR-VL 68.2、Docling 56.7、Unlimited-OCR 34.4、Surya2 12.1ページ/分）より速く、テールも2.2倍と小さいです。このベンチマークではCPUのみで動作します（summary_metrics.csvのtesseract/sroie_2019行）。「十分速い」かどうかは、処理量と、テキストではなくフィールドが必要かどうかに依存します。詳細はTesseract vs PaddleOCRのCPUコストプロファイルを参照してください。

ページ数を増やすと、OCRはページあたりの処理が速くなりますか？

はい、定常状態の下限まで速くなります。これは新しい実行ではなく、測定基準から導出された効果です。モデルの初期化はプロセス/バッチごとに一度だけ支払われます（ページ/分には含まれますが、p50には含まれません）。そのため、バッチ処理や逐次処理で償却されます。高ボリュームでは、ページあたりの実時間は定常状態のp50にスケジューリングを加えた値に近づきます。docTRのSROIE数値はすでにその下限に近く（p50 108.7 ms vs 導出された実時間133.5 ms/ページ）、Surya2（p50 2,668.0 vs 4,940.0 ms）は償却すべき初期化オーバーヘッドがより大きいことを示しています。

このページのレイテンシ数値はどこから来ていますか？

すべての数値は、ImageToTableai/benchmark-ocrで公開されているファーストパーティベンチマークのresults/summary_metrics.csv（latency_p50_ms、latency_p95_ms、pages_per_minute）の行です。各実行には、測定モード（warm_then_scored）、モデルバージョン、環境フィンガープリントを記録した1つの編集済みmanifest.jsonが付属しています。データセットの定義は、以下に引用するSROIE 2019およびCORDの論文に基づいています。

方法論と情報源

プロトコル

このページは、独立した再現可能なベンチマーク実行（公式ティア）のレイテンシー指標を報告するものであり、第三者による主張の調査ではありません。固定テスト分割のみを使用：SROIE 2019テスト（英語レシート361件、フラットなフィールド：会社名/日付/住所/合計）とCORD v2テスト（インドネシア語レシート100件、ネストされたフィールド：メニュー/小計/合計）。トレーニング分割は評価されていません。すべての（エンジン×データセット）ペアは、同じ画像、同じ正解データ、同じ測定プロトコル（warm_then_scored：スコアリング対象パスの前に固定のウォームアップパスを実行）を使用しました。全16回の実行はerror_rate 0.0で完了しました（summary_metrics.csvのerror_rate列）。データは2026年8月に収集されました。

実行環境

• ハードウェア：すべてのGPU実行は単一のNVIDIA RTX 4090（24 GB）上で実施。TesseractはCPUのみ（compute_type=cpu）で実行され、すべての表でその旨が明記されています。GPUティアは1つ、場所と時間も1つ — このページの範囲に関する記述のとおりです。
• エンジン：全モデルは追加調整なしでそのまま実行。バージョンは実行マニフェストに従って固定：Tesseract 5.3.4、PaddleOCR 3.7.0、EasyOCR 1.7.2、docTR v1.0.1、Docling 2.119.0、Surya2 0.22.1、Unlimited-OCR vLLM-served、PaddleOCR-VL 1.6。
• 測定モード：warm_then_scored — レイテンシー値はモデル読み込みを除いた定常状態の1ページあたりの推論時間。ページ/分はモデル初期化を含む実時間（各実行のperformance.run_wall_time_ms、マニフェストは一部編集済み）。
• 実行ティア：全16回の実行はofficial。ベンチマークプロトコル（reports/receipt_v1_official_protocol.md）に基づき、公開が許可されるのは公式実行のみです。

指標の定義

• p50（中央値レイテンシ）: 定常状態におけるページあたりの推論時間の中央値で、50%のページはこれより速かった。モデル読み込み時間は除外（ウォームアップ後に計測）。
• p95（テールレイテンシ）: ページあたりの推論時間の第95パーセンタイルで、5%のページはこれより長くかかった。この実行プロトコルにおける先頭ページ/プリフィル効果とバッチスケジューリングの挙動を反映。プロトコル固有の値であり、エンジンの普遍的な定数ではない。
• p95/p50比: 2つのCSV列の除算で算出（例: 3331.3505 / 296.9897 = 11.22）。テールの形状を示す指標であり、速度の主張ではない。
• ページ/分: モデル初期化を含む実時間スループット。バッチジョブおよび課金の観点。
• 実時間ms/ページ（導出値）: 60,000 ÷ ページ/分 — 測定されたスループットに基づく算術計算で、導出推定値として表示され、測定値ではない。

ソース一覧

1. summary_metrics.csv（GitHub raw）。16行 = 8エンジン × 2つのレシートデータセット（sroie_2019、cord_v2）。列にはlatency_p50_ms、latency_p95_ms、pages_per_minute、compute_type、error_rateが含まれる。このページのすべてのレイテンシおよびスループットの数値は、ここにある行に由来する。
2. ImageToTableai/benchmark-ocrリポジトリ。結果CSV、編集済み実行マニフェスト、固定プロトコル（reports/receipt_v1_official_protocol.md）、および再現用のデータセットサンプルリスト（固定テスト分割）をホストする公開リポジトリ。
3. results/manifests/（GitHub）。公開された各実行（16実行）につき1つの編集済みmanifest.json。環境フィンガープリント、モデルバージョン、測定モード（warm_then_scored）、実時間、アーティファクトハッシュを含む。
4. Huang et al.「ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction」(2019)。SROIE 2019データセットの定義、タスク構造、ライセンス（CC-BY-4.0）。
5. Park et al.「CORD: A Consolidated Receipt Dataset for Post-OCR Parsing」(2020)。CORD v2データセットの定義、ネストされたフィールドスキーマ、ライセンス（CC-BY-4.0）。

制限事項

• 単一GPUティア、単一ロケーション・単一時点: すべてのGPU数値は、2026年8月に1か所のRTX 4090で収集したものです。他のGPU、マルチGPUサーバー、異なるスケジューリングでは、レイテンシとスループットが変動します。採用前に自社のハードウェアで測定してください。
• レシートのみ: SROIE（英語）とCORD（インドネシア語）のレシートを対象としています。請求書、フォーム、契約書、長文ドキュメントのレイテンシは未測定です。上記のランキングはレシート以外には一般化できません。また、CORDの結果はSROIEのランキングには統合されていません。
• p95はプロトコル固有: p95の値は、このベンチマークの実行パターン（固定の361/100ページ分割、ウォームアップ後のスコアリング）における、ファーストページ/プリフィルの影響とバッチスケジューリングを反映しています。これは今回の実行の形状を示すものであり、普遍的な最悪ケースの保証ではありません。
• p50/p95はモデルロードを除外、ページ/分はそれを含む: この2つの基準は意図的に異なります（定常状態の推論 vs ウォールクロックスループット）。これらが同じ数値として提示されることはありません。派生したウォールクロックの1ページあたりの時間（60,000 ÷ ページ/分）は、測定されたスループットに対する算術計算であり、個別に測定された数値ではありません。
• CPU/GPUの非対称性: Tesseract（CPU）はGPUアクセラレーションエンジンと比較されています。そのレイテンシはCPUハードウェアを反映しています。すべてのテーブルにその旨が記載されていますが、この非対称性は比較に内在するものです。
• クラウド/APIモデルなし: AWS Textract、Google Document AI、Azure AI Document Intelligence、およびホスト型OCR/VLM APIは含まれていません。これらのレイテンシモデル（ネットワーク、呼び出しごとのメータリング、オートスケーリング）は、ここで測定されたローカルエンジンとは根本的に異なります。
• バッチサイズスイープなし: 初期化の償却は、測定基準（ページ/分は初期化を含み、p50はそれを除外）から導き出され、コストページの方法と相互参照されています。バッチサイズの実験は実施されていないため、バッチごとのスケーリングは測定値ではなく推定値です。
• サンプルサイズとバージョンの固定: 361 + 100サンプル。結果は、上記の2026年8月時点のモデルバージョンに適用されます。新しいエンジンのリリースによりレイテンシが変わる可能性があり、一桁台のパーセント差はノイズとして扱う必要があります。

関連リファレンス: 1,000ページあたりのOCRコスト · ドキュメント解析VLMに対するOCRパイプライン · docTR vs Surya2: CERタイ、コストギャップ · docTR vs Docling: シングルパス vs パイプライン · Tesseract vs PaddleOCR: レガシーCPU vs 最新GPU

関連記事: AI OCR精度が実際に測定するもの · 画像からのAI抽出と従来のOCRパイプラインの比較 · AIドキュメント抽出の価格（2026年）