PaddleOCR-VL: Boosting Multilingual Document Parsing via a 0.9B Ultra-Compact Vision-Language Model

ArXiv: 2510.14528

🎯 Pitch

A 0.9-billion-parameter vision-language model doesn’t just match massive competitors in document parsing—it beats them, all while running 50% faster. PaddleOCR-VL achieves this by cleverly splitting the task between a lightweight layout detector and an ultra-compact recognition model, proving that bigger isn't always better for complex, multilingual documents.

---

1. Executive Summary

This report introduces PaddleOCR-VL, a resource-efficient document parsing solution centered on PaddleOCR-VL-0.9B, an ultra-compact vision-language model that pairs a NaViT-style dynamic-resolution visual encoder with the ERNIE-4.5-0.3B language model to perform fine-grained element recognition. Evaluated on OmniDocBench v1.0, v1.5, and olmOCR-Bench, the system decomposes document parsing into a two-stage pipeline—a dedicated layout analysis model for element detection and reading order prediction, followed by the compact VLM for recognizing text, tables, formulas, and charts across 109 languages. PaddleOCR-VL achieves state-of-the-art page-level results, including a top overall score of 92.86 on OmniDocBench v1.5 and an 80.0 unit-test pass rate on olmOCR-Bench, while simultaneously delivering 50–53% higher token throughput than the leading baseline, establishing that a carefully architected sub-billion-parameter VLM with a decoupled parsing pipeline can outperform both larger end-to-end VLMs and specialized ensemble systems on document understanding—provided robust layout analysis, targeted hard-case mining, and automated high-quality data annotation are integrated into the training recipe.

2. Context and Motivation

The Core Problem: Document Parsing Is Stuck Between Two Unsatisfactory Extremes

The paper addresses a fundamental tension in how we extract structured information from documents. Document parsing—the task of taking a PDF or image of a document and producing a faithful structured representation (typically Markdown or JSON) that captures text, tables, formulas, charts, reading order, and layout hierarchy—sits at the intersection of computer vision, natural language processing, and information retrieval. It is the gateway through which documents enter RAG pipelines, search indices, and LLM training corpora. Yet as of this paper's writing, the field is polarized between two approaches that each carry significant drawbacks.

The problem is not that document parsing doesn't work at all—it's that no existing approach simultaneously delivers high accuracy, broad language coverage, complex element handling, and practical deployment efficiency. Each available solution sacrifices at least one of these dimensions, and the sacrifices compound when documents become genuinely complex: multi-column layouts, mixed scripts, handwritten annotations, embedded charts, dense mathematical notation, and low-quality scans.

This gap matters enormously for real-world deployment. Documents are the primary format for scientific literature, legal contracts, financial reports, educational materials, government records, and historical archives. The volume of such documents grows exponentially, and organizations across every sector—from academic publishers ingesting millions of papers to law firms processing discovery documents to financial institutions extracting data from annual reports—need reliable, fast, and resource-efficient parsing that handles the full spectrum of content types. When parsing fails, downstream consequences cascade: RAG systems retrieve corrupted text, LLMs hallucinate from malformed tables, and structured data extraction pipelines propagate errors across entire workflows.

The Two Dominant Paradigms and Their Failure Modes

The paper identifies two broad technological approaches to document parsing (Section 1), each with characteristic weaknesses that motivated PaddleOCR-VL's design.

Pipeline Methods: Accurate but Brittle, Complex, and Error-Prone

The first approach, exemplified by systems like MinerU-pipeline, PP-StructureV3, Docling, and Mathpix, decomposes document parsing into a sequence of specialized, modular expert models: one model for layout detection, another for text recognition, another for table extraction, yet another for formula parsing, and so on. These specialized models—often trained on narrow, high-quality datasets for their specific subtask—can achieve strong individual performance. PP-StructureV3, for instance, reports an overall score of 86.73 on OmniDocBench v1.5, competitive with much larger models.

However, the paper identifies three structural problems with this approach. First, integration complexity: stitching together outputs from multiple independent models requires careful engineering to handle bounding box overlaps, coordinate system conversions, format normalization, and edge cases where one model's output contradicts another's. Second, cumulative error propagation: an error in layout detection—a misclassified text block as a table, or a missed formula region—cascades through the entire pipeline. If the layout model fails to detect a table, no downstream table recognition model can recover it. The paper does not quantify this error propagation rate, but the implication is that pipeline accuracy is bounded by the product of each stage's accuracy, making high overall performance fragile. Third, inflexibility: adding support for a new element type (say, chemical structure diagrams or musical notation) requires developing, training, and integrating a new specialized model into the pipeline, which is costly and slow.

These limitations mean that pipeline methods, while often strong on standard benchmarks, degrade unpredictably on out-of-distribution or highly heterogeneous documents—precisely the type encountered in real-world, large-scale document processing.

End-to-End VLM Methods: Flexible but Resource-Heavy and Hallucination-Prone

The second approach, represented by models like MonkeyOCR, MinerU2-VLM, olmOCR, SmolDocling, and general VLMs like GPT-4o, Qwen2.5-VL, and InternVL3, treats document parsing as a sequence-to-sequence task: an image of a document page goes in, and a structured text representation (usually Markdown) comes out. This end-to-end formulation is elegant—it eliminates the complexity of pipeline integration, enables joint optimization across subtasks, and theoretically can handle novel element types without architectural changes.

Yet the paper identifies critical shortcomings that prevent these methods from being practical in resource-constrained or high-throughput settings. First, the long-sequence decoding problem: producing a complete structured representation of a complex document page requires generating thousands of tokens autoregressively. The paper notes this "results in high latency and memory consumption, and increases the risk of unstable layout analysis and hallucinations—problems that are particularly pronounced in multi-column or mixed text–graphic layouts" (Section 2.1.1). The decoder's size directly determines inference speed, and large VLMs (7B, 72B, or 76B parameters) are inherently slow at this task regardless of optimization.

Second, hallucination and ordering instability: end-to-end models sometimes generate text that isn't present in the document, reorder content incorrectly, or produce structurally invalid outputs. The paper observes that these models "often struggle with correct text order and can even generate hallucinations when faced with lengthy or complex layouts" (Section 1). This is a subtle but devastating failure mode: a table that looks correct but contains fabricated numbers is far worse than a table marked as unrecognized, because downstream consumers have no way to detect the fabrication without manual verification.

Third, resource requirements: deploying a 72B-parameter VLM for document parsing is prohibitively expensive for many use cases. The inference performance benchmarks in Table 13 quantify this: even optimized VLMs running on vLLM or SGLang achieve 0.67–1.06 pages per second on an A100 GPU, whereas PaddleOCR-VL achieves 1.62 pages per second. The difference compounds when processing millions of documents.

Fourth, resolution constraints: earlier document parsing models based on fixed-resolution or tiling-based approaches (Section 2.1.2, citing GOT, MinerU2-VLM, and POINTS-Reader) necessarily either downsample high-resolution document images—losing fine text, small subscripts, or dense table cell content—or tile the image into patches, which can break cross-tile structural relationships and introduce boundary artifacts. The paper's adoption of NaViT-style native dynamic resolution is a direct response to this limitation.

Unresolved Tensions in Prior Work

Beyond the high-level paradigm split, the paper's motivation is sharpened by several specific unresolved challenges that prior work either ignored or addressed only partially.

Multilingual document parsing remains rare. While many models claim multilingual support, the paper's systematic In-house-OCR evaluation across 109 languages (Table 6a) reveals substantial gaps. Competing specialized models show normalized edit distances of 0.60–0.92 on Arabic, Tamil, Telugu, and Devanagari scripts—essentially near-complete failure—while performing adequately on Latin script (0.02–0.06). This script-level disparity means that document parsing technology has a built-in Western-language bias, excluding a vast corpus of non-Latin-script documents from reliable automated processing. The paper positions its comprehensive multilingual support not as an accessory feature but as a core requirement for global document processing.

Chart recognition is conspicuously absent from most document parsers. Section D.7 notes that "PaddleOCR-VL demonstrates impressive chart recognition capabilities, a feature currently lacking in many expert OCR VLMs like MinerU2.5, dots.ocr or MonkeyOCR." Charts are abundant in financial reports, scientific papers, and business documents, yet the dominant document parsing models simply ignore them—treating chart regions as generic images and producing a placeholder rather than extracting the underlying data. This is a significant gap because the data within charts (not just the visual representation) is what downstream analytics and RAG systems need. Converting a bar chart into a structured Markdown table, as PaddleOCR-VL does, transforms an opaque visual element into queryable data.

Handwritten and historical documents challenge existing systems. The Ocean-OCR-Handwritten benchmark (Table 7) reveals that models like GOT, which is designed for general OCR, achieve edit distances of 0.40–0.62 on handwritten Chinese and English—essentially garbled output. Even specialized OCR systems like PaddleOCR (the predecessor, not PaddleOCR-VL) reach only 0.33–0.42. The paper's handwritten text samples in Appendix D.4.2 (Figures A20–A21) show the model correctly transcribing Chinese calligraphy notes and mixed printed-handwritten documents, a capability that expands the addressable use cases to archival digitization, historical document processing, and handwritten form extraction.

Verification and evaluation frameworks are inconsistent. The paper highlights that competing methods are evaluated on different benchmarks with different metrics, making direct comparison difficult. olmOCR-Bench addresses this by providing machine-verifiable unit tests that "avoid biased evaluations and soft metric comparisons" (Section 4.1), but it was only recently introduced. OmniDocBench v1.0 and v1.5 provide comprehensive metrics, but even here, the paper notes annotation quality issues: in OmniDocBench v1.0, the paper attributes lower Table TEDS scores for English to "typo-related annotation errors" in the benchmark itself (Table 3), not model failures. This points to a broader problem in the field: benchmark quality limits our ability to accurately assess model quality, and models may be penalized for correctly recognizing text that was annotated incorrectly.

How This Paper Positions Itself

PaddleOCR-VL's design philosophy can be understood as a hybrid that strategically borrows from both paradigms while systematically addressing their weaknesses. The paper is not claiming that either pipeline methods or end-to-end VLMs are fundamentally wrong—rather, it argues that certain subtasks are better suited to different architectures, and that a thoughtful decomposition can outperform both pure approaches.

Specifically, the paper makes the following positioning claims:

Layout analysis is better served by a dedicated, lightweight model than by an end-to-end VLM. The rationale in Section 2.1.1 is multi-layered: layout detection operates at a coarser visual granularity than text recognition, requires lower input resolution, and benefits from architectures (like RT-DETR) specifically designed for object detection with explicit geometric relationship modeling. Attempting to fold layout analysis into a VLM's autoregressive decoding process introduces unnecessary sequence length (more tokens for bounding box coordinates and layout descriptions), increases hallucination risk for structural relationships (reading order is notoriously difficult for LLMs to maintain over long contexts), and ties layout quality to language model scale. By decoupling layout analysis into PP-DocLayoutV2—an RT-DETR-based detection model combined with a lightweight pointer network for reading order—the paper achieves stable, accurate layout analysis with "significantly fewer parameters" than VLM-based alternatives and avoids the instability that "may arise in end-to-end approaches" (Section 2.1.1).

Element recognition benefits from a VLM, but the VLM can be dramatically smaller than prevailing wisdom suggests. The paper's most striking architectural claim is that a 0.9B-parameter VLM can outperform 72B+ general VLMs and 3–7B specialized VLMs on document element recognition tasks. This challenges the implicit assumption that VLM capability scales monotonically with parameter count for document understanding. The paper attributes this efficiency to three design choices: (1) the NaViT-style native dynamic resolution encoder, which avoids the information loss of fixed-resolution or tiling-based approaches; (2) the deliberate balance between vision encoder scale and language model scale, rather than pairing a massive vision encoder with a tiny language model or vice versa; and (3) the use of ERNIE-4.5-0.3B, a language model "that balances a relatively small number of parameters with strong inference efficiency" (Section 2.1.2), where the compact decoder directly translates to faster token generation.

Training data quality, not just quantity, is the decisive factor. The paper dedicates an entire section (Section 3) to its data construction methodology, signaling that the training pipeline is as important as the model architecture. The approach combines four data sources (open-source, synthetic, web-crawled, in-house), automated annotation via expert models followed by VLM refinement, hallucination filtering, and—critically—a systematic hard-case mining process. Section 3.3 describes an evaluation engine that categorizes model errors into fine-grained element types (23 text categories, 20 table categories, 4 formula categories, 11 chart categories), then synthetically generates targeted training data for categories where the model underperforms. This creates a positive feedback loop: training improves the model, evaluation identifies remaining weaknesses, targeted synthesis addresses those weaknesses, and the cycle repeats. The paper frames this not as a one-time data construction effort but as a methodology "for constructing high-quality datasets, providing a solid train data foundation" (Section 1) that can be applied continuously as new document types and edge cases are discovered.

Practical deployment is a first-class design constraint, not an afterthought. The paper repeatedly emphasizes inference speed, GPU memory consumption, and hardware flexibility (Table 13, Appendix C). The inference optimization strategy—multi-threaded asynchronous execution with staged queues, batch aggregation across pages, and tuning of max-num-batched-tokens and gpu-memory-utilization—is not simply an engineering footnote but a core part of the system's value proposition. PaddleOCR-VL is positioned as deployable on hardware ranging from data-center H800 GPUs down to consumer RTX 3060 and 4090D GPUs (Table A2), achieving 0.36–2.23 pages per second depending on the hardware. This broad hardware compatibility addresses the resource-constrained deployment scenarios mentioned in the introduction, where "widespread application of multimodal document parsing, particularly in resource-constrained environments" has been hindered by the computational demands of existing VLMs.

The paper does not claim to have invented any individual component. The architecture combines known building blocks: NaViT (Dehghani et al., 2023), RT-DETR (Zhao et al., 2024), pointer networks with geometric bias from Relation-DETR (Hou et al., 2024), LLaVA-style projector-plus-LLM integration (Liu et al., 2023), and ERNIE-4.5 as the language backbone. The novelty lies in how these components are composed, scaled, and trained together to achieve an accuracy-efficiency Pareto frontier that no prior work reached. The paper positions itself as an engineering contribution that demonstrates what is possible when architecture design, data construction methodology, and deployment optimization are co-designed rather than treated independently.

The Broader Implications

Beyond the specific document parsing task, PaddleOCR-VL carries implications for how the field thinks about vision-language model scaling. The dominant narrative in multimodal AI has been that bigger models are better: GPT-4o, Gemini 2.5 Pro, InternVL3.5-241B, and Qwen2.5-VL-72B represent billions to hundreds of billions of parameters, and the assumption is that document understanding—like other VLM tasks—requires this scale. PaddleOCR-VL's 0.9B parameters achieving superior results on OmniDocBench v1.5 (92.86 vs. 88.03 for Gemini 2.5 Pro and 87.02 for Qwen2.5-VL-72B) challenges this narrative. It suggests that for well-defined, structured-output tasks where high-quality training data can be systematically generated, task-specific optimization may be more important than raw model scale. This is not a universal claim—the paper does not suggest 0.9B models can match 72B models on open-ended visual reasoning or creative generation—but for document parsing specifically, the evidence is compelling.

3. Technical Approach

3.1 Reader Orientation

PaddleOCR-VL is a two-stage document parsing system that first analyzes the layout structure of a document page to locate and order its semantic elements, then feeds each cropped element into a compact 0.9B-parameter vision-language model that recognizes its content and converts it into structured Markdown. The paper is primarily a systems and engineering contribution whose core idea is that a carefully architected sub-billion-parameter VLM, when trained with systematic data curation, automated annotation, and targeted hard-case mining, can outperform much larger general-purpose VLMs on document parsing by decomposing the problem into layout analysis (best done by a dedicated lightweight detector) and element recognition (best done by a compact VLM optimized for high-resolution dense text) rather than forcing a single end-to-end model to handle both simultaneously.

3.2 Big-Picture Architecture (Diagram in Words)

The system has four major components, connected in a sequential pipeline:

1. PP-DocLayoutV2 (Layout Analysis) — a dedicated, lightweight model composed of an RT-DETR-based object detector for localizing and classifying layout elements (text blocks, tables, formulas, charts, images) and a pointer network that predicts the reading order among those elements. It takes a document page image as input and outputs a set of bounding boxes with class labels and a topologically consistent ordering.

2. Element Cropper (Implicit, not a learned module) — uses the predicted bounding boxes from the layout model to segment the page image into individual element sub-images. Each cropped element is routed to PaddleOCR-VL-0.9B for recognition, with the element type determining which task-specific instruction prompt the VLM receives.

3. PaddleOCR-VL-0.9B (Element Recognition) — the core vision-language model that performs fine-grained recognition of text, tables, formulas, and charts. It takes a cropped element image and a task-specific instruction (e.g., "Recognize the text in this image" or "Parse this table into OTSL format") and outputs a structured text representation.

4. Post-Processing Aggregator (Lightweight) — a non-learned module that collects the recognition outputs from all elements, orders them according to the reading order from PP-DocLayoutV2, and formats the complete document into structured Markdown and JSON.

Information flows as follows: a document page (rendered from PDF or as an image) enters the system → PP-DocLayoutV2 detects elements and predicts their reading order → each element is cropped based on its bounding box → PaddleOCR-VL-0.9B receives each crop with an appropriate instruction prompt and produces structured text → the post-processor assembles all element outputs into the final document, preserving the reading order.

