GPU search hardcodes query batch size 1 — no multi-query batching

[ManasSingh12345]

Summary

cuvs-lucene always passes a 1 × dim query matrix to cuVS. CagraSearchParams.maxQueries is never set. cuVS supports batched search natively; the Lucene layer does not expose it.

Reproducer

From a cuvs-lucene checkout:

rg 'deviceBuilder\([^,]+, 1,' src/main/java/com/nvidia/cuvs/lucene/

Both GPU search paths hardcode batch size 1:

• GPUKnnFloatVectorQuery.java (~line 195) — multi-segment path
• CuVS2510GPUVectorsReader.java (~line 458) — per-segment fallback

Neither calls CagraSearchParams.Builder.withMaxQueries(n) for n > 1.

Runtime check: run any GPUKnnFloatVectorQuery search; one cuVS cagraSearch call is issued per Lucene query. MultiPartitionCagraSearch batches segments, not query vectors — still one query per call.

Expected vs actual

• Expected: option to search N query vectors in one GPU call (as cuVS Java API allows via N-row CuVSMatrix + maxQueries).
• Actual: one query vector per search; throughput scaling in benchmarks uses queryThreads (N concurrent batch-1 searches).

Workaround

Use multiple search threads (queryThreads > 1). Not equivalent to in-kernel query batching.

Environment

cuvs-lucene 25.10+, CuVS2510GPUSearchCodec, GPUKnnFloatVectorQuery.

[cjnolet]

@ManasSingh12345 have you verified that Lucene proper supports this?

Some of the databases built on lucene allow for passing multiple query vectors at the same time, but only because there's usually a transfer overhead so you can submit them in a batch.

Lucene, however, does not support the notion of batching.

[cjnolet]

I believe the number of query threads is the number of threads that can search segments in parallel.

Note that this will be moot after @jamxia155's kernel parallel segment search PR is merged in 26.08.