Best Open-Source OCR and Document VLMs to Self-Host on GPU Cloud in 2026: PaddleOCR-VL, DeepSeek-OCR, dots.ocr, and GOT-OCR Compared

VLM-based OCR replaced classical pipelines for enterprise document work in 2026. This post compares five production-ready open-source options - PaddleOCR-VL-1.6, DeepSeek-OCR, dots.ocr, GOT-OCR 2.0, and Granite-Docling - across accuracy, VRAM, throughput, and cost per 10,000 pages on Spheron GPUs. For a deep-dive on deploying DeepSeek-OCR specifically (vLLM/SGLang containers, FastAPI endpoint, and cost-per-million-pages math), see the DeepSeek-OCR deployment guide. This post focuses on model selection: how to pick the right model for your document type, GPU budget, and throughput target.

The motivation is straightforward. AWS Textract charges $1.50 per 1,000 pages for basic text extraction. GCP Document AI is similar. Azure Document Intelligence runs higher on custom models. At 100,000 pages per month, that's $1,500 to $10,000 in API costs, every month, before table extraction fees. Self-hosting on an L40S or A100 on Spheron cuts that to $50-100 per month at comparable accuracy, with documents never leaving your GPU boundary.

Why OCR Went VLM-Native in 2026

Classical OCR worked through a sequence of steps: binarization, layout detection, text region segmentation, character classification, and language-model correction. Each step introduced error that compounded through the pipeline. On clean printed documents the approach was adequate. On photocopied tables, mixed-script invoices, handwritten annotations, or scanned legal contracts, accuracy dropped fast.

VLM-based OCR collapses that pipeline to a single forward pass. The model receives the page as a grid of image patches, processes them through a visual encoder, and generates the extracted text (or structured JSON) autoregressively through a language model decoder. Layout structure, table cell relationships, and text content are all handled in one call. The prompt controls output format, so you can ask for markdown tables, JSON key-value pairs, or plain text without post-processing logic.

The other shift is the API surface. Every VLM OCR model follows the OpenAI vision spec: you submit an image and a text prompt via the /v1/chat/completions endpoint. That makes VLM-based OCR a drop-in replacement for any integration already using GPT-4o Vision or Claude for document reading. For teams that need layout intelligence layered on top of OCR, the Docling, Marker, and MinerU guide covers the hybrid routing pattern where native PDFs go through layout parsers and scanned pages route to a VLM OCR model.

The cost case closed in 2025-2026 when models in the 1-3B range reached production accuracy on printed documents. The compute requirement for good OCR no longer requires H100-class hardware.

The Contenders: Sizes, Licenses, and Language Support

PaddleOCR-VL-1.6's 96.33% OmniDocBench v1.6 overall score is its published headline result. For the remaining models, OmniDocBench v1.6 scores covering these exact checkpoints were not available at time of writing. Use the section below for a characteristic comparison by document dimension rather than a synthetic headline score.

PaddleOCR-VL-1.6 is the widest-coverage option. It pairs a native-resolution visual encoder with the ERNIE-4.5-0.3B LLM for a total of ~0.9B parameters, handling complex multilingual layouts, mixed scripts, and structured tables in a single pass. Its 96.33% OmniDocBench v1.6 score confirms it as the accuracy leader in this group. It is the default choice when document language is unknown or when the corpus spans multiple languages and scripts.

DeepSeek-OCR uses a Mixture-of-Experts decoder with about 570 million active parameters per token, giving it substantially higher throughput at the same batch size. It is MIT-licensed, making it fully open-source in the OSI sense with no restrictions on redistribution or fine-tuning. For bulk batch OCR where throughput per dollar matters most, its MoE architecture is the key advantage.

dots.ocr is published by RedNote (Xiaohongshu) at rednote-hilab/dots.ocr under the MIT license. It pairs a visual encoder with a ~1.7B LLM decoder for general multilingual document parsing across ~100 languages, with particular strength on structured documents and forms. Being MIT-licensed with no commercial-use restrictions, it is a genuine open-weight option for teams that need guaranteed redistribution rights alongside broad language coverage.

