HyperPage learns page layouts so disk vector search reads fewer pages

A research team at Grafy Research Lab has proposed HyperPage, a method that rearranges how vectors are placed on an SSD so that repeated searches touch fewer disk pages. Because disk-resident vector indexes underpin large-scale retrieval, a layout that cuts page reads can lower the latency and cost of the AI search workloads that hit the same index over and over.

What did the HyperPage paper announce?

The paper, titled "HyperPage: Learned Page Layouts for Disk-Resident Graph Vector Indexes," was posted on 13 November 2026 by Xinyu Zhang, Jingze Li, Baihua Zheng and Weiwei Sun, according to Grafy Research Lab. It is listed under databases and information retrieval, runs to 14 pages with 4 figures and 7 tables, and the authors say the code is available.

The central claim is narrow and practical. Instead of laying out an index once and leaving it fixed, HyperPage learns a page layout from the record of a completed run and applies it for a declared memory budget, so that later runs against the same index read fewer pages.

How do disk-resident graph vector indexes work?

Approximate nearest-neighbor search often uses a graph: each stored vector is a node, and edges link it to nearby vectors. To answer a query, the index starts at some entry point and greedily walks the graph, expanding the record it is on and moving toward closer neighbors.

Disk-resident indexes such as DiskANN keep this graph on an SSD rather than in RAM, which is what lets them hold more vectors than memory alone would allow. According to Grafy Research Lab, each vector is stored together with its graph edges as a single record, and records are grouped onto SSD pages. A search has to load the page of every record it expands, so the number of page reads a query needs is decided largely by the layout — that is, by which records happen to share a page.

That coupling is the opening HyperPage exploits. Two records that are always expanded together waste I/O if they sit on different pages; place them on the same page and one read can serve both.

How does HyperPage build the layout?

The method depends on having a record of past queries. Grafy Research Lab describes a setting in which search agents trained with reinforcement learning query one index run after run, and every graph traversal can be logged together with the records it expanded.

HyperPage takes the logs of a finished run and uses them to decide which records should share a page, subject to a declared memory budget. The intuition is that if later runs expand largely the same records in the same neighborhoods, co-locating those records turns many small reads into fewer, fuller ones. The layout is learned from observed access rather than fixed in advance, and the payoff shows up on the runs that follow.

How does HyperPage compare with Starling and MARGO?

The paper positions HyperPage against existing page layouts, naming Starling and MARGO as points of comparison. What sets HyperPage apart, as the authors describe it, is that its layout is derived from the recorded traversals of an actual run rather than decided without that history. The feed summary describing the earlier methods is cut off, so this account sticks to what the summary states.

The comparison matters because page layout for graph indexes is an active area: any method that reduces reads for a given memory budget competes on the same axis, and HyperPage's bet is that logged query behavior is a better guide than a layout that ignores it.

Why do fewer page reads matter in practice?

Vector search is the retrieval layer behind many AI products — semantic search, recommendation, and the retrieval step in retrieval-augmented generation. When the index is too large for RAM it lives on disk, and every query pays for the pages it must fetch. Fewer page reads translate fairly directly into lower latency and less I/O load, and, at scale, into cost.

The catch is that HyperPage's advantage is tied to its assumption. It learns from a finished run's logs, so it fits workloads where the same index is queried repeatedly and the query pattern is reasonably stable — the reinforcement-learning search agents in the paper's setup are exactly that kind of workload. A system that issues one-off, unpredictable queries against a fresh index has no finished run to learn from, and would not benefit in the same way.

How can you explore this with Grafy?

The most direct route is to read the paper itself. Reader is built to read, search and question PDFs and papers with AI, so you can drop in the HyperPage preprint and ask it to explain the layout algorithm, the memory-budget constraint, or how the page-read counts were measured. For a lighter introduction to that workflow, the reading room walkthrough shows how it works on research papers.

To see where this sits among other retrieval results, Grafy News has covered a related result on a new stopping rule that bounds error in constrained vector search. And if you would rather talk the concepts through — graph traversal, SSD pages, reinforcement-learning agents — Grafy Chat can put several models on the question side by side.

Source: Grafy Research Lab, "HyperPage: Learned Page Layouts for Disk-Resident Graph Vector Indexes," arXiv, November 2026.

Frequently asked questions

Does HyperPage reduce page reads on later runs?

According to Grafy Research Lab, yes. HyperPage uses the traversal logs of a finished run to arrange which records share each SSD page, under a declared memory budget. Because later runs tend to expand the same records in the same neighborhoods, that layout lets them fetch fewer pages. Cutting page reads is the paper's central claim and the reason the learned layout is worth building.

What kind of index does HyperPage reorganize?

It targets disk-resident graph vector indexes such as DiskANN. In these, each vector is stored together with its graph edges as a single record on an SSD page. A search must load the page of every record it expands, so the physical page layout — which records share a page — directly shapes how many reads a query needs. HyperPage changes that layout, not the graph itself.

Does HyperPage rely on reinforcement-learning search agents?

The paper's setup assumes search agents trained with reinforcement learning that query the same index run after run, so their graph traversals can be logged with the records they expand. HyperPage learns its layout from those logs. The approach therefore suits workloads with repeated, fairly stable queries against one index, rather than one-off searches on a freshly built index with no history.

---

Source: Grafy Research Lab — HyperPage: Learned Page Layouts for Disk-Resident Graph Vector Indexes