1,000ページあたりのOCRコスト
8つのオープンソースエンジン、ベンチマーク結果(2026年)
最終レビュー: 2026-08-18 · ランク: 公式 · 第一者ベンチマーク · 8エンジン × 2レシートデータセット
本ページの対象外: レシート以外のすべてのドキュメントタイプ — 請求書、フォーム、契約書、長文ドキュメントは含まれません。クラウド/API OCRサービス(AWS、Google、Azureおよびその呼び出し単価)、ファインチューニング済みモデル、GPU調達/償却(ハードウェアの直接購入vs時間単位レンタル)、ストレージとデータ転送、およびLLMフィールド抽出のドルコスト(トークン数のみ)は対象外です。8エンジンの精度/レイテンシの包括的な比較は従来のOCR vs ドキュメント解析VLMに掲載されています。
範囲の声明: 本ページのすべてのドル表示は、1つのGPUランク(RTX 4090)で、1つの価格タイムスタンプ(2026年8月、$0.76/hr、ランマニフェストにprice_recorded_at_utc 2026-08-13T08:00:00Zとして記録)に基づいています。予算策定前に現在のレートで再計算してください。レシートデータセットのみ(SROIE 2019, CORD v2)。コスト = 実行時間(ウォールクロック) × 時間単価(モデル初期化を含む)。
同じGPU、同じレシート、同じ$0.76/hrの請求基準で、8つのオープンソースエンジンの1,000ページあたりOCRコストは22.2倍の差があります — SROIE 2019では、$0.0479(docTR)から$1.0609(Surya2)まで。エンジンの選択だけで、オープンソースOCRコストは桁違いに変動し、ランキングはレイテンシに従うものであり、精度ではない: 最もコストの低いエンジン(docTR)は2番目に高い文字誤差率を持ち、最もコストの高いエンジン(Surya2)は最も低い文字誤差率を持っています。
記事で最もよく必要とされる2つの数値: 測定された最もコストの低いエンジン(docTR、449.3ページ/分)の1,000ページあたり$0.048 対、最もコストの高いエンジン(Surya2、12.1ページ/分)の1,000ページあたり$1.061 — 同じテスト分割、同じGPUランク、同じ価格タイムスタンプ。TesseractはCPU専用です: 請求対象のGPU時間を消費せず、ソースCSVのコストセルは設計上空欄です — ゼロではなく、無料でもありません。
1,000ページあたりのコストは、記録された時間単価で1,000ページを処理した場合の請求対象GPU時間です — 実行時間 × $0.76/時間(実行時間にはモデルの初期化時間が含まれます)。このページのコストランキングはすべてこの方法で計算されており、計算の詳細はコストの見積もり方セクションおよび各テーブルの出典行に記載されています。
請求は時間単位で行われるため、コストは精度ではなく時間に連動します:同じ単価で1ページを109msで読むエンジンは、2,668msで読むエンジンより約25倍安価です。バッチサイズが大きくなるにつれて、すべてのエンジンのコストはさらに下がります。これは、一度きりのモデル初期化コストがより多くのページに分散されるためです。以下のコスト数値は、ベンチマークの実行パターン(固定テスト分割、warm_then_scored測定)を反映しており、ご自身の実行コストとは異なる場合があります。
SROIE 2019: 1,000ページあたりのコストランキング
361件の英語レシートでは、従来の2段階OCRエンジンが安価な側、ドキュメント解析VLMが高価な側を占めています。しかし、各ファミリー内のコスト差が注目されます。PaddleOCR-VL(小型の0.9B VLM)は$0.2048で、最安エンジンの4.3倍以内に収まっています。一方、そのVLM兄弟であるSurya2は最安エンジンの22.2倍のコストで、VLMクラスター内だけで5.2倍のコスト差があります。
出典:summary_metrics.csv — cost_per_1000_pages列、sroie_2019行。docTR 0.0479、EasyOCR 0.1098、PaddleOCR-VL 0.2048、PaddleOCR 0.2214、Unlimited-OCR 0.3879、Docling 0.3978、Surya2 1.0609。Tesseract CPU専用:CSVのセルは空(請求対象GPU時間なし)。コスト = 実行時間 × $0.76/時間(RunPod RTX 4090、価格は2026年8月時点)、モデル初期化込み。
| 順位 | モデル | 種類 | コスト / 1Kページ | ページ/分 | 出典 |
|---|---|---|---|---|---|
| 1 | docTR | 従来型OCR (GPU) | $0.0479 | 449.3 | summary_metrics.csv · doctr/sroie_2019 行 |
| 2 | EasyOCR | 従来型OCR (GPU) | $0.1098 | 124.5 | summary_metrics.csv · easyocr/sroie_2019 行 |
| 3 | PaddleOCR-VL | 文書解析VLM | $0.2048 | 68.2 | summary_metrics.csv · paddleocr_vl_vllm/sroie_2019 行 |
| 4 | PaddleOCR | 従来型OCR (GPU) | $0.2214 | 79.7 | summary_metrics.csv · paddleocr/sroie_2019 行 |
| 5 | Unlimited-OCR | 文書解析VLM | $0.3879 | 34.4 | summary_metrics.csv · unlimited_ocr/sroie_2019 行 |
| 6 | Docling | パイプラインパーサー | $0.3978 | 56.7 | summary_metrics.csv · docling/sroie_2019 行 |
| 7 | Surya2 | 文書解析VLM | $1.0609 | 12.1 | summary_metrics.csv · surya2/sroie_2019 行 |
| — | Tesseract | 従来型OCR (CPU) | n/a (CPUのみ、GPU課金なし) | 78.6 | summary_metrics.csv · tesseract/sroie_2019 行 |
表: summary_metrics.csv — cost_per_1000_pages / pages_per_minute、sroie_2019 行(各361サンプル、error_rate 0.0)。GPU実行は$0.76/hr(RTX 4090、価格はマニフェストに記載のタイムスタンプ付き)。TesseractはCPUのみ実行(コストセルは設計上空欄 — 課金GPU時間なし、コストゼロではない)。コストにはモデル初期化が含まれるため、バッチが大きくなると1ページあたりのコストは低下します。
コストはスループットに依存し、精度には依存しない
エンジンをコストと文字精度でランキングすると、両者の順位はほぼ一致しない。SROIEにおける最高の生テキスト品質はSurya2(CER 0.1915)— 最高価格の$1.0609 —であり、次点はdocTR(CER 0.1971)— 最安価の$0.0479 —である。コストは時間の請求である:Surya2の12.1ページ/分は、同じ時間単価でdocTRの449.3ページ/分と比べて約37倍少ないスループットを提供する。
アーキテクチャの重みとの相関は存在するが、緩い。文書解析VLM(Surya2、Unlimited-OCR、PaddleOCR-VL)は従来の2段階OCRエンジン(docTR、EasyOCR、PaddleOCR)より上位に位置し、パイプラインパーサーDoclingはその中間に位置する。しかし、各クラス内ではばらつきが大きい — VLMクラスターは5.2倍($0.2048〜$1.0609)、従来型クラスターは4.6倍($0.0479〜$0.2214)の幅 — であり、実行で最小のVLMである0.9BパラメータのPaddleOCR-VLは最安エンジンの4.3倍以内であるのに対し、Surya2は22.2倍である。実用的な結論:「より正確ならより高価」という仮説は、自社の文書で測定する限りは誤りと仮定すべきである。このベンチマークでは、コスト順位と精度順位の関係は事実上独立している。
出典:summary_metrics.csv — pages_per_minute列、sroie_2019行。モデル初期化を含む実時間ページ/分。TesseractはCPUのみで実行(CPUハードウェアで78.6ページ/分)。
| モデル | タイプ | CER(低いほど良い) | レイテンシ p50(ms) | ページ/分 | コスト / 1Kページ | docTR比コスト | 出典 |
|---|---|---|---|---|---|---|---|
| docTR | 従来のOCR | 0.1971 | 108.7 | 449.3 | $0.0479 | 1.00× | summary_metrics.csv · doctr/sroie_2019 行 |
| EasyOCR | 従来のOCR | 0.2833 | 413.6 | 124.5 | $0.1098 | 2.29× | summary_metrics.csv · easyocr/sroie_2019 行 |
| PaddleOCR | 従来のOCR | 0.2045 | 297.0 | 79.7 | $0.2214 | 4.62× | summary_metrics.csv · paddleocr/sroie_2019 行 |
| Tesseract | 従来のOCR(CPU) | 0.3347 | 670.9 | 78.6 | n/a(CPU) | n/a | summary_metrics.csv · tesseract/sroie_2019 行 |
| PaddleOCR-VL | 文書解析VLM | 0.3370 | 694.3 | 68.2 | $0.2048 | 4.28× | summary_metrics.csv · paddleocr_vl_vllm/sroie_2019 行 |
| Docling | パイプラインパーサー | 0.5909 | 732.0 | 56.7 | $0.3978 | 8.31× | summary_metrics.csv · docling/sroie_2019 行 |
| Unlimited-OCR | 文書解析VLM | 0.6552 | 1,600.7 | 34.4 | $0.3879 | 8.10× | summary_metrics.csv · unlimited_ocr/sroie_2019 行 |
| Surya2 | 文書解析VLM | 0.1915 | 2,668.0 | 12.1 | $1.0609 | 22.16× | summary_metrics.csv · surya2/sroie_2019 行 |
表:summary_metrics.csv — cer / latency_p50_ms / pages_per_minute / cost_per_1000_pages、sroie_2019 行。コスト比は docTR の 0.0479 で単純除算して算出(例:1.0609 / 0.0479 = 22.16)。Surya2 の CER は、方法論の大文字小文字統合に関する注意点を考慮して読む必要がある(VLM 出力は大文字小文字が正規化されるため、CER は VLM の誤差を過大評価する)。Tesseract のレイテンシは CPU ハードウェアに基づく。コスト列は意図的に空欄(GPU 請求なし)。
遅延カラムはインタラクティブワークロードの観点を加えます。ボリュームあたりのコストとページあたりの遅延は、同一の壁時計事実の二つの視点です。docTRのp50が108.7 msであることは、1,000ページあたりのコストが最も安く、インタラクティブな応答に近い唯一のエンジンであることを意味します。Surya2のp50が2,668 msであることは、最も高価であり、レシートではバッチ専用のワークロードであることを意味します。遅延の詳細は、兄弟記事の8エンジン総合比較で分析されています。
CORD(インドネシアのレシート):コストはデータセットに依存
ドキュメントセットを入れ替えるとコストランキングが入れ替わります。これは、1,000ページあたりのコストがエンジン定数ではないことを証明しています。CORD v2では、EasyOCRが最も安価なエンジン($0.0863)となり、docTRは2位に下がります($0.0939)。一方、両端のアンカーは維持されます。docTRは下位に留まり、Surya2は最も高価なままです($1.1616)。CORDのスプレッドは13.5×に縮小します。
そのメカニズムは、実際のドキュメントセットにおけるスループットです。CORDのインドネシアのレシートは、SROIEの英語のものよりも短く、テキスト密度が低いため、すべてのエンジンのページ/分が変化し、1,000ページあたりのコストもそれに従います。このベンチマークでは、2つのデータセットは意図的に分離されています。CORDには、そのグランドトゥルースにアノテーション構造の膨張があり、CERの読み取りを信頼できないものにしています(方法論を参照)。したがって、SROIEとCORDのカラムは、1つのランキングではなく、2つの独立したデータポイントとして扱ってください。
出典:summary_metrics.csv — cost_per_1000_pagesカラム、cord_v2行。EasyOCR 0.0863、docTR 0.0939、Unlimited-OCR 0.2063、PaddleOCR-VL 0.2409、PaddleOCR 0.3419、Docling 0.5382、Surya2 1.1616。Tesseract CPU専用(空セル)。同じRTX 4090 @ $0.76/hr(価格はタイムスタンプ付き)、コストはモデル初期化を含む。
| 順位 | モデル | タイプ | コスト / 1Kページ | 出典 |
|---|---|---|---|---|
| 1 | EasyOCR | 従来型OCR (GPU) | $0.0863 | summary_metrics.csv · easyocr/cord_v2行 |
| 2 | docTR | 従来型OCR (GPU) | $0.0939 | summary_metrics.csv · doctr/cord_v2行 |
| 3 | Unlimited-OCR | 文書解析VLM | $0.2063 | summary_metrics.csv · unlimited_ocr/cord_v2行 |
| 4 | PaddleOCR-VL | 文書解析VLM | $0.2409 | summary_metrics.csv · paddleocr_vl_vllm/cord_v2行 |
| 5 | PaddleOCR | 従来型OCR (GPU) | $0.3419 | summary_metrics.csv · paddleocr/cord_v2行 |
| 6 | Docling | パイプラインパーサー | $0.5382 | summary_metrics.csv · docling/cord_v2行 |
| 7 | Surya2 | 文書解析VLM | $1.1616 | summary_metrics.csv · surya2/cord_v2行 |
| — | Tesseract | 従来型OCR (CPU) | n/a (CPUのみ、GPU課金なし) | summary_metrics.csv · tesseract/cord_v2行 |
表: summary_metrics.csv — cost_per_1000_pages、cord_v2行(各100サンプル)。CORDはSROIEランキングとは別に扱われています(言語が異なり、正解データの構造も異なるため)。この比較のポイントは、1,000ページあたりのコストが文書セットによって変動することであり、いずれかのランキングが「勝つ」ことではありません。
月間ボリュームシナリオ(推定値)
1,000ページあたりのコストは、予算担当者が必要とするボリューム計算に直接反映されます。SROIEのコスト基準で月間100,000ページの場合、docTRのGPU時間は月$4.79、Surya2は月$106.09です。この差額は約月$101で、100万ページでは約月$1,013に拡大します。これらは測定された1,000ページあたりの数値を単純に掛けたものであり、追加の実行ではありません。
| 月間ボリューム | docTR GPU時間(算出) | Surya2 GPU時間(算出) | 差額 | 根拠 |
|---|---|---|---|---|
| 10,000ページ | $0.48 (10 × $0.0479) | $10.61 (10 × $1.0609) | $10.13 | summary_metrics.csv の cost_per_1000_pages、docTR / surya2 sroie_2019行;単純な乗算による推定 — 実測値ではありません |
| 100,000ページ | $4.79 (100 × $0.0479) | $106.09 (100 × $1.0609) | $101.30 | |
| 1,000,000ページ | $47.88 (1,000 × $0.0479) | $1,060.85 (1,000 × $1.0609) | $1,012.97 |
表:SROIE 2019コスト基準に基づく推定値 — 実測値ではありません。各セルは、測定された cost_per_1000_pages(docTR 0.0479、Surya2 1.0609;summary_metrics.csv sroie_2019行)を、同じRTX 4090の$0.76/時間のレート(価格は2026年8月時点)で、ボリューム(千単位)を掛けて算出しています。GPU時間のみで、CPU、ストレージ、データ転送、オーケストレーション、LLM後処理は含まれません。月間1,000万ページでは、この基準でSurya2単体で約月$10,609に達します(10,000 × $1.0609)。
Tesseractの実際のコストプロファイル:GPU費用なし、しかし無料ではない
Tesseractはベンチマークで唯一のCPU専用エンジンであり、コストセルは設計上空欄です。課金GPU時間を消費しないため、$0.76/hrで課金するものはありません。これはコストゼロと同じではありません。実行するCPUインフラ(自社ハードウェアまたはレンタルCPUインスタンス)は、このベンチマークで定量化されていない実際のコストであり、フィールド回復の上限は下游でコスト増加を引き起こす可能性があります。
SROIEでは、TesseractはCPU上で78.6ページ/分を維持しました。これは7つのGPUエンジンのうち4つ(PaddleOCR-VL 68.2、Docling 56.7、Unlimited-OCR 34.4、Surya2 12.1)より高いです。既にプロビジョニングされたCPUインフラで低ボリュームの場合、これは本物のコスト効率を実現します。GPUレンタルがまったく不要だからです。問題は、テキストだけでなくフィールドが成果物となる場合に現れます。Tesseractの弱いベーステキストは、下游のLLMが回復できるものを制限します。CORD LLMフィールドF1は、CORD CERが0.9523の条件下で0.163です(field_method_comparison.csv、tesseract/cord_v2行)。したがって、GPUの節約分は、他の場所での後処理や修正コストで相殺される可能性があります。CPU対GPUのトレードオフは、専用のTesseract vs PaddleOCRのヘッドトゥーヘッドのテーマです。後処理の上限については、Regex vs LLM Field Extractionで説明しています。
パイプラインコスト ≠ エンジンコスト:LLM後処理の境界
このページのすべての数値は、OCRエンジンのGPU費用のみを示しています。本番の抽出パイプラインでは、OCRテキストの上にLLMフィールド抽出パスを追加するのが一般的です。ベンチマークでは、16回すべての実行で1つ(deepseek-v4-flash)を実行しました。このパスは別個の、トークン単位のAPIコストであり、ここにあるエンジンの数値には含まれていません。
比較CSVには、SROIEでの後処理パスのトークン数が記録されています。例えば、docTRのOCRテキストは、4つのレシートフィールドを抽出するために151,131プロンプト + 25,377完了トークンを消費しました。これらのトークン数は、追加コストの推定基盤です。このページでは、意図的にトークンをドルに換算していません。LLMの価格はプロバイダー、プラン、モデルによって異なり、いかなるドル額もすぐに古くなります。エンジンコストとパイプラインコストは予算の2行です。LLMの行は、OCRエンジンではなく、あなたのプロンプト設計とプロバイダーの関数です。
| エンジン(OCRテキストソース) | LLMプロンプトトークン(SROIE) | LLM補完トークン(SROIE) | ソース |
|---|---|---|---|
| Tesseract | 128,285 | 24,561 | field_method_comparison.csv · tesseract/sroie_2019 行 |
| PaddleOCR | 134,746 | 26,059 | field_method_comparison.csv · paddleocr/sroie_2019 行 |
| EasyOCR | 138,689 | 25,607 | field_method_comparison.csv · easyocr/sroie_2019 行 |
| docTR | 151,131 | 25,377 | field_method_comparison.csv · doctr/sroie_2019 行 |
| Surya2 | 130,262 | 26,372 | field_method_comparison.csv · surya2/sroie_2019 行 |
| Docling | 157,191 | 26,087 | field_method_comparison.csv · docling/sroie_2019 行 |
| Unlimited-OCR | 185,705 | 25,876 | field_method_comparison.csv · unlimited_ocr/sroie_2019 行 |
| PaddleOCR-VL | 148,973 | 26,301 | field_method_comparison.csv · paddleocr_vl_vllm/sroie_2019 行 |
表: field_method_comparison.csv — llm_prompt_tokens / llm_completion_tokens、sroie_2019 行; llm_model = deepseek-v4-flash。トークン数は、361ページのSROIEテスト分割に対して、4つのレシートフィールドの抽出パス1回分をカバーしています。これらはLLM後処理コストの見積もりの基礎となります。LLMの料金はプロバイダやプランによって異なるため、ドル換算は記載していません。
コストの見積もり方
独自のワークロードに対する信頼性のあるコスト見積もりを得るために、8エンジンのベンチマークを再実行する必要はありません。ベンチマークの方法(壁時計時間 × 時給)は、4つのステップと1つの計算例で再現できます。
- エンジンとその測定スループットを選択します。 同じドキュメントタイプのプロキシとして「ページ/分」の列を使用します(例:docTR 449.3、Surya2 12.1ページ/分、SROIEデータセット;summary_metrics.csvのsroie_2019行)。独自のドキュメント構成については、小さなサンプルで独自のスループットを測定してください。上記のランキングは、1,000ページあたりのコストがデータセットに依存することを示しています。
- 処理量を壁時計時間に変換します。 Nページの場合、
hours = (model init + N / pages_per_minute) / 60と計算します。モデルの初期化はプロセス/バッチごとに1回のみ発生するため、分子に含める必要があります。 - 時給を掛けて計算します。
cost = hours × rate。ベンチマークで使用した時給は$0.76/hr(RunPod RTX 4090、2026年8月時点の価格)でした。ベンチマーク自体の計算例: docTRのSROIE実行は、361ページに対して壁時計81,867 ms(マニフェストのperformance.run_wall_time_ms)→ 0.0227時間 × $0.76 = $0.0173(実行コスト)→ × 1,000 / 361 = $0.0479(1,000ページあたり)。CSVの行と完全に一致します。 - 初期化コストの均摊とバッチサイズを考慮します。 上記の81,867 msには、361ページバッチの初期化が含まれています。1,000,000ページの場合、同じ初期化コストは約2,770倍に薄められ、ページあたりのコストは純粋な定常状態スループットに近づきます。小さなバッチでは初期化コストを繰り返し支払うため、10ページバッチは10,000ページ実行と同じ初期化コストを負担し、1,000ページあたりのコストは小さなバッチサイズで急激に上昇します。ワークロードがバースト的な場合は、バッチサイズを大きくするか、初期化コストの高い経済性を受け入れてください。
- パイプラインコストは別途追加します。 LLMフィールド抽出はトークン単位で課金され(比較CSVのトークン数)、ストレージと送信はバイト単位で課金され、TesseractのようなCPU専用スタックはCPU時間で課金されます。これらは、このページの1,000ページあたりのコストに含まれていません。
これは、ベンチマーク自体のコスト基盤(壁時計時間 × 時給、モデル初期化を含む)から導き出した概算方法です。財務アドバイスではなく、正確な数値はハードウェア、ドキュメント構成、バッチサイズ、稼働率によって異なります。$0.76/hrの料金は、2026年8月時点のオンデマンド価格です。現在の料金で再計算してください。
よくある質問
1,000ページあたりのOCRコストはいくらですか?
SROIE 2019では、1,000ページあたり$0.048(docTR)から$1.061(Surya2)です。RTX 4090で$0.76/hr、価格は2026年8月時点の測定です(summary_metrics.csv cost_per_1000_pages、sroie_2019行)。コストにはモデル初期化が含まれるため、バッチサイズが大きくなると1ページあたりのコストは下がります。CORD v2では、同じエンジンで$0.086(EasyOCR)から$1.162(Surya2)の範囲です。
最もコストの低いオープンソースOCRエンジンはどれですか?
docTRがSROIEで1,000ページあたり$0.0479(449.3ページ/分、summary_metrics.csv doctr/sroie_2019行)と、測定されたGPUエンジンの中で最もコストが低いものでした。ただし、データセット依存性という注意点があります:CORD v2では、EasyOCR($0.0863)がdocTR($0.0939)をわずかに上回りました。「最も安い」答えは、使用するドキュメントセットによって異なります。両データセットで、docTR(低め)とSurya2(高め)という基準は維持されました。
なぜ最も高速なエンジンが最も安いのですか?
請求が$0.76/hrの壁時計時間(wall-clock hours)ベースであるためです。1ページを109msで処理するエンジン(docTR)は、2,668msのエンジン(Surya2)の約1/25の時間で済みます(summary_metrics.csv latency_p50_ms / cost_per_1000_pages、sroie_2019行)。従量制GPU課金の下では、スループットがコストに直結します。そのため、コストランキングとスループットランキングはほぼ鏡像の関係になります。
Tesseract OCRは無料ですか?
いいえ。TesseractはCPU専用であるため、課金されるGPU時間は消費せず、ベンチマークCSVのコスト欄は設計上空欄ですが、これはゼロではありません。実行されるCPUインフラには実際のコストがかかり、フィールド復元の上限(CORD LLMフィールドF1 0.163、field_method_comparison.csv tesseract/cord_v2行)により、下流の後処理にコストがかかる可能性があります。既にプロビジョニングされたCPUハードウェアで少量を処理する場合には、実際にコスト効率が良い場合があります。SROIEで78.6ページ/分と、7つのGPUエンジンの4つより高速です。しかし、「GPU請求がない」と「無料」は別物です。
なぜSurya2は1,000ページあたりのコストがこれほど高いのですか?
ベンチマークで最も遅いエンジンだからです:SROIEで12.1ページ/分という速度は、同じ$0.76/時のレートで、1,000ページあたりの実行時間が最も長くなることを意味します(summary_metrics.csvのpages_per_minute / cost_per_1000_pages、surya2/sroie_2019行)。特筆すべきは、最も高い文字精度(CER 0.1915)も持っている点です。これは、コストが精度ではなく時間に依存するという、ベンチマークにおける最も明確な例です。
OCRの1ページあたりのコストは、処理量が増えると下がりますか?
はい、下限があります。ここでのコストにはモデルの初期化コストが含まれており、これはプロセス/バッチごとに1回だけ発生します。ベンチマークのdocTRの実行では、361ページに対して81,867ミリ秒の初期化が行われました(manifest performance.run_wall_time_ms)。したがって、100万ページではこの初期化コストはほぼゼロに希釈され、コストは純粋な定常状態のスループットに近づきます。下限はその定常状態コストそのものです。docTRのSROIEにおける$0.0479/1Kはすでにその下限に近いです。一方、Surya2の$1.0609は、初期化オーバーヘッドだけでなく、本当に遅い定常状態の推論を反映しています。
これらの1,000ページあたりの数値に含まれていないものは何ですか?
LLMの後処理(別途トークン単位のAPIコスト;トークン数はfield_method_comparison.csvに記載)、Tesseractスタイルのスタックに必要なCPU/インフラ、ストレージとデータ転送、オーケストレーション、GPUの稼働率のギャップ、クラウド/API OCRサービスです。これらはすべて、これらの数値が表すエンジンのGPUコストには含まれていません。クラウドAPIは機能に応じた価格設定で呼び出し単位で課金されるため、レンタルGPUの実行時間とは異なるコストモデルです。これらはこのページではベンチマーク対象外です。
これらの数値はどこから来たものですか?
すべての数値は、一次ベンチマークで公開されているCSVの1行です。results/summary_metrics.csv(1,000ページあたりのコスト、スループット、レイテンシ、精度)とresults/field_method_comparison.csv(LLM後処理のトークン数とフィールドF1)は、ImageToTableai/benchmark-ocrで公開されています。各実行には、$0.76/時のレート、2026年8月の価格タイムスタンプ、モデルバージョン、環境ハッシュを記録したmanifest.jsonが1つあります。
方法と情報源
プロトコル
このページは、独立した再現可能なベンチマーク実行(公式ティア)のコスト次元を報告するものであり、第三者の主張を調査したものではありません。固定テスト分割のみを使用しています:SROIE 2019 テスト(361件の英語レシート、会社名/日付/住所/合計のフラットフィールド)とCORD v2 テスト(100件のインドネシア語レシート、メニュー/小計/合計のネストされたフィールド);訓練分割は評価対象外です。すべての(エンジン × データセット)ペアは、同じ画像、同じ正解データ、同じ測定プロトコル(warm_then_scored:スコアリングパスの前に固定ウォームアップパスを実行)を使用しました。すべての16回の実行がエラー率0.0(summary_metrics.csvのerror_rate列)で完了しました。
ランタイム環境とコスト基準
- ハードウェア:すべてのGPU実行はNVIDIA RTX 4090(24 GB)で実行。GPUコストはRunPodのオンデマンドレート$0.76/hrで計算。価格のタイムスタンプ(
price_recorded_at_utc 2026-08-13T08:00:00Z)は各実行のマニフェストに記録。TesseractはCPUのみで実行し、GPUコストはありません(CSVのコストセルは空です。これは意図的なものであり、ゼロではありません)。 - コスト計算式:1,000ページあたりのコスト = 実行時間 × $0.76/hr ×、モデル初期化を含む。コスト見積もり方法セクションのdocTRの計算例で検証済み(81,867 ms → $0.0479/1K)。
- エンジン:すべてのモデルはデフォルト設定で実行、ファインチューニングなし。バージョンは実行マニフェストに固定(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)。
- LLM後処理:API経由のdeepseek-v4-flash(温度0、field_method_comparison.csvのllm_model列)。トークン数は別途パイプラインコストの根拠として報告。OCRエンジンコストには含まれません。
- フィールド後処理:SROIEのフィールド指標は
postprocessed_sroie_receipt_regex_*/ LLMバリアントです。OCRテキストから抽出されたフィールドであり、ネイティブ構造化出力ではありません。 - CORDに関する注意:CORDの正解テキストにはアノテーション構造が埋め込まれており、すべてのエンジンの生CERを過大評価させます。したがって、CORDの行はSROIEのランキングから分離されています。コスト数値(実行時間ベース)はCERの注意事項の影響を受けませんが、両データセットともレシートのみです。
指標の定義
- 1,000ページあたりのコスト: 記録された$0.76/hrのレートで、モデルの初期化時間を含むウォールクロック時間で1,000ページを処理した場合の請求GPU時間。CPUのみのTesseractは空欄。
- 1分あたりのページ数: モデルの初期化時間を含むウォールクロックスループット。
- レイテンシ p50/p95: 安定状態の1ページあたりの推論時間(ウォームアップ後にスコアリング、モデルのロード時間を除く)。
- CER/WER: 正解テキストの文字/単語に対する編集距離(挿入 + 削除 + 置換)。大文字小文字や表記規則に敏感です — VLMの出力は大文字小文字が正規化されるため、CERはVLMの誤差を過大評価します(まとめページを参照)。
- フィールド値F1: 抽出されたフィールド値に対する適合率/再現率の調和平均(正規表現またはLLMによる後処理ごと)。
出典一覧
- summary_metrics.csv (GitHub raw)。16行 = 8エンジン × 2レシートデータセット(sroie_2019, cord_v2)。列:model, compute_type, dataset, cer, wer, field_f1_regex, field_acc_regex, latency_p50_ms, latency_p95_ms, cost_per_1000_pages, pages_per_minute, error_rate。このページのすべてのコスト、スループット、レイテンシ、CERの数値は、このファイルの行に由来します。
- field_method_comparison.csv (GitHub raw)。16行;列 model, dataset, llm_model (= deepseek-v4-flash), regex/LLM field-value accuracy and F1, document-fields-exact, llm_median_latency_ms, llm_prompt_tokens, llm_completion_tokens。すべてのトークン数とLLMフィールドF1の数値は、このファイルの行に由来します。
- ImageToTableai/benchmark-ocr リポジトリ。結果CSV、編集済みランマニフェスト、固定されたプロトコル、および再現用のデータセットサンプルリスト(固定テスト分割)を公開しているパブリックリポジトリ。
- results/manifests/ (GitHub)。公開された各ラン(16ラン)に対し、環境フィンガープリント、モデルバージョン、コストメタデータ(
gpu_hourly_usd、price_recorded_at_utc)、ウォールクロック時間、アーティファクトハッシュを含む編集済みmanifest.json。 - Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019)。SROIE 2019データセットの定義、タスク構造、ライセンス(CC-BY-4.0)。
- 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($0.76/hr)によるものです。GPUスポット/オンデマンド価格は変動します — 現在のレートで再計算してください。他のGPU、マルチGPUサーバリング、バッチスケジューリングはスループストとコストを変動させます。
- レシートのみ: SROIE(英語)およびCORD(インドネシア語)レシートです。請求書、フォーム、契約書、または長文ドキュメントのコスト、スループスト、精度は未測定です。上記のランキングはレシート以外には一般化できません。
- コストにはモデル初期化が含まれる — バッチサイズ依存: 数値はベンチマークの実行パターン(361/100ページ固定分割、ウォームアップ後スコアリング)を反映しています。より小さなバッチは初期化を繰り返し、1,000ページあたりのコストが高くなります。より大きなバッチは定常状態のフロアに近づきます。
- CPU/GPU非対称性: Tesseract(CPU)はGPU加速エンジンと比較されています。そのコスト優位性は、GPU課金がゼロであることによるものであり、コストがゼロであることを意味しません — CPUインフラ、電力、スタッフ時間は定量化されておらず、フィールド復元の上限(CORD LLM フィールドF1 0.163)はコストを後処理にシフトさせる可能性があります。
- クラウド/APIモデルは未対象: AWS Textract、Google Document AI、Azure AI Document Intelligence、およびホスト型OCR/VLM APIは含まれていません。それらのコール単位、機能単位の価格設定は、レンタルGPUのウォールクロック課金とは根本的に異なり、比較を意図したものではありません。
- 稼働率とアイドル時間は未モデル化: 数値は、GPUが実行のウォールクロックに対して課金され、それ以外は未使用であることを前提としています。アイドル、マルチテナント、または低稼働率のGPUを含む実際のデプロイメントでは、有効コストは異なります。
- LLM後処理コストはドルに変換されていません: トークン数(field_method_comparison.csv)が基礎です。LLMの価格設定はプロバイダとプランによって異なり、意図的に読者に委ねられています。
- 導出シナリオは未測定: 月間ボリューム表は、SROIEコストベースの単純な算術であり、導出された推定値としてラベル付けされています — 追加のベンチマーク実行ではありません。
- サンプルサイズとバージョン固定: 361 + 100サンプル。結果は、上記に記載された2026年8月のモデルバージョンに有効です。新しいエンジンリリースはコスト/スループストを変動させる可能性があります。一桁パーセントの差はノイズとして扱うべきです。
関連リファレンス: Traditional OCR vs Document Parsing VLMs · docTR vs Surya2: CER Tie, Cost Gap · Tesseract vs PaddleOCR: CPU Cost Profile · Regex vs LLM Field Extraction · Document Processing Cost Breakdown
関連読書: AI Document Extraction Pricing (2026) · AI OCR vs Traditional OCR Accuracy · AI Image Data Extraction vs Traditional OCR