easyocr CUDA out of memory on a batch of scanned exhibits - how to fix

TL;DR

easyocr's CUDA out-of-memory on a batch of scanned exhibits is the GPU trying to hold too many high-resolution pages at once: easyocr batches input images on the device, and a batch of print-resolution exhibits overflows VRAM. Process pages one at a time (batch_size=1), clear the CUDA cache between pages, and keep the model on GPU - you lose batching throughput but the job completes. If single pages still OOM, downscale the input images or move the overflow pages to CPU.

The query

easyocr CUDA out of memory on a batch of scanned exhibits  -  how to fix

Use this when

• easyocr raises CUDA out of memory on a batch of scanned exhibits
• The first pages process fine and later ones die
• Single pages work but the full batch does not

Not for

• OOM on CPU-only runs - that is system RAM, a different resource with different fixes
• CUDA errors on the very first page - check the install and GPU visibility first
• Slow GPU OCR without OOM - a performance question, not a memory failure

Steps

1. Drop to batch_size=1 and rerun

The immediate fix: feed easyocr one page per call instead of a list. Batching is a throughput optimization; correctness does not need it.

import easyocr
reader = easyocr.Reader(["en"], gpu=True)
for img in page_images:
    result = reader.readtext(img, batch_size=1)
    save(result)

Expected output: pages process sequentially with no CUDA OOM.

2. Clear the CUDA cache between pages

PyTorch holds freed GPU memory in its cache, so peak usage creeps up across pages even at batch_size=1. Emptying the cache between pages keeps the high-water mark at one page's worth.

import torch
for img in page_images:
    result = reader.readtext(img, batch_size=1)
    save(result)
    torch.cuda.empty_cache()

Expected output: stable GPU memory across hundreds of pages instead of a slow climb to OOM.

3. Downscale oversized exhibit images

Scanned exhibits at 600 DPI are far larger than the recognizer needs. Downscaling to 300 DPI (or capping the long edge) cuts VRAM per page dramatically with negligible accuracy loss on printed text.

from PIL import Image
img = Image.open("exhibit.png")
img.thumbnail((2480, 3508))  # cap at ~300 DPI A4

Expected output: per-page VRAM drops several-fold; the whole batch fits the original loop.

4. Fall back to CPU for the overflow, not the whole job

If a few pages are enormous (foldouts, engineering drawings), process just those with gpu=False in a separate reader. The bulk of the exhibits keeps GPU speed.

cpu_reader = easyocr.Reader(["en"], gpu=False)
result = cpu_reader.readtext(huge_img, batch_size=1)

Expected output: the oversized pages complete slowly on CPU while the rest stay fast on GPU.

Tool compatibility

easyocr with PyTorch CUDA backend; Pillow for downscaling. The batching and cache behavior is PyTorch's, so the pattern applies to any GPU OCR pipeline.

Variant phrasings

• easyocr CUDA out of memory batch scanned exhibits
• easyocr readtext CUDA OOM batch_size
• easyocr GPU memory leak pages torch.cuda.empty_cache
• easyocr gpu=False fallback large images

Why it happens

easyocr stacks the input images into one GPU batch tensor, so VRAM scales with batch size times image resolution. Print-resolution scans are huge tensors, and PyTorch's caching allocator additionally retains freed blocks, so memory grows across batches even when each batch is freed. The OOM is therefore a function of batching policy and image size - both fully in your control - not of the model itself.

Edge cases / pitfalls

• empty_cache() has a small synchronization cost; call it between pages, not between batches of a healthy run.
• Multi-GPU machines can shard pages across devices, but fix the per-page memory first - sharding a leak just leaks in parallel.
• Half-precision inference cuts VRAM further if your easyocr/PyTorch build supports it; verify accuracy on a sample first.
• Monitor nvidia-smi during a run once; the steady-state number tells you the real per-page cost for capacity planning.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eaoIlskHhBRy73mqq4uViQ