How we replaced a $5,000/month bill with a $250/month stack without losing accuracy.
We built document processing for a North America-based non-profit on open-weight models. The system runs on two rented CPU servers and keeps every page on-prem. Accuracy matches the cloud API it replaced.
$5,000 → $250. A per-page cloud API replaced by an open-weight stack on rented CPU.What a document intelligence stack costs when you own the model.
What we replaced and what changed.Replace a per-page cloud document API with a document intelligence system that reads forms and scanned documents at the same accuracy, for a fixed monthly cost.
Benchmark eight open-weight models on the client's real documents and score them against the reference cloud API — accuracy, structure and license options. Deploy the winner on rented CPU servers behind a job queue.
Same accuracy tier as the cloud API. Monthly cost fell from roughly $5,000 to $250. The stack reads every document type the client sends it.
Document intelligence is not OCR.
OCR was solved a decade ago: put a clean page in, get text out. Document intelligence is what happens after. Given a messy real document the goal is to produce structured and ordered content that downstream systems can trust.
Three properties make it hard:
Layout and reading order
Cheap OCR flattens all of it into line soup. A two-column report, a nested table, a form spread across two pages all go for a toss. A document intelligence system has to preserve structure and emit content in the order a human would read it. Else the text is incorrect and practically useless.
Forms and filled fields
Half the documents in regulated industries are forms: checkboxes, filled fields, signatures and a few handwritten notes. The system has to record what was asked and what was answered.
Mixed-quality inputs
In the insurance and fintech domain, scans at 150 DPI, photos of paper, redaction bars are all common input. The system has to handle all of them without a separate pipeline per input type.
The mixed document types.
The client is a North America-based non-profit serving families navigating complex benefit programs. The document mix: intake forms, diagnostic-style reports, grant applications, discharge and outcome reports, scanned emails and attachments. Around a hundred thousand pages a month, all of it sensitive.
Data compliance
Client documents could not leave their infrastructure. Cloud APIs were a compliance problem before they were a cost problem.
Budget
The stack had to fit a non-profit budget while absorbing intake bursts.
Eight models on the client's own documents.
We took around two dozen of the client's real documents and ran every candidate through the same harness. The set covered digital PDFs, scanned pages and standalone images.
Each model received identical input and was scored on the same outputs: text accuracy against the embedded PDF layer, structural fidelity on tables and forms, reading order and per-block confidence. The candidates spanned open-weight models from sub-1B to 9B parameters, plus the cloud API as a reference standard.
We expected the cloud API to win on accuracy, while we saw the open-weight models hold up similar accuracy metrics. This is also proven by multiple benchmarks like olmOCR-bench and ExtractBench.
Small open-weight models have caught up.
On the public olmOCR-bench, the best sub-1B open-weight model scores 83.3 out of 100, ahead of models five to fifty times its size. On the client's documents the same pattern held. The small models matched the cloud API on token accuracy and beat it on structure: tables came back as tables, checked boxes came back checked.
Two models sat at the top of our evaluation with statistically identical accuracy and output structure. What separated them was the license — and the license maps to organization size.
The deciding factor moved from model size to model license.
Architecture.
Both model stacks run the same way: a small vision-language model behind a job queue on rented CPU servers. One call per page returns text, tables, form fields, reading order, and bounding boxes. No GPU required at this volume.
Surya 2
Free for non-profits, startups under $5M in funding or revenue, and for research use. Best accuracy per parameter in its class.
This is what we deployed for the client.
LightOnOCR 2 1B
Same accuracy tier under a fully permissive license with no revenue threshold.
The default recommendation for enterprises and for any team that cannot accept OpenRail-M license conditions.
What the stack costs to run.
The deployed stack: two shared CPU servers behind a job queue with object storage and monitoring alongside.
Monthly processing cost 20× lower
Estimated cost of the cloud document intelligence platform, billed per page, against Surya-2 on two rented CPU servers. Bars are drawn to a true $0–$5,000 scale.
At ten times the current volume, the cost advantage grows. The API bill scales linearly with pages while the server bill steps up one server at a time.
On-prem inference has a second effect that does not show up in the numbers. Your data stays inside your infrastructure, which matters under HIPAA and the equivalent regimes in geographies like the EU and UAE.
The queue absorbs the burst.
The sporadic intake spikes would mean a larger API bill. Now they mean a longer queue that drains overnight. The client kept up the accuracy bar and removed the per-page meter.
The same document intelligence pattern applies anywhere documents arrive in volume: claims intake, prior authorization, KYC packets, loan files.
Every document intake problem gets the same solution: call an API.
Most teams wire in a cloud API because it is the fastest path to a working demo. The per-page meter feels cheap at prototype volume. The bill grows in a straight line with volume and the meter never turns into ownership.
Raw extraction APIs have dropped to $4 to $7 per 1,000 pages. Extraction is not document intelligence. No per-field confidence to route a review, no contractual geometry for redaction. The same page can come back different on two runs. Build the missing layer around a raw API and you end up building this stack, while you still rent the model and pay the meter.
Regulated domains make the arrangement harder. When documents cannot leave your infrastructure, the public endpoint is not an option at all. The choices narrow to a premium private deployment of someone else's model, or an enterprise agreement for the privilege of sending your own data out and back.
Most document work does not need an instant answer. A document can sit in a queue for a minute or two and nobody notices. That single fact is what makes a CPU stack viable and it is why the per-page premium buys so little.
None of this is an argument against document intelligence APIs. At low volume they are the right answer, and we deploy them when they are. The skill is knowing your volumes: a startup at thousands of pages a month and an insurer at millions have different optimal stacks, and a document that needs an answer in seconds is different from one that can wait a minute.
Our work is making that call with you, then building whichever option returns more on every dollar.
Which documents are you still paying per page to read?
We help healthcare and insurance teams rebuild document processing on open-weight models. The typical outcome is a 5 to 10× cost reduction with no accuracy trade-off. If you're scoping something similar, let's talk.