SOLANET: GPU-Accelerated k-NNG Toolkit

• SOLANET is a distributed toolkit that constructs approximate k-nearest neighbor graphs at billion-point scale using GPU acceleration and lock-free NN-Descent.
• It integrates a single-GPU lock-free algorithm with MPI one-sided operations for efficient local and cross-partition graph refinement.
• The system demonstrates near-ideal scaling and high recall performance on diverse datasets while mitigating communication overhead through coarse-grained transfers and optimized search strategies.

SOLANET is a GPU-accelerated, distributed toolkit for building high-quality approximate $k$-nearest neighbor graphs (k-NNGs) at billion-point scale. It targets a class of workloads in which neighbor graphs are central data structures for analytics and AI, but where distributed construction is impeded by irregular computation, non-coalesced memory access, load imbalance, and communication overhead. The system combines a lock-free NN-Descent implementation for AMD GPUs with a distributed refinement scheme that pulls remote graphs via MPI one-sided operations and performs graph-based approximate nearest neighbor (ANN) searches with CAGRA to recover cross-partition neighbors (Iwabuchi et al., 26 May 2026).

1. Formal problem setting and quality criteria

SOLANET operates on a dataset $X = \{x_i\}_{i=1}^N$, with $x_i \in \mathbb{R}^d$, under a distance function $d(\cdot,\cdot)$. The directed $k$-NN graph is defined as $G = (V, E)$ with $V = X$, where each $x_i$ has $k$ outgoing edges to its $k$ nearest neighbors. The implementation stores two $X = \{x_i\}_{i=1}^N$0 row-major matrices: $X = \{x_i\}_{i=1}^N$1 for neighbor IDs and $X = \{x_i\}_{i=1}^N$2 for neighbor distances. The evaluated configurations use Euclidean distance,

$X = \{x_i\}_{i=1}^N$3

and cosine dissimilarity,

$X = \{x_i\}_{i=1}^N$4

The constructed graph is approximate rather than exact: each node’s $X = \{x_i\}_{i=1}^N$5 neighbors are intended to be close to the true nearest neighbors, but exact recovery is not required. Graph quality is measured primarily by recall@k. Per-point recall is

$X = \{x_i\}_{i=1}^N$6

and aggregate recall is

$X = \{x_i\}_{i=1}^N$7

The evaluation also uses a build-accuracy criterion by distance thresholding on billion-scale graphs: for each $X = \{x_i\}_{i=1}^N$8, the count is taken of neighbors in the test graph whose distances are less than or equal to the distance of the 20th neighbor in a reference graph (Iwabuchi et al., 26 May 2026).

This formulation places SOLANET in the approximate graph-construction literature rather than the exact all-pairs nearest-neighbor setting. The distinction is important because the system is designed to maximize throughput and scalability while preserving high graph quality.

2. Distributed architecture and execution model

The end-to-end pipeline begins by partitioning the dataset across $X = \{x_i\}_{i=1}^N$9 GPUs, with one MPI rank per GPU and random row-wise assignment:

$x_i \in \mathbb{R}^d$0

Neighbor lists for each point $x_i \in \mathbb{R}^d$1 remain resident on rank $x_i \in \mathbb{R}^d$2. Each GPU first constructs a local graph $x_i \in \mathbb{R}^d$3 using the single-GPU lock-free NN-Descent builder and then optimizes that graph for search, producing $x_i \in \mathbb{R}^d$4. Distributed refinement then recovers cross-partition neighbors in two phases: a binary-tree-structured refinement that progressively merges subgraphs and performs ANN search over larger remote graphs, followed by a flat refinement in which each rank searches its local queries across the other group graphs, pulls the associated vectors and optimized graphs once per group, and updates its local graph. The final result is that each rank holds $x_i \in \mathbb{R}^d$5, whose neighbors may originate from any partition (Iwabuchi et al., 26 May 2026).

