Two to five million candidates out of a billion is a 200x to 500x cut in distance computations per query [15]. Exact search is O(n) per query, so that reduction is simply arithmetic, and it is the entire win [6]. The size it lands on is the same range the post concedes a brute-force loop can still handle [16]. Coarse clustering does not turn billion-scale search into a different problem. It shrinks the problem back to the scale where the naive loop already worked, and it costs recall to do it, since the buckets you chose not to probe can hold the right face [11].
The clustering happens in an offline training step, so bucket boundaries are fixed by the distribution as it looked at training time and every new face is filed under that [11]. How much that costs you depends on how much your incoming corpus resembles the sample the index was trained on.
The second lever is storing compressed rather than full-width vectors, and the text supplied to me breaks off mid-word as it is introduced [13]. A compression section that gets truncated is at least on theme.
The headline figure is one face searched across a billion photos in under a second [14]. To move that onto your hardware you would need the embedding dimensionality, because dimensionality is what converts vector count into bytes and bytes into shard count; the recall target the latency was measured at; the probe count that produced it; and the machine it ran on. The author is deliberately vendor-neutral about the embedding model [18], which is fair for the search argument and no use for sizing. Read the second as a self-reported number on one founder's corpus [1].
Inside the triangle the post names, each knob buys one corner by spending another [9]. More probes buys recall and spends latency [11]. Compression buys memory and spends precision. Cutting vectors is the only move that improves all three at once. A face you never embedded holds no RAM and costs no probe time. It also cannot return as a wrong match. That makes the exclusion list part of the engineering, and it belongs in the same document as the probe count, with a name against it.
In a smaller corpus with a hard recall floor I would take the memory hit and keep full-width vectors far longer than this design allows. At a billion vectors that option is gone, because the vectors do not comfortably fit in one machine's RAM to begin with [7]. The corpus decision arrives whether or not anyone schedules it.
