marker-pdf OOM on a scanned 500-page contract - how to fix

TL;DR

marker-pdf going out of memory on a scanned 500-page contract is the converter trying to hold the whole document - pages, model state, and results - at once. The fix is chunking: split the PDF into page ranges (50 pages each is a good size), convert each chunk separately, and concatenate the markdown. Reduce worker count if VRAM is the constraint, and skip image extraction if you do not need the figures. Chunking also makes the job resumable: a crash loses one chunk, not the whole run.

The query

marker-pdf OOM on a scanned 500-page contract  -  how to fix

Use this when

• marker-pdf OOMs or gets killed on a very large scanned PDF
• Conversion starts fine and dies partway through a 500-page contract
• The same setup converts small PDFs without trouble

Not for

• marker-pdf failing immediately on launch - that is an install or dependency problem
• OOM on small PDFs - check for a memory leak or an undersized machine instead
• Slow but completing conversions - those need performance tuning, not chunking

Steps

1. Split the PDF into page-range chunks

Use a PDF tool to cut the 500 pages into independent chunks. Fifty pages per chunk keeps each conversion well inside memory limits while keeping the chunk count manageable.

qpdf contract.pdf --pages . 1-50 -- chunk-01.pdf
qpdf contract.pdf --pages . 51-100 -- chunk-02.pdf
# ... repeat to 500

Expected output: ten chunk files, each opening cleanly with its 50 pages.

2. Convert each chunk separately

Run marker on one chunk at a time (or a few in parallel if memory allows). Each run's memory is bounded by the chunk size, not the document size.

for f in chunk-*.pdf; do marker_single "$f" --output_dir "out_${f%.pdf}"; done

Expected output: one markdown output per chunk, no OOM kills.

3. Concatenate the markdown in page order

Join the chunk outputs in order into the final document. Add a page-break marker or chunk header between them so downstream chunking can still find boundaries.

for f in $(ls out_chunk-*/chunk-*.md | sort); do cat "$f"; echo -e "\n\n---\n"; done > contract-full.md

Expected output: a single markdown file with all 500 pages' content in order.

4. Tune memory knobs for the next run

If VRAM is the limit, reduce the worker/batch size in marker's config; if RAM is the limit, keep chunks smaller. Disable image extraction when the contract's figures do not matter - images are a large share of peak memory on scanned documents. Expected output: a configuration that converts a 50-page scanned chunk with headroom to spare.

Tool compatibility

marker-pdf (marker_single CLI); qpdf for splitting. The chunking pattern works with any converter that holds the whole document in memory.

Variant phrasings

• marker-pdf OOM scanned 500 page contract
• marker out of memory large PDF conversion
• marker_single killed large scanned PDF
• marker-pdf chunk pages memory

Why it happens

Document converters like marker load pages, run vision models over them, and accumulate results - all sized with the document. A 500-page scanned contract at print resolution is gigabytes of pixel data plus model activations, which exceeds typical container or GPU memory. Chunking converts a memory problem into a bookkeeping problem: each chunk is independent, bounded, and retryable.

Edge cases / pitfalls

• Tables split across chunk boundaries convert as two partial tables - overlap chunks by a page or note the boundary pages for manual review.
• Page numbers in the concatenated markdown refer to chunk-relative pages unless you offset them; record the offset per chunk.
• Parallel chunk conversion multiplies peak memory by the parallelism - size chunks for the parallelism you plan to use.
• Keep the chunk files until the final markdown is verified; re-running one chunk is cheap, re-splitting is not.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Srgi99K55Nr4g-adUYJsMg