The binary-tree phase is organized around repeated alternation between communication and search: remote subgraphs and vectors are pulled, local ANN searches are run, the local graph is updated, and the ranks synchronize. In the flat phase, optimized graphs $x_i \in \mathbb{R}^d$6 are read-only, and ranks proceed independently without a global barrier. SOLANET uses MPI one-sided remote memory access, with MPI_Get as the primary operation. During refinement it does not use PUT or ACCUMULATE on target graphs. RMA windows are created over remote arrays containing the optimized search graph and the feature vectors. In the binary-tree phase, consistency is enforced by MPI_Barrier before modifying local $x_i \in \mathbb{R}^d$7 and after modification so that no rank reads stale or concurrently modified data. In the flat phase, because $x_i \in \mathbb{R}^d$8 is read-only, synchronization is relaxed (Iwabuchi et al., 26 May 2026).

The communication substrate is tuned to coarse-grained transfers. SOLANET pulls compact adjacency lists for $x_i \in \mathbb{R}^d$9 without distances, reducing payload size, and pulls feature vectors $d(\cdot,\cdot)$0 as row-major contiguous float or uint8 arrays. When multiple ranks are accessed, the received arrays are concatenated in place and only metadata such as row counts are updated; no reordering is performed. Batched GETs populate double buffers so that ANN search can overlap communication latency. ANN search over a remote graph returns $d(\cdot,\cdot)$1, containing candidate neighbors per local point; a local update kernel then merges those candidates into the local graph, replacing worse neighbors and maintaining exactly $d(\cdot,\cdot)$2 outgoing edges per source point (Iwabuchi et al., 26 May 2026).

3. Local graph construction and algorithmic core

The single-GPU kernel is a lock-free NN-Descent implementation specialized for AMD GPUs. Its core data structures are the row-major neighbor ID matrix $d(\cdot,\cdot)$3, the distance matrix $d(\cdot,\cdot)$4, and a fixed-capacity per-point candidate list $d(\cdot,\cdot)$5, with capacity $d(\cdot,\cdot)$6 typically in the range $d(\cdot,\cdot)$7 to $d(\cdot,\cdot)$8. Each candidate list is stored contiguously and maintains a parallel-safe producer index. The lock-free design avoids global spin locks. Producer kernels append to $d(\cdot,\cdot)$9 using atomic operations only when a candidate distance is less than the current farthest neighbor distance for point $k$0. A separate consumer kernel assigns one thread per point to process $k$1 and update row $k$2, so row updates are race-free by construction (Iwabuchi et al., 26 May 2026).

The algorithm initializes each point with $k$3 random neighbors and computed distances, then iterates up to $k$4 times or until accepted updates fall below $k$5. In each iteration, a fraction $k$6 of current neighbors is sampled, neighbors of sampled neighbors are traversed to generate candidates, and each candidate $k$7 with

$k$8

is appended to $k$9 if capacity permits. The consumer stage merges existing neighbors and candidates, selects the $G = (V, E)$0 smallest distances, updates $G = (V, E)$1 and $G = (V, E)$2, and resets the candidate-list size. Correctness depends on the fact that only the per-row consumer performs the final graph update. Fixed-capacity candidate queues may drop candidates under contention, but the iterative behavior of NN-Descent is reported to recover most missed neighbors over subsequent iterations (Iwabuchi et al., 26 May 2026).

SOLANET couples this local builder with CAGRA-based graph search during distributed refinement. Search is a multi-start greedy hill-climbing procedure over an optimized graph $G = (V, E)$3, visiting neighbors of the best-so-far nodes until no improvement is found. The optimization of $G = (V, E)$4 follows NSG-like pruning as implemented in CAGRA: edges that can be bypassed through shorter paths are removed to improve reachability within few hops while reducing index size, and the optimized search graph need not store edge distances (Iwabuchi et al., 26 May 2026).

Typical parameters are dataset-scale dependent. The reported defaults are $G = (V, E)$5 for 100M-point datasets and $G = (V, E)$6 for 1B- and 2B-point datasets; $G = (V, E)$7 during refinement; $G = (V, E)$8; $G = (V, E)$9 with $V = X$0 used at scale; and $V = X$1. The distributed schedule sets the number of target groups after the binary-tree phase to $V = X$2 for 100M, $V = X$3 for 1B, and $V = X$4 for 2B (Iwabuchi et al., 26 May 2026).

