Korean Document OCR Comparison 1: Re-evaluating PP-OCRv5, PaddleOCR-VL-1.6, and Unlimited-OCR-2 on the Same 60 Pages

Status: Measured (October 29 to October 30, 2026, using a single 24GB consumer GPU). All numbers are derived from raw data measured firsthand (raw outputs per page, measurement logs, and scoring scripts). Paper figures are noted along with the section and table numbers verified from the original texts; unmeasured items are marked as 〈Unmeasured〉, and items not found in the original texts are marked as 〈Unverified〉. Installation notes and security memos have been gathered separately in Part 2.

Table of Contents

• 1. What We Measured and Why
• 2. How the Three Engines Read Differently
• 3. Test Documents and Scoring
  • Creating Documents with Known Ground Truth
  • Scoring: Two Character Error Rate (CER) Metrics
  • Scoring Pitfall: CER Reaches 16% If Coordinates Are Not Removed
• 4. Results: Accuracy, Speed, and Memory
• 5. Actual Output Comparison
  • Rare Final Consonants: None of the Three Could Read 〈㖙〉 Even Once
  • Meaning-Reversing Errors: 〈"does not exist" → "exists"〉
  • Punctuation: PP-OCRv5 Alters Quotation Marks and Drops Them When Blurry
  • Resolution Degradation in Multi-Page Mode
• 6. Why Is It So Slow, and What Conclusions Should Not Be Drawn from These Numbers
• 7. What to Choose
• 8. Limitations
• References

1. What We Measured and Why

OCR (Optical Character Recognition) is the task of extracting text from images or scanned pages. The traditional approach consists of two stages: first, locating lines of text on a page (detection), and then cropping each detected line to read the characters (recognition). Nowadays, Vision Language Models (VLMs, language models that accept images as input) that view the entire image and directly output Markdown occupy the top ranks of document OCR leaderboards. Vision Language Model (VLM, a language model that takes images as input) occupies the top of the document OCR leaderboard.

We selected three engines for this evaluation. Although all three originate from the same corporate ecosystem (Baidu), their methods of reading pages differ.

Why we had to measure it ourselves. Because major document OCR benchmarks do not include Korean.

• OmniDocBench(CVPR 2025, arXiv 2412.07626) v1.0 has 981 pages, consisting of 290 English, 612 Simplified Chinese, and 79 mixed pages (Table S3). There are no Korean pages. The authors also note that "almost all algorithms score higher on English than on Chinese" (§5.1). This means rankings can vary depending on the language.
• Multi-page document benchmarks like MPDocBench(arXiv 2605.22100, 3,246 pages across 433 documents) and MarathonDocBench(100 documents, ranging from 103 to 300 pages) also feature only English and Chinese.
• The engine-side evidence is also thin. The PaddleOCR-VL 1.0 paper reported a Korean Character Error Rate of 0.052 in in-house tests using cropped single-line units (Table 6a), and the 1.5 and 1.6 papers contain no Korean evaluations. The official documentation for the PP-OCRv5 Korean recognition model merely states an "88.0% accuracy on 5,007 Korean character images" without any corresponding paper figures. The Unlimited-OCR 1 and 2 reports do not contain the word "Korean" even once.

Therefore, there are three questions: Which of the three is the most accurate on Korean documents? How fast are they, and how much memory do they consume? And when they make mistakes, how do they fail?

2. How the Three Engines Read Differently

