PaddleOCR 是百度 PaddlePaddle 团队维护的开源 OCR 工具链，Apache 2.0 协议，商用无需额外授权。它的定位这两年发生了根本变化：2025 年之前大家装 PaddleOCR 是为了拿到文字框和文字内容，2026 年装它更多是为了把一份 PDF 直接变成结构正确的 Markdown。3.7.0 版本（2026 年 6 月 11 日）推出 PP-OCRv6，检测比 PP-OCRv5_server 提升 4.6%、识别提升 5.1%，并且用一个模型统一覆盖中文、英文、日文和 46 种拉丁语系文字，合计 50 语种；同时 OpenVINO 路径上拿到 5.2 倍 CPU 加速。
另一条线是 PaddleOCR-VL。3.3.0（2025 年 10 月）首次发布，用 NaViT 风格的动态分辨率视觉编码器接 ERNIE-4.5-0.3B 语言模型，支持 109 种语言；3.4.0 的 1.5 版本把语种扩到 111 种；3.6.0（2026 年 5 月 28 日）的 PaddleOCR-VL-1.6 在 OmniDocBench v1.6 上拿到 96.33% 的成绩。1.6 相对 1.5 的做法是「区域感知数据优化」——先定位上一代模型的弱势区域再做定向增强，架构与 1.5 完全兼容，所以升级是零成本平替，改个模型名就行。2026 年 7 月 22 日又追加了 HPD-Parsing，基于 InternVL3.5-1B 的 1B 模型，用分层并行解码在 A800 80GB、batch 512、vLLM 环境下打到 4,752 tokens/s 的峰值吞吐。
真正决定你租哪张卡的，不是参数量而是后端。PaddleOCR-VL 的 vLLM 与 SGLang 后端要求 GPU 算力（Compute Capability）不低于 8.0、CUDA 不低于 12.6。官方明确写了：在算力 7.x 的 T4、V100 上服务「能启动」，但「容易超时或 OOM，因此不推荐」。这是自建 PaddleOCR-VL 最常踩的坑——机器跑起来了，日志也没报错，就是一直卡住。下面按两条产线分别给出可用的卡型和价格。
01 —
当前在维护的模型与产线
经典产线按 MB 算，VL 产线按 B 算，两者解决的问题完全不同
| 版本 | 参数量 | 显存 | 上下文 | 说明 |
|---|---|---|---|---|
| PP-OCRv6（PaddleOCR 3.7.0） | tiny 1.5M / small 7.7M / medium 34.5M | det 权重 1.9MB / 9.6MB / 59.4MB，rec 权重 4.4MB / 20.4MB / 73.3MB，显存以百 MB 计 | 中英日 + 46 种拉丁语系，共 50 语种 | 当前经典产线的默认选择。medium 检测 86.2%、识别 83.2%，比 PP-OCRv5_server 更准且模型更小；tiny 档位是给端侧和高并发流水线准备的。 |
| PP-OCRv5 server / mobile | server / mobile 两档 | server det 84.3MB + rec 81MB，合计约 165MB 权重；单卡 24GB 可开很大 batch | 简体中文、繁体中文、英文、日文、拼音手写 | 已被 PP-OCRv6 超越但仍在维护，好处是文档和第三方集成最成熟。GPU 单图耗时 server 89.55ms + 8.46ms，mobile 10.67ms + 5.43ms，是目前唯一有完整官方推理耗时表的一代。 |
| PaddleOCR-VL-1.6（PaddleOCR 3.6.0） | 0.9B（Hugging Face 卡片按张量统计标注 1.0B） | bf16 权重约 2GB（0.9B × 2 字节）；vLLM 实占由 gpu-memory-utilization 决定，官方推荐 0.3 | 109 语种，NaViT 动态分辨率输入 | 当前文档解析的主力，OmniDocBench v1.6 96.33%。与 1.5 架构完全兼容，升级只需换模型名，不用改推理代码。 |
| PaddleOCR-VL-1.5（PaddleOCR 3.4.0） | 0.9B | 同 1.6，bf16 权重约 2GB | 111 语种 | 语种覆盖比 1.6 还多两种，如果你的场景里有 1.6 没覆盖的小语种，这一版仍然值得留着。OmniDocBench 报 94.5%。 |
| HPD-Parsing（2026.07.22） | 1B，基于 InternVL3.5-1B | bf16 权重约 2GB；官方吞吐数据是在 A800 80GB、batch 512 下测的 | 动态切图，最多 24 个 448×448 图块 | 为高吞吐批量解析设计。分层并行解码 + P-MTP 投机解码，峰值 4,752 tokens/s，是现有最快文档解析器的 2.62 倍、自身自回归基线的 3.06 倍，OmniDocBench v1.6 得分 94.91%。 |
| PP-StructureV3 | 多模型组合产线 | 取决于所选检测/识别/表格子模型组合 | 整页版面 + 表格 + 公式 | 不走 VLM 的结构化路线：版面分析、表格识别、公式识别各用专用小模型拼成产线。3.5.0 起支持导出 Markdown 与 DOCX，适合要求可解释、可逐模块替换的场景。 |
02 —
该租哪张卡
先看算力等级，再看显存——PaddleOCR-VL 的门槛是算力 8.0，不是显存
PP-OCRv6 / PP-OCRv5 经典产线，票据、证照、批量图片识别
RTX 3090 24GB$0.193/卡·时
模型权重只有几十 MB，24GB 显存全部用来堆 batch；算力 8.6 同时满足未来切 VL 产线的门槛，而且这是我们最便宜的一张卡。
PaddleOCR-VL-1.6 单卡起 vLLM 服务，做文档转 Markdown
RTX 4090 24GB$0.540/卡·时
算力 8.9、原生 CUDA 12.6+，FlashAttention 编译顺畅，官方推荐的 gpu-memory-utilization 0.3 在 24GB 上就是约 7GB 显存池，跑 0.9B 模型绰绰有余。
高并发文档解析服务，需要更大 KV cache 和更高 vl_rec_max_concurrency
RTX 5090 32GB$0.723/卡·时
多出的 8GB 显存直接换成并发数，版面分析模型和 VLM 可以共卡常驻，不用再为两阶段产线开两台机器。
HPD-Parsing 高吞吐批处理，复现 batch 512 的 4,752 tokens/s
A100 SXM4 80GB$1.088/卡·时
官方吞吐是在 A800 80GB 上测的，A100 SXM4 80GB 是同代同规格同显存的对应卡型，batch 512 的 KV cache 只有 80GB 级别的卡装得下。
03 —
从空机器到出 Markdown
四步，全部用官方文档里的原话命令
- 01
开一台算力 8.0 以上的实例，装 PaddlePaddle 与 PaddleOCR
在 NexGPU 控制台选 RTX 4090 或 RTX 3090，从 2,000+ 预置镜像里挑 PyTorch 或 Ubuntu CLI 起步。注意装的是 CUDA 12.6 通道的 paddlepaddle-gpu，官方要求框架版本不低于 3.2.1，PaddleOCR 本体要 3.6.0 以上才带 PaddleOCR-VL-1.6。
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]>=3.6.0" - 02
起 VLM 推理服务
最省事的是直接拉官方 GenAI 服务镜像，vLLM 版约 13GB、FastDeploy 版约 43GB（带 -offline 后缀的是离线镜像）。如果你更想自己控环境，也可以用 paddleocr install_genai_server_deps vllm 装依赖，backend 支持 vllm、sglang、fastdeploy 三种。
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 - 03
走完整产线，不要只调 VLM
官方反复强调：PaddleOCR-VL 是两阶段系统，第一阶段做版面分析、判定阅读顺序并裁出子图，第二阶段才把子图喂给 VLM 识别再按阅读顺序合并。绕过第一阶段直接把整页丢给 VLM，是效果不及预期最常见的原因。产线客户端连上第二步起的服务即可。
paddleocr install_genai_server_deps vllm - 04
按显存调两个参数
vLLM 侧官方推荐 gpu-memory-utilization 设 0.3、max-num-seqs 设 128；如果是显存紧张的小卡（文档以 RTX 3060 举例）则调到 0.7。客户端侧用 vl_rec_max_concurrency 控制并发——服务端要同时服务多个客户端或算力有限时，把这个值降下来。跑完 docker stop，计算费用当秒停止。
paddleocr genai_server --model_name PaddleOCR-VL-1.6-0.9B --backend vllm --port 8118
算一笔真实的账
假设你要把一批合同 PDF 转成 Markdown，用 PaddleOCR-VL-1.6 跑一次完整批处理。环境准备：RTX 4090 24GB，$0.540/卡·时，拉 13GB 的 vLLM 镜像加装依赖、跑通 demo，约 40 分钟，即 0.67 × $0.540 ≈ $0.36。正式批处理连跑 12 小时：12 × $0.540 = $6.48。中间产物和输出占 20GB，任务结束后再保留 3 天做抽检：20GB × $0.414/GB·月 × 3/30 ≈ $0.83。最后把 5GB 的 Markdown 和 JSON 拉回本地：5 × $0.0081 ≈ $0.04。合计约 $7.71，一次跑完一批合同。如果你走的是经典 PP-OCRv6 产线，同样 12 小时换成 RTX 3090 只要 12 × $0.193 = $2.32。两个数字都没有起步价、没有配额申请、没有开通费；计算费用在实例停止的那一秒就停，存储盘销毁前才继续计费。
04 —