Face Recognition · AMD EPYC · GPU-optimised
Face recognition servers
Real-time facial identification, authentication, attendance and access control. AMD EPYC with GPU acceleration — up to 5 SFF GPUs or 4 dual, plus RTX and Radeon in 3U and 4U.
- AMD EPYC — Multi-socket
- 5 SFF or 4 dual GPUs — Plus RTX / Radeon
- SSD and NVMe tiers — Fast database queries
- 25G / 100G — For high concurrency
- Secure boot — Firmware integrity
Built for low latency
Acceleration, storage and enterprise reliability
Matching a face against a large template database in real time is a memory and I/O problem as much as a GPU one. The platform is sized for both.
- AI acceleration — SFF GPU modules up to 5 single or 4 dual, support for RTX and Radeon cards in 3U and 4U, and PCIe Gen4 and Gen5 with high throughput.
- Flexible storage — 8, 12, 16 or 24 bay hot-swap options, diskless variants for SAN, NAS and object storage, and SSD and NVMe tiers for fast facial database queries.
- Enterprise-ready — Redundant hot-swap PSUs and fans, 10G, 25G and 100G NIC options, and remote management over IPMI and Redfish.
How to size it
Four inputs decide the configuration
Throughput and database size drive the GPU and memory decision; where it is deployed drives the chassis.
- Faces per second — determines GPU count and the choice of model
- Database size — large template databases benefit from an NVMe tier
- Deployment — edge versus central influences chassis depth and acoustics
- Networking — high concurrency needs 25G or 100G NICs
Typical use cases
Where deployments of each kind land
- Access control — GPU: 1–2 GPUs. Use case: Office and building entry authentication
- Attendance — GPU: 2–3 GPUs. Use case: Enterprise-scale facial attendance systems
- Smart city — GPU: 4–5+ GPUs. Use case: Real-time crowd scanning and public safety
Guidance, not a rule. Faces per second and template database size move these numbers more than the number of cameras does.
Performance and security
Latency on one side, protection of the database on the other
GPU scheduling is optimised for low-latency recognition, because a match that arrives after the person has walked through the door has not really been made. Throughput and latency are separate requirements and a build has to be sized against both.
A facial template database is sensitive data by any reading. Encryption support, secure boot and firmware integrity are part of the platform rather than something layered on afterwards — and the hardware side of that is only half of it. The software, the retention policy and the lawful basis for holding the data remain the operator's responsibility.
- Optimised GPU scheduling for low-latency recognition
- Secure boot and firmware integrity
- Encryption support for facial databases
- 25G and 100G networking where concurrency is high
- scheduling for recognition
- database support
- for large template sets
- remote management
Software and management
What it runs, and how it is operated
- FR software compatibility — Tested with the leading face recognition software frameworks used in India, with validated deployments available on request.
- Operating system — Windows Server and the major Linux distributions — Ubuntu, CentOS, RHEL — for FR software compatibility.
- Monitoring — Remote monitoring over IPMI and Redfish, with SNMP integration for centralised control.
- Automation — REST API hooks, so recognition events reach the access control or attendance system that has to act on them.
Technical specifications
The configurable surface
- Chassis — Details: 8 / 12 / 16 / 24 bays, hot-swap or diskless
- Processors — Details: AMD EPYC, multi-socket
- Memory — Details: ECC DDR4 and DDR5, scalable
- GPU — Details: Up to 5 SFF or 4 dual GPUs, plus RTX and Radeon
- Storage — Details: Enterprise HDDs with optional SSD and NVMe tiers
- Networking — Details: 10G / 25G / 100G options
- Power — Details: Redundant hot-swap PSUs
- Management — Details: IPMI and Redfish with virtual console
- Operating system — Details: Windows Server or Linux distributions
- Warranty — Details: Standard next-business-day; SLA upgrades available
FR server questions
The ones asked before every deployment
- What are FR servers used for? — Answer: Facial recognition for access control, attendance systems, public safety and smart city surveillance.
- How many GPUs are needed? — Answer: Smaller deployments need 1–2. Smart city or large-scale deployments may need 4–5 or more for real-time processing.
- Can they integrate with existing CCTV? — Answer: Yes. The servers are designed to integrate with existing surveillance networks and camera infrastructure.
- Do they support encrypted facial databases? — Answer: Yes — database encryption, secure boot and firmware integrity for secure facial data handling.
- Which operating systems are supported? — Answer: Windows Server and the major Linux distributions — Ubuntu, CentOS, RHEL.
- Are they tested with FR vendors in India? — Answer: Yes, tested and compatible with the leading FR vendors used in India.
Request sizing
What to send us
The faces per second you need to process, the size of the template database, and the deployment type — edge, central, or both. With those we can put a configuration and GPU option in front of you.
Database size is the input that surprises people. A system sized comfortably for ten thousand templates is a different machine from one matching against several hundred thousand at the same latency.
Size it first
Work the numbers before you specify
The calculators run the same arithmetic our engineers do, so you can arrive with a starting configuration rather than a blank page.
- Face recognition GPU sizing — Faces per second and template database size to GPU and memory.
- Video analytics GPU sizing — Streams, models and frame rate to a GPU count that holds under real load.
- All sizing tools — Six calculators running the same arithmetic our engineers do.