Pretrained face models: training, benchmarks and real-world use

The network, its checkpoint and your search index

A model architecture describes a computation: how layers transform pixels into features. A checkpoint supplies the learned parameter values for that architecture. A search index stores representations of indexed photographs. These are three separate artifacts. Adding a million photographs to an index increases the available candidates; it does not, by itself, improve the network’s learned filters.

CS Match’s current photo worker uses scrfd_2.5g_bnkps.onnx to locate faces and w600k_r50.onnx to represent aligned faces. The recognizer receives a 112 × 112 RGB patch and emits 512 values. A reference upload passes through those fixed weights. It creates a new comparison vector, not a newly trained personal recognition model.

This separation explains why the same person can be searched before ever appearing in a training set. The application compares learned visual features rather than asking a fixed classifier to choose a name from its training identities. It also explains why a model upgrade requires more care than adding another index row: a new checkpoint can change the coordinate system of every stored vector.

Inspect our vector and preprocessing implementation →

How labelled portraits become useful vectors

During supervised training, multiple photographs share an identity label. The network produces a feature vector, a temporary classification head scores the training identities, and the loss penalizes the wrong separation. Backpropagation adjusts the network weights. A useful training collection includes variation within each identity; otherwise the model can learn accidental shortcuts from a recurring background or capture session.

ArcFace normalizes features and classifier weights, then adds an angular margin to the correct class before applying scaled softmax and cross-entropy. This makes the training decision more demanding than simply picking the largest unmodified logit. At inference, the training identity head is unnecessary: the backbone’s feature vectors support comparisons between new images.

The equation describes the objective, not a training job run by CS Match. The actual values of the scale, margin, batch schedule and augmentation belong to the specific training recipe. Copying an example configuration from a different dataset is not evidence that the deployed checkpoint used that recipe.

● ● ●CS Match / Face AnalysisTechnical schematic

ArcFace: original objective and experiments →

Data cleaning matters as much as a large collection

Identity supervision can be wrong even when an image contains a perfectly visible face. One person assigned several labels creates artificial separation; several people assigned one label create artificial similarity. Near-duplicate images can overrepresent a capture session, and overlap between training and evaluation identities can make a benchmark look easier than a genuine deployment.

The WebFace research distinguishes a noisy collection of 260 million faces and four million identities from a cleaned collection of 42 million faces and two million identities. Its CAST process uses self-training to clean the collection. These are the paper’s dataset descriptions, not the size of our index and not a claim that our R50 was trained on all 42 million faces.

For a team using pretrained weights, the practical work is to record the checkpoint’s stated provenance and reproduce its input convention. Retraining becomes a separate research project: obtain suitable rights, prepare identity labels, separate validation data, run training, evaluate errors and plan a migration of stored embeddings. A user’s unlabelled upload is not a substitute for that process.

WebFace260M: collection, CAST cleaning and evaluation →

Why large-scale training differs from serving a request

A classifier over millions of identities can use considerable memory even when each individual face image is small. Partial FC reduces this training burden by sampling a subset of class centres for a batch; the InsightFace training implementation also supports distributed and mixed-precision training. This concerns training machinery, not the cosine operation in an ordinary comparison request.

Serving the checkpoint reuses the stored weights and evaluates only the required images. We calculate embeddings once per analyzed photo, then reuse the vectors for the selected-reference or all-pairs arithmetic. With N source faces and M reference faces, the matrix has N × M entries; it does not require N × M separate neural-network training or inference jobs.

This is a practical reason to prefer a well-understood pretrained representation for an interactive tool. The expensive learning phase has already happened. Engineering effort can instead go into reliable decoding, correct face selection, rotation handling, stable preprocessing and a report that allows the user to inspect what was compared.

InsightFace training and Partial FC documentation →Follow the comparison request →

What the published recognition results actually show

The chart reproduces the InsightFace model-pack table for R50 and MobileFaceNet. The authors state that buffalo_m shares buffalo_l recognition accuracy. Our detector-plus-R50 choice resembles the buffalo_m combination; the chart remains a model-pack reference, not a local rerun of our exact ONNX artifact.

