Hyperbolic embedding models put vectors on a Lorentz hyperboloid rather than a sphere. One of these is Hyper3-CLIP V1 from hyper³labs, which is about 0.1B parameters, released under OpenMDW-1.0 and backed by an August 2026 arXiv paper. The extra "height" coordinate (x0) tracks how specific a concept is. Vector databases do not offer a Lorentz distance metric, which has been a practical barrier to using these models in production retrieval. Simon Hearne's four-part Milvus blog series, published in mid-October 2026, argues that no new metric is needed. Part 3, the item flagged here, measures the approach on Zilliz Cloud's managed AUTOINDEX.
This matters to builders for two reasons. If the claims hold, hyperbolic models can be deployed on existing managed vector infrastructure without custom indexes. The benchmarks also give rough figures for recall, latency and capacity. All of the numbers come from the vendor's own blog, though, and they rest on a single model and a single image corpus.
What we checked
- What concrete evidence would resolve the remaining editorial uncertainty for this item? partly confirmed. The primary post sets out its method, cluster type, region, index settings and recall/latency/QPS numbers in detail. The underlying math checks out against the Lorentz formulas in the Hyper3-CLIP paper. Still missing: independent replication, results on any other model or dataset, and any statement of product status (GA/preview) for the features used. [4][1][3]
- Is this a new Zilliz Cloud product feature (native hyperbolic metric)? refuted. No. Part 2 says Milvus has no native hyperbolic distance metric. The method uses ordinary inner product on AUTOINDEX, and the Zilliz Cloud post does not announce a launch or give a GA/preview status. [2][4]
- Does the sign-flip-plus-centering trick preserve exact hyperbolic ranking? confirmed. The Lorentz inner product is −x0y0 + x̄·ȳ. Negating the query's x0 therefore turns a plain dot product into the Lorentz product. Subtracting a constant from every stored x0 shifts all scores for a given query by the same amount. The distance is a monotone function of that product, so ranking is preserved. The author reports a maximum deviation of 3.9×10⁻¹⁴ against the model's own scorer. [1][3]
What we found
- Here is the method. At query time, flip the sign of the query's height coordinate, which makes inner product equal the Lorentz inner product. At ingest, subtract the corpus-mean height from stored documents only. Part 2 says plainly that Milvus has no native hyperbolic metric and that none is needed. The same Lorentz formula appears in the Hyper3-CLIP paper, so the algebra can be checked independently. [1][2][3]
- The Zilliz Cloud test used about 1.28M ImageNet images embedded as 513-dim Hyper3-CLIP V1 vectors. It ran on a Performance-optimized Dedicated cluster in aws-eu-west-1 with AUTOINDEX build_level=2 at search level 10. Recall@10 rose from 0.853 on raw vectors to 0.982 after centering, which the post describes as an 88% cut in misses, with no reranking. [4]
- From an in-region c7i.large client, the centered single-request design (A) reached 0.977 recall at 3.75 ms p50 and 1,698 peak QPS. A shortlist-and-rerank design (B) reached 0.995 recall at 4.37 ms with 200 candidates, and 0.999 at 6.61 ms and 384 QPS with 1,000 candidates. In-database reranking via function chains requires Milvus 3.0.1+. At level=1 it was slower, and the author says he cannot explain why. [4]
- Hyperbolic vectors are harder for the managed index than CLIP cosine vectors. At level 1, hyperbolic recall was 0.682 against CLIP's 0.972. At level 10 the gap narrowed to 0.977 against 0.995, with equal latency at each level. Getting near CLIP-level recall therefore means running the index at its most expensive search level. [4]
- The centered collection used 34.2% of a 1 CU Performance-optimized cluster. The author turns that into a conservative floor of about 2.8M embeddings per CU at an 80% watermark and recommends a proof of concept. Zilliz docs describe build_level=2 (precision-first) as applying only to dedicated clusters on Milvus v2.6.x and list it as 'public review', which conflicts with the blog's references to Milvus 3.0.1. The post gives no prices. [4][5]
- In self-hosted Milvus, part 2 reports that centering lifted IVF_FLAT recall from 0.900 to 0.990 and HNSW (ef=128) from 0.989 to 0.996. It slightly hurt IVF_PQ, which was already unusable (0.115 raw, 0.096 centered). Part 1 reports that simulated fp16 storage went from 0.607 to 0.997 with centering. The author notes that the benefit was measured on one model and one image collection. [2][1]
- The post contrasts its results with HypRAG (arXiv 2602.07739), where hyperbolic vectors were reportedly easier to search without centering, and attributes the difference to the model. The HypRAG abstract covers retrieval quality, not ANN indexing, so how well the technique generalizes across hyperbolic models is still untested. [4][6]
What it means
If you use a Lorentz-model embedding such as Hyper3-CLIP, you probably don't need a specialized vector store. The sign-flip identity is exact. Centering stored documents' x0 does not change the ranking, and it appears to matter a great deal for graph and IVF indexes and for fp16 storage. It costs very little to add at ingest. Store the corpus mean so you can apply the same offset to new documents. Avoid PQ-based indexes for these vectors. On Zilliz Cloud, plan to run at high search levels, expect roughly 4 ms p50 in-region and around 0.98 recall without reranking, and add a 200-candidate exact rerank if you need about 0.995 or better.
Treat the numbers as a starting hypothesis, not a spec. They come from the vendor's blog, one model, one ImageNet corpus and one region, and no third party has replicated them. Before relying on them, run your own recall@k against exact Lorentz scoring on your own data. Check build_level availability and version compatibility on your cluster, since the docs list it as public review on v2.6.x. Measure capacity yourself instead of relying on the 2.8M/CU floor.
Still open
- Does centering help as much with other hyperbolic models (MERU, HyCoCLIP, HypRAG's HyTE) and with text corpora? The post itself reports that HypRAG behaved differently.
- What is the release status of the build_level and function-chain reranking features used here on Zilliz Cloud, given that the docs show 'public review' on Milvus v2.6.x and the blog cites Milvus 3.0.1?
- Why is in-database reranking slower at level=1? The author leaves this unexplained.
- What does the setup cost per month, and how does capacity scale beyond 1 CU?