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

3つの指標、1つのページ：p50、p95、ページ/分

このページでは、同じ実行結果について3つの指標を報告しており、それぞれ異なる質問に答えます。p50（中央値）は、warm_then_scoredモードにおける定常状態の1ページあたり推論時間です。スコアリングパスの前に固定のウォームアップパスが行われ、モデルのロード時間は除外されます。したがって、「エンジンが既に稼働している状態で、1ページあたりどれくらい速いか？」という質問に答えます。p95は、第95パーセンタイルにおける同じ測定値です。ページの5%がこの時間よりも長くかかっています。ページ/分は、モデルの初期化を含む壁時計スループットです。これはバッチジョブや課金GPU時間に影響する数値です。

この3つの指標は互換性がなく、一致する必要もありません。定常状態のp50はモデルのロードを除外し、壁時計のページ/分はそれを含み、p50が無視する初回ページ/プリフィル効果やバッチスケジューリングの挙動をp95が捉えます。このページのすべてのチャートと表は、どの指標を示しているかを明記しています。例えば「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× です — 中央値のページが300ms未満であるにもかかわらず、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,251.9 ms）はどちらもdocTRのp95（281.4 ms）より遥かに遅いです。この比は分布の形状を測定しており、分布がどこに位置するかではありません。この二つの数値を一緒に読みます：遅い中央値の周りのタイトな尾部は、依然として遅いです。

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

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

調和が取れるのは測定基準の違いです：ページ/分はモデル初期化とスケジューリングを含む壁時計スループットであり、p50は負荷を除いた定常状態の単一ページ推論です。以下の表は、ページ/分が示唆する1ページあたりの平均壁時計時間を変換したもの（60,000 ÷ ページ/分 — 推定値であり、測定値ではありません）であり、p50との差を示しています。PaddleOCRの推定1ページあたり壁時計時間（752.7 ms）は、定常状態のp50（297.0 ms）の2.5倍です。Surya2の（4,940.0 ms）は、p50（2,668.0 ms）の1.9倍です。オーバーヘッド — 初期化、スケジューリング、呼び出しごとのパイプラインコスト — はp50単体では見えないため、p50が低くても自動的にスループットが高いとは限りません。

表: summary_metrics.csv — latency_p50_ms / pages_per_minute、sroie_2019 行。Wall-clock ms/ページは算出値です（60,000 ÷ pages_per_minute、例: 60,000 / 79.7130 = 752.7）— 測定スループットに基づく算術であり、別途測定された数値ではありません。オーバーヘッド = 算出された wall-clock ÷ 測定された p50。ページ/分はモデル初期化を含む wall-clock です。p50 はロードを除く定常状態です。

極端な値に関する2つ目の補足：唯一のCPUエンジンである Tesseract は、SROIE で78.6 ページ/分を維持しています — GPU 上の PaddleOCR の 79.7 とほぼ同等です。p50（670.9 ms、CPU）と wall-clock（763.0 ms）がほぼ同一であるのは、シングルスレッドの CPU エンジンには隠す初期化オーバーヘッドが少ないためです。p95（1,507.0 ms）は p50 の 2.2× — ベンチマーク中最もタイトな分布の一つです。CPU と GPU のスループットの同等性については、Tesseract vs PaddleOCR で詳細に分析しています。

対話型 vs バッチ：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エンジンのみです。

バッチ処理は別の領域であり、エンジンにとって経済性が変わります。モデルの初期化はプロセス/バッチごとに1回だけ行われるため、逐次またはバッチ処理では初期化コストをより多くのページに摊分できます — バッチサイズが増えるにつれて、ページあたりの遅延とページあたりのコストの両方が低下します。これは測定根拠（pages/min には初期化が含まれ、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は108.2 ms p50（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は実時間で課金されるため、レイテンシとコストは同じ指標の二つの側面です：docTRは最も高速なエンジン（p50が108.7 ms）であり、最も安価なエンジンでもあります（SROIEでの1,000ページあたりのコストが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倍です。これは、PaddleOCRの実時間スループットが大幅に低いためです（79.7 vs 124.5 ページ/分；summary_metrics.csvのcost_per_1000_pages / pages_per_minute、sroie_2019行）。完全なコストランキング、コスト計算式、およびその算出根拠は、兄弟ページである1,000ページあたりのOCRコストに記載されています — このページではレイテンシに焦点を当て、相関関係のみを借用しています。

