[FEA]: reduce binary size

[jameslamb]

Is this a new feature, an improvement, or a change to existing functionality?

New Feature

How would you describe the priority of this feature request

Medium

Please provide a clear description of problem this feature solves

As of this writing, the latest 26.06 libcugraph wheels have the following sizes:

distribution	arch	size (compressed)	size (uncompressed)
libcugraph-cu12	x86_64	1626 MiB	2402 MiB
libcugraph-cu12	aarch64	1617 MiB	2361 MiB
libcugraph-cu13	x86_64	771 MiB	991 MiB
libcugraph-cu13	aarch64	762 MiB	959 MiB

NOTE: v26.6.0a18, latest 26.06 nightly as of Mar 23, 2026

how I got those sizes (click me)

mkdir -p delete-me

platforms=(
  aarch64
  x86_64
)

suffixes=(
  cu12
  cu13
)

for p in "${platforms[@]}"; do
  for s in "${suffixes[@]}"; do
    pip download \
      -d ./delete-me \
      --no-deps \
      --only-binary ':all:' \
      --platform "manylinux_2_28_${p}" \
      --extra-index-url https://pypi.anaconda.org/rapidsai-wheels-nightly/simple/ \
      "libcugraph-${s}>=26.6.0a0"
  done
done

pydistcheck \
  --inspect \
  --output-file-size-unit 'Mi' \
  ./delete-me/*.whl

Such large packages require a relatively large amount of network bandwidth to download and disk space to store, and are not allowed on pypi.org.

PyPI hard limits:

• 1 GiB per file
• 100 GiB total for a project

This issue tracks the work of reducing those sizes.

Describe your ideal solution

Some ideas for how to address this:

• compiling fewer combinations of templates
  • [FEA] Reduce template parameters cuvs#110
  • e.g. more changes like Don't compile int32_t/int64_t vertex_t/edge_t combinations #4720
• tuning compiler flags to optimize for binary size
• checking the wheel contents and removing any extraneous files found
• replacing static linking / vendoring with dynamic linking where possible
• code changes to avoid recompiling the same kernels multiple times
  • related conversation: [Opt] the binary size of libcuvs is increasing when add .cu files cuvs#634
• using JIT-LTO to avoid ahead-of-time compiling some kernels
  • related effort in cuVS: [EPIC] Reducing binary size of libcuvs.so cuvs#1512

Describe any alternatives you have considered

N/A

Additional context

For more ideas, see the similar effort @divyegala has been leading in cuVS: rapidsai/cuvs#1512

Code of Conduct

• I agree to follow cuGraph's Code of Conduct
• I have searched the open feature requests and have found no duplicates for this feature request