olmOCR: A 7B Vision Model Pipeline for Turning PDFs into LLM Training Text
Toolkit for linearizing PDFs for LLM datasets/training
At a glance
- What is it?
- olmOCR is Allen AI's Apache-2.0 toolkit for converting PDF, PNG and JPEG documents into clean Markdown using a 7B vision language model. It competes on old scans and maths rather than on tables, and it needs a GPU to run at all.
- Who is it for?
- Adopt olmOCR if you are assembling a text corpus from scanned or image-based documents and you already have GPU capacity, because the benchmark table shows its strongest columns are old scans with maths (82.3) and old scans generally (47.7), where Marker 1.10.1 records 66.8 and 33.5.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 174 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What olmOCR is for, and who ends up using it
The README describes olmOCR as a toolkit for converting PDFs and other image-based document formats into clean, readable, plain text. The stated feature list is narrow and specific: PDF, PNG and JPEG inputs, Markdown output, support for equations, tables, handwriting and complex formatting, automatic removal of headers and footers, and a natural reading order preserved through figures, multi-column layouts and insets. The cost line in the README is less than $200 USD per million pages converted, qualified immediately by the parenthetical that this is based on a 7B parameter VLM and therefore requires a GPU. That parenthetical is the whole adoption decision in one sentence. Anyone can read a PDF; the people who reach for olmOCR are building training or evaluation corpora at a scale where per-page API pricing and per-page review labour both matter, and where the source material is scans rather than born-digital text. Allen AI's own framing is explicit in the repository description: linearizing PDFs for LLM datasets and training. The project also ships its own benchmark, olmOCR-Bench, which the README says covers over 7,000 test cases across 1,400 documents. Shipping the yardstick you are measured by is a conflict worth noting, though the table includes external systems, which makes it falsifiable by anyone willing to rerun it.
The pipeline: render to image, run vLLM, linearize
olmOCR does not parse PDF structure directly. The system dependencies tell you the mechanism: poppler-utils plus a set of fonts (ttf-mscorefonts-installer, fonts-crosextra-caladea, fonts-crosextra-carlito, gsfonts, lcdf-typetools) exist because the pipeline renders PDF pages to images first. Rendering is where the fonts matter, since a page rendered without the correct typeface produces a different image and therefore a different model output. The release notes trace the inference backend history: v0.1.75 switched from sglang to a vllm based inference pipeline and moved the Docker image to CUDA 12.8. So the data flow is PDF or image, rendered page image, VLM inference through vLLM, Markdown text. The model is a 7B VLM; v0.2.1 notes the default became FP8, which the release notes credit for significantly faster runs and far fewer retries per document. Retries are a first-class concept here, not an error path. Sampling temperature was tuned in v0.1.60 for performance, and v0.2.0 added cleaned-up trainer code under olmocr/train for training your own models. The consequence of this architecture is that OCR quality and GPU throughput are coupled: every quality improvement that requires more sampling or more retries costs pages per hour.
Installing olmOCR: the commands the README gives
The README's installation section starts with system dependencies on Ubuntu or Debian: sudo apt-get update, then sudo apt-get install poppler-utils ttf-mscorefonts-installer msttcorefonts fonts-crosextra-caladea fonts-crosextra-carlito gsfonts lcdf-typetools. Note that msttcorefonts is a legacy alias and that ttf-mscorefonts-installer prompts for a EULA acceptance during install, which breaks unattended Docker builds unless you preseed debconf. The README continues into a Python installation subsection, but the supplied text is truncated at the words Set, so the exact pip command and any virtual environment guidance cannot be confirmed from the material here. What can be confirmed is that Docker support and official images arrived in v0.1.70, with a Using Docker section referenced from the release notes, and that the image was updated to CUDA 12.8 in v0.1.75. For a GPU workload with a font-bundling step, the Docker path avoids reproducing the apt and font setup by hand. The README also points to a benchmark directory at olmocr/bench and a trainer at olmocr/train, so the repository is not only an inference tool.
Where olmOCR wins, and where it does not
The benchmark table is the most useful page in the README because it is disaggregated. olmOCR v0.4.0 scores 82.4 overall, behind Chandra OCR 0.1.0 at 83.1 and Infinity-Parser 7B at 82.5, ahead of PaddleOCR-VL at 80.0, Marker 1.10.1 at 76.1, DeepSeek-OCR at 75.7, MinerU 2.5.4 at 75.2 and Mistral OCR API at 72.0. Overall rank hides the useful part. On Old scans math olmOCR records 82.3, against 66.8 for Marker and 73.6 for DeepSeek-OCR. On Old scans it records 47.7 against 33.5 for Marker, 33.7 for MinerU and 29.3 for Mistral OCR API. Those two columns are the argument for the project: degraded historical scans with mathematical notation. Now the other direction. On Tables olmOCR scores 84.9, below Chandra OCR 0.1.0 at 88.0, Nanonets-OCR2-3B at 86.8, Infinity-Parser 7B at 85.0 and MinerU 2.5.4 at 84.9 (a tie, with MinerU marked by an asterisk). On Long tiny text olmOCR scores 81.9, below Nanonets-OCR2-3B at 93.0 and Chandra OCR 0.1.0 at 92.3. If your corpus is dense financial tables or pages of fine print, the table says olmOCR is not the strongest option, whatever the overall number suggests. The asterisks on some competitor rows are not explained in the supplied material, so treat those comparisons with caution.
The GPU requirement is the real constraint
The README states the model is a 7B parameter VLM and requires a GPU. This is not a footnote. It means olmOCR cannot run in a serverless function, a CI runner without accelerators, or a laptop without a discrete GPU, at least not at the throughput the cost figure implies. Everything that makes the toolkit attractive at scale (vLLM batching, FP8 weights, retry-on-failure sampling) assumes hardware that many teams do not have sitting idle. A second limitation comes from the release history itself. The news entries show a model release roughly every one to two months through 2025: v0.2.1 in July, v0.3.0 in August, v0.4.0 in October with a note that it boosts the olmOCR-Bench score by about 4 points and introduces RL training. The repository's last push is dated 2026-03-25 and the most recent release listed is v0.4.27 from 2026-03-12. A project iterating this quickly means your pinned model weights and your pipeline version both drift. The v0.3.0 note that the release fixes auto-rotation detection and hallucinations on blank documents is a reminder that earlier versions had those failure modes, and blank-page hallucination is a particularly bad one for a training corpus, since it injects invented text into documents that had none. Third limitation: the README's own benchmark suite is the primary public evidence of quality, and the project authors maintain it.
Marker and MinerU solve the same problem differently
Marker 1.10.1 is the closest comparison point in the supplied table and the difference is architectural. Marker scores 83.8 on ArXiv against olmOCR's 83.0, and 72.9 on Tables against 84.9, but collapses to 66.8 on Old scans math and 33.5 on Old scans. That pattern is consistent with a pipeline built around document structure and layout heuristics rather than a general vision model reading the rendered page. Marker's advantage is that it does not need a 7B VLM to produce useful output, which matters if you have no GPU. Its weakness is exactly the material olmOCR was built for. MinerU 2.5.4 shows the opposite trade: 84.9 on Tables and 96.6 on Headers & footers, but 54.6 on Old scans math and 33.7 on Old scans. PaddleOCR-VL leads the ArXiv column at 85.7 and the Headers & footers column at 97.0. The honest reading is that these are not interchangeable tools with a single quality ranking. They are tuned for different document populations, and the benchmark table is the only supplied evidence for which population each one serves. Note also that the README marks several competitor rows with asterisks and does not define them in the material provided.
Licence, maintenance and what an upgrade actually costs
olmOCR is Apache-2.0. That is a permissive licence, which means you can use it commercially, modify it and redistribute it, subject to the terms of the licence text itself. The README's licence badge links to the OLMo repository's LICENSE file rather than to a file inside olmocr, which is worth checking before you rely on it for compliance paperwork; the repository metadata says Apache-2.0, and the badge points elsewhere. This is not legal advice, and the model weights on Hugging Face (olmOCR-2-7B-1025-FP8, olmOCR-7B-0825-FP8, olmOCR-7B-0725-FP8) may carry their own terms separate from the code. On maintenance cost, the release cadence is the number that matters. Between 2026-01-23 and 2026-03-12 the project shipped v0.4.24, v0.4.25 and v0.4.27. If you pin a version, you are choosing to miss model improvements that the release notes tie directly to benchmark gains; if you track main, you re-validate your corpus after each model swap, because output text changes and downstream training data silently shifts. Budget for a re-run of your own held-out sample on every model bump, not just on every code bump.
Editorial conclusion
Adopt olmOCR if you are assembling a text corpus from scanned or image-based documents and you already have GPU capacity, because the benchmark table shows its strongest columns are old scans with maths (82.3) and old scans generally (47.7), where Marker 1.10.1 records 66.8 and 33.5. Do not adopt it for CPU-only environments or for table-heavy extraction, since the README states the model is a 7B VLM that requires a GPU and its tables score of 84.9 sits below MinerU 2.5.4 at 84.9 with PaddleOCR-VL at 84.1 and Chandra OCR 0.1.0 at 88.0. Verify first that poppler-utils, the Microsoft and Carlito fonts, gsfonts and lcdf-typetools are installable on your target image, and that your GPU can host the FP8 7B model plus vLLM.
Community notes