How many camera feeds can one cloud GPU process? There is no dependable universal answer. GPU capacity changes with the video resolution, model, preprocessing pipeline, frame sampling strategy and latency expectations. Even two stores with the same number of cameras may need different configurations.
The most useful approach is to size the complete workload, then test the actual pipeline. This guide provides a practical method for estimating processing demand without treating a model benchmark as a production guarantee.
Define the workload before choosing a GPU
Write down the processing requirements for each camera group. Important inputs include stream count, source FPS, resolution, video codec, analytics task, selected inference FPS and target alert delay.
| Input | Example pilot assumption | Why it matters |
|---|---|---|
| Cameras | 12 | Sets concurrent stream count |
| Source frame rate | 25 FPS | Describes camera output, not inference demand |
| Selected inference rate | 5 FPS per stream | Determines analysed frames |
| Model | Person detection | Affects inference cost |
| Resolution | 1080p source | Influences decode and preprocessing |
| Alerts | Selected zone events | Introduces end-to-end latency requirements |
The values above are illustrative planning assumptions, not benchmark results for SiliconCloud or any GPU.
Calculate the expected inference throughput
If the platform analyses five frames each second from each of 12 cameras, the nominal inference rate is:
12 cameras × 5 analysed FPS = 60 frames per second
This gives a starting throughput requirement. It is not a prediction that a specific GPU will sustain 60 FPS, because the model and pipeline have not yet been benchmarked.
Camera source FPS and inference FPS should not be confused. A 25 FPS stream can be decoded while only a subset of frames is selected for the detector. Tracking and event rules must be tested to confirm that the chosen sampling rate is sufficient for the use case.
Benchmark the complete processing pipeline
A good GPU benchmark includes more than a standalone neural network test. Measure:
- Stream ingestion and decoding.
- Frame resize and preprocessing.
- Model inference at the intended batch settings.
- Object tracking and event processing.
- Data storage or messaging overhead.
- End-to-end event-to-alert latency.
Measure sustained throughput over a representative interval. Monitor GPU memory, GPU utilisation, CPU load and queue length. A pipeline can deliver high average FPS while still producing slow alerts during short traffic spikes.
When available, measure median, 95th-percentile and maximum latency. For operational alerts, tail latency can matter more than an attractive average.
Why model choice changes capacity
A lighter person detection model may process more frames per second than a larger or more complex model, but speed is only one concern. The model must detect the relevant events accurately in the intended retail environment.
A larger model may improve some detection results while increasing inference cost. Different input dimensions can also affect GPU memory demand and speed. Test alternative models on representative footage and compare their accuracy and throughput together.
Avoid selecting a model solely because it scores well on an unrelated public image dataset.
What about batching?
Batching allows some inference engines to process frames from different streams together. This may improve GPU throughput, but waiting to assemble a batch can increase latency.
For footfall trend reports, some additional delay may be acceptable. For an event that needs prompt staff review, lower latency may be more important than maximising frames per second.
Use performance tests to determine the batch size and scheduling approach that fit the actual workload.
CPU, networking and storage also matter
CPU and video decoding
Camera streams must be received, decoded and prepared for inference. CPU usage can become a bottleneck even while the GPU remains partially idle. Some platforms support hardware video decoding, but this depends on the environment and pipeline.
Network bandwidth
Continuous video transport requires stable connectivity. Measure actual stream bitrate rather than estimating bandwidth from resolution alone. Compression settings, camera movement and scene complexity can all influence bitrate.
Object storage
Decide whether to store only event clips, selected images, continuous recordings or aggregated analytics. These choices can change storage demand dramatically.
For an illustrative calculation, a continuously recorded 2 Mbps stream produces approximately 21.6 GB per day before storage overhead:
2 megabits/second × 86,400 seconds ÷ 8 ÷ 1,000 = 21.6 gigabytes/day
Twelve such streams would create approximately 259.2 GB per day. Real usage varies with bitrate, retention rules and what the application actually records. Storing only selected event clips may require far less capacity.
Plan for operational headroom
Do not size infrastructure only to the fastest throughput observed in a short lab test. Leave room for stream reconnects, maintenance, traffic changes and processing spikes.
A useful pilot records sustained throughput, alert latency, CPU and GPU resource usage, dropped frames and storage growth. Capacity planning should revisit these metrics after the system is exposed to normal camera conditions.
If the architecture separates ingestion, model inference and reporting services, different components can scale according to demand. That separation may be more effective than increasing GPU size when the actual bottleneck is in decoding or application processing.
GPU monitoring checklist
- Effective analysed FPS by camera and in total
- GPU utilisation and memory usage
- CPU utilisation and decoder load
- End-to-end alert latency and p95 latency
- Dropped frames and stream reconnects
- Queue depth and processing backlogs
- Network bitrate and connection stability
- Object storage growth and retention
These measurements let technical teams explain why a system needs additional resources, rather than relying on an approximate camera-per-GPU claim.
Example capacity evaluation workflow
Start with a representative group of camera streams, not synthetic blank video. Run the intended model and tracking logic. Increase the number of concurrent streams gradually. Record where throughput or latency no longer meets the agreed acceptance criteria.
Repeat the test with realistic activity levels and processing settings. If the pipeline uses more than one analytics model, measure the combined workload. Include service-level components such as stream ingestion and dashboard updates in the final production assessment.
Only after this process should a team choose a GPU family or estimate a production fleet. SiliconCloud's technology page explains the broader architecture, including compute, storage and monitoring.
Common mistakes in GPU sizing
Using source FPS as inference FPS. The model may not process every source frame.
Ignoring decoding. High video decode load can constrain the pipeline before inference does.
Comparing GPUs using unrelated benchmarks. Different models, precision modes and batch sizes produce different results.
Optimising only average FPS. Event applications also need latency, stability and correct detections.
Assuming camera count alone defines the workload. A four-camera high-resolution model may require more capacity than a larger group running lightweight analytics.
Final takeaway
Size cloud GPUs around representative streams, model accuracy and measured end-to-end performance. Treat camera counts and planning formulas as inputs to testing, not promised GPU capacities. Talk to SiliconCloud about a pilot workload or read our retail AI video analytics overview for the business context.
