高ボリュームの画像およびPDF処理のためのTurbo-OCR

Reddit r/LocalLLaMA / 2026/4/9

💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsTools & Practical Usage

要点

  • この記事は、約94万枚のPDFに対してOCRを行う際の性能ボトルネックについて述べており、PaddleOCRのような一般的な選択肢でも強力なGPUを搭載しているにもかかわらず、約15枚/秒程度に制限されていたことを指摘しています。
  • GPUの低い利用率と、PaddleOCRにおけるPythonおよびシングルストリームのボトルネックによって効率的なスループットが得られなかったことを説明しています。一方で、vLLMを用いたVLMベースのOCRアプローチでは、高コストにもかかわらず約2枚/秒程度にとどまりました。
  • 提案されている解決策は、TensorRTのFP16でPP-OCRv5-mobileをラップするカスタムのC++/CUDA推論サーバーで、マルチストリーム並行処理と、GPU利用率を最大化するためのgRPC/HTTPによる提供を行う点です。
  • 報告されているベンチマークではスループットが大幅に改善され、文字量の多いページで100枚/秒超、文字の少ないスパースなページで1,000枚/秒超を達成し、GPU利用率は約15%から約99%へ上昇しました。
  • トレードオフとして、レイアウト/表の忠実度は低下します(複雑な読順や表抽出は行わない)。著者は、レイアウト精度が必要な場合の代替として、GLM-OCRやPaddle-VLのようなVLM OCRの利用を推奨しています。

最近、約94万枚のPDFを処理する必要がありました。標準的なOCRツールから始めましたが、ボトルネックになっていてストレスでした。RTX 5090でさえ、速度が低いままでした。

問題:

  • PaddleOCR(最も人気のあるオープンソースOCR): 最大でも約15 img/s。GPU利用率は15%前後で推移していました。高性能推論モードはまだBlackwell GPUをサポートしていません(CUDA < 12.8が必要)し、ラテン認識モデルでも動作しません。
  • VLM OCR(vLLM経由): 精度は素晴らしいのですが、最大2 img/sまでしか伸びませんでした。100万ページ規模では、時間とコストが厳しすぎました。

解決策: C++/CUDA推論サーバー

PaddleOCRはPythonのオーバーヘッドとシングルストリーム実行でボトルネックになるため、GPUがほとんど使われていませんでした。対策は、TensorRT FP16とマルチストリームの並行性を備えたPP-OCRv5-mobileモデルをベースにしたC++サーバーを用意し、gRPC/HTTPで提供することでした。GPU利用率は15%から99%へ上がり、PaddleOCR自身のライブラリを使う場合と比べてスループットを大幅に引き上げました。Claude Code と Gemini CLI がほとんどのコーディングを担当しました。ベンチマーク(Linux / RTX 5090 / CUDA 13.1)

  • テキスト量が多いページ: 100+ img/s
  • テキストが少ない/疎なページ: 1,000+ img/s

トレードオフ

  1. 精度 vs. スピード: これは、レイアウト精度を生の速度のために犠牲にします。マルチカラムの読み順や複雑な表の抽出はできません。それが必要なら、GLM-OCRやPaddle-VL、あるいは他のVLMベースOCRの方が良い選択肢です。

興味がある方へ: github.com/aiptimizer/turbo-ocr

submitted by /u/Civil-Image5411
[link] [comments]