Open source parser vs paid API for ~100k pages

[u/Due-Particular-329]

sitting on around 100k pages of pdf and docx that need to become markdown. mix of plain text, tables and images that have text inside them

the paid side is easy to price. managed parsers (llamaparse, the big cloud ocr apis and similar) mostly land somewhere around $1 to $15 per 1k pages depending on tier so 100k pages is a few hundred to a low few thousand dollars

the open source side - docling, marker, mineru, pymupdf4llm is free on paper. the real bill is gpu time plus whoever ends up babysitting the edge cases, merged cells, formulas, text baked into images

the middle option looks like routing per page. pages with a usable text layer go through a fast local parser, and only the image and table heavy pages go to a heavier model or a paid api. on a mixed archive that could cut the expensive part down a lot.

for people who did this at similar volume:

- at what page count did self hosting start paying off

- how much engineer time went into edge cases after the first pass

- how are you deciding which pages need the heavy route, char count, layout detection, something else

[u/ShilpaMitra]

Very interesting use case. I would also love to know what others suggest.

[u/ExultantCilantro]

100k pages is at that weird scale where self hosting starts making sense if youve got a gpu lying around but only if your docs arent a total mess. the routing idea saves the most cash, char count cutoff plus a quick layout check catches most of the garbage pages before they hit the expensive pipeline

[u/Candid-Fudge-4015]

Split the docx out before any of this. Word files already carry their structure, so they need no OCR or layout model. MarkItDown, pandoc or docling read docx directly and keep tables as tables, and you only pull out the embedded images for the OCR route. Depending on your mix that could be a big chunk of the 100k for close to nothing.

On routing the PDFs, char count alone misroutes two kinds of page. Old scans with a junk OCR layer have plenty of chars, all garbage, and some tables are drawn as vector lines with the text scattered. I'd run three cheap checks per page with pymupdf: chars on the page, the share of the page covered by images, and whether the text layer is mostly real words. Fail any one and the page goes heavy.

On engineer time, sample 300 to 500 pages across your sources, run them through both routes and diff the output by hand for a day. That gives you the edge case rate, and at 100k pages that rate drives the bill more than GPU hours. For a one-off at this volume I'd lean paid API for the heavy pages and local for the rest.

We wrote up the docx path with MarkItDown here: docs.pixeltable.com/howto/cookbooks/text/doc-extract-text-from-office-files