PaddleOCR-VL：バージョン、導入、サービング、ベンチマーク

PaddleOCR-VL とは#

PaddleOCR-VL は単一のモデルではなく、2 段階のパイプラインです。¹第 1 段階はレイアウトモデルで、ページ上のすべての要素（段落、見出し、表、数式、グラフ、印影）を検出し、読み順に並べて切り出します。第 2 段階は小型の視覚言語モデルで、切り出した各領域を読み取り、Markdown、HTML の表、LaTeX、またはグラフのデータ表を出力します。最後にパイプラインが、それらを読み順どおりに組み立て直します。

VLM コンポーネントは、NaViT 型の動的解像度ビジュアルエンコーダーと ERNIE-4.5-0.3B 言語モデルを組み合わせたものです。¹Hugging Face の API は 3 つのリリースすべてについて 958,588,736 パラメータ（BF16 safetensors）と報告しており、v1、1.5、1.6 は同じアーキテクチャです。⁴PaddleOCR-VL-1.6-0.9B のような名前の「0.9B」はこの VLM コンポーネントだけを指し、別のモデルサイズを意味するものではありません。¹

PaddleOCR-VL と PP-StructureV3 のどちらを選ぶか#

どちらも文書を Markdown と JSON に変換でき、どちらも paddleocr[doc-parser] に含まれています。README では、表のセルやテキスト行の座標など、より細かい座標が必要な場合は PP-StructureV3 を選ぶよう位置づけています。VL シリーズはこうした座標を返しません。⁵精度を重視するなら PaddleOCR-VL です。OmniDocBench v1.5 の表では、PaddleOCR-VL-1.5 が 94.50、PP-StructureV3 が 86.73 です。⁷PP-StructureV3 は CPU でも快適に動きますが、PaddleOCR-VL は GPU 向けに設計されています。

バージョン：v1、1.5、1.6#

1. 2025年10月16日PaddleOCR-VL（v1）が PaddleOCR 3.3.0 とともに公開。109 言語に対応し、テキスト、表、数式、グラフを扱えます。arXiv 2510.14528。⁵⁴
2. 2025年10月29日Hugging Face Transformers に対応。⁴
3. 2025年11月4日vLLM が公式に対応。⁴
4. 2026年1月29日PaddleOCR-VL-1.5が PaddleOCR 3.4.0 とともに公開。多角形の枠を出力する新しいレイアウトモデル PP-DocLayoutV3、印影認識、テキストスポッティング、ページをまたぐ表の結合、見出しレベルに対応し、チベット語とベンガル語を追加。arXiv 2601.21957。¹⁵
5. 2026年3月6日1.5 が llama.cpp（GGUF）に対応。⁴
6. 2026年5月28日PaddleOCR-VL-1.6が PaddleOCR 3.6.0 とともに公開。アーキテクチャは 1.5 と同じで、Baidu によれば古文書、まれな文字、印影、スポッティング、グラフの結果が改善しています。技術レポート arXiv 2606.03264 は 6月3日に公開されました。¹⁹
7. 2026年7月22日高スループット向けの別の文書解析モデル HPD-Parsing が発表されました（後述）。⁵

レイアウトモデルとコンポーネント名は PaddleX 3.7.2 のパイプライン設定によるものです。³VLM はタスクプロンプトを理解します。v1 は OCR:、Table Recognition:、Formula Recognition:、Chart Recognition: に対応し、1.5 と 1.6 では Spotting: と Seal Recognition: が加わりました。⁴PP-DocLayoutV2 と V3 は同じ 25 種類のラベルを持ち、その中には display_formula、inline_formula、vertical_text、seal、chart が含まれます。¹⁵V3 は多角形の枠と読み順を 1 回の順伝播で予測します。V3 自身のモデルカードによれば、GLM-OCR でも使われています。¹⁵

ベンチマーク：PaddleOCR-VL の位置づけ#

文書解析ツールで最もよく引用されるベンチマークは、OpenDataLab が公開している OmniDocBench です。OpenDataLab は、同じ表に載っている MinerU の開発チームでもあります。下のリーダーボードは Baidu のものではなく、OmniDocBench 自身の README に掲載されたもので、各行は公開されたとおりに転記しています。⁶この表の「Overall」は 1,651 ページに対する ((1 − TextEdit) × 100 + TableTEDS + FormulaCDM) / 3 です。⁶

