OptiFace is a face recognition engine you run yourself. Give it one image; it returns a confident identity match backed by a reliability score you can set policy on. It's engineered to stay accurate as your gallery grows from hundreds to hundreds of thousands of faces — and to keep every face inside your own walls.
Confirm a person is who they claim to be, or find them across an enrolled gallery — one image in, a ranked match out.
Handles awkward angles, poor lighting, and low-resolution captures, with automatic enhancement of small or distant faces.
Reads image quality and liveness so you can reject bad captures and spoofing attempts before they ever reach a decision.
Accuracy is tuned so the match quality holds up as you enrol more people — not just in a small demo.
Everything here ran on the GPU, with OptiFace served as TensorRT engines built from the deployed ONNX. Accuracy is on public pair sets; the false-match study is impostor-side only (one image per subject), so genuine-accept / EER are not computed for the ICAO population.
The model alone is 2,290 img/s, but a full request also decodes, detects, aligns and searches. The CUDA serving path (nvJPEG decode → TensorRT SCRFD detection → GPU alignment → OptiFace → 1:N search, micro-batched) runs those stages on the GPU and raised saturation from ~243 to ~581 detections/s and from ~123 to ~365 identifications/s over the earlier CPU-bound pipeline. With random (Poisson) arrivals one GB10 holds p95 ≈ 100 ms up to ~300 detections/s and p95 ≈ 150 ms up to ~250 identifications/s, i.e. roughly 3,000 and 2,500 users at one request per 10 s. The load generator shared the same host, so these are conservative; multi-face images were not measured. The face detector is a separate third-party model (InsightFace SCRFD).
Host: DGX Spark, NVIDIA GB10 (sm_121), driver 580.173.02, torch 2.11.0+cu128, TensorRT 11.2.1.2, 20 CPU cores. Model under test: the OptiFace engine, deployed ONNX sha256 81f98f43… (matches the shipped SHA256SUMS), and its EMA weights. Everything ran on the GPU as TensorRT engines built from the ONNX — ONNX Runtime has no CUDA provider for the GB10. trt_fp32 is built directly from the deployed ONNX; trt_fp16 is built from an FP16 ONNX exported from the same EMA weights (TensorRT 11 has no FP16 builder flag), matching fp32 with cosine ≥ 0.99997 and identical accuracy on every set below.
Latency stays flat over 120 s with no visible throttling. This is a 2-minute run, not a soak test.
Power is the single nvidia-smi reading at the end of the run, not an average, and covers GPU draw only. Per-dollar and per-server figures need hardware pricing, which is not available.
The pipeline was CPU-bound: the model is about 0.5–3 ms of a 19–25 ms image; detection post-processing (NMS, anchors) and the alignment warp plus JPEG round-trip account for about 90%. That is what the CUDA serving path below removes.
The gender figure is a cosine over a 2-logit vector, a poor measure for it; class agreement was not computed. The liveness decision agreed on 198/198, but both paths take liveness from the same Node-side PAD model, so that line says nothing about the CUDA path. The residual difference comes from sub-pixel landmark differences (GPU Lanczos resize and fp16 detector vs. libvips and fp32); the alignment warp itself matches the CPU one to 6e-5 mean absolute pixel difference on identical landmarks.
The ICAO difference is 3 pairs out of 19,503 and comes from the sub-pixel alignment difference; both are small, but the GPU pipeline is not bit-identical to the CPU one.
The detector is now the largest GPU cost (fp32 detector: 3.85 ms per image; fp16 halves it with no change in landmark deviation).
Identify = decode + detect + align + OptiFace (22 components) + exact top-5 search against a 100,000-identity synthetic 1024-D gallery on the GPU. No request failures at any level.
Measured capacity with random arrivals: detection held p95 under 50 ms up to about 200 req/s and under 250 ms up to about 240 req/s; identification (100k gallery) held p95 under 80 ms up to about 90 req/s and under 150 ms up to about 110 req/s. At one request per 10 s per user that was about 2,000 users for detection and about 900 for identification (about 1,100 at p95 under 150 ms); at one request per 60 s, about 12,000 and about 5,400.
“Concurrent users” here means simultaneous in-flight requests; each client sends its next request as soon as the previous one returns. Throughput did not rise past 8 clients, so more concurrency only added queueing delay — the efficient operating point was about 8 concurrent requests.
Planted-match check at 1M (256 queries): top-1 correct 100%. Random Gaussian vectors, so speed only — no accuracy claim.
Nothing in this section was measured on an H100. It is derived from the GB10 measurements plus public GPU specifications quoted from memory — verify against NVIDIA's datasheets before using any of it externally. Reference specs: H100 SXM 80 GB, about 3.35 TB/s memory bandwidth, about 989 TFLOPS dense FP16 tensor; GB10, about 273 GB/s unified LPDDR5X memory. There is no reliable dense-FP16 figure for the GB10, so the compute ratio is a range, not a computed value.
The GB10 OptiFace model alone is 2,290 img/s, an upper bound that the detector and alignment reduce. The CUDA serving path above measured 581 detections/s and 365 identifications/s on the GB10, well below that bound. Do not quote the H100 ceiling as capacity — measure it. Users supported follow users = sustained req/s ÷ requests per user per second.
No competitor figures are included. None were retrieved or verified; vendor and NIST numbers should be taken from their current published sources.
The earlier “GPU alignment + NMS, then re-run the pipeline” item is done — see the CUDA serving path.
Rule for external use: no comparison table against named vendors until IJB-C and NIST figures exist for both sides and come from their current published sources.
Faces are processed on your servers. Nothing is sent to a third party — a hard requirement for many security and compliance teams.
Every match comes with a calibrated confidence you can build rules and thresholds around, instead of an unexplained raw number.
A single, stable SDK contract drops into your product — enrol, verify, and search behind one clean interface.
One single-pass engine behind one API, with each organisation's data kept fully separate. In the deployed engine, quality, liveness, and attributes are produced inside analyze in the same forward pass.
99.78% on LFW, 100% face detection and a 0.0154% false-match rate on a South Asian (Bangladeshi) ICAO population, with all 22 facial components computed in a 2.24 ms GPU pass. Recognition runs entirely on your own infrastructure, in a single model that enrols, searches, and analyses. IJB-C, NIST FRTE and presentation-attack (liveness) accuracy have not yet been measured.
Tell us what you're building. No sales pitch — just an honest conversation about the shortest path to shipping it.