GPU-accelerated single-cell analysis at scale with rapids-singlecell
Abstract: Single-cell sequencing technologies reveal cellular heterogeneity at high resolution, advancing our understanding of biological complexity. As datasets start to scale to tens of millions of cells, computational workflows face substantial bottlenecks, with CPU-based analytical pipelines requiring hours or days for routine processing steps like filtering, normalization, and clustering. These scalability limitations fundamentally restrict common interactive data exploration and iterative hypothesis testing. Here we introduce rapids-singlecell, a GPU-accelerated framework that integrates natively with the scverse ecosystem and operates directly on the AnnData data structure, which delivers orders-of-magnitude speedups for single-cell workflows. Built on CuPy arrays and the NVIDIA CUDA-X Data Science (RAPIDS) ecosystem, rapids-singlecell provides near drop-in GPU replacements for core scanpy-based analysis steps. Across standard single-cell workflows such as preprocessing, dimensionality reduction, neighborhood graph construction, clustering, and batch correction, rapids-singlecell achieves speedups of up to several hundred-fold compared to optimized CPU baselines. This reduces analysis time from hours to minutes on standard hardware, while maintaining consistent biological interpretations. These performance improvements make it possible to analyze large data sets in close to real time, without the need for data splitting. Together with real-time parameter tuning and iterative workflows, rapids-singlecell makes interactive large-scale single-cell analysis possible.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What is this paper about?
This paper introduces rapids-singlecell, a free software toolkit that makes analyzing very large single-cell gene data much faster by using graphics cards (GPUs). It plugs into the tools many biologists already use and turns hours-long steps into tasks that finish in seconds or minutes—so scientists can explore and test ideas interactively, even on datasets with millions to 100 million cells.
What questions did the researchers ask?
In simple terms, they asked:
- Single-cell datasets are getting huge. Can we make the usual analysis steps (cleaning data, finding patterns, grouping cells, correcting batch effects) fast enough to feel “instant”?
- Can we speed things up without forcing people to rewrite all their code or change tools?
- Will the faster, GPU-based results match the scientific conclusions from the usual CPU-based tools?
How did they do it?
Think of analyzing cells like organizing a giant library:
- Each “cell” is like a book.
- Each “gene” is like a line in the book’s index.
- Most cells don’t use most genes, so the data table is mostly zeros (this is called “sparse” data).
On regular computers (CPUs), sorting and comparing millions of “books” can take forever. A GPU is like having thousands of helpers who can work at the same time, which is perfect for jobs that can be split into many small, similar tasks.
What the team built:
- rapids-singlecell sits inside the popular scverse/scanpy ecosystem and works directly with the standard AnnData format (the “box” many scientists already store their single-cell data in).
- It swaps out slow parts for fast GPU versions, using:
- CuPy (a NumPy-like library for GPUs) that handles sparse data without turning it into big, memory-hungry tables.
- RAPIDS (NVIDIA’s GPU data science tools) for machine learning, graphs, and nearest neighbors.
- Dask for handling data that is too big for one GPU and for splitting work across multiple GPUs.
- Memory smarts: If the GPU runs out of memory, the tool “spills” to the computer’s main memory so it can still finish, just a bit slower.
- Minimal changes: Many scanpy functions have nearly identical GPU versions, so people can switch with only small edits to their scripts.
Everyday analogies for key steps:
- Normalization and scaling: like adjusting all book page counts so they’re comparable.
- PCA/UMAP/t-SNE (dimensionality reduction): like compressing long book descriptions into short summaries that are easier to compare and visualize.
- Nearest neighbors and clustering (Leiden): like finding which books are most similar and sorting them into shelves (groups).
- Batch correction (Harmony): like fixing differences caused by different printers or print days so only the content matters.
What did they find?
They measured speed on big real datasets and compared “normal CPU” vs “GPU with rapids-singlecell.”
Key results:
- One dataset with about 1.3 million cells took ~52 minutes on a strong 32‑core CPU, but only ~26 seconds on a single GPU (over 120× faster).
- Individual steps saw huge boosts:
- Preprocessing: ~70Ă— faster
- UMAP: ~350Ă— faster
- Clustering (Leiden): ~100Ă— faster
- Batch correction with Harmony:
- ~100Ă— faster on ~200,000 cells
- >250Ă— faster on 2.4 million cells
- On 11.4 million cells, every tested GPU finished in under 25 seconds, while the CPU version didn’t finish within 2 hours.
- Ultra‑large scale: With 8 GPUs, they analyzed a 100 million cell dataset in under 20 minutes.
Do the results still make biological sense?
- Yes. While tiny numerical differences happen (that’s normal with massively parallel math), the biological conclusions—like which cells cluster together and which genes mark a cell type—match the CPU versions.
Limits and trade‑offs:
- For small datasets (roughly under 50,000 cells), CPUs can be just as fast or faster because starting up the GPU has some overhead.
- If the GPU has very little memory, it still works but speedups shrink.
- Some steps not yet on GPU fall back to CPU and may add data transfer time.
- Exact “bit‑for‑bit” identical results aren’t guaranteed for random or parallel algorithms, but the scientific meaning remains consistent.
Why is this important?
Speed changes what’s possible:
- Scientists can explore big datasets interactively—tweak settings, try different methods, and immediately see the results.
- Building huge cell atlases (maps of many cell types across tissues and conditions) becomes practical.
- Faster turnaround can help clinical and translational research, where time to insight matters.
- It lowers barriers: you can handle millions of cells on a single workstation GPU, and scale to tens of millions or 100 million with multiple GPUs.
What could this change in the future?
- As single-cell and spatial data keep growing, GPU acceleration will be increasingly essential.
- The toolkit is open-source and designed to expand—more methods can be added, including for spatial transcriptomics and new AI models for biology.
- Because it matches the scanpy API and uses AnnData, labs can adopt it step by step without throwing away their current workflows.
Key terms in simple words
- Single-cell sequencing: measuring which genes are active in each individual cell.
- Sparse data: a table with lots of zeros; most entries are empty.
- CPU vs GPU: CPU is like 1–32 workers good at many tasks; GPU is like thousands of workers great at doing the same kind of task many times in parallel.
- PCA/UMAP/t-SNE: tools that turn complex data into simpler, 2D or 3D shapes you can plot.
- Clustering (Leiden): grouping similar cells together.
- Batch correction (Harmony): removing technical differences so datasets from different runs can be fairly compared.
Knowledge Gaps
Unresolved knowledge gaps, limitations, and open questions
Below is a single, concrete list of what remains missing, uncertain, or unexplored based on the paper. Each point is phrased to guide actionable follow-up work.
- Portability beyond NVIDIA CUDA: no support for AMD/ROCm, Intel GPUs, or SYCL; pathway and feasibility for a vendor-agnostic backend remain undefined.
- Sparse index ceiling: CuPy’s int32 CSR/CSC indices cap nnz and practical cell counts; lack of 64-bit sparse indexing on GPU and its performance implications are not addressed.
- Global algorithms on partitioned data: how kNN graphs, UMAP, and Leiden maintain accuracy and consistency when constructed across Dask partitions (chunk boundaries, ghost regions, stitching) is not quantified.
- Automatic chunk-size selection: no principled, data- and hardware-aware heuristic to set Dask chunk sizes; impact on both runtime and result quality is unstudied.
- Deterministic reproducibility: no “deterministic mode” or kernel variants to eliminate non-deterministic atomics and reduce floating-point order effects for audit/regulatory use.
- CPU↔GPU routing: no automatic planner to decide per-step CPU vs GPU execution for small datasets (<~50k cells) to avoid GPU overhead and minimize host-device transfers.
- Mixed pipelines overhead: when functions fall back to CPU, the cumulative cost of repeated data movement to/from GPU is unquantified; need strategies to keep data resident.
- Coverage gaps in scverse/scanpy APIs: unspecified missing methods (e.g., differential expression tests, trajectory inference/PAGA, RNA velocity, cell–cell communication) and roadmaps for GPU equivalents.
- Batch correction diversity: GPU support is shown only for Harmony; lack of GPU-accelerated alternatives (BBKNN, fastMNN, Scanorama, scVI/totalVI-based integration) and their comparative performance/accuracy at scale.
- Modality breadth: no benchmarks for scATAC-seq, multiome (RNA+ATAC), CITE-seq, or methylation data with different sparsity/statistics; algorithm suitability and accuracy on these modalities are unknown.
- Spatial analysis scope: beyond Moran’s I and Geary’s C, broader Squidpy workflows (image feature extraction, segmentation, spatial graph building) lack GPU acceleration and validation.
- Approximate neighbor search details: cuVS index types, recall–throughput trade-offs, and their downstream impact on clustering/UMAP quality are not reported.
- Numerical precision: no exploration of FP16/BF16 or mixed precision for speed/memory gains, nor the impact of reduced precision on biological interpretability.
- Oversubscription thresholds: absence of quantitative guidance on when RMM oversubscription starts to thrash, degrade runtime severely, or affect numerical stability.
- Multi-GPU scaling efficiency: lack of strong-scaling/weak-scaling curves, NVLink vs PCIe vs multi-node network comparisons, and fault-tolerance behavior under Dask.
- End-to-end I/O: benchmarks exclude I/O; for large h5ad/Zarr workflows, file read/write, compression, and serialization may be dominant—GPU-accelerated I/O and end-to-end timings are missing.
- Energy and cost efficiency: no power/energy measurements or cost-per-analysis comparisons against multi-core/multi-node CPU alternatives for practical procurement decisions.
- Quality metrics breadth: validation focuses on ARI/neighborhood preservation; effects on DE tests, marker gene ranking stability, batch-mixing metrics (e.g., kBET, LISI), and biological annotation consistency across seeds/hardware are not comprehensively quantified.
- Hardware guidance: specific, evidence-based recommendations (VRAM vs dataset size/sparsity, cores vs memory bandwidth) and minimal configurations for interactive performance are not provided.
- Failure modes and resilience: behavior under GPU memory pressure, Dask task failures, or heterogeneous hardware is not characterized; checkpointing and incremental recomputation strategies are unspecified.
- Parameter auto-tuning: despite enabling rapid sweeps, there is no built-in mechanism for automated hyperparameter search (e.g., neighbor k, UMAP min_dist, Leiden resolution) with quality-aware selection.
- Memory fragmentation and pooling: impact of RMM pool settings, fragmentation, and CSR↔CSC conversions on long-running interactive sessions is unevaluated.
- Kernel maintenance and portability: long-term stability of custom RawKernels across CUDA versions/architectures and test coverage for numerical correctness are not discussed.
- Interop with deep learning models: pathways to integrate with scVI/totalVI, diffusion models, or “foundation models” while minimizing data copies and synchronizing memory are future work, not specified.
- Streaming/online analysis: no support for real-time or incremental updates as new cells arrive (e.g., in clinical pipelines), including updating PCA/kNN/UMAP without full recomputation.
- Security and privacy: distributed/multi-node execution with PHI is not covered (data encryption, access control, audit logging), relevant for clinical deployment.
- Visualization at scale: interactive plotting/rendering of embeddings for tens of millions of points (e.g., GPU-side rasterization, progressive refinement) is not addressed.
- Fairness of CPU baselines: benchmarks are limited to a single high-end CPU node; comparisons to optimized multi-node CPU clusters and alternative CPU libraries/backends are absent.
- Comprehensive roadmap: the paper mentions future support for spatial and broader hardware, but lacks a prioritized, time-bounded roadmap and community contribution guidelines for missing methods.
Practical Applications
Immediate Applications
Below is a concise list of concrete, deployable use cases that leverage the paper’s findings and software to deliver real-world impact now.
- Drop-in acceleration of Scanpy pipelines for large datasets (academia, biotech/pharma, software/IT) Use rapids-singlecell as a near drop-in replacement for CPU Scanpy workflows (preprocessing, PCA/UMAP/t-SNE, neighbors, Leiden, Harmony) to cut runtimes from hours to seconds/minutes for 1–10M+ cells. Potential tools/workflows: Jupyter notebooks and script-based pipelines using AnnData, CuPy, RAPIDS (cuML, cuGraph), Dask; containerized images (pip/conda). Assumptions/dependencies: CUDA-capable GPU (consumer/pro workstation/datacenter), RAPIDS/CuPy/Dask versions aligned, dataset size typically >50k cells to see speedups; minor non-deterministic numerical differences acceptable.
- Interactive parameter sweeps and QC dashboards (academia, pharma discovery, healthcare translational labs) Enable real-time hyperparameter tuning (e.g., Leiden resolution, UMAP parameters), threshold experiments, and rapid embedding comparisons during data exploration and lab meetings. Potential tools/workflows: Live notebooks (Voila/Streamlit + rapids-singlecell), GPU-backed job schedulers; precomputed PCA embeddings for fast sweeps. Assumptions/dependencies: GPU access; acceptance of slight stochastic variance; versioned environments for reproducibility.
- Multi-GPU out-of-core atlas construction with Dask (consortia, public data platforms, cloud providers) Build and refresh multi-million–hundred-million cell atlases (e.g., Tahoe 100M) in minutes using Dask partitioning and multi-GPU scaling. Potential tools/workflows: Dask clusters (on-prem or cloud), chunked AnnData processing, automated nightly updates of atlases. Assumptions/dependencies: Aggregate GPU memory/compute; operational Dask cluster; data locality and I/O bandwidth; int32 sparse index limits mitigated via chunking.
- Fast batch correction at scale with Harmony-GPU (academia, pharma, clinical research) Integrate diverse cohorts (hundreds of thousands to millions of cells) rapidly to harmonize embeddings for downstream comparative analyses. Potential tools/workflows: rapids-singlecell Harmony on PCA embeddings; integration pipelines for multi-center studies. Assumptions/dependencies: GPUs; consistent preprocessing across batches; validation of biological equivalence post-correction.
- Accelerated perturbation analysis (CRISPR/drug screens) via GPU E-distance (biotech/pharma R&D) Quantify transcriptomic differences between conditions/groups at scale, enabling more screens per day and richer bootstrapped confidence intervals. Potential tools/workflows: rapids_singlecell.ptg.Distance for pairwise and one-sided comparisons; automated reporting. Assumptions/dependencies: Well-defined groups and embeddings; GPU-enabled bootstrap; careful statistical interpretation.
- Spatial statistics at scale (spatial transcriptomics) using Moran’s I & Geary’s C (academia, biotech) Compute global/local spatial autocorrelation quickly across large tissue sections for rapid spatial feature discovery. Potential tools/workflows: Squidpy-compatible workflows accelerated via CuPy within AnnData. Assumptions/dependencies: Adequate GPU memory or Dask chunking; appropriate spatial weight matrices; planned broader spatial support will expand scope.
- Cloud “GPU single-cell analysis as a service” (cloud/IT, software vendors) Offer managed rapids-singlecell environments with autoscaling GPUs and Dask clusters for large-scale analyses and collaborative sessions. Potential tools/workflows: Kubernetes + RAPIDS, NGC/conda images, multi-tenant notebook servers with GPU pools. Assumptions/dependencies: Cost management; user data privacy; version pinning across tenants.
- Teaching and training with realistic large datasets (education) Run lab exercises on million-cell data interactively, making advanced single-cell methods accessible to students without overnight jobs. Potential tools/workflows: Preprovisioned GPU lab machines/cloud credits; annotated notebooks; classroom-scale datasets. Assumptions/dependencies: Entry-level GPUs or shared cloud; curriculum adapted to minor stochastic differences.
- Clinical/translational pipeline acceleration for research use (healthcare/clinical research labs) Shrink time from sequencing to analysis for translational projects (e.g., tumor microenvironment profiling), enabling same-day exploratory results. Potential tools/workflows: SOPs with rapids-singlecell replacing CPU steps; semi-automated QC and clustering dashboards. Assumptions/dependencies: Not a regulated diagnostic; documented versions/hardware; staff trained in GPU workflows.
- Cost and energy optimization in HPC (IT operations, sustainability) Use GPU acceleration to reduce wall-clock time and potentially energy per analysis relative to long-running CPU jobs. Potential tools/workflows: Job scheduling that prioritizes GPU nodes for single-cell; measurement of energy/performance metrics. Assumptions/dependencies: Local energy profile of GPUs vs CPUs; workload size sufficient to realize efficiency gains.
Long-Term Applications
The following use cases require additional research, integration, scaling, or regulatory steps before widespread deployment.
- Near-instrument, real-time single-cell analysis for clinical decision support (healthcare) Integrate GPU analysis pipelines with sequencing instruments to deliver interpretable clusters and differential signatures within clinical windows. Potential tools/products: “On-instrument analysis” modules; validated clinical dashboards with automated parameter sweeps and QC gates. Assumptions/dependencies: Regulatory validation; deterministic/reproducible configurations; robust data governance; standardized SOPs.
- National-scale interactive cell atlas platforms (policy, public data platforms, academia) Launch portals that allow real-time exploration and re-analysis of 100M+ cells with on-demand GPU-backed computations for the public and researchers. Potential tools/products: Federated Dask clusters across institutions; caching layers; provenance-aware analysis notebooks. Assumptions/dependencies: Sustainable public funding; data sharing agreements; cloud/HPC procurement; fair-use governance.
- Experiment-in-the-loop automation with robotics (robotics, biotech/pharma) Couple rapid analysis with automated liquid handlers/CRISPR screens to adapt protocols based on immediate cluster/perturbation outcomes. Potential tools/products: Orchestration software linking LIMS/robots to rapids-singlecell outputs; closed-loop optimization. Assumptions/dependencies: Reliable streaming data; robust APIs; safety and compliance in automated labs.
- Integration with foundation models for cell biology (academia, biotech) Use GPUs to couple rapids-singlecell with large pretrained models (e.g., for denoising, annotation, generative embeddings), enabling richer analyses at scale. Potential tools/products: Hybrid pipelines combining RAPIDS with model inference/finetuning; annotation assistants. Assumptions/dependencies: Model availability and licensing; GPU memory; benchmarked biological fidelity.
- Deterministic, audit-ready GPU pipelines for regulated settings (policy, healthcare) Develop deterministic modes and audit frameworks (e.g., mlf-core extensions) to reconcile GPU parallelism with regulatory demands for reproducibility. Potential tools/products: Locked-down container images; hardware/version provenance capture; standardized random seed controls. Assumptions/dependencies: Community standards; acceptance by regulators; possible performance trade-offs.
- Cross-vendor accelerator support to democratize access (policy, software/IT) Port key kernels and dependencies beyond CUDA (e.g., HIP/ROCm, oneAPI) to widen hardware options and reduce vendor lock-in. Potential tools/products: Backend-agnostic sparse arrays; accelerator abstraction layers in scverse. Assumptions/dependencies: Maturity of alternative GPU ecosystems; sparse support parity; developer bandwidth.
- Streaming single-cell pipelines for time-series and spatial omics (academia, biotech) Process data as it arrives (time-lapse, high-res spatial) with GPU kernels optimized for streaming and tiling, enabling live monitoring of experiments. Potential tools/products: Incremental PCA/UMAP, streaming neighbor graphs, live spatial autocorrelation. Assumptions/dependencies: Algorithmic developments for online updates; I/O streaming; memory management refinements.
- Enterprise single-cell MLOps platforms (software/IT, biotech/pharma) Productize end-to-end GPU workflows: environment pinning, job orchestration, monitoring, cost/energy tracking, and provenance for large teams. Potential tools/products: Managed services with RAPIDS/Dask; observability dashboards; cost-aware scheduling. Assumptions/dependencies: Organizational buy-in; integration with identity/security; training.
- Energy and sustainability policy for computational biology (policy) Establish guidelines that incentivize energy-efficient GPU workflows for large-scale omics, including carbon accounting and procurement standards. Potential tools/products: Benchmarked energy profiles; policy frameworks for grant reviewers; institutional best practices. Assumptions/dependencies: Transparent metrics; collaboration with HPC centers; balancing cost, performance, and emissions.
- Auto-delegation across scverse and mixed CPU/GPU workflows (software ecosystem) Seamless routing of function calls to GPU-backed implementations when beneficial, with intelligent fallbacks and profiling. Potential tools/products: scverse-wide auto-delegation layer; per-step cost/benefit advisors; hybrid execution planners. Assumptions/dependencies: Ongoing development in scverse; accurate profilers; user controls over determinism vs speed.
Glossary
- Adjusted Rand index: A statistic for comparing the similarity between two clusterings, adjusted for chance. "adjusted Rand index for cluster assignments"
- AnnData: A standardized data structure for annotated matrices used in single-cell omics workflows. "operates directly on the AnnData data structure"
- Array API (standard): A cross-library specification that standardizes array operations and interfaces across Python numerical libraries. "adoption of the array API standard."
- AUCell: A gene set enrichment method that scores whether a set of genes is active within each cell. "multivariate linear model (mlm), univariate linear model (ulm), weighted aggregate (waggr), AUCell, and z-score."
- Batch correction: Procedures that adjust data to remove non-biological differences between batches or experiments. "GPU-accelerated batch correction using the Harmony algorithm"
- Compressed Sparse Column (CSC): A sparse matrix storage format optimized for fast column access. "Compressed Sparse Row (CSR) and Compressed Sparse Column (CSC) formats."
- Compressed Sparse Row (CSR): A sparse matrix storage format optimized for fast row access. "Compressed Sparse Row (CSR) and Compressed Sparse Column (CSC) formats."
- CUDA RawKernels: Low-level, custom CUDA kernels JIT-compiled via CuPy for fine-grained GPU control. "CuPy CUDA RawKernels - just-in-time (JIT) compiled CUDA kernels - that allow writing custom GPU code directly in Python and C (Methods)."
- CUDA-X Data Science (RAPIDS): NVIDIA’s suite of GPU-accelerated libraries for end-to-end data science workflows. "Built on CuPy arrays and the NVIDIA CUDA-X Data Science (RAPIDS) ecosystem"
- cuDF: A GPU DataFrame library within RAPIDS for pandas-like data manipulation on GPUs. "cuML (v25.12.0), cuDF (v25.12.0), and RMM (v25.12.0)."
- cuGraph: A RAPIDS library providing GPU-accelerated graph algorithms. "cuGraph for graph-based computations (e.g., clustering)"
- cuML: A RAPIDS library of GPU-accelerated machine learning algorithms. "including cuML14 for machine learning tasks (e.g., PCA, UMAP15)"
- cuVS: A RAPIDS library for high-performance vector search and nearest-neighbor retrieval. "and cuVS for vector search (Methods)."
- Dask: A parallel computing framework for task scheduling and out-of-core, multi-GPU execution. "integrates Dask16, a parallel computing framework that facilitates out-of-core and multi-GPU computations (Methods)."
- delta method: A statistical technique to approximate the variance of a function of random variables. "The variance of the energy distance is approximated via the delta method:"
- Diffusion map: A manifold learning technique that constructs low-dimensional embeddings using diffusion processes on graphs. "Diffusion map"
- Energy distance (E-distance): A metric that quantifies differences between probability distributions based on pairwise distances. "energy distance (E-distance) metric"
- Geary's C: A spatial autocorrelation statistic measuring local dissimilarity between neighboring observations. "Geary's C measures local dissimilarity:"
- HBM3e: A high-bandwidth memory standard used in GPUs for increased throughput. "192 GB HBM3e"
- Harmony: A batch effect correction algorithm for integrating single-cell datasets across conditions or experiments. "using the Harmony algorithm integrated in rapids-singlecell."
- Highly variable gene (HVG): Genes with elevated expression variance used to select informative features in single-cell analysis. "highly variable gene (HVG) selection"
- igraph backend: A graph analysis backend/library used to accelerate community detection and related operations. "the faster igraph backend"
- JIT (just-in-time) compilation: Runtime compilation that translates code to machine instructions at execution time for performance. "just-in-time (JIT) compiled CUDA kernels"
- Leiden clustering: A community detection algorithm for partitioning graphs into clusters with improved guarantees over Louvain. "Leiden clustering (Methods)."
- leidenalg: A software package implementing the Leiden algorithm for community detection. "leidenalg (v0.11.0)"
- Moran's I: A spatial autocorrelation statistic measuring global spatial similarity across a dataset. "Moran's I measures global spatial autocorrelation:"
- obsm: An AnnData slot for storing multidimensional arrays (e.g., embeddings) associated with observations (cells). "stored in adata.obsm (e.g., PCA coordinates)"
- obsp: An AnnData slot for storing pairwise (often sparse) matrices between observations (e.g., graphs). "Results are stored in AnnData .obsp slots"
- out-of-core processing: A technique to process datasets larger than memory by streaming data in chunks. "for GPU-accelerated computation and out-of-core processing."
- oversubscription: Allowing memory usage to exceed on-device capacity by spilling data to host memory. "supports oversubscription."
- pertpy: A framework for perturbation analysis in single-cell data, supporting metrics like energy distance. "from pertpy through the ptg (pertpy-GPU) submodule."
- PyNNDescent: An approximate nearest neighbor search algorithm/library based on the NN-Descent method. "PyNNDescent (v0.5.13)"
- RAPIDS Memory Manager (RMM): A GPU memory manager providing pooling and automatic spilling to host memory. "RAPIDS Memory Manager (RMM)"
- scanpy: A widely used Python library for scalable single-cell omics analysis. "near drop-in GPU replacements for core scanpy-based analysis steps."
- scverse: A community ecosystem of interoperable tools and data structures for single-cell omics in Python. "Rapids-singlecell integrates into the scverse3 ecosystem"
- sparse Gram matrix: A Gram (inner-product) matrix computed directly from sparse data representations. "sparse gram matrix computation"
- squidpy: A Python framework for spatial single-cell analysis and spatial statistics. "Rapids-singlecell accelerates spatial statistics from Squidpy8."
- stencil-based discretizations: Numerical methods using local stencil operations on grids, common in PDE/HPC contexts. "typical stencil-based discretizations."
- t-SNE: A non-linear dimensionality reduction method for visualizing high-dimensional data in low dimensions. "Non-linear embeddings (UMAP, t-SNE) use cuML implementations."
- UMAP: A graph-based manifold learning algorithm for dimensionality reduction and visualization. "Non-linear embeddings (UMAP, t-SNE) use cuML implementations."
- vector search: High-dimensional nearest neighbor search used for similarity queries over embeddings. "vector search (Methods)"
Collections
Sign up for free to add this paper to one or more collections.