4. Complexity, communication, and implementation environment

The communication model is expressed with the Hockney relation

$V = X$5

where $V = X$6 is latency and $V = X$7 is inverse bandwidth. Assuming ANN search cost per query $V = X$8 is near-constant with respect to source graph size, the binary-tree phase from $V = X$9 ranks to $x_i$0 groups with $x_i$1 levels has total time

$x_i$2

which is summarized as

$x_i$3

The grouped merge contributes

$x_i$4

and the flat refinement contributes

$x_i$5

The overall distributed refinement time is therefore

$x_i$6

The stated interpretation is that compute decreases with $x_i$7, bandwidth terms remain constant with respect to $x_i$8 for fixed $x_i$9, and latency grows with $k$0 but is mitigated by coarse-grained GETs and compute overlap (Iwabuchi et al., 26 May 2026).

Communication volume is expressed at the group level. For a remote group,

$k$1

and

$k$2

Across the flat phase, total payload per rank is approximately

$k$3

Memory usage scales linearly in $k$4 and $k$5. Per rank, the build graph requires

$k$6

the search graph requires only IDs,

$k$7

and candidate buffers require

$k$8

The omission of distances from $k$9 reduces both footprint and RMA payload (Iwabuchi et al., 26 May 2026).

The reported implementation platform is LLNL’s Tuolumne, using AMD MI300A APUs with four APUs per node, 512 GB total per node, HPE Slingshot 11 interconnect, and ROCm v6.4.3. Unified physical memory is enabled with HSA_XNACK=1, and hipMalloc is used for core structures. The GPU kernels are implemented with HIP, use wavefront-level primitives, LDS tiling, and coalesced row-major access patterns. Local ANN search uses hipVS CAGRA, graph optimization uses CAGRA’s NSG-inspired prune, and communication uses MPI one-sided GETs into GPU-accessible buffers with double buffering in the flat phase (Iwabuchi et al., 26 May 2026).

5. Empirical evaluation and observed scaling

The evaluation spans small and large datasets, including Fashion-MNIST, NYTimes, Last.fm, GIST, SIFT-1M, GloVe50, DEEP-100M, SIFT-100M, DEEP-1B, SIFT-1B, and DEEP-2B. DEEP-2B is formed by shifting two copies of DEEP-1B along coordinate axes to avoid overlap. The principal billion-scale experiments use $k$0, $k$1, $k$2, and the group counts described above (Iwabuchi et al., 26 May 2026).

On a single MI300A APU, the lock-free NN-Descent builder outperforms hipVS GNND in recall-time trade-off on all tested datasets except NYTimes, where hipVS is slightly better. A particularly notable case is Last.fm, on which hipVS could not exceed 28% recall, while SOLANET achieved approximately 91% recall. On L2 datasets, recall@32 is reported as approximately 99% across APUs, whereas NYTimes reaches approximately 80%. Scaling from 1 to 16 APUs modestly improves recall on GIST from 86% to 90% and on Last.fm from 91% to 95% (Iwabuchi et al., 26 May 2026).

At 100M scale, DEEP-100M improves from 1207 s on 1 APU to 66 s on 32 APUs, a speedup of 18.3×, and to 26× at 64 APUs. SIFT-100M improves from 1474 s on 1 APU to 65 s on 32 APUs, a speedup of 22.7×, and to 31.6× at 64 APUs. The reported degradation beyond 32 APUs is attributed to small partitions and growing latency overhead. At 1B scale, DEEP-1B improves from 926 s on 32 APUs to 84 s on 512 APUs, an 11.0× speedup, while SIFT-1B improves from 858 s to 79 s, an 11.7× speedup. Against NEO-DNND on 256 CPUs, DEEP-1B with $k$3 requires 1214 s for NEO-DNND and 146 s for SOLANET on 256 APUs, making SOLANET 8.3× faster. At 2B scale, DEEP-2B improves from 1090 s on 64 APUs to 159 s on 512 APUs, a 6.9× speedup (Iwabuchi et al., 26 May 2026).

