Most identity verification is built on a trade-off nobody questions: send the image to a server, wait, get an answer. It works, but it’s slow, and it means a photo of someone’s face travels across the internet every time they prove who they are.
VerifEye starts from a different premise. If verification runs on the device itself (no upload, no round trip) it can be both faster and more private, because the two problems share a root cause. Server round trips are what make verification slow, and they’re also what put biometric data in transit and in someone else’s infrastructure. Fix the architecture and both problems shrink together.
“The industry treats privacy and speed as a trade-off. On-device architecture is the proof that they’re actually the same problem.”
What “Fast” Actually Means
It’s easy to claim to be the fastest. Realeyes’ engineering team publishes the numbers instead. Section 7.2 of the Realeyes Face Verification whitepaper benchmarks the two components of the pipeline — face detection and face embedding — across precision levels on real consumer hardware: a Samsung S24 (Snapdragon 8 Gen 3) and an iPhone 15 (Apple A16 Bionic).
The headline number is the shift from general-purpose CPU to a dedicated on-device accelerator:
(Figures drawn from Section 7.2, “On-Device Performance,” measured over 1,000 inference cycles.)
| Configuration | Face detection | Face embedding | Total |
|---|---|---|---|
| Server CPU, single core (baseline) | 17–20 ms | 55–88 ms | ~72–108 ms |
| On-device CPU, FP16 | 12.9–23 ms | 35.1–49 ms | ~48–72 ms |
| On-device accelerator (QNN / CoreML), INT8 | 2.8–6.7 ms | 2.7–3.0 ms | ~5.5–9.7 ms |
| ms = millisecond | |||
Routing inference to the phone’s own accelerator; Qualcomm’s QNN on Android, Apple’s CoreML on iOS is what does the real work. The embedding model alone drops from 55–88 milliseconds on CPU to under 3 milliseconds on the accelerator. That’s the step that turns a verification check from something a user waits for into something that just happens.
“A user verified once at onboarding shouldn’t have to prove it from scratch every time.”
Why Speed Compounds
The main reason speed compounds isn’t how one check feels to a user; whether verification takes 100ms or 2ms, nobody notices the difference in the moment. It’s what that speed makes possible on the device itself.
Mobile phones and especially battery-powered cameras, doorbell cameras, wearables, access-control sensors have never been able to run face recognition continuously. Server round trips were too slow and too battery-intensive to repeat every few seconds, and running recognition locally on general-purpose CPU cost too much power to sustain either. That constraint capped these devices to occasional, deliberate checks: one verification at one moment, then nothing until the next explicit request.
“Fast enough to check once was always possible. Fast enough to run continuously wasn’t — until now.”
VerifEye’s sub-10-millisecond, on-device inference removes both halves of that constraint at once. It’s cheap enough in latency and power draw to run continuously instead of once, which turns verification from a single gate into an ongoing state. That opens categories of deployment that weren’t previously possible:
- Continuous re-verification: confirming the same person is still present throughout a session, not just at login.
- Recognition on battery-constrained hardware: cameras and wearables that couldn’t afford a server round trip, or the power cost of running recognition continuously on CPU, can now do it locally.
- Passive, ambient checks: verification that runs in the background of an interaction instead of interrupting it.
It also still matters in the conventional sense, the industry’s slowest identity checks (document upload, manual review) see abandonment rates as high as 68%, and any move toward “instant” reduces that friction. But the more consequential gain is architectural: fast enough and light enough on power, to run continuously on devices that could never do that before.
Not Every Check Needs the Same Precision
The other half of the story: VerifEye doesn’t run every check at maximum precision, because not every check needs it. Think of it like image resolution; a billboard needs full detail, a thumbnail doesn’t need nearly as much to still be recognizable. The whitepaper documents three versions of the same underlying model, each trading a bit of precision for speed and size:
- FP32 (full precision): the most exact version of the model (the “billboard” setting). Used where compute is generous and every fraction of accuracy matters, typically server or on-premises deployments.
- FP16 (half precision): roughly half the size and twice as fast as FP32, and tested at a 0.996 similarity score against the full-precision output (1.0 being identical), a gap too small to affect real-world accuracy. This is the default for most on-device deployments.
- INT8 (compressed, running on the phone’s own accelerator): the smallest and fastest version, as little as 42 MB for the embedding model, running in under 3ms. The trade-off is that it needs extra tuning per device to hold onto that accuracy.
“Not every decision needs six decimal places of precision. It needs the right amount, running as fast as that amount allows.”
That range matters because not every use case is asking the same question. A financial re-authentication needs a tight, high-confidence match. That’s a job for FP32 or well-tuned FP16. But confirming someone is clearly over 18, or clearly not a bot trying to farm survey rewards, doesn’t need the same bar. Those are coarse, high-confidence-at-a-glance decisions, and customers can deliberately run them on the fastest, most compressed configuration without over-engineering accuracy the use case never asked for. Speed becomes a dial customers turn to match the actual risk in front of them, not a fixed cost everyone pays regardless of need.
The Takeaway
On-device deployment was, until recently, a compromise: private, but slow enough that customers reserved it for their highest-stakes flows. VerifEye’s benchmarked numbers; sub-10-millisecond end-to-end inference on stock consumer chips, with a documented, tunable path between accuracy and speed, argue that the compromise no longer holds. Fast and private aren’t opposing goals to balance. On-device, they’re the same design decision.