Face Recognition GPU Sizing
Both stages of a face recognition pipeline sized properly — extraction against new faces per second, matching against the enrolled database — and the larger of the two is the answer.
Enter the face rate — or estimate it from cameras and footfall — and the size of the enrolled database. The calculator sizes both stages of the pipeline separately and returns the larger, because a pipeline is only as fast as the stage that cannot keep up.
Why it asks for faces per second, not cameras
A face is recognised once and then tracked. Sizing against frame rate rather than the rate of new faces over-provisions by roughly the number of frames a person stays in view, which is commonly sixty times or more. The input exists to prevent exactly that.
Why the database size is an input
Extraction is a fixed cost per face; searching for the match is not. Ten million enrolled records is a fundamentally different search from ten thousand, and past a certain scale matching rather than extraction becomes the constraint.
How face recognition sizing actually works
Recognition runs per face, not per frame
This is the mistake that produces most over-sized face recognition quotes. A camera at 30fps does not need thirty recognitions a second. The system detects a face, extracts its embedding once, and a tracker carries that identity for as long as the person stays in frame. The rate that matters is new faces entering the scene, and it is typically dozens of times smaller than the frame rate.
Twenty cameras with thirty people a minute passing each is ten new faces per second. Sized on frames it would look like six hundred recognitions a second — sixty times the machine, for the same site.
The enrolled database is the second half of the problem
Extracting an embedding is a fixed cost per face. Searching for it is not: the work grows with how many people are enrolled, and ten million records is a fundamentally different search from ten thousand. A well-built index keeps that growth well below linear, but it does not make it free.
So the sizing runs both stages and takes the larger. On a small gallery at high footfall, extraction is the constraint and more cameras mean more cards. On a very large gallery, matching binds first — and adding cameras barely moves the number while adding enrolled records moves it a lot.
- Extraction-bound: high footfall, modest database — the cameras are driving it
- Matching-bound: large enrolled database — the gallery is driving it, and index choice matters more than camera count
- Which one binds decides what to do about it, so the page names it
Accuracy and throughput pull against each other
Lightweight recognition backbones run into the thousands of embeddings per second on a single card; accuracy-grade backbones run in the low hundreds. That is a difference of roughly ten times in hardware for the same face rate, bought with recognition accuracy that matters a great deal in the deployments where face recognition is worth doing at all.
This calculator sizes on the accurate backbone, because that is what production surveillance uses. If your deployment can accept a lighter model, the hardware drops sharply, and that is a conversation worth having before you buy.
Common questions
- How many GPUs does a face recognition system need?
- It depends on new faces per second and on how many people are enrolled, far more than on camera count. A modest site with a small database often runs on one card. A large enrolled database changes the answer even at the same footfall, because matching cost grows with the gallery.
- Does face recognition run on every frame?
- No, and assuming it does is the most common sizing error. A face is detected and recognised once, then tracked. Sizing against frame rate rather than the rate of new faces over-provisions by roughly the number of frames a person stays in view — often sixty times or more.
- How does database size affect face recognition performance?
- Substantially. Searching a gallery of ten million embeddings is far more work than ten thousand, even with a good index. Past a certain scale, matching rather than extraction becomes the constraint, and the remedy is index design and hardware rather than fewer cameras.
- How many faces per second can one GPU process?
- For an accuracy-grade recognition backbone, in the low hundreds per second on a high-end card, and proportionally less on smaller ones. Lighter backbones run an order of magnitude faster with lower accuracy, which is a trade worth making deliberately.
- Do I need separate servers for recognition and recording?
- Not necessarily, but they are sized separately and often separated in practice — recording is a sustained write workload and recognition is a GPU workload, and keeping them apart means one cannot starve the other. Size the recording side with the NVR storage calculator.