The performance breakdown on DEEP-1B separates local build, binary-tree refinement, and flat refinement. Local k-NNG build decreases from 166 s on 32 APUs to 8 s on 512 APUs, approximately 21×. Binary-tree refinement to 32 groups takes 10 s at 512 APUs, about 12% of total runtime. Flat refinement decreases from 739.89 s on 32 APUs to 48.68 s on 512 APUs, approximately 15×, which is described as close to the ideal 16× reduction in queries per rank. CAGRA throughput is reported as approximately 1.48M queries per second on a 2M-node graph with 2M queries and approximately 1.3–1.4M queries per second on 32M-node graphs with the same query count, supporting the near-constant-$k$4 assumption. Communication overhead is described as negligible because of coarse-grained GETs, read-only $k$5, and overlap between communication and search (Iwabuchi et al., 26 May 2026).

Graph quality at scale is assessed relative to NEO-DNND reference graphs. On DEEP-1B and SIFT-1B, SOLANET achieves approximately 99% recall@20 for all APU counts. When the comparison is reversed, NEO-DNND attains 70–71% on DEEP-1B and 74–75% on SIFT-1B, indicating that SOLANET produces higher-quality graphs while also running faster (Iwabuchi et al., 26 May 2026).

6. Relation to prior work, deployment practice, and nomenclature

SOLANET is situated between single-node GPU graph builders and distributed neighbor-graph systems. The local builder is discussed alongside FAISS, CAGRA/cuVS/hipVS, SONG, GGNN, and BANG. Its distinguishing property is the removal of global locks through atomic candidate append and single-thread-per-row updates, with the explicit goal of improving throughput on AMD GPUs while maintaining high recall. In distributed settings, the paper contrasts SOLANET with MapReduce NN-Descent systems such as WARASHINA, centroid-based approaches such as Kim et al., CPU-MPI systems such as DNND and NEO-DNND, and PyRKNN. The principal architectural distinction is that SOLANET fetches whole remote graphs and vectors once and performs many distance computations per byte transferred, whereas the CPU-MPI designs are described as using fine-grained on-demand communication with lower arithmetic intensity (Iwabuchi et al., 26 May 2026).

The reported deployment guidance is concrete. Suggested defaults are $k$6 for datasets up to 100M points and $k$7 for billion-point datasets, $k$8, $k$9, $X = \{x_i\}_{i=1}^N$00, dataset-scale-specific $X = \{x_i\}_{i=1}^N$01, double buffering in flat refinement, and per-point candidate capacity approximately $X = \{x_i\}_{i=1}^N$02 to $X = \{x_i\}_{i=1}^N$03. Resource planning assumes approximately 128 GB per APU on MI300A; billion-scale float-vector datasets with $X = \{x_i\}_{i=1}^N$04, k-NNG storage, and workspace typically require at least 32 APUs for 1B and at least 64 APUs for 2B. Failure modes include floating-point precision stress for extremely small distances, steep load imbalance on very skewed clusters, strong-scaling limits when $X = \{x_i\}_{i=1}^N$05 becomes too small, and extra-copy penalties on systems without unified memory or GPUDirect RDMA (Iwabuchi et al., 26 May 2026).

The future-work agenda includes integration of additional local ANN builders and searchers, portability to NVIDIA GPUs, exploration of GPUDirect RDMA paths and more aggressive MPI RMA synchronization such as lock_all/flush, domain-aware partitioning to skip low-value cross-partition refinement, and enhanced overlap and adaptive batching to further reduce latency impact at extreme process counts (Iwabuchi et al., 26 May 2026).

A recurrent source of confusion is nomenclature. SOLANET should be distinguished from “SolNet: Open-source deep learning models for photovoltaic power forecasting across the globe,” which is a multivariate LSTM-based transfer-learning framework for photovoltaic power forecasting rather than a distributed neighbor-graph construction toolkit (Depoortere et al., 2024). It should also be distinguished from “SolarisNet: A Deep Regression Network for Solar Radiation Prediction,” a 6-layer deep regression network for daily global solar radiation prediction; the term “SOLANET” does not appear in that paper and is not introduced as an alias or related model name (Dey et al., 2017).