Sizing a GPU for document processing: memory class, card count and cost at 25,000, 100,000 and 500,000 pages a month
TL;DR
One A100-class GPU running a compact document VLM at about 20 pages a minute clears roughly 1,200 pages an hour. A hundred thousand pages a month is about 83 GPU-hours of work — one card, busy four hours a day.
Memory decides the class of card; volume and the processing window decide how many. A 24 GB card is enough for the extraction layer, 48 GB adds a ~30B general model, and 80 GB or multi-GPU is for whole-file questions over long agreements.
GPUs = (monthly pages ÷ window hours) ÷ pages per hour per GPU × headroom, rounded up. Use 1.5× headroom for retries and month-end peaks until you have measured your own rate.
Up to roughly 100,000 pages a month, EU on-demand rental at about €1.80 an hour is the cheapest local compute. An owned box overtakes it past about 130,000 pages, and a reserved €600 card only past about 270,000.
The cheapest capacity is often a longer processing window, not more hardware: 500,000 pages a month needs four cards inside office hours and one card running continuously.
Questions people ask
What GPU do I need for document processing with a local model?
The largest model in your stack sets the memory class. A 24 GB card (RTX 4090, L4, A10) runs compact document VLMs from sub-1B to about 8B with room to batch, which covers invoices, receipts, forms and claims. A 48 GB card (L40S, RTX 6000 Ada, A6000) adds a ~30B general model at 8-bit for hard pages. An 80 GB card (A100, H100) is for ~30B at 16-bit or a quantized long-context model.
How many pages per hour can one GPU process?
About 1,200 pages an hour on an A100-class card running a compact document VLM with a header-and-totals schema at moderate resolution. Four things move that figure: image resolution, output length, batching and model size. Full line-item schemas, handwriting, 300-dpi inputs or a ~30B model land lower; a leaner schema and downscaled images land higher. Measure on 200 real pages before ordering hardware.
How many GPUs do I need for 100,000 pages a month?
One. At 1,200 pages an hour that is 83 raw GPU-hours, or 125 with 1.5× headroom for retries and peaks — about 71% utilization of a single card in an 8-hour window across 22 working days, with room for a bad month. At 25,000 pages a card sits at 18% utilization and belongs on rental. At 500,000 pages you need four cards inside office hours or one card running continuously.
Is it cheaper to buy a GPU or rent one for document processing?
It depends on utilization. At the article’s assumptions, EU on-demand rental at €1.80 an hour is cheapest up to roughly 100,000 pages a month — about €225 for that volume. An owned RTX 4090-class box, amortized over 36 months with power and a slice of ops, overtakes rental past about 130,000 pages. A reserved €600 card only wins past about 270,000 pages; below that you are paying for predictability and guaranteed capacity.
How much VRAM does a 30B model need?
Weights in 16-bit precision take about two bytes per parameter, so a 30B model needs roughly 60 GB before the KV cache, activations and the batch — an 80 GB card with headroom. Eight-bit quantization halves that, which fits the 48 GB class; four-bit roughly quarters it and squeezes onto 24 GB with small batches. Quantization costs accuracy that you must measure on your own pages rather than assume.
What else does a document processing server need besides the GPU?
Four things starve a well-sized GPU. Plan four to eight CPU cores per GPU for PDF rasterization, deskew and resizing, in a separate worker pool. Keep system RAM at least equal to total GPU memory. Put weights on NVMe — a 30B model at 16-bit is about 60 GB on disk — and do not keep page images past delivery. Add a queue in front of the GPU and a rental fallback if the SLA is same-day.
Want this worked out on your documents?
We will price a real sample against OpenAI or Anthropic and tell you whether Local document models or a local model on your hardware is the cheaper first step.
One A100-class GPU running a compact document VLM at about 20 pages a minute clears roughly 1,200 pages an hour. That single figure sizes most European document pipelines. A hundred thousand pages a month is about 83 GPU-hours of work — one card, busy four hours a day, with headroom left for retries. You do not need a second GPU until volume passes several hundred thousand pages a month inside a business-hours window, and you do not need an 80 GB card until you add a ~30B model or a long-context model to the stack. Memory decides the class of card; volume and the processing window decide how many you buy or rent.
This article gives you the arithmetic, a memory table by card class, a worked sizing for 25,000, 100,000 and 500,000 pages a month, and a buy-versus-rent comparison in euros. All figures are planning numbers derived from stated assumptions. Measure yours on 200 pages before ordering hardware.
The throughput arithmetic
Sizing a GPU for OCR and LLM workloads is a throughput problem, not a FLOPS problem. The unit that matters is pages per minute per GPU, and four things move it.
Image resolution
A vision-language model turns the page into vision tokens before it reads anything, and tokens scale with pixels. A 300-dpi A4 scan fed in at full size can cost several times the tokens of the same page downscaled to a longest edge of around 1,000–1,500 pixels. For printed invoices the lower resolution loses nothing that matters; for small-print footnotes or handwriting it can. Fix the resolution per document family and measure throughput at that setting — not at whatever the scanner produced.
Output length
Generation is sequential: every output token is a separate step. A schema that returns twelve header fields is fast. A schema that returns every line of a 60-line invoice with descriptions is several times slower on the same card, because the model writes several times more tokens. Ask for what you will use. If you need full line items, budget for them in pages per minute.
Batching
A GPU processing one page at a time sits mostly idle, waiting on memory. Serving stacks with continuous batching — vLLM and its peers — keep dozens of pages in flight, and that is where most of the “20 pages a minute” comes from. Batching needs memory headroom, which is one reason a 24 GB card running a sub-1B model often outperforms the same card squeezing an 8B model in at the edge of its memory.
Model size
Roughly, throughput falls in proportion to parameter count at the same batch size, and then falls faster once memory limits force smaller batches. The compact document parsers profiled in our local OCR model comparison exist to keep this number high. A ~30B general VLM is a different throughput class and should be reserved for the pages that need it.
Put together: pages per hour per GPU is 60 × pages per minute at your resolution, your schema, your batch size, on your card. The 1,200 figure is a compact VLM on an A100-class card with a header-plus-totals schema at moderate resolution. Handwriting, full line items or a larger model will land lower; a leaner schema and downscaled images can land higher.
VRAM classes and what fits
Memory is the hard constraint. Weights in 16-bit precision take about two bytes per parameter, so parameter count sets a floor: roughly 2 GB for a 1B model, 16 GB for 8B, 60 GB for 30B — before the KV cache, activations and the batch. Eight-bit quantization halves that; four-bit roughly quarters it, at a cost in accuracy that you must measure on your pages rather than assume. Three card classes cover almost every document deployment:
GPU memory classes for document workloads. Fit estimates use about 2 bytes per parameter at 16-bit precision with headroom for KV cache and batching; quantized fits depend on the serving stack. Card names are examples of the class, not recommendations.
Class
Example cards
Fits comfortably
Fits with quantization
Typical role
24 GB
RTX 4090, L4, A10
Compact document VLMs (sub-1B to ~8B) with room to batch
~14B at 8-bit; ~30B at 4-bit with small batches
Single-family extraction, pilots, per-page parsing at volume
48 GB
L40S, RTX 6000 Ada, A6000
~8B–14B with large batches and higher resolution
~30B at 8-bit; ~70B dense at 4-bit
Mixed families, handwriting, a general VLM alongside a parser
80 GB
A100 80 GB, H100
~30B at 16-bit with headroom
Llama 4 Scout-class long-context MoE at 4-bit; ~70B at 8-bit
Data rooms at scale; rarely needed for extraction alone
GPU memory classes for document workloads. Fit estimates use about 2 bytes per parameter at 16-bit precision with headroom for KV cache and batching; quantized fits depend on the serving stack. Card names are examples of the class, not recommendations.
The practical reading for a European operations team: a 24 GB card is enough for the extraction layer — invoices, receipts, forms, claims — with a compact VLM. You move to 48 GB when you want a ~30B general model in the same box for the hard pages, and to 80 GB or multi-GPU when the requirement is “ask a question of this 400-page agreement”. Long-context models such as Llama 4 Scout have modest active parameters but large total weights, and the context itself consumes memory; plan on 80 GB with quantization, or two or more cards — and check the license for EU use before you plan at all.
The sizing formula
Three inputs, one answer:
Monthly pages per document family, at a steady level — not the migration backlog.
Processing window in hours per month: the hours during which pages must be processed. An 8-hour window across 22 working days is 176 hours; a continuously fed queue is 720.
Pages per hour per GPU, measured at your resolution and schema.
Then: GPUs = (monthly pages ÷ window hours) ÷ pages per hour per GPU × headroom, rounded up. Headroom covers retries, second passes on low-confidence pages, and the peak week. Retries alone run 1.3–2.0× on the sticker for teams that have not measured their own rate; we use 1.5× below. Month-end peaks in accounts payable can double a normal day, and a longer window absorbs that better than extra cards.
Illustrative scenario, assumptions stated here: compact document VLM at 1,200 pages per hour per A100-class GPU; 1.5× headroom for retries and peaks; 8-hour window across 22 working days = 176 hours; continuous = 720 hours. Measure your own pages per hour before applying.
Monthly pages
Raw GPU-hours
GPU-hours with 1.5× headroom
GPUs, 176-hour window
GPUs, continuous
One card’s utilization, 176-hour window
25,000
21
31
1
1
≈ 18%
100,000
83
125
1
1
≈ 71%
500,000
417
625
4
1
Exceeds one card
Illustrative scenario, assumptions stated here: compact document VLM at 1,200 pages per hour per A100-class GPU; 1.5× headroom for retries and peaks; 8-hour window across 22 working days = 176 hours; continuous = 720 hours. Measure your own pages per hour before applying.
Read the table this way. At 25,000 pages a month a dedicated GPU is idle four days in five; that volume belongs on on-demand rental or a shared box, and on hybrid economics the exceptions may be cheaper on an API. At 100,000 pages one card is well used inside an eight-hour window and has room for a bad month. At 500,000 pages the window is the decision: four cards if everything must finish inside office hours, one card if a queue can run around the clock. The cheapest capacity is often a longer window, not more hardware.
Buy, rent, or EU cloud
Three ways to pay for the same GPU-hours, priced for the three volumes above. EU on-demand rental for an A100-class card runs €1.50–€2.20 an hour at the time of writing; we use €1.80. A reserved line — a rented A100-class card for the month, or a small owned box including power and a slice of ops — is about €600 a month. An owned consumer-class box is the cheapest per hour and the most expensive to neglect.
Illustrative scenario, assumptions stated here: GPU-hours from the sizing table (1.5× headroom). On-demand at €1.80 per GPU-hour. Reserved at ≈ €600 per A100-class card per month. Owned box: €4,500 RTX 4090-class workstation over 36 months (€125/month) + electricity at €0.25/kWh and 0.6 kW under load + €150/month for a slice of ops; assumes the same pages per hour as the A100 case, which a consumer card may not reach — verify. Excludes the engineering to build the pipeline.
Option
25,000 pages/month
100,000 pages/month
500,000 pages/month
Trade-off
EU on-demand rental (€1.80/h)
≈ €56
≈ €225
≈ €1,125
No idle cost; peak capacity not guaranteed; you choose the EU region
Reserved EU GPU (≈ €600/card/month)
€600
€600
€600 (1 card, continuous) or €2,400 (4 cards, 176-hour window)
Predictable; capacity is yours; idle at low volume
Cheapest at high utilization; you own failures, updates and failover
Illustrative scenario, assumptions stated here: GPU-hours from the sizing table (1.5× headroom). On-demand at €1.80 per GPU-hour. Reserved at ≈ €600 per A100-class card per month. Owned box: €4,500 RTX 4090-class workstation over 36 months (€125/month) + electricity at €0.25/kWh and 0.6 kW under load + €150/month for a slice of ops; assumes the same pages per hour as the A100 case, which a consumer card may not reach — verify. Excludes the engineering to build the pipeline.
Three conclusions fall out of the table, and a fourth sits above it. Up to roughly 100,000 pages a month, on-demand rental is the cheapest way to buy local compute, provided you can live with capacity not being guaranteed on the busiest day. An owned box overtakes on-demand somewhere past 130,000 pages a month at these assumptions, and a reserved card only past about 270,000 — below that, what you are paying €600 for is predictability and guaranteed capacity, not a lower bill. For scale: 100,000 routine invoice pages on GPT-4.1 at list prices at the time of writing is about €700 a month and on Claude Sonnet 5 about €1,160, before retries, against €225–€600 for any local option — the arithmetic in 100,000 invoice pages: fixed cost vs per-token. Below about 50,000 pages the honest question is whether an API is cheaper still, and the hybrid stack exists for exactly that band. The fourth conclusion is residency: all three local options keep pages in the EU, and the rental region is a checkbox you control — the European buyer’s guide covers what to ask a provider about it.
CPU, RAM, storage and the rest of the box
The GPU is the expensive part, not the only part. Four things starve a well-sized GPU:
CPU. PDF rasterization, deskew, cropping and resizing run on CPU before the GPU sees a page. At 20 pages a minute that is light; with four cards in parallel it is not. Plan four to eight cores per GPU and keep preprocessing in a separate worker pool so one slow PDF never blocks the model.
System RAM. Weights load through host memory, and batches of decoded page images sit there. A working rule is system RAM at least equal to total GPU memory, and comfortably more if the same box runs the queue and the database.
Storage. A 30B model at 16-bit is about 60 GB on disk, and weights belong on NVMe. Page images are the larger item: a 300-dpi A4 scan as JPEG runs a few megabytes, so 100,000 pages a month is on the order of a few hundred gigabytes if you keep the images. Most teams should not keep them past delivery — retention limits are a GDPR obligation, not just a disk saving.
Queue and failover. Pages arrive in bursts; a queue in front of the GPU turns a month-end spike into a longer run rather than a failure. A same-day SLA also wants a second box or a rental fallback for the day the card dies.
None of this is exotic. It is the same operational discipline as any on-premise document AI deployment: the model is one process; the queue, the preprocessing and the delivery are the system.
A sizing procedure
Count pages per month per family, and note the peak week. Use six months of steady state, not the backlog you plan to clear once.
Fix the processing window. Overnight batch, same-day, or continuous. This decision moves the GPU count more than any other.
Pick the model class per family — compact parser, general VLM, long-context — using the shortlist by document family. The largest model in the stack sets the memory class.
Measure pages per hour on 200 real pages at the resolution and schema you will use in production, with batching on, on the card class you intend to buy or rent.
Compute GPU-hours with headroom: monthly pages ÷ measured pages per hour × your retry-and-peak factor (1.5× if unmeasured).
Divide by window hours and round up to get the card count. If the count is more than one, revisit step 2 before buying.
Price all three ways — on-demand, reserved, owned — at your GPU-hours, and put the API sticker for the same pages next to them.
Add the rest of the box (CPU, RAM, NVMe, queue) and a failover plan if the SLA is same-day.
What to measure before you order anything
Two measurements settle the sizing: pages per hour on your own pages at your production resolution and schema, and your real retry rate. Everything else in this article is arithmetic on those two. If your measured pages per hour comes in at half our figure, double the GPU-hours and re-run the tables — the conclusions about card class do not change, only the count and the window.
If you want the measurement done for you, that is the first week of a local document models deployment: we run your sample on the card class you are considering and hand back throughput, straight-through rate and the sizing. If the question is broader — which of your workflows should be on local hardware at all — that is local AI consulting, and this article is its chapter on hardware.