We benchmarked every PaddleOCR model on a CPU

Results at a glance#

Seconds per page: median of 3 warm runs per document, averaged over 5 documents. Character error rate: mean over the 5 documents. Peak RAM: maximum resident memory of the whole Python process (range across the two engines). Model size: detection + recognition files on disk in decimal megabytes (10⁶ bytes), PaddlePaddle format; the ONNX files are within 1 MB. The official docs quote the same files in MiB, so medium appears there as 133 MB.

What we'd tell a friend#

1. Use PP-OCRv6 medium when accuracy matters#

   It missed one item in 124, and that one is arguable: it read 600x600 as 600×600. It also beat the previous flagship, PP-OCRv5 server, on both accuracy (123 vs 117) and speed (4.5 s vs 5.2 s per page with PaddlePaddle).

2. Use PP-OCRv6 small for speed on CPU#

   3.3–3.7× faster than medium with two extra misses, both the same confusion (Order → 0rder). It's also the model our browser tool runs.

3. Use tiny only if you never need Japanese#

   On Latin and Chinese text tiny was close behind (0.46% character errors without the Japanese page), but on Japanese it produced gibberish — 47% character errors — exactly as the docs warn: its dictionary has no kana.

4. Try ONNX Runtime on CPU#

   engine="onnxruntime" made every PP-OCRv6 tier 1.4–1.5× faster with identical text. The exception: PP-OCRv5 server became 7× slower, so don't use that combination.

5. Pin PaddlePaddle to 3.2.0#

   PaddlePaddle 3.3.1 — what pip install paddlepaddle gives you today — crashed PaddleOCR 3.7.0 on CPU. Its workaround, enable_mkldnn=False, costs a lot of speed (below).

Every mistake, model by model#

A single error rate hides what kind of errors a model makes. These are all the ground-truth items each model got wrong (the PaddlePaddle and ONNX Runtime engines produced identical text):

Two patterns stand out. PP-OCRv6 small and tiny confuse capital O with zero in a monospaced receipt font — worth a post-processing rule if you read order numbers. And PP-OCRv5's l/I/L confusions on the invoice are exactly the errors we later saw in PP-StructureV3, which uses PP-OCRv5 server text models by default.

The tiny model and Japanese#

The cost of the enable_mkldnn=False workaround#

If you're stuck on PaddlePaddle 3.3.1, enable_mkldnn=False stops the crash by disabling oneDNN, PaddlePaddle's CPU acceleration library. We measured what that costs with PP-OCRv6 medium:

Disabling oneDNN made the same model 2.6× slower than the pinned 3.2.0 setup and 4.1× slower than ONNX Runtime. Pinning paddlepaddle==3.2.0 or switching engines is the better fix. Troubleshooting details.

PP-StructureV3: default vs PP-OCRv6 text models#

We also ran the document pipeline on our invoice and paper page. PP-StructureV3 in PaddleOCR 3.7 still defaults to the PP-OCRv5 server text models, which misread three lines of the invoice (four wrong characters). Passing the PP-OCRv6 medium models fixed all three lines:

The table and the LaTeX formula on our paper page came out correct either way. Full outputs and the one-line fix are on the PP-StructureV3 page.

Method#

Test documents#

We generated six fictional documents with known text so every character could be checked. Five were used for text OCR (124 ground-truth items); the paper page was used for PP-StructureV3. All names and numbers are invented.

Setup#

• Machine: Linux x86-64 container, 4 vCPU Intel Xeon @ 2.10 GHz, 15 GB RAM, no GPU.
• Software: Python 3.13, paddleocr 3.7.0, paddlex 3.7.2; PaddlePaddle 3.2.0 (oneDNN on) or ONNX Runtime; PaddlePaddle 3.3.1 only for the enable_mkldnn=False run.
• Pipeline: PaddleOCR(use_doc_orientation_classify=False, use_doc_unwarping=False, use_textline_orientation=False) with explicit text_detection_model_name / text_recognition_model_name; default lang; all other settings default.
• Timing: per document, one untimed warm-up run, then the median of 3 timed predict() calls. Models were run one at a time in separate processes.
• Accuracy: each ground-truth item is matched to the best predicted line (contained in a line counts as exact, since detectors may merge neighbouring items). Whitespace and full-width punctuation are normalised on both sides. Character error rate = edit distance ÷ ground-truth characters.

Limitations#

• Our documents are synthetic and clean. Real scans and photos are harder; expect higher error rates in production. The ranking between models is more informative than the absolute numbers.
• 124 items is a small sample. A difference of one or two items between models is within noise; treat the 123 vs 121 vs 117 spread as indicative.
• One CPU, no GPU. GPU speed ratios differ; see the official speed tables for A100, V100 and Apple M4 figures.
• We didn't test PaddleOCR-VL, which needs a GPU for useful speed.

Want to reproduce it? Every script is linked under Sources. make_samples.py regenerates the images, run_all.sh runs the whole matrix, and bench.py holds the ground truth and scoring.

How this compares with Baidu's numbers#

Baidu's own in-house benchmark ranks the models in the same order we found: PP-OCRv6 medium first (detection Hmean 86.2, recognition 83.2), then PP-OCRv6 small (84.1 / 81.3), then PP-OCRv5 server (81.6 / 78.1), with tiny last on recognition (73.5). Their absolute numbers are much lower than ours; their test set is larger and more varied, so the two aren't directly comparable. The models page charts the official figures.²

FAQ#