Delegate CAGRA build heuristics to cuVS instead of hardcoding them - #177
Conversation
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
|
/ok to test f320ada |
|
/ok to test 6d7fc62 |
|
/ok to test f9fd999 |
|
Let's get NVIDIA/cuvs#2345 merged and then use |
paul-aiyedun
left a comment
There was a problem hiding this comment.
Changes overall look good to me. I just had a few questions.
@achirkin, it looks like your PR keeps the |
a3df879 to
2b55668
Compare
|
/ok to test 692229e |
|
/ok to test 87e16ac |
|
@imotov there are two things:
|
|
/ok to test e8167e2 |
|
/ok to test 1b0fd04 |
|
/ok to test 3e7c48d |
|
/ok to test 8e6ebe3 |
|
/ok to test ca62402 |
|
/ok to test 6132d5f |
|
/ok to test 1ce03b4 |
|
/ok to test 7b31187 |
|
/ok to test 9ab46b1 |
|
@achirkin based on our recent discussion, could you take another look and let me know what you think and how it fits into your recent change in NVIDIA/cuvs#2345. |
|
@imotov thanks for the updates! Do I understand it right, that the current PR only covers the HNSW heuristics (take beamWidth as argument and produce optimal config for CAGRA build, export and HNSW search), but doesn't yet support CAGRA heuristics (take build quality as argument and produce optimal config for CAGRA build and CAGRA search)? |
| .withIntermediateGraphDegree(gpuSearchParams.getIntermediateGraphDegree()) | ||
| .withNumWriterThreads(gpuSearchParams.getWriterThreads()); | ||
| if (gpuSearchParams.getStrategy().equals(GPUSearchParams.Strategy.HEURISTIC)) { | ||
| // AUTO_SELECT: cuVS picks the build algorithm and derives its parameters at build time, so |
There was a problem hiding this comment.
I would assume here we'd go similar to the HNSW code below, i.e.:
CagraIndexParams derived = CagraIndexParams.fromDataset(... gpuSearchParams.build_quality());
...|
@achirkin the only way I see how it could support build quality as argument is by switching from AUTO_SELECT algo seclection to using CagraIndexParams.fromDataset, which, as far as I understand, will switch the process from considering device memory to fully relying on dataset and will have a few other differences. Is this what we want to do? |
|
It is arguably different from otherwise default CAGRA settings, but the logic at the moment is exactly the same as in HSNW path: we just use the dataset dimensions to choose the optimal parameters / select graph algo. |
|
/ok to test 186a629 |
|
/ok to test bf38b05 |
|
/ok to test 27e2a75 |
|
@achirkin could you take another look? |
|
/ok to test 8305a87 |
|
This had at one time required |
|
/ok to test 3411fac |
|
/merge |
Replace the hand-rolled IVF-PQ parameter derivation and the 5M-vector algorithm switch in
CagraIndexParamsFactorywith cuVS's own heuristics: the GPU-native path now usesAUTO_SELECT, and the accelerated-HNSW path usesCagraIndexParams.fromHnswParams(), derived frommaxConn/beamWidth. Algorithm selection now differs per path: accelerated-HNSW keeps a dataset-size crossover but at cuVS's 1M vectors rather than our 5M, while the GPU-native path's AUTO_SELECT chooses on available device memory instead of size, using each algorithm's default parameters.Expose the cuVS HNSW heuristic type on AcceleratedHNSWParams, defaulting to
SAME_GRAPH_FOOTPRINT.Fixes #149