上位 10 の中で、PaddleOCR-VL-1.6 は数式のスコアが最も高く（CDM 97.53）、表では TeleOCR、テキストの編集距離では OvisOCR2 がトップです。⁶参考までに、同じ表では Gemini 3 Pro が 92.91、dots.ocr が 90.77、GPT-5.2 が 86.59、MinerU のパイプラインが 86.47 です。GPT-4o と PP-StructureV3 はこの表に載っていません。⁶1,651 ページのベンチマークでの 1〜2 ポイントの差は、あなたの文書での結果をほとんど示さない点に注意してください。必ず自分の文書のサンプルで試してください。

バージョンごとにどれだけ改善したか#

Real5-OmniDocBench での v1 から 1.5 への大きな伸びは、難しいケースによるものです。傾いたページは 77.47 から 91.66 に、画面撮影は 82.54 から 91.76 に上がっており、PP-DocLayoutV3 で多角形のレイアウト枠に切り替えたことと符合します。⁸これらは開発元の数値として扱ってください。第三者の表では伸びは小さく、v1 から 1.5 で +0.75、1.5 から 1.6 で +1.41 です。⁶

ハードウェア要件#

NVIDIA GPU では、どのエンジンで VLM を動かすかによって要件が変わります。¹

• T4 と V100（CC 7.x）では vLLM を起動できますが、ドキュメントでは "prone to timeouts or OOM"（タイムアウトや OOM が起きやすい）として推奨していません。これらのカードでは PaddlePaddle エンジンを使ってください。¹
• RTX 30/40/50 と A10/A100 は CC 8 以上なので、すべてのバックエンドの要件を満たします。ただし RTX 50（Blackwell、CC 12）は SGLang と FastDeploy の対象範囲外です。Blackwell には専用のガイドがあり、CUDA 12.9+ に対応したドライバーと -sm120 のイメージが必要です。¹¹
• VRAM：最低要件はリポジトリのどこにも記載されていません。メモリに関する唯一の記述は NVIDIA RTX 3060 向けのチューニングのヒントで、vLLM または FastDeploy で gpu-memory-utilization: 0.7 を設定するというものです。¹
• x64 CPU：対応表では x64 CPU での PaddlePaddle によるローカル推論が「対応」とされていますが、MCP サーバーのドキュメントは VL シリーズについて "CPU inference is not recommended"（CPU 推論は推奨しない）としています。¹¹⁶私たちは速度を測っていません。

推論方式ごとの対応デバイス#

「+ サーバー」の行は、レイアウト解析をクライアント側の PaddlePaddle で、VLM を指定したサーバーで実行する構成です。「対応中」は、ドキュメントで作業中または未検証とされているものです。公式の対応表には Kunlunxin、Hygon、MetaX、Iluvatar、Intel Arc も含まれます（後述）。vLLM、SGLang、FastDeploy は Windows ではネイティブに動かないため、Windows では Docker を使ってください。¹

インストール#

VL のガイドでは PaddlePaddle 3.2.1 以降と Python 3.9〜3.13 を求めており、仮想環境の利用を推奨しています。CPU 版と GPU 版の PaddlePaddle を同じ環境に入れないでください。¹

python -m venv .venv_paddleocr && source .venv_paddleocr/bin/activate
python -m pip install paddlepaddle-gpu==3.2.1 -i https://www.paddlepaddle.org.cn/packages/stable/cu126/
python -m pip install -U "paddleocr[doc-parser]"

python -m venv .venv_paddleocr && source .venv_paddleocr/bin/activate
python -m pip install paddlepaddle==3.2.1 -i https://www.paddlepaddle.org.cn/packages/stable/cpu/
python -m pip install -U "paddleocr[doc-parser]"

# ~8 GB image with PaddlePaddle preinstalled; needs a driver for CUDA 12.6+
docker run -it --gpus all --network host --user root \
  ccr-2vdh3abv-pub.cnc.bj.baidubce.com/paddlepaddle/paddleocr-vl:latest-nvidia-gpu \
  /bin/bash
# then run the paddleocr CLI or Python inside the container
# offline variant (~10 GB): ...:latest-nvidia-gpu-offline

私たち自身のテストから、バージョンに関する注意点が 2 つあります。PyPI の素の paddlepaddle（執筆時点で 3.3.1）では、CPU での PP-OCRv6 の推論が ConvertPirAttribute2RuntimeAttribute エラーでクラッシュしました。ガイドが指定するバージョンをそのまま固定しているのはこのためです。また、A dependency error occurred during pipeline creation と表示される場合は、[doc-parser] extra なしで paddleocr をインストールしています。どちらもエラー解決ガイドに載っています。OS と CUDA の組み合わせの全体はインストールガイドをご覧ください。