GOT-OCR 2.0 (General OCR Theory, from UCAS) targets formatted-text recognition: equations, tables, music sheets, geometric diagrams, and multi-column academic papers. At under 3 GB VRAM, it runs on consumer cards and is the right pick for memory-constrained or edge deployments. It does not handle handwriting or degraded scans as well as the larger models.

Granite-Docling is IBM's vision model built for the Docling document parsing pipeline. Its training includes TableFormer-informed table datasets, making it strong on financial tables and legal document layouts. The primary language coverage is English, and it integrates natively with Docling's DoclingDocument JSON output format.

OmniDocBench v1.6 Accuracy: Tables, Formulas, Multi-Column, Handwriting

PaddleOCR-VL-1.6's headline OmniDocBench v1.6 result is 96.33% overall. For the other models, published OmniDocBench v1.6 scores covering these exact checkpoints were not available at time of writing. The table below characterizes each model's strengths by document dimension:

These characterizations are based on published model documentation and benchmark references, not OmniDocBench v1.6 specific test runs for every model. Differences in practical accuracy are often small on clean printed documents. The gaps open up on degraded scans, handwriting, and complex tables.

For tables: PaddleOCR-VL-1.6 and Granite-Docling are the strongest options. Granite-Docling's training on FinTabNet and PubTabNet gives it better table cell boundary detection on financial and scientific layouts. PaddleOCR-VL-1.6 is more flexible across document types.

For multilingual: PaddleOCR-VL-1.6 is the model covering 100+ languages reliably. If your corpus includes CJK scripts, Arabic, or other non-Latin scripts, it is the right starting point. DeepSeek-OCR supports ~100 languages as well, making it viable for broad multilingual batch work.

For handwriting: Both PaddleOCR-VL-1.6 and DeepSeek-OCR handle handwritten annotations acceptably on clean scans. GOT-OCR 2.0 and Granite-Docling are not designed for handwriting.

For formulas: GOT-OCR 2.0 has specific training on mathematical notation and LaTeX generation. For scientific paper OCR with inline equations, it outperforms the other models.

VRAM Footprint and Throughput per GPU

Throughput figures below are peak decode estimates based on model architecture and VRAM sizing. They reflect decode-only rate and do not include PDF rasterization, I/O, or pre/post-processing overhead. Sustained end-to-end throughput is roughly half these figures and drives the cost-per-page numbers in the table further below. Actual results vary by DPI, batch size, output length, and serving configuration.

DeepSeek-OCR's MoE architecture activates roughly 570M parameters per decoding step from a ~3B total. PaddleOCR-VL-1.6 is itself compact at ~0.9B, so the raw decoding parameter gap is narrower than older MoE-vs-dense comparisons suggested. The throughput advantage for DeepSeek-OCR comes primarily from its routing efficiency and larger activation batch capacity at the same VRAM budget. When your pipeline needs to exceed ~45 pages/min peak decode on PaddleOCR-VL-1.6, moving to an A100 80G raises that ceiling to ~60 pages/min at about 1.5x the per-GPU cost.

For serving framework choice: use vLLM for general OCR workloads with varied document types. SGLang is worth switching to when processing large batches of identical-template documents (invoices, forms, contracts) because RadixAttention prefix caching reuses shared system-prompt tokens across requests, improving throughput by 20-40% on repeated-template workloads. The DeepSeek-OCR deployment guide covers the full vLLM and SGLang container configuration with Docker run commands and --tensor-parallel-size settings.

Deployment: vLLM and SGLang, Batching Scanned PDFs, Structured JSON Output

The vLLM launch command for PaddleOCR-VL-1.6 follows the same pattern as any vision-language model:

docker run --runtime nvidia --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model PaddlePaddle/PaddleOCR-VL-1.6 \
  --tensor-parallel-size 1 \
  --max-model-len 8192 \
  --limit-mm-per-prompt image=1 \
  --served-model-name paddleocr-vl

For structured JSON output, instruct the model via system prompt. The model will follow the schema reliably on printed documents:

system_prompt = """You are a document OCR engine. Extract the document content and return ONLY valid JSON with this structure:
{
  "text_blocks": [...],
  "tables": [{"headers": [...], "rows": [[...]]}],
  "page_language": "..."
}
Do not include any text outside the JSON object."""

