Performance Calculator
Use this calculator to size a DocAI Fabric deployment for your document volume. Enter your target throughput, adjust the processing pipeline to match your workflow, and the calculator estimates the capacity you need to provision. Start in Basic mode for the common settings; switch to Advanced to fine-tune per-activity times, token estimates, and infrastructure assumptions (your Basic entries are preserved). When you are done, download the results as a PDF report. The calculator estimates:
- LLM capacity for the model that performs split, classification, and extraction. For a cloud model this is a tokens-per-minute (TPM) quota that maps directly to Azure OpenAI quota; for an on-prem model it is the number of GPUs required.
- OCR throughput in pages per second, when OCR runs as a cloud service.
- DocAI Fabric container replicas and the total vCPU and RAM they require.
- Storage throughput in MB/s and operations per second.
1. Target throughput
How many pages the system must process, and during which working hours. Processing is assumed to be spread evenly across working time.
Effective rate: 500 pages/hour = 0.14 pages/sec, 1.7 documents/min.
2. Document profile
The document type sets how much OCR text a typical page produces.
3. Processing pipeline
Turn activities on or off to match your workflow, then choose the OCR engine and LLM model. The per-activity times and token estimates keep their defaults; switch to Advanced to change them.
OCR: cloud engines (Microsoft Read, Google Vision) run outside the container, so their capacity appears as a separate OCR throughput requirement. Built-in engines run inside the DocAI Fabric containers and consume CPU, so they add to the container count instead. Tesseract suits clean, high-quality scans of printed text; RapidOCR handles real-world documents including handwriting, but is slower per page.
LLM: a private cloud model (for example Azure OpenAI GPT-5.4-mini) is sized as a tokens-per-minute quota. An on-prem model (for example Ollama Gemma 4 E4B) runs on your own GPU servers, so it is sized as a GPU count from the model's prefill and decode throughput. The defaults assume a small quantized model with batching; benchmark your model on the target GPU and adjust. Either way the model runs separately from the DocAI Fabric containers, so it does not change the container count.
4. Required capacity
LLM (split / classify / extract)
Cloud model: Azure OpenAI quota is granted as tokens per minute (TPM) and counts both input and output tokens.
OCR
External requirement: verify against your OCR provider's rate limit. Does not consume container CPU.
DocAI Fabric containers
Sized by worker slots: 2 concurrent workers span 1 replica. CPU-bound work needs only 0.2 cores, so the provisioned vCPU carry headroom.
Storage
Worker time per page across the pipeline: 6.3 s (~31.5 s per document), of which 0.9 s is CPU-bound (conversion, PDF export, and built-in OCR). Replicas are sized to satisfy both the worker-slot and the CPU constraint.
Download your sizing report
Select Download PDF report at the bottom of the calculator to export a document with an executive summary, all inputs, the calculation methodology, and detailed results. It opens your browser's print dialog, where you can choose "Save as PDF" as the destination.
How the calculation works
- Throughput normalization. Your volume is spread evenly over the configured working time to get a sustained rate in pages per second. If your load is bursty (for example, most documents arrive in a 2-hour morning window), enter the volume and time window of the busiest period instead of a yearly average.
- LLM capacity. For each LLM-based activity (split, classify, extract), input tokens per call are modeled as a fixed prompt overhead (instructions and response schema; the defaults approximate the built-in DocAI Fabric prompt templates and grow with the number of document classes and fields you define) plus the document content: text tokens per page, image tokens per page, or both, depending on the activity's Send text / Send image configuration. The document type preset sets the text density per page (a sparse form produces far fewer OCR tokens than a dense contract page). Call granularity matters: classification and extraction make one call per document, while split scans the document with a sliding window, paying the prompt overhead once per window. Window size and step are configurable in the split row; with the defaults (2 pages, step 1) each page is sent roughly twice. Output tokens per page are multiplied by the page rate. The calculator assumes one model serves all LLM activities; if you use different models per activity, run the calculator once per model with only that activity enabled.
- Cloud model (for example Azure OpenAI GPT-5.4-mini). The requirement is the combined input plus output rate, reported both per second and as a tokens-per-minute quota to request from the provider.
- On-prem model (for example Ollama Gemma 4 E4B). The model runs on your own GPU servers. Input tokens are processed during prefill (fast) and output tokens during decode (slower), so the calculator sizes GPUs additively: input rate divided by the per-GPU prefill throughput, plus output rate divided by the per-GPU decode throughput, padded by utilization. The per-GPU throughput defaults are rough ballparks for a small quantized model with continuous batching; benchmark your model on the target GPU (L4, L40S, A100, H100) and override them. Also confirm the model weights fit in the GPU memory. In both cases the model is separate infrastructure from the DocAI Fabric containers and does not change the container count.
- OCR engine: cloud vs built-in. Cloud engines (Microsoft Read, Google Vision) run outside the container. The worker waits for the response, but the OCR work itself happens on the provider's infrastructure, so the requirement shows up as an external pages-per-second throughput target to check against your provider's rate limit. Built-in engines (Tesseract, RapidOCR) run inside the DocAI Fabric container and consume CPU, so they add to the container count instead of producing an external requirement. Tesseract is fast and suits clean, high-quality scans of printed text; RapidOCR handles real-world documents including handwriting but takes longer per page. Switching to a built-in engine typically increases the required number of containers.
- Container sizing. Each workflow worker processes one activity at a time, including the time it spends waiting for LLM or cloud-OCR responses. Replicas are sized against two constraints, and the larger one wins: (a) worker slots, from the page rate multiplied by the total processing seconds per page (every activity occupies a worker while it runs); and (b) CPU cores, from the page rate multiplied by the CPU-bound seconds per page (conversion, PDF export, and built-in OCR actively use a core, whereas LLM and cloud-OCR calls wait on the network). Both are padded by the target utilization to absorb bursts. vCPU and RAM follow from the per-replica configuration.
- Storage. Each activity reads and writes intermediate artifacts (page images, OCR results, extraction results). The per-page MB and operation counts are multiplied by the page rate.
Notes and limitations
- The default per-page times and token counts are conservative estimates for typical business documents (invoices, orders, bills of lading). Actual values depend on page density, field count, and model choice. For an accurate sizing, process a representative sample in a pilot project and read the measured durations and token usage from the Usage tab, then plug those numbers in here.
- The calculator sizes steady-state automatic processing only. It does not include human review time, retries after provider throttling, or headroom for re-running historical batches. For batch re-runs, size for the rate you want the batch to complete at.
- Review, validation, and notification activities consume negligible worker time compared to OCR and LLM activities and are omitted from the default pipeline. You can approximate additional custom activities by increasing the run count or per-page time of an existing row.
- Future versions will extend this to network bandwidth, storage volume, and cost estimation.