The Throughput Math of Self-Hosted Document Parsing
What a 100-page-in-101-seconds parser means for capacity and cost: the throughput math of self-hosting SoMarkAI's open-weight OXR model.

Every company building on large language models eventually meets the same bill. Contracts, filings, invoices and research reports arrive as PDFs, and before any model can reason over them, they have to be converted into structured text. At small volumes that step is a rounding error. At millions of pages it becomes a line item, and its two drivers, accuracy and throughput, decide whether the rest of the AI stack is worth paying for.
A model released on October 20, 2026 gives a useful set of numbers to work with. OXR, a 1.3-billion-parameter document parser from SoMarkAI, a document-parsing company headquartered in Shanghai, publishes both its accuracy results and a detailed speed benchmark, with code and weights available on GitHub. That makes it possible to do the capacity math for self-hosting from public figures.

Recognition decoding speed and end-to-end throughput, 21 models on one RTX PRO 6000. Source: SoMarkAI.
The measured speed
SoMarkAI tested 21 document-parsing models under one protocol: a single NVIDIA RTX PRO 6000 Blackwell GPU with 96 GB of memory, a 24-CPU quota, 96 GiB of RAM, and a frozen 100-page subset of the OmniDocBench dataset reused for every model. The full protocol, including the list of pages, is in the repository's benchmark document.
OXR completed the 100 pages end to end in 100.972 seconds on average across two rounds, or 0.990373 pages per second. The next fastest, OvisOCR2, ran at 0.741960 pages per second. That gives OXR 33.5% higher throughput than the runner-up.
Converting speed into capacity
Pages per second becomes useful once it is turned into the units an operations team plans in. At 0.99 pages per second, one GPU processes about 3,565 pages an hour and about 85,600 pages a day of continuous running.
The table below converts the benchmark's measured throughput for five of the 21 models into the time one GPU would need for one million pages, assuming the same hardware and a workload similar to the test set.
| Model | Pages per second | Hours per 1M pages | Days per 1M pages |
|---|---|---|---|
| OXR-1.0 | 0.990 | 280 | 11.7 |
| OvisOCR2 | 0.742 | 374 | 15.6 |
| PaddleOCR-VL-1.6 | 0.691 | 402 | 16.8 |
| MinerU2.5-Pro | 0.393 | 707 | 29.5 |
| Chandra-OCR-2 | 0.064 | 4,327 | 180.3 |
Derived from end-to-end throughput in SoMarkAI's published 21-model benchmark, one RTX PRO 6000 per model.
The spread is the point. For a fixed backlog, GPU time scales with the inverse of throughput, so the gap between the first and fifth rows in this table is a factor of more than 15 in compute. Whatever an organization pays per GPU-hour, owned or rented, multiplies straight through that column.
Why accuracy belongs in the same calculation
Throughput is the visible cost. Parsing errors are the hidden one, because they surface later, in a different budget.
A table flattened into a run of numbers produces a wrong answer in a retrieval system. A two-column page read straight across mixes sentences from separate columns. These errors travel. An analyst checks the output, a support agent escalates a bad answer, a compliance team reviews an extraction that should have been right. The labor attached to each error usually costs far more than the compute that produced it.
That is why the accuracy figures matter commercially. In SoMarkAI's comparison against published scores, OXR ranks first on olmOCR-Bench (87.84), OmniDocBench (97.18) and DocParsingBench (87.76). It ranks first in tables: on DocParsingBench, OXR scores 80.04 on tables against 77.69 for the next best system in that category, and on olmOCR-Bench's table category it scores 93.05, the highest in the comparison. For financial documents, where tables carry most of the value, that is the category that decides how much rework follows.
SoMarkAI attributes accuracy to the architecture and its training working together, and speed mainly to the architecture. Layout analysis runs as a separate model, and OXR handles recognition and reading order in one pass, removing a sequential reading-order stage. Post-training uses a recursive self-improvement loop that targets the samples the model misreads or is uncertain about.
The licensing variable
OXR’s code and weights are publicly available under Apache 2.0 with additional terms. Review the current LICENSE file for commercial-use thresholds, attribution requirements and scope.
For a larger enterprise, the comparison becomes a license fee plus hardware against the per-page pricing of a hosted service. Hardware remains part of any self-hosting cost model. Organizations should review the current license alongside their expected workload before comparing local deployment with a hosted service.
Hardware entry point
The minimum footprint is modest by current AI standards. SoMarkAI lists Linux and an NVIDIA GPU with BF16 support, with 24 GB of video memory enough for low-concurrency testing and 48 GB or more recommended for long documents or higher concurrency. The model is served on vLLM through a plugin shipped with the weights.
There is also a zero-cost way to evaluate before committing. SoMarkAI runs a free hosted API with no signup or key, meant for testing: requests are queued, and the company advises against production use. A finance team can run its own worst documents through it, compare the output with what it gets today, and then decide whether the throughput math above is worth acting on.
Caveats on the numbers
Benchmarks are a starting point for a capacity plan. The speed test uses one GPU model and a 100-page sample drawn from a public dataset; a company's documents may be longer, denser or more uniform. Concurrency settings, page sizes and output formats all move real throughput. The accuracy rankings rely on scores published by other teams and apply to the models compared as of October 5, 2026.
The direction of the evidence is still clear. For organizations that parse documents at scale, a small model that is both fast and accurate changes the cost of the pipeline at both ends: fewer GPU-hours going in, and less correction coming out.