UK Why there is no single answer
Ask how many cameras a GPU can handle and the honest answer is that it depends on the job. The same card might analyse 60 streams for a simple people counter and only six for a model that segments every pixel at full frame rate. Choosing video analytics hardware is really about finding which part of the pipeline runs out first.
Every camera stream passes through the same stages: the computer receives the compressed video over the network, decodes it into frames, resizes them, runs the AI model, then tracks, records or raises alerts. Each stage has its own limit, and the GPU’s capacity is set by the tightest one. Our guide to what video analytics is covers the pipeline itself.
The four limits to check
Work through these in order. Any one of them can cap the camera count.
-
//
Video decode. GPUs decode H.264 and H.265 in dedicated hardware engines (NVDEC on NVIDIA GPUs), separate from the cores that run the model. Decode capacity is measured in pixels per second, so one 4K stream costs about the same as four 1080p streams. The codec mainly changes the bitrate on the network, and our comparison of H.264 vs H.265 explains the trade-off.
-
//
Inference. This is usually the real limit. A model’s cost per frame depends on its size and input resolution, and its throughput depends on precision and batching. Running the model at INT8 precision can roughly double throughput compared with FP16 on supported GPUs, with little loss of accuracy once calibrated.
-
//
Memory. Each stream needs frame buffers, and each model needs memory for its weights and working data. Several models running side by side, or a large model with many streams, can exhaust GPU memory before the cores are busy.
-
//
Network and CPU. The computer has to receive every stream and the processor has to manage them. A 1080p H.265 camera typically sends 2 to 6 Mbps, so dozens of cameras sit comfortably on a 1 GbE link, but recording, tracking and stream handling all add processor load.
Frame rate is the biggest lever
Cameras usually send 25 or 30 frames per second, but most analytics do not need to inspect every one. Intrusion detection, counting and safety checks work well at 5 to 10 frames per second, especially with an object tracker filling in the frames between detections. Analysing one frame in three cuts the inference load by two thirds and roughly triples the number of cameras the same GPU can cover.
Resolution matters in the same way. Many detectors work on an input of around 640 pixels square, so a 4K frame is scaled down before inference anyway. Cropping to a zone of interest, or tiling only where small objects must be found, uses the GPU’s time on the parts of the scene that matter.
A worked sizing example
Here is how to estimate the camera count for a typical detection workload. The figures are illustrative; replace them with numbers measured on your own model and GPU.
| Step | Assumption | Result |
|---|---|---|
| Measured model throughput | Detector at INT8, batched, on the target GPU | 600 frames per second |
| Frames analysed per camera | 10 frames per second, tracker in between | 10 per camera |
| Theoretical camera count | 600 ÷ 10 | 60 cameras |
| Planning margin | Run at 75% for peaks, tracking and recording | 45 cameras |
| Decode check | 45 × 1080p30 within the GPU’s decode capacity? | Confirm on datasheet |
If the decode check fails, decode fewer frames, use a lower-resolution substream from each camera, or spread the cameras over two GPUs. If memory runs short, reduce the batch size or the number of models loaded at once. The TOPS figure on a datasheet is a useful first filter between GPUs, but it is a peak value and never replaces a measured frames-per-second number.
Matching the hardware to the camera count
For a few cameras on a vehicle or a machine, a NVIDIA Jetson system is often enough: the module combines a GPU, hardware decoders and the processor in one low-power package, and many carrier boards take cameras directly over GMSL or PoE.
For dozens of streams at one site, a computer with a discrete GPU gives more decode engines, more memory and much higher inference throughput. The 72 W NVIDIA L4 is built for this kind of many-stream inference, and our industrial GPU computers take a range of RTX and data centre cards for larger camera counts. Beyond that, the choice is between several edge computers spread across the site and one larger server in a cabinet. Our range of edge AI computers covers all of these approaches.
Remember the cameras’ own power, too. If the computer powers them over PoE, its port budget limits the count as surely as the GPU does, as our guide to PoE budgeting for multi-camera edge AI explains.
Quick answers on cameras per GPU
Camera counts and GPUs: common questions
Does a 4K camera count as four 1080p cameras?
For decoding, roughly yes. Decode load scales with pixels per second. For inference it may not, because frames are usually scaled down to the model’s input size first.
Can two models run on the same stream?
Yes. A detector often feeds a second model, such as a classifier or plate reader, that runs only on the objects found. Budget for both.
Is it better to use one big GPU or several small systems?
It depends on the site. One GPU is simpler to manage; several systems near the cameras cut cabling and avoid a single point of failure.
How do I measure capacity?
Run the real pipeline on the target hardware. Add streams until frames start to drop or latency rises, then plan for about 75% of that figure.
We fit and configure the GPU, storage and operating system as standard, so the system arrives ready for your analytics software.