Python と CLI での使い方#

from paddleocr import PaddleOCRVL

pipeline = PaddleOCRVL()          # loads v1.6 by default
# pipeline = PaddleOCRVL(pipeline_version="v1.5")
# pipeline = PaddleOCRVL(engine="transformers")
# pipeline = PaddleOCRVL(device="cpu")   # Apple Silicon

for res in pipeline.predict("paper.png"):
    res.print()
    res.save_to_json(save_path="output")
    res.save_to_markdown(save_path="output")
    res.save_to_word(save_path="output")   # .docx

paddleocr doc_parser -i paper.png --save_path ./output

# pick a release, or switch engine
paddleocr doc_parser -i paper.png --pipeline_version v1.5 --save_path ./output
paddleocr doc_parser -i paper.png --engine transformers --save_path ./output

# fix rotated or curved pages first
paddleocr doc_parser -i photo.jpg --use_doc_orientation_classify True --use_doc_unwarping True

pipeline_version が受け付けるのは "v1"、"v1.5"、"v1.6" の 3 つだけで、それぞれ PaddleX のパイプライン PaddleOCR-VL、PaddleOCR-VL-1.5、PaddleOCR-VL-1.6 に対応します。²各結果は PP-StructureV3 と同じ形の parsing_res_list（block_label、block_content、block_bbox、block_order）を持ち、保存メソッドとして save_to_json、save_to_markdown、save_to_html、save_to_xlsx、save_to_word、save_to_img があります。¹

複数ページの PDF：restructure_pages()#

PDF では 1 ページにつき 1 つの結果が返ります。ページをまたぐ表の結合、文書全体での見出しレベルの再構成、すべてを 1 つの結果にまとめる処理を行うには、ページのリストを restructure_pages() に渡します。¹

from paddleocr import PaddleOCRVL

pipeline = PaddleOCRVL()
pages = list(pipeline.predict("report.pdf"))

# merge_tables and relevel_titles already default to True in the code
merged = pipeline.restructure_pages(pages, concatenate_pages=True)

for res in merged:        # one result with concatenate_pages=True
    res.save_to_markdown(save_path="output")

PaddleOCR 3.7.0 でのシグネチャは restructure_pages(res_list, merge_tables=True, relevel_titles=True, concatenate_pages=False) で、戻り値はリストです。²公式の例では merge_tables=True, relevel_titles=True を明示的に渡しているため、既定ではオフのように見えますが、実際はオンです。有効にする必要があるのは concatenate_pages だけです。PP-StructureV3 にあるのと同じ、よりシンプルな concatenate_markdown_pages(markdown_list) ヘルパーも用意されています。

実際によく使うパラメータ#

vl_rec_* の設定はコンストラクタに渡します。それ以外はコンストラクタでも、predict() の呼び出しごとにも指定できますが、prompt_label、layout_shape_mode、サンプリング設定は predict() でのみ指定できます。既定値は使い方ドキュメントと 3.7.0 のソースによるものです。prompt_label の値は PaddleX 3.7.2 のコードによるもので、エラーメッセージには 4 つしか挙がっていませんが、実際には 6 つのラベルを受け付けます。¹²³食い違いが 1 つあります。ドキュメントでは layout_threshold の既定値を 0.5 としていますが、PaddleX の設定ファイルでは 1.5 と 1.6 で 0.3、v1 ではクラスごとに 0.4〜0.5 です。³パイプラインが実際に使う値を確認するには pipeline.export_paddlex_config_to_yaml("vl.yaml") を呼び出します。編集したら、PaddleOCRVL(paddlex_config="vl.yaml") でそのファイルを渡してください。²

サービング：vLLM、SGLang、FastDeploy、llama.cpp#

上のクイックスタートの方法では、すべてを 1 つの Python プロセスで実行します。ドキュメントはこれを "rapid validation"（素早い検証）向けとし、本番環境では専用の VLM 推論サーバーを推奨しています。¹役割分担は次のとおりです。VLM サーバーは 0.9B のモデルだけを動かし、クライアント（引き続き PaddleOCRVL パイプライン）はレイアウト解析をローカルで行って、切り出した領域をサーバーに送ります。クライアントでもレイアウトモデルが動くため、ドキュメントはクライアントも GPU で動かすことを推奨しています。¹

VLM サーバーを起動する#