Each column is a distinct evaluation. Read across a column to compare the two published rows; do not average the columns into a claimed production accuracy. The full 0–100 axis avoids exaggerating small absolute differences. The exact values remain available in the table and in the full-size image.

● ● ●CS Match / Face AnalysisPublished benchmark

Published InsightFace model-pack results →

Different test sets ask different questions

LFW evaluates unconstrained face verification. CFP-FP stresses a frontal-to-profile change; AgeDB-30 stresses age variation in verification pairs. IJB-C includes still images and video-derived media organized into templates, and its verification results depend on an operating point and a template-processing protocol. The benchmark name is part of the result, not decorative context.

Verification asks whether a pair passes a threshold. Identification asks which gallery entry ranks highest, or whether any entry should be accepted at all. Detection asks where a face is located. A percentage from one of these tasks cannot simply be relabelled as performance on another. Our all-pairs comparison is a set of independent pair scores; searching a large public index adds candidate selection and coverage to the problem.

A score for your photo is also a different quantity from a benchmark accuracy. Accuracy summarizes decisions over labelled trials. Cosine similarity describes the geometry of one pair. Our displayed percentage rescales that cosine using configured endpoints; it is not the fraction of a benchmark that this particular person passed.

ArcFace evaluation datasets and protocols →Our score conversion and its limits →

Read error rates at a stated threshold

For a threshold t, the false-accept rate counts different-person trials whose score reaches t. The true-accept rate counts same-person trials whose score reaches t. Raising t generally accepts fewer pairs: false accepts may fall while missed matches rise. The relevant question is the tradeoff at the intended operating point, not whether one attractive example reached 100%.

TAR at FAR 0.01% means the true-accept rate at an operating point allowing a false-accept fraction of 0.0001 on the evaluation’s different-person trials. It does not mean that every returned search match has a 99.99% probability of being correct. A balanced verification-pair benchmark and an open-set search have different base rates and different opportunities for a false match.

Keep threshold selection separate from final evaluation. If you repeatedly adjust a threshold after inspecting the same test errors, that set has become part of development. Reserve a final holdout, keep identity groups separate where appropriate, report denominators and inspect results by capture condition. This is how a useful benchmark becomes a defensible application evaluation.

A reproducible way to use a pretrained checkpoint

Pin the exact model file and record a cryptographic checksum. Document its source, runtime, image channel order, pixel normalization and landmark template. Keep a small fixed set of permitted test images with expected dimensions and valid outputs. This catches a reversed RGB/BGR conversion or changed alignment before it silently changes millions of comparisons.

Run the complete image-to-result path, not just a network fed with ideal cropped faces. Include group images, profile views, rotated heads, small faces and photos where no face is usable. Check missed detections and invalid vectors separately from valid but wrong comparison decisions. Measure time and memory on the intended serving hardware; a research latency figure from another runtime is not a capacity plan.

The model’s code license and the rights for pretrained weights and training data are separate checks. The InsightFace model zoo states a non-commercial research restriction for its downloadable models. A commercial deployment needs the applicable rights for its selected artifacts; this article does not grant them or establish that a particular deployment has obtained them.

• Version the detector, recognizer and preprocessing together.
• Record raw scores before applying a user-facing display scale.
• Use the same labelled holdout when comparing candidate deployments.
• Keep published results, reproduced results and product examples clearly distinguished.

Checkpoint source and model terms →Review our image pipeline →

What a good pretrained-model integration contributes

Our implementation is designed around a practical chain of evidence: select the intended person, obtain an aligned representation, inspect the pair and decide whether to explore public image sources. The number is accompanied by the reference crop, the source crop, detection confidence and raw vector similarity. These details make it possible to notice a wrong selection or poor input rather than treating the result as an unexplained verdict.

The strongest reason for this approach is the combination of a capable established representation with explicit controls around it. It avoids making a user retrain a network just to compare a photo, and avoids hiding the original evidence behind a single label. That is an engineering argument for a sensible balance of quality, cost and inspectability. It is not a claim that CS Match has beaten every recognition system in a controlled benchmark.

Compare alternatives and the engineering tradeoffs →Open Face Analysis →