3.3 Roadmap for the Deep Dive

• First, the layout analysis model (PP-DocLayoutV2), including its RT-DETR detection backbone, the pointer network for reading order prediction, and the two-stage training procedure — because layout analysis is the first stage of the pipeline and errors here cascade into all downstream recognition.
• Second, the PaddleOCR-VL-0.9B architecture in detail: the NaViT-style dynamic-resolution visual encoder, the MLP projector, the ERNIE-4.5-0.3B language model with 3D-RoPE positional encoding, and the rationale for the specific scale balance between vision and language components.
• Third, the training recipe for PaddleOCR-VL-0.9B, including the two-stage curriculum (pre-training alignment on 29M image-text pairs followed by instruction fine-tuning on 2.7M task-specific samples), the hyperparameter configurations, and the four task-specific instruction formats (OCR, table recognition, formula recognition, chart recognition).
• Fourth, the data construction methodology: the four data sources (open-source, synthetic, web-crawled, in-house), the automated annotation pipeline using expert models and large VLMs with hallucination filtering, and the hard-case mining process that uses fine-grained evaluation to identify weaknesses and synthetically generate targeted training data.
• Fifth, the inference optimization strategy: the multi-threaded asynchronous execution architecture, batch aggregation across pages, and backend-specific tuning for vLLM, SGLang, and FastDeploy.

3.4 Detailed, Sentence-Based Technical Breakdown

This is a systems paper describing a complete document parsing pipeline. The core contributions are (1) the architectural decomposition of document parsing into separate layout analysis and element recognition stages, (2) the design of PaddleOCR-VL-0.9B as an ultra-compact VLM for element recognition, and (3) the systematic data construction and hard-case mining methodology that enables strong performance with limited model capacity.

---

PP-DocLayoutV2: Layout Analysis via Detection and Pointer Network

Layout analysis is the task of taking a document page image and producing (a) the bounding boxes and semantic class labels of all content elements, and (b) the correct reading order among those elements. PaddleOCR-VL treats this as a purely visual task, handled by a dedicated model that operates independently of the recognition VLM. The motivation for this decomposition is stated in Section 2.1.1: end-to-end VLM approaches that generate both layout coordinates and content autoregressively "result in high latency and memory consumption, and increase the risk of unstable layout analysis and hallucinations—problems that are particularly pronounced in multi-column or mixed text–graphic layouts."

PP-DocLayoutV2 is architecturally a two-stage sequential network. The first stage is an object detection model based on RT-DETR (Zhao et al., 2024), a real-time detection transformer that predicts bounding boxes and class labels for each layout element. The paper uses PP-DocLayout_Plus-L pretrained weights for initialization, which is a previously developed layout detection model from the same team. The detection model performs per-class thresholding to select foreground proposals — this filtering step ensures that only high-confidence detections proceed to the ordering stage, preventing low-quality proposals from corrupting the reading order.

The second stage is a pointer network with six transformer layers that takes the filtered set of detected elements and predicts their reading order. The pointer network receives as input each detected element represented by its absolute 2D positional encoding and a learned class label embedding. The handling of geometric relationships is notably explicit: the encoder attention incorporates a geometric bias mechanism adapted from Relation-DETR (Hou et al., 2024). This mechanism explicitly models pairwise geometric relationships among elements rather than relying on the attention mechanism to implicitly learn spatial relationships from coordinates alone. The pairwise relation head linearly projects element representations into query and key vectors, then computes bilinear similarities to produce pairwise logits. The output is an $N \times N$ matrix where each entry $(i, j)$ represents the relative order relationship between element $i$ and element $j$ — specifically, whether element $i$ should precede element $j$ in the reading order.

The final decoding step uses a deterministic win-accumulation algorithm to recover a topologically consistent total ordering from the pairwise relationship matrix. The paper does not detail the win-accumulation algorithm, but the general principle is: for each pair of elements, determine which one "wins" (should come first) based on the pairwise logits; then sort elements by their total number of wins to produce a consistent order. This is different from simply predicting a sequence index for each element because it can handle cases where the pairwise relationships are not perfectly transitive — the deterministic decoding enforces consistency.

The training follows a two-stage strategy. In the first stage, the RT-DETR detection model is trained for 100 epochs on a self-constructed dataset of "over 20,000 high-quality samples" for layout element detection and classification, initialized from PP-DocLayout_Plus-L pretrained weights. After this stage, the detection model's parameters are frozen, and the pointer network is trained independently for 200 epochs. The pointer network training uses

$\mathcal{L}_{\text{order}} = \text{Generalized Cross Entropy Loss}$

where the loss is computed between the predicted pairwise ordering matrix and the ground-truth pairwise ordering labels. The paper specifically states they use the Generalized Cross Entropy Loss formulation from Zhang and Sabuncu (2018) because "this loss function demonstrates increased robustness in scenarios where pre-annotated data are mixed into the dataset." The pointer network is trained with a constant learning rate of $2 \times 10^{-4}$ using the AdamW optimizer.

What the loss computes: the Generalized Cross Entropy (GCE) loss is a modified cross-entropy that applies a Box-Cox transformation to the predicted probabilities before computing the negative log-likelihood. For a prediction probability $p$ and a target class $y$, standard cross-entropy is $-\log(p_y)$; GCE replaces $\log(p_y)$ with a term like $\frac{1 - p_y^q}{q}$ for a hyperparameter $q$. When $q \to 0$, GCE reduces to standard cross-entropy; when $q > 0$, the loss downweights the contribution of high-loss examples, making it more robust to label noise.

Why this form: training the pointer network involves "pre-annotated data" — data where reading order labels may have been generated automatically rather than manually verified. Standard cross-entropy would treat every label as equally trustworthy, allowing noisy labels to dominate the gradient during training. GCE reduces the influence of examples where the model's prediction strongly disagrees with the label, under the assumption that such disagreements are more likely to be label errors than model failures on well-annotated data. This is particularly important for reading order, where automated annotation systems (e.g., top-to-bottom, left-to-right heuristics) can produce systematically wrong labels for complex multi-column layouts, and a loss function that is too sensitive to these errors would learn to replicate the heuristic's mistakes.

The paper contrasts PP-DocLayoutV2 with LayoutReader (Wang et al., 2021), another specialized reading-order model, claiming that PP-DocLayoutV2 "achieves higher performance with fewer parameters by efficiently extending RT-DETR with a pointer network." The key efficiency insight is that reusing the detection model's visual features as input to the pointer network avoids duplicating the visual encoding step that a standalone reading order model would require.

---

PaddleOCR-VL-0.9B: Vision-Language Architecture for Element Recognition

PaddleOCR-VL-0.9B is the core recognition model that processes cropped element images and outputs structured text representations. Its architecture follows the general pattern established by LLaVA (Liu et al., 2023): a vision encoder extracts features from the input image, a projector maps those features into the language model's embedding space, and a pre-trained language model generates the output text autoregressively. However, the specific choices for each component, their scales, and their interaction are carefully optimized for the document parsing domain.

The total model size is 0.9B parameters, but the paper does not provide an exact breakdown between vision encoder, projector, and language model parameter counts. Given that the language model backbone is ERNIE-4.5-0.3B (300M parameters) and the projector is a 2-layer MLP (relatively few parameters), the vision encoder accounts for the majority of the remaining parameters — roughly 500–600M.

Vision Encoder: NaViT-Style Native Dynamic Resolution

The vision encoder is initialized from Keye-VL's vision model (Kwai Keye Team, 2025) and is described as "NaViT-style" (Dehghani et al., 2023). NaViT, which stands for "Native Resolution Vision Transformer," departs from the standard ViT practice of resizing or padding all input images to a fixed resolution before processing. Instead, NaViT processes images at their native aspect ratio and resolution by packing variable-length sequences of image patches into a single batch using a technique called "Patch n' Pack."

The core idea of NaViT is that standard ViTs require all images in a batch to have the same number of patches because attention computation uses fixed-size tensors. Resizing to a fixed square resolution (e.g., 224×224, 336×336) distorts aspect ratios and can downsample high-resolution document images to the point where small text becomes illegible. Tiling approaches divide the image into fixed-size overlapping tiles, process each tile independently, and then merge the results — but this breaks cross-tile spatial relationships and introduces boundary artifacts where text spans multiple tiles.

NaViT addresses this by allowing each image to contribute a variable number of patches, determined by its native resolution modulo patch size. If the patch size is $P \times P$ pixels and the input image is $H \times W$ pixels, NaViT produces $\lceil H/P \rceil \times \lceil W/P \rceil$ patches, preserving the original aspect ratio. Multiple images with different patch counts are packed into a single batch by concatenating their patch sequences and using an attention mask that prevents cross-image attention. Positional embeddings are computed on-the-fly for each patch based on its 2D coordinates in the original image.

The paper states that the maximum resolution supported during Stage 1 training is 1280 × 28 × 28 and during Stage 2 training is 2048 × 28 × 28. The "28" here refers to the patch size in pixels — the vision encoder uses a 28×28 pixel patch. This means Stage 1 supports images up to $1280 \times 28 = 35840$ pixels in total area (e.g., roughly $190 \times 190$ patches), and Stage 2 supports up to $2048 \times 28 = 57344$ pixels in total area (e.g., roughly $240 \times 240$ patches). The maximum resolution is expressed as a total number of patches rather than a fixed height and width because NaViT supports any aspect ratio — a very wide but short document (e.g., a landscape table) can use a 500×40 patch configuration, while a very tall but narrow document (e.g., a single-column text page) can use a 150×150 configuration, as long as the total patch count stays within the budget.

The paper explicitly claims this design "enables the vision-language model to handle images of arbitrary resolution without distortion, yielding fewer hallucinations and stronger performance on text-intensive tasks." The mechanism for this improvement is twofold: (1) the native resolution preserves fine details in dense text regions, preventing the model from having to hallucinate illegible characters that were downsampled away, and (2) the aspect ratio preservation maintains the spatial layout of text lines and columns, which is essential for correctly ordering recognized text and for distinguishing between genuinely adjacent content and content that only appears adjacent because of aspect ratio distortion.

Projector: 2-Layer MLP with GELU and Patch Merging

The projector bridges the vision encoder's output features and the language model's token embedding space. It is a randomly initialized 2-layer MLP with GELU (Gaussian Error Linear Unit) activation. GELU is a smooth approximation to the ReLU activation function, defined as

$\text{GELU}(x) = x \cdot \Phi(x)$

where $\Phi(x)$ is the cumulative distribution function of the standard normal distribution. GELU weights inputs by their magnitude rather than applying a hard threshold at zero, which provides non-zero gradients for negative inputs (unlike ReLU) and has been found to improve training stability in transformer-based models.

The projector incorporates a merge size of 2, which means it combines every 2 neighboring visual feature tokens into a single token before passing them to the language model. This is a downsampling operation that reduces the sequence length of visual tokens by a factor of 2 (in each spatial dimension, so typically a factor of 4 total for 2D feature maps after accounting for the way merge operations are applied). The purpose is to reduce the computational cost of the language model's attention over visual tokens: if the vision encoder produces $N$ patch tokens, merging with size 2 reduces this to approximately $N/4$ tokens. For a high-resolution document image with thousands of patches (e.g., $200 \times 200 = 40,000$ patches at maximum resolution), this reduction is critical for keeping the language model's context length manageable, since the language model's self-attention has quadratic complexity in sequence length.

Language Model: ERNIE-4.5-0.3B with 3D-RoPE

The language model backbone is ERNIE-4.5-0.3B, an open-source language model from Baidu with approximately 300M parameters. The paper chooses this model specifically because "in auto-regressive language models, the entire sequence is generated by predicting one token at a time. This approach means that the size of the decoder is directly linked to the overall inference latency, so a smaller model will decode faster." This is a crucial design consideration: for document parsing, the VLM must generate potentially thousands of output tokens (a complete Markdown representation of a complex table or a multi-paragraph text block), and the autoregressive decoding step is strictly serial — each token depends on all previous tokens and cannot be parallelized. The time per generated token scales roughly with the number of parameters in the language model, so a 0.3B decoder will generate tokens roughly 20–240× faster than 7B–72B decoder models, assuming comparable architecture efficiency.

The paper enhances the language model's positional encoding by incorporating 3D-RoPE (3D Rotary Position Embedding), adapted from Qwen2.5-VL (Bai et al., 2025). Standard rotary position embeddings (RoPE) encode 1D position information (token index) by applying a rotation to the query and key vectors in self-attention,

$q_m = R_m \cdot q, \quad k_n = R_n \cdot k$

where $R_m$ is a rotation matrix parameterized by position $m$, and the attention score between query at position $m$ and key at position $n$ depends on the relative position $m - n$. This encodes 1D sequential order.

3D-RoPE extends this to encode three positional dimensions simultaneously: the 2D spatial position $(h, w)$ of each visual patch within the image, and the temporal/sequential position $t$ of each text token in the sequence. Each visual token receives a 2D position encoding that captures its spatial location, while each text token receives a 1D position encoding. The attention mechanism then computes three separate rotary components that are combined (typically through summation or concatenation of the attention logits). The paper does not specify the exact combination method, but the standard approach in Qwen2.5-VL is to apply the 2D RoPE to visual tokens and the 1D RoPE to text tokens, and when computing attention between a text query and a visual key (or vice versa), use both components.

Why this form: for document parsing, knowing where in the image a visual feature comes from is essential. A text token should attend to the specific visual patches that contain the characters it is trying to read, not to arbitrary patches across the image. Standard 1D RoPE would position visual tokens only by their index in the flattened patch sequence, which loses the 2D spatial structure (a patch at $(10, 5)$ and a patch at $(5, 10)$ would have similar 1D positions if the image is roughly square, but they are in entirely different regions). 3D-RoPE preserves this spatial locality: attention scores naturally decay with spatial distance, so the model learns to attend preferentially to nearby visual features when generating text about a specific image region. This is particularly important for table recognition, where the model must map specific visual cells to their row and column positions, and for multi-column text layouts, where the model must read one column at a time without confusing text from adjacent columns.

Architecture Rationale: Why This Specific Balance

The paper claims that "our architecture achieves a balance the scale of vision and language models to optimize performance in multi-elements recognition tasks." The implicit design principle is that the vision and language components should be scaled proportionally so that neither creates a bottleneck. A massive vision encoder with a tiny language model would produce rich visual features that the language model cannot effectively use because its limited capacity prevents it from learning the complex mapping from visual features to structured text. Conversely, a tiny vision encoder with a massive language model would produce impoverished visual features that lose fine-grained document details, forcing the language model to hallucinate missing information.

The paper's configuration — a vision encoder of roughly 500–600M parameters paired with a 300M-parameter language model — represents roughly a 2:1 vision-to-text ratio. This is a deliberate departure from VLMs like LLaVA, which often pair a 300M-parameter vision encoder (ViT-L) with a 7B-parameter language model (a 1:23 ratio biased heavily toward language capacity), or from InternVL3-78B, which pairs a ~6B vision encoder with a ~72B language model. The paper's hypothesis, validated by the benchmark results, is that document parsing is vision-intensive: the bottleneck is extracting accurate fine-grained visual information (individual characters, table cell separators, formula subscripts) rather than complex multi-step reasoning over that information. Therefore, the vision encoder should be proportionally larger relative to the language model than in general VLMs designed for tasks like visual question answering or image captioning, where high-level semantic understanding of scenes matters more than pixel-level character recognition.

---

Training Recipe for PaddleOCR-VL-0.9B

The training of PaddleOCR-VL-0.9B follows a two-stage curriculum designed to first align the vision and language representations on a broad dataset, then specialize the model for specific document parsing tasks with higher-resolution, task-specific data. Both stages train all model components (vision encoder, projector, and language model) — the paper specifies "Trainable components: All" for both stages in Table 1.

Stage 1: Pre-Training Alignment

Stage 1 is a single epoch of training on 29 million high-quality image-text pairs. The purpose is to establish a "coherent understanding between diverse visual inputs and their semantic textual content" — in practice, this means teaching the randomly initialized projector to map vision encoder features into the language model's token embedding space in a way that produces semantically meaningful text, while also fine-tuning the vision encoder and language model to work well together.

Training hyperparameters for Stage 1 (Table 1):

• Maximum resolution: 1280 × 28 × 28 (total patch count per image)
• Sequence length: 16,384 tokens (the maximum total context length including both visual tokens, projected through the merge-2 MLP, and text tokens)
• Batch size: 128 (the number of image-text pairs per gradient update, presumably using gradient accumulation if GPU memory is insufficient for true batch size 128)
• Data augmentation: enabled (the paper does not specify which augmentations; typical document image augmentations include random rotation, slight perspective transforms, color jitter, JPEG compression artifacts, and noise to simulate scan quality variation)
• Maximum learning rate: $5 \times 10^{-5}$
• Minimum learning rate: $5 \times 10^{-6}$
• Epochs: 1

The learning rate schedule is a cosine decay from the maximum to the minimum learning rate over the course of the epoch. The paper uses the ERNIEKit repository (PaddlePaddle Authors, 2025) for training, which is the training framework for the ERNIE model family.