PP-OCRv5 Koreandoes not understand page structure. The detector finds text line boxes, and the recognizer produces characters for each line. The output is a sequence of line texts from top to bottom. According to the PaddleOCR 3.0 technical report (arXiv 2507.05595, §2.1), this family totals about 0.07B parameters and is under 100MB (based on the report's baseline model; the size of the Korean recognition model is unverified).

PaddleOCR-VL divides the work into two parts (1.0 paper arXiv 2510.14528, §2.1). A layout model (PP-DocLayoutV3 starting from v1.5) determines "what is where and in what order," and then a 0.9B VLM (NaViT-style dynamic resolution encoder + ERNIE-4.5-0.3B) reads the content of a single cropped element. The VLM does not look at the entire page at once. Version 1.6 (arXiv 2606.03264) keeps the architecture unchanged while updating only the data and post-training. It selected and reinforced error-prone samples (predictions diverging across 8 checkpoints and 16 types of distortions, ancient texts, and rare characters), followed sequentially by CPT, SFT, and GRPO reinforcement learning (§3, §4).

Unlimited-OCR-2 's backbone is the "optical compression" from DeepSeek-OCR (arXiv 2510.18234). An encoder (DeepEncoder) reduces a 1024×1024 image 16x into around 256 visual tokens, and a 3B MoE (Mixture of Experts, using only some experts per token) decoder generates the text. What the Part 2 report (HF public PDF, p.5-7) adds is SR-SWA(Sparse-Reference Sliding-Window Attention). Every time the decoder generates the next token, instead of looking at all visual tokens across all pages, it looks only at a few blocks of that page and the immediately preceding output. Calculated using the configuration parameters we received, this is remote 12 blocks × 32 + local 128 = 512 tokens, which matches the "512 tokens" in the model card. This mechanism ensures that the computational cost of a single step does not increase even as the number of pages grows.

There is also an interesting link in the training data of the two VLMs. The pseudo-labels (labels generated by another model instead of humans) for Unlimited-OCR-2 were extracted from MinerU2.5-Pro and PaddleOCR-VL-1.6 (Part 2 report, p.8). The two VLMs in this comparison also share a teacher-student relationship.

3. Test Documents and Scoring

Creating documents with known ground truth

Real scanned documents require humans to type out the ground truth text character by character. So we did the reverse. We decided on the ground truth text first and rendered the pages using that text. The body text was extracted from TT Lab's technical study notes, focusing on paragraphs where Korean accounts for over 40%, rendered at A4 size (150dpi, 1240×1754 pixels) using a single Apple SD Gothic Neo font. The 60 pages were divided as follows.

The blurred copy has the exact same text as the standard body. Therefore, the difference between the two sets of the same engine represents "errors caused by degraded image quality."

Scoring: Two Types of Character Error Rate (CER)

CER(Character Error Rate) is the minimum number of edits (insertions, deletions, substitutions) required to convert the ground truth into the output, divided by the length of the ground truth text. A 1% rate means roughly one error per 100 characters. Edit distance was calculated using Myers' (1999) bit-parallel algorithm.

Since output formats vary by engine, we first normalizethem. We standardize to Unicode NFKC, remove markdown symbols (#, *, | , etc.), HTML tags, and coordinate markers added by the model, and strip all spaces and line breaks. Since spacing and line wrapping depend on the layout, only the character sequence is compared.

Then, we compute CER twice.

• Full CER: All normalized characters. Includes punctuation marks such as brackets (「」), interpuncts (·), periods, and commas.
• Text-Only CER: Measured leaving only Korean letters, English letters, and numbers.

The reason for maintaining two separate metrics is that engines vary significantly in how they handle punctuation. Combining them into a single score would make an engine that frequently drops punctuation and an engine that misreads Korean look like they have the same score. Use cases where only the text matters (like search indexing) and use cases where documents need to be read by humans require looking at different numbers.

Scoring Pitfall: Leaving Coordinates Results in a 16% CER

The output of Unlimited-OCR-2 includes coordinates for each block. For example, it looks like this.

<BLOCK>text[71, 96, 900, 160]<FORK>우리에게 의미는 「언젠가 휴대폰 안에서 …

Initially, the scorer removed only <…> tags and kept text[71, 96, 900, 160] . As a result, the median CER for standard body text came out to 16.3%(ranging from 13.9% to 17.5% per page). Adding one more coordinate regex line brought it down to 0.80% . For the blurred copy, it dropped from 16.95% to 1.99%, and for the table, from 8.38% to 0.17% (recalculated with the same output and ground truth). A 20-fold difference came from a single output format detail. When evaluating VLM outputs, the proper procedure is to first visually inspect a few pages of the raw output and adjust the normalization rules.

4. Results: Accuracy, Speed, Memory

How to read: The median is the middle value of the CERs calculated per page. For an even number of pages, like 8 pages, the upper value (the fifth one) was used. For long documents, they were graded as a single block, resulting in a single value. Time is the average measured excluding one warmup page, and for long documents, the total time was divided by the page count. Memory is the peak value recorded by each framework's allocator ( max_memory_allocated), so it is smaller than the value shown in nvidia-smi . No page failed across all 13 batches.

There are three key takeaways from the figure.

PaddleOCR-VL-1.6 was the most accurate across all four batches. The overall CER of 0.48% for regular body text means about six characters out of roughly 1,230 per page were wrong. For tables, it was 0% across all 4 pages along with PP-OCRv5.

The rankings change when punctuation is excluded. In terms of overall CER, Unlimited-OCR-2 (0.80%) is better than PP-OCRv5 (1.52%). However, when counting only characters, the order reverses with PP-OCRv5 at 0.33% and Unlimited-OCR-2 at 0.75%. This is even more distinct in blurry copies. For overall CER, PP-OCRv5 is the worst of the three at 4.47%, but its character-only CER is 1.23%, which is better than Unlimited-OCR-2 (1.76%). Most of PP-OCRv5's errors are punctuation, while most of Unlimited-OCR-2's errors are characters. In the figure, a long bar between two points means there are many punctuation errors. Unlimited-OCR-2 has almost no bar.

Reading multiple pages at once roughly tripled the errors for Unlimited-OCR-2. Comparing the first 10 pages of the same long document, PaddleOCR-VL-1.6 is 0.58%, PP-OCRv5 is 1.53%, and Unlimited-OCR-2 is 2.72% (the values for the first 10 pages were recalculated by trimming the 40-page output to match the end of the 10 ground-truth pages, and applying the same method to the entire 40 pages yields the 0.53% and 1.41% shown in the table). The difference from reading page by page (0.80% for regular body text) stems from the resolution mode. Single pages are read using Gundam mode, which splits them into tiles for close inspection, while multiple pages are read using Base mode with 273 visual tokens per page. Section 5 provides a practical example.

The processing speeds are on a completely different scale. For a single standard body page, PP-OCRv5 took 0.36 seconds, PaddleOCR-VL-1.6 took 13.81 seconds (about 38 times slower), and Unlimited-OCR-2 took 31.07 seconds (about 86 times slower). Simply converting this to an hourly rate yields 10,000 pages, about 260 pages, and about 116 pages, respectively. The reason PP-OCRv5 was even faster on the blurry copy (0.20 seconds) is because the image was scaled down to 0.6x. As for memory usage, PP-OCRv5 used 2.27 GiB, PaddleOCR-VL-1.6 used 5.80 GiB, and Unlimited-OCR-2 used 6.32 GiB for weights alone, increasing with the page count: 6.85 GiB for 1 page, 7.59 GiB for 10 pages, and 8.81 GiB for 20 pages. A 24GB graphics card has plenty of headroom for all three.

However, the execution times for the two VLMs reflect our implementation method, not the limitations of the models themselves. We will explore the reasons in Section 6.

5. Actual Output Comparison

Let us look at the actual outputs following the numbers. The two figures below show the exact same location on page 2. The top image is a pixel-for-pixel crop of the image received by the engine, and the bottom image shows the outputs of the three engines aligned to their ground truth positions. This page was chosen because it contains a diverse mix of error types (the CER for page 2 of the general body text is 0.09% for PaddleOCR-VL-1.6, 0.26% for Unlimited-OCR-2, and 1.57% for PP-OCRv5, which is slightly better than the bundle median).

Rare base: "쿅" was not read even once by all three

"Jaesseumnida" (jaetda, the past tense of jaeda) appears 7 times on page 8 of the general body text. All three engines got it wrong all 7 times. This is also true for the clean general body text.

PP-OCRv5 always read it as "jyeot" on the clean side. The recognizer picks an answer only from a fixed character dictionary; if "jaet" is not in that dictionary, it is consistently replaced with the most similar character like this (it is unconfirmed whether it is actually missing from the dictionary). The answers of the two VLMs are scattered. It seems that among similarly shaped characters, the language model leans toward the one it has seen more frequently. Since this is a final consonant rarely seen in everyday documents, it is highly likely that it was scarce in the training data of all three engines.

There are more similar characters. "hip" (found in read, disclosed, heap memory) appears 5 times in the regular body text, but Unlimited-OCR-2 read it as "him" or "rip" all 5 times, PaddleOCR-VL-1.6 got them all right, and PP-OCRv5 was wrong once. For "sseup" in "sseumnida", only Unlimited-OCR-2 read it as "ssing" (2 out of 3 times in regular body text, and all 3 times in blurred copies). Conversely, for "rael" in "rally", PP-OCRv5 (ael) and PaddleOCR-VL-1.6 (raem, ral) got it wrong, while Unlimited-OCR-2 got it right on the clean side. No engine is safe with rare characters, and each engine has different weak characters.

Errors that flip meanings: "does not exist → exists"

Unlimited-OCR-2 read "eop" as "it". This happens 2 out of the 14 times "eop" appears in the regular body text, and the same 2 times in the blurred copies. An example from the image is when "there is no message telling you why it is so does not exist" becomes "message exists". In terms of CER, it is just one character out of 1,150, or 0.09 percentage points, but the meaning of the sentence becomes completely opposite. Both Paddle engines got it right all 14 times.

This error is difficult to explain solely by character shape. "eop" and "iss" have quite different final consonant shapes. When visual evidence is weak, it appears to be an error where the decoder's language knowledge fills in the more common one. The PP-OCRv6 paper (arXiv 2606.13108) also raises this kind of "hallucination" in VLM-based OCR as an issue. For documents where a single negative word matters, such as contracts or test results, VLM outputs must assume a human review workflow.

Punctuation: PP-OCRv5 changes quotation marks and erases them when blurred

Almost all of the factors that drove up the overall CER of PP-OCRv5 are punctuation marks. Counting the error types (aligning normalized characters and counting discrepancies) in the regular body text, changing 「 to ' occurred 46 times, and changing 」 to ] occurred 42 times. In blurred copies, instead of changing them, they were erased. There were 60 deletions of periods, 39 deletions of 「, 38 deletions of commas, 36 changes from commas to periods, 30 deletions of 」, and 28 deletions of middle dots ·. Small, blurred dots appear not to be captured as characters during the detection stage.

The two VLMs also misplace punctuation marks, but with a much lower frequency. For PaddleOCR-VL-1.6, changing 「 to ‘ or ' in blurred copies occurred 18 times, while for Unlimited-OCR-2, deleting middle dots 18 times and changing 「 to ' 11 times were the most common errors in blurred copies.

Let us also point out a small flaw on the grader side. All three engines read the dash – in the correct answer as a hyphen -, and since normalization treats hyphens as Markdown symbols and removes them, it counted "dash deletion" 4 times per batch. Strictly speaking, the dashes were replaced with hyphens, but since they were fed identically to all three engines, the rankings remain unchanged.

Resolution drop in multi-page mode

When Unlimited-OCR-2 reads a 10-page long document all at once, the output contains errors that are hard to see when reading page by page. Examples include "increases → is played around with", "feels → chae-gap", "mention → dancer", "light → bakkwi-on", "comment → reply" (3 times), and "rally → mwolli". Instead of just a single character, two or three characters collapse together and are replaced by visually similar words. The CER for the first 10 pages of PaddleOCR-VL-1.6, which read the exact same pages individually, was 0.58%.

The cause has already been pointed out in the paper. In Table 3 of DeepSeek-OCR, dense Chinese characters in the same Base mode have an edit distance about 4 times that of English (0.205 vs. 0.054), which improves to 0.097 in the token-extended Gundam mode. The Unlimited-OCR Part 1 report (arXiv 2606.23050, §5.4) also notes that most errors in documents exceeding 40 pages are because it could not read small text in Base mode I write that it happened. Hangul is also a square-shaped letter with final consonants (batchim), so it is closer to Chinese. Our results match that explanation. When visual tokens per page are reduced to 273, the final consonants of 24px Hangul get blurred.

6. Why is it so slow, and why you shouldn't judge by these numbers

The 30 seconds per page of Unlimited-OCR-2 is far from the speed in the paper. However, the two numbers are of different kinds.

Paper numbers are concurrent throughputs. The 5,580 TPS (tokens per second, §5.2) of Unlimited-OCR Paper 1 is the sum of 512 concurrent requests, and the 1,315 TPS in Table 4 of Paper 2 is for a batch size of 16. Dividing by a single request yields about 11 and about 82 tokens/second, respectively. The approximately 3.8ms per step in Figure 6(b) of Paper 2 was measured with batch size 3. The hardware is undisclosed (unverified) for all three figures. We had 37.9 tokens per second and 26.4ms per step in batch size 1 (calculated by dividing the 9,426 output tokens on page 8 of the main text by 248.6 seconds).

The hardware share is not large. Batch 1 decoding is memory bandwidth-bound because weights must be read from memory at every step. The bandwidth of the A800 80GB tested by the model card is 1,935 GB/s (official specs), and our GPU is about 936 GB/s, a difference of about 2.1x. Reading about 0.57B active parameters in bf16 (2 bytes) takes about 1.14 GB per step, so the theoretical lower bound for our GPU is also about 1.2ms per step (estimated). The measured 26ms is over 20 times that. The bottleneck is not the hardware, but the execution path.

The Transformers path is for "quick testing". The model card calls it that and recommends SGLang for serving. The remote code we received (revision 5632329a) makes the reason clear. It is a Python loop that yields tokens one by one and lacks CUDA graphs. At each MoE layer, tokens_per_expert.cpu() synchronizes the GPU and CPU, and decoding attention does not compute only selected blocks; instead, it copies the entire cache to fp32, performs dense matrix multiplication, and masks it. The result is identical to sparse attention, but the computation is dense. As a result, the 20-page batch took 2.16 times longer than the 10-page batch (while generating 1.96 times more output tokens). This accounts for the step time increasing by about 10%, from 27.7ms to 30.6ms.

What SR-SWA promises is that "each step takes a constant amount of time." Since the total time is proportional to the number of output tokens, it is natural for it to scale linearly with the page count. What SR-SWA prevents is the quadratic growth of full attention. In Part 2, Figure 6(b), the difference diverges significantly from 50 pages to over 100 pages (at 100 pages, full attention takes about 26.7ms versus SR-SWA taking about 3.9ms, estimated visually from the chart). Our measurements with 10 and 20 pages cannot verify the benefits of SR-SWA.

PaddleOCR-VL is in the same situation. We read the pages sequentially using Paddle's dynamic graph without vLLM or FastDeploy servers. Paper v1.0, Table 13 reports 1.62 pages/sec with FastDeploy and 1.35 pages/sec with vLLM by packing 512 PDFs onto a single A100. Appendix Table A2 and version 1.5 Table A8 also report 0.36 to 0.54 pages/sec on entry-level consumer GPUs. This is more than ten times faster than our 0.07 pages/sec (13.81 seconds). Since this is batch throughput, it cannot be directly compared.

Therefore, based on these results, do not apply to the following claims:

• "Unlimited-OCR-2 is twice as slower than PaddleOCR-VL-1.6": Neither VLM used the recommended serving path. The speed difference in a serving engine was not measured.
• "PP-OCRv5 is 90 times faster than a VLM": The speed of the classical pipeline holds true under our conditions, but the VLM numbers are based on batch size 1 and a path without a serving engine.
• "Unlimited-OCR-2 is the most inaccurate": Our test only looked at single-paragraph body text. What this model highlights are multi-page tables, paragraphs, and heading hierarchies. Its self-reported MPDocBench score of 84.59 (Part 2, p. 10, Table 1) is higher than the third-party measurement of 80.80 for PaddleOCR-VL-1.5 on the same benchmark (MPDocBench paper, Table 2), though the testers differed and input methods were not verified to be identical. Structural metrics were not measured by us.
• "There were no repetition errors": The author's evaluation configuration enabled n-gram repetition blocking (size 35), but we disabled it. While we did not observe repetition loops in this 60-page test, the configurations differ.

7. What to Choose

Recommendations are limited to the scope of our actual measurements: Korean single-paragraph body text, grid tables, a single 24GB GPU, and batch size 1.

Another option is combining the classical pipeline with a VLM. For example, processing all documents with PP-OCRv5 first to build an index, and re-reading only pages intended for human reading or those with low confidence using PaddleOCR-VL-1.6. The effectiveness of this combination has not been measured.

8. Limitations

• Synthetic documents. To know the ground truth, characters were rendered using a single font, and blurring, rotation, downscaling, and JPEG artifacts were also synthesized. Real-world scan difficulties such as paper texture, warping, shadows, handwriting, multi-column layouts, and stamps are absent. Results on real scans have not been measured.
• The tables are simple. These are 4-page grid tables without merged cells. We did not measure table structure (TEDS) and compared only the cell text.
• The sample size is small. Each bundle ranges from 4 to 8 pages, and the median is the fifth value among 8 pages. A difference of 0.1 percentage points can be flipped by a single page.
• Single device, time-shared. A single 24GB GPU was shared with other tasks, and its impact was not measured separately.
• No serving engine was used. Unlimited-OCR-2 uses the Transformers pipeline (bf16, torch 2.14), while the PaddleOCR family uses native inference with PaddleOCR 3.7.0 and paddlepaddle-gpu 3.4.0 (cu129).
• n-gram repetition blocking was disabled(Unlimited-OCR-2, no_repeat_ngram_size=0).
• For Unlimited-OCR-2, the measurement for the 40-page bundle was cut off midway, so it has only 10-page and 20-page versions. For long documents from the other two engines, 40 pages were read page by page.
• Source of main text. The test paragraphs came from our study notes, some of which are published on this blog. It has not been verified whether the same texts were included in the training data of the engines.
• Memory numbers are based on the allocator. The pre-allocated share by the framework and the CUDA context are excluded, so actual card consumption is higher.

A word from Titi. All three engines read "jaessumnida" (measured) twenty-one times and got it wrong every single time. It would be troublesome if you meant to write that you measured the speed of a ping-pong ball, but wrote that you slept instead! That is why OCR results are not chosen solely by a single number, but by looking at what and how they get things wrong.

References

All original texts were accessed and verified on 2026-10-30. Since arXiv is in HTML format, section and table numbers are used instead of page numbers.

• Unlimited OCR Works, arXiv 2606.23050: https://arxiv.org/abs/2606.23050
• Unlimited OCR Works 2 (Report PDF, no arXiv number): https://huggingface.co/baidu/Unlimited-OCR-2/blob/main/Unlimited-OCR-2.pdf
• Unlimited-OCR-2 Model Card: https://huggingface.co/baidu/Unlimited-OCR-2
• DeepSeek-OCR, arXiv 2510.18234: https://arxiv.org/abs/2510.18234
• DeepSeek-OCR 2, arXiv 2601.20552: https://arxiv.org/abs/2601.20552
• PaddleOCR-VL, arXiv 2510.14528: https://arxiv.org/abs/2510.14528
• PaddleOCR-VL-1.5, arXiv 2601.21957: https://arxiv.org/abs/2601.21957
• PaddleOCR-VL-1.6, arXiv 2606.03264: https://arxiv.org/abs/2606.03264
• PaddleOCR 3.0 Technical Report, arXiv 2507.05595: https://arxiv.org/abs/2507.05595
• PP-OCRv6, arXiv 2606.13108: https://arxiv.org/abs/2606.13108
• PP-OCRv5 Multilingual Recognition Model (Official Documentation): https://www.paddleocr.ai/latest/en/version3.x/algorithm/PP-OCRv5/PP-OCRv5_multi_languages.html
• OmniDocBench, arXiv 2412.07626, repository and leaderboard: https://github.com/opendatalab/OmniDocBench
• MPDocBench-Parse, arXiv 2605.22100: https://arxiv.org/abs/2605.22100
• MarathonDocBench: https://huggingface.co/datasets/baidu/MarathonDocBench
• A800 80GB PCIe Specifications (Lenovo Press): https://lenovopress.lenovo.com/lp1813-thinksystem-nvidia-a800-80gb-pcie-gen4-gpu
• Myers, "A fast bit-vector algorithm for approximate string matching based on dynamic programming", Journal of the ACM, 1999