: GPU-accelerated I/O for AnnData (h5ad), ETA for Wilcoxon DE (#487), and guidance on get.anndata_to_GPU/CPU

[asmlgkj]

Hi rsc team — thanks a lot for the great work on rapids-singlecell!

I have three related questions:

1. GPU-accelerated I/O for AnnData / other formats

Is there a plan or timeline to support GPU-accelerated reading of h5ad (and possibly loom/mtx) so that data land on the device without an extra round-trip?

Even partial acceleration (e.g., reading into GPU-native sparse/dense arrays, or a zero-copy path for .X) would already help a lot for large datasets.

Any recommended interim best practices to minimize host↔device copies when starting from h5ad?

2. Wilcoxon differential expression (PR Wilcoxon rank-sum addition to rank_genes_groups #487)

I noticed that Wilcoxon DE has been added here: #487

What’s the expected release or availability timeline?

Will the API mirror Scanpy’s tl.rank_genes_groups(..., method="wilcoxon") semantics (ties, groups vs. reference, dense/sparse support)?

Any constraints to be aware of (e.g., memory behavior on large CSR inputs, batching, multi-GPU)?

3. When to use rsc.get.anndata_to_GPU / rsc.get.anndata_to_CPU

I’m a bit unsure about when these calls are required vs. when rsc will handle device placement automatically.

Concretely:

Do rsc functions auto-move .X (and relevant matrices) to GPU if they detect host arrays, or should we always call rsc.get.anndata_to_GPU(adata) first?

What exactly gets moved by these helpers: only .X, or also layers, obsm (e.g., embeddings), and other arrays if present?

Expected GPU dtypes/structures: should .X be on the device as Cupy dense or cupyx.scipy.sparse.csr_matrix? Any guidance on supported sparsity patterns?

Mixed workflows: If I run a CPU step (e.g., a Scanpy CPU-only function) and then a GPU step, do I need to call get.anndata_to_GPU(adata) again?

When is get.anndata_to_CPU(adata) recommended (e.g., for plotting, exporting, certain Scanpy ops)? Are there safeguards to avoid redundant copies?

A tiny MWE to clarify expectations would be super helpful:

[Intron7]

1. GPU-accelerated I/O (h5ad / other formats)
   • There is no ETA for GPU-native I/O.
   • We may use KVIKIO in the future, but nothing is scheduled yet.
   • For now, the supported workflow is: load with Scanpy/anndata (CPU) → rsc.get.anndata_to_GPU.

2. Wilcoxon implementation
   • Also no ETA.
   • I still need to review the PR and integrate it properly with the full Scanpy-style rank_genes_groups API.
   • Once merged, details will appear in the release notes.

3. rsc.get.anndata_to_GPU behaviour
   • Moves only .X (or the specified layer) to the GPU unless convert_all=True.
   • Preprocessing (pp) functions require .X on the GPU, except pp.pca and pp.neighbors, which handle conversion internally.
   • Tool (tl) functions convert data to GPU when called, since embeddings/graphs are frequently passed back into Scanpy functions.

[asmlgkj]

1 After moving data to GPU using rsc.get.anndata_to_GPU(), do I need to explicitly call anndata_to_CPU() before:

1. Saving the AnnData object to file (e.g., adata.write('output.h5ad'))
2. Performing slicing operations (e.g., adata[adata.obs['cell_type'] == 'T cell'])

Current understanding

Based on the documentation:

• anndata_to_GPU() moves only .X (or specified layer) to GPU by default
• Tool functions convert data to GPU automatically when called

However, it's unclear whether save/slice operations handle GPU arrays automatically or if manual conversion to CPU is required.

Expected behavior

Could you clarify:

• Does adata.write() automatically transfer GPU data to CPU before saving?
• Do slicing operations work with GPU arrays, or do they require CPU conversion first?
• If manual conversion is needed, should we call anndata_to_CPU() or just move .X back?

Example code

import rapids_singlecell as rsc
import scanpy as sc

adata = sc.read_h5ad('input.h5ad')
adata = rsc.get.anndata_to_GPU(adata)

# Process data
rsc.pp.normalize_total(adata)
rsc.pp.log1p(adata)

# Do I need this before saving/slicing?
# adata = rsc.get.anndata_to_CPU(adata)

# Save
adata.write('output.h5ad')

# Slice
subset = adata[adata.obs['cell_type'] == 'T cell']

Thanks for the clarification!

2
In Scanpy, sc.tl.leiden() and sc.tl.louvain() support a flavor parameter to choose different implementations (e.g., flavor='igraph', flavor='vtraag').

Does rsc.tl.leiden() / rsc.tl.louvain() support the same parameter? Or does it only use the cuGraph implementation?

Use case

I'm migrating existing Scanpy workflows to rapids-singlecell and some of them specify flavor='igraph' for clustering. I'd like to know if:

1. This parameter is supported in rsc
2. If not, is the cuGraph implementation expected to give similar results?
3. Are there any plans to support multiple flavors?

Example

import rapids_singlecell as rsc

# Does this work?
rsc.tl.leiden(adata, flavor='igraph')

# Or is only cuGraph supported?
rsc.tl.leiden(adata)

Context

Since cuGraph is GPU-accelerated and igraph/vtraag are CPU implementations, I understand if only cuGraph is supported. Just want to confirm the expected behavior.

Thanks!

[Intron7]

For future questions of this type (workflow structure, when conversions happen, how functions interact), the best place to ask is the scverse Discourse:

https://discourse.scverse.org/c/help/rsc/48

That forum is better suited for longer explanations, follow-up questions, and exploratory discussions.
The GitHub issue tracker is mainly for bug reports, missing documentation, or clear API inconsistencies.

Since rsc builds on Scanpy, AnnData, cuML, and CuPy, it’s also important to check the documentation of those packages when working with CLI tools or mixed CPU/GPU workflows.

In many cases, you can also verify expected behaviour by running a small test AnnData example — the demo notebooks are set up to make this easy.

If anything in the rsc documentation is unclear or incomplete, I’m happy to improve it — just let me know.