What 29M image-text pairs means in practice: this is a very large dataset by document parsing standards, and the paper's data construction methodology (Section 3, detailed in Appendix A) explains how these pairs were curated. The dataset includes text recognition samples at three hierarchical levels (text lines, text blocks, text pages), table recognition samples in OTSL format, formula recognition samples in LaTeX, and chart recognition samples as Markdown tables, spanning 109 languages and diverse document types. The scale matters because it provides broad coverage of visual styles, languages, fonts, and document degradation types, reducing the risk that the model overfits to specific data characteristics during fine-tuning.

Stage 2: Instruction Fine-Tuning

Stage 2 is two epochs of training on a curated dataset of 2.7 million samples that are "intentionally designed to be highly rich and diverse in its distribution." The purpose is to adapt the model's general multimodal understanding to the specific downstream element recognition tasks, and to expose the model to higher-resolution images than those used in Stage 1.

Training hyperparameters for Stage 2 (Table 1):

• Maximum resolution: 2048 × 28 × 28 (increased from Stage 1's 1280)
• Sequence length: 16,384 tokens (unchanged)
• Batch size: 128 (unchanged)
• Data augmentation: enabled (unchanged)
• Maximum learning rate: $5 \times 10^{-6}$ (10× lower than Stage 1)
• Minimum learning rate: $5 \times 10^{-7}$ (10× lower than Stage 1)
• Epochs: 2

The lower learning rate reflects the fine-tuning objective: Stage 1 moves parameters significantly to establish cross-modal alignment; Stage 2 makes smaller, more careful adjustments to avoid catastrophic forgetting of the broad alignment while specializing for task-specific patterns. The increased maximum resolution (2048 vs. 1280, a 60% increase in maximum patch count) exposes the model to more detailed document images during the task-specific phase, which is important because document elements (especially dense tables and formulas with small subscripts) benefit from seeing higher-resolution details.

During Stage 2, the model is trained with explicit task instructions for four distinct recognition tasks. The paper describes these instructions in Section 2.2.2:

1. OCR (Optical Character Recognition): The instruction fine-tunes the model to "accurately identify and extract textual content from images, encompassing individual characters, words, text lines, text blocks and simple layout structure of page-level texts." This means the training data includes OCR examples at multiple granularities: the model learns to output a single character given a character image, a word string given a word image, a single line of text given a line image, a text block (multiple lines with layout information) given a block image, and a page-level text structure (with reading order and paragraph breaks) given a page-level text image. The output format for text-level OCR is plain text with whitespace and newline characters to preserve layout, while block-level OCR includes simple structural markers.

2. Table Recognition: The instruction fine-tunes the model to "parse tabular structures within documents ... accurately extracting cell contents, identifying rows and columns, and recognize the logical relationships between different table elements, ultimately generating structured representations based on OTSL format." OTSL stands for Optimized Table Sequence Language (Lysak et al., 2023), a tokenization scheme designed for table structure recognition. OTSL represents a table as a linear sequence of tokens that encodes both the cell content and the structural relationships (row and column spans, header separators, merging patterns). The paper adopts OTSL rather than HTML because it is "more computationally efficient for decoding" — HTML uses verbose opening and closing tags that dramatically increase the number of tokens the language model must generate, whereas OTSL uses a compact encoding where structural relationships are represented by a small set of special tokens inserted into the cell content stream.

3. Formula Recognition: The instruction focuses on enabling the model to "recognize and interpret mathematical and scientific formulas ... converting their visual representation into a structured LaTeX format and distinguishing between inline \(...\) and display \[...\] equations." The key design choice here is that the model must produce the correct LaTeX delimiter type (inline vs. display) in addition to the LaTeX expression itself. Inline formulas are typically small expressions embedded within a line of text (e.g., \(x^2 + y^2 = z^2\)), while display formulas are larger, centered equations on their own line (e.g., \[\sum_{i=1}^{n} i = \frac{n(n+1)}{2}\]). Distinguishing between these is important for proper rendering in downstream Markdown or LaTeX processors.

4. Chart Recognition: The instruction trains the model to "recognition information from various types of charts, such as bar charts, line graphs, and pie charts and convert Markdown format tables." This task is fundamentally different from the other three: instead of recognizing text or structure within a document, the model must interpret the data encoded in a visual chart and output a structured data table. The output is a Markdown-formatted table where the first column typically contains the x-axis categories and subsequent columns contain the y-axis values for each series. This is a surprisingly ambitious capability for a 0.9B-parameter model — general VLMs like GPT-4o and Qwen2.5-VL-72B can perform chart-to-table conversion, but the paper demonstrates that a compact model trained on high-quality chart data can match or exceed their performance.

The 2.7 million samples across four tasks represent a smaller dataset than Stage 1's 29M, but with higher quality and more targeted coverage. The paper does not provide the exact breakdown between the four tasks, but the data construction descriptions in Appendix A suggest text OCR comprises the largest share (20M image-text pairs for text, 5M for tables, unspecified but likely ~1M for formulas, 0.8M for charts), and the 2.7M fine-tuning samples are a filtered, high-quality subset.

---

Data Construction Methodology

The data construction methodology is presented as one of the paper's three main contributions, reflecting the authors' view that training data quality and coverage are as important to final performance as architectural decisions. The methodology consists of three phases: data curation (sourcing diverse raw data), automatic annotation (generating high-quality labels), and hard-case mining (identifying and addressing model weaknesses).

Data Curation: Four Complementary Sources

The paper sources data from four distinct origins (Section 3.1), each chosen to address specific coverage requirements:

1. Open Source Dataset: Established public datasets provide high-quality, manually annotated data but tend to be narrow in scope. The paper cites specific sources for each element type: CASIA-HWDB for handwriting, UniMER-1M and MathWriting for mathematical expressions, and ChartQA, PlotQA, Chart2Text, DVQA, Unichart, Beagle, ChartINFO, visText, and ExcelChart for charts. Each source "underwent an initial filtering and cleaning protocol to rectify or discard noisy and low-quality annotations." The filtering is necessary because public datasets often contain labeling errors, inconsistent annotation formats, or examples that are not representative of real-world documents (e.g., synthetic charts with unnaturally clean aesthetics).

2. Data Synthesizing Dataset: Because "the naturally imbalanced distribution of public data" means some content types, languages, or visual styles are underrepresented, the paper employs a data synthesizing strategy to generate missing data at low cost. The synthesis approach varies by element type: text synthesis uses diverse CSS styles, over 200 fonts, and various corpora to render text images; table synthesis uses a tool that randomizes structures, fonts, CSS styles, and textual content to generate "over 5,500,000 training instances" at a rate of 10,000 samples per hour; formula synthesis uses rule-based LaTeX code generation and inverse rendering via a LaTeX rendering engine; and chart synthesis uses "a billion distinct personas" to generate diverse data tables and persona-specific rendering code. The scale of synthesis is notable — it dwarfs the public data contribution in some categories (5.5M synthetic tables vs. the smaller public table datasets).

3. Network Accessible Dataset: "To improve model generalization and robustness against the complexities of unstructured real-world documents," the paper collects publicly accessible data from the internet, specifically citing academic papers, newspapers, formal scientific journal articles, scanned handwritten documents, diverse examination papers, and slides. This data source is crucial because it captures the visual and structural diversity of real-world documents that are not represented in clean benchmark datasets — yellowed paper, uneven lighting in photographs, watermarks, coffee stains, unusual fonts, and highly variable layout conventions. The paper does not specify who or what system performed this collection, but the description suggests a large-scale web crawl with document-type classification.

4. In-house Dataset: "Through years of research in the field of OCR, we have accumulated extensive datasets with diverse data types across all tasks of document parsing." This is an institutional asset that provides high-quality, internally curated data for tasks and domains where public data is insufficient. The paper states these are incorporated "with precisely controlled proportions, which have become unnecessary factors that enable our models to achieve outstanding performance." This likely means the in-house data is used to calibrate the training distribution, ensuring that key categories (specific languages, document types, or recognition challenges) are neither over- nor under-represented relative to their real-world frequency.

Automatic Data Annotation: Expert Models + VLMs + Filtering

For raw data that lacks labels, the paper employs a multi-stage automatic annotation pipeline (Section 3.2) designed to generate high-quality labels without expensive manual annotation.

The pipeline begins with expert model pre-annotation. PP-StructureV3, the authors' own pipeline-based document parsing system, performs preliminary processing to generate pseudo labels. These pseudo labels may contain errors — the paper explicitly notes they "may contain some inaccuracies" — but they provide a reasonable starting point that captures the basic structure and content.

These pseudo labels, together with the original image, are formatted into prompts and submitted to more advanced multimodal large language models for refinement. The paper specifically names ERNIE-4.5-VL and Qwen2.5-VL as the refiners. The prompts are designed through "prompt engineering" to guide the large VLMs to analyze the image content and correct or enhance the initial pseudo labels. The key insight is that large VLMs can leverage their general visual understanding capabilities to spot errors that the expert model made — for example, an expert OCR model might misread a degraded character, but a VLM can use surrounding context (the word it belongs to, the font style, the expected language) to infer the correct character.

The final annotation undergoes a hallucination filtering step, which "eliminates any potentially incorrect content generated by the large models." The paper does not specify the filtering mechanism in detail, but the named filtering strategies elsewhere in the paper include: n-gram analysis (checking whether generated text contains statistically unlikely character sequences that suggest hallucination), HTML validation (for table annotations, checking that the OTSL/HTML structure is syntactically valid), rendering-based verification (for formulas, checking that the generated LaTeX can be successfully rendered by xelatex and that the rendered image has a similar aspect ratio to the original), and consistency checks (for charts, verifying that extracted tick labels and data points are self-consistent).

Hard-Case Mining: Targeted Synthetic Data Generation from Evaluation Feedback

The hard-case mining process (Section 3.3) is the most innovative aspect of the data methodology. It transforms the one-shot data construction problem into a continuous improvement loop.

The process begins with an evaluation engine that classifies each evaluation sample into a fine-grained category. For text, there are 23 categories (including Chinese, English, printed, handwritten, Japanese, Latin, emojis, etc.). For tables, there are 20 categories (limited tables, unlimited tables, handwritten tables, checklists, invoices, rotated tables, etc.). For formulas, there are 4 categories (Chinese and English, handwritten and printed, simple and complex). For charts, there are 11 categories (Chinese and English, line charts, bar charts, bar-line hybrids, pie charts, etc.). This fine-grained categorization is important because model failure typically clusters in specific categories rather than being uniform across all samples.

The model is evaluated on this categorized evaluation set using appropriate metrics for each task: Edit Distance for text, TEDS (Tree Edit Distance-based Similarity) for tables, RMS-F1 (Root Mean Square F1) for charts, and BLEU for formulas. By analyzing the per-category metric scores, the system identifies "hard cases where the model performs poorly" — categories where the metric falls below a threshold (which the paper does not specify).

For identified weak categories, the system generates synthetic training data targeting precisely those categories. The synthesis leverages "a rich set of resources (such as Font Library, CSS Library, Corpus) and rendering tools (like XeLaTeX and web browsers)" to produce new examples that share the characteristics of the hard cases but with novel content. For example, if the evaluation shows poor performance on handwritten tables, the synthesis tool generates new handwritten table images using handwriting-style fonts, varied table structures, and diverse content. These synthetic examples are added to the training data, and the model is retrained or fine-tuned, theoretically improving performance on the previously weak categories.

This creates a positive feedback loop: training → evaluation → weakness identification → targeted synthesis → retraining → improved evaluation. The paper frames this as a methodology that "not only enables us to construct high-quality data on demand, but also provides a new perspective on the automated generation of high-quality data." The "on demand" aspect is crucial: instead of collecting all conceivable data upfront (which is impossible because the space of possible documents is infinite), the system discovers what it needs through evaluation and generates it.

---

Inference Optimization: Multi-Threaded Asynchronous Pipeline

The deployment infrastructure for PaddleOCR-VL is not an afterthought but a core component of its practical value proposition. The paper introduces a multi-stage asynchronous execution design that maximizes GPU utilization and throughput when processing large batches of documents.

The inference workflow is divided into three stages, each running in a separate thread (Section 4.3):

1. Data Loading: Rendering PDF pages as images, performing any necessary preprocessing (rotation correction, deskewing, color normalization), and queuing the rendered images for layout analysis.

2. Layout Model Processing: PP-DocLayoutV2 receives images from the data loading queue, detects and classifies layout elements, predicts reading order, and places the cropped element images (with task type metadata) into a queue for VLM inference.

3. VLM Inference: PaddleOCR-VL-0.9B processes batches of cropped elements, generating structured text outputs that are collected for final aggregation.

Data is transferred between adjacent stages via queues, enabling concurrent execution. While one batch of pages is being loaded, the layout model processes a previously loaded batch, and the VLM processes yet another batch of cropped elements. This pipelining eliminates idle time that would occur in a sequential implementation where each stage waits for the previous one to complete before starting.

Batch Aggregation Across Pages: A key optimization is that "batch processing is only triggered when either the number of items in the queue reaches a predefined threshold or the waiting time for queued data exceeds a specified limit. This design allows blocks across different pages to be aggregated and processed together, thereby maximizing parallelism, especially when handling large volumes of files." This addresses a classic utilization problem: individual pages have widely varying numbers of elements (a page with many small text blocks might produce dozens of element crops, while a full-page figure produces one), so per-page batching would create small batches for simple pages, underutilizing the GPU. By pooling elements across pages into larger batches, the system maintains high GPU utilization regardless of per-page element count variance.

Backend-Specific Tuning: The paper evaluates three inference backends — FastDeploy, vLLM, and SGLang — and tunes parameters for each. The tuning focuses on two key VLM serving parameters:

• max-num-batched-tokens: This controls the maximum total token count (input + output) across all sequences in a batch. Increasing this value allows larger batches but consumes more GPU memory. Tuning involves finding the largest value that fits in available GPU memory without causing out-of-memory errors.

• gpu-memory-utilization: This controls what fraction of the GPU's memory the serving engine is allowed to use. Higher values leave less memory for the OS and other processes but allow larger KV caches, enabling larger batches and longer sequences. The paper tunes this to "balance inference throughput with GPU memory consumption."

The results in Table 13 show that FastDeploy achieves the highest throughput (1.62 pages/s, 2486.4 tokens/s on A100), followed by vLLM (1.35 pages/s, 2067.6 tokens/s) and SGLang (1.11 pages/s, 1707.8 tokens/s). The paper notes that FastDeploy is their own deployment framework, and these results demonstrate that custom inference optimization can yield substantial throughput improvements over general-purpose VLM serving engines, even when those engines use state-of-the-art techniques like PagedAttention (vLLM) and RadixAttention (SGLang).

---

Summary of Design Choices and Their Justifications

• Decoupled layout analysis from element recognition: layout analysis operates at coarser visual granularity, requires lower input resolution, and benefits from non-autoregressive architectures designed for detection and ordering, while VLM-based layout analysis introduces sequence length overhead, hallucination risk, and instability in multi-column layouts.

• NaViT-style native dynamic resolution over fixed-resolution or tiling: preserves aspect ratios and fine-grained visual details in dense text without the information loss of downsampling or the boundary artifacts of tiling, which is essential for accurate recognition of small text, subscripts, and dense table cells.

• 2:1 vision-to-language model scale ratio over 1:20+ ratios common in general VLMs: document parsing is vision-intensive (the bottleneck is extracting fine visual features, not complex reasoning over them), so the vision encoder should be proportionally larger relative to the language model.

• ERNIE-4.5-0.3B as language model over larger LLMs: the autoregressive decoding step is strictly serial and scales with model size, so a compact decoder directly reduces inference latency and increases throughput, which is critical for large-scale document processing.

• OTSL format for table output over HTML: OTSL uses a compact encoding with special structural tokens, reducing the number of output tokens the language model must generate compared to verbose HTML with opening and closing tags.

• Generalized Cross Entropy Loss for pointer network training: the reading order training data includes pre-annotated (automatically labeled) samples with potential label noise, and GCE downweights high-loss examples that are more likely to be label errors than model failures.

• Two-stage training curriculum (29M alignment → 2.7M fine-tuning): Stage 1 establishes broad cross-modal alignment across diverse document types, languages, and visual styles; Stage 2 specializes for specific tasks with higher resolution and task-specific instructions, using a lower learning rate to avoid catastrophic forgetting.

• Multi-threaded asynchronous execution with cross-page batch aggregation: maximizes GPU utilization by eliminating idle time between pipeline stages and pooling element crops across pages to form consistently large inference batches regardless of per-page element count variance.

• Evaluation-driven hard-case mining over static dataset construction: the space of possible documents is unbounded, so targeted synthetic data generation based on identified model weaknesses is more efficient and adaptive than attempting to pre-collect all conceivable document types.

4. Key Insights and Innovations

Innovation 1: Decomposing Document Parsing into Layout Analysis and Element Recognition Is a Strategic Architecture Choice, Not Just an Engineering Convenience

The field of document parsing has been polarized between two architectural approaches: pipeline methods that chain specialized expert models, and end-to-end VLMs that treat parsing as a single sequence-to-sequence task. PaddleOCR-VL's decision to decompose document parsing into a dedicated layout analysis stage (PP-DocLayoutV2) and a separate element recognition stage (PaddleOCR-VL-0.9B) might appear, at first glance, to be simply another pipeline — an incremental return to the modular approach after the VLM wave. But the paper makes a conceptually different argument about why this decomposition matters, and it is this argument — not the decomposition itself — that constitutes the intellectual contribution.

The dominant assumption in recent document parsing research, embodied by models like MonkeyOCR, olmOCR, POINTS-Reader, and SmolDocling, has been that end-to-end VLM processing is the natural endpoint for document understanding: a single model, trained jointly, producing structured output directly from page images. This assumption is appealing because it promises simplicity (no integration engineering), joint optimization (the model can learn interactions between layout and content), and extensibility (new element types require only new training data, not new expert models). The paper does not reject this assumption outright — it identifies a more nuanced failure mode.

The key diagnostic insight is that layout analysis and content recognition place fundamentally different demands on model architecture and training, and that forcing both into a single autoregressive decoding process introduces specific pathologies that are not simply "the model isn't big enough" problems that would resolve with more parameters. The paper identifies three such pathologies that are structural rather than capacity-limited:

First, the long-sequence correlation problem. When an end-to-end VLM generates layout coordinates followed by content for each element, the model must maintain a consistent mental map of the page across potentially thousands of output tokens. The paper observes that this leads to "unstable layout analysis and hallucinations—problems that are particularly pronounced in multi-column or mixed text–graphic layouts" (Section 2.1.1). This is not merely a capacity issue — it reflects a fundamental tension in autoregressive generation: the model generates tokens sequentially but must represent inherently 2D spatial relationships. The probability that a token at position 5000 in the output sequence correctly references the spatial relationship established by a token at position 50 decays with sequence length, and no amount of parameter scaling can eliminate this decay entirely if the architecture doesn't explicitly model spatial structure. PP-DocLayoutV2, by contrast, uses a detection transformer with explicit pairwise geometric bias and a pointer network that directly models the $N \times N$ pairwise ordering matrix — it represents spatial relationships structurally, not as a fragile byproduct of sequential token generation.

Second, the resolution mismatch. Layout analysis operates at a coarser visual granularity than content recognition. Detecting that a region is a table requires understanding its overall spatial extent and relationship to surrounding text blocks, which can be done at relatively low resolution. Recognizing the individual characters within that table's cells requires much higher resolution. An end-to-end VLM must process the entire page at high enough resolution to recognize the finest text, which means the visual token count for layout-relevant features is far higher than necessary — the model wastes capacity encoding fine-grained details of regions where it only needs coarse structural information. The decoupled design allows PP-DocLayoutV2 to operate at lower resolution (the paper notes it "typically requires lower input image resolution" in Section 2.1.1) while PaddleOCR-VL-0.9B receives only the cropped element at high resolution, making the total visual computation more efficient than processing the full page at the resolution needed for the hardest element.

Third, the error isolation property. In a pipeline, if the layout model misclassifies a formula as a text block, the downstream formula recognition model never gets a chance to correct it — the error is final. This is the classic "cumulative error propagation" critique of pipeline methods. But the paper implicitly argues that this critique is overstated for document parsing specifically, because layout detection is a more tractable and reliable task than end-to-end parsing. The evidence is in the results: PP-DocLayoutV2's layout analysis quality, when combined with high-quality element recognition, produces superior overall results to end-to-end models that theoretically could recover from layout errors through joint optimization. The empirical finding — that a pipeline with a good layout model and a good recognition model outperforms a jointly optimized end-to-end model — suggests that the joint optimization benefit is smaller than the architectural mismatch cost.

This decomposition is not a return to traditional pipelines as they existed before VLMs. The difference is that PaddleOCR-VL-0.9B, the recognition component, is itself a VLM — it benefits from the flexibility and generalization of vision-language modeling for the subtask where those properties are most valuable (recognizing diverse, complex elements). The layout component remains a specialized detector because that subtask benefits more from spatial reasoning architectures than from language modeling. The paper's contribution is not "pipelines are better than end-to-end" but rather "different subtasks within document parsing have different optimal architectures, and a heterogeneous system that matches architecture to subtask outperforms homogeneous systems." This is a more nuanced position than either the pipeline or end-to-end camps have typically taken, and it opens a design space — heterogeneous document parsing systems — that was underexplored because the field had implicitly assumed architectural uniformity within a single system.

Innovation 2: Ultra-Compact VLMs (0.9B) Can Dominate Document Parsing When the Vision-Language Scale Ratio Is Deliberately Rebalanced

One of the paper's most striking empirical findings is that a 0.9B-parameter VLM can outperform models 20–80× its size on document parsing benchmarks. PaddleOCR-VL-0.9B achieves an overall score of 92.86 on OmniDocBench v1.5, surpassing Qwen2.5-VL-72B (87.02), Gemini 2.5 Pro (88.03), and InternVL3.5-241B (82.67). On text recognition across 109 languages (In-house-OCR, Table 6a), it achieves normalized edit distances of 0.013–0.135 across Latin, Arabic, Devanagari, Cyrillic, Japanese, and Korean scripts — while competing specialist models show edit distances of 0.60–0.92 on non-Latin scripts, effectively failing. On charts (In-house-Chart, Table 12), it achieves 0.844 RMS-F1, surpassing Qwen2.5-VL-72B's 0.730. These are not marginal improvements — they represent a qualitative gap, particularly for non-Latin scripts where prior models essentially do not work.

The dominant narrative in vision-language modeling — reinforced by the steady progression from LLaVA-7B to InternVL3.5-241B — has been that VLM capability scales with parameter count, and that tasks requiring fine-grained visual understanding (like document parsing) are particularly parameter-hungry. PaddleOCR-VL challenges this narrative not by simply showing that a small model can work well, but by implicating the vision-to-language parameter ratio as a crucial architectural variable that the field has systematically underexplored.

The standard VLM architecture following LLaVA pairs a vision encoder of roughly 300M–400M parameters (ViT-L or SigLIP) with a language model of 7B–13B parameters — a ratio of approximately 1:20 to 1:30, heavily favoring language capacity. Even the recent generation of specialized document VLMs largely maintains this ratio: MonkeyOCR-pro-3B uses a 3.7B total model (though the vision-language ratio is not specified, the naming suggests a language model in the 2–3B range), and MinerU2-VLM uses a 0.9B model with similar proportions to general VLMs. The implicit assumption is that document parsing requires substantial language reasoning capacity to interpret visual content and produce structured output.

PaddleOCR-VL-0.9B inverts this assumption with a ratio of approximately 2:1 (roughly 500–600M vision encoder to 300M language model). The paper argues explicitly that "our architecture achieves a balance the scale of vision and language models to optimize performance in multi-elements recognition tasks" (Section 2.1.2). The conceptual claim is that document parsing is vision-intensive, not language-intensive: the primary bottleneck is extracting accurate fine-grained visual information — individual characters in 109 scripts, thin table cell separators, subscript and superscript positioning in formulas, tick marks and data point positions in charts — rather than performing complex multi-step reasoning over that information. A 300M-parameter language model is more than sufficient to convert well-extracted visual features into structured text; what matters is that the visual features are rich and accurate.

This has significant implications beyond the specific performance numbers. It suggests that the field's approach to scaling VLMs — keeping the vision encoder relatively small and scaling the language model massively — may be optimal for tasks requiring high-level visual reasoning (scene understanding, visual question answering, image captioning) but fundamentally suboptimal for tasks requiring dense, fine-grained visual extraction. Document parsing may be an extreme case of this pattern, but the principle likely extends to other tasks where the visual signal is dense and the mapping from vision to text is relatively direct: screenshot-to-code, diagram parsing, map reading, medical image report generation from scans.

The evidence for this interpretation is not just in the overall benchmark scores but in the pattern of where PaddleOCR-VL excels relative to larger models. On OmniDocBench v1.5 (Table 2), the largest gaps are in Text Edit Distance (0.035 for PaddleOCR-VL vs. 0.047–0.094 for the next-best models), Formula CDM (91.22 vs. 85.82–88.46), and Table TEDS-S (94.76 vs. 89.02–92.38). These are precisely the tasks where fine-grained visual feature extraction matters most: correctly reading every character, distinguishing similar-looking mathematical symbols, and accurately capturing table cell boundaries. On tasks where higher-level reasoning about document structure might matter more, the gap is smaller: Reading Order Edit Distance (0.043 vs. 0.044 for MinerU2.5) is nearly tied. The differential performance pattern aligns with the vision-intensive hypothesis.

The chart recognition results (Table 12) provide particularly striking support. Converting a chart to a structured data table requires both visual extraction (reading axis labels, identifying data point positions) and reasoning (inferring the chart type, understanding that stacked bars represent cumulative quantities, distinguishing between bar groups and individual bars). Yet PaddleOCR-VL's 0.844 RMS-F1 substantially exceeds Qwen2.5-VL-72B's 0.730, and the gap is larger for English charts (0.822 vs. 0.697) than Chinese (0.855 vs. 0.746). This suggests that even the "reasoning" component of chart understanding is not bottlenecked by language model scale — the 300M-parameter ERNIE-4.5 can handle it — and that the visual extraction quality from the larger, native-resolution vision encoder is the decisive factor.

Innovation 3: Evaluation-Driven, Fine-Grained Hard-Case Mining Converts Data Construction from a One-Time Effort into a Continuous Improvement Loop

The paper's data construction methodology, described in Section 3.3 and detailed in Appendix A, introduces a systematic process for identifying model weaknesses at a granular level and generating targeted synthetic training data to address them. This is not merely "we collected a lot of data" or "we used data augmentation" — it represents a conceptual shift in how training data is constructed for document parsing, from static dataset assembly to a dynamic, feedback-driven cycle.

Prior document parsing systems, whether pipeline-based or end-to-end, have typically relied on static datasets assembled before training begins. The data construction process — collecting public datasets, crawling web documents, perhaps synthesizing some examples — happens once, and the model is trained once on the resulting fixed corpus. If the model performs poorly on a specific document type after training, the options are limited: collect more data of that type (expensive), manually annotate edge cases (very expensive), or accept the limitation. The hard-case mining process described in this paper transforms this by making data construction responsive to measured model performance.

The mechanism is worth understanding conceptually even though the technical details are covered in Section 3. The system includes an evaluation engine that categorizes test samples into fine-grained types: 23 text categories, 20 table categories, 4 formula categories, 11 chart categories. After training, the model is evaluated on each category separately, and categories where performance falls below expectations are flagged. For these flagged categories, the system generates new synthetic training data specifically targeting the weakness — using font libraries, CSS libraries, corpora, and rendering engines to produce examples that share the challenging characteristics but with novel content. The model is then fine-tuned on this targeted data.

This is an instance of a broader idea — weakness-conditioned data generation — that has appeared in other forms in ML (adversarial training, hard negative mining, active learning), but the paper's application to document parsing is notable for its granularity and automation. Rather than mining hard examples from existing data (which is limited by what data exists), the system generates them on demand, using the detailed categorization to ensure that the synthetic data addresses precisely the capability gap, not a vaguely defined "hard case."

The significance of this innovation extends beyond the specific performance gains it enables. It reframes data construction as an ongoing operational process rather than a one-time research effort. In production deployments, document parsing systems continuously encounter new document types, formats, and edge cases. A system built with the hard-case mining methodology can incorporate these encounters into its training cycle: collect examples where the deployed model fails, categorize the failures, generate synthetic variants, and retrain. This makes the system adaptive to its deployment environment in a way that static-dataset-trained models are not. The paper doesn't fully demonstrate this continuous aspect — the reported results use the mining process during development, not in an ongoing deployment loop — but the methodology is described in a way that clearly supports continuous operation.

A subtle but important design choice is the use of synthetic data rather than manual annotation for addressing weaknesses. The paper states that only "a small number of corner cases" receive manual annotation (Section 1). The reliance on synthesis is practical — manual annotation at scale is prohibitively expensive — but it also enables a particular kind of generalization. When the system generates synthetic examples of handwritten tables with specific characteristics, it can control the distribution of visual variation (font styles, writing angles, noise levels, line weights) precisely, creating a training distribution that covers the space of possible variations more thoroughly than a collection of real examples ever could. This is the counterintuitive idea that for some document types, synthetic data may actually produce better generalization than an equivalent volume of real data, because real data is inevitably biased toward the specific cameras, scanners, and document preparation practices of its source.

The results that support this innovation are distributed across the evaluation tables. The multilingual text recognition results (Table 6a) are particularly telling: the model achieves edit distances of 0.011–0.135 across 10 script families, while competing models show catastrophic failure (0.60+) on several. This breadth of multilingual performance is unlikely to be achievable through public datasets alone, given the severe imbalance in available training data across languages. The hard-case mining process, applied to low-resource scripts identified through the evaluation engine, is the mechanism that closes this gap.

Innovation 4: Verifier-Free, Decoder-Small Architecture Makes Inference Throughput a First-Class Design Objective Tied to Model Capacity Choices

The paper's treatment of inference performance is unusual for a model paper. Rather than reporting inference speed as an afterthought in a brief "Deployment" subsection, the paper designs the model architecture around inference efficiency as a primary constraint and provides detailed throughput benchmarks across multiple hardware configurations and serving backends (Table 13, Appendix C). This is not merely good engineering — it represents a perspective on model design where inference cost is a first-class objective alongside accuracy, and where architectural choices (model scale, vision-to-language ratio, pipeline decomposition) are explicitly motivated by their inference implications.

The dominant approach in VLM research has been to optimize for accuracy on benchmarks, treating inference efficiency as a separate engineering problem to be solved after the model is designed. This leads to architectures that are accurate but impractical: InternVL3.5-241B may achieve strong benchmark scores, but deploying it for large-scale document processing is economically infeasible for most organizations. Even the specialized document VLMs in the 3–7B range (MonkeyOCR-3B, olmOCR-7B, POINTS-Reader-3B) are substantially larger than PaddleOCR-VL-0.9B, and the inference cost difference — roughly 3–8× more computation per generated token, since the decoder is 3–8× larger — compounds when processing millions of document pages.

The paper's key architectural insight regarding inference is that the language model's parameter count directly and linearly determines the per-token generation cost in the autoregressive decoding step, and this step dominates end-to-end inference time for document parsing. Unlike the vision encoding step, which can be parallelized across image patches and across multiple element crops, the text generation step is strictly serial: each output token depends on all previous tokens and cannot be generated in parallel with other outputs for the same element. The paper explicitly states this motivation: "in auto-regressive language models, the entire sequence is generated by predicting one token at a time. This approach means that the size of the decoder is directly linked to the overall inference latency, so a smaller model will decode faster" (Section 2.1.2). This is not a new observation — it's a basic fact about autoregressive models — but the paper's willingness to make it a binding architectural constraint is distinctive.

The choice of ERNIE-4.5-0.3B as the language model is thus not an arbitrary selection of a small model; it is a deliberate optimization of the accuracy-per-inference-FLOP Pareto frontier. For a given vision encoder quality (determined by the NaViT architecture and its training), there exists some minimum language model capacity needed to convert visual features to structured text without becoming the accuracy bottleneck. The paper's empirical finding is that this minimum is surprisingly low — 300M parameters is sufficient for the mapping from visual features to structured text across four distinct recognition tasks (OCR, tables, formulas, charts) — and that exceeding this minimum provides negligible accuracy gains while substantially increasing inference cost.

The evidence for this claim comes from comparing PaddleOCR-VL's accuracy and throughput against larger models. On OmniDocBench v1.5 (Table 2), PaddleOCR-VL-0.9B achieves 92.86 overall vs. Qwen2.5-VL-72B's 87.02 — higher accuracy with roughly 1/80th the language model parameters (the vision encoders differ, so it's not a pure language model comparison, but the point stands). On inference throughput (Table 13), PaddleOCR-VL processes 1.62 pages/second on an A100 vs. 1.06 for MinerU2.5 (1.2B parameters) — 53% higher throughput. When deployed on FastDeploy, token throughput is 2486.4 tokens/second vs. 1647.9 for MinerU2.5 on vLLM — a 51% advantage. These numbers are not small optimizations; they represent the difference between processing a million-page document corpus in 7 days vs. 11 days on the same hardware, or being able to deploy on a consumer RTX 3060 (0.36 pages/second, Table A2) vs. requiring a data-center GPU.

The multi-threaded asynchronous execution design described in Section 4.3 is worth highlighting as an architectural complement to the model-level efficiency. The three-staged pipeline with cross-page batch aggregation addresses a subtle utilization problem: individual document pages have highly variable numbers of elements, so processing pages one-at-a-time would create small VLM batches on simple pages. By pooling element crops across pages and triggering batch processing based on either count or timeout thresholds, the system maintains high GPU utilization regardless of per-page element variance. This is the kind of systems-level optimization that is often ignored in research papers but is critical for practical deployment, and its inclusion signals the paper's orientation toward real-world applicability.

The broader implication is a challenge to the "train the biggest model you can, then distill or quantize for deployment" paradigm that has been common in industry. PaddleOCR-VL suggests an alternative: design the model for deployment efficiency from the start, making architectural choices that align with inference constraints, and invest the saved complexity budget into better training data and task-specific optimization. The results suggest this approach can produce models that are simultaneously more accurate and more efficient than larger models that were optimized primarily for accuracy and only later adapted for deployment. Whether this pattern generalizes beyond document parsing — a domain where the task structure is unusually amenable to decomposition and where high-quality training data can be systematically generated — is an open question, but the paper makes a compelling case for its domain.

5. Experimental Analysis

Evaluation Methodology

• Dataset. The primary evaluation is conducted on three public benchmarks: OmniDocBench v1.5 (1,355 document pages, expanded from v1.0 with 374 new documents featuring more balanced Chinese-English distribution and richer formula content), OmniDocBench v1.0 (981 PDF pages spanning 9 document types, 4 layout styles, and 3 language categories), and olmOCR-Bench (1,402 PDF documents with 7,010 test cases using machine-verifiable unit tests). For element-level evaluation, additional datasets are used: OmniDocBench-OCR-block (17,148 block-level text images extracted from v1.5), OmniDocBench-Table-block (512 tables cropped from v1.5), OmniDocBench-Formula-block (1,050 formula sub-images cropped from v1.5), In-house-OCR (107,452 line-level text samples across 109 languages and multiple text types), In-house-Table (a diverse collection spanning 20 table types), In-house-Formula (34,816 samples covering common formula scenarios), In-house-Chart (1,801 manually verified samples across 11 chart categories), and Ocean-OCR-Handwritten (400 samples evenly split across real and synthetic Chinese and English handwriting). The paper does not describe how these in-house datasets were split into train/validation/test — the evaluation is conducted on held-out test portions, but the split methodology is not specified.

• Base model(s). The core recognition component is PaddleOCR-VL-0.9B, a vision-language model built from three pre-trained components: a NaViT-style vision encoder initialized from Keye-VL's weights, a randomly initialized 2-layer MLP projector with GELU activation, and the ERNIE-4.5-0.3B language model with 3D-RoPE positional encoding. The layout analysis component, PP-DocLayoutV2, combines an RT-DETR-based detection model initialized from PP-DocLayout_Plus-L pretrained weights with a 6-layer transformer pointer network for reading order prediction. The paper chooses this scale to demonstrate that a compact VLM can match or exceed much larger models on document parsing — the language model at 0.3B parameters is roughly 20–240× smaller than the 7B–72B language models in competing VLMs, and the total 0.9B is 3–80× smaller than specialized document VLMs like MonkeyOCR-3B (3.7B) or general VLMs like Qwen2.5-VL-72B.

• Metrics. Page-level evaluation uses a weighted combination of: Text Edit Distance (normalized Levenshtein distance between recognized and ground-truth text, lower is better), Formula CDM (Character Detection Matching, which evaluates formula recognition by matching detected characters to ground-truth characters based on spatial positioning and identity, higher is better), Table TEDS (Tree Edit Distance-based Similarity, measuring structural accuracy of table extraction as a percentage where 100 is perfect), Table TEDS-S (a structural-only version of TEDS that ignores cell content and measures only row/column structure), and Reading Order Edit Distance (a metric not precisely defined in the paper but presumably comparing the sequence of element identifiers against ground-truth reading order, lower is better). Element-level evaluation uses: Edit Distance for text and table content, TEDS for table structure, CDM for formulas, RMS-F1 for chart recognition (Root Mean Square F1, which evaluates the accuracy of extracted data tables by comparing predicted and ground-truth cells), and standard metrics including F1-score, Precision, Recall, BLEU, and METEOR for the Ocean-OCR-Handwritten benchmark. For olmOCR-Bench, the metric is unit test pass rate (percentage of machine-verifiable tests that the extracted content passes). For OmniDocBench v1.5, the overall score is described as "a weighted combination of the metrics for text, formulas, and tables" but the weighting formula is not specified.

• Baselines. The paper compares against three categories of systems: Pipeline tools including Marker-1.8.2, MinerU-pipeline, MinerU2-pipeline, PP-StructureV3, Docling-2.14.0, OpenParse-0.7.0, Unstructured-0.17.2, Pix2Text-1.1.2.3, and Mathpix; General VLMs including GPT-4o, InternVL3-76B, InternVL3.5-241B, Qwen2.5-VL-72B, Gemini-2.5 Pro, InternVL2-76B, Qwen2.5-VL-7B, MiniCPM-V2.6-8B, and Qwen2-VL-7B; and Specialized document VLMs including MonkeyOCR-pro-1.2B, MonkeyOCR-3B, MonkeyOCR-pro-3B, Dolphin (322M), OCRFlux-3B, Mistral OCR, POINTS-Reader (3B), olmOCR-7B, MinerU2-VLM (0.9B), Nanonets-OCR-s (3B), dots.ocr (3B), MinerU2.5 (1.2B), SmolDocling-256M, Nougat, GOT, and TinyChart. For the Ocean-OCR-Handwritten benchmark, additional baselines include InternVL2.5-4B, PaddleOCR (the predecessor system), TextIn, and Ocean-OCR. The chart recognition evaluation also compares against OneChart, PP-StructureV3, and TinyChart. Not all baselines are evaluated on all benchmarks — the paper uses consistent subsets where evaluations are available from prior work or where the authors conducted their own evaluation runs.

• Generation budget / compute accounting. For page-level parsing, there is no explicit generation budget — the evaluation measures end-to-end accuracy on full document pages given to each system. For inference performance, compute is measured in wall-clock time: total time (seconds to process the OmniDocBench v1.0 dataset of 981 pages in batches of 512), pages per second, and tokens per second (output tokens generated, tokenized with the "cl100k_base" tokenizer). The paper measures these under three serving backends (FastDeploy v2.3, vLLM v0.10.2, SGLang v0.5.2) on a single NVIDIA A100 GPU, and additionally across multiple hardware configurations (H800, A100, H20, L20, A10, RTX 3060, RTX 4090D) in Appendix C. GPU memory usage (average VRAM in GB) is also reported to capture resource efficiency. For dots.ocr specifically, the paper notes that 200 threads were used for concurrent page processing and Base64-encoded image content in Markdown was replaced with a dummy UUID-based path "to ensure a reasonable token count" — an important detail for fair comparison since dots.ocr produced inline images rather than external references.

• Cross-validation / statistical protocol. The paper does not report any cross-validation procedure for the model evaluation. The results on OmniDocBench and olmOCR-Bench are reported as single-run scores on the test sets. For olmOCR-Bench specifically, results are reported with ±1.0 confidence intervals (e.g., "80.0 ± 1.0"), suggesting either multiple evaluation runs or the benchmark's built-in statistical reporting — but the paper does not specify how these intervals were computed. The In-house benchmarks lack any reported statistical variation. There is no mention of training/validation/test splits for the in-house datasets, and no description of how hyperparameters were selected or whether any model selection was performed using the evaluation benchmarks.

Main Quantitative Results

Page-Level Document Parsing

The headline results establish PaddleOCR-VL as the top-performing system across all three page-level benchmarks, with the largest margins appearing on tasks requiring fine-grained visual extraction rather than high-level structural reasoning.

OmniDocBench v1.5 (Table 2). PaddleOCR-VL achieves an overall score of 92.86, surpassing the next-best model MinerU2.5 at 90.67 and substantially outperforming general VLMs like Gemini-2.5 Pro (88.03), Qwen2.5-VL-72B (87.02), and InternVL3.5-241B (82.67). The performance gap is uneven across subtasks:

• Text recognition (Text Edit Distance, lower is better): PaddleOCR-VL achieves 0.035, compared to MinerU2.5's 0.047 and dots.ocr's 0.048. The gap to general VLMs is dramatic: Qwen2.5-VL-72B achieves 0.094, Gemini-2.5 Pro 0.075. This is a ~2.7× lower error rate than Qwen2.5-VL-72B, suggesting that text recognition — the most fundamental document parsing capability — is where the compact VLM's native-resolution architecture provides the largest advantage over larger models that may downsample or tile.

• Formula recognition (Formula CDM, higher is better): 91.22, compared to Qwen2.5-VL-72B at 88.27, MinerU2.5 at 88.46, and InternVL3.5-241B at 87.23. The margin over MinerU2.5 (2.76 points) is substantial, and the gap to specialized VLMs is even larger (MonkeyOCR-pro-3B: 87.25, olmOCR-7B: 86.04). This is notable because formulas are particularly sensitive to resolution — distinguishing similar symbols (e.g., \partial vs. \delta, subscript vs. regular-size characters) requires the fine-grained visual features that the NaViT encoder preserves.

• Table recognition (Table TEDS, higher is better): 90.89, vs. MinerU2.5's 88.22 and dots.ocr's 86.78. For structural-only table quality (Table TEDS-S): 94.76 vs. MinerU2.5's 92.38. The structural advantage suggests that the OTSL format and targeted table training data are capturing table geometry accurately.

• Reading Order (Edit Distance, lower is better): 0.043, essentially tied with MinerU2.5 at 0.044, and substantially better than general VLMs (Qwen2.5-VL-72B: 0.102, Gemini-2.5 Pro: 0.097). The near-tie with MinerU2.5 suggests that reading order — which depends more on the layout analysis component than the recognition VLM — is where PP-DocLayoutV2's pointer network delivers competitive but not dominant performance.

OmniDocBench v1.0 (Table 3). PaddleOCR-VL achieves an average overall edit distance of 0.115, compared to 0.143 for both MinerU2.5 and dots.ocr, and 0.172–0.238 for the next tier of specialized VLMs (MonkeyOCR-pro-3B: 0.172, MonkeyOCR-pro-1.2B: 0.184, MinerU2-VLM: 0.186). Breaking this down by language reveals an interesting asymmetry:

• English text (Text Edit Distance): PaddleOCR-VL achieves 0.041, behind dots.ocr's 0.032 but substantially ahead of MinerU2.5's 0.050 and MonkeyOCR-pro-3B's 0.067. The paper does not comment on why dots.ocr outperforms on English text recognition specifically, but it may relate to dots.ocr's architecture or training data composition.

• Chinese text (Text Edit Distance): 0.062, with dots.ocr at 0.066, MinerU2.5 at 0.074, and MonkeyOCR-pro-3B at 0.107. PaddleOCR-VL leads, but the margins are narrower than in v1.5, likely reflecting the v1.0 benchmark's less balanced Chinese-English distribution.

• Formula Edit Distance: 0.241 (English) and 0.316 (Chinese), compared to MinerU2.5's 0.258 and 0.473, and dots.ocr's 0.329 and 0.416. The Chinese formula advantage is particularly large (0.316 vs. 0.416–0.473 across competitors), suggesting that the in-house formula training data with targeted Chinese formula synthesis (the paper notes that only ~1% of real-world formulas contain Chinese characters, making this a long-tail distribution) is paying off.

• Table TEDS: 88.0 (English) and 92.14 (Chinese). The paper explicitly notes that English Table TEDS is lower than expected and attributes it to "typo-related annotation errors in OmniDocBench v1.0" — the model may be correctly recognizing text that was incorrectly annotated in the benchmark, artificially depressing the score. Chinese Table TEDS (92.14) leads all competitors, with dots.ocr at 89.0 and MinerU2.5 at 89.2. This annotation-quality caveat is important: it means the reported numbers may underestimate true performance on English tables, and cross-benchmark comparisons are confounded by benchmark quality differences.

• Reading Order Edit Distance: 0.045 (English) and 0.063 (Chinese), nearly tied with dots.ocr (0.040, 0.067) and essentially SOTA on Chinese.

olmOCR-Bench (Table 4). PaddleOCR-VL achieves 80.0 ± 1.0 overall unit test pass rate, the highest among all evaluated systems. The next best are dots.ocr (79.1 ± 1.0), MinerU2.5 (77.5 ± 1.0), and MonkeyOCR-pro-3B (75.8 ± 1.0). The per-category breakdown reveals where PaddleOCR-VL excels and where it doesn't:

• ArXiv (academic papers): 85.7, the highest by a substantial margin (next: MonkeyOCR-pro-3B at 83.8, dots.ocr at 82.1). Academic papers typically contain dense text, formulas, and tables — all strengths identified in the OmniDocBench results.

• Headers and Footers: 97.0, second only to dots.ocr (not reported for this category in the excerpt, but implied by the overall ranking). Headers and footers are text-heavy regions that are challenging because they often contain small font sizes and are positioned at page edges where scanning artifacts are common.

• Old Scans Math: 71.0, behind dots.ocr (64.2) and MinerU2.5 (74.0). This is a notable relative weakness — Old Scans Math combines degraded image quality (scanned historical documents) with mathematical content, two challenges that independently are strengths for PaddleOCR-VL. The paper does not analyze why this category underperforms relative to competitors, though it may relate to the training data's distribution of scan degradation types.

• Tables: 84.1, behind dots.ocr (88.3) and MinerU2.5 (85.1). This is a surprising result given PaddleOCR-VL's strong table performance on OmniDocBench — it suggests either that olmOCR-Bench's table tests are measuring different aspects of table quality, or that the table training data has some coverage gap for the specific table types in olmOCR-Bench.

• Long Tiny Text: 85.7, behind dots.ocr (81.2? appears to be reporting a different metric) and General VLMs like Gemini Flash 2. The category tests extraction of very small text in dense layouts — exactly where NaViT's native resolution should help. The 85.7 score is solid but not dominant, perhaps reflecting a tradeoff between resolution preservation and the increased visual token count that NaViT produces for dense pages.

Element-Level Recognition

The element-level benchmarks allow evaluation of PaddleOCR-VL-0.9B's recognition capabilities in isolation from the layout analysis stage, providing insight into which component drives the overall system performance.

Text Recognition (Tables 5, 6, 7). The results demonstrate that PaddleOCR-VL-0.9B is a state-of-the-art OCR engine across languages, scripts, and text types, with the most dramatic advantages appearing in non-Latin scripts where competing models fail catastrophically.

• OmniDocBench-OCR-block (Table 5): PaddleOCR-VL achieves the lowest edit distance in 8 of 9 document type categories, with substantial margins in challenging categories like Exam Paper (0.115 vs. 0.116–0.248), Magazine (0.020 vs. 0.023–0.233), and Colorful Textbook (0.081 vs. 0.084–0.347). The only non-winning category is Research Report (0.033, behind Qwen2.5-VL-72B's 0.040 — but the table shows 0.033 vs. 0.040, so PaddleOCR-VL actually wins here as well, making it 9/9). The most dramatic gap is against Dolphin (0.095–0.347 across categories), highlighting the performance cliff between specialized and general OCR VLMs.

• In-house-OCR Multilingual (Table 6a): The headline finding is the collapse of competing models on non-Latin scripts. PaddleOCR-VL achieves Arabic 0.122, Korean 0.052, Tamil 0.043, Greek 0.135, Thai 0.081, Telugu 0.011, Devanagari 0.097, Cyrillic 0.109, Latin 0.013, Japanese 0.086. In contrast, Qwen2.5-VL-72B — a model ~80× larger — achieves Telugu 0.758, Tamil 0.389, and Arabic 0.405, while MinerU2.5 shows Arabic 0.978 (essentially complete failure), Korean 0.917, and Telugu 0.937. Even MonkeyOCR-pro-3B — a 3.7B specialized document VLM — achieves Arabic 0.601, Tamil 0.921, and Telugu 0.909. The pattern is stark: all competing models, regardless of scale or specialization, effectively fail on Dravidian scripts (Tamil, Telugu), Arabic script, and Thai, while performing adequately on Latin (0.013–0.063). PaddleOCR-VL is the only model that achieves reasonable performance across all tested scripts. This suggests that the training data construction methodology — specifically the systematic synthesis of multilingual text data and the hard-case mining process applied to low-resource scripts — is the decisive factor, not model architecture or scale.

• In-house-OCR Text Types (Table 6b): Across 13 text type categories, PaddleOCR-VL achieves the lowest edit distance in every category, with the largest advantages in challenging specializations: Rare Characters (0.001 vs. 0.034–0.092), Vertical Text (0.005 vs. 0.086–0.962), Single Characters (0.027 vs. 0.041–0.202), Emoji (0.057 vs. 0.134–0.225), and Art Font (0.165 vs. 0.220–0.337). The Vertical Text result is particularly notable because MinerU2.5 achieves 0.962 — essentially complete failure — while PaddleOCR-VL achieves near-perfect recognition, confirming that vertical text support was a deliberate design consideration (evidenced by the vertical text examples in Figures A17, A22 in Appendix D).

• Ocean-OCR-Handwritten (Table 7): For handwritten text, PaddleOCR-VL achieves English Edit Distance 0.118, Chinese Edit Distance 0.034, with corresponding F1-scores of 0.750 (EN) and 0.957 (ZH). These lead all baselines, with the next-best Chinese performer being Qwen2-VL-7B at 0.113 Edit Distance and 0.881 F1 — a 3.3× lower error rate for PaddleOCR-VL. The improvement over the predecessor PaddleOCR system (0.418 EN, 0.325 ZH Edit Distance) is dramatic, demonstrating the value of the VLM approach over the previous pipeline for handwriting. MinerU2.5 performs poorly on handwriting (0.238 EN, 0.356 ZH Edit Distance), consistent with its focus on printed documents.

Table Recognition (Tables 8, 9). PaddleOCR-VL achieves SOTA on table recognition benchmarks, with the advantages concentrated in content accuracy rather than pure structure.

• OmniDocBench-Table-block (Table 8): Overall TEDS 0.9195, Structural TEDS 0.9543, and Overall Edit Distance 0.0561. These lead all competitors: MinerU2.5 achieves 0.9005/0.9539/0.0693, MinerU2-VLM 0.9002/0.9369/0.0734, and dots.ocr only 0.8194/0.8442/0.1508. The gap between Structural TEDS and Overall TEDS is small for PaddleOCR-VL (0.9543 − 0.9195 = 0.0348), suggesting that most errors are in cell content recognition rather than structure, and that structural accuracy is very high.

• In-house-Table (Table 9): Overall TEDS 0.8699, Structural TEDS 0.9066, Overall Edit Distance (as a similarity score, higher is better — note this is the inverse of typical edit distance) 0.9066, Structural Edit Distance 0.9339. MinerU2.5 is the closest competitor at 0.8469/0.8955/0.8896/0.9239. The larger gap in Overall TEDS (0.8699 vs. 0.8469, a 2.3-point margin) compared to Structural TEDS (0.9066 vs. 0.8955, a 1.1-point margin) again indicates that PaddleOCR-VL's advantage is primarily in recognizing table content accurately, not just parsing structure. The general VLMs (Qwen2.5-VL at various scales) show substantially lower performance: even the 72B version achieves only 0.7762 Overall TEDS, confirming that table recognition in document parsing is not well-served by general-purpose VLM training.

Formula Recognition (Tables 10, 11). Formula recognition results strongly favor PaddleOCR-VL, with the largest margins on Chinese formulas, consistent with the targeted data synthesis for long-tail Chinese formula examples.

• OmniDocBench-Formula-block (Table 10): Overall CDM 0.9453, English CDM 0.9677, Chinese CDM 0.9228. MinerU2.5 achieves 0.9187/0.9751/0.8623 — a 6-point advantage on Chinese formulas. The English CDM is higher for MinerU2.5 (0.9751 vs. 0.9677), which is the only subtask where PaddleOCR-VL does not lead in this table. This may reflect MinerU2.5's formula training data composition, or it may be a statistical fluctuation given the relatively small test set (1,050 formula images).

• In-house-Formula (Table 11): Overall CDM 0.9882, English CDM 0.9914, Chinese CDM 0.9849. MinerU2.5 achieves 0.9770/0.9832/0.9708. The near-perfect English CDM (0.9914) suggests that printed English formulas — the dominant type in academic papers and the best-represented category in training data — are essentially solved by PaddleOCR-VL. The Chinese CDM of 0.9849, while slightly lower, still represents a 1.4-point advantage over MinerU2.5 and a substantial lead over general VLMs like Qwen2.5-VL-72B (0.9304). dots.ocr shows 0.5408 Chinese CDM — the paper attributes its poor performance to "easily recognizing cropped formulas as images" (Table 10 note), indicating a failure mode where the model doesn't attempt formula recognition on cropped regions.

Chart Recognition (Table 12). Chart recognition is where PaddleOCR-VL most dramatically outperforms general VLMs, and where the results support the paper's claim that chart recognition is a neglected capability in document parsing.

• In-house-Chart: Overall RMS-F1 0.8440, English 0.8222, Chinese 0.8549. The closest competitor is PP-StructureV3 at 0.8060/0.7963/0.8109 — notable because PP-StructureV3 is the authors' own pipeline system, suggesting that PaddleOCR-VL represents an improvement over their prior chart recognition capabilities. Qwen2.5-VL-72B achieves only 0.7300 overall, and smaller VLMs perform much worse: Qwen2.5-VL-3B at 0.5942, TinyChart at 0.2159, OneChart at 0.3716. The ~11-point gap over Qwen2.5-VL-72B (0.8440 vs. 0.7300) is the largest relative advantage across all element-level tasks, and it challenges the assumption that chart understanding requires large language models — the 0.3B ERNIE-4.5, when paired with a strong vision encoder and high-quality chart training data, outperforms a 72B general VLM by a wide margin.

Inference Performance

The inference benchmarks (Table 13, Appendix C Table A2) establish that PaddleOCR-VL achieves SOTA throughput while maintaining SOTA accuracy, across a range of hardware and serving backends.

Single A100 GPU, OmniDocBench v1.0 dataset (Table 13):

• FastDeploy backend: 605.6 seconds total, 1.6184 pages/s, 2486.4 tokens/s, 62.8 GB average VRAM.
• vLLM backend: 728.7 seconds total, 1.3453 pages/s, 2067.6 tokens/s, 40.1 GB average VRAM.
• SGLang backend: 882.1 seconds total, 1.1115 pages/s, 1707.8 tokens/s, 49.7 GB average VRAM.

Compared to baselines (all on vLLM unless noted): MonkeyOCR-pro-1.2B achieves 0.6730 pages/s and 1120.3 tokens/s; dots.ocr achieves 0.3522 pages/s and 532.9 tokens/s (with 200 threads for concurrent processing, which makes its lower throughput notable); MinerU2.5 achieves 1.0574 pages/s and 1647.9 tokens/s. PaddleOCR-VL on vLLM outperforms MinerU2.5 on vLLM by 27% in pages/s (1.3453 vs. 1.0574), and on FastDeploy by 53% (1.6184 vs. 1.0574). Token throughput advantages are similar: vLLM is 25% higher (2067.6 vs. 1647.9 tokens/s), FastDeploy is 51% higher (2486.4 vs. 1647.9).

The FastDeploy vs. vLLM gap for PaddleOCR-VL (1.6184 vs. 1.3453 pages/s) demonstrates that custom inference optimization yields ~20% additional throughput beyond what a state-of-the-art general VLM serving engine provides. However, FastDeploy uses more VRAM (62.8 GB vs. 40.1 GB for vLLM), indicating a throughput-memory tradeoff.

Multi-hardware evaluation (Appendix C, Table A2): PaddleOCR-VL demonstrates operational feasibility across a wide hardware spectrum:

• Data center GPUs: H800 achieves 2.23 pages/s (FastDeploy), A100 1.62 pages/s, H20 1.54 pages/s, L20 1.22 pages/s.
• Consumer/workstation GPUs: A10 achieves 0.82 pages/s (FastDeploy), RTX 4090D 1.15 pages/s (vLLM), RTX 3060 0.36 pages/s (vLLM).

The RTX 3060 result (0.36 pages/s, 11.9 GB VRAM) is particularly significant for the paper's "resource-constrained environments" narrative — it means the system can process approximately 31,000 pages per day on a budget consumer GPU, making large-scale document processing accessible without data center infrastructure. The RTX 4090D at 1.15 pages/s (~99,000 pages/day) offers near-data-center throughput on a high-end consumer card.

Ablation Studies and Robustness Checks

The paper does not report formal ablation studies in the traditional sense — there are no controlled experiments where individual components of PaddleOCR-VL-0.9B are removed or varied while holding other factors constant. The paper presents implicit evidence for design choices through comparisons across the model zoo of baselines, and through the differential performance patterns across benchmarks. However, several of these implicit comparisons serve an ablative function:

Decoupled layout analysis vs. end-to-end VLM: The comparison between PaddleOCR-VL (decoupled pipeline) and end-to-end specialized VLMs (MonkeyOCR, olmOCR, MinerU2-VLM) on OmniDocBench v1.5 (Table 2) provides evidence for the decoupled design. PaddleOCR-VL achieves 92.86 overall vs. 87.13 for MonkeyOCR-3B and 81.79 for olmOCR-7B — but these models differ in architecture, training data, and model scale simultaneously, so the comparison does not isolate the effect of decoupling. The reading order results are the closest to a controlled comparison: PaddleOCR-VL's reading order edit distance of 0.043 is nearly identical to end-to-end VLMs like dots.ocr (0.053), suggesting that the pointer network is competitive but not uniquely superior for reading order. The advantage of decoupling appears to be primarily in accuracy (avoiding VLM hallucination on layout) and throughput (avoiding long autoregressive sequences for full pages), not in reading order quality specifically.

NaViT dynamic resolution vs. fixed-resolution/tiling approaches: The comparison between PaddleOCR-VL and MinerU2-VLM (also 0.9B parameters, but without NaViT-style native resolution) on OmniDocBench v1.5 (Table 2) provides some evidence: PaddleOCR-VL achieves 92.86 vs. 85.56 overall, with Text Edit Distance 0.035 vs. 0.078. However, these models differ in training data, language model, and training recipe, making it impossible to attribute the gap solely to the vision encoder. The strong text recognition results on OmniDocBench-OCR-block (Table 5) — where PaddleOCR-VL achieves 0.020–0.115 edit distance across document types vs. 0.089–0.234 for MinerU2.5 — are more suggestive, since both are evaluated on the same cropped images. But again, the systems differ in multiple dimensions beyond the vision encoder.

Vision-to-language model scale ratio: The comparison between PaddleOCR-VL-0.9B (roughly 2:1 vision-to-language ratio) and Qwen2.5-VL-72B (unknown but likely much more language-heavy) on element recognition tasks partially supports the vision-intensive hypothesis. On chart recognition (Table 12), PaddleOCR-VL achieves 0.844 RMS-F1 vs. 0.730 for Qwen2.5-VL-72B. On In-house-OCR multilingual (Table 6a), PaddleOCR-VL achieves Arabic 0.122 vs. Qwen2.5-VL-72B's 0.405. However, these models differ in vision encoder architecture, training data composition, and training objectives, so the specific contribution of the vision-to-language ratio cannot be isolated.

OTSL vs. HTML for table output: No direct comparison is provided. The paper states that OTSL is adopted "for coding efficiency" but never compares table recognition accuracy with an equivalent model using HTML output. The table recognition results (Tables 8, 9) demonstrate strong performance, but we cannot determine how much of this is due to OTSL vs. other factors.

Stage 1 vs. Stage 2 training: No ablation on the two-stage training curriculum is reported. The paper does not show what performance would be without Stage 2 fine-tuning, without Stage 1 pre-training, or with a different distribution of data between the stages.

Hard-case mining effectiveness: The paper's most distinctive methodological contribution — the evaluation-driven hard-case mining loop — receives no direct experimental validation. There is no comparison showing model performance before and after hard-case mining, no ablation where hard-case mining is disabled, and no analysis of which categories improved most from the mining process. The multilingual text recognition results (Table 6a) provide circumstantial evidence — the broad multilingual coverage is unlikely without targeted synthesis — but the causal link is not demonstrated.

3D-RoPE vs. standard positional encoding: No ablation is reported. The paper incorporates 3D-RoPE from Qwen2.5-VL but provides no evidence that it improves performance over standard RoPE or learned positional embeddings for document parsing tasks.

Merge size in projector: The paper specifies a merge size of 2 to reduce visual token count, but no ablation on alternative merge sizes (1, 4, 8) or the effect on accuracy-vs-throughput is reported.

Batch size, sequence length, and resolution choices: No sensitivity analysis for these hyperparameters is provided. The paper reports specific values (batch size 128, sequence length 16,384, max resolution 1280/2048 × 28 × 28) without evidence that these are near-optimal or how performance varies with different settings.

Negative result: dots.ocr on cropped formulas (Table 10 note): The paper reports that dots.ocr achieves only 0.4641 Overall CDM on OmniDocBench-Formula-block, attributed to "easily recognizing cropped formulas as images." This is an interesting finding about a competitor's failure mode — when formulas are cropped tightly without surrounding context, dots.ocr may classify them as non-text elements and not attempt recognition — but the paper doesn't investigate whether this is a training data issue, an architecture limitation, or a prompt-engineering problem.

Critical Assessment

The experiments demonstrate that PaddleOCR-VL, as a complete system, achieves state-of-the-art performance on the evaluated benchmarks. The evidence for this is extensive and consistent across multiple benchmarks, element types, languages, and document categories. However, the paper's central claims are broader than "our system performs well on these benchmarks," and the experimental design has significant gaps in establishing the specific causal contributions of individual architectural and methodological innovations.

Claim 1: The decoupled two-stage architecture is superior to end-to-end VLM approaches for document parsing. The experiments support that PaddleOCR-VL (decoupled) outperforms end-to-end VLMs on OmniDocBench and olmOCR-Bench. However, the comparison is system-level, not component-level: the competing models differ in architecture, training data, model scale, and training procedure simultaneously. We cannot determine whether PaddleOCR-VL's advantage comes from the decoupled architecture, the NaViT vision encoder, the multilingual training data, the hard-case mining, or (most likely) some combination of all of these. A stronger test would compare PaddleOCR-VL-0.9B used as an end-to-end parser against the same model used in the decoupled pipeline, but this experiment is not performed. The reading order results — where PaddleOCR-VL's pointer network achieves performance comparable to end-to-end VLMs rather than substantially better — suggest that decoupling does not yield a dramatic advantage for reading order specifically. The throughput advantage of decoupling is clear (shorter VLM sequences for individual elements vs. whole pages), but throughput was not measured for end-to-end VLMs on the same task, making the comparison asymmetric.

Claim 2: The NaViT-style native dynamic resolution encoder is a key enabler of the model's accuracy, particularly for text-intensive and fine-grained recognition tasks. This claim has strong circumstantial support. The text recognition results, particularly on dense text (OmniDocBench-OCR-block) and small/dense scripts (In-house-OCR multilingual), are dramatically better than competing models that use fixed-resolution or tiling approaches. The mechanism — native resolution preservation prevents downsampling loss — makes technical sense and is consistent with the NaViT paper's findings. However, the paper never demonstrates that resolution is the bottleneck: there is no experiment varying input resolution while holding other factors constant, and no comparison showing that fixed-resolution encoding degrades PaddleOCR-VL's performance (which would require retraining the model with a fixed-resolution encoder). The claim is plausible and consistent with the data, but it is not demonstrated by the experiments as reported.

Claim 3: The vision-to-language model scale ratio (~2:1) is deliberately optimized for document parsing, which is vision-intensive rather than language-intensive. This is the paper's most architecturally interesting claim, but it has the weakest experimental support. No variant of PaddleOCR-VL with a different scale ratio (e.g., a 0.3B vision encoder + 0.6B language model, or a 0.6B vision encoder + 0.3B language model) is evaluated. The comparison to larger VLMs (Qwen2.5-VL-72B, InternVL3.5-241B) shows that PaddleOCR-VL-0.9B outperforms them, but these models differ in scale, architecture family, training data, and training objectives — the scale ratio is confounded with everything else. A cleaner test would be to train PaddleOCR-VL variants with different vision-to-language ratios and compare them, but this is not done. The claim that document parsing is "vision-intensive" is supported by the observation that PaddleOCR-VL-0.9B's language model (300M parameters) is sufficient for the task, but this doesn't demonstrate that a larger language model wouldn't help — it only demonstrates that 300M is sufficient when paired with the specific vision encoder and training data used. The chart recognition results, where PaddleOCR-VL outperforms Qwen2.5-VL-72B by a large margin (0.844 vs. 0.730 RMS-F1), provide the strongest evidence for the vision-intensive hypothesis (since chart recognition requires both visual extraction and reasoning), but even here, the comparison is confounded.

Claim 4: The data construction methodology, particularly hard-case mining and systematic multilingual data synthesis, is essential to the model's performance. The multilingual text recognition results (Table 6a) provide compelling indirect evidence: no competing model achieves usable performance on non-Latin scripts, while PaddleOCR-VL achieves reasonable accuracy across all tested scripts. This is strong evidence that PaddleOCR-VL's training data includes comprehensive multilingual coverage that competitors lack. However, the specific contribution of hard-case mining vs. other aspects of the data construction pipeline (large-scale synthesis, in-house data, automated annotation) cannot be disentangled. The paper does not report performance before and after applying hard-case mining, or compare variants trained with and without the mining process. The claim that hard-case mining is a "methodology" rather than a one-time effort is not experimentally validated — we see the output of one cycle of mining, not evidence that multiple cycles produce compounding improvements.

Claim 5: PaddleOCR-VL achieves SOTA inference efficiency while maintaining SOTA accuracy. This claim is well-supported by the throughput benchmarks (Table 13, Table A2) compared against baselines, with the caveat that throughput was only measured for a subset of competing systems (MonkeyOCR-pro-1.2B, dots.ocr, MinerU2.5). The throughput advantage over MinerU2.5 — the closest competitor in accuracy and the only baseline with similar model scale — is substantial (53% higher pages/s on FastDeploy, 27% higher on vLLM). The multi-hardware results (Table A2) demonstrating operation on consumer GPUs are also well-supported, though no baseline throughput numbers are provided for consumer GPUs, so we cannot assess whether PaddleOCR-VL's efficiency advantage holds across hardware tiers.

Genuine weaknesses in the experimental design:

• No training data ablation studies. The paper makes strong claims about the importance of data construction methodology but never demonstrates that specific data components (synthetic data, hard-case mining, multilingual synthesis, in-house data) improve performance over a baseline trained only on public data. This is a significant gap given that data construction is presented as one of three main contributions.

• No model scaling or architecture ablation studies. The paper claims a specific vision-to-language ratio is optimal but never compares against alternative ratios. The paper claims NaViT is important but never compares against fixed-resolution training. The paper claims 3D-RoPE is beneficial but never ablates it. These omissions are understandable given the computational cost of training multiple 0.9B models from scratch, but they mean the paper's architectural claims rest on cross-system comparisons that are inherently confounded.

• No statistical rigor for most results. Only olmOCR-Bench reports confidence intervals. For OmniDocBench and all in-house benchmarks, results are reported as point estimates with no indication of variance across runs, sensitivity to random seeds, or statistical significance of differences from baselines. The 500-question MATH test set in the reference example paper's domain is small; OmniDocBench v1.5's 1,355 pages is somewhat larger but still finite, and differences of 0.1–1.0 points in reported metrics may or may not be statistically significant.

• Unclear train/test contamination risk. The paper uses in-house datasets for evaluation but also incorporates in-house data in training (Section 3.1). Without clear documentation of train/test splits and assurance that evaluation samples were excluded from training, there is a risk of inflated performance estimates on in-house benchmarks. This is particularly concerning for the In-house-OCR, In-house-Table, In-house-Formula, and In-house-Chart benchmarks, where PaddleOCR-VL's margins over competitors are largest.

• Missing baselines for key comparisons. The inference throughput comparison (Table 13) includes only MonkeyOCR-pro-1.2B, dots.ocr, and MinerU2.5. It does not include throughput for other specialized VLMs like MonkeyOCR-pro-3B, olmOCR-7B, or POINTS-Reader, nor for general VLMs like Qwen2.5-VL-72B. This makes the throughput advantage claim narrower than it could be. Similarly, the chart recognition evaluation (Table 12) does not include several specialized document VLMs (MonkeyOCR, MinerU2.5, olmOCR) that are compared on other tasks, making it unclear whether PaddleOCR-VL's chart advantage is unique or shared by other document-specific systems.

• Benchmark annotation quality concerns. The paper itself notes annotation errors in OmniDocBench v1.0 affecting English Table TEDS. If benchmark labels contain errors, then all models' reported scores are noisy — but the noise may not be uniform. A model that exactly reproduces the ground-truth annotation errors would score perfectly on a flawed benchmark; a model that correctly recognizes the actual content would be penalized. The paper does not analyze how annotation quality varies across benchmarks or how it might differentially affect model rankings.

• No evaluation of the hard-case mining loop as a process. The paper describes hard-case mining as a methodology for continuous improvement but evaluates only a single trained model. There is no demonstration that applying the mining process iteratively yields diminishing or compounding returns, no analysis of how many iterations are needed, and no evidence that the categories identified as "hard" by the evaluation engine correspond to real-world deployment failures rather than artifacts of the evaluation set composition.

Experiments that would have strengthened the paper:

1. An ablation where PaddleOCR-VL-0.9B is trained with the full data pipeline vs. only public data vs. only synthetic data, to isolate the contribution of the data construction methodology.

2. A controlled comparison of the decoupled pipeline against using PaddleOCR-VL-0.9B end-to-end (with appropriate prompt engineering) on the same pages, to quantify the specific benefit of decoupling.

3. Training a variant of PaddleOCR-VL-0.9B with a fixed-resolution encoder (e.g., standard ViT at 336×336 with tiling) and the same language model and training data, to isolate the NaViT contribution.

4. Evaluation of PaddleOCR-VL's performance when PP-DocLayoutV2 makes errors (e.g., missed or misclassified elements), to characterize the pipeline's robustness to layout analysis failures and the degree of error propagation.

5. Latency measurements (time-to-first-token, time-per-output-token) in addition to throughput, since the sequential nature of some pipeline stages may introduce latency bottlenecks even when throughput is high.

6. Limitations and Trade-offs

6.1 Hard Problems and Degraded Documents Remain Unsolved: Zero Improvement Beyond the Base Model's Capability Boundary

The assumption or constraint. The paper's two-stage pipeline depends entirely on the recognition VLM's ability to produce correct output for each cropped element. If PaddleOCR-VL-0.9B cannot recognize a particular type of content because it falls outside its training distribution or capability range, no amount of layout analysis quality or inference optimization can recover it. This is not an acknowledged limitation per se—the paper does not explicitly state "our model fails on X category of document"—but the performance floor is visible in the hardest evaluation subsets.

The consequence. The system fails catastrophically on content that exceeds the VLM's recognition capacity, but this failure is silent: the VLM may produce plausible-looking but incorrect structured text rather than an explicit uncertainty signal. For downstream consumers (RAG systems, search indices, automated data extraction pipelines), this is worse than an error flag because it introduces undetectable corruption. A hallucinated number in a financial table or a misrecognized formula in a scientific paper propagates through the entire downstream pipeline with no mechanism for detection.

What evidence exists in the paper. The evidence for a capability ceiling is indirect but present. On the OlmOCR-Bench Old Scans Math category (Table 4), PaddleOCR-VL achieves 71.0 compared to MinerU2.5's 74.0—this is one of the few categories where PaddleOCR-VL does not lead, and it specifically combines degraded image quality (old scans) with mathematical content. On OlmOCR-Bench Tables, PaddleOCR-VL achieves 84.1 vs. dots.ocr's 88.3 (Table 4), despite leading on table benchmarks elsewhere (OmniDocBench-Table-block: 0.9195 TEDS, Table 8). This category-level inconsistency suggests that certain table types or degradation conditions push the model past its recognition threshold, but the paper never characterizes which conditions or what the failure mode looks like. The paper also notes that dots.ocr "easily recogniz[es] cropped formulas as images" on the Formula-block benchmark (Table 10 note)—a recognition refusal that, while inaccurate, is arguably safer than hallucinated LaTeX. PaddleOCR-VL does not exhibit this refusal behavior, raising the question of whether it sometimes hallucinates formulas where dots.ocr would output nothing.

Mitigation status. The hard-case mining process (Section 3.3) is explicitly designed to address capability gaps, and the evaluation engine's fine-grained categorization (23 text types, 20 table types, 4 formula types, 11 chart types) provides a mechanism for identifying weaknesses. But this is a training-time solution, not an inference-time safeguard. If a deployed model encounters a novel degradation type or document format that was not covered in the hard-case mining loop, there is no runtime mechanism for detecting the failure or falling back to a safer behavior. The paper does not describe any confidence estimation, uncertainty quantification, or anomaly detection for VLM outputs. Without these, the system's behavior on out-of-distribution inputs is uncharacterized and potentially dangerous for high-stakes applications.

---

6.2 The Decoupled Pipeline Introduces an Error Propagation Vulnerability That Is Acknowledged but Never Quantified

The assumption or constraint. By separating layout analysis (PP-DocLayoutV2) and element recognition (PaddleOCR-VL-0.9B) into sequential stages, the paper accepts the classic pipeline weakness: an error in the first stage cannot be corrected by the second stage. If PP-DocLayoutV2 fails to detect a table, misclassifies a formula as text, assigns an incorrect bounding box that crops out content, or produces a wrong reading order, the recognition VLM never sees the correct input and cannot recover. The paper acknowledges this vulnerability in its critique of pipeline methods (Section 1): "they are increasingly hindered by integration complexity, cumulative error propagation, and inherent limitations when handling highly complex documents." The authors are transparent that their approach reintroduces this risk, arguing that it is mitigated by using a dedicated, high-accuracy layout model rather than a VLM for this stage.

The consequence. The overall system accuracy is bounded by the product of layout analysis accuracy and element recognition accuracy. Even if PaddleOCR-VL-0.9B achieves perfect recognition on correctly-cropped elements (which it does not), the end-to-end accuracy cannot exceed PP-DocLayoutV2's detection recall. For complex, densely-laid-out documents where layout detection is inherently ambiguous (overlapping elements, irregular layouts, non-rectangular regions, figures embedded within text columns), this product bound becomes the dominant constraint on system performance. The paper provides no characterization of how often layout errors occur, what types of documents trigger them, or how severely they degrade the final output.

What evidence exists in the paper. The paper provides zero direct evidence on this limitation. There is no experiment measuring PP-DocLayoutV2's detection accuracy in isolation on any benchmark. There is no comparison of end-to-end performance when the same VLM is given ground-truth layout boxes vs. predicted layout boxes, which would quantify the error propagation gap. There is no analysis of failure cases where the layout model's output causes downstream recognition errors. The layout detection examples in Appendix D.2 (Figures A9–A11) are qualitative success cases—they show the model working well, not where it fails. The reading order results (OmniDocBench v1.5 Table 2: 0.043 Edit Distance, essentially tied with MinerU2.5 at 0.044) suggest that reading order quality is competitive but not dominant, but reading order is only one dimension of layout quality; detection recall and classification accuracy are unmeasured.

Mitigation status. The paper mitigates this risk through design (using a "stable and accurate" dedicated layout model rather than a VLM, Section 2.1.1) and through per-class thresholding on the detection proposals to filter low-confidence detections before the ordering stage. But the mitigation is undocumented and unevaluated: the paper does not specify the per-class thresholds, does not report detection precision/recall, and does not analyze how the threshold choice trades off false positives (hallucinated elements that waste VLM computation and produce spurious output) against false negatives (missed elements that are permanently lost). A practitioner deploying this system has no guidance on what types of documents are likely to trigger layout errors or how to detect them at inference time.

---

6.3 All Evaluations Are on a Single Public Benchmark Family (OmniDocBench) and Internally-Curated Test Sets; Real-World Generalization Is Unproven

The assumption or constraint. The paper's headline results are almost entirely on OmniDocBench v1.0 and v1.5, which—while diverse and carefully constructed—represent a specific distribution of document types, languages, and quality levels curated by the OmniDocBench authors. The element-level evaluations rely heavily on in-house test sets whose construction, representativeness, and relationship to the training data are not documented. The paper implicitly assumes that strong performance on these benchmarks translates to strong performance in real-world deployment, but provides no evidence from wild document collections, user-submitted documents, or production pipelines.

The consequence. Benchmark performance may overestimate real-world accuracy for several reasons that the paper does not control for. First, the in-house evaluation sets are constructed by the same team that builds the training data, creating a risk of unintentional distribution overlap between training and evaluation (the paper does not describe train/test split methodology for any in-house dataset). Second, the hard-case mining process (Section 3.3) explicitly generates synthetic training data to target categories where the evaluation engine identifies weaknesses—this is a legitimate technique for improving a model, but it means the evaluation set is being used to guide training data construction, which can create a subtle form of overfitting if the same evaluation set is used both to identify weaknesses and to measure final performance. Third, OmniDocBench was published in mid-2025 and the paper was written shortly thereafter; the benchmark's documents, while diverse, cannot represent the full spectrum of degradation types, historical document formats, unusual layouts, and domain-specific conventions that appear in real-world corpora spanning decades or centuries of document production. Fourth, the paper itself notes annotation quality issues in OmniDocBench v1.0 ("typo-related annotation errors" affecting English Table TEDS, Table 3), meaning the benchmark scores are contaminated by label noise with unknown bias.

What evidence exists in the paper. The paper provides no out-of-distribution evaluation. There are no results on document types or degradation conditions that are systematically different from those in the training and evaluation sets. The qualitative examples in Appendix D (Figures A5–A29) are success cases selected to demonstrate capabilities, not a random or systematic sample that would reveal failure modes. The olmOCR-Bench results (Table 4) provide some cross-benchmark validation and show category-level variation (e.g., Old Scans Math lower than ArXiv, Tables lower than competitors), but olmOCR-Bench was constructed by a different team with different curation criteria, and it is unclear whether its document distribution is sufficiently different from OmniDocBench to serve as a genuine out-of-distribution test. The paper's strongest cross-validation is the multilingual text recognition (Table 6a), where PaddleOCR-VL is the only model achieving usable performance across all scripts—but this in-house evaluation set's content and construction methodology are not described beyond the category breakdown in the caption.

Mitigation status. The paper acknowledges the need for comprehensive evaluation by using multiple benchmarks (OmniDocBench v1.0, v1.5, olmOCR-Bench) and supplementing with in-house datasets across four element types. But it does not acknowledge the specific risks of training-evaluation distribution overlap from the in-house datasets, does not provide train/test split documentation, and does not discuss the limitations of OmniDocBench as a proxy for real-world document processing. The continuous hard-case mining process described in Section 3.3 is, in principle, a mechanism for expanding the model's capability boundary by incorporating new failure cases discovered in deployment—but this process is described as a development methodology, not as a validated continuous improvement loop with production telemetry.

---

6.4 The Hard-Case Mining Methodology Receives Zero Direct Experimental Validation Despite Being Presented as a Core Contribution

The assumption or constraint. Section 3.3 describes an evaluation-driven hard-case mining process that is presented as one of the paper's three main contributions (Section 1: "High-quality Data Construction Methodology"). The process uses a fine-grained evaluation engine to identify model weaknesses, then generates targeted synthetic training data to address those weaknesses. The paper assumes that this process yields measurable performance improvements and that the identified "hard cases" correspond to genuine capability gaps rather than artifacts of the specific evaluation set composition.

The consequence. Without experimental validation, a practitioner cannot assess whether the hard-case mining methodology actually works, how much it contributes to the model's performance relative to simpler approaches (e.g., just training on more randomly-sampled synthetic data), or whether the investment in building the evaluation engine and synthesis pipeline is worth replicating. The paper's claim that this methodology "not only enables us to construct high-quality data on demand, but also provides a new perspective on the automated generation of high-quality data" (Section 1) is an assertion about methodology effectiveness that is entirely unsupported by the reported experiments.

What evidence exists in the paper. Zero direct evidence. There is no experiment comparing model performance with and without hard-case mining. There is no experiment showing that targeted synthesis for a specific weak category improves performance on that category more than an equivalent volume of untargeted synthesis. There is no analysis of how many iterations of the mining loop were performed, how performance changed across iterations, or whether the benefits compound or saturate. The multilingual text recognition results (Table 6a) provide circumstantial evidence—it is unlikely that the model could achieve Arabic 0.122 and Thai 0.081 Edit Distance without systematic attention to low-resource scripts, and the hard-case mining process is the most plausible mechanism for this attention. But this is correlation, not causal evidence: the model could achieve these results through the large-scale synthesis described in Appendix A.1 alone, without the evaluation-driven targeting. The performance on vertical text (0.005 Edit Distance, Table 6b) and rare characters (0.001 Edit Distance, Table 6b) similarly suggests targeted effort on these categories, but the specific contribution of the mining loop vs. other aspects of data construction cannot be disentangled.

Mitigation status. The paper does not acknowledge this lack of validation as a limitation. The hard-case mining process is described as a completed methodology whose output is the trained model, not as an object of experimental study. The paper includes "a small number of corner cases" that received manual annotation (Section 1), suggesting that some hard cases were manually addressed rather than synthetically generated, but the proportion and selection criteria for manual vs. synthetic hard cases are not reported. A practitioner attempting to replicate this methodology would have no guidance on critical operational parameters: how many evaluation samples per category are needed for reliable weakness detection, what performance threshold triggers hard-case mining, how many synthetic examples to generate per weak category, or how to validate that the synthetic data actually addresses the weakness rather than creating new forms of overfitting.

---

6.5 Inference Throughput Is Reported, but Latency and Memory Constraints for Interactive or Real-Time Use Cases Are Unexplored

The assumption or constraint. The inference performance evaluation (Section 4.3, Table 13, Appendix C) reports throughput metrics—pages per second, tokens per second—and average GPU memory usage, measured over batch processing of the entire OmniDocBench v1.0 dataset (981 pages) in batches of 512. The paper uses this to claim "fast inference speeds" and suitability for "practical deployment in real-world scenarios" (Abstract). But throughput, measured on large batches amortized over hundreds of pages, is an appropriate metric for offline batch processing of document corpora; it does not reflect the latency experienced by an interactive user waiting for a single document to be parsed.

The consequence. A practitioner deploying PaddleOCR-VL for an interactive application—a user uploads a PDF and expects the parsed Markdown within a few seconds—cannot predict the user experience from the reported throughput numbers. The three-stage asynchronous pipeline (data loading → layout analysis → VLM inference) with cross-page batch aggregation is designed to maximize GPU utilization by pooling work across pages, but this design inherently introduces latency: a single page's elements may wait in the VLM inference queue until enough elements from other pages accumulate to form an efficient batch, or until a timeout threshold is reached. The paper specifies that batch processing is triggered "when either the number of items in the queue reaches a predefined threshold or the waiting time for queued data exceeds a specified limit" (Section 4.3), but these thresholds are not specified, and their effect on per-document latency is not measured. A time-sensitive application would need to tune these thresholds for low latency, potentially sacrificing the throughput advantages that the paper's design achieves in batch mode.

What evidence exists in the paper. None. There are no latency measurements for single-document processing. There is no experiment showing how time-to-completion varies with document complexity (number of detected elements, which determines VLM inference queue depth), with the batch aggregation threshold, or with the choice of serving backend. The Appendix C multi-hardware table (Table A2) reports total time, pages/s, tokens/s, and average VRAM—all aggregate batch-processing metrics. A document with one full-page figure (one element) and a document with 50 mixed text blocks, tables, and formulas (50 elements) would have very different processing times, but this variance is invisible in the reported metrics. The paper's claim of "fast inference speeds" is therefore supported only for high-throughput batch scenarios, not for the interactive use cases implied by phrases like "practical deployment in real-world scenarios."

Mitigation status. The paper does not acknowledge latency as a dimension distinct from throughput. The multi-threaded asynchronous design is presented as purely beneficial, without discussion of the latency-throughput tradeoff inherent in batch aggregation across pages. The paper does not report time-to-first-token or time-per-output-token for the VLM decoding stage, which would be relevant even in batch scenarios for understanding how document complexity affects processing time. A practitioner would need to perform their own latency characterization before deploying in a latency-sensitive setting.

---

6.6 No Ablation Studies Exist for Any Architectural or Methodological Claim; All Causal Attribution Is Cross-System and Confounded

The assumption or constraint. The paper makes multiple specific architectural and methodological claims: that NaViT-style native resolution encoding is critical for text-intensive recognition (Section 2.1.2), that the ~2:1 vision-to-language parameter ratio is deliberately optimized for document parsing (Section 2.1.2), that 3D-RoPE positional encoding improves spatial reasoning (Section 2.1.2), that the OTSL format improves table recognition efficiency and accuracy (Section 2.2.2), that the two-stage training curriculum (29M alignment → 2.7M fine-tuning) is necessary (Section 2.2.2), and that the hard-case mining process drives performance improvements (Section 3.3). None of these claims is tested through controlled variation of the relevant component while holding other factors constant. Instead, all evidence for these claims comes from comparing PaddleOCR-VL—a complete system incorporating all of these design choices simultaneously—against competing systems that differ in architecture, training data, model scale, training procedure, and deployment configuration.

The consequence. A practitioner cannot determine which design choices are essential and which are incidental. If the practitioner wants to adapt the approach to a different domain, language family, or resource constraint, they do not know which components to prioritize replicating vs. which they can substitute. For example, if a team wants to build a document parser for a specific language using a different base language model, they cannot determine from this paper whether the NaViT encoder or the training data construction methodology is more critical to the system's performance. The paper's results demonstrate that the combination of choices works well, but the contribution of each individual choice is unknown. This limits both the scientific understanding of why the system works and the practical guidance for building similar systems.

What evidence exists in the paper. The paper provides zero formal ablation studies. There is no comparison of PaddleOCR-VL-0.9B with and without NaViT, with alternative vision-to-language ratios, without 3D-RoPE, with HTML instead of OTSL, without Stage 2 fine-tuning, or without hard-case mining. Some implicit comparisons exist by comparing against systems that make different choices—for instance, MinerU2-VLM (also 0.9B parameters, but without NaViT-style encoding) achieves 85.56 overall on OmniDocBench v1.5 vs. PaddleOCR-VL's 92.86 (Table 2), which is suggestive but confounded by differences in training data, language model, and training recipe. The inference throughput comparison between FastDeploy, vLLM, and SGLang backends (Table 13) is the closest the paper comes to a controlled experiment, but this varies the serving infrastructure, not the model architecture.

Mitigation status. The paper does not acknowledge the absence of ablation studies as a limitation. The paper's nature as a systems contribution—where the goal is to demonstrate a complete working system rather than to isolate the effect of individual components—makes the lack of ablations somewhat understandable; training multiple 0.9B-parameter models from scratch with different architectural choices would be extremely expensive. But the paper makes specific causal claims ("by integrating a NaViT-style dynamic high-resolution visual encoder... we significantly enhance the model's recognition capabilities," Section 1) that go beyond simply demonstrating system performance and enter the territory of explaining why the system works. These explanatory claims are not supported by the experimental design. A more cautious framing—"PaddleOCR-VL achieves SOTA performance; the specific contribution of individual components remains to be characterized through future ablation studies"—would more accurately reflect the evidence presented.

7. Implications and Future Directions

How This Work Changes the Landscape

This paper shifts the conversation around document parsing from a choice between two unsatisfactory extremes—brittle expert-model pipelines and resource-hungry end-to-end VLMs—toward a heterogeneous architecture paradigm where different subtasks receive different architectural treatments based on their specific demands. This is a reframing, not a paradigm shift: the individual components (RT-DETR detectors, NaViT encoders, LLaVA-style VLMs, pointer networks) are established building blocks. What is new is the empirical demonstration that a carefully composed heterogeneous system can simultaneously dominate both accuracy and efficiency benchmarks against both pipeline and end-to-end competitors. Before this work, a reasonable practitioner might have assumed that end-to-end VLM approaches represent the future of document parsing (following the broader trend in multimodal AI) and that pipeline methods are a transitional technology. PaddleOCR-VL complicates this narrative by showing that for document parsing specifically, the optimal system is neither purely pipeline nor purely end-to-end—it is a strategic decomposition where the layout stage benefits from detection-native architecture and the recognition stage benefits from VLM-native architecture, with the two connected by a simple cropping interface.

This reframing has practical consequences for how research effort should be allocated. The paper's finding that a 0.9B-parameter VLM with a 2:1 vision-to-language ratio can outperform 72B+ general VLMs on element recognition (92.86 vs. 87.02 overall on OmniDocBench v1.5, 0.844 vs. 0.730 RMS-F1 on chart recognition) makes the case that scaling model parameters is not the primary path forward for document parsing. Instead, the field should prioritize: (1) architecture specialization for document-specific visual challenges (native dynamic resolution for dense text, spatial reasoning for layout), (2) systematic data construction pipelines that cover long-tail document types and languages through targeted synthesis, and (3) inference optimization as a first-class design constraint. The dominance of general VLMs on document parsing benchmarks—which prior to this paper might have been interpreted as evidence that document parsing "just needs bigger models"—is revealed as an artifact of those models' training data scale, not their architectural suitability. PaddleOCR-VL's superior accuracy with 1/80th the parameters demonstrates that task-specific optimization can trump raw scale when the task structure is well-understood and high-quality training data can be systematically generated.

The paper also resolves a tension in the literature regarding multilingual document parsing. Prior to this work, the field had no clear diagnosis for why competing specialized document VLMs achieved catastrophic failure on non-Latin scripts (edit distances of 0.60–0.92 for Arabic, Tamil, Telugu in Table 6a) while performing adequately on Latin. PaddleOCR-VL's results—achieving 0.011–0.135 across all 10 tested script families—demonstrate that this is a data coverage problem, not a fundamental architecture limitation. The paper's systematic multilingual data synthesis and hard-case mining methodology provides a recipe for closing this gap, and the results imply that any document parsing system intended for global deployment must treat multilingual coverage as a first-class training data requirement, not an afterthought to be addressed through scale alone.

The verifier-free design carries an implicit methodological message. Unlike the reference example paper, which built elaborate process reward models and search strategies to optimize test-time compute, PaddleOCR-VL achieves state-of-the-art accuracy without any verifier, search, or iterative refinement at inference time. The entire system is a single forward pass per element (layout detection plus one VLM generation). This suggests that for document parsing—a domain where the mapping from pixels to structured text is highly constrained and training data can be made comprehensive—investing in better training data and architecture yields better returns than investing in inference-time search or verification, at least at the current capability frontier. This is a domain-specific insight that runs counter to the broader trend toward test-time compute scaling.

The chart recognition results (Table 12) specifically change the landscape by demonstrating that a sub-billion-parameter model can perform chart-to-table conversion at a level that exceeds dedicated chart understanding models (OneChart: 0.3716 RMS-F1) and large general VLMs (Qwen2.5-VL-72B: 0.7300). This establishes chart recognition as a tractable capability for compact document parsers, contradicting the implicit assumption that chart understanding requires large-scale reasoning. The implication is that chart recognition should be a standard component of document parsing systems, not an optional add-on requiring separate models.

Follow-Up Research This Work Enables

Quantifying the error propagation tax in the decoupled pipeline. The paper's central architectural decision—separating layout analysis and element recognition—reintroduces the classic pipeline vulnerability of unrecoverable early-stage errors. Yet the paper provides zero characterization of this tax: no detection recall/precision for PP-DocLayoutV2, no end-to-end comparison against the same VLM given ground-truth layout boxes, and no analysis of which document types trigger layout failures. A strong follow-up would instrument PP-DocLayoutV2's detection performance on OmniDocBench v1.5 at the per-element level (how often are text blocks, tables, formulas, charts correctly detected and classified?) and then measure PaddleOCR-VL-0.9B's recognition accuracy when given ground-truth crops vs. predicted crops. The difference between these two numbers—the "layout error tax"—would tell practitioners exactly how much performance they are sacrificing for the throughput gains of decoupling, and would guide whether investment in better layout models or VLM-based layout is worthwhile. This experiment is straightforward to run because OmniDocBench provides bounding box annotations; the paper sidesteps it entirely.

Training PaddleOCR-VL-0.9B variants with controlled architecture ablations to isolate the NaViT and vision-to-language ratio contributions. The paper's two most architecturally interesting claims—that native dynamic resolution is critical and that a 2:1 vision-to-language ratio is optimal—rest entirely on cross-system comparisons that are hopelessly confounded. A controlled experiment would train two variants of PaddleOCR-VL-0.9B: one with the NaViT encoder replaced by a standard fixed-resolution ViT (with tiling to handle high-resolution inputs, as GOT and MinerU2-VLM do), and another with the vision and language model scales swapped (e.g., a smaller vision encoder paired with a larger language model, keeping total parameters near 0.9B). Training all three variants on the same data with the same recipe would directly measure how much accuracy each architectural choice contributes. This experiment is computationally expensive (training three 0.9B models) but feasible for a well-resourced team, and it would transform the paper's architectural claims from plausible hypotheses to demonstrated facts. The fixed-resolution variant is particularly important because it would test whether NaViT's advantage is real or whether the same accuracy could be achieved with a simpler encoder and more training data.

Stress-testing the multilingual claim with truly low-resource scripts and zero-shot language transfer. Table 6a shows PaddleOCR-VL achieving reasonable performance on 10 script families, but all of these were presumably included in training data. An important follow-up would test the model on scripts that were deliberately held out during training—for example, training a variant without Georgian, Armenian, or Ethiopic script data and measuring whether the model's native-resolution encoding enables any zero-shot transfer to unseen scripts. If the model can recognize characters in an unseen script purely from visual pattern generalization, that would suggest the vision encoder has learned a script-agnostic character recognition capability that transcends specific training scripts. If it fails completely (as competing models fail on training-included non-Latin scripts), that would confirm that multilingual performance requires explicit script-level data coverage and that claims of "109 language support" should be understood as "109 languages seen during training" rather than general multilingual capability. This experiment would also clarify whether the hard-case mining methodology can be applied to genuinely novel scripts discovered in deployment or whether it requires a minimum amount of initial data to bootstrap.

Characterizing the VLM's hallucination behavior on out-of-distribution document elements and developing runtime confidence estimation. The paper never addresses what PaddleOCR-VL-0.9B does when it encounters content it cannot recognize—does it produce garbled text, plausible-looking but incorrect output, or an explicit refusal? The dots.ocr failure mode noted in Table 10 ("easily recognizing cropped formulas as images") represents a form of implicit refusal; PaddleOCR-VL does not exhibit this behavior, raising the question of whether it instead hallucinates content for unrecognizable inputs. A systematic study would: (1) Construct a test set of document elements with controlled degradation (progressive blur, noise, occlusion, unusual fonts) and measure how recognition accuracy degrades. (2) Evaluate whether the model's output token probabilities or internal representations contain a usable confidence signal—can we threshold the sequence-level log-probability to detect hallucinations? (3) Compare the hallucination rate (producing plausible but incorrect structured text) against the refusal rate (producing empty or error-indicating output) across degradation levels. This matters enormously for practical deployment because undetected hallucinations in document parsing are worse than explicit failures: a hallucinated number in a financial table or a misrecognized drug name in a medical document propagates silently through downstream systems. The paper's silence on this topic is its most significant practical limitation.

Applying the hard-case mining methodology iteratively and measuring the performance trajectory. The paper describes hard-case mining as a continuous improvement methodology but evaluates only a single trained model—we see the output of the process, not the process itself. A compelling follow-up would run multiple iterations of the mining loop on a fixed model architecture: (1) Train an initial model on the base dataset. (2) Evaluate on the fine-grained evaluation engine to identify the top-5 weakest categories. (3) Generate synthetic data targeting those categories. (4) Fine-tune the model on the augmented dataset. (5) Repeat steps 2–4 for several iterations. Plotting per-category accuracy against iteration number would reveal: whether the mining process produces diminishing or compounding returns, how many iterations are needed before saturation, whether improvements in one category come at the expense of others (catastrophic forgetting), and whether the synthetic data's benefit plateaus or continues to scale with volume. This experiment would transform hard-case mining from an assertion into a validated methodology, and would give practitioners concrete guidance on how many iterations to budget for, how many synthetic examples to generate per weak category, and what performance trajectory to expect. The paper's fine-grained evaluation engine with 58 categories (23 + 20 + 4 + 11) across four element types provides an ideal instrument for this study.

Benchmarking PaddleOCR-VL on document collections from genuinely different distributions—historical archives, non-Western publishing conventions, noisy mobile captures. The paper's evaluation relies heavily on OmniDocBench (curated benchmark documents) and in-house datasets (constructed by the same team). A critical external validation would test the system on document corpora from distributions that OmniDocBench does not represent: 19th-century printed books with degraded type and non-standard layouts, modern documents from publishing traditions that use right-to-left or top-to-bottom primary text direction with embedded left-to-right elements (Arabic technical documents, Japanese newspapers), and photographs of documents taken with smartphone cameras under uneven lighting with perspective distortion. These are exactly the types of documents that real-world deployment pipelines encounter, and they stress-test different aspects of the system: historical documents stress the vision encoder's robustness to degradation, non-Western layouts stress the layout model's geometric reasoning and the language model's directional awareness, and mobile captures stress the entire pipeline's ability to handle noise that training augmentations may not cover. Performance on such corpora—compared against MinerU2.5 as the strongest competing compact system—would reveal whether the benchmark-reported accuracy generalizes or whether the system has overfit to OmniDocBench-like document characteristics.

Practical Applications and Downstream Use Cases

Large-scale academic literature ingestion for RAG systems. Organizations that maintain search indices over millions of scientific papers—publishers like arXiv, Semantic Scholar, and institutional library systems—need to convert PDFs into structured text with accurate extraction of formulas, tables, citations, and reading order. PaddleOCR-VL's 1.62 pages/second throughput on a single A100 GPU (Table 13) means processing 1 million pages takes approximately 7.2 days of GPU time, compared to roughly 10.9 days for MinerU2.5 at 1.06 pages/second—a 34% reduction in processing time and cost. More importantly, the formula recognition accuracy (CDM 0.9453 on OmniDocBench-Formula-block, Table 10) and table structural accuracy (TEDS-S 94.76, Table 2) mean that the extracted formulas and tables are substantially more reliable for downstream search and analysis. For a corpus like arXiv's 2.5 million papers (each averaging ~10 pages, so ~25 million pages), the difference between 0.115 average edit distance (PaddleOCR-VL on OmniDocBench v1.0, Table 3) and 0.143 (MinerU2.5) translates to roughly 700,000 fewer character-level errors across the corpus—errors that would otherwise corrupt search results, citation extraction, and LLM training data.

Multilingual document processing for global enterprises and government archives. The paper's demonstration of usable text recognition accuracy across 109 languages—with edit distances of 0.011–0.135 across Arabic, Devanagari, Cyrillic, Thai, Tamil, Telugu, Korean, and Japanese scripts (Table 6a) where competitors achieve 0.60–0.98—makes PaddleOCR-VL the first document parsing system that can plausibly be deployed for global-scale multilingual document processing without per-language model customization. A multinational corporation processing contracts, invoices, and correspondence in dozens of languages, or a government archive digitizing historical documents from a multilingual society, can deploy a single system rather than maintaining separate OCR pipelines per script family. The deployment flexibility across hardware tiers (Table A2: from H800 at 2.23 pages/s to RTX 3060 at 0.36 pages/s) means that the same system can be used in both centralized data centers (for bulk archival processing) and edge deployments (for on-premise document processing in offices or field locations with limited connectivity). The 0.9B model size makes deployment feasible on hardware that cannot accommodate 7B+ VLMs.

Financial document automation with chart data extraction. Financial services firms process vast quantities of documents containing both tabular data and visualizations—annual reports, earnings presentations, market research, economic analyses—where the charts contain data that is not separately available in structured form. PaddleOCR-VL's chart recognition capability (RMS-F1 0.844 overall, 0.822 English, Table 12) enables automated extraction of chart data into structured tables, something competing document parsers either do not attempt (MinerU2.5, MonkeyOCR, dots.ocr do not report chart capabilities) or do less accurately (Qwen2.5-VL-72B: 0.730). In a financial analysis pipeline processing 10,000 earnings presentations, each containing an average of 15 charts, PaddleOCR-VL would correctly extract approximately 8,440 chart tables correctly (at 0.844 RMS-F1), compared to approximately 7,300 for Qwen2.5-VL-72B. The extracted data tables can directly feed into quantitative models, trend analysis, and structured databases, eliminating the manual data entry that currently dominates chart data extraction workflows. The importance of this capability is amplified by the fact that financial charts often contain information critical for investment decisions that is not repeated in the document text.

On-device document parsing for privacy-sensitive applications. Healthcare, legal, and government applications often require that documents never leave the local device due to privacy regulations or security requirements. PaddleOCR-VL's demonstrated operation on consumer GPUs (RTX 3060 at 0.36 pages/s, RTX 4090D at 1.15 pages/s, Table A2) means that a complete document parsing system—handling text, tables, formulas, and charts in over 100 languages—can run entirely on a workstation or high-end laptop without any cloud dependency. A law firm processing discovery documents, a hospital parsing patient records for structured data extraction, or a government agency digitizing classified archives can deploy PaddleOCR-VL locally with throughput appropriate for interactive or small-batch use (a 50-page legal filing parsed in approximately 2–3 minutes on an RTX 4090D). The 40–63 GB VRAM requirement for optimal performance (Table 13, Table A2) is the limiting factor for consumer deployment, but the paper shows operation at 11.9 GB VRAM on RTX 3060 with reduced throughput, making it feasible on mid-range hardware. No other SOTA document parsing system with comparable accuracy and language coverage has demonstrated operation in this hardware class.