This estimator converts a fraud-detection inference workload into an approximate GPU count. It uses peak transaction volume, measured transactions per second per GPU, target utilization, redundancy, and a safety buffer.
The calculation is intended for early infrastructure planning and vendor comparisons. It distinguishes throughput-driven capacity from availability-driven spare capacity, so teams can see how much of the fleet is needed for traffic and how much is reserved for failover or maintenance.
1. Enter peak demand
Use the highest sustained fraud-scoring rate expected during normal operation.
2. Use benchmarked GPU throughput
Enter transactions per second measured on the intended model, precision, batch size, and GPU type.
3. Choose target utilization
Leave operating headroom rather than planning for continuous 100% utilization.
4. Add buffer and redundancy
Apply a demand buffer and explicit spare GPUs, then review total fleet size and capacity.
Effective TPS per GPU = Benchmarked TPS per GPU × Target utilization
Traffic GPUs = ceil(Peak TPS × (1 + Buffer %) ÷ Effective TPS per GPU)
Total GPUs = Traffic GPUs + Redundant GPUs
The result is the estimated number of GPUs to provision, including explicit redundant units.
Benchmark throughput must come from a configuration that matches the production model; otherwise the estimate can be misleading.
Given: 300 peak TPS, 95 TPS per GPU, 70% target utilization, 20% demand buffer, and 1 spare GPU.
Calculation: Effective throughput = 95 × 0.70 = 66.5 TPS/GPU. Buffered demand = 300 × 1.20 = 360 TPS. Traffic GPUs = ceil(360 ÷ 66.5) = 6. Add one spare.
Result: Provision 7 GPUs.
Benchmarks often represent near-maximum throughput. Applying a utilization target preserves headroom for traffic variation and avoids operating at saturation.
This calculator adds them after traffic sizing. That makes the redundancy assumption explicit instead of silently counting all GPUs as normally active.
Not directly with one average unless you calculate a defensible weighted effective throughput. Separate pools are usually clearer.
No. It sizes online inference capacity only unless training load is deliberately included in the throughput benchmark and demand.
Use production-like measurements with the same model version, precision, batch size, feature pipeline, and latency constraint.