よくある質問

最も高速なOCRエンジンはどれですか？

このベンチマークで最も高速だったのはdocTRです：SROIE 2019で1ページあたり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を使用した場合のOCR遅延の典型的な範囲は？

RTX 4090上で8つのオープンソースエンジンを用いたSROIE 2019レシート（summary_metrics.csv latency_p50_ms、sroie_2019行）での1ページあたりp50遅延は、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エンジンは一度限りのプリミングコストを支払い、遅いサンプルがシリアライズされる可能性があるため、定義上、95パーセンタイルの最も遅い5%のページは中央値から大きく離れています。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遅延とページ/分が一致しないのですか？

これらは異なる測定値だからです。ページ/分はモデルの初期化とスケジューリングを含む壁時計スループットです；p50はモデルロードを除外した定常状態の1ページあたり推論時間です。SROIEでは、PaddleOCRのp50（297.0 ms）は純粋な定常状態で約200ページ/分を示唆しますが、測定されたスループットは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が判断基準となります。

なぜある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の組み合わせに特有のものであり、言語コンテンツとスケジューリングが末尾挙動を変えたもので、中央値だけではありません。

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

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

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

はい、定常状態のフロアに達するまで速くなります。これは測定基準に由来する派生効果であり、新しい実行ではありません。モデル初期化はプロセス/バッチごとに1回のみ発生します（pages/minには含まれますが、p50には含まれません）。したがって、バッチまたは連続処理で初期化コストを分散できます。大量処理では、1ページあたりの壁時計時間は定常状態のp50にスケジューリング時間を加えた値に近づきます。docTRのSROIE数値はすでにそのフロアに近いです（p50 108.7 ms vs 派生壁時計 133.5 ms/ページ）。Surya2の数値（p50 2,668.0 vs 4,940.0 ms）は、分散すべき初期化オーバーヘッドがより大きいことを示しています。

このページのレイテンシ数値はどこから来たものですか？

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

手法と出典

プロトコル

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

ランタイム環境

• ハードウェア：すべてのGPU実行は単一のNVIDIA RTX 4090（24 GB）で行われました。TesseractはCPUのみ（compute_type=cpu）で実行され、すべての表にそのようにラベル付けされています。単一のGPUティア、単一の場所/時間帯 — これがこのページの範囲声明です。
• エンジン：すべてのモデルはデフォルト設定で実行され、ファインチューニングは行われていません。バージョンは実行マニフェストに従って固定されています：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ページあたり推論時間であり、pages/minはモデル初期化を含む壁時計時間です（マニフェスト内のperformance.run_wall_time_msに基づく）。
• 実行ティア：すべての16回の実行はofficialです。ベンチマークプロトコル（reports/receipt_v1_official_protocol.md）によると、公開対象は公式実行のみです。

指標の定義

• p50（中央値レイテンシ）：定常状態における1ページあたりの推論時間の中央値 — 50%のページがこれより速かった。モデルのロード（ウォームしてからスコアリング）は除外。
• p95（テールレイテンシ）：1ページあたりの推論時間の第95パーセンタイル — 5%のページがこれより時間がかかった。この実行プロトコルにおける初ページ/プリフィル効果やバッチスケジューリングの挙動を反映。プロトコル固有のものであり、普遍的なエンジン定数ではない。
• p95/p50比：2つのCSVカラムを割って算出（例：3331.3505 / 296.9897 = 11.22）。テールの形状を示す指標であり、速度の主張ではない。
• ページ/分：モデルの初期化を含む壁時計スループット。バッチジョーブと請求のビュー。
• 壁時計ms/ページ（算出値）：60,000 ÷ pages/min — 計測されたスループットに基づく算術演算。算出された推定値としてラベル付けされており、計測値ではない。

出典一覧

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ラン）に対し、環境フィンガープリント、モデルバージョン、計測モード（warm_then_scored）、壁時計時間、アーティファクトハッシュを含む編集済みmanifest.jsonが1つずつ。
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コスト · 従来のOCR vs ドキュメントパースVLM · docTR vs Surya2: CER同等、コスト差 · docTR vs Docling: シングルパス vs パイプライン · Tesseract vs PaddleOCR: レガシーCPU vs モダンGPU

関連読書: AI OCR vs 従来のOCRの精度 · AI画像データ抽出 vs 従来のOCR · AIドキュメント抽出の価格設定（2026）