For batching scanned PDFs, submit pages in parallel rather than sequentially:

import asyncio
import base64
import io
from openai import AsyncOpenAI
from pdf2image import convert_from_path

async def ocr_page(client, image, page_num, system_prompt):
    buf = io.BytesIO()
    image.save(buf, format='JPEG')
    img_b64 = base64.b64encode(buf.getvalue()).decode()
    response = await client.chat.completions.create(
        model="paddleocr-vl",
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": [
                {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{img_b64}"}},
                {"type": "text", "text": "Extract all content from this document page."}
            ]}
        ]
    )
    return page_num, response.choices[0].message.content

async def batch_ocr(pdf_path: str, system_prompt: str) -> list:
    client = AsyncOpenAI(base_url="http://localhost:8000/v1", api_key="none")
    images = convert_from_path(pdf_path, dpi=150)
    tasks = [ocr_page(client, img, i, system_prompt) for i, img in enumerate(images)]
    return await asyncio.gather(*tasks)

Convert PDFs at 150-200 DPI. Higher DPI increases token count without proportional accuracy gain on most printed documents. See docs.spheron.ai for instance provisioning steps.

Plugging OCR into a RAG Ingestion Pipeline

OCR output feeds a RAG pipeline in three stages: extraction, chunking, and embedding.

PDF Pages
    |
    v
VLM OCR (vLLM/SGLang)
    |
    v
JSON blocks (text, tables, metadata)
    |
    v
Chunker (section-aware, table-preserving)
    |
    v
Embedding Model (BGE-M3, Qwen3-Embedding)
    |
    v
Qdrant / Milvus

The key decision at the chunking stage is whether to treat tables as single chunks or split them by row. For financial tables that need to be retrieved as whole objects (e.g., P&L statements), keep the table as one chunk. For long tables that span multiple topics (e.g., supplier comparison tables), row-level chunking with header metadata produces better retrieval precision.

For the full RAG stack design including embedding model sizing, FAISS-GPU indexing, and LLM inference colocated on one GPU node, see the agentic RAG infrastructure guide. When your document corpus mixes native PDFs and scanned pages, the hybrid pipeline pattern for routing by page type is covered in our document intelligence guide, where native PDFs go through layout parsers and scanned pages route to a VLM OCR model.

For document corpora where cross-document reasoning matters (e.g., contract repositories or research literature), the GraphRAG deployment guide covers knowledge graph indexing on top of OCR-extracted text.

Cost per 10,000 Pages on Spheron GPUs vs Paid OCR APIs

Throughput and cost figures use PaddleOCR-VL-1.6 as the reference model since it is the most broadly applicable. DeepSeek-OCR's MoE architecture yields higher throughput at the same batch size, reducing cost per page by roughly 30-40% at equivalent GPU pricing. Throughput figures here are sustained end-to-end estimates including PDF rasterization, I/O, and processing overhead, which is roughly half of the peak decode rates shown in the VRAM table above.

Pricing fluctuates based on GPU availability. The prices above are based on 23 Jun 2026 and may have changed. Check current GPU pricing → for live rates.

Self-hosting breaks even against Textract at roughly 50,000-100,000 pages per month. Below that threshold the fixed GPU cost exceeds the per-page savings. Above it, the advantage compounds: at 500,000 pages per month, Spheron on a single L40S GPU rental costs about $364 in GPU time versus $750 for Textract (and more once you add table extraction fees).

Recommendation Matrix by Use Case

The core decision point is accuracy vs. cost vs. multilingual coverage. PaddleOCR-VL-1.6 leads on benchmark accuracy and language breadth. DeepSeek-OCR is the cost-per-page winner for bulk batch work. GOT-OCR 2.0 is the right pick when VRAM budget is the binding constraint.

VLM-based OCR on mid-tier cloud GPUs replaces per-page API costs at scale. For most OCR workloads, an L40S or A100 on Spheron keeps cost-per-page well below managed API pricing with no minimum commitments.

L40S GPU pricing → | A100 on Spheron → | View all GPU pricing →