docker run -it --rm --gpus all --network host \
  ccr-2vdh3abv-pub.cnc.bj.baidubce.com/paddlepaddle/paddleocr-genai-vllm-server:latest-nvidia-gpu \
  paddleocr genai_server --model_name PaddleOCR-VL-1.6-0.9B --host 0.0.0.0 --port 8118 --backend vllm

docker run -it --rm --gpus all --network host \
  ccr-2vdh3abv-pub.cnc.bj.baidubce.com/paddlepaddle/paddleocr-genai-fastdeploy-server:latest-nvidia-gpu \
  paddleocr genai_server --model_name PaddleOCR-VL-1.6-0.9B --host 0.0.0.0 --port 8118 --backend fastdeploy

python -m venv .venv_vlm && source .venv_vlm/bin/activate
python -m pip install "paddleocr[doc-parser]"
paddleocr install_genai_server_deps vllm      # or: sglang, fastdeploy
paddleocr genai_server --model_name PaddleOCR-VL-1.6-0.9B --backend vllm --port 8118

# GGUF files: huggingface.co/PaddlePaddle/PaddleOCR-VL-1.6-GGUF
./build/bin/llama-server \
  -m /path/to/PaddleOCR-VL-1.6-GGUF.gguf \
  --mmproj /path/to/PaddleOCR-VL-1.6-GGUF-mmproj.gguf \
  --port 8111 --host 0.0.0.0 --temp 0

コマンドは使い方チュートリアルからそのまま引用しています。¹install_genai_server_deps でインストールされる vLLM と SGLang は CUDA 12.6 向けで、vLLM と SGLang には FlashAttention 2.8.2 が必要です。Transformers エンジンは、必要な transformers のバージョンが異なるため、vLLM や SGLang と同じ環境では使えません。¹サーバーのチューニングは YAML ファイルに書き、--backend_config で渡します（vLLM なら gpu-memory-utilization や max-num-seqs など）。

パイプラインからサーバーを呼び出す#

from paddleocr import PaddleOCRVL

pipeline = PaddleOCRVL(
    vl_rec_backend="vllm-server",      # or sglang-server, fastdeploy-server
    vl_rec_server_url="http://localhost:8118/v1",
    vl_rec_max_concurrency=16,         # tune for your GPU
)
for res in pipeline.predict("report.pdf"):
    res.save_to_markdown(save_path="output")

paddleocr doc_parser --input report.pdf \
  --vl_rec_backend vllm-server \
  --vl_rec_server_url http://localhost:8118/v1

# server started with plain `vllm serve` (port 8000): pass the HF repo id
paddleocr doc_parser --input report.pdf \
  --vl_rec_backend vllm-server \
  --vl_rec_server_url http://localhost:8000/v1 \
  --vl_rec_api_model_name 'PaddlePaddle/PaddleOCR-VL-1.6'

マネージドの VLM エンドポイントも、--vl_rec_api_key を付ければ同じように使えます。ドキュメントによると、SiliconFlow が提供しているのは v1 と 1.5 だけ（pipeline_version="v1.5" を指定）、Novita AI は v1 だけです。¹

パイプライン全体の HTTP API#

パイプライン全体を実行する HTTP エンドポイントとして、ドキュメントでは Docker Compose の構成（ポート 8080 で待ち受け）と paddlex --serve --pipeline PaddleOCR-VL が紹介されています。どちらもリクエストを 1 件ずつ処理します。同時実行が必要な場合、ドキュメントは別の高性能サービング（HPS）ソリューションを案内しています。¹リクエスト形式とクライアントについてはサービングと API のガイド (EN) で解説しています。

公開されているスループット（Baidu の数値）#

Baidu は、OmniDocBench v1.5 で A100 1 基、バッチサイズ 512 の条件での PaddleOCR-VL-1.5 のエンドツーエンドのスループットを報告しています。FastDeploy 2.3 で 1.4335 ページ/秒、vLLM 0.10.2 で 1.1433、SGLang 0.5.2 で 1.0091 です。同じ表で、vLLM 上の MinerU2.5 は 0.9984 ページ/秒です。¹⁰これらの表はリポジトリ内に画像としてしか存在しないため、私たちが書き起こしました。1.6 のドキュメントでは、推論速度は 1.5 と同じとしています。⁹私たち自身の GPU での数値はありません。

Apple Silicon、AMD、Ascend などのハードウェア#

各アクセラレーターには公式のガイドがあり、それぞれ検証に使ったデバイスが 1 つ記載されています。¹¹

