dots.ocr is an open-weight, MIT-licensed document parser that reads layout and text from a page in a single vision language model. Three things almost nobody tells you: it was renamed dots.mocr in March 2026 and both its homes moved, the cheapest AWS GPU cannot run it at all, and the "1.7B" figure everyone repeats is not the checkpoint you download.
Written for US engineering and procurement teams deciding whether to self-host dots.ocr. Every figure here comes from a primary source and the arithmetic is shown. Last updated September 2026.
Upload a document to extract
Drop files here or click to upload
Up to 50 files
Free plan extracts the first 5 files, the rest unlock when you upgrade
Uploading...
Before you rent a GPU by the hour, drop in the hardest document you have and see what finished, validated fields look like.
dots.ocr is an open-weight vision language model that parses a document page in one pass, returning layout regions and their text together rather than running detection and recognition as separate stages. It came out of a research group at RedNote in July 2025, it is MIT licensed with no revenue threshold attached, and the weights have been downloaded 279,367 times in the last month. On the independent OmniDocBench board it scores 90.77 overall with a table TEDS of 87.18, which puts it in the upper group of open models without being the leader.
The three facts that decide adoption are not on the front page of the repository. It has been renamed. It will not run on the GPU you were probably going to rent. And the parameter count in every write-up about it is the wrong number.
Read this one twice before you copy a tutorial. The project's own News entry states, verbatim: "2026.03.19 We have rebranded dots.ocr-1.5 as dots.mocr." Two organization moves came with it. The GitHub repository at rednote-hilab/dots.ocr now returns an HTTP 301 to repository id 1028989499, which resolves to studio-dots-ai/dots.ocr, and the HuggingFace organization rednote-hilab is now dots-studio. The old paths still redirect, so nothing is broken today. But almost every dots.ocr tutorial, Docker file and pip snippet on the internet was written before March 2026 and names an organization that no longer exists under that name, and the model those tutorials install stopped being updated on October 31, 2025.
dots.ocr became dots.mocr on March 19, 2026, and the model that shipped under the new name is the same size as the one that shipped under the old one. This is a rebrand of a maturing project rather than a deprecation. Nothing has been taken away, no end of life has been announced, and the original checkpoint is still there and still downloadable. What changed is where active work happens, and every name you would use to find it.
| What | Before | Now | How we checked |
|---|---|---|---|
| GitHub repository | rednote-hilab/dots.ocr | studio-dots-ai/dots.ocr | The old API path returns HTTP 301 to repository id 1028989499 |
| HuggingFace organization | rednote-hilab | dots-studio | Model paths such as dots-studio/dots.ocr resolve; the old org name does not |
| Model name | dots.ocr-1.5 | dots.mocr | Rebranded March 19, 2026 according to the project News entry |
| SVG variant | did not exist | dots.mocr-svg | Released alongside dots.mocr, weights last touched March 20, 2026 |
| Base model | dots.ocr.base | dots.ocr.base | Unchanged, released October 31, 2025, 13 likes and 29 downloads |
| Licence | MIT | MIT | Unchanged across the rename, on the repository and all four checkpoints |
| Parameter count | 3,039,179,264 | 3,039,179,264 | Identical. The rebrand did not change the model size |
dots.mocr, unless you have a specific reason to pin the older weights. On the team's own olmOCR-Bench table the successor wins seven of the eight columns, and the one column where the original is ahead is headers and footers, by a tenth of a point. Both are the same 3.04 billion parameters, both are MIT, and both load the same way. The gaps that matter are on old scans with mathematics, where dots.mocr scores 85.5 against 64.2, and on tables, where it scores 90.7 against 88.3.
dots.mocr already pulls 469,916 monthly HuggingFace downloads against 279,367 for dots.ocr, a factor of 1.68. It has 166 likes against 1,327, because likes accumulate over a year and downloads reset every month. That split is what a rename looks like halfway through.
Last code push to master was March 24, 2026, with 146 open issues sitting against 9,097 stars and 806 forks. The dots.ocr weights were last modified October 31, 2025. The dots.mocr weights were touched July 4, 2026. Work moved, it did not stop.
The successor parses charts, diagrams, chemical structures and logos directly into SVG code rather than describing them, and there is a dedicated dots.mocr-svg checkpoint for that specifically. The team is candid that a 3B model does not excel at it yet.
| Checkpoint | Downloads, last 30 days | Likes | Weights last modified | Licence |
|---|---|---|---|---|
| dots.ocr | 279,367 | 1,327 | October 31, 2025 | MIT |
| dots.mocr | 469,916 | 166 | July 4, 2026 | MIT |
| dots.mocr-svg | 3,512 | 35 | March 20, 2026 | MIT |
| dots.ocr.base | 29 | 13 | October 31, 2025 | MIT |
Figures read from the HuggingFace model API on September 1, 2026. Download counts are a rolling 30-day window and will move.
Plan for a 24 GB card, but understand that the model is not what fills it. The weights are 5.66 GiB. Even a full-length sequence at the model's maximum 131,072-token context adds only another 3.5 GiB. The 24 GB recommendation you see everywhere is about serving concurrent requests and about vLLM preallocating the card, not about the model being large. Here is the arithmetic, all of it derived from the published config.json.
| What is consuming memory | How it is computed | Result |
|---|---|---|
| Weights, BF16 | 3,039,179,264 params x 2 bytes | 5.66 GiB |
| KV cache, per token | 2 x 28 layers x 2 KV heads x 128 head dim x 2 bytes | 28 KiB |
| KV cache, full 131,072-token window | 28 KiB x 131,072 tokens | 3.50 GiB |
| Weights plus one maximum-length sequence | sum of the two above | about 9.2 GiB |
| What vLLM actually reserves | --gpu-memory-utilization 0.9 from the project README | 90 percent of whatever card you give it |
The grouped-query attention in this model is doing a lot of work here. With only 2 key-value heads against 12 attention heads, the KV cache is six times smaller than it would be with full multi-head attention, which is why a 131,072-token window costs 3.5 GiB rather than 21 GiB.
No, and this is the finding that costs teams a day. A 16 GB T4 has more memory than the 9.2 GiB the model needs, and it still cannot run it. The reason is two lines in config.json: the checkpoint's torch_dtype is bfloat16, and the vision tower pins "attn_implementation": "flash_attention_2". Turing-generation cards support neither. You need Ampere or newer, which is a hard architectural floor and not something you can tune around.
That single line reshapes the economics against every other open parser. PaddleOCR benchmarks on a T4 and runs happily on one at $0.5260 an hour. dots.ocr starts at $0.8048. Here is the whole AWS GPU ladder in US East (N. Virginia), on-demand Linux, priced on the day this page was written.
| Instance | GPU | Architecture | VRAM | On-demand, per hour | Runs dots.ocr? |
|---|---|---|---|---|---|
| g4dn.xlarge | Tesla T4 | Turing | 16 GB | $0.5260 | No. No BF16 and no FlashAttention-2 |
| g6.xlarge | NVIDIA L4 | Ada Lovelace | 24 GB | $0.8048 | Yes, and it is the cheapest that does |
| g5.xlarge | NVIDIA A10G | Ampere | 24 GB | $1.0060 | Yes, 25 percent more per hour than the L4 |
| g5.2xlarge | NVIDIA A10G | Ampere | 24 GB | $1.2120 | Yes. The box most deployment guides recommend |
| g6e.xlarge | NVIDIA L40S | Ada Lovelace | 48 GB | $1.8610 | Yes, and overkill for a 3B model |
The saving nobody publishes. Every popular dots.ocr deployment write-up reaches for g5.2xlarge, because the A10G was the obvious 24 GB Ampere card when the model launched in 2025. g6.xlarge gives you the same 24 GB on a newer L4, also clears the FlashAttention-2 bar, and costs $0.8048 an hour against $1.2120. Running one instance around the clock that is $587.50 a month instead of $884.76, a saving of $297.26 a month for identical VRAM. If you have four inference boxes, that is $14,268 a year for changing one letter in an instance type.
Nobody can honestly tell you, including us, and anyone quoting a single dollar-per-page figure for dots.ocr is guessing. The team publishes no throughput number, and throughput on a document model depends on page density, resolution, batch size and whether you are running the layout pass alone or the full parse. What is verifiable is the hourly rate. So the honest way to cost a self-hosted parser is to fix the hourly rate, then read your cost off whatever pages per hour you measure on your own documents.
One g6.xlarge at $0.8048 an hour. Measure your pages per hour, find the row.
| If you measure | Hours per 1,000 pages | Cost per 1,000 pages |
|---|---|---|
| 100 pages per hour | 10.00 hours | $8.05 |
| 250 pages per hour | 4.00 hours | $3.22 |
| 500 pages per hour | 2.00 hours | $1.61 |
| 1,000 pages per hour | 1.00 hour | $0.80 |
| 2,500 pages per hour | 0.40 hours | $0.32 |
| 5,000 pages per hour | 0.20 hours | $0.16 |
| 10,000 pages per hour | 0.10 hours | $0.08 |
How busy the card has to stay before self-hosting beats a managed rate.
| Managed rate you are replacing | Break-even throughput | Equivalent monthly volume |
|---|---|---|
| $0.50 per 1,000 pages | 1,610 pages an hour, sustained | 1,175,008 pages a month |
| $1.50 per 1,000 pages (AWS Textract text, Azure Read, Google Enterprise OCR) | 537 pages an hour, sustained | 391,669 pages a month |
| $10.00 per 1,000 pages (Azure Layout, Bedrock Data Automation) | 81 pages an hour, sustained | 58,750 pages a month |
| $15.00 per 1,000 pages (AWS Textract TABLES) | 54 pages an hour, sustained | 39,167 pages a month |
| $30.00 per 1,000 pages (Google Form Parser) | 27 pages an hour, sustained | 19,583 pages a month |
The line to take away is the second row. Against a $1.50 per 1,000 pages managed rate, which is what AWS Textract charges for plain text, what Azure charges for Read and what Google charges for Enterprise Document OCR, a self-hosted dots.ocr box has to sustain 537 pages every hour of every day before it is cheaper. That is 391,669 pages a month, and it assumes the card never idles. Most teams evaluating an open parser are nowhere near that number, which is why the honest reason to self-host is usually data residency or unit-cost control at genuine scale rather than a smaller bill next month. The same arithmetic across every open reader is on our self-hosted OCR cost page, and the managed rates it is being compared against are on OCR pricing per 1,000 pages.
Middling on composite scores and genuinely excellent on tables, which for a finance or operations team is the more useful half of that sentence. On the independent OmniDocBench board it scores 90.77 overall with a table TEDS of 87.18, third among the systems we track and behind PaddleOCR-VL-1.6 and MinerU2.5-Pro. On the team's own olmOCR-Bench table it is 79.1 overall, sixth of eleven. But its Tables column of 88.3 is the highest number in that entire table except its own successor.
| System | Size | Overall | Table TEDS | Licence |
|---|---|---|---|---|
| PaddleOCR-VL-1.6 | 0.9B | 96.34 | 94.76 | Apache-2.0, no cap |
| MinerU2.5-Pro | 1.2B | 95.75 | 93.42 | Apache 2.0 plus a revenue cap |
| dots.ocr | 3B | 90.77 | 87.18 | MIT, no cap |
| DeepSeek-OCR 2 | 3B | 90.25 | 83.89 | Open weights |
| olmOCR | 7B | 85.74 | 83.00 | Open weights |
| Mistral OCR | not stated | 85.66 | 76.78 | Commercial API |
| Marker | not a single model | 78.44 | 65.77 | Weights free below $5M revenue |
| AWS Textract, Azure DI, Google Document AI | not stated | Not on the board | Not on the board | Commercial API |
OmniDocBench, the independent CVPR 2025 board. Its Overall metric is defined as ((1 minus text edit distance) times 100, plus table TEDS, plus formula CDM) divided by three, so 90.77 is a composite of three different skills and not a claim that 90.77 percent of characters came out right. The full board, and the finding that AWS Textract, Azure Document Intelligence and Google Document AI publish no accuracy figure and appear on no public leaderboard at all, is on our OCR accuracy comparison.
Here is the table the dots team publishes in its own repository, sorted by the overall column. Read down the Tables column instead and the ranking inverts. This is the second time we have seen a composite bury a grid specialist: HunyuanOCR sits 18th on OmniDocBench's composite and 6th on tables for exactly the same reason. Averaging text accuracy, table structure and formula recognition into one number is fine for a research leaderboard and misleading for a procurement decision, because almost nobody buys a document parser to read prose.
| Model | ArXiv | Old scans math | Tables | Old scans | Headers and footers | Multi column | Long tiny text | Overall |
|---|---|---|---|---|---|---|---|---|
| dots.mocr | 85.9 | 85.5 | 90.7 | 48.2 | 94.0 | 85.3 | 81.6 | 83.9 |
| Chandra OCR 0.1.0 | 82.2 | 80.3 | 88.0 | 50.4 | 90.8 | 81.2 | 92.3 | 83.1 |
| Infinity-Parser 7B | 84.4 | 83.8 | 85.0 | 47.9 | 88.7 | 84.2 | 86.4 | 82.5 |
| olmOCR v0.4.0 | 83.0 | 82.3 | 84.9 | 47.7 | 96.1 | 83.7 | 81.9 | 82.4 |
| PaddleOCR-VL | 85.7 | 71.0 | 84.1 | 37.8 | 97.0 | 79.9 | 85.7 | 80.0 |
| dots.ocr | 82.1 | 64.2 | 88.3 | 40.9 | 94.1 | 82.4 | 81.2 | 79.1 |
| Marker 1.10.1 | 83.8 | 66.8 | 72.9 | 33.5 | 86.6 | 80.0 | 85.7 | 76.1 |
| DeepSeek-OCR | 77.2 | 73.6 | 80.2 | 33.3 | 96.1 | 66.4 | 79.4 | 75.7 |
| MinerU 2.5.4 | 76.6 | 54.6 | 84.9 | 33.7 | 96.6 | 78.2 | 83.5 | 75.2 |
| Mistral OCR API | 77.2 | 67.5 | 60.6 | 29.3 | 93.6 | 71.3 | 77.1 | 72.0 |
| Nanonets-OCR2-3B | 75.4 | 46.1 | 86.8 | 40.9 | 32.1 | 81.9 | 93.0 | 69.5 |
Label this table correctly, because it matters. These are the dots team's own published olmOCR-Bench figures, reproduced from their repository. The team also publishes an Elo ranking in which dots.ocr scores 1086.2 and dots.mocr 1124.7, both ahead of PaddleOCR-VL-1.5 at 920.5 and HuanyuanOCR at 984.2 but behind Gemini 3 Pro at 1210.7. That Elo evaluation was judged by Gemini 3 Flash, by the team's own note. Vendor-published benchmarks are still useful, especially when they show a model losing, and this one does show dots.ocr losing to four other systems on the composite. Treat it as a strong hypothesis to test on your documents, not as an independent result.
The team's own caveat, in tension with that 88.3. The repository's Limitation section says that extracting complex tables and mathematical formulas "persists as a difficult task given the model's compact architecture", and that outright parsing failures "may still occur occasionally". Both things are true at once: dots.ocr is very good at tables relative to models of its size, and a 3 billion parameter model reading a dense financial statement will still occasionally produce a grid that does not reconcile. The weakest column in the table above tells the same story from the other side. Old scans math at 64.2 is the lowest of any model listed except Nanonets-OCR2-3B.
There is no official hosted dots.ocr API. The team ships weights and vLLM serving instructions, so the API is the one you stand up. That is a meaningful difference from Mistral OCR or MinerU, both of which operate an endpoint you can call with a key. If you want dots.ocr in production you are running a GPU service, with everything that implies: a queue, a retry policy, health checks, a model upgrade path and somebody on call.
PyTorch built for your CUDA version first, then flash-attn, then the package. The project pins its examples to torch 2.7.0 on CUDA 12.8 with flash-attn 2.8.0.post2. Getting flash-attn to compile against the wrong torch is the most common way this install goes wrong.
The models now live under dots-studio on HuggingFace, with a ModelScope mirror. Use dots-studio/dots.mocr for new work. Any tutorial telling you to pull rednote-hilab/dots.ocr is pre-March 2026 and will get you the older checkpoint.
vllm serve dots-studio/dots.mocr --tensor-parallel-size 1 --gpu-memory-utilization 0.9 --chat-template-content-format string --served-model-name model --trust-remote-code. Two of those matter. The 0.9 is why the card looks full. The --trust-remote-code is a security review item.
Why --trust-remote-code is not optional here. The model's config.json uses an auto_map block pointing at configuration_dots.DotsOCRConfig and modeling_dots_ocr.DotsOCRForCausalLM, which are Python files shipped inside the model repository rather than classes that exist in the transformers library. Loading the model executes that code. For most teams that is a shrug. For a regulated US enterprise it is a line item in a security review, and it is better to raise it yourself in week one than to have it found in week nine.
What comes back is layout regions with their text, which you then serialize. If Markdown is what you want at the end, our PDF to Markdown API page covers what every vendor emits and the finding that Markdown is a more expensive meter rather than an output toggle. If you need typed fields to post into a system, PDF to JSON API is the right route, and PDF to CSV API covers getting a parsed grid into a spreadsheet, including the merged-cell trap that flattens columns.
If you are comparing dots.ocr against another open model, the two benchmark tables above are your starting point and your own documents are the tiebreak. If what you actually want is to stop operating a parsing service, the comparison is with a managed product, and it is a question about which parts of the job you are buying rather than which model reads a page better. Here is that second comparison, stated fairly.
| Question | Self-hosted dots.ocr | A managed extraction product |
|---|---|---|
| What you pay | $587.50 a month per always-on g6.xlarge, plus your engineers | A published per-page rate and nothing else |
| Who runs it | You. A GPU box, a queue, a retry policy, a model upgrade path | The vendor |
| Cost when the queue is empty | The same $0.8048 an hour | Zero |
| Where documents are processed | Your own infrastructure, in your own region | The vendor region you selected |
| What you get back | Layout JSON and Markdown for the whole page | Named fields mapped to your schema |
| Confidence per business field | No. Page structure, not validated field values | Standard on document products |
| Validation and human review | You build it | Part of a workflow product |
| Export into accounting or an ERP | You build it | Included |
| Licence risk | None. MIT with no revenue threshold | A contract |
| Who is accountable when a number is wrong | You | A vendor with an SLA |
We sell the right-hand column, so weigh the rows accordingly. dots.ocr is a genuinely good model with the cleanest licence in its category, plain MIT with no revenue threshold anywhere, which is better than Marker and better than MinerU. Its table score is the best of any open model of its size after its own successor. If you have a GPU, an engineer who wants to own an inference service, and what you need is a parsed page, self-host it and do not let anybody sell you out of that decision. The case for buying was never price per page. It is that a parser hands you a document and a workflow hands you checked fields, routed, reviewed and posted into the system that needed them. And one thing worth saying plainly: DocuOCR is a cloud product. If your documents genuinely cannot leave your network, we are not the answer either, and on-premise OCR software covers the options that are, including the ones that are not us.
The system at the top of the independent board at 96.34, and the one open model that runs on the $0.5260 T4 that dots.ocr cannot use.
Read itSecond on the board at 95.75, with the highest table score measured anywhere, and a hosted API documented to time out on AWS URLs.
Read itThe other 3B open reader, costed from DeepSeek's own throughput claim, plus the correction to the 97 percent accuracy figure everyone repeats.
Read itIBM's CPU-first parser at about $0.21 per 1,000 pages, and the cheapest of this group to operate if you have no GPU budget.
Read itThe full OmniDocBench board and the finding that the three biggest cloud document APIs publish no accuracy number at all.
Read itThe same hourly-rate arithmetic applied across every open-weight reader worth evaluating.
Read itEvery managed vendor normalized to one unit, so the break-even table above has something honest to sit against.
Read itWhat each vendor emits when you ask for Markdown, and why Markdown is a more expensive meter rather than a toggle.
Read itIf the documents genuinely cannot leave your network, the honest options, including the ones that are not us.
Read itA composite benchmark score cannot tell you how a 3 billion parameter model handles your vendor's invoice template, and dots.ocr publishes no throughput number you can budget against. Upload the document you were about to write a dots.ocr script for and see what finished, validated fields look like. If dots.ocr wins on your documents, use dots.ocr.
