Keep the OCR queue fed, and keep the receipts

Product spotlight | Peterson Compute Trading | November 9, 2026
AI-assisted public-source analysis. No OCR benchmark, deployment or purchase was performed. Dollar figures are US dollars.

Give a builder 100,000 scanned catalogue pages and a search box to fill. The job is ordinary: recover printed text, preserve its page coordinates, and let readers jump back to the original image. Our proposed collection is rights-cleared, non-sensitive and mostly English. It is a hypothetical workload, not a customer result.

The tempting question is which GPU to rent. Start one level earlier: how often will the worker stop, and where will its finished pages live? Runpod Serverless makes those questions unusually concrete. Its queue can keep a worker processing successive requests, but running time includes initialization and waiting. Its completed API results also expire. A successful OCR run needs both a controlled bill and a durable output. Worker lifecycle, result retention

Define a usable page

Use PaddleOCR's PP-OCRv5 server detection and recognition models as the candidate engine. The developer's model cards document the two stages separately: locate text, then recognize text lines. They do not establish accuracy on this catalogue. Keep the source image beside the output so readers can verify part numbers, punctuation and tiny type. Detection model, recognition model

Pin the model files, pipeline options, dependency versions and container digest. The current PaddleOCR tutorial supports explicit model selection and GPU execution; relying on an unspecified default can change the experiment later. For this first pass, target text search rather than faithful reconstruction of tables or illustrations. Pipeline documentation

Prepare a human-checked sample covering faint scans, rotated pages, dense columns and similar-looking characters. Define acceptance before measuring speed: correct searchable identifiers, usable text coverage and a reliable page link. Track failures separately. A page returned by the API is not automatically a page worth indexing.

Read the meter literally

Runpod's endpoint-settings documentation, updated November 4, lists its 24-GB category of L4, A5000 and 3090 GPUs at $0.00019 per second. That is $0.684 per worker-hour with one GPU. This is a documented planning rate, not an account quote or a promise of a particular card. The public pricing-page fetch was unreadable in this check, so verify the console rate before spending. Endpoint settings

The billing guide, updated October 15, says charges run from worker start until full stop, rounded up to a second. Model loading can be billed; ordinary image pulls and cached-model downloads normally occur before the worker starts. A running worker's idle-timeout window is billed too. The console label Idle instead means the worker has scaled down and is unbilled. Those two uses of idle deserve different counters. Billing rules

For the proposed trial, set zero active workers, cap concurrency, and explicitly set timeouts. Console and REST v2 defaults differ, so inspect the resulting configuration rather than assuming a copied example matches the console. GPU categories can contain different hardware, and fallback choices can change the execution profile. Record the actual device on every run. Configuration reference

The same GPU, two different bills

Here is an intentionally hypothetical cost model. Assume 100,000 pages, two seconds of processing per page, twenty seconds of billed startup per worker activation, and a five-second billed tail before shutdown. Processing includes input handling and durable output writes within the worker. None of these timings has been measured.

In a fragmented schedule, suppose each worker activation handles ten pages before the queue empties. Ten thousand activations consume 200,000 processing seconds plus 250,000 startup-and-tail seconds. At the documented rate, the compute bill is $85.50.

In a well-fed schedule, suppose each activation handles 1,000 pages before shutting down. One hundred activations consume the same 200,000 processing seconds plus 2,500 overhead seconds. The compute bill becomes $38.48, a hypothetical reduction of $47.03, or 55%.

This comparison changes the number of worker activations, not model speed. It does not require a thousand-page API request. Keep jobs small and feed them successively: Runpod documents that workers take queued jobs back to back. One-page requests do not imply one cold start per page. Conversely, batching requests cannot guarantee the assumed hundred activations; arrival timing, scaling, failures and available capacity decide what happens. Worker execution sequence

The arithmetic is simply rate multiplied by processing seconds plus activation overhead. Add 2% extra processing for retries to the well-fed case, while holding activations fixed, and compute rises to $39.24. If only 95,000 unique pages meet the quality bar, that is about $0.413 per thousand accepted pages. These are sensitivity inputs, not reliability claims. Storage, external preparation, transfer charges elsewhere, taxes and human review remain outside the model.

The receipt must outlive the request

Runpod's request guide, updated October 19, gives asynchronous /run results a thirty-minute retention window after completion. The job's TTL is a separate clock covering queueing and execution. Neither is an archive. Leaving collection until tomorrow can therefore lose access to completed API results. Request policies and retention

Have each proposed worker write its page result to durable storage before returning success. Derive its key from the input hash, page number, model revision and processing options. Commit atomically, retain the original coordinates, and return a compact reference. A retry checks for a valid existing result. A manifest records accepted, rejected and pending pages, with capped attempts and a quarantine for corrupt inputs. This is a design proposal, not implemented exactly-once execution.

Stage submissions so queue age stays within the configured TTL. Set execution limits around measured page-runtime tails, not the average. Reconcile source pages against durable outputs and the bill. Record worker starts, billed seconds, device identity, failed attempts and accepted unique pages. That makes a faster GPU's eventual contribution measurable without confusing it with a better-fed queue.

PaddleOCR's repository is Apache-2.0 licensed, and both selected model cards declare Apache-2.0. Preserve applicable license and attribution notices, mark distributed modifications, and review additional dependencies. Those licenses do not grant rights to the scanned catalogue. Repository license, model licenses

The first trial should prove that a finished page survives, a retry does not duplicate it, and the billed lifetime matches the ledger. Then optimize dollars per accepted page. The most useful GPU purchase may be the one postponed until those three checks pass.