Three generations of face verification technology. One experiment: run them all on the same images and see what holds up. Plus a second track on whether model size or compression quality wins when hardware is the constraint.
Two questions drove this experiment. First: can modern LLM vision models do face verification as well as purpose-built tools, or do 60 years of dedicated computer vision still have an edge? Second: on consumer hardware with limited VRAM, does a bigger model at lower compression still beat a smaller model at higher quality?
For the vision track we benchmarked three generations of technology. dlib (2017) uses 128-dimension face embeddings, the classic workhorse. InsightFace/ArcFace (2021) expanded that to 512 dimensions and trained on 5.8 million images using ArcFace loss. And then there are LLM vision models: Llama 3.2 Vision, Gemma 3 27B, general-purpose multimodal models that look at two photos and answer "same person?" in plain English.
For the text track we ran four language models on a content classification task to test whether model size beats compression efficiency on a single consumer GPU. Everything ran locally on a single RTX 3060 12GB. No cloud, no API calls.
Each model received the same reference image and candidate image. The question: are these the same person?
Test images: Creative Commons photos of public figures. Fully local: no API calls, no external services, no private data.
128-dimension face embeddings. The original workhorse of local face recognition. Fast, reliable, gets the job done, but the embedding space is small by modern standards and training data was limited by 2017 benchmarks.
512-dimension embeddings. ArcFace loss training on MS1MV3 (5.8M images). State of the art for dedicated face recognition. The model security researchers actually use.
General-purpose multimodal models doing face verification in natural language. Not designed for this task. Running entirely on a consumer RTX 3060 12GB GPU: no cloud, no API.
A 70 billion parameter language model has 70 billion numbers, the weights that define what the model knows. At full precision (16 bits per number), a 70B model takes about 140GB of storage and RAM. Most consumer GPUs have 8–24GB. Something has to give.
Quantization compresses those weights by reducing how many bits represent each number. The levels break down like this:
No compression. Every weight stored at native floating-point precision. This is the baseline everything else is measured against. A 70B model weighs ~140GB, requires datacenter hardware or multi-GPU rigs. A 14B model at fp16 is ~29GB, which fits in a 32GB V100 with room to spare.
50% size reduction from full precision. Near-identical quality. A 70B model is still ~70GB, too large for a 12GB GPU either way.
75% size reduction. The practical sweet spot for local deployment. A 70B model shrinks to ~40GB. Quality loss is measurable but usually acceptable.
81% size reduction. Aggressive compression. A 70B model hits ~26GB. Quality degradation becomes noticeable on complex reasoning tasks.
87% size reduction. A 70B model drops to ~18GB , finally fits on larger consumer GPUs. But you've thrown away a lot. The big open question: how much?
Consumer hardware like a single RTX 3060 with 12GB VRAM can't run a 70B model at Q4 in GPU memory. It spills into system RAM and slows down dramatically. But what if you quantize down to Q2? The model fits better, but you've compressed away a lot of what made it smart.
Here's the real question this track is trying to answer: can a 70B model at Q2 (heavily compressed, larger brain) still outperform a 14B model at Q4 (less compressed, smaller brain)? In this first round we tested everything at Q4_K_M to establish the baseline. The 70B spilled to RAM and ran 8x slower for identical accuracy on a simple task. Round 2 tests the compression frontier, running the 70B at Q2 and Q3 to find where the quality breaks.
Four language models, same task: classify 10 text snippets as content match vs. non-match. 5 true matches, 5 non-matches. All models ran at Q4_K_M quantization. Round 1 baseline. Round 2 compression results below.
FPR = False Positive Rate (flagged legit content as a match). FNR = False Negative Rate (missed a real match).
Each model received a reference description and a candidate text snippet. The question: does this text describe content that matches the reference?
InsightFace matched dlib's 100% accuracy on every test pair and ran 13x faster. 0.7 seconds vs 9.4 seconds per comparison. Same correctness, dramatically faster pipeline. There's no practical reason to stay on dlib for local face verification tasks.
0 for 4. After a 95-second first inference, the model never produced a SAME/DIFFERENT verdict. Likely refused face comparison of public figures due to content policy guardrails. This is a real limitation for content protection use cases: a model that won't say "same person" is useless for the job.
3 for 4. It correctly identified all three different-person pairs. But it missed the one true positive: two photos of the same person. For content protection that's the critical failure mode: if a model can't confirm a match, it can't help a creator prove infringement. Confidence was 1.0 on its calls. Wrong direction.
DeepSeek R1 14B, Qwen3 14B, and Llama 3.3 70B all scored 10/10 on the classification task. But the 70B averaged 88.6 seconds per case vs 10.9s for DeepSeek. Same accuracy, 8x the wait. At Q4_K_M on a 12GB GPU, the 70B can't fully load into VRAM, it spills into system RAM and slows to a crawl. The 14B fits cleanly and runs fast. This is the baseline. The question for Round 2: what happens when we drop the 70B to Q2 or Q3? Does it finally fit in VRAM? Does accuracy hold? That's where the real size-vs-quality tradeoff starts.
A general-purpose LLM vision model cannot do face verification as well as a purpose-built model. Not yet. The classical models (both generations) ran circles around the LLMs on accuracy and speed. But the LLMs weren't useless: they excelled at the text classification track, where reasoning about context is exactly the job. The lesson isn't that one approach is better. It's that the right tool depends entirely on the task. A model trained to identify faces will always know something a general-purpose chatbot doesn't.
Why it won: Accuracy was the threshold: you either verify the face correctly or you don't. InsightFace matched dlib's perfect score on all 4 pairs. Tie goes to speed. At 0.7s average vs dlib's 9.4s, InsightFace runs the same verification 13 times while dlib finishes once. At scale, thousands of image pairs in a scan, that gap compounds into hours.
Why the LLMs lost: Llama 3.2 Vision returned HTTP 400 on every pair. The model refused to compare faces of real people, likely a content policy guardrail. Gemma 3 27B completed 3 of 4 but failed the only true-positive pair: two photos of the same person. It called them different with 100% confidence. That's the worst failure mode in identity verification: high confidence in the wrong answer. It also averaged 80 seconds per pair and spilled heavily onto CPU, making it impractical even if it had gotten the answer right.
Deciding metric: Accuracy first, then latency as the tiebreaker. InsightFace won both. dlib matched it on accuracy but lost by 13x on speed. The LLMs were disqualified by accuracy before speed was even a factor.
Why it won: Three models hit 100% accuracy: DeepSeek R1 14B, Qwen3 14B, and Llama 3.3 70B. Tie goes to speed. DeepSeek averaged 10.9 seconds per case. The 70B averaged 88.6 seconds. Same answer, same confidence. One model got there 8 times faster. On a 12GB GPU, the 70B can't fit in VRAM at Q4_K_M quantization and spills into system RAM. RAM is slower than VRAM by an order of magnitude. The 14B fits cleanly, stays in VRAM, and runs hot.
Why Gemma 3 27B lost: Accuracy. It scored 80%, two missed cases, while the others got 100%. It also hit cold-load timeouts on the first two cases (model loading from disk took longer than the 120-second cutoff), meaning the first results it produced came after the other models had already answered multiple cases.
Deciding metric: Accuracy first, latency as tiebreaker. DeepSeek and Qwen3 tied on both accuracy and near-identical run profiles; DeepSeek edges out on average latency by a few seconds. The 70B had the same accuracy but was disqualified from the win by the hardware constraint: size without VRAM is a liability, not an advantage.
The 70B got faster at every compression level: Q4 (100s) → Q3 (85s) → Q2 (66s). Accuracy held 100% across all three. Compression didn't crack the brain. But it also couldn't close the gap. DeepSeek R1 14B: 9.6 seconds. Llama 70B Q2: 66.1 seconds. Same verdict as Round 1, different cause.
The bottleneck isn't precision. It's size. A 70B at Q2 is still a 70B.
Same 10-case classification task. Five models: the two baseline winners re-run for comparison, the 70B at Q4_K_M as reference, and the 70B at Q3 and Q2 as challengers. Question: does compression close the speed gap without breaking accuracy?
Run: May 8, 2026 · Behemoth (RTX 3060 12GB) · No cloud, no API calls.
* Case 1 latency includes cold-load time from disk for Qwen3 and all 70B variants. Warm inference is faster.
Round 1 tested all models at Q4_K_M, full quantization for baseline accuracy. The 70B spilled into system RAM and ran 8× slower than the 14B with identical accuracy. The question was whether compressing the 70B to Q3 or Q2 would change that calculus.
Round 2 added three challengers: the 70B at Q4 (reference), Q3 (81% size reduction to ~26GB), and Q2 (87% reduction to ~18GB). The baseline winners, DeepSeek and Qwen3, were re-run alongside them for direct comparison on the same hardware on the same day.
All five models scored 100% accuracy. The 70B got faster with each compression level. It still wasn't close to the 14B. The speed gap is a function of model size, not quantization level.
Q4 to Q3 cut the 70B's average latency from 100.4s to 85.2s, a 15% improvement. Q3 to Q2 cut it further to 66.1s, another 22%. That's real. But DeepSeek R1 14B ran in 9.6 seconds. The 70B at maximum compression is still 7× slower. Quantization reduces how many bits represent each weight, not how many weights there are. A 70B model at Q2 still has 70 billion parameters moving through computation. The bottleneck is size, not precision.
The 70B at Q2 scored 10/10 with zero false positives and zero false negatives. Confidence on individual cases dropped slightly (0.8–0.9 where the Q4 version reported 0.9-0.99) but the verdicts were correct every time. For this classification task, throwing away 87% of each weight's precision left the model fully capable of answering the question. Whether that holds on harder reasoning tasks is a separate question. On this one, Q2 held.
Case 1 timed out at 120 seconds with no response. Same cold-load behavior as Round 1. Once the model was warm, Cases 2–10 averaged 11.7 seconds each and hit 100% accuracy. This is reproducible: Qwen3's first inference from a cold start exceeds the 120-second cutoff on this hardware. The fix is simple: pre-warm the model before the first case. But in an unattended pipeline, that's a real operational consideration.
After Round 1, DeepSeek won because the 70B couldn't fit in VRAM and spilled to RAM. That felt like a hardware constraint: run the 70B on a bigger card and it might win. Round 2 tested the other side of that: compress the 70B so it fits better. Same answer. The 70B at Q2 is faster than Q4, but still 7× behind DeepSeek. The task doesn't require a bigger brain. A 14B reasoning model that fits cleanly in VRAM gives the same answer in one-seventh the time. Unless the task gets harder, the 14B wins.
Why it won (different reason than Round 1): Round 1 verdict: the 70B spills to RAM on a 12GB GPU, and RAM is slow. Round 2 hypothesis: compress the 70B so it spills less. Round 2 result: compression helped (100s → 66s) but didn't change the outcome. The 70B at Q2 still has 70 billion parameters. The 14B has 14 billion. On identical hardware, bigger models take longer to run regardless of how efficiently you pack the numbers. VRAM spillover was a symptom, not the disease. Size is the disease.
Why this matters for the use case: Content monitoring pipelines run this classification at scan time, potentially thousands of URLs per session. At 9.6 seconds per URL, a 500-URL scan takes about 80 minutes. At 66 seconds, the same scan takes over 9 hours. For automated monitoring, latency is the product. DeepSeek gives the same answer in one-seventh the time.
The unanswered question: This task was designed to be solvable. A 14B reasoning model was always going to handle it. What if the task required more? Deeper context, ambiguous cases, multi-signal reasoning? That's where a 70B earns its weight. The right model for this classification layer is the 14B. Whether a harder layer needs the 70B remains untested.
A Tesla V100-SXM2-32GB joined the lab. The 70B finally ran fully in VRAM at every quantization level. The speed gap closed. DeepSeek R1 14B still won, 6.1s vs 108s for the 70B Q4. Three rounds. Same verdict. Smaller is faster, and on this task, faster is better.
The V100 confirmed what two rounds of RAM spillover couldn't: VRAM was a symptom. Model size was always the disease.
Same 10-case classification task. Five models. New hardware: Tesla V100-SXM2-32GB (32GB VRAM) added to Behemoth alongside the RTX 3060. For the first time, the 70B ran fully in VRAM at all three quantization levels, no spillover, no RAM bottleneck.
Run: May 17, 2026 · Behemoth (V100 32GB + RTX 3060 12GB) · No cloud, no API calls.
* Qwen3 case 1 cold-load timeout excluded from average. Cases 2–9 scored.
Rounds 1 and 2 ran on a single RTX 3060 with 12GB VRAM. The 70B at Q4 spilled heavily into system RAM. Q3 spilled less. Q2 spilled the least. All three were slower than the 14B because RAM is an order of magnitude slower than VRAM.
The V100 removed the spillover constraint entirely. The 70B Q2 (26GB) and Q3 (34GB) fit fully on the V100. The 70B Q4 (42GB) spans both cards, V100 plus the RTX 3060, but still runs entirely in VRAM. For the first time in three rounds, the 70B ran the way it was designed to.
Result: the 70B Q2 dropped from 66.1s to 29.4s. The Q3 dropped from 85.2s to 60.2s. Real improvements. Still not enough. DeepSeek R1 14B went from 9.6s to 6.1s on the faster hardware. The 14B benefited too.
Moving the 70B Q2 from RAM spillover to full VRAM cut its latency by 55%, 66s down to 29s. That's the VRAM effect in numbers. It's real and it's significant. But the 14B went from 9.6s to 6.1s on the same hardware upgrade. Both models benefited. The ratio barely changed. VRAM was a constraint on the 70B, but removing it exposed a deeper one: parameter count.
Round 2: 70B Q4 averaged 100.4s spilling to RAM. Round 3: 70B Q4 averaged 108.1s fully in VRAM on the V100. Running in VRAM was slightly slower than running in RAM on the 3060. The V100 has massive bandwidth but the model is 42GB spanning two cards across PCIe. For the Q4 version, the dual-GPU split introduced overhead that offset the VRAM advantage. Quantize it down and the story changes, but at Q4, bigger memory didn't help.
Round 1: hardware constraint. The 70B couldn't fit in 12GB VRAM. Round 2: compression challenge. Drop the 70B to Q2 and see if it fits and stays accurate. Round 3: remove the ceiling entirely. Run the 70B at Q4 on 32GB VRAM, fully loaded, no excuses. Same result every time. The 14B reasons through the classification task in 6 seconds. The 70B takes 108. For this specific task, 70 billion parameters is solving a problem that 14 billion already solved. The 70B earns its size on harder jobs.
Adding a Tesla V100-SXM2-32GB to the lab opened up model categories that were impossible before: 32B models fully in VRAM, 70B models without RAM spillover, Q4 quantization on the largest publicly available open-source models. None of that changed the classification verdict. But it opens the door to experiments that actually need it: longer context windows, multi-document reasoning, models above 30B parameters. Round 3 closed the Face-Off. The V100 opens the next chapter.
Why it won: Three rounds, three different hardware environments, same result. On 12GB VRAM, the 70B spilled to RAM and lost. On a 32GB V100, it ran clean and still lost. The task, classify 10 text cases as content match or non-match, is solved completely by a 14B reasoning model. No 70B adds anything except latency. At 6.1 seconds per case, DeepSeek R1 14B is the production answer.
What the V100 proved: VRAM was a real bottleneck, the 70B Q2 cut from 66s to 29s when RAM spillover was eliminated. But the 14B also got faster (9.6s to 6.1s). The 70B's architecture is the constraint, not its memory environment. More VRAM is a prerequisite for running bigger models, not a reason to run them when smaller ones work.
Shipping it: DeepSeek R1 14B on Behemoth, local inference, no API costs. The V100 gives it room to run fast. The Face-Off is closed.
Three rounds decided. Same winner every time. Now the same question with one variable changed: does precision matter? DeepSeek R1 14B won at Q4_K_M, 75% compression, 9GB. Here it runs at Q8 (50% compression, 15GB) and fp16 (full precision, 29GB). Same 10 DMCA classification cases. Same hardware. Same scoring. Only the quantization changes.
| Model | Quant | VRAM | Accuracy | Latency | Status |
|---|---|---|---|---|---|
| DeepSeek R1 14B Round 3 baseline | Q4_K_M | 9 GB | 10/10 | 6.1s | ✓ Done |
| DeepSeek R1 14B Q8 LATE ENTRY | Q8_0 | 15 GB | 10/10 | 9.1s | ✓ Done |
| DeepSeek R1 14B fp16 LATE ENTRY | fp16 | 29 GB | 10/10 | 24.9s | ✓ Done |
Precision didn't help. All three scored 10/10. Q4 won the ladder on speed. Q8 ran at 9.1s, 62% slower than Q4, zero accuracy gain. fp16 at 24.9s is 4.4× slower than Q4 and still 10/10. The model brain is the same across all three quantization levels. For this classification task, the information is fully preserved at Q4. Compression artifacts don't appear to exist below the threshold that would change a SAME/DIFFERENT verdict. The production answer is Q4: smallest, fastest, correct.
Note: fp16 case 1 hit 114.5s on first inference, cold-load overhead for a 29GB model. Cases 2–10 averaged ~14.5s. Full average including cold load: 24.9s.
Every test case. Every verdict. Every model's actual reasoning. Nothing cherry-picked.
Reference image shown left. Candidate image right. Ground truth: whether they are the same person.
* First-case latency includes model cold-load time from disk. Subsequent cases run significantly faster once the model is resident in memory.
Same 10 cases as Round 1. Models shown left to right: DeepSeek R1 14B · Qwen3 14B · Llama 70B Q4 · Llama 70B Q3 · Llama 70B Q2.
* Case 1 latency includes cold-load time for Qwen3, 70B Q4, Q3, and Q2. Warm inference is 3–10× faster on subsequent cases.