FIG. 09 // HSPANN.BUDGET_100B ONE QUERY · RECALL@10 ≈ 0.95 · 100B × 768 DIMENSIONS
Per-query budget for a 100B-vector index
Routing is the first limit: at current scoring rates it would use most of a 200 ms budget before any list is scanned. Splitting the data adds capacity; making routing faster is the next requirement.
MEASURED at the 100B tree shape DERIVED from a measured rate EXTRAPOLATED three factors of ten past the data
MEASURED
Routing accuracy 		95%of nearest lists kept A beam of 8,192 internal nodes per level keeps 95% of a query's 10 nearest lists.
MEASURED
Routing work 		≈1Mcenters scored per query About as much work as scanning 700 lists, at that beam.
DERIVED
Routing time, one machine 		≈100–175 msper query At the measured 175 ns per center on one thread, and the 1.6× I get from parallel routing today. The first limit: most of a 200 ms budget before any list is scanned.
DERIVED
Routing tree memory 		≈75 GBcopied to every machine At the measured 0.75 bytes per vector. Still fits in one machine's memory.
DERIVED
Posting lists in memory 		≈12 TB≈200 machines of 64 GB cache At the measured 120 bytes per vector. Full vectors (≈300 TB) stay in the block store.
MEASURED
Machines a query touches 		≈1 in 633 of 200 Lists concentrate in fewer subtrees as the tree deepens.
EXTRAPOLATED
Codes scanned 		≈16M10M to over 80M The 10M–100M trend extended three factors of ten. The range is too wide to test; read it as an order of magnitude.
Routing work and accuracy: stand-in tree of 70M FineWeb vectors as leaf centers, 200 queries. Memory and time use rates measured on the 100M index; routing time at the 100B shape is derived, not directly timed. The scan estimate extends the trend three factors of ten and is an order of magnitude, not a promised result.