Skip to content

Pull nightly cuopt wheels in build workflows - #17

Draft
0x17 wants to merge 3 commits into
mainfrom
multi-gpu
Draft

0x17 wants to merge 3 commits into
mainfrom
multi-gpu

Conversation

@0x17

@0x17 0x17 commented Sep 15, 2026

Copy link
Copy Markdown
Member

Track NVIDIA's nightly cuopt-cu12/cuopt-cu13 wheels (26.10 dev channel) instead of the pinned 26.8 stable release, so future builds on this branch stay current with pre-release fixes. This intentionally does not touch gmscuopt.c: the new multi-GPU PDLP feature is not reachable through the C API in any nightly build yet (confirmed by tracing cuOptSolve -> solve_lp_with_method -> run_pdlp, none of which read num_gpus for method=PDLP; distributed dispatch only exists in the mps_data_model-based solve_lp overload used by cuopt_cli, which the C API never calls).

Track NVIDIA's nightly cuopt-cu12/cuopt-cu13 wheels (26.10 dev
channel) instead of the pinned 26.8 stable release, so future builds
on this branch stay current with pre-release fixes. This intentionally
does not touch gmscuopt.c: the new multi-GPU PDLP feature is not
reachable through the C API in any nightly build yet (confirmed by
tracing cuOptSolve -> solve_lp_with_method -> run_pdlp, none of which
read num_gpus for method=PDLP; distributed dispatch only exists in the
mps_data_model-based solve_lp overload used by cuopt_cli, which the C
API never calls).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@0x17 0x17 self-assigned this Sep 15, 2026
0x17 and others added 2 commits September 15, 2026 15:25
uv's default index-strategy stops looking once it finds a matching
package name on an index, even if no version there satisfies the
constraint. Since pypi.nvidia.com only has stable cuopt-cu12/cuopt-cu13
releases (up to 26.8.0), uv found the package there first and refused
to fall through to the nightly index for a 26.10.* build, failing
resolution. Verified locally (dry-run) that the nightly index alone
resolves all cu12/cu13 dependencies for both x86_64 and arm64.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
cuOpt's C API accepts num_gpus up to 72, but the concurrent-mode code
path it actually drives (solve.cu) hardcodes the barrier thread to
device index 1, so values above 2 are accepted without error but have
no further effect. Widen the GAMS option's upper bound to match the
C API so it's not artificially more restrictive, and make the
description explicit about the 2-GPU cap so users aren't misled into
expecting more speedup from higher values.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant