Run LightOnOCR-3 Locally on Windows 11, Mac and Kali Linux: Free OCR Install Guide, PDF to Markdown, and It Beats Paid Mistral OCR

LightOnOCR-3 is a free family of OCR models from the French company LightOn, released on October 8, 2026 under Apache 2.0. Give it a photo or a PDF page and it returns clean Markdown: headings, paragraphs in reading order, tables as HTML, math as LaTeX, and now, for the first time, a box around every block, a description of every picture and the numbers behind every chart. It comes in three sizes, and here is the surprise: the smallest, at 0.9 billion parameters, scores 85.5 on the olmOCR-Bench test, ahead of the paid Mistral OCR 4.1 at 81.9, and ahead of its own bigger "1B" sibling. The 0.8B model installs locally on an ordinary Windows 11, Mac or Kali Linux laptop and runs offline. The 4B model, the most accurate, is second only to a model eight times its size. And there is one rule that quietly ruins results if you break it: the model accepts only two prompts, an empty one or the single word "grounding." Ask it anything else and quality drops.

Jake runs a phone repair shop, and under his counter sits a shoebox he is slightly ashamed of: six years of supplier invoices, warranty cards, handwritten repair tickets and the occasional receipt that has faded to a ghost. His accountant wants totals. His supplier dispute needs one specific invoice from 2023. His friend Ethan, a developer, looked at the shoebox, then at Jake's laptop, and said: "Give me an evening." This page is that evening. It covers what LightOnOCR-3 is in plain English, which of the three sizes to pick, the honest benchmarks against Mistral OCR, PaddleOCR, Chandra and others, how to run it free on Windows, Mac and Kali Linux, how to turn a PDF into Markdown and pull tables out of invoices, the mistakes that make it look bad, and what it costs compared with Amazon Textract on AWS.

New to running AI on your own machine? Our plain-English series on running AI locally explains models, parameters and file formats in about ten minutes. You can follow this page without it; every step starts from zero.

What LightOnOCR-3 is, in plain English

OCR, optical character recognition, means turning a picture of text into actual text you can copy, search and edit. Old OCR tools did it letter by letter and gave you a jumble whenever a page had two columns, a table or a stamp across it. Modern OCR models are small vision-language models: they look at the whole page the way you do, and write out what they see in a sensible order.

LightOnOCR-3 is that kind of model, and it is end-to-end: one model, one step, from page image to finished Markdown. There is no separate layout detector, table extractor or reading-order engine to install and keep in sync. You send a page; you get the page back as text, with tables as HTML and formulas as LaTeX.

The family has two modes:

• Transcription mode: send the image with an empty prompt, and you get the full page as Markdown. This is how earlier LightOnOCR versions worked, so existing setups switch with no changes.
• Grounding mode: send the image with the single word grounding, and every block comes back with a label and a bounding box. Pictures get a short description, and charts become an HTML table of their data points. This mode is new in version 3.
• 
  
  
  
  

Here is what grounding output looks like, straight from LightOn's model card. Coordinates run from 0 to 1000 whatever the image size:

![title](80,70,920,140)
# Company report 2025

![text](80,175,920,225)
Revenue rose 20%.

![image](80,285,460,545)
A solar-powered factory.

![chart](540,285,920,545)
<table>
  <tr><th>Year</th><th>Revenue</th></tr>
  <tr><td>2024</td><td>€10M</td></tr>
  <tr><td>2025</td><td>€12M</td></tr>
</table>

Look at the chart block. The model did not just say "there is a chart here"; it read the bars and wrote down the numbers. For anyone feeding documents into a search tool or a chatbot, that is the difference between "a report mentions revenue" and "revenue was 12 million in 2025."

The labels it uses: title, section, text, list, header, footer, page_number, footnote, caption, formula, code, table, image, chart, header_image, footer_image and aside_text. A label ending in +, such as text+, marks a block that continues the previous one, for example across two columns. Grounding costs about 25% more output: on the 4B model, an average page takes 1,433 output tokens in grounding mode versus 1,158 in plain transcription.

It handles tables, receipts, forms, multi-column layouts and math notation, and LightOn highlights French documents and handwriting as particular strengths. It is made in Europe, by a Paris-based company listed on the stock exchange, which matters to some buyers for data-sovereignty reasons.

LightOnOCR-3 0.8B vs 1B vs 4B: which size to pick

The names are a little misleading, so here is the family in one table. The parameter counts come from the Hugging Face files themselves.

The trap is assuming "1B" sits between 0.8B and 4B in quality. It does not. The 1B keeps the older LightOnOCR-2 architecture so that existing deployments can upgrade without changing code, while the 0.8B and 4B moved to the newer Qwen3.5 vision-language design, which LightOn says brings a significant speed-up and simpler integration. The 1B also trails the other two on charts and visual grounding, which LightOn puts down to that architecture difference. If you are starting fresh, choose between the 0.8B and the 4B, and ignore the 1B.

The simple rule Ethan gave Jake: the 4B when accuracy matters more than anything, such as invoices with numbers you will pay; the 0.8B when you have a lot of pages and an ordinary laptop. On the long-tiny-text category of olmOCR-Bench, think fine print and dense footnotes, the 0.8B actually scores highest of the three, 94.1.

LightOnOCR-3 benchmarks vs Mistral OCR, Chandra, Surya and others

LightOn published results on three benchmarks, with the code to reproduce them in its GitHub repository. All numbers below are LightOn's runs; no independent lab has re-run them yet. Higher is better everywhere.

olmOCR-Bench: general document OCR

Note that LightOnOCR-2-1B's 83.2 excludes headers and footers, so it is not a perfectly like-for-like row. By category, the 4B leads on arXiv papers (91.1), the 1B on multi-column pages (85.9) and the 0.8B on long tiny text (94.1). Infinity Parser Pro, eight times the size of the 4B, stays stronger on old scans and on headers and footers.

ParseBench: tables, charts and formatting

ParseBench is where the new grounding features show. The 4B leads on charts (66.1) and semantic formatting (67.6), and the jump from LightOnOCR-2-1B's 48.0 to the 3-series' mid-70s is the clearest sign of what version 3 added. Infinity Parser Pro still leads on visual grounding itself, 74.9.

fr-bench-pdf2md: French documents and handwriting

On French documents, the 4B scores 74.1 overall, ahead of the 0.8B (70.5), the 1B (69.6), Chandra 2 (69.0), Infinity Parser Pro (63.2), dots.mocr (59.3), Surya OCR 2 and Mistral OCR 4.1 (54.1 each) and jina-ocr-v1 (53.2). Within that test, the 4B scores 46.1 on handwritten pages, 49.6 on forms and 83.6 on multi-column layouts. Handwriting is clearly still the hardest case: under half right on a hard French handwriting set is a leader's score, not a solved problem.

What the numbers mean for you

Three honest takeaways. First, the gap between good open OCR models is now small: several sit within two or three points of each other on olmOCR-Bench. Second, all three LightOnOCR-3 sizes beat the paid Mistral OCR 4.1 on all three benchmarks LightOn ran, which is a remarkable thing to be able to say about a free model you can run at home. Third, LightOn's own blog warns that benchmark scores depend heavily on post-processing, and that a simple rewrite of the output can noticeably change them. Treat a two-point difference as a tie, and test on twenty of your own pages before you decide anything.

How fast is LightOnOCR-3?

LightOn measured speed on one NVIDIA H100 per model, with vLLM 0.30.0. At a page size of 1540 px, the 0.8B peaks at 4.78 pages per second and the 4B at 3.36 pages per second. The 1B has the lowest single-page wait, 2.7 seconds. Against Chandra-OCR-2 at each model's best benchmark setting, the 4B is 19% faster on a single page and serves 21% more pages per second.

Resolution is the big speed lever. LightOn's best benchmark scores use pages rendered at 400 DPI and capped at 5 megapixels, about 4,800 image tokens per page; rendering at 1540 px cuts the image tokens by almost two-thirds. For everyday invoices and letters, the model card's advice of a 2048 px longest edge is the balance point.

On cost, LightOn estimates under one cent per thousand pages on suitable hardware at volume, depending on the machine and workload. On a laptop you pay nothing per page at all, just time: expect seconds per page rather than pages per second, which is fine for a shoebox and slow for a warehouse.

Do you even need an OCR model? The free tools you already have

Before downloading anything, a quick honesty check, because not every "image to text" job needs a model. If you only want the text from one screenshot or one photo now and then, your computer already does it:

• Windows 11: the Snipping Tool's Text Actions copy text straight out of a screenshot, and Microsoft's free PowerToys adds a Text Extractor shortcut (Win+Shift+T) that grabs text from anything on screen. Our guide to screenshots and the Snipping Tool on Windows 11 covers the basics.
• Mac and iPhone: Live Text lets you select text in any photo or screenshot.
• Android: Google Lens copies text from the camera or a photo.

Those are perfect for a phone number on a flyer. They fall apart on a 40-page scanned contract, a supplier invoice with a table, a two-column research paper, a chart you need the numbers from, or a folder of 3,000 pages. That is the job for LightOnOCR-3: whole documents, in order, with structure, in bulk, privately.

LightOnOCR-3 hardware: RAM, GPU and file sizes

All three models are small by today's standards. Here is what each needs:

Each page also needs working memory for its image tokens, up to several thousand per page at full resolution, so leave headroom. On a processor alone, the 0.8B is the comfortable choice; the 4B works but is noticeably slower per page. With an NVIDIA graphics card of 12 GB or more, the 4B in full precision runs well, and vLLM can batch many pages at once. If you are shopping for hardware, our laptop guide for local AI has the tiers.

How to install LightOnOCR-3 locally: four ways (Windows 11, Mac, Linux and Kali)

Way 1: try it in the browser first

LightOn runs a free demo on Hugging Face, "LightOnOCR-3 Demo," described as OCR to Markdown with layout grounding. Upload a page and see the result in a minute, no install. One caution: the page goes to a server you do not control. Use a sample document, never a real contract, payslip or customer record. Everything below runs on your own machine.

Way 2: local install with Python and Transformers (Windows 11, Mac, Linux and Kali)

This is the simplest local route and works everywhere Python does. The 0.8B and 4B need transformers 5.2 or newer; LightOn's card installs 5.5.4 or later. Create a virtual environment first. On Kali and other recent Linux systems, a system-wide pip install is refused with "externally-managed-environment," and our guide to that error explains the fix.

python3 -m venv ~/ocr
source ~/ocr/bin/activate
pip install "transformers>=5.5.4" torch pillow pypdfium2

On Windows the activate line is ocr\Scripts\activate. Keep the quotes around the version: without them, the shell reads > as "write to a file" and installs the wrong version.

Here is a complete script that turns every page of a PDF into a Markdown file. It follows LightOn's settings: render at 400 DPI, shrink to a 2048 px longest edge, thinking switched off, temperature 0.2.

import sys
from pathlib import Path
import pypdfium2 as pdfium
import torch
from transformers import AutoProcessor, Qwen3_5ForConditionalGeneration

MODEL = "lightonai/LightOnOCR-3-0.8B"     # or lightonai/LightOnOCR-3-4B
MODE = "plain"                           # or "grounding"

device = "cuda" if torch.cuda.is_available() else "cpu"
dtype = torch.bfloat16 if device == "cuda" else torch.float32
model = Qwen3_5ForConditionalGeneration.from_pretrained(MODEL, dtype=dtype).to(device)
processor = AutoProcessor.from_pretrained(MODEL)

pdf_path = Path(sys.argv[1])
out = Path("out") / pdf_path.stem
out.mkdir(parents=True, exist_ok=True)

for i, page in enumerate(pdfium.PdfDocument(str(pdf_path)), start=1):
    img = page.render(scale=400 / 72).to_pil()   # 400 DPI
    img.thumbnail((2048, 2048))                  # longest edge 2048 px, aspect kept
    png = out / f"page-{i:03}.png"
    img.save(png)

    content = [{"type": "image", "path": str(png)}]
    if MODE == "grounding":
        content.append({"type": "text", "text": "grounding"})
    inputs = processor.apply_chat_template(
        [{"role": "user", "content": content}],
        add_generation_prompt=True, tokenize=True, return_dict=True,
        return_tensors="pt", enable_thinking=False,
    ).to(model.device)

    ids = model.generate(**inputs, max_new_tokens=4096, do_sample=True, temperature=0.2)
    text = processor.decode(ids[0, inputs["input_ids"].shape[1]:], skip_special_tokens=True)
    (out / f"page-{i:03}.md").write_text(text, encoding="utf-8")
    print(f"page {i} done")

Run it with python ocr_pdf.py invoices.pdf and the Markdown lands in out/invoices/, one file per page, next to the exact image the model saw. Keeping the images is deliberate: when a page comes out wrong, you can look at what the model was given. For a single photo instead of a PDF, skip the rendering lines and point the path at your image.

The 1B model is different: it uses the LightOnOcrForConditionalGeneration and LightOnOcrProcessor classes, its page size is 1540 px, and on Apple Silicon its card recommends float32. Since the 0.8B scores higher anyway, most people never need it.

Way 3: vLLM and LightOn's command-line tool (fastest, NVIDIA on Linux)

For many pages, LightOn's own GitHub tool is the most convenient: a lightonocr command that takes whole PDFs, a Python client and a browser viewer that shows each page with its blocks drawn on top. It talks to a vLLM server, which needs Linux with an NVIDIA GPU; on Windows, run it inside WSL2.

git clone https://github.com/lightonai/LightOnOCR
cd LightOnOCR
uv sync --extra vllm && source .venv/bin/activate

vllm serve lightonai/LightOnOCR-3-4B \
    --limit-mm-per-prompt '{"image": 1}' --max-model-len 18000 \
    --default-chat-template-kwargs '{"enable_thinking": false}' \
    --mm-processor-cache-gb 0 --no-enable-prefix-caching --port 8010

Then, in a second terminal inside the same folder:

lightonocr paper.pdf                              # plain Markdown -> out/paper/
lightonocr paper.pdf --mode grounding             # with boxes and labels
lightonocr scan.png --print                       # a single image, printed
lightonocr paper.pdf --pages 1,3-5 --name intro   # selected pages
lightonocr viewer                                 # browse results at http://127.0.0.1:8000

Each run creates a folder with page-NNN.png, page-NNN.md and, in grounding mode, page-NNN.json with the parsed blocks. The client keeps 64 pages in flight, which is how vLLM reaches those pages-per-second numbers. It also repairs escaped math delimiters in the output while leaving prices alone, a small touch that matters on invoices.

Version pinning matters here, and LightOn is unusually frank about it. The vllm extra pins vLLM 0.30.0 with transformers 5.16.1. Transformers 5.17 breaks the 1B models on vLLM 0.30.0, and vLLM 0.27.1 makes every model loop, repeating the same lines forever. If you install vLLM yourself instead of through the repository, match those versions.

Way 4: llama.cpp with community GGUF files (CPU-friendly)

LightOn has not published GGUF files, but community builds of all three models appeared within hours, for example prithivMLmods/LightOnOCR-3-4B-GGUF and prithivMLmods/LightOnOCR-3-0.8B-GGUF, each with a separate mmproj file for the vision part. They run in llama.cpp on an ordinary processor. Because these are third-party conversions, LightOn's benchmark numbers do not automatically apply to them; for OCR, where one wrong digit matters, use the Q8_0 files rather than smaller ones.

hf download prithivMLmods/LightOnOCR-3-0.8B-GGUF \
    LightOnOCR-3-0.8B.Q8_0.gguf LightOnOCR-3-0.8B.mmproj-q8_0.gguf --local-dir .

llama-server -m LightOnOCR-3-0.8B.Q8_0.gguf \
    --mmproj LightOnOCR-3-0.8B.mmproj-q8_0.gguf \
    --chat-template-kwargs '{"enable_thinking": false}' --port 8010

Send pages to its OpenAI-compatible chat endpoint with the image and no text for plain mode, exactly as LightOn's own client does, with a temperature of 0.1:

import base64, requests

b64 = base64.b64encode(open("page-001.png", "rb").read()).decode()
r = requests.post("http://127.0.0.1:8010/v1/chat/completions", json={
    "messages": [{"role": "user", "content": [
        {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{b64}"}},
        # {"type": "text", "text": "grounding"},   # add this line for grounding mode
    ]}],
    "temperature": 0.1,
    "max_tokens": 4096,
})
print(r.json()["choices"][0]["message"]["content"])

Ollama and LM Studio do not list LightOnOCR-3 in their catalogs, and both are built around chat, so llama-server is the cleaner fit for an OCR job. If you are still deciding between local AI runners in general, our comparison of Ollama, LM Studio and llama.cpp explains the trade-offs.

Using the layout blocks from Python

Grounding mode becomes most useful through LightOn's Python client, which parses the blocks for you. Once the vLLM server from Way 3 is running, this pulls out every block with its label and box, then rebuilds the page as Markdown without the headers, footers and page numbers that clutter search results:

from lightonocr import LightOnOCR, load_pages, to_markdown, HEADER_FOOTER

ocr = LightOnOCR()                                   # talks to http://127.0.0.1:8010/v1
pages = load_pages("paper.pdf", ocr.profile.longest_edge)
print(ocr.plain(pages[0]))                           # plain Markdown

blocks = ocr.grounding(pages[0])                     # LightOnOCR-3 only
for b in blocks:
    print(b.label, b.bbox, b.text[:60])
print(to_markdown(blocks, drop=HEADER_FOOTER))       # clean text for search or a chatbot

The boxes are useful beyond text. Because each image block has coordinates, you can crop the figures out of a scanned report and save them as separate files, or highlight exactly where on a page a number came from when someone asks "where did this figure come from?"

A real example: Jake's shoebox of invoices

Here is how Ethan turned the shoebox into something an accountant could use, in one evening, with nothing leaving the shop.

1. Scan everything to PDF. Jake's printer has a document feeder, so the shoebox became twelve PDFs, one per year and type, in about an hour. A phone scanning app works too; aim for flat, even light and the whole page in frame.
2. Run plain mode on everything with the 0.8B. The script above, left running, produced one Markdown file per page. This made every document searchable with an ordinary file search the same night.
3. Run grounding mode with the 4B on the invoices only. Invoices are where the numbers matter, so they got the most accurate model and the block labels, which made the tables easy to find.
4. Pull the tables into a spreadsheet. Each table block is HTML, and Python's pandas library reads HTML tables directly, so a few lines turned every invoice table into rows of a CSV file.
5. Check the totals. Ethan added a simple check: the sum of line items should equal the invoice total. Every invoice that failed the check went into a "look at me" folder for Jake.

The table step looks like this:

from io import StringIO
from pathlib import Path
import pandas as pd

rows = []
for md in sorted(Path("out").rglob("page-*.md")):
    text = md.read_text(encoding="utf-8")
    if "<table" not in text:
        continue
    for table in pd.read_html(StringIO(text)):   # needs: pip install pandas lxml
        table["source"] = str(md)
        rows.append(table)

pd.concat(rows, ignore_index=True).to_csv("all_invoice_tables.csv", index=False)

Of the first year's invoices, the check flagged a handful: a faded thermal receipt, one invoice with a coffee ring across the total, and one where the supplier's own arithmetic was wrong, which Jake found more satisfying than anything else that evening. The handwritten repair tickets were the weakest results, as the benchmarks predicted; clean block capitals came out well, and hurried cursive less so. For those, Jake kept the scans and used the Markdown only for searching.

Once the shoebox is Markdown, the next step is finding things in it by meaning rather than exact words. Our guide to EmbeddingGemma 2 shows how to build a private search box over documents like these, also fully offline.

Scanning tips that matter more than the model

The best model cannot read what the scan lost. Ethan's checklist for Jake's shoebox, in the order it matters:

1. Scan at 300 to 400 DPI. Lower resolutions lose small print and decimal points; higher ones only make bigger files.
2. Use even light and no shadows. A phone held over a page casts a shadow across exactly the line you need. Light from two sides, or use a document feeder.
3. Keep pages flat and straight. Curled receipts and book spines bend lines. Press them flat under glass, or use a scanning app that straightens the page.
4. Scan thermal receipts first. They fade with heat and time. The oldest ones in Jake's box were already ghosts; scan any you care about this week.
5. Use color for documents with stamps, highlights or colored tables. Black-and-white scanning can merge a red stamp into the text underneath it.
6. Keep the originals until the totals check out. OCR plus a total check catches most errors; the paper settles the rest.

"OCR a PDF" usually means two different jobs

When people search "OCR PDF," they want one of two things, and LightOnOCR-3 does only one of them. It extracts the content into Markdown you can search, edit, analyze or feed to a chatbot. It does not produce a "searchable PDF," the kind that looks identical to the scan but lets you select and search text inside a PDF reader. That needs an invisible text layer added to the PDF itself, which is a job for a tool such as OCRmyPDF, built on the Tesseract engine. Plenty of offices use both: OCRmyPDF so staff can search inside the PDF in their reader, and an OCR model like LightOnOCR-3 when the content needs to go somewhere else, such as a spreadsheet, a database or an AI assistant.

Why LightOnOCR-3 output looks wrong: the common mistakes

OCR models rarely crash. They return text that looks fine at a glance and is subtly wrong, so these mistakes are easy to miss. Here they are, most common first.

Writing your own instructions

This is the big one. LightOnOCR-3 was trained on exactly two prompts: nothing at all, or the word grounding. LightOn's card says plainly that other instructions are "out of distribution." "Extract the invoice total as JSON" or "only give me the table" does not make it smarter; it makes it worse. Run it in one of the two modes, then do any extraction in your own code, as in Jake's table example.

Thinking left switched on

The 0.8B and 4B are built on Qwen3.5, whose chat template can turn on a "thinking" mode. LightOnOCR-3 was trained and evaluated with thinking off. Pass enable_thinking=False in Transformers, --default-chat-template-kwargs '{"enable_thinking": false}' in vLLM, or --chat-template-kwargs '{"enable_thinking": false}' in llama-server.

Greedy decoding

It sounds sensible to set the temperature to zero for OCR, so the model always picks the most likely word. LightOn's tip is the opposite: use a temperature of 0.1, not greedy decoding. Its card examples use 0.2 with top-p 0.9. Small amounts of randomness help models like this avoid getting stuck repeating a line.

Pages that are too small or too big

Render PDFs at 400 DPI, then shrink so the longest edge is 2048 px for the 0.8B and 4B, or 1540 px for the 1B, keeping the aspect ratio. A low-resolution scan loses small print; a huge image wastes thousands of tokens per page and can push the request past the model's limit. Photos from a phone usually need shrinking, not enlarging.

A max-tokens limit that cuts pages short

An average page is over a thousand output tokens, and grounding adds about a quarter more. A dense page of small print can need much more. If the end of a page is missing, raise the limit; LightOn's examples use 4,096.

More than one page per request

A request is one page image and nothing else. LightOn's server settings even limit each prompt to one image. To go faster, send many single-page requests at once and let vLLM batch them, which is what the lightonocr tool does with 64 pages in flight.

The wrong vLLM or transformers version

vLLM 0.27.1 makes every model loop, and transformers 5.17 breaks the 1B on vLLM 0.30.0. Use the repository's pinned versions: vLLM 0.30.0 with transformers 5.16.1. On the Transformers-only route, the 0.8B and 4B need at least version 5.2.

Expecting grounding from older versions

Only LightOnOCR-3 understands grounding. LightOnOCR-1 and LightOnOCR-2 do plain OCR only, and LightOn's Python client raises an error if you ask them for blocks.

Dollar signs turning into math

OCR models write formulas as LaTeX, which uses dollar signs, so a price line can come back with escaped dollars. LightOn's client repairs escaped math delimiters and leaves prices alone; if you use the raw endpoint, check money columns and fix them in post-processing.

Uploading private documents to the demo

The online demo is for trying the model. For anything with names, addresses, account numbers or health details, run it locally, which is the whole point of an open model.

Choosing the 1B because it sounds bigger

The 1B uses the older design and scores below the 0.8B overall. Pick it only to upgrade an existing LightOnOCR-2 setup with no code changes.

LightOnOCR-3 vs PaddleOCR, Tesseract, Mistral OCR and Amazon Textract

"LightOnOCR vs" searches compare very different kinds of tools, so here they are side by side in plain terms:

Tesseract still has a place, and it is a small one: it reads characters, not documents, so tables, columns and charts are where an end-to-end model pulls far ahead. The hosted APIs earn their price when you need no infrastructure at all, or features beyond OCR. For everything else, a free model that scores higher than a paid API on the same benchmarks is hard to argue with.

LightOnOCR on AWS, and what Amazon Textract costs instead

There are two AWS stories here, and they are easy to mix up. New to these services? Our Bedrock vs SageMaker AI explainer sorts them out first.

• LightOnOCR-2-1B is in Amazon SageMaker JumpStart since August 10, 2026, deployable from the SageMaker console or the SageMaker Python SDK. That is the previous version, with plain OCR only.
• LightOnOCR-3 is not in JumpStart yet. To use it on AWS now, self-host it with vLLM on a GPU instance. The 4B in full precision needs about 9 GB for weights plus room for pages, so a single 24 GB GPU, such as the NVIDIA L4 in Amazon EC2 G6 instances, has space to batch. Keep the endpoint private inside your VPC.

The alternative is Amazon Textract, AWS's managed service. These are its on-demand prices in US East (N. Virginia), from AWS's official price list published September 11, 2026:

Read that against what LightOnOCR-3 gives you for free: layout, tables and chart data in every grounding-mode page. On Textract, plain text is cheap, $150 for 100,000 pages, but structure costs extra, and a layout-plus-tables pipeline runs to hundreds or thousands of dollars at that volume. Self-hosting LightOnOCR-3 costs the GPU hours you rent instead, which at LightOn's measured speeds is a small number of hours per hundred thousand pages on a data-center GPU.

Textract still wins in three situations: when you need its specialist features such as Queries, identity documents or lending packages; when your team has no one to run a GPU server; and when your compliance setup already approves Textract and nothing else. For a small business like Jake's, the shoebox costs nothing on a laptop. Our explainer on Hugging Face models on AWS covers self-hosting patterns and their costs in more depth.

LightOnOCR-3: frequently asked questions

By midnight, the shoebox was a folder of Markdown files and one spreadsheet of invoice lines, with a short "look at me" pile on top. The accountant got the totals she wanted, the 2023 dispute had its invoice, and the supplier had its own arithmetic mistake pointed out, politely. Jake put the shoebox back under the counter, but this time it was a backup, not the only copy. A year ago this job meant a paid service and uploading every document. Tonight it took a free model, a laptop and an evening.

Revision note. Written October 9, 2026, the day after LightOn released LightOnOCR-3. If there is a shoebox under your counter too, one quiet evening is all it takes to make it searchable.