Hugging Face と Transformers#

重みは Hugging Face で PaddlePaddle/PaddleOCR-VL、-1.5、-1.6 として公開されており、ほかに GGUF 版と、単体のレイアウトモデル PP-DocLayoutV3 もあります。モデルカードには、1 枚の画像を OCR: や Table Recognition: などのタスクプロンプトとともに送る、Transformers をそのまま使った例が載っています。1.5 と 1.6 では transformers>=5.0.0 が必要です。⁴これは要素単位の認識で、切り出した表や数式には便利ですが、ページ全体を解析するものではありません。Transformers で文書全体を処理するには、パイプラインはそのままにエンジンを切り替えます：PaddleOCRVL(engine="transformers")。¹

ホスト型 API（GPU 不要）#

PaddleOCR 3.7.0 には公式のホスト型サービス用のクライアントが含まれており、文書解析の既定モデルは PaddleOCR-VL-1.6 です。¹³AI Studio のアクセストークンが必要です。コードは 3.7.0 のソースと照合しましたが、サービス自体は呼び出していません。

# export PADDLEOCR_ACCESS_TOKEN="..."
from paddleocr import PaddleOCRClient, Model

client = PaddleOCRClient()
result = client.parse_document(
    file_path="report.pdf",
    model=Model.PADDLE_OCR_VL_16,   # the default
)
for page in result.pages:
    print(page.markdown_text)
client.close()

export PADDLEOCR_ACCESS_TOKEN="..."
paddleocr api --model_type doc_parsing --file_path report.pdf

AI Studio のクォータのページには、ユーザーごとにモデル 1 つあたり 1 日 3,000 ページまで解析でき、1 ファイルにつき解析されるのは最初の 100 ページだけとあります。一方、非同期 API のガイドでは 1 リクエストで最大 1,000 ページの PDF に対応するとしています。2 つの公式ページの記述が食い違っているので、自分のファイルで試してください。¹⁴私たちが確認できたページには、料金はどこにも記載されていませんでした。詳細、TypeScript と Go の SDK、エラーコードは API のページ (EN) にまとめています。

HPD-Parsing：スループット重視の姉妹モデル#

2026年7月22日に発表された HPD-Parsing は、大量の文書解析向けに InternVL3.5-1B をベースに作られた、約 1B の別の文書 VLM です。ページを 1 本の長いトークン列としてデコードする代わりに、メインのレイアウトブランチからコンテンツブランチを生成して並列にデコードし、さらに Progressive Multi-Token Prediction（P-MTP）でデコードのステップ数を減らします。¹²

• 精度（自己申告）：OmniDocBench v1.6 で総合 94.91。HPD-Parsing は OmniDocBench README の表に載っていないため、第三者による数値はありません。比較のために挙げると、同じ表で PaddleOCR-VL-1.6 は 96.34 です。¹²⁶
• 速度（自己申告）：A800 80GB、vLLM、バッチサイズ 512 で 2.68 ページ/秒、4,752.1 トークン/秒。自己回帰型のベースラインは 1.02 ページ/秒です。¹²
• 要件：NVIDIA GPU（H100、H800、H20、A100、A800、A30、L20、RTX Pro 6000 で検証済み）、CUDA 12.8+ 対応のドライバー、Linux x86-64、Python 3.10〜3.13、v0.17.1 ベースの独自ビルドの vLLM。paddleocr パッケージは一切使いません。¹²

docker run -it --rm --gpus all --network host \
  ccr-2vdh3abv-pub.cnc.bj.baidubce.com/paddlepaddle/hpd-parsing-vllm:latest-nvidia-gpu

サーバーはポート 8118 で待ち受け、OpenAI API で通信します。クライアントは各ページとともに固定のプロンプト document parsing with fork. を送ります。¹²GPU 1 時間あたりの処理ページ数が精度の最後の 1 ポイントより重要で、対応するデータセンター向け GPU を使っているなら HPD-Parsing を選びます。精度、幅広いハードウェア対応、paddleocr のツール群を重視するなら PaddleOCR-VL を選びます。

ファインチューニング#

VLM は ERNIEKit による教師ありファインチューニングが可能ですが、レイアウトモデルと読み順モデルはファインチューニングできません。¹1 つ矛盾があります。v1 のアルゴリズムの FAQ では、ある回答でファインチューニングは "not supported"（非対応）とし、別の回答では ERNIEKit による SFT を推奨しています。現在の指針は、使い方チュートリアルの ERNIEKit の節です。

よくある質問#