The Memory Math of Quantization

Vector memory is not a mystery line item. It is one multiplication: bytes equals vectors times dimensions times bytes per dimension. At 1,024 dimensions in float32 that is 4,096 bytes per vector, so 10 million vectors is about 41 GB and a billion is about 4.1 TB.

The relationship is linear, which is the useful part: there are exactly three levers, and every compression technique is a discount on one of them.

Bytes per dimension is the first. int8 quantization scales each dimension into a single byte, a straight 4x cut, and for most retrieval workloads it costs a point or two of recall. Binary quantization keeps only the sign of each dimension, 32x, at which point the distance metric becomes a Hamming distance and the arithmetic gets very cheap.

Dimensions is the second, and Matryoshka is what makes it free when your model supports it. Matryoshka models are trained so that the first d dimensions of an n-dimensional vector are themselves a valid embedding, so truncating is a slice rather than a re-encode. Models without that training lose far more quality when truncated, because their dimensions are not ordered by importance.

Vectors is the third, and it is the one nobody wants to pull, because it means indexing less of your corpus.

Product quantization sits slightly outside that framing: it splits the vector into subvectors and replaces each with the id of its nearest centroid, so the ratio is tunable rather than fixed. PQ-64 lands a 1,024-dimension float32 vector at 64 bytes, which is 64x.

The thing that makes any of this survivable is the rescore cascade. Retrieve wide with the cheap representation, then re-rank that shortlist with a more precise one you kept elsewhere. The compression only ever has to be good enough to keep the right answer inside the shortlist, not good enough to rank it first. That is why stacking works: Matryoshka truncation, then a binary first pass, then a PQ rescore, then full precision on the final handful.