There is no DeepSeek OCR API. The weights are free, the GPU is not, and running them costs about $0.33 per 1,000 pages at DeepSeek's own published throughput. The 97 percent accuracy figure filling this search results page is a misreading of the paper: on the one independent benchmark that ranks it, DeepSeek-OCR 2 scores 90.25, 17th of 32.
Written for US engineering and procurement teams deciding whether to self-host. Every figure is pulled from a primary source and the arithmetic is shown. Last updated August 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 provision a GPU, drop in the hardest document you have and see what finished, validated fields look like.
DeepSeek-OCR is a 3.3-billion-parameter vision language model that DeepSeek released in October 2025 to test an unusual research question: can you store a long piece of text more cheaply as a picture of that text than as text tokens? The paper is called Contexts Optical Compression, and OCR is the measuring instrument rather than the product. It works well enough that people started using it as a document reader, which is why you are here.
Three facts settle most buying decisions. There is no DeepSeek OCR API, so the only way to use it is to host it. The licence is genuinely permissive, MIT for v1 and Apache-2.0 for the January 2026 successor. And the compute is cheap in the way open weights always are, roughly $0.33 per 1,000 pages against the $1.50 that AWS, Azure and Google all charge for plain text extraction, with the catch that a rented GPU bills for its idle hours too.
The correction that matters most, because the entire first page of Google gets it wrong. You will see "DeepSeek OCR is 97% accurate" repeated everywhere, often against invented Tesseract and PaddleOCR figures. DeepSeek's abstract actually says the model "can achieve decoding (OCR) precision of 97%" when the number of text tokens is within 10 times the number of vision tokens, and that at a 20x compression ratio "the OCR accuracy still remains at about 60%". That is a measurement of how much text survives being squeezed into a smaller visual representation. It is not a character accuracy rate on invoices, and it was never presented as one. The number to use instead is the independent one: 90.25 on OmniDocBench v1.7, 17th of 32 systems.
"DeepSeek OCR API" gets searched every month and the honest answer is that the thing being searched for does not exist. DeepSeek's published API serves three models, and DeepSeek-OCR is not among them. The closest thing is a general vision chat model, which is a different model with different weights, a different price shape and, as the next section shows, a hard ceiling on how much of your page it is allowed to look at.
| Model on api.deepseek.com | Accepts | Input per 1M, off-peak | Output per 1M, off-peak | Notes |
|---|---|---|---|---|
| deepseek-v4-flash | Text | $0.22 | $0.66 | No image input. Returns 400 on an image block. |
| deepseek-v4-pro | Text | $0.66 | $1.98 | No image input. Returns 400 on an image block. |
| deepseek-v4-flash-vision-exp | Text and images | $0.22 | $0.66 | The only model that accepts images. Not DeepSeek-OCR. |
| DeepSeek-OCR | Not on the API | n/a | n/a | Open weights only. Download and host it yourself. |
| DeepSeek-OCR 2 | Not on the API | n/a | n/a | Open weights only. Download and host it yourself. |
Cache-miss input rates, read from DeepSeek's Models and Pricing page on August 30, 2026. Peak rates are exactly double every one of these figures.
DeepSeek charges peak rates from 01:00 to 04:00 and 06:00 to 10:00 UTC, Monday through Friday, and half that at every other hour. Converted to Eastern time those windows are 9pm to midnight and 2am to 6am. A batch that runs during US business hours, or any hour of a US weekend, is billed entirely at the off-peak rate. Nobody planning capacity in the United States needs to schedule around this, which is worth knowing precisely because it is the opposite of how cloud peak pricing usually behaves.
The usual escape hatch for an open-weight model is a serverless inference provider. Checked on August 30, 2026, the Hugging Face API reports exactly one provider mapped to DeepSeek-OCR, Novita, with its status recorded as error, and reports no providers at all for DeepSeek-OCR 2. So the answer to "where can I call DeepSeek OCR" is the same as the answer to "what does it cost": you are provisioning the endpoint yourself, and the cost is your GPU bill.
DeepSeek publishes no rate card, so a price has to be derived. Conveniently, DeepSeek published the two numbers needed to do it. The paper states that in production DeepSeek-OCR generates training data "at a scale of 200k+ pages per day (a single A100-40G)". That is a throughput figure attached to a named GPU, and a named GPU has a rentable price.
AWS does not rent a single A100 40GB. That silicon is sold in eight-GPU units as p4d.24xlarge, at $21.9576420 an hour on demand in US East, read from the AWS pricing feed with a manifest date of August 29, 2026. Divide by eight and one A100 40GB is $2.7447 an hour.
DeepSeek states 200,000 pages a day on one of those GPUs. Divided across 24 hours that is 8,333 pages an hour. It is DeepSeek's own figure for its own pipeline, so treat it as a best case rather than a promise about your documents.
$2.7447 divided by 8,333 pages is $0.000329 a page, which is $0.33 per 1,000 pages. Against the $1.50 per 1,000 that AWS, Azure and Google all charge for plain text extraction, that is about a fourfold to fivefold difference on compute alone.
| Way of running it | Per 1,000 pages | Where the number comes from |
|---|---|---|
| Self-hosted DeepSeek-OCR on a rented A100 40GB | $0.33 | DeepSeek states 200,000+ pages/day on one A100 40GB. AWS p4d.24xlarge is $21.9576/hr for 8 of them. |
| DeepSeek hosted vision model, off-peak, input only | $0.08 | 384 tokens per image at $0.22 per 1M input tokens. This is the read, not the write. |
| DeepSeek hosted vision model, off-peak, 700 output tokens | $0.55 | Output dominates: writing the page back out costs 5.5x what reading it in costs. |
| DeepSeek hosted vision model, peak, 700 output tokens | $1.09 | Peak is exactly double off-peak, and falls outside US business hours. |
| AWS Textract DetectDocumentText | $1.50 | Published rate, plain text extraction, first 1M pages. |
| Azure Document Intelligence Read | $1.50 | Published rate, S0 tier. |
| Google Enterprise Document OCR | $1.50 | Published rate, first 5M pages. |
Per-page compute is not what you pay. What you pay is the GPU, by the hour, forever. One rented A100 40GB is $2.7447 an hour, which is $2,004 a month whether it processes six million pages or six. At $1.50 per 1,000 pages, $2,004 buys about 1.34 million pages from a managed API. The box's ceiling at DeepSeek's own throughput is about 6.08 million pages a month, so the break-even sits at roughly 22 percent utilization. Below 1.34 million pages a month, a managed API is genuinely cheaper, and no amount of open-weight enthusiasm changes that arithmetic.
deepseek-v4-flash-vision-exp caps every image at 384 tokens, so reading a page in costs 384 tokens at $0.22 per million, which is $0.084 per 1,000 pages. Writing the page back out as markdown is where the money goes. At roughly 700 output tokens for a dense business page, that is $0.66 per million, or $0.46 per 1,000 pages, about 5.5 times the cost of reading it in. The 700-token assumption is ours and yours will differ, so the useful takeaway is the ratio, not the total.
This is the finding that decides whether the hosted route is usable for documents at all, and DeepSeek states it plainly in a place nobody looks. The vision guide says every image is resized before inference "so that the total pixel count after resizing is roughly that of an 800x800 image", with "an upper bound of 384 tokens per image", and adds that "a 2000x2000 image and a 5000x5000 image consume the same number of tokens after resizing".
Run that against a real document. A US Letter page scanned at 300 DPI is 2,550 by 3,300 pixels, or 8.4 million of them. Squeezing that to 640,000 pixels is a 13-fold reduction by area, which is a 3.6-fold reduction on each edge. Your 300 DPI scan arrives at the model as roughly 83 DPI. For a clean 11-point invoice that is probably fine. For 6-point disclosure text, a carbon-copy bill of lading or a faint fax, it is the whole ball game, and no prompt engineering recovers pixels that were discarded before inference started.
| What is looking at the page | Effective size | Pixels | What that means |
|---|---|---|---|
| US Letter scanned at 300 DPI | 2,550 x 3,300 | 8,415,000 | What your scanner produced |
| DeepSeek hosted vision API, after automatic resize | about 800 x 800 | 640,000 | A 13-fold reduction by area, roughly 83 effective DPI |
| Self-hosted DeepSeek-OCR, Base mode | 1024 x 1024 | 1,048,576 | Already 1.6x more pixels than the hosted API allows |
| Self-hosted DeepSeek-OCR, Large mode | 1280 x 1280 | 1,638,400 | 2.56x more pixels than the hosted API allows |
| Self-hosted DeepSeek-OCR 2, full dynamic mode | 6 tiles plus overview | 4,587,520 | 7.2x the hosted API, roughly 221 effective DPI |
The conclusion is counterintuitive and worth stating flatly: for document work, the free model you host yourself can see more of the page than DeepSeek's own paid vision endpoint. Large mode gives it 2.56 times the pixels, and DeepSeek-OCR 2's full dynamic mode gives it 7.2 times, which for a Letter page works out around 221 effective DPI. That is a strong argument for self-hosting that has nothing whatever to do with price.
DeepSeek documents its resolution modes as a menu of names and token counts, which makes them look like arbitrary presets. Divide the pixels by the tokens and they are not arbitrary at all. Every mode in both versions lands on precisely the same number, a 64 by 64 pixel patch per token. That single constant tells you more about picking a mode than the names do: you are not choosing a quality setting, you are choosing how many patches of a fixed size you are willing to pay for.
| Mode | Resolution | Vision tokens | Pixels | Pixels per token |
|---|---|---|---|---|
| Tiny | 512 x 512 | 64 | 262,144 | 4,096 |
| Small | 640 x 640 | 100 | 409,600 | 4,096 |
| Base | 1024 x 1024 | 256 | 1,048,576 | 4,096 |
| Large | 1280 x 1280 | 400 | 1,638,400 | 4,096 |
| Gundam tile (v1) | 640 x 640 | 100 | 409,600 | 4,096 |
| Dynamic tile (v2) | 768 x 768 | 144 | 589,824 | 4,096 |
| Global view (v2) | 1024 x 1024 | 256 | 1,048,576 | 4,096 |
It also settles a common misreading of the second release. DeepSeek-OCR 2 did not make the encoder denser. It kept the same 4,096 pixels per token and changed the tiling, moving from 640 by 640 crops at 100 tokens each to 768 by 768 crops at 144 tokens each, then reordering those tokens by what the image appears to contain rather than reading strictly left to right. Fewer, larger tiles cover a page with less overlap.
OmniDocBench is the independent, Apache-2.0 document parsing leaderboard from OpenDataLab, and its current v1.7 board ranks 32 systems end to end. DeepSeek-OCR 2 sits 17th with an overall score of 90.25. DeepSeek-OCR v1 is not on the current board at all, having been evaluated in October 2025 and since replaced by its successor.
One caution before reading the table, because it is the mistake the 97 percent claim already made once. The Overall column is defined by OmniDocBench as ((1 - text edit distance) x 100 + table TEDS + formula CDM) / 3. It blends three different measurements of three different things. A score of 90.25 does not mean 90.25 percent of characters were correct.
| System | Size | Overall | Text edit distance, lower is better | Table TEDS | How you get it |
|---|---|---|---|---|---|
| PaddleOCR-VL-1.6 | 0.9B | 96.34 | 0.0326 | 94.76 | Apache-2.0 open weights |
| MinerU2.5-Pro | 1.2B | 95.75 | 0.036 | 93.42 | Open weights, revenue-capped licence |
| GLM-OCR | 0.9B | 95.22 | 0.044 | 92.83 | Open weights |
| Gemini 3 Pro | not stated | 92.91 | 0.064 | 89.15 | Managed API |
| dots.ocr | 3B | 90.77 | 0.048 | 87.18 | Open weights |
| OpenDoc-0.1B | 0.1B | 90.67 | 0.049 | 83.88 | Open weights |
| DeepSeek-OCR 2 | 3B | 90.25 | 0.050 | 83.89 | Apache-2.0 open weights |
| HunyuanOCR | 1B | 89.95 | 0.088 | 91.01 | Open weights |
| Qwen3-VL-235B | 235B | 89.78 | 0.063 | 83.07 | Open weights |
| GPT-5.2 | not stated | 86.59 | 0.114 | 82.95 | Managed API |
| olmOCR | 7B | 85.74 | 0.139 | 83.00 | Open weights |
| Mistral OCR | not stated | 85.66 | 0.097 | 76.78 | Managed API |
| AWS Textract, Azure DI, Google Document AI | not stated | Not on the board | Not on the board | Not on the board | Managed API |
A text edit distance of 0.050 is close to the front of the board and better than every general-purpose frontier model ranked on it. On dense running text, DeepSeek-OCR 2 is genuinely strong, and it beats GPT-5.2 by 3.66 overall points at a fraction of the size.
Table TEDS of 83.89 is its weak column, 10.87 points behind PaddleOCR-VL-1.6 at 94.76. HunyuanOCR scores 91.01 on tables at a third of the parameters. If your documents are invoices, statements and remittance advices, tables are not a detail of the job, they are the job.
OpenDoc-0.1B scores 90.67 and edges out DeepSeek-OCR 2 at one thirtieth of the parameter count, while Qwen3-VL at 235B scores 89.78 and loses to both. Parameter count is a poor predictor of document parsing quality, which is a useful thing to know before sizing a GPU.
Worth noting what is absent from that table as much as what is in it. AWS Textract, Azure Document Intelligence and Google Document AI, the three most widely deployed document APIs in the United States, publish no accuracy figure and appear on no public leaderboard. The OCR accuracy comparison works through that in full.
DeepSeek-OCR 2 arrived on January 27, 2026, announced in v1's own README. Most write-ups have not caught up, and the ones that have tend to miss the detail your legal team will care about most: the licence changed between versions. v1 ships a 1,065-byte MIT LICENSE. v2 ships an 11,342-byte Apache-2.0 LICENSE.txt. Both Hugging Face cards agree with their repositories.
| DeepSeek-OCR | DeepSeek-OCR 2 | |
|---|---|---|
| Released | October 20, 2025 | January 27, 2026 |
| Paper | Contexts Optical Compression, arXiv:2510.18234 | Visual Causal Flow, arXiv:2601.20552 |
| Licence | MIT (LICENSE, 1,065 bytes) | Apache-2.0 (LICENSE.txt, 11,342 bytes) |
| Parameters | 3,336,106,240 in bfloat16, about 6.7 GB | 3,389,119,360 in bfloat16, about 6.8 GB |
| GitHub stars | 23,859 | 3,387 |
| Hugging Face downloads | 2,440,096 | 1,105,392 |
| Resolution modes | Five: Tiny, Small, Base, Large, Gundam | One dynamic mode, (0-6) x 768 plus 1 x 1024 |
| Vision tokens per page | 64 to 400 fixed, more in Gundam | 256 to 1,120 |
| Published accuracy claim | 97% decoding precision under 10x compression | None. The paper publishes no accuracy figure |
| OmniDocBench v1.7 position | Not on the current board | 17th of 32, overall 90.25 |
| Last pushed to GitHub | January 27, 2026 | February 3, 2026 |
| Serverless inference providers on Hugging Face | One, Novita, reporting status error | None |
Both are permissive and both let you ship commercially, so nothing here blocks adoption. They are not an identical review, though. Apache-2.0 adds an express patent grant from the contributors, which most corporate counsel treat as a positive, and it adds obligations MIT does not have: preserve the NOTICE file if one is distributed, and state significant changes you make to the files. If your open-source review process has separate checklists per licence family, v1 and v2 go down different paths, and a team that cleared v1 has not automatically cleared v2.
v2, in almost every case. It is the only one of the two with an independent benchmark score on the current board, it is the version DeepSeek's own README points you at, and its dynamic mode gives the model far more of the page. The case for v1 is narrow: you need MIT specifically, or you have already validated v1 against your documents and have no reason to revalidate. Both are research releases with no support policy, so version choice is a decision you own either way.
| Question | Self-hosted DeepSeek OCR | A managed extraction product |
|---|---|---|
| What you pay | About $0.33 per 1,000 pages of GPU time, plus your engineers | A published per-page rate and nothing else |
| Who runs it | You. A GPU box, a queue, a retry policy, an upgrade path | The vendor |
| Vendor rate card | None exists. There is no DeepSeek OCR price list | Published per page |
| Break-even against $1.50 per 1,000 | About 1.34 million pages a month | Cheaper below that, every time |
| Confidence per field | A model output, not a per-field business score | Standard on document products |
| Field extraction | You map markdown and coordinates onto your schema | Named fields returned directly |
| Validation and human review | You build it | Part of a workflow product |
| Data residency | Nothing leaves your network once weights are cached | Depends entirely on the vendor |
| Table reconstruction | 83.89 Table TEDS, its weakest published column | Varies, and most vendors publish nothing at all |
| Maintenance | No pushes since February 2026, no support policy | A contract and a roadmap |
| Cost at 1 million pages a month | About $2,004 of rented A100 time, mostly idle | $1,500 at $1.50 per 1,000 |
| Cost at 5 million pages a month | About $2,004, the same box, now well used | $7,500 at $1.50 per 1,000 |
We sell the right-hand column, so read the cost rows knowing that. If you are pushing several million pages a month, your documents are mostly text, and you have an engineer who wants to own a GPU service, self-hosting DeepSeek-OCR 2 is a sound decision and we are not going to argue you out of it. The compute really is that much cheaper at volume. The case for buying is not price per page. It is that a model hands you markdown and a workflow hands you checked fields, and the distance between those two things is classification, per-field confidence, a review queue for the values that fall below threshold, and an export your accounting system accepts.
One more thing worth saying plainly, because it cuts against us. 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. Self-hosted DeepSeek-OCR is one of them, and on data residency it is unambiguous: the weights run inside your network with no callback to DeepSeek and no account.
The long-form pricing walkthrough, with the arithmetic run across a range of GPU rates rather than a single one, and the break-even against a hosted API at each.
Read itThe open-weight model that currently leads OmniDocBench, priced the same way at about $0.03 per 1,000 pages, with the English recognition trap a US team has to know about.
Read itIBM's CPU-based parser at about $0.21 per 1,000 pages, plus the three separate licences a US product has to clear before shipping it.
Read itThe same arithmetic applied across every open-weight reader worth evaluating, and where the break-even against a managed API actually sits for each.
Read itThe full OmniDocBench board, and the finding that the three biggest cloud document APIs publish no accuracy number and sit on no public leaderboard.
Read itEvery managed vendor normalized to one unit, so the $0.33 on this page has something honest to be compared against.
Read itA compression ratio on a research benchmark cannot tell you how a model handles your vendor's invoice template or a scanned remittance advice. Upload the document you were about to write a DeepSeek-OCR script for and see what finished, validated fields look like. If DeepSeek wins on your documents, run DeepSeek.
