Searcharxiv⌕ Search

arXiv · 2610.27508

KatoANN: Enabling Near-Exact Vector Search at the Speed of Lossy Scans with CPU Matrix Engines

Abstract

Distance scans in partition-family approximate nearest-neighbor (ANN) search are typically limited by memory bandwidth. Existing systems therefore improve throughput by reading fewer bytes per candidate, often at the cost of recall. We present KatoANN, a CPU ANN search system that removes this tradeoff by batching distance scans on Intel AMX, a CPU matrix engine. Batching allows multiple queries to reuse each fetched vector code, shifting the scan from memory-bound to compute-bound and enabling near-exact distances at the speed of a lossy scan. KatoANN stores each vector once as a 16-bit SQ16 code split into high- and low-byte planes. Its adaptive rank-then-refine scan first ranks all candidates using only the high byte, then refines a small survivor set using the full-byte code. Both stages use the same representation, avoiding a second copy of the raw vectors. Experiments across diverse high-dimensional workloads show that KatoANN is the fastest partition-family ANN search system in our evaluation throughout the high-recall range.

Explore related subjects

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Soobin Cho, Gyuyeong Kim. 2026-10-20. KatoANN: Enabling Near-Exact Vector Search at the Speed of Lossy Scans with CPU Matrix Engines. https://arxiv.org/abs/2610.27508

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

A General LLM Framework for Query Refinement

Numerous studies have explored the SQL query refinement problem, where the objective is to minimally modify an input query so that its output satisfies a specified set of constraints. However, these works typically target restricted classes of queries or constraints. We present OmniTune, a general framework for refining arbitrary SQL queries using LLM-based optimization by prompting (OPRO). OmniTune employs a two-step OPRO scheme that explores promising refinement subspaces and samples candidates within them, supported by concise history and skyline summaries for effective feedback. Experiments on a comprehensive benchmark demonstrate that OmniTune handles both previously studied refinement tasks and more complex scenarios beyond the scope of existing solutions.

cs.DB↗

Does Tile Granularity Matter? An Empirical Study of Vector Tile Compression for Map Rendering with MapLibre Tiles

Vector tiles are delivered as pyramids of small, independently encoded units, whose spatial granularity is largely determined by the tiling scheme. We investigate how this granularity affects compression in column-oriented MapLibre Tiles (MLT), using feature-oriented Mapbox Vector Tiles (MVT) as a baseline. Five heterogeneous geospatial datasets were encoded as conventional tile pyramids and as two denser variants grouping the area of 2 x 2 or 4 x 4 conventional tiles into one encoding unit at approximately matched logical levels of detail. Compared with conventional tiling, the 4 x 4 variant increased MLT's raw size saving over MVT by 1.0-7.3 percentage points across all five datasets. After per-tile gzip, the saving increased by 1.5-6.4 points in four datasets and decreased by 1.4 points in one. Coarser granularity lengthened MLT streams and reduced structural overhead in every dataset. The largest raw gains occurred where conventional tiles had the shortest streams: as mean values per stream rose from 27 to 2,075 across datasets, the raw gain decreased from 7.3 to 1.0 points. Encoded payload bytes per value also declined, with the strongest reductions in two datasets. For the two sparse datasets, coarser units reduced bytes per vertex across both formats, with or without gzip; the resulting 4 x 4 MLT+gzip archives were 71% and 33% smaller than the conventional ones. Thus, the measured compression advantage of MLT depends on spatial encoding-unit granularity, and conventional fine-grained tiling can understate the potential of column-oriented compression.

cs.DB↗

SARP: An On-SSD Index for KVCache with Fast Prefix Matching and Recovery

Distributed LLM serving relies on a global index to locate reusable key-value cache (KVCache) blocks through prefix matching. Losing the index after a crash or restart forces affected requests to recompute existing KVCache on GPUs. Persisting the index restores access after a failure. Existing persistent indexes face a tension between prefix-matching performance and recovery time. A snapshot-backed in-memory index supports fast prefix matching, but rebuilding the full index delays recovery. An on-SSD index avoids this rebuild, but adds storage accesses to prefix matching. Our core insight is that extending a matched prefix over a short span typically requires distinguishing only a few token sequences, suggesting that sparse in-memory routing state may suffice. Prefix matching also accesses block metadata in sequence order, allowing metadata for consecutive blocks to be retrieved together. We present SARP (Sparse Adaptive Routing and Packing), an on-SSD KVCache index for fast recovery and prefix matching. SARP groups consecutive block IDs and metadata into segments to amortize storage accesses across multiple blocks. A compact in-memory routing directory identifies candidate segments using entries at selected block positions. SARP limits segment retrievals and uses compact filters to prioritize candidates with longer potential matches. After retrieval, SARP verifies block IDs against the query and reuses only KVCache blocks covered by the verified prefix. After a restart, SARP restores the sparse routing directory from a snapshot. Across four multi-turn chat and agentic workloads, SARP recovers 8.0x to 77.5x faster than the in-memory index baselines and delivers 1.15x to 66.6x the request throughput of the on-SSD index baselines, while reusing only 0.0030% to 0.029% fewer tokens than exact prefix matching.

cs.DB↗