Four engines search the same 30,000 vectors on this device's CPU. Three of them build an index here, now, while you wait. Mastersoup loads a catalog computed offline and starts answering immediately.
Then delete 3,000 vectors and search again. Nothing rebuilds, and nothing goes offline to catch up. Every number below is measured on the machine you are holding.
Computed offline from a reference corpus and shipped unchanged. Nothing here was fitted to the vectors it is about to search.
fp32 vectors, catalog reused, deletes resolved inside a cluster
same catalog, vectors held as 4-bit codes
k-means partition, flat lists, removal through an id map
one global graph, M=16, deletions marked but not reclaimed
Thirty thousand vectors is what fits comfortably in a browser tab. These are the questions this page raises but cannot answer itself.
A 12-hour soak on the C++ runtime, 450 million inserts and deletes over SIFT-1M, with the query distribution cycling from stationary to sweep to skew. Recall never fell below 0.977 and showed no downward trend.
On a Grace-Blackwell GPU at 64 probes, Mastersoup and cuVS IVF-Flat land on the same recall curve. cuVS trained k-means on the million vectors it was about to search; the Mastersoup catalog was built offline from a 102,400-vector reference sample and never saw them. cuVS is faster at this point, 177 µs against 250 µs — the gap is kernel engineering, not partition quality.
One million vectors at 768 dimensions inside a 2 GB heap: the 4-bit store fits in 777 MB. The fp32 store does not fit at all.